DDoS แต่ละแบบต่างกันอย่างไร และควรหยุดที่ชั้นไหน

Firewall กัน DDoS ได้ไหม คำตอบขึ้นกับว่าโดนแบบไหนครับ DDoS บางแบบทำให้ลิงก์ internet เต็มตั้งแต่ก่อน packet จะมาถึง firewall บางแบบทำให้ตาราง connection ของเครื่องเต็ม และบางแบบส่ง request ที่ถูกต้องตาม protocol ทุกอย่างเข้าไปจนแอปทำงานไม่ทัน แต่ละแบบจึงต้องหยุดคนละจุด

บทความนี้อิงการแบ่งสามแบบของ CISA, FBI และ MS-ISAC ใน Understanding and Responding to Distributed Denial-of-Service Attacks (มีนาคม 2567) และใช้ RFC กับ advisory ต้นทางอธิบายกลไกของแต่ละแบบ

                ISP/scrub       firewall       WAF              
                    ┆               ┆           ┆       ┌──────┐
                    ┆               ┆           ┆       │server│
 UDP :123 replies   ┆               ┆           ┆       │      │
 ●≈─────≈─≈─≈──────≈✕───────────────────────────────────│      │
                    ┆               ┆           ┆       │      │
 volumetric: fills the link         ┆           ┆       │      │
                    ┆               ┆           ┆       │      │
 SYN, never ACK     ┆               ┆           ┆       │      │
 ──────s───s─────s───s─────s──s─────✕───────────────────│      │
                    ┆               ┆           ┆       │      │
 protocol: fills the SYN backlog    ┆           ┆       │      │
                    ┆               ┆           ┆       │      │
 GET /login x1000   ┆               ┆           ┆       │      │
 ─g─g────────────gg───────g──────────────────g──✕───────│      │
                    ┆               ┆           ┆       │   ●  │
 application: fills app CPU         ┆           ┆       └──────┘
 drop each flood before the resource it fills                   

DDoS ต่างจาก DoS อย่างไร

ต่างกันที่จำนวนต้นทางครับ CISA นิยาม DoS ว่าใช้ต้นทางเดียว หรือคอมพิวเตอร์ไม่กี่เครื่อง ส่วน DDoS ใช้หลายต้นทาง มักเป็น botnet คือเครื่องที่ถูกยึดหลายเครื่องที่ถูกสั่งให้ส่ง traffic พร้อมกัน

เป้าหมายของทั้งสองแบบเหมือนกัน คือทำให้ระบบใช้งานไม่ได้ แต่ DDoS สร้าง traffic ได้มากกว่ามาก และเพราะ traffic มาจาก IP จำนวนมาก CISA จึงระบุว่า DDoS trace และบล็อก IP ต้นทางได้ยาก ยิ่งถ้าใช้ IP spoofing ร่วมด้วย

DDoS แบ่งเป็นกี่แบบ

CISA แบ่งเป็นสามแบบ (CISA, 2567):

CISA เขียนไว้ด้วยว่าสามแบบนี้ไม่ได้แยกขาดจากกัน ผู้โจมตีใช้หลายแบบในครั้งเดียวได้

Volumetric attack ทำงานอย่างไร

Volumetric attack ส่ง traffic เข้ามามากกว่าที่ลิงก์หรือระบบรับไหว เป้าหมายคือทำให้เครือข่ายอิ่มตัว หรือใช้ทรัพยากรของเป้าหมายจนหมด จน request ปกติเข้าไม่ได้

สิ่งที่ต้องเข้าใจคือ ถ้าลิงก์จาก ISP มาที่องค์กรมีขนาด 1 Gbps แล้ว traffic ที่วิ่งมามีมากกว่านั้น ส่วนที่เกินจะถูกทิ้งตั้งแต่ฝั่ง ISP ก่อนถึงอุปกรณ์ของเรา (ตัวเลข 1 Gbps เป็นตัวอย่าง) firewall ที่อยู่หลังลิงก์นั้นจะ drop packet ได้ทุกตัวที่ผ่านมาถึง แต่ทำให้ลิงก์ว่างขึ้นไม่ได้ เพราะ packet ใช้ bandwidth ไปแล้วตั้งแต่ก่อนมาถึง

