NFS export ที่ผูกกับที่อยู่ VPN: สิ่งที่มันไม่ได้พิสูจน์
กฎการ export ตรวจสอบว่าแพ็กเก็ตมาจากไหน AUTH_SYS อ้าง UID ภายในเครื่อง และ Kerberos ยืนยันตัวผู้ใช้ ตัดสินใจว่าบริการไฟล์ของคุณต้องการสิ่งใด
โฮสต์ทำการ export ไดเรกทอรีไปยังที่อยู่ VPN การเมานต์สำเร็จ และการออกแบบก็ถูกบันทึกว่าได้รับการยืนยันตัวตน สิ่งที่กฎนี้จำกัดจริง ๆ คือแพ็กเก็ตดูเหมือนมาจากที่ใด การที่ผู้สั่งการทำงานกับไฟล์จะเป็นคนเดียวกับที่อ้างว่าตนเป็นหรือไม่นั้นขึ้นอยู่กับโพรไฟล์ความปลอดภัยของ NFS และในการ export ลักษณะนี้ส่วนใหญ่ไม่มีใครเปลี่ยนจากค่าเริ่มต้น
อัตลักษณ์สามอย่างสามารถปรากฏในคำขอเดียว
เพื่อน VPN ถืออัตลักษณ์ที่ลงทะเบียนไว้ เช่น ใบรับรองไคลเอนต์หรือคีย์ของเพื่อน แพ็กเก็ต IP ภายในถือที่อยู่ต้นทาง การทำงานกับไฟล์ถือข้อมูลรับรองผู้ใช้ที่กลไก NFS ของมันจัดหาให้ การออกแบบที่ถือว่าที่อยู่เป็นตัวแทนของทั้งสามอย่างนั้นได้ละเลยสมมติส่วนที่ต้องตรวจสอบไปโดยปริยาย
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
การเขียนสามบรรทัดนั้นคือแบบฝึกหัดทั้งหมด การถกเถียงส่วนใหญ่ว่าการ export ปลอดภัยหรือไม่จะพังทลายลงเมื่อชัดเจนว่าการควบคุมใดอยู่ในบรรทัดใด
ความเป็นเจ้าของที่อยู่เป็นรายละเอียดของการนำไปใช้
เกตเวย์สามารถกำหนดที่อยู่ทันเนลให้เพื่อนที่ได้รับการยอมรับ หรืออนุญาตซับเน็ตที่กำหนดเส้นทางให้กับมัน การที่การนำไปใช้จะปฏิเสธแพ็กเก็ตที่ต้นทางภายในเป็นของไคลเอนต์อื่นหรือไม่นั้นเป็นคุณสมบัติของการนำไปใช้นั้น และควรค่าแก่การตรวจสอบมากกว่าการสันนิษฐาน
โค้ดเซิร์ฟเวอร์ในพื้นที่ผู้ใช้ของ Community แบบดั้งเดิม OpenVPN ตัวอย่างเช่น สามารถปฏิเสธต้นทางที่เชื่อมโยงกับไคลเอนต์อื่นก่อนที่แพ็กเก็ตจะถูกส่งผ่านอุปกรณ์ TUN นั่นคือการตรวจสอบความเป็นเจ้าของที่อยู่ที่มีคุณค่าจริง และยังคงไม่ใช่การยืนยันตัวผู้ใช้ NFS เพราะไม่บอกอะไรเลยว่าบัญชีใดเป็นผู้ดำเนินการ
การแปลต้นทางกัดกร่อนแม้กระทั่งสิ่งนั้น เกตเวย์ NAT สามารถแสดงไคลเอนต์ทุกคนเป็นที่อยู่เดียว และเมื่อนั้นกฎการ export ก็ไม่สามารถแยกคนที่อยู่เบื้องหลังได้ ความแม่นยำที่ดูเหมือนมีของกฎก็กลายเป็นเรื่องแต่งที่แผนภาพค้ำไว้ หากการ export มีความสำคัญ จงเก็บการกำหนดที่อยู่ให้ชัดเจนแทนที่จะปล่อยให้ผู้แปลตัดสินว่าใครนับเป็นใคร
อ่านโพรไฟล์ความปลอดภัยก่อนที่จะเชื่อถือการ export
แนวทาง NFS ของ Red Hat แยก sec=sys ซึ่งใช้ UNIX UID และ GID ภายในเครื่องผ่าน AUTH_SYS ออกจากโหมด Kerberos krb5 เพิ่มการยืนยันตัวผู้ใช้ krb5i เพิ่มการป้องกันความสมบูรณ์ และ krb5p เพิ่มการป้องกันความเป็นส่วนตัวของการรับส่งข้อมูล
ข้อมูลรับรอง AUTH_SYS มีฟิลด์เช่น UID ของผู้เรียกและรหัสกลุ่ม และ RFC 5531 เตือนอย่างชัดเจนว่าโพรไฟล์นี้ไม่ได้ให้ความปลอดภัยในตัวเองและขึ้นอยู่กับการป้องกันจากภายนอก การรันภายใน VPN ให้การป้องกันสำหรับการขนส่งและไม่เปลี่ยนอะไรในข้ออ้างภายในแพ็กเก็ต
exportfs -v
showmount -e nfs.example.internalอ่านโพรไฟล์ในผลลัพธ์นั้นก่อนอ่านรายการไคลเอนต์ การ export ที่ดูเหมือนถูกจำกัดอาจถูกจำกัดด้วยที่อยู่เท่านั้น ขณะที่ผู้เรียกแต่ละรายยังคงอ้าง UID ใดก็ได้ตามต้องการ
เลือกแบบจำลอง แล้วจึงรักษาสิทธิ์ไว้
เลือกแบบจำลองการยืนยันตัวตนของบริการไฟล์ที่เหมาะกับไคลเอนต์ที่คุณดูแลจริง ๆ Kerberos ต้องมีอัตลักษณ์และการติดตั้งบริการรองรับ ดังนั้นการเปลี่ยนตัวเลือกการเมานต์เพียงข้อเดียวจึงไม่ใช่การย้ายระบบ และจะล้มเหลวจนกว่าจะมีโดเมน Kerberos หลัก และไฟล์ keytab
ภายใต้แบบจำลองใดก็ตาม จงรักษาสิทธิ์การ export และการอนุญาตของระบบไฟล์ที่จำกัดสิ่งที่หลักที่ได้รับการยืนยันแล้วทำได้ การยืนยันตัวตนบอกคุณว่าใครถาม การอนุญาตตัดสินว่าคำตอบควรเป็นใช่หรือไม่ การรวมสองสิ่งนี้ไว้ในการตั้งค่าเดียวคือวิธีที่การย้ายระบบลงเอยด้วยการให้สิทธิ์มากกว่าที่การกำหนดค่าเดิมให้
ใช้กฎที่อยู่ให้ตรงกับวัตถุประสงค์จริง
การจำกัดบริการให้อยู่ในเส้นทางและแหล่งที่ได้รับอนุมัติยังคงคุ้มค่า รวมถึงนโยบายอินพุตของโฮสต์เมื่อปลายทาง VPN และเซิร์ฟเวอร์ NFS ใช้เครื่องเดียวกัน กฎที่ส่งต่อทราฟฟิกไม่ได้ควบคุมคำขอที่มุ่งไปยัง บริการที่ทำงานในเครื่องเดียวกัน ช่องว่างนี้อธิบายการ export จำนวนมากอย่างน่าประหลาดใจที่ควรเป็นส่วนตัว ตรวจสอบนโยบายอินพุตภายในอย่างชัดเจนแทนที่จะสันนิษฐานว่ากฎของทันเนลครอบคลุมมัน
ตรวจสอบว่าอินเทอร์เฟซอื่นหรือเกตเวย์ที่แปลต้นทางไม่สามารถทำให้เป็นไปตามกฎได้โดยไม่คาดคิด และถือว่านั่นเป็นเหตุผลในการพิสูจน์ที่มา ไม่ใช่ข้ออ้างว่าการปลอมที่อยู่รับประกันการเมานต์ที่ใช้งานได้
รันกรณีทดสอบการยอมรับสามกรณีแทนหนึ่งกรณี เริ่มด้วยไคลเอนต์ที่ได้รับอนุมัติทำหน้าที่เป็นผู้ใช้ที่ได้รับอนุมัติ จากนั้นทำซ้ำจากเพื่อนที่ไม่เคยได้รับอนุมัติ แล้วลองสิ่งที่ผู้ใช้ที่ได้รับอนุมัติยังไม่ได้รับอนุญาตให้ทำ หลังจากนั้นถามว่าเกิดอะไรขึ้นหากไคลเอนต์ที่ได้รับอนุญาตถูกบุกรุก เพราะการยืนยันตัวตนของการขนส่งไม่ได้ทำให้ทุกโปรเซสบนเครื่องนั้นน่าเชื่อถือ ใบรับรองที่ถูกขโมยกับบัญชีภายในที่อยากรู้อยากเห็นเป็นปัญหาที่ต่างกันด้วยการควบคุมที่ต่างกัน