ชื่อ VPN ส่วนตัวใช้ไม่ได้? ตัวน่าสงสัยคือการป้องกัน DNS rebinding

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

การป้องกัน rebinding มีอยู่เพื่อหยุดกลอุบายหนึ่งอย่างโดยเฉพาะ ชื่อส่วนตัวที่ถูกเผยแพร่โดยเจตนาดูคล้ายกันมากพอที่การป้องกันจะทำงาน

อ่านคำตอบก่อนอ่านนโยบาย

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

อาการซ้อนทับกัน ดังนั้นรูปร่างของคำตอบจึงเป็นตัวตัดสินการวินิจฉัย NXDOMAIN คือเรกคอร์ดที่หายไป REFUSED คือกฎการเข้าถึง ที่อยู่สาธารณะสำหรับชื่อภายในคือข้อผิดพลาดของนโยบายหรือ split-DNS และที่อยู่ส่วนตัวที่ถูกต้องแต่ไคลเอนต์ใช้ไม่ได้เป็นปัญหาคนละเรื่องโดยสิ้นเชิง การเชื่อมต่อที่ถูกปฏิเสธหรือคำขอที่ค้างไม่ได้พิสูจน์อะไรด้วยตัวเอง ดังนั้นคำสั่งแรกในตั๋วลักษณะนี้ควรเป็นการค้นหาไม่ใช่การรีสตาร์ท จดคำตอบไว้ก่อนจะเปลี่ยนอะไร

การป้องกันหยุดอะไรจริง ๆ

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

dnsmasq บันทึกพฤติกรรมนั้นไว้อย่างชัดเจน พร้อมข้อยกเว้นรายโดเมน ในคู่มือของมันอธิบาย rebind-domain-ok ว่าเป็นวิธีระบุโดเมนที่อาจคืนที่อยู่เช่นนั้นได้อย่างชอบธรรม อ่านสิ่งนี้เป็นสัญญาณว่าการแก้ไขที่ตั้งใจคือการอนุญาตแบบจำกัด ไม่ใช่สวิตช์ทั้งระบบ

จำกัดข้อยกเว้นให้อยู่ในเนมสเปซ

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

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

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

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

ทดสอบทรัพยากรและการป้องกันอีกครั้ง

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

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

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

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