วิธีทำ volumetric attack ที่พบบ่อยคือ reflection กับ amplification ซึ่งอธิบายในหัวข้อถัดไปครับ

Reflection และ amplification คืออะไร

Reflection คือการส่ง request ไปที่ server ของคนอื่นโดยปลอม IP ต้นทางเป็น IP ของเหยื่อ server จึงตอบกลับไปหาเหยื่อแทน Amplification คือการเลือก request ที่ทำให้ได้คำตอบใหญ่กว่า request หลายเท่า เมื่อใช้ร่วมกัน traffic ที่ผู้โจมตีส่งออกไปน้อย ๆ จะกลายเป็น traffic ที่ใหญ่มากที่ปลายทาง

กลไกนี้ใช้ได้กับ UDP เพราะ UDP เป็น protocol แบบไม่มี connection และไม่ตรวจ IP ต้นทาง (CISA Alert TA14-017A) ลองดู packet สมมติหนึ่งตัว IP ทั้งหมดอยู่ในช่วงที่ RFC 5737 สงวนไว้สำหรับเอกสาร:

ผู้โจมตีส่ง:   src 203.0.113.10:443  ->  dst 198.51.100.7:123   UDP  NTP request   (src ปลอมเป็น IP ของเหยื่อ)
NTP server ตอบ: src 198.51.100.7:123  ->  dst 203.0.113.10:443  UDP  คำตอบขนาดใหญ่   (ไปหาเหยื่อ ไม่ใช่ผู้โจมตี)

ขนาดที่ขยายได้วัดเป็น Bandwidth Amplification Factor (BAF) คือจำนวนไบต์ของ UDP payload ที่ server ตอบ เทียบกับจำนวนไบต์ของ payload ใน request ค่าบางส่วนในตารางของ TA14-017A:

ถ้าคิดตามนิยาม request ที่มี payload 50 ไบต์ไปที่ NTP server ที่มี BAF 556.9 จะได้คำตอบประมาณ 27,845 ไบต์ไปที่เหยื่อ (เลข 50 ไบต์เป็นตัวอย่างสำหรับคำนวณ) MITRE ATT&CK จัดเทคนิคนี้ไว้เป็น T1498.002 Reflection Amplification และเรียก server ที่ถูกใช้ว่า reflector

SYN flood ทำให้ server รับ connection ใหม่ไม่ได้อย่างไร

SYN flood ส่ง SYN จำนวนมากที่ไม่มีวันตอบ ACK กลับ จน backlog ของ connection ที่เปิดค้างครึ่งทางเต็ม แล้ว connection ใหม่ที่ถูกต้องเข้าไม่ได้ RFC 4987 อธิบายว่าการโจมตีนี้ไม่ได้พยายามทำให้เครือข่ายหรือหน่วยความจำเต็ม แต่พยายามทำให้ backlog ของ half-open connection บน port นั้นเต็ม

ลำดับที่เกิดขึ้นบน server:

client (IP ปลอม)                  server (port 443, LISTEN)
SYN  ---------------------------> เปลี่ยนเป็น SYN-RECEIVED และจอง TCB หนึ่งก้อน
     <--------------------------- SYN-ACK  (ส่งไป IP ปลอม ไม่มีใครตอบ)
     (ไม่มี ACK กลับมา)             TCB ค้างใน backlog จนหมดเวลา

ตามที่ RFC 4987 เล่าไว้ backlog เริ่มต้นของระบบทั่วไปมีตั้งแต่ราวครึ่งโหลถึงหลายสิบ และตัวจับเวลาที่คืน TCB อาจตั้งไว้ที่ 75 วินาที ผู้โจมตีจึงต้องส่ง SYN ให้เร็วกว่าที่ระบบคืนพื้นที่เท่านั้น RFC ยังระบุว่าการโจมตีนี้ไม่กระทบ connection ขาออก และ connection ที่ตั้งไว้แล้ว กระทบเฉพาะ connection ใหม่ที่จะเข้ามาที่ port นั้น

