การตรวจสอบการเข้าสู่ระบบสองครั้งไม่ใช่สองปัจจัย: VPN และ RADIUS

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

สิ่งที่แบ็กเอนด์ที่สองพิสูจน์ได้จริง

การค้นหาบัญชีท้องถิ่นพิสูจน์ว่ามีชื่ออยู่ในฐานข้อมูลและมีรหัสผ่านตรงกับชื่อนั้น การแลกเปลี่ยน RADIUS พิสูจน์ว่าเซิร์ฟเวอร์ RADIUS ส่งคืน Access-Accept สำหรับแอตทริบิวต์ที่ได้รับ ไม่มีข้อความใดกล่าวถึงประเภทของปัจจัย เพราะ ทั้งสองตรวจสอบความรู้ และ แนวปฏิบัติด้านอัตลักษณ์ดิจิทัลของ NIST นับประเภทปัจจัยที่แตกต่างกันและตัวยืนยันตัวตนของแต่ละประเภท ไม่ใช่เซิร์ฟเวอร์หรือข้อความแจ้ง

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

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

AND, OR และสำรองเป็นผลิตภัณฑ์ที่ต่างกัน

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

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

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

การตรวจสอบสองชั้นของ OpenVPN เป็นกรณีรูปธรรม

OpenVPN ชุมชน 2.6 กำหนดให้ต้องมีทั้งใบรับรองไคลเอนต์และสคริปต์ auth-user-pass-verify ที่กำหนดค่าไว้เมื่อทั้งสองเปิดใช้งาน นั่นคือ AND ที่บันทึกไว้ระหว่างการตรวจสอบใบรับรองกับสคริปต์ข้อมูลรับรอง และเป็นการตรวจสอบสองครั้งจริง แต่มันยังไม่ใช่สองประเภทปัจจัยโดยอัตโนมัติ เนื่องจากสคริปต์อาจตรวจสอบเฉพาะรหัสผ่าน

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

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

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

ตรวจสอบการผสมกันบนเกตเวย์ของคุณ

อ่านการกำหนดค่าก่อนเชื่อถือสรุปของคอนโซล บรรทัดที่ตัดสินนโยบายคือโหมดใบรับรอง สคริปต์ข้อมูลรับรอง และลำดับปลั๊กอิน

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

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

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

เขียนความต้องการเป็นกรณีเชิงลบ

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

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

รันการปฏิเสธทั้งสี่ซ้ำหลังการเปลี่ยนแปลงปลั๊กอินหรือเฟิร์มแวร์ใด ๆ พวกมันมีต้นทุนต่ำ และนโยบายที่มันปกป้องคือส่วนที่ผู้โจมตีตรวจสอบก่อน