ภาพในใจ — 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 สูงกว่าซื้อกล่องใหม่หลายเท่า

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