วิธีติดตามเส้นทางการเข้าถึงข้ามหลาย firewall

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

• firewall หลายตัว
• ชุดกฎและลำดับความสำคัญที่แตกต่างกัน
• โซนเครือข่ายและเส้นทางการ routing

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

ปัญหาหลัก: การเข้าถึงถูกกำหนดจากทั้งสภาพแวดล้อม

เครื่องมือบริหารจัดการ firewall แบบ native มักมีขอบเขตอยู่ที่อุปกรณ์เพียงตัวเดียว โดยแสดงเพียง:

• กฎ
• ล็อก
• สถานะการกำหนดค่า

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

Access path คืออะไร

Access path คือลำดับของการประเมินที่กำหนดว่าทราฟฟิกสามารถเดินทางจากต้นทางไปยังปลายทางได้หรือไม่ ประกอบด้วย:

• ระบบต้นทางและปลายทาง
• พอร์ตและโปรโตคอล
• ทุก firewall ทุกจุดควบคุม และอุปกรณ์ layer 3 ตลอดเส้นทาง
• กฎที่อนุญาตหรือปฏิเสธทราฟฟิกในแต่ละขั้นตอน

การติดตาม access path หมายถึงการระบุองค์ประกอบเหล่านี้ทั้งหมดและความสัมพันธ์ระหว่างกัน

อินพุตและเอาต์พุต

อินพุต

• ระบบต้นทาง
• ระบบปลายทาง
• พอร์ตและโปรโตคอล
• การกำหนดค่า firewall ทั่วทั้งสภาพแวดล้อม
• โทโพโลยีเครือข่ายและเส้นทางการ routing
• object group และการแมปแอดเดรส

เอาต์พุต

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

ขั้นตอนที่ 1: กำหนดการเชื่อมต่อให้ชัดเจน

เริ่มจากคำถามที่เจาะจง: App_Server สื่อสารกับ DB_Server บนพอร์ต 1433 ได้หรือไม่ หากไม่กำหนดการเชื่อมต่อให้ชัดเจน การติดตามเส้นทางก็จะคลุมเครือ

ขั้นตอนที่ 2: ระบุเส้นทางที่คาดหวัง

พิจารณาว่าทราฟฟิกควรไหลผ่านเครือข่ายอย่างไร ซึ่งรวมถึง:

• โซนหรือเครือข่ายต้นทาง
• เซกเมนต์ระหว่างทาง
• โซนหรือเครือข่ายปลายทาง

ในหลายสภาพแวดล้อมมีเส้นทางที่เป็นไปได้มากกว่าหนึ่งเส้นทาง จึงต้องเข้าใจโทโพโลยีก่อนจะประเมินกฎ

ขั้นตอนที่ 3: ประเมินจุดบังคับใช้นโยบายแต่ละจุด

ที่ firewall หรือจุดควบคุมแต่ละแห่ง: 1. ระบุกฎที่เกี่ยวข้อง 2. ประเมินลำดับและความสำคัญของกฎ 3. พิจารณาว่าทราฟฟิกถูกอนุญาตหรือถูกปฏิเสธ

ตัวอย่าง

Firewall A: อนุญาต App → DB (1433) Firewall B: ปฏิเสธ App → DB (1433) การเชื่อมต่อจึงถูกบล็อก เพราะทุกจุดบังคับใช้นโยบายต้องอนุญาตทราฟฟิกนั้น

ขั้นตอนที่ 4: ขยาย object group

กฎมักอ้างอิงถึง object group แทนที่จะเป็นระบบแต่ละระบบ และกลุ่มเหล่านี้อาจมีแอดเดรสอยู่หลายรายการ

ตัวอย่าง

อนุญาต App → DB_Group (1433) DB_Group อาจขยายออกเป็น: DB_Server Backup_DB Reporting_DB การติดตามเส้นทางจึงต้องประเมินสมาชิกที่ขยายออกมาทั้งหมด

ขั้นตอนที่ 5: ประเมินปฏิสัมพันธ์ระหว่างกฎ

กฎแต่ละข้อไม่ได้ทำงานแยกจากกัน ปัจจัยสำคัญได้แก่:

• ลำดับของกฎ
• เงื่อนไขที่ซ้อนทับกัน
• กฎแบบกว้างที่ไปลบล้างกฎที่เจาะจง

ตัวอย่าง

