พื้นที่ผู้ดูแลระบบ SaaS หลัง VPN: ควรเชื่อถือที่อยู่ใด

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

สิ่งที่ต้นทางได้รับจริงหลังจากผ่านทันเนล

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

curl -s https://ifconfig.me
dig +short admin.example.com

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

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

เชื่อถือเฉพาะพร็อกซีที่เขียนที่อยู่ใหม่

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

ผูกเงื่อนไขกับทุกการดำเนินการที่ป้องกันไว้

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

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

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

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

ทดสอบการข้ามที่คุณเพิ่งปิด

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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