ภาพในใจ — Packet = ซองพัสดุที่มีหน้าซอง + ของในซอง#

ทุกอย่างที่วิ่งบน network — อีเมล / รูปใน Line / video YouTube / ข้อมูลธนาคาร / SQL query ของ application — ถูก ตัดเป็นชิ้นเล็กๆ เรียกว่า packet (ซองพัสดุดิจิทัล)

แต่ละ packet มี 2 ส่วน:

1. Header (หน้าซองพัสดุ) — เขียนว่า มาจากไหน → ไปไหน + ส่งทางช่องไหน + ขนาดเท่าไร
2. Payload (ของในซอง) — เนื้อหาจริง (ข้อความ / รูป / ไฟล์ / SQL query)

Firewall = ยามที่อ่านหน้าซอง (header) — บางรุ่นอ่านได้แค่หน้าซอง บางรุ่นเปิดซองดูของข้างในได้ — และตัดสินใจว่า อนุญาตให้ผ่าน หรือ ทิ้ง

IP Address — เลขที่บ้านของอุปกรณ์#

IP address (Internet Protocol address) = เลขที่บ้านของเครื่อง ใน network. ทุกอุปกรณ์ที่ต่อ internet มี IP address — เหมือนทุกบ้านมีเลขที่

มี 2 รุ่น:

• IPv4 — เช่น 192.168.1.100 หรือ 203.150.220.55 (ตัวเลข 4 ชุด)
• IPv6 — เช่น 2001:0db8:85a3::8a2e:0370:7334 (ยาวกว่ามาก เพราะ IPv4 ใกล้หมด)

ลองนึก scenario — เครื่อง laptop ของคุณที่บ้านมี IP 192.168.1.50. เว็บธนาคารของคุณมี IP 203.150.220.10. ตอนคุณเปิดเว็บธนาคาร — packet จะมี header — source = 192.168.1.50 → destination = 203.150.220.10

Firewall อ่านได้แค่ source + destination — สามารถบอกได้ว่า “เครื่องนี้คุยกับเว็บนี้” — แต่ บอกไม่ได้ว่าคุยเรื่องอะไร

Port — ประตูหน้าบ้าน ที่บอกว่ารับบริการอะไร#

Port = ประตูหน้าบ้าน ที่บอกว่า packet นี้ขอใช้บริการอะไร ในเครื่องนั้น

ลองนึก — บ้านหลังเดียว (IP address เดียว) — แต่มีหลายประตู — ประตูหน้าสำหรับลูกค้า / ประตูหลังสำหรับครัว / ประตูข้างสำหรับซ่อมบำรุง

ในโลก network — port เป็นตัวเลข 0-65535. มี port มาตรฐานที่ทุก service ใช้:

• Port 80 — HTTP (เว็บ ไม่ encrypt)
• Port 443 — HTTPS (เว็บ encrypt — TLS จาก EP.24)
• Port 22 — SSH (remote login)
• Port 25 — SMTP (ส่งอีเมล — EP.25)
• Port 3306 — MySQL database
• Port 3389 — RDP (Remote Desktop ของ Windows)
• Port 53 — DNS (สมุดที่อยู่)

ทำไม port สำคัญต่อ firewall — เพราะ firewall ตัดสินใจได้ที่ระดับ port. เช่น — “อนุญาต port 443 (เว็บ HTTPS) จาก internet เข้ามาที่ web server” + “บล็อก port 3306 (MySQL) ห้ามจาก internet เข้ามาที่ database server”

เอาตรงๆ ครับ — ปัญหาคลาสสิคของวงการ ที่ทำให้บริษัทโดน breach — คือ ลืม block port ที่ไม่ควรเปิดให้ internet. เคสในข่าวบ่อยที่สุดคือ — เปิด port 3389 (RDP) ของ Windows ให้ internet เข้าถึงได้ — โจรสแกนเจอ → brute-force password → เข้าได้. นี่คือเส้นทางของ ransomware ส่วนใหญ่ในไทยช่วง 2020-2024

TCP vs UDP — ระบบไปรษณีย์ลงทะเบียน vs ไปรษณีย์ธรรมดา#

TCP (Transmission Control Protocol) = ไปรษณีย์ลงทะเบียน — ยืนยันว่าของถึงจริง + เรียงลำดับถูก + ถ้าหายส่งใหม่. ใช้กับเว็บ / อีเมล / file transfer — ที่ต้อง ครบ + เรียง

UDP (User Datagram Protocol) = ไปรษณีย์ธรรมดา — ส่งไปแล้วก็แล้วกัน ไม่ยืนยัน. ใช้กับ video streaming / voice call / online game — ที่ต้อง เร็ว + ยอมเสีย packet ได้บ้าง (ภาพกระตุกหน่อยดีกว่ารอ)

