จากฝันร้ายในคืนวันศุกร์: เมื่อระบบโดนถล่มด้วย DDoS จนล่มไม่เป็นท่า

Photo by panumas nikhomkhai on Pexels

บ่ายวันศุกร์ที่ควรจะเป็นช่วงเวลาผ่อนคลายของทีมพัฒนา กลับกลายเป็นจุดเริ่มต้นของมหากาพย์การกู้ระบบที่ผมไม่มีวันลืม ในฐานะ System Engineer ที่ดูแลระบบ E-commerce ขนาดกลางที่มีทราฟฟิกเข้ามาเรื่อยๆ จู่ๆ หน้าจอ Monitoring ของเราก็เปลี่ยนเป็นสีแดงเถือก ค่า CPU Usage พุ่งทะยานแตะ 100% ภายในเวลาไม่ถึง 3 นาที พร้อมกับการแจ้งเตือนจากระบบว่าผู้ใช้งานทั่วไปไม่สามารถเข้าถึงเว็บไซต์ได้เลย สิ่งแรกที่แวบเข้ามาในหัวคือ “เราโดนของเข้าให้แล้ว”

เมื่อผมรีบ SSH เข้าไปตรวจสอบที่เซิร์ฟเวอร์หลัก สิ่งที่พบคือการเชื่อมต่อนับหมื่นรายการที่ค้างอยู่ในสถานะ SYN_RECV ซึ่งเป็นสัญญาณชัดเจนของ SYN Flood Attack ซึ่งเป็นหนึ่งในรูปแบบการโจมตีแบบ Distributed Denial of Service (DDoS) ที่คลาสสิกแต่ทำลายล้างสูง ทราฟฟิกมหาศาลจากไอพีแปลกปลอมทั่วโลกกำลังรุมกระหน่ำพอร์ต 80 และ 443 ของเราจนแบนด์วิดท์เต็มเหยียดและหน่วยความจำของเซิร์ฟเวอร์หมดลงในพริบตา

ความผิดพลาดครั้งใหญ่ที่สุดในตอนนั้นคือ เราพึ่งพาเพียงแค่ค่า Default ของระบบปฏิบัติการและไม่ได้ตั้งค่า Firewall ให้รัดกุมพอสำหรับการรับมือกับการโจมตีในระดับแอปพลิเคชันและเน็ตเวิร์ก บทเรียนราคาแพงในคืนนั้นที่ต้องใช้เวลาเกือบ 10 ชั่วโมงในการกู้ระบบกลับมา ทำให้ผมตระหนักว่า การมี Firewall ที่เปิดใช้งานอยู่เฉยๆ นั้นไม่เพียงพอ แต่เราต้องรู้วิธี “ปรับแต่ง” มันให้ฉลาดพอที่จะแยกแยะระหว่างลูกค้าตัวจริงกับบอทที่มุ่งร้าย

เข้าใจศัตรู: ถอดรหัสรูปแบบการโจมตีที่ Firewall ต้องรับมือ

ก่อนที่เราจะเริ่มลงมือเขียนกฎ (Rules) บน Firewall สิ่งสำคัญคือต้องเข้าใจก่อนว่าเรากำลังสู้กับอะไร การโจมตีแบบ DDoS ไม่ได้มีรูปแบบเดียว จากประสบการณ์ที่ผมเจอมาตลอดหลายปี สามารถแบ่งการโจมตีหลักๆ ออกเป็นสองประเภทที่สร้างความปวดหัวให้เรามากที่สุด ประเภทแรกคือ Volumetric Attacks หรือการส่งทราฟฟิกขยะปริมาณมหาศาลเข้ามาถมท่อเน็ตเวิร์กให้เต็ม เช่น UDP Flood หรือ ICMP Flood ซึ่งเป้าหมายคือการทำให้แบนด์วิดท์ของเซิร์ฟเวอร์ตันจนใช้งานไม่ได้

