การเข้าสู่ระบบ VPN ค้างหลัง Access-Challenge ของ RADIUS

รหัสผ่านของคุณถูกต้อง แต่การเข้าสู่ระบบ VPN กลับล้มเหลว และ RADIUS server อาจทำตามที่สั่งไว้อย่างถูกต้องแล้วก็ได้ เกตเวย์น่าจะได้รับ Access-Challenge ไม่ได้แสดงอะไรที่เป็นประโยชน์ แล้วก็หมดเวลาหรือถือว่าคำตอบนั้นเป็นการปฏิเสธ จากฝั่งไคลเอนต์ดูเหมือนข้อมูลรับรองผิดหรืออุโมงค์เสีย สาเหตุมักอยู่กลางบทสนทนาที่ไม่มีใครบันทึกไว้

หนึ่งการเข้าสู่ระบบ สองการแลกเปลี่ยนกับ RADIUS

เมื่อแบ็กเอนด์ต้องการปัจจัยที่สอง มันไม่ตอบคำขอแรกด้วยการยอมรับหรือปฏิเสธ แต่ตอบด้วยรหัส 11 แล้วรอคำตอบถัดไปของผู้ใช้ ซึ่งเกตเวย์ต้องส่งกลับไปในคำขอติดตาม คำขอติดตามนั้นเป็นของบทสนทนาการยืนยันตัวตนเดียวกัน ไม่ใช่ความพยายามเข้าสู่ระบบใหม่

ในการตั้งค่าที่ทำงานได้ ผู้ใช้จะเห็นพรอมต์ที่สอง คือรหัสผ่านก่อน จากนั้นรหัสใช้ครั้งเดียว หรือพรอมต์รวมเพียงอันเดียวหากผู้ดูแลเอกสารไว้ ในการตั้งค่าที่เสีย พรอมต์ที่สองจะไม่ปรากฏเลยและการเข้าสู่ระบบก็ล้มเหลวเฉย ๆ

นี่คืออาการที่ต้องตามหา และยืนยันได้ง่ายจากฝั่งไคลเอนต์เพียงอย่างเดียว ถ้าไคลเอนต์ VPN ขอความลับเพียงหนึ่งเดียวแล้วปฏิเสธรหัสผ่านที่คุณรู้ว่าถูกต้อง การแลกเปลี่ยนน่าจะจบลงที่ชาเลนจ์

ชาเลนจ์บรรจุอะไรจริง ๆ

ข้อกำหนด RADIUS อธิบายรหัส 11 ในหัวข้อ 4.4 และอนุญาตแอตทริบิวต์สองตัวที่สำคัญที่นี่ Reply-Message เก็บข้อความสำหรับผู้ใช้ และ State เก็บค่าที่ไม่โปร่งใสซึ่งเซิร์ฟเวอร์ต้องการให้ส่งกลับมา NAS ไม่ควรตีความ State แต่ควรคืนค่าโดยไม่เปลี่ยนแปลง

คำขอติดตามใช้ Identifier ใหม่และ Request Authenticator ใหม่ และต้องพาค่า State เดียวกันพร้อมคำตอบของผู้ใช้ เซิร์ฟเวอร์จับคู่กับชาเลนจ์ที่ค้างอยู่ผ่าน State นั้น จึงเป็นเหตุให้เกตเวย์ที่สร้างแอตทริบิวต์ใหม่หรือทิ้งมันไปไม่สามารถทำพิธีให้เสร็จได้ response authenticator ในทุกคำตอบก็ต้องผ่านการตรวจสอบด้วย มิฉะนั้น NAS ควรทิ้งแพ็กเก็ต

หัวข้อ 4.4 เพิ่มรายละเอียดที่อธิบายความล้มเหลวเงียบส่วนใหญ่ NAS ที่รองรับชาเลนจ์ไม่ได้จะถือว่า Access-Challenge เป็นการปฏิเสธ หากบริการ VPN ของเกตเวย์คุณเก่ากว่าการรองรับนั้นหรือละเว้นมันไป คำขอปัจจัยที่สองจากแบ็กเอนด์จะกลายเป็น «การยืนยันตัวตนล้มเหลว» ทันทีโดยไม่มีพรอมต์ใด ๆ

