VPN ทำงานยังไง — ภาพในใจ#

ลองนึกท่อใต้ดินจริงๆ ครับ. เมืองที่มีตึกราชการ — มี ถนนสาธารณะ ข้างบน + มี ท่อใต้ดินลับ ใต้ดิน. ขรก. ที่อยู่บ้านอยากเข้าตึกราชการ — ลงท่อใต้ดินที่บ้าน → เดินในท่อ → ขึ้นมาที่ตึกราชการ. ระหว่างทาง — คนข้างบนถนนมองไม่เห็น + ถ้าใครเจาะท่อจะเจอแค่ความมืด เพราะของข้างในห่อแน่นหนา

VPN ทำแบบนั้นใน Internet:

1. พนักงานเปิด VPN client ที่ laptop (Cisco AnyConnect / FortiClient / WireGuard / OpenVPN)
2. VPN client authenticate กับ VPN gateway ของบริษัท (username + password + MFA — จาก EP.13)
3. หลังจาก authenticate ผ่าน — มีการ negotiate key (ใช้ Diffie-Hellman ที่ผมเล่าใน EP.21)
4. ตั้งแต่จุดนี้ — ทุก packet ที่ออกจาก laptop พนักงานถูก encrypt ด้วย key ที่ negotiate ไว้
5. Packet วิ่งบน Internet สาธารณะ — แต่ใครดักจะเจอแค่ gibberish (ข้อมูลขยะ) — เพราะถอดรหัสไม่ได้
6. ถึง VPN gateway ของบริษัท → ถอดรหัส → ปล่อยเข้า internal network

ผลลัพธ์ — laptop ของพนักงานที่อยู่บ้าน เหมือนต่อสาย LAN เข้าออฟฟิศโดยตรง — แม้จริงๆ จะวิ่งผ่าน Internet ของ 3BB / AIS / True

3 ตระกูลของ VPN — IPsec / SSL VPN / WireGuard#

ในวงการ VPN — มี 3 ตระกูลใหญ่ที่ผู้บริหารควรรู้ชื่อ

ตระกูล 1 — IPsec (Internet Protocol Security) — มาตรฐานเก่าแก่ของวงการ (RFC แรกปี 1995). ทำงานที่ Network Layer (Layer 3) — encrypt ทั้ง packet รวม IP header. แข็งแกร่งมาก — รัฐบาล / ทหาร / ธนาคารใหญ่ใช้กัน. ข้อจำกัด = ตั้งค่ายาก (มี protocol IKE / ESP / AH / Tunnel mode / Transport mode) + มีปัญหาเรื่อง NAT (ต้องใช้ NAT-T workaround). มักใช้ทำ site-to-site VPN ระหว่างสาขา (สำนักงานใหญ่ ↔ สาขาเชียงใหม่)

ตระกูล 2 — SSL VPN / TLS VPN — VPN ที่ขี่บน TLS (ที่ผมเล่าใน EP.24) เลย. ทำงานที่ Application Layer. ข้อดี = ผ่าน firewall ขององค์กรอื่นได้ เพราะใช้ port 443 (port ของ HTTPS) — ที่ทุกองค์กรเปิดให้ทะลุ. ตั้งค่าง่ายกว่า IPsec มาก. ใช้ใน VPN ของพนักงาน work from home เป็นหลัก. ผลิตภัณฑ์ที่ดังในวงการ = Cisco AnyConnect, Fortinet FortiClient, Pulse Secure, GlobalProtect ของ Palo Alto

ตระกูล 3 — WireGuard — VPN ตระกูลใหม่ (เปิดตัว 2016, รวมเข้า Linux kernel ปี 2020). ออกแบบโดย Jason A. Donenfeld. จุดเด่น = code base น้อย (4,000 บรรทัด เทียบกับ OpenVPN 100,000+ บรรทัด — น้อย = ช่องโหว่น้อย) + เร็วกว่า IPsec/OpenVPN หลายเท่า + modern cryptography (ChaCha20 / Curve25519 / BLAKE2 / Poly1305) + ตั้งค่าง่ายมาก. ผลิตภัณฑ์ที่ใช้ WireGuard = Mullvad, NordLynx ของ NordVPN, Tailscale, Cloudflare WARP

Split Tunnel vs Full Tunnel — คำถามที่ทุก CIO ต้องตอบ#

หลังจาก setup VPN เสร็จ — มี policy ใหญ่ ที่ผู้บริหารต้องตัดสินใจ — เมื่อพนักงาน connect VPN เข้าออฟฟิศแล้ว — traffic อื่นๆ ของพนักงาน (Facebook / YouTube / Netflix) วิ่งผ่าน VPN ด้วยไหม?

Full Tunnel — ทุก traffic ของพนักงานวิ่งผ่าน VPN gateway ของบริษัท

• ข้อดี = บริษัท monitor ได้หมด + apply security policy เดียวทั้ง corporate + remote / Block phishing ผ่าน DNS ของบริษัทได้
• ข้อเสีย = bandwidth ของ VPN gateway บริษัทรับหนัก — ตอน COVID หลายบริษัท VPN gateway ล่ม เพราะ traffic Netflix ของพนักงานกินหมด + VPN gateway กลายเป็น single point of failure

