เชื่อม RADIUS เข้ากับ OpenVPN: ปลั๊กอินหรือฮุกสคริปต์?

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

ความเชื่อผิด: ปลั๊กอินคือเส้นทางที่ได้รับการสนับสนุน

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

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

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

ปลั๊กอินผูกอะไรไว้ด้วยกัน

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

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

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

ฮุกสคริปต์ไว้วางใจอะไรจริง ๆ

ฮุกตั้งค่าด้วย auth-user-pass-verify และกลไกการส่งมอบ คือตัวแปรสภาพแวดล้อมหรือไฟล์ชั่วคราว ในรูปแบบตัวแปรสภาพแวดล้อม OpenVPN ต้องการ script-security 3 ซึ่งเป็นระดับที่เอกสารระบุว่าอนุญาตให้เปิดเผยรหัสผ่านแก่สคริปต์ ระดับนั้นเป็นการทำให้ค่าดีฟอลต์อ่อนลงโดยเจตนา และควรถือเป็นการอนุญาตพร้อมเหตุผลแนบท้าย

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

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

รหัสออกกำหนดว่าจะล้มเหลวแบบเปิดหรือไม่

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

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

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

คุณเสียอะไรเมื่อใบรับรองหายไป

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

รักษาการป้องกันช่องทางควบคุมไว้ เพื่อให้คู่ที่ไม่ผ่านการยืนยันตัวตนไม่สามารถตรวจหรือท่วมการจับมือได้ และใช้ username-as-common-name เมื่อการตั้งค่าต่อผู้ใช้ขึ้นกับชื่อสามัญ เกตเวย์ที่จัดการมักแก้ต่างออกไป โดยสิ้นสุดการยืนยันตัวตนด้วยใบรับรองที่เกตเวย์ที่พูด EAP-TLS กับ RADIUS และในกรณีนั้นคำสั่งเซิร์ฟเวอร์เหล่านี้ไม่ใช้เลย คัดลอกโมเดลที่แพลตฟอร์มของคุณเองจัดทำเอกสารไว้ ไม่ใช่ของผลิตภัณฑ์ข้างเคียง คำสั่งที่สำคัญต่างกันมากพอที่การผสมกันจะให้การตั้งค่าที่แยกวิเคราะห์ได้แล้วไม่ยืนยันตัวตนใครเลย