ประเภทที่สองซึ่งมีความแนบเนียนและตรวจจับยากกว่าคือ Application Layer Attacks (Layer 7) เช่น HTTP Flood หรือ Slowloris การโจมตีประเภทนี้ไม่ได้ใช้แบนด์วิดท์จำนวนมหาศาล แต่จะส่งคำขอ (Requests) ที่ดูเหมือนเป็นทราฟฟิกปกติจากผู้ใช้ทั่วไปเข้ามาอย่างต่อเนื่อง เพื่อให้เว็บเซิร์ฟเวอร์ต้องประมวลผลอย่างหนักจนทรัพยากรระบบ เช่น PHP-FPM หรือฐานข้อมูล (Database) ทำงานหนักจนค้างไปเอง

ความแตกต่างระหว่าง Layer 4 และ Layer 7 Attacks

การโจมตีในระดับ Layer 4 (Transport Layer) มักจะมุ่งเน้นไปที่การทำลายโปรโตคอล TCP/UDP เช่น การส่งแพ็กเก็ต SYN เข้ามาโดยไม่มีการตอบกลับเพื่อเชื่อมต่อให้สำเร็จ ทำให้เซิร์ฟเวอร์ต้องเปิด Connection ค้างไว้รอจนกว่าจะหมดเวลา (Timeout) ในขณะที่ Layer 7 (Application Layer) จะเลียนแบบพฤติกรรมของมนุษย์ เช่น การกดรีเฟรชหน้าเว็บรัวๆ หรือการยิง API คิวรีข้อมูลหนักๆ ซึ่งทำให้การป้องกันต้องใช้ความละเอียดอ่อนและการวิเคราะห์พฤติกรรมที่ซับซ้อนขึ้น

ลงมือปฏิบัติ: การตั้งค่า iptables และ firewalld เพื่อสกัดกั้นภัยคุกคาม

เครื่องมือพื้นฐานที่ติดตั้งมากับ Linux ทุกตัวอย่าง iptables หรือระบบที่ใหม่อย่าง firewalld คือปราการด่านแรกที่เราสามารถปรับแต่งได้ทันทีโดยไม่มีค่าใช้จ่ายเพิ่มเติม จากเหตุการณ์ครั้งนั้น ผมได้พัฒนาชุดคำสั่ง iptables ที่ออกแบบมาเพื่อกรองทราฟฟิกที่ผิดปกติออกไปตั้งแต่ระดับเคอร์เนล (Kernel) ก่อนที่มันจะส่งต่อไปถึงเว็บเซิร์ฟเวอร์อย่าง Nginx หรือ Apache ด้วยซ้ำ

หัวใจสำคัญคือการจำกัดจำนวนการเชื่อมต่อใหม่ (Connection Rate Limiting) และการบล็อกแพ็กเก็ตที่ไม่ได้มาตรฐาน เช่น แพ็กเก็ตที่ไม่มีแฟล็ก (Null Packets) หรือแพ็กเก็ตที่มีโครงสร้างผิดแปลกไปจากมาตรฐาน TCP ซึ่งมักจะถูกสร้างขึ้นโดยเครื่องมือยิง DDoS อัตโนมัติ การตั้งค่าเหล่านี้เปรียบเสมือนการคัดกรองบุคคลที่ประตูทางเข้าอาคาร เพื่อไม่ให้คนแปลกหน้าจำนวนมากเข้ามายืนออจนเต็มพื้นที่โถงต้อนรับ

ด้านล่างนี้คือตัวอย่างสคริปต์ iptables ที่ผมใช้จริงในการป้องกันการโจมตีประเภท SYN Flood และการจำกัดความเร็วในการเชื่อมต่อสำหรับพอร์ตเว็บทั่วไป ซึ่งช่วยลดภาระของเซิร์ฟเวอร์ได้อย่างมีนัยสำคัญเมื่อเกิดการโจมตี

# 1. ป้องกัน SYN Flood ด้วยการจำกัดจำนวน SYN Packets ต่อวินาที
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j ACCEPT

# 2. บล็อกแพ็กเก็ตที่ผิดปกติ (เช่น Null Packets)
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# 3. จำกัดการเชื่อมต่อใหม่จาก IP เดียวกัน ไม่ให้เกิน 20 Connections บนพอร์ต HTTPS
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --set
iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 20 -j DROP