Split Tunnel — เฉพาะ traffic เข้า internal app ของบริษัท วิ่งผ่าน VPN — traffic อื่นๆ (Facebook / Netflix) ออกตรงๆ ผ่าน Internet ของบ้าน

• ข้อดี = bandwidth บริษัทเบาขึ้นมาก + user experience ดี (Netflix ไม่ช้า)
• ข้อเสีย = บริษัทไม่เห็น traffic อื่นๆ ของพนักงาน — ถ้าพนักงานโดน phishing ระหว่างใช้ Facebook → endpoint โดน malware → กลับมา connect VPN → malware เข้าออฟฟิศ

ใน scenario ทั่วไปของบริษัทไทย — ก่อน COVID นิยม full tunnel. ช่วง COVID 2020 ทุกคนเปลี่ยนเป็น split tunnel เพราะ VPN gateway รับไม่ไหว. หลัง COVID — เริ่มย้ายไปทาง ZTNA (Zero Trust Network Access) ที่ผมจะเล่าใน EP.37 — เลิกใช้ VPN แบบเก่าทั้งหมด

ข้อจำกัดของ VPN ที่ผู้บริหารต้องเข้าใจ#

VPN ฟังดูเป็น silver bullet — แต่ในวงการ security ปี 2026 — VPN ถูก challenge หนักมาก ด้วย 3 เหตุผล

ข้อจำกัด 1 — Perimeter mindset — VPN สมมุติว่า “ข้างในเชื่อใจ ข้างนอกไม่เชื่อใจ”. พอพนักงานผ่าน VPN เข้ามาแล้ว — ระบบมองว่า trusted — เข้าถึงได้ทุกอย่าง. ปัญหา = ถ้าโจรขโมย VPN credential ของพนักงาน → โจรเข้าได้ทั้งบริษัท. นี่คือ anti-pattern ของยุค Zero Trust ที่ผมเล่าใน EP.17

ข้อจำกัด 2 — Performance — traffic ต้องวิ่งผ่าน VPN gateway → encrypt → decrypt → forward → latency เพิ่ม. ในยุค SaaS (Office 365 / Salesforce / Workday) — การส่ง traffic Office 365 ของพนักงานในเชียงใหม่ → VPN gateway ที่กรุงเทพฯ → ออก Internet → ไป Microsoft ที่สิงคโปร์ → กลับมาทางเดิม = ผิดธรรมชาติของ cloud

ข้อจำกัด 3 — VPN gateway = juicy target — โจรรู้ดีว่า VPN gateway = ประตูเข้าทุกอย่าง. ในข่าวเคยมีหลายเคสที่ VPN appliance vendor (Fortinet / Pulse Secure / Citrix) มี 0-day vulnerability → โจรทั่วโลกแห่กันโจมตี. เคสเด่นในวงการ — CVE-2019-11510 ของ Pulse Secure VPN (path traversal → อ่าน credential ของ user ทุกคนได้) → หลายบริษัทใหญ่โดน ransomware ผ่าน VPN นี้ในปี 2020-2021

มุมผู้บริหาร: VPN ยังจำเป็นในปี 2026 — แต่อย่ามองเป็น solution สุดท้ายของ remote access. คำถามที่ CIO/CISO ต้องตอบให้ได้ — “VPN gateway ของเรามี MFA บังคับทุก account ไหม + อยู่ใน end of support ไหม?” เคสที่บริษัทไทยโดน ransomware ส่วนใหญ่ — VPN ไม่มี MFA หรือ MFA ใช้ SMS ที่ถูก SIM swap ได้. Gartner ประกาศแล้วว่า VPN จะตายภายใน 2025 — เริ่มแผนย้ายไป ZTNA ได้แล้ว

Forward Proxy — พนักงานออกเว็บผ่าน proxy#

ลองนึก scenario นี้ครับ — บริษัทไทยขนาดใหญ่. พนักงาน 5,000 คน. ทุกคนต้องเข้า Internet เพื่อค้นข้อมูล / อ่านข่าว / ใช้ SaaS

ถ้า ไม่มี Forward Proxy — Browser ของพนักงานทุกคน ออก Internet ตรงๆ. ปัญหา:

• บริษัทไม่รู้ว่าใครเข้าเว็บอะไร
• พนักงานเข้าเว็บโป๊ / เว็บ gambling ระหว่างเวลางาน — บริษัทห้ามไม่ได้
• ถ้าพนักงานเข้าเว็บที่มี malware → endpoint โดน infect → ลามใน internal network
• ไม่มี DLP (Data Loss Prevention) — พนักงาน upload เอกสารลับขึ้น Google Drive ส่วนตัว = บริษัทไม่เห็น

ถ้า มี Forward Proxy — Browser ของพนักงานทุกคน ถูกบังคับส่ง request ผ่าน Proxy server ของบริษัท (set ในนโยบาย Group Policy / config ของ Browser). Proxy ทำหน้าที่:

1. ตรวจ URL — block เว็บใน blacklist (โป๊ / gambling / phishing)
2. ตรวจ content — scan ไฟล์ที่ download มีไวรัสไหม
3. บันทึก log — รู้ว่าใครเข้าเว็บอะไร เวลาไหน นานแค่ไหน
4. Cache — ถ้าหลายคนเข้าเว็บเดียวกัน → Proxy เก็บ copy → ส่งจาก cache (ลด bandwidth)
5. TLS Inspection — ถ้าจำเป็น Proxy ถอด TLS ของพนักงาน → ตรวจ content ภายใน → encrypt ใหม่ส่งต่อ (เรื่องนี้มีประเด็น privacy ที่ต้องระวัง)
6. DLP — ตรวจว่ามี บัตรประชาชน / เลขบัญชี / source code ออกไปไหม

ผลิตภัณฑ์ที่ใช้กันในวงการ — Zscaler Internet Access, Cisco Umbrella, Forcepoint Web Security, Squid (open source). ในปี 2026 — Forward Proxy ส่วนใหญ่ย้ายขึ้น cloud เป็น SWG (Secure Web Gateway) แทนการตั้ง appliance ในออฟฟิศ

Reverse Proxy — ลูกค้าจากทั่วโลกเข้าเว็บบริษัทผ่าน proxy#

อีกทิศที่ตรงข้าม — Reverse Proxy — แทนที่จะ เราออกไปข้างนอก — กลายเป็น คนอื่นเข้ามาหาเรา — แต่ ผ่านคนกลาง

ลองนึก scenario นี้ครับ — บริษัท e-commerce ไทย. เว็บ www.shopxxx.co.th. ลูกค้าจากทั่วประเทศ (และต่างประเทศ) เข้าเว็บนี้ทุกวัน

ถ้า ไม่มี Reverse Proxy — ลูกค้าทุกคน connect ตรงไป web server ของบริษัท. ปัญหา:

• IP ของ web server เปิดให้โลกเห็น → โจร scan + โจมตีตรง
• server เดียวรับ load ทั่วประเทศ → ถ้า traffic เยอะ ล่มทันที
• ลูกค้าในเชียงใหม่ ต้อง round-trip มาถึง server ที่กรุงเทพฯ ทุกครั้ง → ช้า
• โดน DDoS = ตายทันที (เรื่องนี้จะเจาะลึกใน EP.31)

ถ้า มี Reverse Proxy — ลูกค้าทุกคน connect ไปที่ Reverse Proxy (มักเป็น CDN = Content Delivery Network — เครือข่ายผู้กระจายเนื้อหา). Reverse Proxy ทำหน้าที่:

1. ซ่อน IP จริงของ web server — โจรเห็นแค่ IP ของ CDN
2. Cache static content — รูป / CSS / JS เก็บที่ edge — ลูกค้าในเชียงใหม่ได้จาก edge ที่เชียงใหม่ ไม่ต้องวิ่งมากรุงเทพฯ
3. Load balance — กระจาย traffic ไปหลาย web server ของบริษัท
4. TLS termination — ถอด TLS ที่ Reverse Proxy → ส่ง plain HTTP ภายใน data center (ลด load ของ web server)
5. WAF — Reverse Proxy ส่วนใหญ่มี WAF built-in (จาก EP.29) — block SQL injection / XSS
6. DDoS protection — ดูดซับ traffic flood ที่ edge (รายละเอียดใน EP.31)
7. Bot management — แยก bot ที่ดี (Google bot) ออกจาก bot ที่ร้าย (scraper / credential stuffing)

ผลิตภัณฑ์ที่ดังที่สุดในวงการ — Cloudflare, Akamai, Amazon CloudFront, Fastly, Imperva. ในไทย ทุกเว็บใหญ่ของธนาคาร / e-commerce / news ใช้ CDN ทั้งหมด — ลูกค้าทั่วไปไม่ทันสังเกตว่ากำลังคุยกับ Cloudflare ก่อนถึง web server ของแบรนด์

Forward vs Reverse — สรุปภาพง่ายๆ#

ในวงการ MITM (Man in the Middle — คนกลางที่ดักฟัง) บางทีถูกใช้ในความหมายลบ — แต่ในความเป็นจริง — Proxy ทุกตัวคือ MITM แบบ legitimate. ความแตกต่าง = คุณรู้ตัวและตั้งเองหรือไม่

มุมผู้บริหาร: บริษัทขนาดกลางที่มีพนักงาน 50+ + เว็บลูกค้า ควรมีทั้ง Forward Proxy/SWG (control + DLP) และ Reverse Proxy/CDN (performance + protection). คำถามที่ CIO ต้องตอบได้ — “ถ้าวันหนึ่ง Cloudflare/Akamai ล่ม — แผน failover ของเราคืออะไร?” เพราะ CDN ใหญ่กลายเป็น single point of failure ของ Internet ทั้งโลก. ถ้าตอบไม่ได้ทันที = ฝากบ้านไว้กับคนอื่น 100% โดยไม่รู้ตัว

Private IP vs Public IP — ทำไมต้องมี 2 ระดับ#

