บทความโดย: ดร. วิรินทร์ เมฆประดิษฐสิน
หากจะกล่าวว่า FortiGate คือป้อมปราการ Firewall Policy ก็คือ “กฎมณเฑียรบาล” ที่กำหนดชะตากรรมของทุกสรรพสิ่งในอาณาจักรเครือข่าย ในบทความนี้เราจะไม่คุยกันแค่เรื่องการกดปุ่มเมนู แต่เราจะเจาะลึกไปถึง “สมอง” ของ FortiOS ว่ามันคิดอย่างไรเมื่อได้รับ Packet ข้อมูล และทำอย่างไรเราจึงจะออกแบบนโยบายที่ทั้งปลอดภัยสูงสุดและทำงานได้รวดเร็วที่สุดในเวลาเดียวกัน
1. เจาะลึกกลไก Packet Flow: Packet เดินทางผ่าน Policy อย่างไร?
“ถ้าคุณไม่รู้ว่า Packet ไหลอย่างไร คุณก็ไม่มีวันแก้ปัญหา Network ได้” เมื่อข้อมูลวิ่งเข้าสู่ Interface ของ FortiGate มันจะผ่านกระบวนการที่เรียกว่า Ingress, Security Inspection, และ Egress ตามลำดับดังนี้
1.1 การตรวจสอบเบื้องต้น (Sanity Check)
ก่อนจะถึงระดับ Policy เครื่องจะตรวจก่อนว่า Packet นั้นผิดปกติหรือไม่ (เช่น IP ผิดรูปแบบ) จากนั้นจะทำ Route Lookup เพื่อดูว่าปลายทางจะไปทางไหน หากไม่มีเส้นทางไป (No Route) Packet จะถูก Drop ทันทีโดยไม่ต้องอ่าน Policy
1.2 Policy Lookup: การค้นหา “คู่ที่ใช่”
FortiGate ใช้กลไก First-Match Logic อย่างเคร่งครัด โดยไล่เรียงจาก Policy ID 1 ลงไปถึงข้อสุดท้าย (Implicit Deny) โดยมีเงื่อนไขการแมตช์ 4 ส่วน (Tuple) ที่ต้อง “ผ่านทั้งหมด”:
- Interfaces: ขาเข้าและขาออกต้องตรงกัน
- Address: IP ต้นทางและปลายทางต้องอยู่ในขอบเขตที่กำหนด
- Service: พอร์ตและโปรโตคอลต้องตรงตามที่ระบุ
- Schedule: เวลาที่ร้องขอต้องอยู่ในช่วงเวลาที่อนุญาต
2. ยุทธศาสตร์การจัดลำดับ Policy (Policy Orchestration)
การจัดลำดับ Policy ไม่ใช่เรื่องของความสวยงาม แต่เป็นเรื่องของ “ความปลอดภัยและประสิทธิภาพ” (Security & Performance)
2.1 กฎ Specific vs General (แคบไปกว้าง)
กฎที่ระบุเจาะจงรายเครื่อง หรือรายแอปพลิเคชันที่วิกฤต ต้องอยู่ “ด้านบน” เสมอ เพื่อให้เครื่องประมวลผลได้ทันทีโดยไม่ต้องไล่ลงไปด้านล่าง ส่วนกฎกว้างๆ เช่น “Internet Access สำหรับพนักงานทั่วไป” ควรอยู่ “ด้านล่าง”
2.2 การจัดการ Policy Shadowing (จุดตายของวิศวกร)
Shadowing คือสถานการณ์ที่ Policy ข้อบน “คลุม” Policy ข้อล่างไว้ทั้งหมด จนข้อล่างไม่มีวันได้ทำงาน
- ตัวอย่าง: กฎที่ 1 อนุญาต “All to All” แต่กฎที่ 2 สั่ง “Block Facebook” ผลคือ Facebook จะไม่ถูก Block เพราะ Packet ไปติดกฎที่ 1 ก่อน
- การแก้ไข: แนะนำให้ใช้เครื่องมือ Policy Lookup ในหน้า GUI หรือใช้คำสั่ง diag debug flow ใน CLI เพื่อหาว่า Packet ตกลงที่ Policy ID ใดกันแน่
3. เจาะลึก NAT (Network Address Translation): มากกว่าการเปลี่ยน IP
ใน FortiGate การทำ NAT แบ่งออกเป็นสองปรัชญาใหญ่ที่วิศวกรต้องเลือกใช้ให้ถูกงานครับ
3.1 Central NAT vs Policy-based NAT
- Policy-based NAT (Default): การกำหนด NAT ไว้ “ภายใน” Firewall Policy ข้อนั้นๆ ข้อดีคือตั้งค่าง่าย เห็นภาพชัดเจนในจุดเดียว
- Central NAT: การแยกตาราง NAT ออกจาก Firewall Policy (คล้ายกับ Palo Alto หรือ Check Point) เหมาะสำหรับองค์กรขนาดใหญ่ที่มี Public IP จำนวนมากและต้องการบริหารจัดการ NAT แบบศูนย์กลาง
3.2 Source NAT (SNAT) – การออกไปสู่โลกภายนอก
- Dynamic IP Pool: การใช้ Public IP หลายตัวหมุนเวียนกัน เพื่อป้องกันปัญหา Port Exhaustion (พอร์ตเต็ม) เมื่อพนักงานจำนวนมากออกอินเทอร์เน็ตพร้อมกัน
- Fixed Port: การล็อกให้พอร์ตต้นทางไม่เปลี่ยน (สำหรับแอปพลิเคชันเก่าๆ ที่เข้มงวดเรื่องพอร์ต)
3.3 Destination NAT (DNAT) – การเปิดประตูบ้าน (Virtual IP)
การทำ Virtual IP (VIP) คือการสร้าง “ตัวแทน” ของ Server ภายในบนโลกอินเทอร์เน็ต
- Port Forwarding: การแมตช์พอร์ตจากภายนอกเข้าหาภายใน (เช่น 8080 ภายนอก เข้าสู่ 80 ภายใน)
- Server Load Balancing (SLB): FortiGate สามารถทำตัวเป็น Load Balancer เบื้องต้น กระจาย Traffic ไปยัง Web Server หลายๆ ตัวภายในได้ด้วยฟีเจอร์ VIP นี้
4. Security Inspection Modes: Proxy vs Flow
ในระดับ Policy เราต้องเลือกโหมดการตรวจ (Inspection Mode) ซึ่งส่งผลโดยตรงต่อ Performance:
- Flow-based: ตรวจข้อมูลขณะที่ Packet วิ่งผ่านไปเลย (Real-time) ข้อดีคือเร็วมาก (High Throughput) แต่ความละเอียดในการแกะไฟล์มัลแวร์จะน้อยกว่า
- Proxy-based: FortiGate จะทำตัวเป็น “คนกลาง” รับข้อมูลมาประกอบเป็นไฟล์ให้เสร็จก่อนแล้วค่อยตรวจ ข้อดีคือละเอียดที่สุด (Deep Inspection) แต่ใช้ทรัพยากร CPU และ RAM สูงกว่า
5. การบริหารจัดการระดับ Enterprise (Policy Management)
เมื่อ Policy เพิ่มขึ้นเป็นหลักพันข้อ ดร. วิรินทร์ แนะนำเทคนิคการจัดการดังนี้
5.1 Policy Grouping & Section View
ใช้การแบ่งกลุ่มตามทิศทางของทราฟฟิก (Sequence) หรือแบ่งตามแผนก เพื่อลดความสับสนและลดเวลาในการหา Rule เมื่อเกิดปัญหา
5.2 Policy Audit & Cleaning
- Hit Count: ตรวจดูว่า Policy ไหนไม่มีคนใช้เลย (Zero Hit) ควรทำการ Disable หรือลบออกเพื่อความปลอดภัย
- Last Used: ตรวจสอบว่ามีการใช้งานครั้งสุดท้ายเมื่อไหร่ หากทิ้งไว้นานอาจเป็น “รูรั่ว” ที่ลืมปิด
- Comment & Tags: การระบุเลขที่ Ticket หรือชื่อผู้ขอสร้าง Policy เพื่อให้สามารถสืบย้อนกลับได้ในอนาคต
6. เทคนิคการ Troubleshooting Policy
หาก User บ่นว่า “เน็ตเข้าไม่ได้” หรือ “แอปทำงานผิดปกติ” ขั้นตอนสืบสวน คือ
- Policy Lookup: ใช้เครื่องมือจำลองใน GUI เพื่อดูว่า Traffic นั้นควรจะไปตกที่ Rule ไหน
- Log Analysis: ตรวจดู Forward Traffic Log ว่าสถานะเป็น Accept, Deny หรือ Timeout
- CLI Debug Flow: ใช้คำสั่ง diag debug flow เพื่อดูระดับเม็ดข้อมูลว่า Packet ถูก Drop ที่ขั้นตอนไหน (เช่น ติดที่ Authentication หรือติดที่ Security Profile)
7. บทสรุป: รากฐานของความมั่นคงปลอดภัย
การออกแบบ Firewall Policy ไม่ใช่แค่การ “ทำให้เน็ตวิ่งได้” แต่มันคือการ “ทำลายความเสี่ยง” ให้เหลือน้อยที่สุด (Principle of Least Privilege) วิศวกรที่เก่งจะเขียน Policy ให้ “น้อยแต่มาก” คือใช้จำนวนข้อน้อยที่สุดแต่ครอบคลุมความปลอดภัยได้ละเอียดที่สุด
ในบทความถัดไป (บทที่ 4) เราจะมาดูเครื่องมือที่จะทำให้ Policy ของเรา “ฉลาดและจัดการง่าย” ยิ่งขึ้น นั่นคือการใช้ Objects (Address, Service, Schedule) ซึ่งจะเปลี่ยนการคอนฟิกแบบเดิมๆ ให้กลายเป็นระบบบริหารจัดการระดับสูง
💡 เกร็ดความรู้
- Explicit Deny Policy: ในองค์กรที่ต้องการความปลอดภัยสูงสุด บางครั้งเราจะสร้าง Policy “Deny All” ไว้ก่อน Implicit Deny เพื่อให้สามารถ “เปิด Log” ของการ Drop ทั้งหมดมาวิเคราะห์ได้ชัดเจนขึ้น
- NAT Loopback: เทคนิคที่ช่วยให้เครื่องภายในสามารถเรียกหา Public IP ของตัวเองได้ (เช่น เรียกหา Web Server ตัวเองผ่านชื่อโดเมนจากภายในวง LAN)