คำขอแบบลูกโซ่หายไปตรงไหน

ผู้ต้องสงสัยคนแรกคือเส้นทางของพรอมต์ ไม่ใช่ข้อมูลรับรอง พอร์ทัลที่แสดงช่อง OTP สำหรับการเข้าสู่ระบบเว็บไม่ได้ทำเช่นนั้นโดยอัตโนมัติสำหรับบริการ VPN และเกตเวย์บางตัวส่งชาเลนจ์ให้เฉพาะไคลเอนต์ที่ประกาศความสามารถนั้น ทดสอบบัญชีเดียวกันที่จุดเข้าใช้ทั้งสอง หากพอร์ทัลทำงานแต่ VPN ไม่ทำงาน คุณกำลังดูการส่งต่อ ไม่ใช่โทเคน

รูปแบบอินพุตเป็นผู้ต้องสงสัยคนที่สอง การต่อรหัสผ่านและรหัสเข้าด้วยกันโดยไม่มีตัวคั่นที่ผู้ขายเอกสารไว้ หรือปล่อยให้ข้อมูลรับรองที่บันทึกไว้เล่นรหัสเก่าซ้ำ จะล้มเหลวในลักษณะที่ดูเหมือนรหัสผ่านผิดทุกประการ ใช้พรอมต์แยกหรือรูปแบบรวมที่ผู้ดูแลเอกสารไว้ และอย่าคิดค้นตัวคั่นเอง

ข้อบกพร่องเฉพาะรุ่นมีอยู่จริง แต่รายการรุ่นที่แก้ไขแล้วเมื่อหลายปีก่อนไม่ใช่การวินิจฉัยสำหรับการติดตั้งวันนี้ อ่านบันทึกการออกรุ่นของซอฟต์แวร์ที่คุณใช้งานจริง และเก็บขั้นตอนการแลกเปลี่ยนที่สังเกตได้ไว้เป็นหลักฐาน

ติดตามความพยายามครั้งเดียวตั้งแต่ต้นจนจบ

ทำซ้ำหนึ่งครั้งโดยเปิดการดีบักฝั่งเซิร์ฟเวอร์ และกันเซสชันอื่นทั้งหมดออกจากหน้าต่างการจับแพ็กเก็ต

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

ในเอาต์พุต มองหารูปร่างของบทสนทนามากกว่าบรรทัดเดียว Access-Request แรกที่มี Identifier 3 ตามด้วย Access-Challenge ที่พา State แล้วจึงเป็น Access-Request ที่สองที่มี Identifier 4 ซึ่งกล่าวถึง State เดิมซ้ำและมีคำตอบของผู้ใช้ หากคำขอที่สองหายไป เกตเวย์ไม่เคยติดตามต่อเลย หากมาถึงโดยไม่มี State เซิร์ฟเวอร์จะจับคู่กับชาเลนจ์ที่ค้างอยู่ไม่ได้และมักจะปฏิเสธ

เมื่อแบ่งปันร่องรอย ให้ปิดบังข้อมูลรับรอง โทเคน และข้อมูลระบุตัวตนที่ไม่จำเป็น และเชื่อมโยงเหตุการณ์จากความพยายามครั้งเดียวแทนที่จะผสมการลองซ้ำจากหลายแท็บเบราว์เซอร์ เวลาประทับเป็นเพื่อนของคุณตรงนี้ ชาเลนจ์ที่มาถึงหลังจากไคลเอนต์ยอมแพ้จะดูเหมือนการปฏิเสธสำหรับผู้ใช้ และดูเหมือนคำตอบที่ช้าสำหรับบันทึก

สถานะสุดท้ายที่คุณต้องการคือบทสนทนาที่เสร็จสมบูรณ์และได้รับอนุญาต ตามด้วยการเข้าถึงบริการตามที่ตั้งใจ คำตอบที่มาจาก RADIUS server พิสูจน์ได้น้อยกว่านั้นมาก