ในโลก IPv4 (ที่ Internet ใช้กันหลัก) — มี IP address ทั้งหมด 4.3 พันล้านตัว (2 ยกกำลัง 32). ฟังดูเยอะ — แต่ในโลกที่มี มือถือ 7 พันล้านเครื่อง + IoT device อีกหลายหมื่นล้าน — IPv4 ไม่พอใช้ มาตั้งแต่ทศวรรษ 2000

วิธีแก้ระยะสั้น = แยก IP เป็น 2 โซน

Private IP (RFC 1918) — IP ที่ใช้ ในเครือข่ายส่วนตัว เท่านั้น — Internet สาธารณะไม่ route ให้

• 10.0.0.0/8 — ใช้ในองค์กรใหญ่
• 172.16.0.0/12 — ใช้ในองค์กรขนาดกลาง
• 192.168.0.0/16 — ใช้ในบ้านทั่วไป

Public IP — IP ที่ใช้ในโลก Internet จริง — โลกทั้งโลกเห็นและ route ถึง

ทุกบ้าน + ทุกบริษัท ใช้ Private IP ภายใน — ออก Internet แสดงเป็น Public IP ตัวเดียว ของ router/firewall

NAT ทำงานยังไง#

ลองนึกภาพ — บ้านคุณมี router. ในบ้านมี laptop ที่ Private IP 192.168.1.10 อยากเข้า google.com

ขั้นตอน:

1. Laptop ส่ง packet — source IP = 192.168.1.10, destination = Google
2. Packet ถึง router — router เก็บ note ในตาราง NAT — “packet นี้มาจาก 192.168.1.10”
3. Router เขียนทับ source IP → กลายเป็น Public IP ของ router (เช่น 49.230.1.50)
4. Packet ออก Internet ไป Google — Google เห็นแค่ 49.230.1.50
5. Google ตอบกลับมาที่ 49.230.1.50
6. Router ดูตาราง NAT — รู้ว่า “packet นี้ต้องส่งกลับให้ 192.168.1.10” — แปลกลับ → ส่งให้ laptop

ที่จริงมีรายละเอียดเพิ่มที่ port — เรียกว่า PAT (Port Address Translation) หรือ NAPT — ใช้ port number เป็น key ในตาราง — ทำให้ 1 Public IP รองรับ อุปกรณ์ Private หลายพันเครื่อง พร้อมกันได้

NAT กับ Security — ของแถมที่ไม่ได้ตั้งใจ#

NAT ออกแบบมาเพื่อ ประหยัด IP — ไม่ใช่เพื่อ security. แต่ผลข้างเคียงคือ:

ของแถมข้อ 1 — โจรเห็นแค่ Public IP เดียว — Private IP ของอุปกรณ์ภายในซ่อนหมด. โจรสแกนจากนอกได้แค่ router — ภายในมองไม่เห็น

ของแถมข้อ 2 — ภายในเริ่ม connection ออกได้ แต่ภายนอกเริ่ม connection เข้าไม่ได้ (ยกเว้นมีตั้ง port forwarding) — เพราะตาราง NAT มี entry เฉพาะของ traffic ที่ออกไป

ของแถมข้อ 3 — ทำ DDoS reflection ยากขึ้น — โจรปลอม source IP ลำบาก เพราะต้องผ่าน NAT (เรื่องนี้จะลึกใน EP.31)

แต่ NAT ไม่ใช่ firewall — ห้ามเข้าใจผิด. NAT แค่ แปล IP — ไม่ได้ ตรวจ traffic. บริษัทที่คิดว่า “มี NAT แล้วไม่ต้องมี firewall” = วงการเรียกว่า NAT myth — อันตรายมาก

ใน IPv6 — ที่มี address มหาศาล (340 undecillion) — ทุกอุปกรณ์มี Public IP จริงได้ — ไม่ต้องใช้ NAT. ในวงการเลยมีคำถาม — “IPv6 → NAT จะตายไหม?” คำตอบในปี 2026 = ยังไม่ตาย เพราะ NAT myth + management habit ยังหนัก

มุมผู้บริหาร: NAT เป็นเรื่อง network engineer — ผู้บริหารแค่จำคำเดียว: NAT ไม่ใช่ firewall. บริษัทที่อ้างว่า “ไม่ต้องมี firewall เพราะมี NAT” = misunderstand เต็มๆ. NAT แค่แปลงที่อยู่ — ไม่ตรวจเนื้อหา ไม่ block traffic ที่อันตราย. ถ้าทีม network ของคุณยังพูดประโยคนี้ — แปลว่ามี gap พื้นฐาน

DNS — สมุดที่อยู่ของ Internet#

DNS (Domain Name System — ระบบชื่อโดเมน) = สมุดที่อยู่ของ Internet ทั้งโลก

หน้าที่ของ DNS = แปล ชื่อที่คนจำได้ (www.bangkokbank.com) → ตัวเลข IP ที่คอมเข้าใจ (203.150.x.x)

ภาพในใจ — ลองนึกว่าคุณอยากโทรหาเพื่อน. คุณจำชื่อเพื่อนได้ — แต่จำเบอร์มือถือไม่ได้. คุณเปิด สมุดโทรศัพท์ (สมัยโบราณ) — เปิดหาชื่อ → ได้เบอร์ → กดเบอร์ → โทร

