Firewall Rules Best Practices สอนเขียน Rule อย่างมืออาชีพ 2026

ทำไม Firewall Rules ต้องเขียนให้ดี?

Firewall คือด่านแรกในการป้องกันเครือข่ายจากภัยคุกคาม แต่ Firewall ที่ดีต้องมี Rules ที่เขียนดี ด้วย Firewall ที่มี Rules ยุ่งเหยิง ซ้ำซ้อน หรือกว้างเกินไป เท่ากับไม่มี Firewall เลย บทความนี้จะสอนวิธีเขียน Firewall Rules อย่างมืออาชีพ ตั้งแต่หลักการออกแบบ การตั้งชื่อ การ Audit จนถึง Change Management

หลักการออกแบบ Firewall Rules

1. Least Privilege (สิทธิ์น้อยที่สุด)

อนุญาตเฉพาะ Traffic ที่จำเป็นเท่านั้น ไม่ใช่อนุญาตทุกอย่างแล้วค่อย Block ถ้าไม่แน่ใจว่าต้องเปิดหรือไม่ = ไม่เปิด

# BAD: อนุญาตทุกอย่างจาก LAN ไปอินเทอร์เน็ต
permit ip 192.168.1.0/24 any

# GOOD: อนุญาตเฉพาะ HTTP/HTTPS
permit tcp 192.168.1.0/24 any eq 80
permit tcp 192.168.1.0/24 any eq 443

2. Implicit Deny (ปฏิเสธโดยปริยาย)

Rule สุดท้ายต้องเป็น Deny All เสมอ อะไรที่ไม่ได้อนุญาตชัดเจน = ถูก Block อัตโนมัติ Firewall ส่วนใหญ่มี Implicit Deny อยู่แล้ว แต่ควรเขียน Explicit Deny ไว้ด้วยเพื่อความชัดเจนและ Logging

# Rule สุดท้ายเสมอ:
deny ip any any log    # Block ทุกอย่าง + Log ไว้ตรวจสอบ

3. Order Matters (ลำดับสำคัญ)

Firewall ประมวลผล Rules จากบนลงล่าง ถ้า Packet ตรงกับ Rule ใดก่อน จะใช้ Rule นั้นทันที ไม่ดู Rule ถัดไป ดังนั้น:

• Deny rules ที่สำคัญไว้บนสุด (Block known bad traffic ก่อน)
• Specific rules ก่อน General rules
• Frequently matched rules ไว้บน (Performance ดีกว่า)

# ลำดับที่ถูกต้อง:
# 1. Anti-spoofing (Block เบื้องต้น)
deny ip 10.0.0.0/8 any          # Block private IP จาก WAN
deny ip 172.16.0.0/12 any
deny ip 192.168.0.0/16 any

# 2. Known bad actors
deny ip host 203.0.113.50 any   # Blocked attacker IP

# 3. Specific permits
permit tcp 192.168.1.100 host 10.0.0.5 eq 3306   # App server to DB

# 4. General permits
permit tcp 192.168.1.0/24 any eq 443              # LAN to HTTPS

# 5. Implicit deny
deny ip any any log

Rule Documentation — บันทึกทุก Rule

ทุก Rule ต้องมี:

# ตัวอย่าง Rule พร้อม Documentation
# ============================================
# Rule ID: FW-042
# Description: Allow web app server to MySQL database
# Source: 192.168.10.50 (web-app-01)
# Destination: 192.168.20.10 (db-mysql-01)
# Port: TCP 3306
# Business Justification: CRM application requires DB access
# Requester: Somchai - Development Team
# Approved by: Prasert - IT Security Manager
# Date: 2026-04-16
# Review Date: 2026-10-16
# ============================================
permit tcp host 192.168.10.50 host 192.168.20.10 eq 3306

Rule Naming Conventions

ตั้งชื่อ Rule ให้อ่านรู้เรื่อง

Naming Convention ที่แนะนำ

# Format: [ZONE]-[ACTION]-[SRC]-[DST]-[SVC]-[TICKET]
# ตัวอย่าง:
DMZ-ALLOW-WebSrv-to-AppSrv-HTTPS-CHG001
LAN-ALLOW-Users-to-Internet-HTTP-STD
WAN-DENY-Bogons-to-Any-ALL-SEC001
DMZ-ALLOW-LB-to-WebPool-HTTP-CHG042

Zone-Based Rules — แบ่ง Zone ให้ชัดเจน

Network Zones ที่ควรมี

Inter-Zone Policy Matrix

Object Groups — จัดกลุ่มให้เป็นระเบียบ

แทนที่จะเขียน IP Address ตรง ๆ ใน Rule ใช้ Object Groups จะจัดการง่ายกว่ามาก

# สร้าง Object Groups
object-group network WEB-SERVERS
  host 192.168.10.50
  host 192.168.10.51
  host 192.168.10.52

object-group network DB-SERVERS
  host 192.168.20.10
  host 192.168.20.11

object-group service WEB-SERVICES
  tcp eq 80
  tcp eq 443
  tcp eq 8080

# ใช้ Object Group ใน Rules
permit object-group WEB-SERVICES object-group WEB-SERVERS object-group DB-SERVERS

# ถ้าต้องเพิ่ม Web Server ใหม่ แค่เพิ่มใน Object Group
# ไม่ต้องแก้ Rule!