Firewall ส่วนใหญ่ตรวจได้ทั้ง TCP + UDP — แต่ rule ต่างกัน เพราะ UDP ไม่มี connection state ให้จำ (ดูหัวข้อ stateful firewall ข้างล่าง)

OSI Model — 7 ชั้นของระบบ network ในภาษาคน#

ในตำราจะเจอคำว่า OSI Model ที่เป็นโมเดล 7 ชั้นของ network. ผมไม่อยากให้คุณจำชื่อทุกชั้น — แต่ให้จำว่ามีระดับ ล่าง (สาย / สัญญาณ / IP / port) และระดับ บน (application / ของในซอง)

ใน 7 ชั้น — 3 ชั้นที่ผู้บริหารควรรู้ชื่อ:

• Layer 3 (Network) — IP address — “บ้านไหน → บ้านไหน”
• Layer 4 (Transport) — TCP/UDP + port — “ประตูไหน → ประตูไหน + ระบบลงทะเบียนหรือธรรมดา”
• Layer 7 (Application) — ของในซอง — HTTP / SQL / email content — “คุยเรื่องอะไร”

ทำไมเรื่องนี้สำคัญ — เพราะ firewall 4 รุ่น ที่เราจะคุยต่อ — แต่ละรุ่น ตรวจที่ Layer ต่างกัน:

• Gen 1 (Packet Filter) — ตรวจ Layer 3 + 4 (IP + port)
• Gen 2 (Stateful) — ตรวจ Layer 3 + 4 + จำ connection
• Gen 3 (NGFW) — ตรวจถึง Layer 7 (เปิดซองดูของ)
• Gen 4 (Cloud) — Layer 3 + 4 (เป็นหลัก) แต่ในรูปแบบ cloud-native

ตรงนี้คือ อ้าว — เรื่องวิวัฒนาการของ firewall ที่ผู้บริหารต้องเข้าใจ

มุมผู้บริหาร: ผู้บริหารไม่ต้องจำตัวเลข — แค่ถามคำถามถูก 2 ข้อใน meeting กับ network team — “ป้อมยามของเราตรวจถึง layer ไหน?” (รุ่นเก่าดู layer 3-4 / รุ่นใหม่ดูถึง layer 7) และ “port อะไรของเราเปิดสู่ internet — มีรายการไหม?” ถ้าตอบรายการไม่ได้ทันที = ไม่รู้ว่าประตูบ้านเปิดให้ใครเข้าบ้าง

ภาษา rule ของ packet filter#

ลองนึก rule book ของยามรุ่นนี้:

1
RULE 1: ALLOW from ANY to web-server:443 (TCP)
2
RULE 2: ALLOW from office-network to mail-server:25 (TCP)
3
RULE 3: DENY from ANY to database-server:3306 (TCP)
4
RULE 4: DENY all other

อ่านได้ว่า — อนุญาตทุกคนเข้าเว็บ port 443 ได้ + อนุญาตเฉพาะคนในออฟฟิศส่งเมล + ห้ามทุกคนเข้า database จาก internet + ที่เหลือ ห้ามหมด

rule สุดท้าย — “DENY all other” — สำคัญที่สุด เรียกว่า Default Deny หรือ Deny by Default. หลักการคือ — อะไรที่ไม่ได้ allow ชัดเจน = ห้ามหมด. ตรงข้ามกับ Default Allow ที่ปล่อยทุกอย่างที่ไม่ได้ ban — ซึ่งคือ กับดักคลาสสิคของวงการ ที่ทำให้บริษัทโดน breach

ข้อดีของ packet filter#

• เร็ว — ตัดสินใจในไม่กี่ microsecond ต่อ packet เพราะดูแค่ header
• simple — เข้าใจง่าย rule ไม่ซับซ้อน
• ราคาถูก — hardware ไม่ต้องแรง
• ยังใช้อยู่จริง — Linux iptables / nftables พื้นฐานคือ packet filter

ข้อจำกัดของ packet filter — เหตุที่ต้องวิวัฒนาการเป็นรุ่น 2#

ลองนึก scenario นี้ดูครับ — ยามเห็นรถยี่ห้อ A คันเก่งของพนักงาน. ออกไปนอกหมู่บ้านตอนเช้า. ตอนเย็นกลับมา — แต่ยาม จำไม่ได้ ว่าคันนี้เคยออก — ยามต้องเช็คใหม่ทั้งหมดเหมือนรถมาใหม่ครั้งแรก

ในโลก network — ปัญหานี้คือ — stateless. ยามรุ่น 1 ไม่มีความจำ. ทุก packet ตรวจใหม่ราวกับเป็น packet แรก

ปัญหาจริงที่เกิด:

1. ไม่รู้ว่า return packet เป็น reply ของ session ที่เคยเปิดหรือเปล่า — ลูกค้าในออฟฟิศคลิกเข้าเว็บข้างนอก (outbound) → server ตอบกลับ (inbound) ยามรุ่น 1 ตัดสินใจ inbound packet โดย ไม่รู้ว่าเป็น reply ของ request ที่ออกไปก่อน ต้องเปิด rule กว้าง “อนุญาต inbound TCP จาก internet ทุก port” → ช่องโหว่ใหญ่

2. โดนหลอกได้ง่ายด้วย spoofing — โจรปลอม source IP ของ packet ให้ดูเหมือนมาจาก trusted source

3. ไม่เห็นของในซอง — มี SQL injection / malware / data exfiltration ใน payload ก็มองไม่เห็น เพราะ ยามอ่านได้แค่หน้าซอง

นี่คือเหตุที่ pure packet filter — ไม่พอใช้ตั้งแต่ปี 1994 เป็นต้นมา

มุมผู้บริหาร: ถ้าบริษัทของคุณยังใช้ pure packet filter เป็น perimeter firewall ในปี 2026 — คุณอยู่หลังโลก 30 ปี. แต่ packet filter ยัง มีประโยชน์ ในระดับ host-level (เช่น iptables ของ Linux server แต่ละเครื่อง) — เป็น defense in depth เลเยอร์ใน. คำถามที่ผู้บริหารควรถาม IT team — “perimeter firewall ของเราเป็น Gen ไหน — และเราใช้ default deny หรือ default allow”. ถ้า answer = “default allow” หรือ “ไม่แน่ใจ” → red flag ที่ต้องแก้ก่อนทำอย่างอื่น. หลักการ default deny เป็น control พื้นฐานที่ลด attack surface 60-80% โดยที่ไม่ต้องลงทุนใหม่ — แค่ rewrite rule

State Table — สมุดบันทึกของยาม#

ลองดูตัวอย่างกันครับ. ในใจของ firewall stateful — มีตารางที่เก็บ:

1
Connection ID | Source IP    | Dest IP       | Src Port | Dst Port | State        | Last Seen
2
0x4A2F        | 192.168.1.50 | 203.150.220.10| 51234    | 443      | ESTABLISHED  | 09:15:42
3
0x4A30        | 192.168.1.51 | 8.8.8.8       | 33567    | 53       | RELATED      | 09:16:01

ทุก connection มี state ที่ track ได้:

• NEW — packet แรกของ connection ใหม่
• ESTABLISHED — connection เปิดแล้ว ทั้ง 2 ฝั่งคุยกันได้
• RELATED — connection ที่เกี่ยวข้องกับ connection หลัก (เช่น FTP data channel)
• INVALID — packet ที่ไม่ตรงกับ state ใดๆ — น่าสงสัย ทิ้ง

ทำไม stateful ดีกว่ามาก#

1. จัดการ return traffic ได้อัตโนมัติ — เมื่อ outbound packet ออกไป — firewall จดในตาราง — return packet ที่ตรง connection กลับเข้ามา อนุญาตเอง ไม่ต้องเปิด rule กว้าง. ลด attack surface มหาศาล

2. ตรวจ TCP handshake state ได้ — TCP connection เปิดด้วย 3-way handshake (SYN → SYN-ACK → ACK). stateful firewall ตรวจได้ว่า packet มาในลำดับที่ถูก. packet ที่ไม่ตรงลำดับ = invalid = ทิ้ง. กัน SYN flood attack ได้บางส่วน

3. กัน spoofing ได้ดีขึ้น — โจรที่ปลอม source IP เพื่อแฮก connection — ต้องเดา sequence number ของ TCP ให้ถูก — ยากกว่ามาก

ข้อจำกัดของ Stateful — ยังเปิดซองไม่ได้#

แต่ stateful firewall ก็ยังมีข้อจำกัด — ตรวจได้แค่ที่ Layer 3 + 4 + state. ไม่เปิดดูของในซอง (Layer 7)

ลองนึก scenario — โจรส่ง packet เข้าทาง port 443 (HTTPS) — ซึ่ง firewall อนุญาตให้ลูกค้าทุกคนใช้ — แต่ใน payload มี SQL injection ที่จะโจมตี web application. stateful firewall มองไม่เห็น เพราะตรวจไม่ถึง Layer 7

อีกตัวอย่าง — malware ที่ใช้ DNS tunneling — ส่งคำสั่งและขโมยข้อมูลผ่าน port 53 (DNS) ซึ่งทุกบริษัทเปิดให้ใช้. stateful firewall เห็นแค่ “packet ออกไป port 53 ปกติ” — ไม่รู้ว่าใน payload มี data exfiltration

นี่คือเหตุที่ — ตั้งแต่ประมาณปี 2007 — วงการต้องการ firewall ที่เปิดซองได้ — รุ่น 3

ทำไม stateful ยังเป็น “เกณฑ์ขั้นต่ำ” ของปี 2026#