ใน Internet — คุณคือ Browser. เพื่อนคือ web server ของธนาคาร. ชื่อเพื่อนคือ bangkokbank.com. เบอร์มือถือคือ IP address. สมุดโทรศัพท์คือ DNS

ทุกครั้งที่คุณพิมพ์ชื่อเว็บ — Browser ของคุณ ถาม DNS ก่อนเสมอ ว่า “ชื่อนี้ IP อะไร” — ถึงจะ connect ไปต่อ

5 ขั้นตอนที่เกิดขึ้นเวลาคุณพิมพ์ชื่อเว็บ#

ทุกครั้งที่คุณพิมพ์ www.bangkokbank.com กด Enter — Browser ถามต่อๆ กันไป 5 ขั้น: (1) ถาม Recursive Resolver ของ ISP (3BB/AIS/Cloudflare 1.1.1.1) ก่อน → resolver ไม่รู้ → (2) ถาม root ว่า .com อยู่ไหน → (3) root ชี้ไปที่ TLD .com → (4) .com ชี้ไปที่ authoritative ของ bangkokbank → (5) authoritative ตอบ IP 203.150.x.x → resolver จำไว้แล้วส่งกลับ Browser

ปัญหาใหญ่ — ทุกขั้นตอนนี้ default ไม่มีการเข้ารหัส + ไม่มีการยืนยันตัวตน — ใครก็สามารถ แทรกตอบปลอม ได้ถ้าจังหวะเหมาะ. นี่คือจุดอ่อนที่สำคัญที่สุดของ Internet

DNS Poisoning — ปัญหาที่เป็น single point of failure ของ Internet#

ลองนึกฉาก scenario — โจรอยากให้คุณเข้า ธนาคารปลอม แทน ธนาคารจริง

Phishing แบบเก่า — โจรส่ง email หลอกให้คลิก URL ปลอม (bangkokbank-secure.com แทน bangkokbank.com) — ต้องหลอกตา user

DNS Poisoning — โจรไม่ต้องหลอก user เลย — โจรหลอกระบบ DNS ให้ตอบ IP ผิด. User พิมพ์ bangkokbank.com ถูกทุกตัวอักษร — แต่ DNS resolver ตอบกลับ IP ของ server โจร — user ไม่มีทางรู้ตัว

ผลลัพธ์ — user เข้าเว็บปลอม → ใส่ username/password → โจรได้ → ใช้กับธนาคารจริง

นี่คือเหตุผลที่ DNS เป็น single point of failure ของ Internet ทั้งโลก — ถ้า DNS เพี้ยน — ทุก traffic ของ user ไปผิดที่ตั้งแต่ขั้นแรก — ไม่มี security อื่นช่วยได้ (firewall / IDS / antivirus ก็ป้องกันไม่ได้ เพราะ user เข้าเว็บที่ “ดูถูกต้อง” ทุกอย่าง)

4 เทคโนโลยีของ DNS Security#

วงการตอบสนองภัยนี้ด้วย 3 เทคโนโลยีหลัก — ผู้บริหารควรรู้ชื่อทั้ง 3

เทคโนโลยี 1 — DNSSEC (DNS Security Extensions) — เซ็นชื่อ DNS record ด้วย digital signature (concept เดียวกับ EP.21 + EP.23)

วิธีทำงาน:

• Authoritative server ของ bangkokbank.com มี private key
• ทุก DNS record ถูก sign ด้วย private key
• Resolver มี public key ของ TLD .com
• ตอนได้ record มา → resolver ตรวจลายเซ็น → ถ้าผ่าน = ของแท้

ปัญหา — DNSSEC เปิดตัวปี 1997 — adoption rate ช้ามาก เพราะตั้งค่ายาก + ไม่มี incentive ทางธุรกิจ. ปัจจุบัน ประมาณ 5% ของ domain ทั่วโลก sign ด้วย DNSSEC. .gov ของอเมริกาบังคับ. .co.th ของไทย ยังไม่บังคับ

เทคโนโลยี 2 — DoH / DoT (DNS over HTTPS / TLS) — encrypt DNS query

ใน DNS เดิม — query วิ่งบน UDP port 53 แบบ plain text — ใครดักก็เห็น user ถามหา domain อะไร. ISP / รัฐบาล / โจรใน WiFi สาธารณะ เห็นได้หมด

2 เทคโนโลยีนี้แก้ปัญหาเดียวกัน — encrypt DNS — ต่างกันแค่ port: DoH ใช้ port 443 (เหมือน HTTPS — ผ่าน firewall ได้ทุกที่), DoT ใช้ port 853 (dedicated — แต่บาง firewall block). Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9 ให้บริการฟรี. ผลกระทบใหญ่ — ISP เห็น traffic encrypted เฉยๆ ไม่เห็น domain ที่ user ค้น — เปลี่ยนเกม privacy ของ Internet ทั้งโลก

เทคโนโลยี 3 — DNS Sinkholing — เทคนิคของ defender ใช้ DNS ป้องกันบริษัทตัวเอง

