การเสริมความปลอดภัยของ VPN บน Windows: แก้การยืนยันตัวตนก่อนอุโมงค์

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

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

สามหน้าที่ กล่องโต้ตอบเดียว

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

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

แยกทั้งสามไว้ในบันทึกของคุณก่อนแตะการตั้งค่าใด ๆ แล้วแก้ไขจากจุดอ่อนที่สุดขึ้นไป

ทำไม MS-CHAPv2 จึงไม่ผ่านการทดสอบการเล่นซ้ำ

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

คุณสมบัติที่คุณต้องการคือข้อมูลรับรองที่ไม่สามารถเล่นซ้ำได้ EAP-TLS พร้อมใบรับรองไคลเอนต์ให้แต่ละอุปกรณ์มีอัตลักษณ์ของตัวเองและอนุญาตให้คุณเพิกถอนอุปกรณ์เพียงเครื่องเดียว

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

คีย์ที่แชร์ล่วงหน้ายืนยันคู่ ไม่ใช่บุคคล

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

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

การอนุญาตเป็นของ Network Policy Server

NPS บน Windows ตัดสินว่าใครเชื่อมต่อได้ และทำเช่นนั้นหลังการยืนยันตัวตนสำเร็จแล้ว การแยกนั้นเป็นการควบคุมเสริมความปลอดภัยที่มีประโยชน์ที่สุดในผลิตภัณฑ์ และการติดตั้งจำนวนมากปล่อยไว้ไม่แตะต้อง

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

การบัญชี RADIUS ยังให้บันทึกหนึ่งรายการว่าใครเชื่อมต่อและเมื่อใด บันทึกนั้นคือความแตกต่างระหว่างการทบทวนเหตุการณ์กับการเดา และมีอยู่ไม่ว่าใครจะอ่านมันหรือไม่

จำกัดสิ่งที่การเข้าสู่ระบบที่สำเร็จสามารถเข้าถึง

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

ไม่มีตัวเลือกใดเป็นค่าเริ่มต้นด้านความปลอดภัย ทั้งสองต้องเขียนไว้ข้างโปรไฟล์ไฟร์วอลล์ที่มันสมมติ

ตรวจสอบเส้นทางความล้มเหลว

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

จากนั้นยืนยันว่าพอร์ตใดถูกเผยแพร่และเพราะเหตุใด PPTP ต้องใช้ TCP 1723 และ GRE ในฐานะโปรโตคอล IP ไม่ใช่พอร์ต IKEv2 ต้องใช้ UDP 500 และ 4500 และ L2TP ต้องใช้ UDP 1701 พร้อม IPsec การเปิดอินเทอร์เฟซการจัดการเพื่อให้ไคลเอนต์เชื่อมต่อไม่ใช่การซ่อม แต่เป็นเหตุการณ์ที่สองที่รอการค้นพบ

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