ยกระดับการป้องกันด้วยการปรับแต่งเคอร์เนล (Sysctl)

นอกจากการตั้งค่ากฎบน Firewall แล้ว อีกหนึ่งจุดสำคัญที่หลายคนมักมองข้ามคือการปรับแต่งพารามิเตอร์ของระบบเครือข่ายในระดับเคอร์เนลผ่านไฟล์ /etc/sysctl.conf ระบบปฏิบัติการ Linux ส่วนใหญ่ถูกตั้งค่าเริ่มต้นมาเพื่อเน้นความยืดหยุ่นและการเชื่อมต่อที่ราบรื่น แต่มันไม่ได้ถูกออกแบบมาเพื่อรับมือกับสภาพแวดล้อมที่เป็นอันตรายในปัจจุบัน

ฟังก์ชันหนึ่งที่ช่วยชีวิตระบบของผมไว้หลายครั้งคือ tcp_syncookies เมื่อเปิดใช้งานฟังก์ชันนี้ เซิร์ฟเวอร์จะไม่สร้าง Connection State ในหน่วยความจำทันทีที่ได้รับแพ็กเก็ต SYN แต่จะส่งคุกกี้พิเศษกลับไปพร้อมกับแพ็กเก็ต SYN-ACK หากไคลเอนต์ตอบกลับมาพร้อมกับ ACK ที่ถูกต้อง ระบบจึงจะยอมรับการเชื่อมต่อ วิธีนี้ช่วยป้องกันไม่ให้หน่วยความจำของระบบเต็มจากการโจมตีแบบ SYN Flood ได้อย่างมีประสิทธิภาพสูงสุด

พารามิเตอร์สำคัญใน sysctl.conf ที่ต้องปรับแต่ง

นอกเหนือจาก SYN Cookies แล้ว เราจำเป็นต้องลดระยะเวลาในการรอคอยการเชื่อมต่อที่ค้างอยู่ (Timeout) ให้สั้นลง และเพิ่มขนาดของคิวในการรองรับการเชื่อมต่อ (Backlog Queue) เพื่อให้เซิร์ฟเวอร์สามารถรองรับคิวการเชื่อมต่อที่ถาโถมเข้ามาได้มากขึ้นโดยไม่ปฏิเสธการเชื่อมต่อของผู้ใช้ที่ดี

# เปิดใช้งาน TCP SYN Cookies เพื่อป้องกัน SYN Flood
net.ipv4.tcp_syncookies = 1

# เพิ่มจำนวนคิวสูงสุดสำหรับการเชื่อมต่อที่ยังไม่เสร็จสิ้น
net.ipv4.tcp_max_syn_backlog = 2048

# ลดเวลาที่ระบบจะรอคอยการตอบกลับจากแพ็กเก็ต FIN-WAIT-2
net.ipv4.tcp_fin_timeout = 15

# เพิ่มขนาดของคิวรับส่งแพ็กเก็ตสูงสุดของระบบ
net.core.netdev_max_backlog = 50000

การใช้ Cloud-Based Firewall ร่วมกับ Local Firewall เพื่อการป้องกันที่สมบูรณ์แบบ

แม้ว่าเราจะตั้งค่า Local Firewall และเคอร์เนลได้ดีเยี่ยมเพียงใด แต่ก็ยังมีขีดจำกัดด้านฮาร์ดแวร์และแบนด์วิดท์ของอินเทอร์เน็ตเกตเวย์ หากผู้โจมตีใช้ปริมาณแบนด์วิดท์ในการโจมตีมากกว่าขนาดของท่ออินเทอร์เน็ตที่เราเช่าไว้ (เช่น การโจมตีขนาด 10 Gbps บนสายสัญญาณขนาด 1 Gbps) เซิร์ฟเวอร์ของเราก็ยังคงล่มอยู่ดีเนื่องจากทราฟฟิกไม่สามารถเดินทางมาถึงเซิร์ฟเวอร์ได้เลย

