รีวิว Firewall Rule อย่างไร และ Rule แบบไหนควรลบ

ตอบสั้น ๆ ก่อนครับ การรีวิว firewall rule คือการไล่ rule ทุกตัวตามลำดับที่ firewall ใช้ตรวจ แล้วถามทีละตัวว่า rule นี้ยังมี traffic ใช้อยู่ไหม กว้างเกินงานที่ต้องทำหรือเปล่า มี rule ด้านบนที่ทำให้มันไม่เคยถูกใช้หรือไม่ หมดอายุแล้วหรือยัง และมีใครเป็นเจ้าของ rule ที่ควรลบหรือแก้มีหกแบบหลัก คือ rule ที่ถูกบัง (shadowed) rule ซ้ำ (redundant) rule แบบ any-any rule ที่ไม่มี hit rule ชั่วคราวที่หมดอายุ และ rule ที่ไม่มีเจ้าของหรือเหตุผลกำกับ

NIST SP 800-41 Rev. 1 ซึ่งเป็นแนวทางเรื่อง firewall ของ NIST (กันยายน 2552) เขียนไว้ว่า ruleset มักซับซ้อนขึ้นตามอายุ firewall ที่เริ่มด้วย rule ไม่กี่ตัว มักมี rule มากขึ้นมากเมื่อใช้งานครบปีแรก และการรีวิวจะช่วยหา rule ที่ไม่จำเป็นแล้ว บทความนี้เขียนเป็น checklist ที่หยิบไปใช้ได้เลยครับ

RULEBASE (top-down, first match)        REVIEW                  
  # name     src  dst      service      finding / action        
────────────────────────────────────────────────────────────────
▶ 1 web-in   any  dmz-web  tcp/443                              
                                                                
  2 lan-out  lan  any      any                                  
                                                                
  3 lan-dns  lan  dns-srv  udp/53                               
                                                                
  4 old-ftp  lan  ftp-01   tcp/21                               
                                                                
  5 vendor   ext  db-01    tcp/1433                             
                                                                
  6 mon-snmp mgmt any      udp/161                              
                                                                
  7 deny-all any  any      any                                  
                                                                
checking                                                        

ก่อนเริ่มรีวิว ต้องเตรียมข้อมูลอะไรบ้าง

ต้องมีสามอย่างครับ ruleset ที่ export ออกมาพร้อมลำดับ ข้อมูลการใช้งานของแต่ละ rule และบันทึกการเปลี่ยนแปลงตั้งแต่รีวิวครั้งก่อน

• ruleset ตามลำดับจริง firewall หลายตัวตรวจ rule ทีละตัวจากบนลงล่างจนกว่าจะเจอตัวที่ตรง ลำดับจึงสำคัญเท่ากับเนื้อหาของ rule บน FortiGate ให้ดูแบบ By Sequence ซึ่งแสดง policy ตามลำดับที่ใช้ตรวจ traffic ไม่ใช่แบบจัดกลุ่มตาม interface
• ข้อมูลการใช้งาน บน PAN-OS แต่ละ rule มี Hit Count, Last Hit, First Hit, Modified และ Created ส่วน FortiGate เก็บ hit count แยกเป็นเจ็ดวันล่าสุดบวกวันปัจจุบัน และดูเวลา first/last hit ได้จาก CLI
• บันทึกการเปลี่ยนแปลง NIST แนะนำว่าการรีวิวแต่ละครั้งควรดูทุกการเปลี่ยนแปลงตั้งแต่รีวิวครั้งก่อน โดยเฉพาะว่าใครเปลี่ยน และเปลี่ยนในสถานการณ์ไหน

ถ้า firewall เป็นคู่ HA ต้องเก็บข้อมูลจากทั้งสองเครื่อง PAN-OS ระบุว่า hit count ไม่ sync ระหว่าง firewall ในคู่ HA ถ้าดูแค่เครื่อง active ตอนนี้ rule ที่ใช้ตอนเครื่องอีกตัวเป็น active จะดูเหมือนไม่มีใครใช้ครับ

Rule แบบไหนควรลบหรือแก้

ไล่จากบนลงล่าง แล้วเช็กทีละข้อด้านล่างนี้กับทุก rule ครับ

1. Rule ที่ถูกบัง (shadowed)

rule ที่ถูกบังคือ rule ที่ไม่มี traffic ไหนมาถึงเลย เพราะ rule ที่อยู่ด้านบนกว้างกว่าและครอบเงื่อนไขของมันไว้หมดแล้ว knowledge base ของ Palo Alto Networks อธิบายว่าคำเตือน shadow มักแปลว่ามี rule ที่กว้างกว่าวางอยู่เหนือ rule ที่เฉพาะเจาะจงกว่า ตอน commit PAN-OS จะขึ้นข้อความแบบนี้

Rule 'rule1' shadows 'rule2'
Configuration committed successfully

