RouterOS OpenVPN และ NPS: ตั้ง user-auth-method ไม่ใช่ auth

บน RouterOS นั้น auth เลือกไดเจสต์ของอุโมงค์ ขณะที่ user-auth-method ตัดสินใจว่าคำขอ RADIUS ถูกตรวจสอบอย่างไร จัดให้ตัวหลังสอดคล้องกับนโยบาย NPS

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

ขั้นตอนที่ 1: อ่านการตั้งค่าทั้งสองก่อนเปลี่ยนอย่างใดอย่างหนึ่ง

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

/interface ovpn-server server print
/interface ovpn-server server export

ฟิลด์ auth แสดงรายการไดเจสต์เช่น sha1 และ sha256 และควบคุม HMAC ที่พิสูจน์ตัวตนแพ็กเก็ตอุโมงค์ ฟิลด์ user-auth-method เลือก pap หรือ mschap2 และตัดสินใจว่าเราเตอร์นำเสนอข้อมูลรับรองของผู้ใช้ต่อ RADIUS อย่างไร การเปลี่ยนไดเจสต์ไม่สามารถเปลี่ยนพฤติกรรมที่สองได้ ดังนั้นการปฏิเสธเดิมจึงอยู่รอดทุกการปรับครั้งแรก

หยุดตรงนี้หากรีลีสของคุณไม่เปิดเผย user-auth-method เลย บิลด์ RouterOS เก่าอาจไม่เสนอสิ่งนี้บนเซิร์ฟเวอร์ OpenVPN และการแก้ไขเป็นของรีลีสที่คุณรองรับได้ ไม่ใช่คำสั่งที่คัดลอกจากรุ่นใหม่กว่า

ขั้นตอนที่ 2: หานโยบายที่ปฏิเสธการล็อกอินจริง

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

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

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

หยุดตรงนี้หากคำขอไม่เคยไปถึง NPS นั่นคือปัญหาความลับร่วม ที่อยู่ไคลเอนต์ หรือ UDP 1812 และการเปลี่ยนวิธีการพิสูจน์ตัวตนจะไม่แก้ไข

ขั้นตอนที่ 3: เปลี่ยนวิธีเดียว ทั้งสองด้าน

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

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

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

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

ขั้นตอนที่ 4: ทดสอบการล็อกอินสามครั้งและสิทธิ์หนึ่งอย่าง

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

/log print where topics~"ovpn"
/radius monitor 0

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

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

บทความที่เกี่ยวข้อง