กฎข้อที่ 1: Allow App → Any (Any Port) กฎข้อที่ 2: Deny App → DB (1433) กฎ deny มีอยู่จริง แต่ไม่เคยถูกเรียกใช้งาน

ขั้นตอนที่ 6: พิจารณาเส้นทางสำรอง

แม้เส้นทางหนึ่งจะบล็อกทราฟฟิก แต่อีกเส้นทางหนึ่งอาจอนุญาตให้ผ่านได้

ตัวอย่าง

เส้นทางที่ 1: Firewall A ปฏิเสธ App → DB เส้นทางที่ 2: Firewall B อนุญาต App → DB หากเส้นทางการ routing เปิดให้ใช้เส้นทางที่ 2 การเชื่อมต่อก็จะสำเร็จ การ trace จึงต้องครอบคลุมทุกเส้นทางที่เป็นไปได้

ขั้นตอนที่ 7: สรุปผลลัพธ์สุดท้าย

หลังประเมิน:

• จุดบังคับใช้นโยบายทั้งหมด
• ปฏิสัมพันธ์ระหว่างกฎ
• การขยายของ object
• เส้นทางที่เป็นไปได้

คุณจะระบุได้ว่า:

• การเชื่อมต่อถูกอนุญาตหรือถูกบล็อก
• กฎข้อใดเป็นตัวกำหนดผลลัพธ์
• ควรปรับการควบคุมที่จุดใด

ตัวอย่าง: เหตุใดการเชื่อมต่อจึงได้รับอนุญาต

คำถาม App_Server เข้าถึง DB_Server บนพอร์ต 1433 ได้หรือไม่ สิ่งที่พบจากการตรวจสอบคอนฟิก Firewall A: Allow App → DB_Group (1433) Firewall B: ไม่มี deny ที่ระบุไว้ชัดเจน ลำดับกฎ: กฎ allow แบบกว้างมีผลเหนือกว่า ผลลัพธ์ที่เกิดขึ้นจริง App → DB (1433) App → Backup_DB (1433) การเชื่อมต่อได้รับอนุญาตเนื่องจากการขยาย object group และลำดับความสำคัญของกฎ

เหตุใดการ trace ด้วยมือจึงไม่เพียงพอ

การ trace ด้วยมือจะทำได้ยากเมื่อ:

• มีอุปกรณ์เกี่ยวข้องหลายตัว
• ชุดกฎมีขนาดใหญ่และซับซ้อน
• object group ขยายตัวออกเป็นจำนวนมาก

สิ่งนี้นำไปสู่:

• การวิเคราะห์ที่ไม่ครบถ้วน
• ข้อสันนิษฐานที่คลาดเคลื่อน
• การแก้ปัญหาที่ล่าช้า

การประเมินเส้นทางการเข้าถึงด้วย policy model

policy model ช่วยให้ประเมินการเข้าถึงได้อย่างเป็นระบบ โดยผสานสิ่งต่อไปนี้เข้าด้วยกัน:

• คอนฟิกของ firewall
• โทโพโลยีเครือข่าย
• การแปลงค่า object
• ตรรกะการประเมินกฎ

สิ่งนี้ช่วยให้ทีมงานสามารถ:

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

บทบาทของ FireMon

FireMon ช่วยให้ประเมินเส้นทางการเข้าถึงได้ด้วยการ:

• สร้าง policy model ที่เป็นมาตรฐานเดียวกันครอบคลุมทุก firewall
• นำโทโพโลยีและ routing มาร่วมพิจารณา
• ประเมินการเชื่อมต่อระหว่างระบบ
• ระบุกฎที่ควบคุมการเข้าถึงนั้น

สิ่งนี้ให้แนวทางที่สอดคล้องกันในการตอบคำถามว่า เหตุใดการเชื่อมต่อนี้จึงถูกอนุญาตหรือถูกบล็อก

ประเด็นสำคัญ

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

บทสรุป

ในการแก้ปัญหาการเข้าถึง เป้าหมายไม่ใช่การค้นหา rule แต่คือการใช้ทั้งจุดบังคับใช้นโยบายและ network topology เพื่อให้เห็นภาพการเชื่อมต่อแบบ end-to-end ซึ่งช่วยให้อธิบายได้อย่างชัดเจนว่าเหตุใดทราฟฟิกจึงได้รับอนุญาตหรือถูกปฏิเสธ