วิธีทำงาน:

• บริษัทมี internal DNS resolver
• มี list ของ domain ที่ malware ชอบใช้ (จาก threat intel feed)
• เวลา endpoint ใน network ถาม domain ใน list → DNS resolver ตอบกลับ IP ปลอม (เช่น 0.0.0.0 หรือ honeypot ของบริษัท)
• ผลลัพธ์ — malware ที่ติดในเครื่องพนักงาน — call back ไป C&C ของโจรไม่ได้

DNS Sinkholing เป็นเครื่องมือที่ทรงพลังมาก — ลงทุนน้อย — ประสิทธิภาพสูง. ผลิตภัณฑ์ที่ใช้ — Cisco Umbrella, Quad9 (ฟรี — block known malware domain), Pi-hole (open source, ใช้ในบ้าน)

มุมผู้บริหาร: DNS เป็นเรื่องที่ผู้บริหารไม่ค่อยเห็นในงบ IT เพราะ “ทำงานเงียบๆ” — แต่เป็น single point of failure ที่ใหญ่ที่สุดของ Internet. quick win ที่ ROI สูงที่สุด — ลงทุน DNS filtering ระดับองค์กร (เดือนละไม่ถึง 50,000 บาท) เพราะ malware ส่วนใหญ่ต้อง resolve C&C domain ก่อนทำงาน. บริษัทไทยที่ลงตัวนี้ลด ransomware incident ได้ 60%+

Kaminsky 2008 — เคสที่เปลี่ยน Internet ทั้งโลก#

ในเดือนกุมภาพันธ์ 2008 — Dan Kaminsky นักวิจัย security คนหนึ่งของ IOActive — กำลังนั่งทำงานทั่วไป — บังเอิญค้นพบ vulnerability ใน DNS

ในความเป็นจริง — DNS cache poisoning ไม่ใช่เรื่องใหม่ — มีคนรู้มาตั้งแต่ปี 1990s. ใช้ดักช่องว่างที่ DNS resolver เก็บ cache → ส่ง record ปลอมก่อน authoritative ตอบกลับ → resolver เก็บ cache ปลอม → user ต่อๆ มาทั้งหมดถูกหลอก

แต่ในยุค 2008 — มี มาตรการป้องกัน หลายอย่าง — โจรต้องเดา Transaction ID (16-bit) + เดาเวลาที่ resolver query — ทำให้สำเร็จได้ยาก. ในทางทฤษฎี — โจรอาจต้องส่ง response ปลอม 65,000 ตัว ในจังหวะเดียว — ส่วนใหญ่หา window ไม่เจอ. อายุของ cache (TTL) ก็ช่วย — ถ้าหลอกไม่ทันใน window แรก ต้องรอ TTL หมด

Kaminsky พบ trick ใหม่ — แทนที่จะหลอก www.bangkokbank.com ตรงๆ — เขาบังคับให้ resolver query subdomain ที่ไม่มีอยู่จริง เช่น aaa.bangkokbank.com, aab.bangkokbank.com, aac.bangkokbank.com… ทีละล้านตัว. resolver ต้อง query หา authoritative ทุกครั้ง — เปิด window ใหม่ตลอด. โจรส่ง response ปลอมที่ ฉีก authoritative ของ bangkokbank.com ทั้ง zone — ไม่ใช่แค่ 1 record

ผลลัพธ์ — โจร poison cache ของ resolver ใหญ่ๆ ทั่วโลกได้ภายใน 10 วินาที. ทุก user ที่ใช้ resolver นั้น — เข้าเว็บไหนก็ไปที่โจร

ถ้า Kaminsky เปิดเผยบทความ — Internet ทั้งโลกจะถูกหลอกในวันเดียว

สิ่งที่ Kaminsky ทำต่อ — เป็น case study ของวงการ:

1. เก็บความลับ 5 เดือน — ไม่บอกใคร ไม่เขียน blog
2. เรียก secret meeting ที่ Microsoft campus ในเดือนมีนาคม 2008 — มี vendor DNS ทั่วโลกร่วม — Microsoft / Cisco / Internet Systems Consortium (BIND) / Nominum / OpenDNS / ISC
3. ร่วมกัน design patch — แก้ปัญหาโดยเพิ่ม randomization ของ source port (เพิ่ม 16-bit ของ port + 16-bit ของ TXID = 32-bit ที่ต้องเดา) — ทำให้โจรเดายากขึ้นหลายล้านเท่า
4. ทุก vendor ปล่อย patch พร้อมกัน ในวันที่ 8 กรกฎาคม 2008 — เรียกว่า Patch Tuesday
5. Kaminsky เปิดเผย detail ที่งาน Black Hat USA 2008 ในเดือนสิงหาคม — หลัง patch ถูก deploy แล้ว

นี่คือ กรณีที่ responsible disclosure ใช้ในระดับโลก — Kaminsky ได้รับการยกย่องเป็น hero ของ Internet. แสดงให้เห็นว่า DNS เปราะบางแค่ไหน — และ community ตอบสนองได้ ถ้าทำเป็นทีม

บทเรียนของ Kaminsky 2008:

• DNS ที่ออกแบบในยุค 1980s — ไม่ได้คิดเรื่อง adversarial — ปัจจุบันเปราะบาง
• DNSSEC ที่ออกแบบมาตั้งแต่ 1997 — ปัจจุบันยังไม่ได้ adoption ทั่วโลก (5% adoption ในปี 2026)
• Source port randomization ที่ patch ในปี 2008 = mitigation ไม่ใช่ solution — solution จริงคือ DNSSEC + DoH

(หมายเหตุของวงการ — Dan Kaminsky เสียชีวิตในปี 2021 อายุ 42 ปี — วงการ security ทั้งโลกรำลึกถึงเขาในฐานะคนที่ช่วย Internet ไว้รอบหนึ่ง)

DNSpionage 2018 — DNS hijacking ระดับชาติ#

อีกเคสในวงการ — DNSpionage (2018-2019) — campaign ที่ตรวจพบโดย Cisco Talos และ FireEye

ในเคสนี้ — โจร (เชื่อว่าเป็น APT ของอิหร่าน) — ไม่ poison DNS resolver แบบ Kaminsky — แทนที่จะหลอก resolver — เข้ายึด domain registrar account ของเหยื่อตรงๆ

วิธีทำงาน:

1. โจร phish credential ของ admin ที่จัดการ DNS ของรัฐบาลต่างๆ ในตะวันออกกลาง + ยุโรป + อเมริกาเหนือ
2. เข้า admin panel ที่ registrar (GoDaddy / Network Solutions / etc.) → เปลี่ยน NS record (Name Server) ของ domain เหยื่อ → ชี้ไปที่ name server ของโจร
3. ตอนนี้ โจรควบคุม DNS ของเหยื่อทั้งหมด — ตอบ IP อะไรก็ได้
4. โจรชี้ traffic ของเหยื่อ → server proxy ของโจร → ขโมย credential + ยึด email + ดักข้อมูล
5. โจรยังได้ TLS certificate ของ domain เหยื่อ จาก Let’s Encrypt (เพราะคุม DNS = ผ่าน domain validation)

บทเรียนของ DNSpionage:

• DNS = single point of failure ไม่ใช่แค่ที่ resolver — แต่ที่ registrar / authoritative ของเหยื่อ ด้วย
• การ secure DNS account ของบริษัท ที่ registrar (GoDaddy / Cloudflare Registrar / TH NIC) สำคัญเทียบเท่ากับ root admin ของระบบ
• บังคับ MFA + Registrar Lock + DNSSEC ที่ registrar = control พื้นฐานที่ทุกบริษัทควรมี

ในข่าวเคยมี — บริษัทไทยขนาดใหญ่บางแห่ง — domain ของบริษัท ลงทะเบียนใต้ชื่อพนักงาน IT คนเดียว ที่ไม่ได้อยู่บริษัทแล้ว — ไม่มี MFA — ไม่มี company recovery. นี่เป็น time bomb ของ governance ที่ผู้บริหารต้อง audit

DGA — Domain Generation Algorithm: เกมไล่ตามของ Antivirus#

เรื่องสุดท้ายที่ผู้บริหารควรรู้ — DGA (Domain Generation Algorithm — อัลกอริทึมสร้างชื่อโดเมน)

ลองนึก scenario นี้ — โจรสร้าง malware + ทำให้ติดในเครื่องเหยื่อทั่วโลก. Malware ต้อง call กลับ C&C server ของโจรเพื่อรับคำสั่ง + ส่ง data กลับ

ปัญหาของโจรในยุคเก่า — โจร hardcode IP / domain ของ C&C ในตัว malware. ทันทีที่ antivirus เจอ malware → analyze → ได้ domain ของ C&C → แจ้ง registrar + ISP → block domain นั้น → malware ทั้ง army ตายในวันเดียว

วิธีแก้ของโจร = DGA

DGA = malware มี algorithm สุ่มสร้าง domain ใหม่ทุกชั่วโมง / ทุกวัน — เช่น

1
xkjzqpoiuew.com    (ของวันที่ 13 พ.ค.)
2
mzqxpoiuy.net      (ของวันที่ 14 พ.ค.)
3
kpoiuqxzm.org      (ของวันที่ 15 พ.ค.)

โดยใช้ seed = วันที่ปัจจุบัน + secret ที่ malware รู้ + โจรรู้

ผลลัพธ์ — ทุกวัน malware ลอง resolve domain ใหม่หลายพันตัว. ใน 1 ปี อาจมี 365,000+ domain ที่ malware ลอง. โจรลงทะเบียนแค่ตัวเดียวต่อวัน ก็พอ. Antivirus block domain ตามไม่ทัน

เคสที่ดังที่สุดในวงการ — Conficker worm (2008-2009) — สร้าง domain ใหม่ 500 ตัวต่อวัน — Microsoft + ICANN + ทีมวิจัยทั่วโลก ต้องร่วมกัน pre-register domain ทั้ง 500 ตัวต่อวัน เพื่อ block

วิธีรับมือ DGA ในปัจจุบัน:

• DGA detection — ML model ที่ดู pattern ของ domain (DGA domain มัก “ดูสุ่ม” — ไม่มี vowel pattern ของภาษาคน) — ติดใน Firewall NGFW / EDR / DNS resolver
• DNS sinkholing ของ DGA cluster — block domain pattern แบบ wholesale
• Threat intel feed ที่ share รายชื่อ DGA family — Cisco Umbrella / Akamai / Cloudflare ใช้

บทเรียนของ DGA — block-list ของ domain ไม่พอ ในยุคนี้ — ต้องมี detection ที่ pattern level + DNS visibility ระดับ network

มุมผู้บริหาร: 3 เคส Kaminsky / DNSpionage / DGA มี theme เดียว — DNS = backbone ที่โจรชอบโจมตี เพราะ payoff สูงและ visibility ต่ำ. คำถามที่ผู้บริหารต้องถามทันที — “domain ของบริษัทที่ registrar — มี MFA + Registrar Lock แล้วหรือยัง?” ถ้าโจรเข้า registrar account ได้ — DNS เพี้ยน 1 วัน = ลูกค้าเข้าเว็บไม่ได้ + email บริษัทไม่ทำงาน + ภาพแบรนด์เสียหายระยะยาว

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

ข้อแรก — VPN ในปี 2026 ยังจำเป็น แต่ไม่ใช่ silver bullet — เริ่มวางแผน ZTNA ตั้งแต่วันนี้

นี่คือคำแนะนำที่ผมอยากให้คุณจำที่สุดของ EP นี้ครับ. VPN ออกแบบมาตั้งแต่ทศวรรษ 1990s — บน assumption ของ perimeter security — “ข้างในเชื่อใจ ข้างนอกไม่เชื่อใจ”. ในยุค Cloud + SaaS + Remote work + BYOD — assumption นี้ไม่จริง

ในเคสที่ออกข่าวบ่อย — บริษัทไทยขนาดใหญ่หลายแห่ง ในช่วงปี 2020-2024 — โดน ransomware ผ่าน VPN credential ที่ถูกขโมย — โจรเข้า VPN → ภายใน trusted ทุกอย่าง → เคลื่อนที่อย่างอิสระ → encrypt ทั้งบริษัท

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

1. MFA บังคับที่ VPN gateway ทันที — ห้ามใช้ password อย่างเดียว — ห้ามใช้ SMS-based MFA (SIM swap risk) — ใช้ authenticator app หรือ FIDO2 key เป็นหลัก
2. Patch VPN appliance ทันที ที่ vendor ปล่อย — VPN vulnerability เป็นช่องที่โจรชอบโจมตี
3. Segment internal network หลัง VPN (จาก EP.28) — VPN ไม่ใช่บัตรผ่านเข้าทุกอย่าง — แต่เป็นแค่ door
4. Plan ZTNA pilot ใน 12-18 เดือนข้างหน้า — เริ่มจาก app ที่สำคัญที่สุด (ERP / HR / Finance) — ค่อย migrate ทั้งบริษัทใน 2-3 ปี

ข้อสอง — DNS เป็น single point of failure ที่ผู้บริหารส่วนใหญ่มองข้าม — ต้อง audit + protect ตั้งแต่ระดับ registrar

ข้อนี้สำคัญมากครับ. ทุก traffic ของ Internet ต้องผ่าน DNS — ก่อน firewall / IDS / WAF จะมีโอกาสตรวจ. ถ้า DNS เพี้ยน — security อื่นทั้งหมดของบริษัทช่วยไม่ได้

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

1. Audit ใครเป็นเจ้าของ domain ของบริษัทที่ registrar — ห้ามใช้ชื่อพนักงาน IT คนเดียว — ใช้ company account + multi-admin + recovery email ของบริษัท + MFA บังคับ + Registrar Lock (ป้องกัน domain transfer)
2. ใช้ DNS resolver ที่มี security built-in — แทน DNS ของ ISP ทั่วไป — เปลี่ยนเป็น Cisco Umbrella (มีค่าใช้จ่าย — block known malicious domain) หรือ Quad9 (ฟรี — community-driven) สำหรับ corporate
3. DNS log + monitor — เก็บ DNS query ของทุก endpoint — analyze หา anomaly (domain แปลกๆ / DGA pattern / volume สูงผิดปกติ)
4. DNSSEC ของ domain บริษัท — เปิดที่ registrar (Cloudflare Registrar / GoDaddy ส่วนใหญ่รองรับ) — ป้องกัน cache poisoning ของ resolver ทั่วโลก
5. มี secondary DNS provider — ถ้า primary ล่ม / โดน DDoS → secondary มาแทนทันที (เคส Dyn 2016 ที่จะเล่าใน EP.31 — บริษัทใหญ่ที่มี Dyn เป็น sole DNS provider ทุกราย down พร้อมกัน)

5 ข้อนี้ — ในงบประมาณบริษัทขนาดกลางในไทย — รวมประมาณ 100,000-500,000 บาท/ปี — แต่ลด attack surface ของ DNS ลงได้กว่า 80%. ROI สูงมากเทียบกับการลงทุนใน firewall ราคาแพง