ทางออกที่ดีที่สุดที่ผมนำมาใช้ควบคู่กันคือการใช้ Cloud-Based Firewall หรือ Content Delivery Network (CDN) ที่มีฟีเจอร์ป้องกัน DDoS เช่น Cloudflare หรือ AWS Shield บริการเหล่านี้จะทำหน้าที่เป็นหน้าด่านคอยกรองทราฟฟิกขยะจำนวนมหาศาลในระดับเทราไบต์ที่ขอบเครือข่าย (Edge Network) ทั่วโลก ก่อนที่จะส่งเฉพาะทราฟฟิกที่สะอาดและปลอดภัยเข้ามายังเซิร์ฟเวอร์จริงของเรา

การทำงานร่วมกันอย่างเป็นระบบคือ เราจะตั้งค่า Cloud Firewall ให้ทำหน้าที่กรองการโจมตีขนาดใหญ่ และตั้งค่า Local Firewall บนเซิร์ฟเวอร์ของเราให้อนุญาตเฉพาะทราฟฟิกที่มาจากไอพีของ Cloud Provider เท่านั้น วิธีนี้ไม่เพียงแต่ช่วยประหยัดทรัพยากรของเซิร์ฟเวอร์ แต่ยังช่วยซ่อนไอพีจริง (Origin IP) ของเราไม่ให้ผู้โจมตีรับรู้และยิงตรงเข้ามาที่เครื่องได้อีกด้วย

สรุปแนวทางปฏิบัติที่ดีที่สุดในการตั้งค่า Firewall ป้องกัน DDoS

จากประสบการณ์ตรงที่ต้องเผชิญหน้ากับการโจมตีและกู้ระบบในสถานการณ์จริง ผมได้กลั่นกรองแนวทางการป้องกันที่ได้ผลที่สุดออกมาเป็นขั้นตอนการปฏิบัติงานที่ชัดเจน เพื่อให้คุณสามารถนำไปประยุกต์ใช้กับระบบของคุณเองก่อนที่จะสายเกินไป

• เปิดใช้งาน SYN Cookies เสมอ: เป็นวิธีที่ง่ายและมีประสิทธิภาพสูงสุดในการป้องกันการโจมตีประเภท SYN Flood ในระดับระบบปฏิบัติการ
• จำกัด Connection Rate: ตั้งค่า Firewall ให้จำกัดจำนวนการเชื่อมต่อใหม่ต่อวินาทีจากหนึ่งไอพี เพื่อป้องกันบอทยิงถล่ม
• ซ่อน Origin IP: ใช้ Cloud Firewall บังหน้าเซิร์ฟเวอร์จริงไว้เสมอ และบล็อกทราฟฟิกทั้งหมดที่ไม่ได้มาจาก IP ของ Cloud Provider
• ตั้งค่า Timeout ให้กระชับ: ลดเวลาการรอคอยการเชื่อมต่อที่ค้างอยู่เพื่อคืนทรัพยากรระบบให้เร็วที่สุด
• ตรวจสอบ Log อย่างสม่ำเสมอ: ติดตั้งระบบวิเคราะห์ล็อกเพื่อตรวจจับพฤติกรรมที่ผิดปกติก่อนที่มันจะขยายตัวเป็นการโจมตีขนาดใหญ่

สรุป

การป้องกัน DDoS ไม่ใช่เรื่องของการตั้งค่าครั้งเดียวแล้วจบไป แต่เป็นกระบวนการที่ต้องอาศัยการตรวจสอบ ปรับปรุง และปรับตัวให้เข้ากับรูปแบบการโจมตีใหม่ๆ อยู่เสมอ การผสานพลังระหว่าง Local Firewall ที่ปรับแต่งอย่างละเอียดระดับเคอร์เนล ร่วมกับการใช้ Cloud-Based Firewall ที่แข็งแกร่ง คือกุญแจสำคัญที่จะช่วยให้ระบบของคุณยังคงยืนหยัดทำงานได้อย่างมั่นคง แม้ในวันที่ต้องเผชิญกับพายุทราฟฟิกที่โหมกระหน่ำอย่างรุนแรงที่สุด