แม้ Gen 3 + 4 จะออกมาแล้ว — stateful firewall ยังเป็นมาตรฐานขั้นต่ำ ของ network firewall ในปี 2026. Linux iptables ที่ใช้ option --state หรือ nftables ของ Ubuntu / RHEL — เป็น stateful firewall. AWS Security Group ก็เป็น stateful (เราจะเข้าหัวข้อข้างล่าง)

ถ้าบริษัทคุณยังใช้ stateless — แสดงว่าระบบเก่ามาก ควร upgrade ทันที

มุมผู้บริหาร: stateful firewall เป็น baseline ที่ทุก enterprise ต้องมี — ไม่ใช่ “ขั้นสูง” อีกต่อไป. คำถามที่ผู้บริหารควรถาม — “firewall ที่เราใช้ — perimeter เป็น stateful ไหม + host-level (server ทุกตัว) เป็น stateful ไหม”. ทั้ง 2 ระดับต้องใช่. นอกจากนั้น — สังเกตว่า stateful firewall ลด rule ที่ต้องเขียนได้ครึ่งหนึ่ง (ไม่ต้องเขียน return rule แยก) — ทำให้ rule book สะอาดและจัดการง่าย. ถ้า rule book ของบริษัทคุณยังมี inbound rule ที่อนุญาต return traffic แยกต่างหาก — แสดงว่าออกแบบเดิมจากยุค packet filter ที่ยังไม่ refactor — ใช้โอกาส refactor ตอน upgrade

1. Deep Packet Inspection (DPI) — เปิดซองดูเนื้อหา#

Deep Packet Inspection (DPI — การตรวจสอบเนื้อใน packet ระดับลึก) = ความสามารถใน อ่าน payload (เนื้อในซอง) ของ packet ไม่ใช่แค่ header

NGFW สามารถ:

• ดูว่า traffic ใน port 80/443 จริงๆ เป็น HTTP หรือ malware ที่ใช้ HTTP เป็น cover
• ตรวจ pattern ของ SQL injection ใน HTTP request
• ตรวจ malware signature ใน file transfer
• บล็อก specific URL category (เช่น gambling / adult / proxy site)

2. Application Awareness — รู้ว่า traffic นี้คือ app อะไร#

นี่คือฟีเจอร์ที่ Palo Alto Networks (founded 2005 โดย Nir Zuk) push หนัก ทำให้ Palo Alto กลายเป็นเจ้าตลาด NGFW

Application Awareness = NGFW สามารถระบุว่า — traffic ที่วิ่งผ่าน port 443 (HTTPS) เป็น application อะไร — Facebook? YouTube? Dropbox? Salesforce? BitTorrent ที่ปลอมเป็น HTTPS?

ทำไมเรื่องนี้สำคัญ — เพราะในยุคนี้ app ทุกตัวซ่อนใน HTTPS. ยุค packet filter — “ปิด port 443 = ปิด Facebook” ทำได้. ยุคนี้ — port 443 = ทุกอย่าง — ปิดไม่ได้ ต้อง identify เป็น app เฉพาะแล้วเลือก allow/block

ลองนึก rule book ของ NGFW:

1
RULE 1: ALLOW Salesforce, Microsoft 365 from office to internet
2
RULE 2: ALLOW Dropbox for engineering team only
3
RULE 3: DENY BitTorrent, anonymous proxy, gambling, adult
4
RULE 4: BLOCK known C2 servers (auto-updated)

อ่านได้ว่า — บริษัทใช้ Salesforce + M365 ได้ + Dropbox เฉพาะทีม engineer + ห้าม BitTorrent / proxy / gambling / adult + บล็อก IP ของ command-and-control server ที่รู้จัก (อัพเดตอัตโนมัติจาก threat intelligence feed)

3. Intrusion Prevention System (IPS) Integrated — ตำรวจหยุดรถในป้อม#

NGFW มัก built-in Intrusion Prevention System (IPS) เข้ามาในกล่องเดียว. IPS คือระบบที่ตรวจ + บล็อก การโจมตีที่รู้จัก (signature) หรือ pattern ที่ผิดปกติ (anomaly)

เราจะเข้าหัวข้อ IPS / IDS / WAF เต็มๆ ใน EP.29 — แต่จำไว้ว่าใน NGFW มีพื้นฐานของ IPS ฝังในแล้ว

4. User Identity Awareness — รู้ว่าใครใช้ ไม่ใช่แค่ IP ไหน#

NGFW เก่งๆ — integrate กับ Active Directory / Azure AD / LDAP — สามารถระบุได้ว่า — packet นี้มาจาก user คนไหน ไม่ใช่แค่ IP address

ลองนึก rule book:

1
RULE: ALLOW user=engineering-group to Dropbox, GitHub
2
RULE: ALLOW user=finance-group to Banking-portal
3
RULE: DENY user=intern-group to admin-tool