สังเกตว่า commit ผ่าน คำเตือนนี้จึงหลุดไปได้ง่าย บทความเดียวกันยังบอกว่า FQDN object ที่ resolve ไม่ได้ก็ทำให้ขึ้นคำเตือนนี้ได้ จึงควรเช็ก FQDN ก่อนสรุปว่า rule ถูกบังจริง

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

2. Rule ซ้ำ (redundant)

rule ซ้ำคือ rule ที่ถ้าลบออก ผลกับ traffic ทุกตัวจะเหมือนเดิม เพราะมี rule อื่นที่ให้ action เดียวกันครอบอยู่ ต่างจาก rule ที่ถูกบังตรงที่ rule ซ้ำอาจยังมี hit เพราะ traffic มาถึงมันก่อน แต่ถ้าไม่มีมัน traffic ก็จะไปตรง rule อื่นที่ให้ผลเดียวกัน NIST บอกว่า firewall บางรุ่นมีเครื่องมือตรวจ policy อัตโนมัติที่หา redundant rules ได้ และควรใช้เป็นประจำ ซึ่งน่าจะเป็นส่วนหนึ่งของรอบรีวิวปกติ

ทำอะไร: รวมเป็น rule เดียว หรือลบตัวที่เล็กกว่า แล้วเช็ก hit count ของ rule ที่เหลือว่าเพิ่มขึ้นตามที่คาด

3. Rule แบบ any-any

rule ที่ source, destination หรือ service เป็น any ขัดกับหลักสองข้อของ NIST คือ ruleset ควรเจาะจงที่สุดเท่าที่ทำได้กับ traffic ที่ควบคุม และ firewall ควร block traffic ทั้งขาเข้าและขาออกที่ policy ไม่ได้อนุญาตไว้ชัดเจน (deny by default) rule ที่เปิด any ในช่อง service คือการอนุญาตทุกอย่างที่ไม่มีใครตั้งใจห้าม ซึ่งตรงข้ามกับ deny by default

ทำอะไร: ใช้ log ของ rule นั้นดูว่ามี traffic อะไรวิ่งผ่านจริง แล้วเขียน rule ใหม่ที่ระบุแค่สิ่งนั้น วางไว้เหนือ rule เดิม เมื่อ rule เดิมไม่มี hit แล้วจึงปิด ตัวอย่างใน PAN-OS docs ใช้วิธีเดียวกันตอนย้ายจาก port-based rule เป็น app-based rule คือวาง rule ใหม่ไว้ด้านบน แล้วดู hit count ว่า traffic ย้ายไปที่ rule ใหม่แล้วจึงลบ rule เดิม

4. Rule ที่ไม่มี hit

rule ที่ไม่มี traffic ตรงเลยในช่วงเวลาที่นานพอเป็นตัวเลือกให้ปิด PAN-OS docs เขียนเหตุผลไว้ว่าการเข้าถึงที่เปิดไว้เกินจำเป็น เช่น เมื่อ server ถูกปลดระวางแล้ว หรือไม่ต้องใช้สิทธิ์ชั่วคราวแล้ว เป็นช่องที่ผู้โจมตีใช้ได้ และควรใช้ hit count หา rule ที่ไม่ได้ใช้แล้วลบออก Policy Optimizer ของ PAN-OS กรองได้ เช่น rule ที่ Unused ใน 30 วันที่ผ่านมา

ทำอะไร: ปิด (disable) ก่อน อย่าเพิ่งลบ ดูหัวข้อถัดไปว่าทำไมครับ

5. Rule ชั่วคราวที่หมดอายุ

rule ที่เปิดให้ vendor เข้ามาทำงาน หรือเปิดไว้ทดสอบ มักไม่มีใครกลับมาปิด ถ้า firewall มีฟีเจอร์วันหมดอายุ ควรใช้ตั้งแต่ตอนสร้าง rule FortiOS 7.4 มี Policy expiration ให้ตั้งวันที่ที่ policy จะถูก disable ค่าเริ่มต้นคือ Disable (ไม่หมดอายุ) ถ้าเลือก Default จะหมดอายุใน 30 วัน ปรับได้ 0 ถึง 365 วัน

config firewall policy
    edit 25
        set policy-expiry enable
        set policy-expiry-date "2025-10-31 18:00:00"
    next
end

ทำอะไร: ค้น rule ที่ชื่อหรือ comment บอกว่าชั่วคราว ถ้าเลยวันที่ตกลงไว้แล้วให้ปิด ถ้ายังต้องใช้ให้ขอวันหมดอายุใหม่พร้อมเหตุผล

6. Rule ที่ไม่มีเจ้าของหรือเหตุผล

rule ที่ไม่มี comment ไม่มีเลข ticket และไม่รู้ว่าใครขอ คือ rule ที่ไม่มีใครตอบได้ว่ายังต้องใช้ไหม NIST เขียนว่า comment ของแต่ละ rule ช่วยให้คนอื่นรู้ว่า rule นั้นสร้างมาทำไม และมีประโยชน์มากกับคน audit ruleset และควรเก็บบันทึกการตัดสินใจเรื่อง policy และทุกการเปลี่ยน ruleset FortiOS 7.4 บังคับได้ด้วย Policy change summary ซึ่งบังคับให้มี audit trail ทุกครั้งที่แก้ firewall policy