ฝั่งป้องกัน RFC 4987 ประเมินว่า SYN cache และ SYN cookies ดูจะเป็นสองวิธีเดียวที่ใช้ได้จริง SYN cookies ไม่จองสถานะเลยตอนรับ SYN แต่เข้ารหัสสถานะที่จำเป็นไว้ใน sequence number ของ SYN-ACK แล้วสร้างกลับจาก ACK ที่ตอบมา บน Linux ค่า net.ipv4.tcp_syncookies มีค่าเริ่มต้นเป็น 1 คือส่ง syncookies เมื่อ syn backlog ของ socket ล้น ส่วน firewall ก็ช่วยได้ โดย RFC 4987 อธิบายวิธีย้ายขั้นตอนตั้ง connection ไปให้ firewall ที่คัดกรองการเชื่อมต่อทำแทน (หัวข้อ 3.8)

CISA จัด SYN flood ไว้ที่ Layer 4 ใน DDoS Quick Guide ร่วมกับ ICMP flood ที่ Layer 3 ซึ่งแนะนำให้ rate-limit ICMP

Application-layer attack ต่างจากสองแบบแรกอย่างไร

Application-layer attack ส่ง request ที่ถูกต้องตาม protocol แต่มีจำนวนมาก หรือเลือก request ที่ทำให้แอปทำงานหนัก จน CPU หรือแอปรับไม่ไหว CISA อธิบายว่าแบบนี้ไม่ได้ทำให้เครือข่ายหรือทรัพยากรระบบเต็ม แต่ใช้จุดอ่อนของแอปที่เป็นเป้าหมาย

ตัวอย่างใน DDoS Quick Guide คือ HTTP GET flood และ HTTP POST flood เช่นการส่ง form login หรือ upload ซ้ำ ๆ guide ฉบับเดียวกันระบุว่า HTTPS GET flood และ HTTPS POST flood ต้องถอดรหัสก่อนจึงจะตรวจและหยุดได้ อุปกรณ์ที่ไม่ได้ถอดรหัสจะเห็นแค่ TLS connection จำนวนมาก ไม่เห็นว่าข้างในเป็น request อะไร

อีกตัวอย่างคือ HTTP/2 Rapid Reset (CVE-2023-44487) ซึ่ง CISA ระบุว่าถูกใช้โจมตีจริงตั้งแต่สิงหาคมถึงตุลาคม 2566 Google อธิบายว่า client ส่ง request แล้วส่ง RST_STREAM ยกเลิกทันที server เริ่มทำงานกับ request ไปแล้ว แต่ stream ที่ถูกยกเลิกไม่นับในเพดาน stream พร้อมกัน ผู้โจมตีจึงไม่เคยเกินเพดานจำนวน stream ที่เปิดพร้อมกัน ทั้งที่ส่ง request ไม่หยุด Google แนะนำให้ปิดทั้ง TCP connection เมื่อเจอการใช้ผิดแบบนี้ เพราะการบล็อกทีละ request ไม่พอ และให้แพตช์ HTTP/2 implementation

แต่ละแบบควรหยุดที่ชั้นไหน

หยุดก่อนถึงทรัพยากรที่แบบนั้นทำให้เต็มครับ สรุปจากเอกสารของ CISA และ RFC 4987:

ข้อควรระวังเรื่อง blackholing คือ DDoS Quick Guide ระบุว่าวิธีนี้ทำให้เว็บไซต์นั้นเข้าไม่ได้เลยสำหรับทุก traffic ทั้ง traffic โจมตีและ traffic ของผู้ใช้จริง ISP ใช้เพื่อปกป้องลูกค้ารายอื่นในเครือข่าย ผลคือการโจมตีสำเร็จในมุมของเว็บนั้น แต่ไม่ลามไปที่อื่น