นี่คือการ enforce นโยบายตาม user identity — แทนที่จะตาม IP address ที่ user เปลี่ยนได้ทุกวัน (โดยเฉพาะยุค laptop เคลื่อนที่ + remote work)

5. SSL/TLS Decryption — เปิดซองที่ปิดผนึก#

ตอนนี้ traffic 90%+ ใน internet เป็น HTTPS (encrypted). ถ้าไม่ decrypt — DPI ก็มองไม่เห็นเนื้อใน

NGFW สามารถทำ SSL/TLS Decryption (เรียกเรียกว่า SSL inspection):

1. firewall ทำตัวเป็น MITM (Man-in-the-Middle) ที่ได้รับอนุญาต
2. decrypt traffic ที่เข้ามา → ตรวจเนื้อหา → encrypt ใหม่ส่งต่อ
3. ใช้ root certificate ของบริษัทที่ติดตั้งในเครื่อง employee

ข้อระวัง — SSL inspection มี trade-off กับ privacy (employee อาจรู้สึกว่าโดน monitor) + กระทบ TLS 1.3 + Certificate Pinning + ใช้ CPU เยอะ. ต้องวางนโยบายชัดว่า decrypt traffic ประเภทไหน (เช่น ไม่ decrypt banking site + healthcare site)

NGFW ในวงการ — Vendor หลัก#

ในตลาดปัจจุบัน (2026) — vendor หลักของ NGFW:

• Palo Alto Networks — เจ้าตลาด — รุ่น PA-series + Prisma
• Fortinet — FortiGate — เด่นเรื่อง performance + ราคา
• Cisco — Firepower / Secure Firewall — แข็งใน enterprise ที่ใช้ Cisco อยู่แล้ว
• Check Point — Quantum series — ผู้บุกเบิก stateful + ยังแข็งใน NGFW
• pfSense / OPNsense — open-source ที่ SME / homelab ใช้ได้ฟรี

ราคา enterprise NGFW — เริ่มหลักแสนบาทถึงหลายล้านบาทต่อกล่อง สำหรับองค์กรใหญ่

มุมผู้บริหาร: การ upgrade จาก stateful → NGFW เป็น investment ที่จำเป็น สำหรับองค์กรกลาง-ใหญ่ในไทยตอนนี้. แต่ NGFW ไม่ใช่ silver bullet — feature ทั้งหมดต้อง เปิดและ tune ให้เหมาะ ไม่งั้นจ่ายแพงเพื่อใช้แค่ feature ของ Gen 2. ในเคสที่เจอได้ทั่วไป — บริษัทไทยซื้อ Palo Alto / FortiGate มาราคาหลายล้าน — แต่ ไม่เปิด App-ID / SSL inspection / User-ID เพราะกลัว break อะไร — ใช้เหมือน stateful firewall ราคาแพง. คำถามที่ผู้บริหารควรถาม — “NGFW ของเราเปิด feature อะไรบ้าง — มี report ว่า block อะไรในเดือนที่ผ่านมาไหม”. ถ้าตัวเลขเป็น 0 หรือเล็กมาก = ไม่ได้ใช้จริง = waste investment. ROI ของ NGFW มาจาก threat intelligence feed + application visibility — ไม่ใช่จาก hardware

AWS Security Group — Stateful Firewall ที่ติดกับทุก instance#

มาดูเคสที่ใช้กันเยอะที่สุดในปี 2026 ครับ. ใน AWS — Security Group (SG) = stateful firewall ที่ติดกับ ENI (Elastic Network Interface) ของแต่ละ EC2 instance / Lambda / RDS / ฯลฯ

ลักษณะ:

• stateful — return traffic ผ่านอัตโนมัติ
• default deny — เฉพาะที่ allow ชัดเจน inbound. outbound default allow (เว้นแก้)
• อ้างอิงด้วย ID ของ SG อื่นได้ — เช่น “allow inbound port 3306 จาก SG ของ application tier” (ไม่ต้องเขียน IP ที่เปลี่ยนได้ทุกครั้งที่ scale)
• ไม่มี explicit deny — เฉพาะ allow + implicit deny ที่เหลือ

ตัวอย่าง:

1
SG: web-tier
2
  Inbound:  allow 443 from 0.0.0.0/0 (internet)
3
            allow 22 from bastion-sg
4

5
SG: app-tier
6
  Inbound:  allow 8080 from web-tier-sg
7

8
SG: db-tier
9
  Inbound:  allow 3306 from app-tier-sg

อ่านได้ว่า — internet เข้าได้แค่ web tier port 443 → web tier ต่อ app tier port 8080 → app tier ต่อ db tier port 3306. ทุก tier เปิดเฉพาะ source ที่จำเป็น — และไม่ต้อง hard-code IP