ทำอะไร: หาเจ้าของจาก log การเปลี่ยนแปลงหรือจาก traffic ที่วิ่งผ่าน ถ้าหาได้ให้เติม comment ถ้าหาไม่ได้ให้ถือเป็น rule ไม่มี hit และเข้าขั้นตอนปิดก่อนลบ

ทำไมไม่ควรลบ rule ที่ hit count เป็นศูนย์ทันที

เพราะ hit count เป็นศูนย์ไม่ได้แปลว่าไม่มีใครใช้เสมอไปครับ มีอย่างน้อยสี่กรณีที่ตัวเลขนี้หลอกได้

• ช่วงเวลาสั้นเกินไป งานที่รันรายไตรมาสหรือรายปีจะไม่โผล่ใน 30 วัน และหน้า policy list ของ FortiGate แสดง hit count แค่เจ็ดวันล่าสุด
• counter ถูก reset บน PAN-OS hit count อยู่ต่อหลัง reboot และ upgrade แต่จะหายถ้า reset เองหรือเปลี่ยนชื่อ rule และข้อมูลที่ reset แล้วไม่ได้เก็บไว้ที่ไหน บน FortiGate ปุ่ม Clear Counters ลบสถิติของ policy นั้น
• ดูเครื่องเดียวในคู่ HA อย่างที่บอกข้างบน
• rule สำรองสำหรับเหตุฉุกเฉิน เช่น rule สำหรับ DR site ที่จะถูกใช้เมื่อเกิด failover เท่านั้น

ก่อนปิด rule ควรเช็กวันที่ใน Created และ Modified ด้วย rule ที่เพิ่งสร้างเมื่อวานก็มี hit เป็นศูนย์เหมือนกัน และ Policy Optimizer ของ PAN-OS มีตัวเลือกไม่นับ rule ที่ถูก reset ภายในจำนวนวันที่กำหนด

ลบ rule อย่างไรไม่ให้ระบบล่ม

ทำเป็นสามจังหวะครับ ทดสอบ ปิด แล้วค่อยลบ

1. ทดสอบก่อนแก้ ใช้เครื่องมือ policy match ส่ง traffic สมมติเข้าไปถาม firewall ว่าจะตรง rule ไหน บน PAN-OS อยู่ที่ Device > Troubleshooting ใส่ zone, source, destination, port และ protocol บน FortiGate คือ Policy Lookup ซึ่งจะไฮไลต์ policy ที่ตรงในหน้ารายการ วิธีนี้ใช้เช็กได้ว่าเมื่อย้ายหรือปิด rule แล้ว traffic จะไปตกที่ rule ไหน
2. ปิดก่อน และติด tag กับวันที่ PAN-OS ให้ disable และ tag rule ได้จากหน้า Policy Optimizer โดยตรง rule ที่ปิดไว้เปิดกลับได้ในคำสั่งเดียวถ้ามีคนโทรมาว่าระบบใช้ไม่ได้
3. ลบเมื่อผ่านช่วงรอ ผ่านไปหนึ่งรอบที่ครอบงานรายเดือนหรือรายไตรมาสแล้วไม่มีใครแจ้งปัญหา จึงลบ และบันทึกลงใน change log

ทุกจังหวะควรผ่าน change management NIST เขียนว่าการแก้ ruleset ควรอยู่ใต้กระบวนการ change management อย่างเป็นทางการ เพราะกระทบทั้งความปลอดภัยและการทำงานของธุรกิจ และควร backup policy กับ ruleset เป็นประจำ ก่อนเริ่ม

ควรรีวิว firewall rule บ่อยแค่ไหน

NIST ไม่ได้กำหนดตัวเลข แต่บอกว่าควรรีวิวเป็นรอบที่แน่นอน ไม่ใช่รอให้มี audit หรือเหตุฉุกเฉิน และแนะนำให้บางครั้งให้คนที่ไม่ได้อยู่ในทีมรีวิวปกติมา audit ruleset ทั้งชุด เพื่อดูว่า policy ยังตรงกับเป้าหมายขององค์กรไหม NIST ยังเสนอ penetration test เพื่อเช็กว่า ruleset ทำงานตามที่ตั้งใจ แต่ใช้เพิ่มจากการ audit ไม่ใช่ใช้แทน

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

แหล่งอ้างอิง

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy (กันยายน 2552)
• Palo Alto Networks PAN-OS 11.1: View Policy Rule Usage
• Palo Alto Networks PAN-OS 11.1: Test Policy Rules
• Palo Alto Networks Knowledge Base: What is a Shadow Rule?
• Fortinet FortiOS 7.4.0: Firewall policy
• Fortinet FortiOS 7.4.2: Seven-day rolling counter for policy hit counters