ALB ภายในที่มีชื่อ DNS สาธารณะ: เปิดเผยจริงหรือไม่

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

ขั้นแรก: อ่านสคีมา ไม่ใช่ IP

ฟิลด์สคีมาคือคำประกาศของโหลดบาลานเซอร์เองเกี่ยวกับขอบเขตของมัน aws elbv2 describe-load-balancers --names app-internal คืนค่า Scheme ที่มีค่า internal หรือ internet-facing พร้อมชนิดที่อยู่สำหรับ IPv4 หรือ dual stack โหลดบาลานเซอร์ที่หันสู่อินเทอร์เน็ตยังส่งต่อไปยังเป้าหมายส่วนตัวได้ ดังนั้นการเห็นที่อยู่แบ็กเอนด์ส่วนตัวไม่ได้พิสูจน์อะไรเกี่ยวกับส่วนหน้า

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

ขั้นที่สอง: ดูว่าชื่อ resolve ไปที่ใด

สอบถามจากนอก VPC ด้วย dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com และสังเกตว่าคำตอบอยู่ใน 10.0.0.0/8, 172.16.0.0/12 หรือ 192.168.0.0/16 คำตอบส่วนตัวจากรีโซลเวอร์สาธารณะเป็นพฤติกรรมที่คาดหวังสำหรับชื่อโหลดบาลานเซอร์ภายใน ไม่ใช่หลักฐานว่าที่อยู่สามารถกำหนดเส้นทางจากอินเทอร์เน็ตได้

resolve ชื่อเดียวกันจากใน VPC แล้วเปรียบเทียบ ถ้าสองคำตอบต่างกัน คุณกำลังเห็นการตั้งชื่อแบบ split-horizon และความต่างนั้นเป็นรายละเอียดการออกแบบ ไม่ใช่การรั่วไหล

ขั้นที่สาม: ระบุเส้นทางที่เข้าถึงมันได้

ที่อยู่ส่วนตัวเข้าถึงได้จากทุกที่ที่มีเส้นทางและกฎความปลอดภัย ระบุอย่างตั้งใจ: VPN ระหว่างไซต์, VPN ไคลเอนต์, VPC peering, การเชื่อมต่อ transit gateway, Direct Connect และพร็อกซีหรือ bastion ใด ๆ ใน VPC หนึ่งในนั้นคือเส้นทางที่ตั้งใจ และที่เหลือคือสิ่งที่ผู้โจมตีจะมองหา

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

ขั้นที่สี่: ทดสอบ listener และแอปพลิเคชันแยกกัน

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

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

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

ขั้นที่ห้า: ตัดสินว่าชื่อเองสำคัญหรือไม่

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

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

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