Azure NSG (Network Security Group) — คล้าย AWS SG#

ใน Azure — Network Security Group (NSG) = ทำหน้าที่คล้าย AWS SG แต่:

• มี priority ของ rule (เลข 100-4096)
• มีทั้ง allow + deny rule explicit (ไม่ใช่ implicit deny อย่างเดียว)
• ติดกับ subnet หรือ NIC ของ VM ได้

Google Cloud Platform (GCP) มี VPC Firewall Rules — concept คล้ายๆ กัน

ทำไม cloud firewall ต่างจาก traditional firewall#

1. Distributed, not perimeter — ไม่ใช่ “กำแพงเมือง” — แต่ “ป้อมที่ทุกบ้าน”. concept เปลี่ยนจาก perimeter-based → identity / workload-based

2. Auto-scaling — เมื่อ application scale up เป็น 100 instance — security policy ตามไปด้วยอัตโนมัติ. traditional firewall ทำไม่ได้ — ต้อง manual

3. API-driven (Infrastructure as Code) — rule เปลี่ยนผ่าน Terraform / CloudFormation / ARM template. ตรวจ + review ใน git ได้. version control + rollback ได้. traditional firewall — เปลี่ยนผ่าน GUI / CLI ของ vendor

4. Native log to cloud-native SIEM — log ส่งตรงเข้า AWS CloudWatch / Azure Monitor / GCP Logging — analyze ด้วย cloud-native tool ได้

5. ขาด feature ของ NGFW บางอย่าง — AWS SG + Azure NSG ไม่ใช่ NGFW — ไม่มี DPI, ไม่มี application awareness, ไม่มี IPS. ตรวจที่ Layer 3 + 4 + state เป็นหลัก. ถ้าต้องการ NGFW ใน cloud — ต้องใช้ AWS Network Firewall หรือ Azure Firewall Premium หรือ deploy NGFW vendor (Palo Alto VM-Series / FortiGate-VM) ใน cloud

Cloud-native NGFW — เทรนด์ปี 2024-2026#

ในปี 2024-2026 — เทรนด์คือ cloud-native NGFW:

• AWS Network Firewall (launched 2020) — managed service ที่มี DPI + IPS
• Azure Firewall + Azure Firewall Premium — IDPS + TLS inspection + URL filtering
• GCP Cloud NGFW (2023) — fully distributed
• Cloudflare Magic Firewall — ระดับ network edge ทั่วโลก

นี่คือ convergence ของ NGFW + Cloud Firewall — รวมเข้าด้วยกันใน managed service

SASE / SSE — เทรนด์ใหม่ของ network security#

อีกเทรนด์ในวงการ — SASE (Secure Access Service Edge) ที่ Gartner ตั้งคำในปี 2019 — เป็นแนวคิดที่รวม firewall + VPN + CASB + ZTNA + SD-WAN เป็น cloud-delivered service เดียว

vendor หลัก: Zscaler, Cloudflare, Netskope, Palo Alto Prisma Access, Cisco Umbrella + Duo, Fortinet FortiSASE

เราจะคุย SASE ลึกๆ ใน EP.37 (Remote Work + ZTNA) — แต่ตอนนี้ให้รู้ว่า — firewall ในปี 2026 ไม่ใช่กล่องเดียวที่หน้าออฟฟิศ อีกต่อไป — มัน distribute ทั่ว cloud + ทุก edge

มุมผู้บริหาร: ถ้าบริษัทคุณ migrate ไป cloud — traditional firewall ที่หน้าออฟฟิศไม่พอ. คำถามที่ผู้บริหารควรถาม CISO/CTO — “workload ของเราใน cloud — SG/NSG manage ผ่าน IaC + code review หรือผ่าน GUI manual?” ถ้าตอบ GUI manual = rule sprawl จะตามมาในไม่กี่เดือน. Capital One breach 2019 ที่เสียหายระดับร้อยล้านดอลลาร์ — root cause ตรงนี้เลย

วงจรชีวิตของ rule sprawl#

ภาพในใจง่ายๆ ครับ:

1. ปีที่ 1 — บริษัทตั้ง firewall. rule 30-50 ข้อ. ทุกคนเข้าใจ
2. ปีที่ 3 — application ใหม่ launch — ขอเปิด port + เปิด rule. คนเปิด rule = engineer คนหนึ่ง. document = comment สั้นๆ ใน rule
3. ปีที่ 5 — engineer คนนั้นลาออก. application ถูก decommission. แต่ rule ยังอยู่ — เพราะไม่มีกระบวนการลบ
4. ปีที่ 8 — มี rule 500 ข้อ. คนใหม่เข้ามา ไม่กล้าลบเพราะ “กลัว break อะไร”
5. ปีที่ 12 — rule 1,500 ข้อ. มี shadow rule (rule ที่ถูก override ด้วย rule อื่น — ไม่มีผล) + redundant rule (ซ้ำซ้อน) + overly permissive rule (allow กว้างเกิน) + rule ที่ไม่มีใครรู้ว่าทำอะไร
6. ปีที่ 15 — บริษัทโดน audit. audit findings ขอ review rule. ทีมใช้เวลา 6 เดือน review แล้วยังไม่จบ