ความเห็นของผมคือ แผนรับ DDoS ที่ใช้ได้ต้องมีครบทั้งสามชั้น และต้องคุยกับ ISP หรือผู้ให้บริการ mitigation ไว้ก่อนวันที่โดนจริง เพราะ volumetric attack แก้จากในองค์กรอย่างเดียวไม่ได้

ถ้ากำลังโดนอยู่ ควรทำอะไร

เปิด incident response plan แล้วแจ้ง ISP หรือผู้ให้บริการ hosting ทันที ลำดับที่ CISA แนะนำมีดังนี้ (CISA):

1. ยืนยันว่าเป็น DDoS จริงด้วย network monitoring และ traffic analysis
2. เปิดใช้ incident response plan
3. แจ้ง ISP หรือ hosting provider
4. เก็บหลักฐาน: เวลา, IP, packet capture และ log
5. กรอง traffic ที่ firewall หรือ IPS ด้วย rate limit หรือ ACL
6. เปิด DDoS mitigation service ถ้ามี
7. เพิ่ม bandwidth และทรัพยากรถ้าทำได้
8. ใช้ CDN

ข้อแนะนำเพิ่มที่ guide ยกมาจาก MS-ISAC มีประโยชน์มากกับ reflection คือ ให้ส่ง IP ที่โจมตีให้ ISP, จำไว้ว่า reflection attack มักมาจาก public server ที่เป็นเครื่องให้บริการจริง และขอให้ ISP กรองตาม port และขนาด packet ข้อกลางสำคัญครับ เพราะ IP ที่เห็นใน log ตอนโดน reflection คือ DNS หรือ NTP server ของคนอื่น การบล็อกถาวรอาจตัดบริการที่เราใช้อยู่ด้วย

องค์กรเราจะไม่เป็นต้นทางของ reflection ได้อย่างไร

ปิด UDP service ที่ไม่ได้ใช้ และไม่ปล่อย packet ที่มี IP ต้นทางไม่ใช่ของเราออกจากเครือข่าย TA14-017A แนะนำให้ปิดหรือถอด service ที่ไม่ต้องการ หรือไม่ให้เข้าถึง service ภายในจาก internet อัปเดตซอฟต์แวร์และตั้งค่าเพื่อจำกัดการใช้ผิด เช่น DNS response rate limit และทำ ingress filtering ตาม BCP 38

BCP 38 คือ RFC 2827 (พฤษภาคม 2543) ตัวอย่างใน RFC คือ router ฝั่ง ISP ที่ยอมให้ผ่านเฉพาะ traffic ที่มี IP ต้นทางอยู่ใน prefix 204.69.207.0/24 ซึ่งเป็น prefix ที่กำหนดให้เครือข่ายฝั่งนั้น packet ที่ IP ต้นทางอยู่นอก prefix จะถูกทิ้ง ถ้าทุกเครือข่ายทำแบบนี้ packet ที่ปลอม IP ต้นทางจะออกจากเครือข่ายต้นทางไม่ได้ ซึ่งเป็นเงื่อนไขที่ reflection ต้องใช้ ในหน้า RFC 4987 เองก็เขียนว่า filtering แบบนี้ได้ผลเต็มที่ แต่เครื่องปลายทางไม่ควรพึ่งมันอย่างเดียว เพราะไม่มีอะไรรับประกันว่าทุกเครือข่ายจะทำ

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

• CISA, FBI, MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks (มีนาคม 2567)
• CISA: DDoS Quick Guide (ตุลาคม 2563)
• CISA Alert TA14-017A: UDP-Based Amplification Attacks
• RFC 4987: TCP SYN Flooding Attacks and Common Mitigations
• RFC 2827 (BCP 38): Network Ingress Filtering
• RFC 5737: IPv4 Address Blocks Reserved for Documentation
• Linux kernel documentation: IP Sysctl
• MITRE ATT&CK v18: Reflection Amplification (T1498.002)
• CISA: HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487
• Google Cloud: How it works, the novel HTTP/2 "Rapid Reset" DDoS attack