สำหรับท่านใดที่ใช้งาน Cisco Secure Firewall Threat Defense (FTD) ร่วมกับ Firewall Management Center (FMC) คงคุ้นเคยกับการเขียน Rule บน Access Control Policy (ACP) เป็นอย่างดี แต่รู้หรือไม่ว่าก่อนที่ทราฟฟิกจะเดินทางไปถึง ACP ไฟร์วอลล์ยังมีอีกหนึ่งชั้นการตรวจสอบที่ทำงาน เร็วและเบากว่า นั่นคือ Prefilter Policy
ในบทความนี้จะพาไปรู้จักว่า Prefilter Policy คืออะไร ทำงานอย่างไร ต่างจาก Access Control Policy ตรงไหน และลงมือตั้งค่าจริงทีละขั้นตอนบน FMC พร้อมทดสอบผลลัพธ์ให้เห็นภาพชัด ๆ ผ่านการ Fastpath ทราฟฟิกที่ถูกบล็อกโดย ACP ให้กลับมาใช้งานได้
Prefilter Policy คืออะไร
Prefilter Policy คือชั้นการกรองทราฟฟิก (Filtering) ชั้นแรกสุด ของกระบวนการ Access Control บน FTD โดยจะทำงานอยู่ในเอนจิน LINA (ส่วนของไฟร์วอลล์ที่สืบทอดมาจาก Cisco ASA) ก่อน ที่ทราฟฟิกจะถูกส่งต่อเข้าสู่กระบวนการตรวจสอบเชิงลึกด้วย Snort (เช่น Security Intelligence, Intrusion, Application Detection ใน Access Control Policy)
เพราะทำงานที่ระดับต้นทางและใช้เพียงคุณลักษณะพื้นฐานของแพ็กเก็ต (Outer header) ในการตัดสินใจ Prefilter จึงประมวลผลได้รวดเร็ว เหมาะกับการจัดการทราฟฟิกปริมาณมากที่ไว้ใจได้ หรือ ต้องการตัดทิ้งตั้งแต่ต้นทาง โดยไม่ต้องเปลืองทรัพยากรของ Snort
ลำดับการทำงานของ Packet บน FTD :
Prefilter Policy → Decryption → Security Intelligence → Identity → Access Control Policy (Snort)
หมายเหตุ: ทุก Access Control Policy จะมี Prefilter Policy ผูกอยู่เสมอ โดยค่าเริ่มต้นคือ Default Prefilter Policy ซึ่งไม่สามารถเพิ่ม Rule ได้ หากต้องการเขียน Rule เอง จะต้องสร้าง Prefilter Policy ขึ้นมาใหม่แล้วนำไปผูกกับ ACP
ประเภทของ Rule ใน Prefilter Policy
ภายใน Prefilter Policy เราสามารถสร้าง Rule ได้ 2 ประเภท ซึ่งมีวัตถุประสงค์ต่างกัน ดังนี้
| ประเภท Rule | คำอธิบาย |
| Prefilter Rule | ใช้กรองทราฟฟิกทั่วไปจากคุณลักษณะพื้นฐาน เช่น Source/Destination Interface (Zone), Source/Destination Network, VLAN Tag และ Port เป็น Rule ที่ใช้บ่อยที่สุดในการทำงานทั่วไป |
| Tunnel Rule | ใช้จัดการทราฟฟิกที่ถูกห่อหุ้ม (Encapsulated) แบบ plaintext เช่น GRE, IP-in-IP, IPv6-in-IP และ Teredo โดยพิจารณาจาก Outer Header และสามารถกำหนด “Tunnel Zone” เพื่อให้ ACP นำ Inner traffic ไปกรองต่อได้ |
Action ทั้ง 3 แบบของ Prefilter Rule
หัวใจสำคัญของ Prefilter Rule คือการเลือก Action ว่าจะให้ทำอะไรกับทราฟฟิกที่ตรงเงื่อนไข ซึ่งมีให้เลือก 3 แบบ:
| Action | ความหมายและการนำไปใช้ |
| Analyze | ส่งทราฟฟิกต่อไปให้ Access Control Policy ตรวจสอบตามปกติ (เป็นค่าเริ่มต้น) เหมาะกับทราฟฟิกที่ยังต้องการให้ Snort ตรวจสอบเชิงลึก |
| Block | ตัดทิ้ง (Drop) ทราฟฟิกตั้งแต่ต้นทางทันที โดยไม่ต้องส่งต่อให้ตรวจสอบต่อ ช่วยลดภาระของไฟร์วอลล์ |
| Fastpath | ปล่อยผ่านทราฟฟิกโดยข้ามการตรวจสอบทั้งหมด ทั้ง Access Control, QoS และ Snort ทราฟฟิกจะถูกจัดการที่ LINA โดยตรง ทำให้เร็วและลดภาระมาก เหมาะกับทราฟฟิกที่ไว้ใจได้หรือว่าเรา Trust และมีปริมาณสูง เช่น การสำรองข้อมูลหรือการโอนไฟล์ขนาดใหญ่ |
ตัวอย่างและขั้นตอนการตั้งค่า
เพื่อให้เห็นภาพการทำงานของ Prefilter Policy อย่างชัดเจน บทความนี้จะจำลองสถานการณ์ดังนี้:
- Zone: Inside-Zone (วง 172.16.100.0/24) และ Outside-Zone (ออกอินเทอร์เน็ต)
- เงื่อนไข: บน Access Control Policy มี Rule ที่ตั้งค่าให้ Block ทราฟฟิกจาก Inside ออก Outside ทำให้เครื่องภายใน ping ออกอินเทอร์เน็ต (8.8.8.8) ไม่ได้
- เป้าหมาย: สร้าง Prefilter Rule แบบ Fastpath เพื่อให้ทราฟฟิกจากวง 172.16.100.0/24 ไป Outside ข้ามการบล็อกของ ACP และกลับมา ping ได้ตามปกติ
ขั้นตอนที่ 1 : สร้าง Prefilter Policy
เข้าสู่ FMC แล้วไปที่เมนู Policies > Access Control > Prefilter จากนั้นคลิกปุ่ม New Policy ที่มุมขวาบนเพื่อสร้าง Prefilter Policy ใหม่
ตั้งชื่อ Policy ในช่อง Name จะใส่ Description หรือไม่ก็ได้ แล้วคลิก Save
ขั้นตอนที่ 2 : เพิ่ม Prefilter Rule
หลังจากสร้าง Policy ระบบจะเข้าสู่หน้า Rule Editor คลิกปุ่ม + Add Prefilter Rule เพื่อเริ่มสร้าง Rule ใหม่
2.1 ตั้งชื่อ Rule และเลือก Action
ในช่อง Name ตั้งชื่อ Rule และติ๊ก Enabled ให้เรียบร้อย จากนั้นที่ช่อง Action จะเห็นตัวเลือกทั้ง 3 แบบคือ Analyze, Block และ Fastpath ให้เลือกตามวัตถุประสงค์ ในที่นี่จะเลือกเป็น Fastpath ที่แท็บ Interface Objects เลือก Zone ต้นทางและปลายทาง โดยเลือก Inside-Zone แล้วกด Add to Source และเลือก Outside-Zone แล้วกด Add to Destination
2.2 กำหนด Networks
ไปที่แท็บ Networks เลือก Object ที่ต้องการมาเป็น Source Network ในแล็บนี้เลือก IPv4-Private-172.16.0.0-12 เป็น Source ส่วน Destination ปล่อยเป็น any หมายถึงปลายทางใดก็ได้
2.3 กำหนด VLAN Tags และ Ports (ถ้าต้องการ)
2.4 ตั้งค่า Logging
ที่แท็บ Logging แนะนำให้ติ๊ก Log at End of Connection และส่ง Connection Event ไปยัง Firewall Management Center เพื่อให้สามารถตรวจสอบเหตุการณ์ย้อนหลังได้ในภายหลัง เสร็จแล้วกด Add หรือ Save เพื่อบันทึก Rule
2.5 ตรวจสอบ Rule และบันทึก Policy
จะเห็น Rule Test-Rule ปรากฏในตาราง โดยมี Rule Type = Prefilter, Source = Inside-Zone, Destination = Outside-Zone, Source Network = IPv4-Private-172.16.x และ Action = Fastpath จากนั้นคลิก Save ที่มุมขวาบนเพื่อบันทึก Prefilter Policy
ขั้นตอนที่ 3 : ผูก Prefilter Policy เข้ากับ Access Control Policy
Prefilter Policy จะยังไม่มีผลจนกว่าจะถูกนำไปผูกกับ Access Control Policy ให้ไปที่ Policies > Access Control แล้วเปิด ACP ที่ใช้งานอยู่ (ในแล็บนี้คือ Default Policy)
ที่แถบขั้นตอนด้านบน คลิกที่ Prefilter Rules จะมีกล่องให้เลือก Prefilter Policy ให้เปลี่ยนจาก Default Prefilter Policy เป็น Prefilter-Policy ที่เราสร้างไว้
คลิก Apply เพื่อยืนยันการผูก Policy จากนั้นสังเกตว่าใน ACP มี Rule ALLOW_Inside_to_Outside ที่ถูกตั้งค่า Action เป็น Block อยู่ (ทำให้ Inside ออก Outside ไม่ได้) แล้วคลิก Save ที่มุมขวาบน
ขั้นตอนที่ 4 : Deploy การตั้งค่าไปยัง FTD
ทุกการเปลี่ยนแปลงบน FMC จะยังไม่มีผลจนกว่าจะ Deploy ให้คลิกปุ่ม Deploy ที่มุมขวาบน เลือกอุปกรณ์ปลายทาง
ทดสอบผลลัพธ์
ทดสอบจากเครื่องภายใน (172.16.100.100) ด้วยคำสั่ง ping 8.8.8.8 จะพบว่าได้ผลลัพธ์ Request timed out เนื่องจากทราฟฟิก Inside → Outside ถูก Rule บน Access Control Policy บล็อกไว้
หลังใช้งาน Prefilter Fastpath (ทราฟฟิกวิ่งผ่านได้)
เมื่อ Prefilter Rule แบบ Fastpath ถูก Deploy เรียบร้อย ให้ลอง ping 8.8.8.8 อีกครั้ง คราวนี้จะได้รับ Reply from 8.8.8.8 กลับมาเป็นปกติ (0% loss) เพราะทราฟฟิกจากวง 172.16.0.0/12 ถูก Fastpath ให้ข้ามการตรวจสอบและการบล็อกของ ACP ไปเรียบร้อย
ตรวจสอบ Log ใน Unified Events
เพื่อยืนยันการทำงาน ให้ไปที่ Analysis > Unified Events จะเห็นรายการ Connection ที่มี Action = Fastpath และเมื่อคลิกดูรายละเอียด (Event Details) จะพบว่าฟิลด์ Prefilter Policy = Prefilter-Policy และ Tunnel/Prefilter Rule = Test-Rule ตรงกับ Rule ที่เราสร้างไว้ ยืนยันว่าทราฟฟิกวิ่งผ่าน Prefilter Rule จริง
อ้างอิง: Cisco Security Cloud Control: Secure Firewall Threat Defense Management – Prefilter Policies