นี่คือ rule sprawl ที่เห็นในข่าว IT industry บ่อย — บริษัทไทยใหญ่ๆ มี 1,000+ rules บน Palo Alto / FortiGate / Check Point — และ ไม่มีใครรู้จริงว่า แต่ละ rule ทำอะไร

Anti-pattern ที่เจอบ่อยที่สุด#

1. Any-Any-Allow — rule ที่อนุญาต source = any, destination = any, port = any. ไม่ใช่ firewall — เป็นทางหลวง

2. Permissive temporary rule — engineer เปิด rule “ชั่วคราวสำหรับ test” แล้วลืมปิด — 5 ปีผ่านไป

3. Rule ที่ระบุ IP เก่า — IP ของ partner เก่าที่ปิด business ไปแล้ว — rule ยังอยู่

4. Shadow rule — rule ลำดับ 50 บอก allow แต่ rule ลำดับ 30 deny ก่อนแล้ว → rule 50 ไม่มีผล แต่ยังอยู่ใน rule book ทำให้สับสน

5. Overly broad scope — “allow port 1-65535 จาก subnet ทั้งหมด” — แทนที่จะระบุ port ที่จำเป็น

6. Duplicate rule — rule เหมือนกัน เขียน 5 ครั้ง โดยทีมที่ไม่ได้คุยกัน

วิธีรักษา — Firewall Hygiene#

มี 6 หลักการ ของ firewall hygiene ที่ผู้บริหารควรขอให้ทีม IT ทำ:

1. Documentation บังคับ — ทุก rule ต้องมี comment ที่ระบุ — เปิดโดยใคร / วันที่ / business owner / purpose / review date

2. Default deny ทุก zone — rule สุดท้ายต้องเป็น “deny all”. ห้ามใช้ default allow

3. Periodic review (6-12 เดือน) — review ทุก rule. business owner ยืนยันว่ายังจำเป็น — ถ้าไม่ยืนยัน → ลบ

4. Change management process — ทุก rule change ผ่าน ticket + approval + log. ห้าม engineer เปิด rule เอง

5. Automated tool ตรวจ shadow + redundant — vendor อย่าง AlgoSec, Tufin, Skybox, FireMon มี tool ที่ scan firewall config + ระบุ rule ที่มีปัญหา

6. IaC สำหรับ cloud firewall — เปลี่ยนผ่าน git commit + PR review เท่านั้น. ไม่มี manual change ใน console

Default Deny — กฎเหล็กที่ลด liability มากที่สุด#

ในทั้ง 6 ข้อ — ผมอยากเน้นข้อ 2 — Default Deny

หลักการ: “อะไรที่ไม่ได้ allow ชัดเจน = ห้ามหมด”

ตรงข้ามกับ Default Allow — “อะไรที่ไม่ได้ ban = ปล่อยผ่าน”

ทำไม default deny สำคัญที่สุด:

• กัน unknown attack — ภัยที่ยังไม่รู้จัก (zero-day) — ถ้าไม่เคยมีใครคิดจะเปิด port นั้น → ก็ปิดอยู่ตามธรรมชาติ
• ลด attack surface โดย default — ทุก service ที่ไม่ได้ใช้ ปิดอยู่
• บังคับให้คิด — เปิดอะไรต้องมีเหตุผล + approval

ถ้า perimeter firewall + cloud firewall + host firewall ของบริษัทคุณ — default deny ทั้งหมด + มี rule review process — แค่ 2 ข้อนี้ลด attack surface ของ network ลงได้ 70-80% โดยไม่ต้องลงทุน NGFW ใหม่

มุมผู้บริหาร: ถ้าคุณเลือกถามได้แค่คำถามเดียวกับ network team ของบริษัทในปีนี้ — ถามว่า “perimeter firewall + cloud firewall + host firewall ของเรา — default deny ทั้งหมดไหม + รวมมี rule กี่ข้อ + เคย review ครั้งล่าสุดเมื่อไร”. คำตอบที่ดี — “default deny ทุกชั้น + รวม ~200-500 rules + review ทุก 6 เดือน”. คำตอบที่น่ากังวล — “rule 1,500+ ข้อ ไม่ได้ review มา 3 ปี”. ในเคสที่เจอได้ทั่วไป — บริษัทขนาดกลางที่ทำ firewall cleanup ครั้งใหญ่ — ลด rule ลงได้ 40-60% + ค้นเจอ misconfiguration ที่อาจเปิด attack vector หลายจุด — ไม่ต้องซื้อ hardware ใหม่. งานนี้ ROI สูงมาก เพราะใช้แค่ man-hour ของ engineer ที่มีอยู่แล้ว — แต่ผลกระทบทาง security + audit + compliance ทั้งหมดดีขึ้นพร้อมกัน

