Meshnet, Docker และสิทธิ์ที่อยู่ระหว่างนั้น

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

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

ติดตามปลายทางหลังการเผยแพร่

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

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

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

ตัดสินว่าสิทธิ์หนึ่งให้การเข้าถึงภายในมากน้อยเพียงใด

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

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

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

ทดสอบสิทธิ์ ไม่ใช่แค่ URL

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

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

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

เขียนข้อค้นพบด้วยถ้อยคำของระบบเอง

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

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