Rule Audit and Cleanup

ทำไมต้อง Audit Rules?

Firewall Rules สะสมมากขึ้นเรื่อย ๆ ตามเวลา Rules ที่เคยจำเป็นอาจไม่จำเป็นแล้ว เซิร์ฟเวอร์ที่เคยมีอาจถูกปลดระวาง แต่ Rule ยังอยู่ ทำให้เกิด:

• Shadow Rules: Rule ที่ไม่มีทาง Match เพราะถูก Rule อื่นบังอยู่
• Redundant Rules: Rule ที่ซ้ำซ้อนกับ Rule อื่น
• Orphan Rules: Rule สำหรับ Server/Service ที่ไม่มีอยู่แล้ว
• Overly Permissive Rules: Rule ที่กว้างเกินไป เช่น permit any any

Audit Checklist

Logging Strategies

Log อะไรบ้าง?

# ตัวอย่าง Logging Rules
# Log denied traffic
deny ip any any log-input         # Log + แสดง Input Interface

# Log admin access
permit tcp 192.168.100.0/24 any eq 22 log   # SSH access logged

# ไม่ Log traffic ปกติที่เยอะ (Performance)
permit tcp 192.168.1.0/24 any eq 443        # No log for normal HTTPS

Change Management สำหรับ Firewall Rules

กระบวนการเปลี่ยนแปลง Firewall Rules

1. Request: ผู้ร้องขอส่ง Change Request พร้อม Business Justification
2. Review: ทีม Security ตรวจสอบว่า Rule ไม่ขัดกับ Policy
3. Risk Assessment: ประเมินความเสี่ยงของการเปลี่ยนแปลง
4. Approval: ผู้มีอำนาจอนุมัติ
5. Implementation: เพิ่ม/แก้ไข Rule ตาม Change Request
6. Testing: ทดสอบว่า Rule ทำงานตามที่ต้องการ
7. Documentation: บันทึก Rule ใน Documentation
8. Review: ตรวจสอบอีกครั้งหลัง 30 วัน

Change Request Template

# ============================================
# FIREWALL CHANGE REQUEST
# ============================================
# Ticket: CHG-2026-0042
# Date: 2026-04-16
# Requester: Somchai (App Development Team)
# Approver: Prasert (IT Security Manager)
#
# Description:
# Allow new microservice (svc-payment) to access
# payment gateway API on port 443
#
# Source: 192.168.10.100 (svc-payment-01)
# Destination: 203.0.113.200 (payment-gateway.com)
# Protocol/Port: TCP/443
# Direction: Outbound
#
# Business Justification:
# New payment processing service requires API access
# to external payment gateway for customer transactions
#
# Risk Level: Low
# Temporary: No
# Review Date: 2026-10-16
# ============================================

Common Firewall Rule Mistakes

Rule Testing — ทดสอบก่อน Deploy

วิธีทดสอบ Firewall Rules

# 1. ทดสอบ Connectivity หลังเพิ่ม Rule
# จาก Source Server:
telnet 192.168.20.10 3306       # ทดสอบ TCP Port
nc -zv 192.168.20.10 3306       # Netcat test
curl -v https://api.example.com  # HTTP/S test

# 2. ทดสอบว่า Deny ทำงาน
# จาก Server ที่ไม่ควรเข้าถึง:
telnet 192.168.20.10 3306       # ต้อง Timeout/Refused

# 3. ตรวจสอบ Hit Count
# Cisco ASA:
show access-list | include FW-042
# Palo Alto:
show rule-hit-count
# FortiGate:
diagnose firewall iprope lookup

Firewall Rule Template

# ============================================
# FIREWALL RULE TEMPLATE
# ============================================
# Rule ID: FW-[XXX]
# Name: [ZONE]-[ACTION]-[SRC]-[DST]-[SVC]-[TICKET]
# Description: [What this rule does]
#
# Source Zone: [WAN/DMZ/LAN/Server/Mgmt]
# Source Address: [IP/Subnet/Object Group]
#
# Destination Zone: [WAN/DMZ/LAN/Server/Mgmt]
# Destination Address: [IP/Subnet/Object Group]
#
# Service/Port: [Protocol/Port]
# Action: [Permit/Deny]
# Logging: [Yes/No]
#
# Business Justification: [Why this rule exists]
# Requester: [Name - Team]
# Approved by: [Name - Role]
#
# Created: [Date]
# Review Date: [Date + 6 months]
# Expiry: [Date or "Permanent"]
#
# Compliance: [PCI-DSS/ISO27001/PDPA/N/A]
# ============================================

Compliance Requirements

สรุป: Firewall Rules ที่ดี = เครือข่ายที่ปลอดภัย

Firewall Rules ที่เขียนอย่างมืออาชีพต้องมีหลักการ Least Privilege, Implicit Deny, ลำดับที่ถูกต้อง, Documentation ครบถ้วน, Naming Convention ที่ชัดเจน และ Change Management ที่เป็นระบบ

เริ่มวันนี้: Audit Firewall Rules ที่มีอยู่ ลบ Rules ที่ไม่ใช้ เพิ่ม Documentation ที่ขาด และสร้าง Change Management Process สำหรับ Firewall Rules ใหม่ทุกตัว เครือข่ายที่ปลอดภัยเริ่มจาก Firewall Rules ที่ดี