สิ่งที่ผู้นำต้องจำ#

ข้อแรก — Default Deny คือ control ที่ ROI สูงที่สุดของ network security — ลงทุนต่ำ ผลกระทบสูง

นี่คือคำแนะนำที่ผมอยากให้คุณจำมากที่สุดของ EP นี้ครับ

หลักการ Default Deny — “อะไรที่ไม่ได้ allow ชัดเจน = ห้ามหมด” — เป็น mindset ที่ฟรี ไม่ต้องซื้อ hardware ใหม่. แต่บริษัทไทยจำนวนมาก ยังตั้ง default allow เพราะ “สะดวก” + “ไม่ต้อง troubleshoot” + “ตอนติดตั้งเร่งเปิดให้ใช้งานก่อน”

ลองคิดง่ายๆ — เมืองที่ป้อมยามตั้งกฎว่า — “ใครก็เข้าได้ ยกเว้นคนในรายชื่อ ban” vs “ห้ามเข้า เว้นแต่จะอยู่ในรายชื่อ allow”. 2 กฎนี้ — กฎที่ 1 = ปลอดภัยน้อยกว่ามาก เพราะรายชื่อ ban อัพเดตไม่ทัน + โจรใหม่ที่ไม่อยู่ในรายชื่อก็เข้าได้

ทำไมไม่ทุกบริษัทใช้ default deny — เพราะมัน ทำให้งานเริ่มต้นยากขึ้น. ทุก service ใหม่ต้อง request rule. ทุก rule ต้องผ่าน change management

แต่นั่นแหละ — ความยากนี้คือฟีเจอร์ ไม่ใช่บั๊ก. มันบังคับให้ทุกคนคิดก่อนเปิด

Action plan สำหรับบริษัทไทยขนาดกลาง:

1. Audit firewall ทุก layer — perimeter + DMZ + internal + host + cloud — แต่ละ layer เป็น default deny หรือไม่
2. ถ้ายังเป็น default allow — wave 1: เปลี่ยน internal network → default deny ก่อน (impact ต่ำ); wave 2: cloud workload (1-3 เดือน); wave 3: perimeter (cleanup สุดท้าย)
3. Periodic rule review — กำหนด schedule 6-12 เดือน + ทุก rule ต้องมี business owner ยืนยัน
4. Change management bind กับ firewall — ห้าม engineer เปิด rule เอง — ผ่าน ticket + approval

ข้อสอง — รู้ว่า firewall ของบริษัทคุณเป็น Gen ไหน + ใช้ feature ครบหรือเปล่า — สำคัญกว่า “ซื้อ firewall ใหม่”

ข้อนี้เป็น mindset ที่เห็นในข่าววงการบ่อย — บริษัทไทย โดน sales pitch ของ vendor มาขาย NGFW รุ่นใหม่ราคาหลายล้าน. ซื้อมาแล้ว — เปิดใช้แค่ stateful + ไม่เปิด App-ID + ไม่เปิด SSL inspection + ไม่เปิด IPS — เพราะกลัว break อะไร

ผลลัพธ์ — จ่ายราคา Gen 3 เพื่อใช้ feature ของ Gen 2 = waste investment 60-70%

คำถามที่ดีกว่า “จะซื้อ firewall ใหม่ไหม” คือ:

• “firewall ที่มีอยู่ — เปิด feature อะไรบ้าง”
• “มี monthly report ว่า block อะไรเดือนนี้ไหม”
• “ทีม network ของเรา trained กับ feature ของ firewall ปัจจุบันหรือเปล่า”
• “rule sprawl ของเรา — มี plan cleanup ไหม”

ถ้าตอบคำถามเหล่านี้ได้ดี → ไม่ต้องซื้อใหม่. ถ้าตอบไม่ได้ → ปัญหาจริงคือ process + people ไม่ใช่ technology — ซื้อใหม่ก็ไม่ช่วย

ในเคสที่บริษัทขนาดกลางในไทยลด rule sprawl + tune NGFW ปัจจุบัน — โดยทั่วไป performance + visibility + security posture ดีขึ้น 30-50% โดยไม่ต้องจ่าย CAPEX ใหม่. การลงทุนใน operational excellence ของ firewall ที่มีอยู่ — ROI สูงกว่าซื้อกล่องใหม่หลายเท่า

ลองนึกในใจครับ — ป้อมยามของหมู่บ้านที่คุณดูแล — รุ่นไหน — และทำงานตามที่ควรจะทำหรือเปล่า