วิธีตั้งค่ากำแพงไฟร์วอลล์เซิร์ฟเวอร์ ป้องกัน DDoS และบอทอย่างมืออาชีพ

การตั้งค่ากำแพงไฟร์วอลล์บนเซิร์ฟเวอร์ คือการเปิดใช้งานเฉพาะพอร์ตที่จำเป็น และปิดกั้นการเข้าถึงที่ไม่ต้องการทั้งหมด ซึ่งเป็นชั้นป้องกันแรกสำหรับการโจมตีแบบ DDoS, การทดลองรหัสผ่านแบบ brute force และการจราจรจากบอทที่เป็นอันตราย โดยหลักการปฏิบัติ คือ การจำกัดการเข้าถึง SSH, เปิดบริการเว็บไซต์อย่างมีการควบคุม, จำกัดอัตราการร้องขอที่น่าสงสัย, ตรวจสอบบันทึก (log) อย่างสม่ำเสมอ และหากเป็นไปได้ ควรใช้ระบบป้องกันบนชั้น CDN/WAF เพื่อกรองทราฟฟิกก่อนที่จะถึงเซิร์ฟเวอร์

ทันทีที่คุณเปิดเซิร์ฟเวอร์เว็บสู่โลกอินเทอร์เน็ต ก็จะมีการสแกนพอร์ต, ความพยายามเชื่อมต่อ SSH, บอทค้นหาช่องโหว่ และผู้ใช้งานปลอม ๆ เข้ามาทันที โดยเฉพาะกับเซิร์ฟเวอร์ที่ใช้ WordPress, อีคอมเมิร์ซ, แผงควบคุม, API หรือเซิร์ฟเวอร์เกม การมีไฟร์วอลล์ไม่ใช่แค่ตัวเลือกทางเทคนิค แต่เป็นสิ่งจำเป็นเพื่อความต่อเนื่องของระบบ ในบทความนี้เราจะตั้งค่ากำแพงไฟร์วอลล์บน Linux แบบทีละขั้นตอน โดยครอบคลุม UFW, firewalld, nftables, Fail2ban, ไฟร์วอลล์สำหรับเว็บแอปพลิเคชัน และแนวทางลด DDoS ร่วมกัน

เริ่มต้นด้วยความจริงที่สำคัญ: ไฟร์วอลล์บนเซิร์ฟเวอร์เพียงอย่างเดียวไม่สามารถหยุดการโจมตี DDoS ที่มีปริมาณสูงได้ เช่น เมื่อการโจมตีที่มีปริมาณ 20 Gbps, 80 Gbps หรือสูงกว่านั้นมาถึงศูนย์ข้อมูลหรือโครงข่ายหลัก แบนด์วิดท์จะเต็มก่อนที่แพ็กเกจจะมาถึงกฎในระบบปฏิบัติการของคุณ ดังนั้นการป้องกันที่เหมาะสมคือการใช้ระบบป้องกันหลายชั้น ได้แก่ การป้องกัน DDoS ที่ระดับผู้ให้บริการ, CDN/WAF, ไฟร์วอลล์ระบบปฏิบัติการ, การจำกัดอัตราการเข้าถึงแอปพลิเคชัน และการวิเคราะห์บันทึกอย่างสม่ำเสมอ สำหรับการเลือกโครงสร้างพื้นฐานที่เหมาะสม สามารถดูได้ที่ โซลูชันเซิร์ฟเวอร์ VPS และ VDS Hostragons และสำหรับตัวเลือกเว็บโฮสติ้งที่ปลอดภัย โปรดเยี่ยมชม แพ็คเกจเว็บโฮสติง Hostragons

กำแพงไฟร์วอลล์เซิร์ฟเวอร์มีประโยชน์อย่างไร?

กำแพงไฟร์วอลล์เซิร์ฟเวอร์เป็นชั้นป้องกันที่กรองทราฟฟิกเครือข่ายตามที่อยู่ IP ต้นทาง IP ปลายทาง พอร์ต โปรโตคอล สถานะการเชื่อมต่อ และในบางกรณีตามลักษณะของแพ็กเกจ ยกตัวอย่าง เช่น เว็บไซต์ของคุณควรเปิดพอร์ต 80 และ 443 แต่พอร์ตฐานข้อมูล 3306 ไม่ควรเปิดสู่สาธารณะ และสำหรับ SSH พอร์ต 22 ไม่ควรเปิดให้ทุกคนเข้าถึง แต่ควรจำกัดเฉพาะ IP ของสำนักงานคุณ

เป้าหมายหลักของไฟร์วอลล์ไม่ใช่การกำจัดการโจมตีทั้งหมดอย่างวิเศษ แต่คือการลดพื้นที่เสี่ยงที่เปิดให้ถูกโจมตี ยิ่งพื้นที่เสี่ยงน้อย โอกาสที่แฮกเกอร์จะเจาะทะลุได้น้อยลง เช่น เซิร์ฟเวอร์ Linux ที่เพิ่งติดตั้งใหม่อาจเปิด SSH, แผงควบคุมเว็บ, บริการอีเมล, ฐานข้อมูล, เอเจนต์มอนิเตอร์ และบริการทดสอบพร้อมกัน ซึ่งแต่ละบริการต่างก็เพิ่มความเสี่ยง กำแพงไฟร์วอลล์ที่ตั้งค่าอย่างดีจะใช้หลักการ “ปฏิเสธโดยค่าเริ่มต้น ยกเว้นสิ่งที่จำเป็นต้องอนุญาต”

ทำความเข้าใจ DDoS และทราฟฟิกบอท

ทำไมการโจมตี DDoS ถึงแตกต่าง?

DDoS หรือ Distributed Denial of Service คือการโจมตีที่ใช้ทราฟฟิกจำนวนมากจากหลายแหล่งเพื่อทำให้บริการเป้าหมายไม่สามารถเข้าถึงได้ บางครั้งจะเติมเต็มแบนด์วิดท์ บางครั้งจะใช้ CPU และ RAM ของเซิร์ฟเวอร์จนหมด หรือบางครั้งจะไปกระตุ้นการทำงานหนักของแอปพลิเคชันในชั้นแอป เช่น เซิร์ฟเวอร์แอปพลิเคชันขนาดเล็กที่รับคำขอ HTTP 50,000 ครั้งต่อวินาที อาจไม่สามารถตอบสนองได้แม้แบนด์วิดท์ไม่เต็ม เพราะ PHP-FPM, Node.js หรือพูลการเชื่อมต่อฐานข้อมูลถูกใช้งานจนล้น

บอทเป็นภัยเสมอไปไหม?

ไม่ใช่เสมอไป บอทอย่าง Googlebot, Bingbot และบอทติดตามบางตัวมีประโยชน์ แต่บอทที่เป็นอันตรายจะสแกนแผงควบคุม, ค้นหาไดเรกทอรีเปิด, ส่งสแปมฟอร์ม, คัดลอกเนื้อหา, ใช้งาน XML-RPC ผิดวัตถุประสงค์, สร้างบัญชีปลอม และพยายามล็อกอิน ดังนั้นการจัดการบอทต้องแยกแยะตามพฤติกรรม ไม่ใช่บล็อกทุกตัว สัญญาณสำคัญได้แก่ อัตราความผิดพลาดสูง, คำขอจำนวนมากในเวลาสั้น, หัวข้อที่ไม่เหมือนเบราว์เซอร์จริง และรูปแบบ URL ที่น่าสงสัย

รายการตรวจสอบก่อนเริ่มตั้งค่า

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

• อย่าปิดเซสชัน SSH ที่กำลังใช้งาน ให้เปิดเทอร์มินัลอีกหน้าต่างเพื่อลองทดสอบ
• ตรวจสอบว่าเซิร์ฟเวอร์ของคุณมีคอนโซล, VNC หรือโหมดกู้คืนให้ใช้งาน
• ตรวจสอบพอร์ตที่เปิดอยู่ด้วยคำสั่ง ss -tulpn หรือ netstat -tulpn
• จดบันทึกพอร์ตที่บริการเว็บ, เมล, DNS, ฐานข้อมูล, แผงควบคุม และมอนิเตอร์ใช้
• ถ้าใช้ IPv6 ให้วางแผนกฎไฟร์วอลล์สำหรับ IPv6 ด้วย
• เริ่มจากการตั้งกฎอนุญาตก่อน แล้วค่อยตั้งกฎปฏิเสธ
• ยืนยันว่าการตั้งค่ากฎเป็นแบบถาวร ไม่หายไปเมื่อตัวเซิร์ฟเวอร์รีสตาร์ท

ตัวอย่างเช่น เซิร์ฟเวอร์ที่โฮสต์เว็บไซต์เพียงอย่างเดียว มักเปิดพอร์ต 80, 443 และ SSH แบบจำกัด หากไม่มีบริการอีเมล พอร์ตอย่าง 25, 465, 587 หรือ 993 ไม่ควรถูกเปิด และหากฐานข้อมูลใช้เฉพาะภายในเซิร์ฟเวอร์ ควรปิดพอร์ต 3306 หรือ 5432 สำหรับการเข้าถึงจากภายนอก

ควรเลือกใช้เครื่องมือไฟร์วอลล์แบบไหน?

ในโลก Linux มีเครื่องมือหลายตัวที่ใช้แกนกรองข้อมูลชุดเดียวกัน แต่มีความง่าย-ยากในการใช้งานต่างกัน สำหรับผู้เริ่มต้น UFW ใช้งานง่ายและติดตั้งรวดเร็ว ระบบองค์กรหรือระบบ Red Hat มักใช้ firewalld ส่วน nftables เหมาะกับกรณีใช้งานระดับสูงและต้องการความยืดหยุ่น ตารางด้านล่างช่วยให้เลือกได้ง่ายขึ้น

ขั้นตอนตั้งค่ากำแพงไฟร์วอลล์บนเซิร์ฟเวอร์

1. ตรวจสอบพอร์ตและบริการที่เปิดใช้งาน

ขั้นตอนแรกคือการดูว่ามีบริการอะไรเปิดอยู่บนเซิร์ฟเวอร์ Linux ของคุณ โดยใช้คำสั่ง ss -tulpn ซึ่งแสดงว่าบริการใดฟังพอร์ตใดบ้าง เช่น nginx ฟังที่ 0.0.0.0:80 และ 0.0.0.0:443 หมายความว่ารับทราฟฟิกจากทุกอินเทอร์เฟซ ส่วน MariaDB ฟังที่ 0.0.0.0:3306 ก็ถือว่าเสี่ยง เพราะฐานข้อมูลควรฟังแค่ 127.0.0.1

กฎง่ายๆ คือ ไม่มีบริการใดที่ไม่จำเป็นควรฟังบน 0.0.0.0 หากเป็นไปได้ควรแก้ไขการตั้งค่าบริการก่อน แล้วค่อยใช้ไฟร์วอลล์ปิดกั้น เพราะถ้าไฟร์วอลล์ปิดการทำงาน บริการยังเปิดรับจากภายนอกได้อยู่

2. ตั้งนโยบายเริ่มต้นเป็นปิด

สำหรับชุดกฎที่ปลอดภัย ควรปฏิเสธทราฟฟิกขาเข้าทั้งหมดเป็นค่าตั้งต้น และอนุญาตเฉพาะที่จำเป็นเท่านั้น ส่วนทราฟฟิกขาออกสามารถกำหนดได้ตามความเหมาะสม ใน Ubuntu ที่ใช้ UFW วิธีคิดคือ อนุญาต SSH ก่อน จากนั้นเปิดพอร์ต 80, 443 แล้วตั้งนโยบายขาเข้าปฏิเสธ และเปิดใช้งานไฟร์วอลล์

ตัวอย่างขั้นตอนคือ อนุญาต SSH จาก IP ของแอดมิน, เปิด HTTP/HTTPS ให้ทุกคน, ปิดพอร์ตที่ไม่จำเป็น แล้วจึงเปิดไฟร์วอลล์ การเปิดไฟร์วอลล์ก่อนอนุญาต SSH เป็นข้อผิดพลาดที่พบบ่อยโดยเฉพาะกับเซิร์ฟเวอร์ระยะไกล

3. จำกัดการเข้าถึง SSH

SSH คือเป้าหมายหลักของแฮกเกอร์ เซิร์ฟเวอร์ที่เปิดพอร์ต 22 ไว้โดยไม่มีการป้องกัน อาจเจอพยายามเดารหัสผ่านนับร้อยหรือพันครั้งต่อวัน วิธีที่ปลอดภัยที่สุดคือจำกัดการเข้าถึง SSH เฉพาะ IP ที่เชื่อถือได้ เช่น IP สำนักงานหรือ VPN หากไม่มี IP คงที่ ให้ใช้การพิสูจน์ตัวตนด้วยกุญแจ SSH และปิดการเข้าสู่ระบบด้วยรหัสผ่าน

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

การเปลี่ยนพอร์ต SSH อาจช่วยลดเสียงรบกวนจากบอทอัตโนมัติได้ แต่ไม่ได้เพิ่มความปลอดภัยโดยตรง การป้องกันจริงๆ ต้องอาศัยการจำกัด IP, การพิสูจน์ตัวตนที่แข็งแกร่ง และการตรวจสอบบันทึก

4. เปิดพอร์ตเว็บอย่างมีการควบคุม

สำหรับเซิร์ฟเวอร์ที่ให้บริการเว็บไซต์ พอร์ต 80 และ 443 จำเป็นต้องเปิด แต่ปัจจุบันพอร์ต 443 (HTTPS) ควรเป็นพอร์ตหลัก และพอร์ต 80 ควรใช้สำหรับเปลี่ยนเส้นทางไป HTTPS เท่านั้น เว็บไซต์ที่ไม่มีใบรับรอง SSL ไม่เพียงแต่ทำให้ผู้ใช้ไม่มั่นใจ แต่ยังส่งผลต่ออันดับ SEO ด้วย ที่นี่ ใบรับรอง SSL Hostragons เป็นลิงก์ที่เหมาะสมสำหรับแนะนำการติดตั้ง HTTPS

เมื่อเปิดพอร์ตเว็บ ต้องระวังการเปิดเผย IP จริงของเซิร์ฟเวอร์ หากใช้ CDN หรือ reverse proxy ควรอนุญาตให้รับทราฟฟิกจากช่วง IP ของ CDN เท่านั้น จะช่วยป้องกันการโจมตีโดยตรงที่เซิร์ฟเวอร์ แม้แฮกเกอร์จะรู้ IP จริงแล้วก็ตาม

5. ปิดพอร์ตฐานข้อมูลและบริการภายในที่ไม่จำเป็น

บริการอย่าง MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB ที่เปิดพอร์ตสู่สาธารณะ ถือเป็นความเสี่ยงสูง ตัวอย่างเช่น Redis ไม่มีการยืนยันตัวตน หรือ Elasticsearch ที่อนุญาตการเข้าถึงดัชนีโดยไม่ได้รับอนุญาต หรือ MongoDB ที่เปิดพอร์ตจัดการโดยตรง เคยเกิดเหตุข้อมูลรั่วไหลหลายครั้ง บริการเหล่านี้ควรฟังแค่ภายในเครื่อง (localhost) หรือเครือข่ายส่วนตัวเท่านั้น

เช่น หาก WordPress และฐานข้อมูลรันบนเซิร์ฟเวอร์เดียวกัน ให้ฐานข้อมูลฟังที่ 127.0.0.1 เท่านั้น หรือถ้าแยกเซิร์ฟเวอร์ ให้อนุญาตเฉพาะ IP ภายในของเซิร์ฟเวอร์แอปพลิเคชัน การเปิดพอร์ต 3306 หรือ 5432 ให้เข้าถึงจากอินเทอร์เน็ตเป็นช่องโหว่ที่บอทมักสแกนอยู่เสมอ

6. ใช้ Fail2ban ป้องกันการเดารหัสผ่าน (Brute Force)

Fail2ban คือโปรแกรมที่ตรวจสอบบันทึกการเข้าใช้งาน และบล็อก IP ที่พยายามล็อกอินผิดซ้ำ ๆ ชั่วคราว สามารถตั้งค่าได้กับ SSH, nginx, Apache, Postfix, Dovecot, WordPress login และบริการแผงควบคุม ตัวอย่างเช่น หาก IP ใดพยายามล็อกอิน SSH ผิด 5 ครั้งใน 10 นาที ระบบจะบล็อก IP นั้น 1 ชั่วโมง ถือเป็นวิธีเริ่มต้นที่ง่ายและได้ผลดี

แต่ต้องระวังไม่ตั้งกฎเข้มงวดเกินไป เพราะอาจบล็อกผู้ใช้จริงได้ ในช่วงแรกควรตั้งเวลาและจำนวนครั้งที่เหมาะสม คอยตรวจสอบบันทึก และค่อย ๆ ปรับเพิ่มความเข้มงวด

7. เพิ่มการจำกัดอัตรา (Rate Limiting) และข้อจำกัดการเชื่อมต่อ

ระบบปฏิบัติการสามารถช่วยจำกัดอัตราการเชื่อมต่อใหม่จาก IP เดียวกัน เพื่อลดการโจมตี DDoS และบอทได้ เช่น หาก IP เดียวกันพยายามเชื่อมต่อเกินจำนวนที่กำหนดต่อวินาที สามารถบล็อกหรือจำกัดได้ ในฝั่งเว็บเซิร์ฟเวอร์ nginx มีโมดูล limit_req และ limit_conn ส่วน Apache มี mod_evasive เป็นต้น ในแอปพลิเคชันควรตั้งข้อจำกัดสำหรับการล็อกอิน, การค้นหา, ตะกร้าสินค้า, ระบบชำระเงิน และ API endpoint ด้วย

เช่น หน้าเข้าสู่ระบบอาจจำกัดให้ IP เดียวทำได้ไม่เกิน 10 ครั้งต่อนาที หน้าแอดมินค้นหาอาจจำกัด 2-5 ครั้งต่อวินาที สำหรับ API ควรออกแบบระบบโทเค็นผู้ใช้, จำกัด IP และวิเคราะห์พฤติกรรมร่วมกัน เพื่อป้องกันการเปลี่ยน IP หลบเลี่ยงข้อจำกัด

ตัวอย่างการตั้งค่าไฟร์วอลล์ด้วย UFW

บน Ubuntu หรือ Debian เซิร์ฟเวอร์เว็บ สามารถตั้งค่าไฟร์วอลล์แบบง่าย ๆ ดังนี้: ตรวจสอบบริการที่เปิดอยู่ก่อน, อนุญาต SSH จาก IP ผู้ดูแลระบบ, เปิดพอร์ต 80 และ 443, ตั้งนโยบายปฏิเสธทราฟฟิกขาเข้าเป็นค่าเริ่มต้น และตรวจสอบสถานะ UFW หากไม่สามารถจำกัด SSH ด้วย IP คงที่ได้ ช่วงแรกอาจเปิด SSH ให้ทุก IP ชั่วคราวก่อน แล้วค่อยเปลี่ยนไปใช้ VPN หรือ IP คงที่

ตัวอย่างสมมติว่า IP ผู้ดูแลระบบคือ 203.0.113.10 อนุญาต SSH เฉพาะ IP นี้ เปิดเว็บให้ทุกคนเข้าถึงพอร์ต 80 และ 443 ปิดพอร์ตฐานข้อมูล, Redis, แผงควบคุม และพอร์ตทดสอบ เหมาะสำหรับเว็บไซต์องค์กรขนาดเล็กถึงกลาง สำหรับการตั้งค่าโดเมนและ DNS อย่างถูกต้อง สามารถดูได้ที่ การตรวจสอบโดเมนและการลงทะเบียน Hostragons

แนวคิดโซนกับ firewalld

บนเซิร์ฟเวอร์ที่ใช้ AlmaLinux, Rocky Linux หรือ RHEL firewalld เป็นที่นิยม ใช้แนวคิดโซน (zone) เช่น public สำหรับอินเทอร์เฟซที่เปิดสู่สาธารณะ trusted สำหรับเครือข่ายที่เชื่อถือได้ และ drop สำหรับการปฏิเสธทราฟฟิกเงียบ ๆ สิ่งสำคัญคือต้องเข้าใจความต่างระหว่างกฎ runtime ที่ใช้ทันทีแต่ไม่ถาวร กับกฎ permanent ที่ถาวรแต่ต้องรีโหลด

ในองค์กร การใช้ firewalld กับการกำหนดบริการช่วยให้จัดการง่าย เช่น เปิด http และ https บนโซน public จำกัด ssh เฉพาะบาง IP หากมีหลายอินเทอร์เฟซสำหรับเครือข่ายแยกกัน เช่น เครือข่ายผู้ใช้ เครือข่ายสำรอง โซนช่วยเพิ่มความปลอดภัยและทำให้อ่านง่ายขึ้น

CDN, WAF และการป้องกัน DDoS ระดับผู้ให้บริการ

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

แบบจำลองที่ดีที่สุดคือ DNS ชี้ผ่าน CDN เพื่อปกปิด IP จริงของเซิร์ฟเวอร์ ไฟร์วอลล์บนเซิร์ฟเวอร์จึงรับเฉพาะทราฟฟิกจากช่วง IP ของ CDN เท่านั้น พอร์ตสำหรับจัดการเซิร์ฟเวอร์ควรใช้ VPN หรือ IP คงที่เข้าถึง วิธีนี้ลดโอกาสถูกโจมตีโดยตรงและช่วยกรองบอทก่อนถึงแอปพลิเคชัน สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความปลอดภัยและการเพิ่มความเร็วเว็บไซต์ สามารถดูได้ที่ คู่มือการเร่งความเร็วและความปลอดภัยเว็บไซต์

มาตรการป้องกันบอทในชั้นแอปพลิเคชัน

การบล็อกบอทไม่ได้จำกัดแค่การบล็อก IP เท่านั้น เพราะบอทสมัยใหม่อาจใช้พร็อกซี, เครือข่ายมือถือ, IP ศูนย์ข้อมูล และเปลี่ยน User-Agent อยู่ตลอด ดังนั้นต้องวิเคราะห์พฤติกรรม เช่น การล็อกอินซ้ำ ๆ จาก IP เดียว, การสแกนที่ก่อให้เกิด 404 บ่อยครั้ง, การร้องขอ wp-login.php หรือ xmlrpc.php มากกว่าปกติ, คลิกที่แตกต่างจากผู้ใช้จริง และหัวข้อคำขอที่น่าสงสัย

• ใช้การจำกัดอัตรา (rate limiting) บนแบบฟอร์มล็อกอินและลงทะเบียน
• ปิดหรือจำกัดการเข้าถึง XML-RPC ที่ไม่จำเป็น
• ปกป้องแผงควบคุมด้วย URL ที่ไม่ซ้ำ, จำกัด IP และระบบยืนยันตัวตนหลายชั้น (MFA)
• กรอง User-Agent และ Referer ที่น่าสงสัยในระดับ WAF
• ใช้ CAPTCHA หรือระบบตรวจสอบบอทที่มองไม่เห็นอย่างสมดุลในฟอร์มต่าง ๆ
• สำหรับ API ให้ใช้กุญแจ, ลายเซ็น, โควต้า และตรวจสอบเวลาคำขอ

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

การตรวจสอบบันทึกและระบบแจ้งเตือน

การตั้งค่าไฟร์วอลล์ไม่ใช่จบ แต่ต้องติดตามตรวจสอบอย่างต่อเนื่อง เช่น ดูบันทึก auth.log หรือ secure สำหรับการพยายามล็อกอิน SSH, ตรวจสอบ nginx access log ว่ามีคำขอผิดปกติหรือไม่, ตรวจสอบ error log ว่ามี 404 หรือ 500 เพิ่มขึ้นหรือไม่ และติดตามประสิทธิภาพของ CPU และจำนวนการเชื่อมต่อ การตั้งค่าการแจ้งเตือนง่าย ๆ ช่วยให้รู้ตัวเร็วเมื่อเกิดการโจมตี

ตัวอย่างเกณฑ์แจ้งเตือน เช่น 100 คำขอ 404 จาก IP เดียวภายใน 5 นาที, 20 ครั้งพยายามล็อกอินใน 1 นาที, CPU ใช้งานเกิน 90% ติดต่อกัน 10 นาที หรือจำนวนการเชื่อมต่อเพิ่มขึ้น 3 เท่าของปกติ ค่าเหล่านี้อาจปรับตามลักษณะเว็บไซต์ แต่สิ่งสำคัญคือรู้จักรูปแบบทราฟฟิกปกติของคุณ

ข้อผิดพลาดที่พบบ่อยและวิธีหลีกเลี่ยง

• เปิดไฟร์วอลล์โดยไม่อนุญาต SSH ก่อน: อาจทำให้เข้าเซิร์ฟเวอร์ไม่ได้ ควรทดสอบด้วยเซสชันที่สองเสมอ
• ลืมตั้งกฎ IPv6: แม้ปิด IPv4 แต่ IPv6 อาจเปิดให้บริการโดยไม่ตั้งใจ
• เปิดพอร์ตฐานข้อมูลสู่สาธารณะ: เช่น 3306, 5432, 6379 หรือ 9200 ที่บอทมักสแกนบ่อย
• ใช้ CDN แต่เปิดเผย IP จริง: ทำให้แฮกเกอร์โจมตีเซิร์ฟเวอร์โดยตรงได้
• เปลี่ยนกฎโดยไม่จดบันทึก: ทำให้ยากต่อการแก้ไขเมื่อเกิดปัญหา
• ไม่มีแผนสำรองสำหรับเข้าถึงเซิร์ฟเวอร์: หากตั้งค่าผิดและไม่มีคอนโซลสำรอง จะทำให้ระบบล่มนานขึ้น

ตัวอย่างนโยบายไฟร์วอลล์ที่ใช้งานได้จริง

สำหรับเว็บไซต์องค์กรขนาดเล็ก นโยบายสรุปได้ว่า: ปิดทราฟฟิกขาเข้าทั้งหมดเป็นค่าตั้งต้น, เปิดพอร์ต 443 ให้ทุกคน, เปิดพอร์ต 80 สำหรับเปลี่ยนเส้นทาง HTTPS เท่านั้น, จำกัด SSH ให้เข้าถึงเฉพาะ VPN หรือ IP ผู้ดูแลระบบ, ฐานข้อมูลฟังเฉพาะ localhost หรือเครือข่ายส่วนตัว, ถ้าใช้ CDN ให้อนุญาตเฉพาะ IP ของ CDN ที่พอร์ต 80 และ 443, Fail2ban ตรวจสอบการล็อกอิน SSH และเว็บ, ส่งบันทึกไปยังระบบตรวจสอบส่วนกลาง

สำหรับเว็บไซต์อีคอมเมิร์ซขนาดกลาง สามารถเพิ่มได้อีก เช่น ตั้ง allowlist สำหรับ IP ของ callback การชำระเงิน, วางแผงควบคุมหลัง VPN, ใช้โควต้าผู้ใช้ API, เปิดกฎ WAF ป้องกัน SQL injection และ XSS, วางแผนการกรองชั่วคราวตามประเทศหรือ ASN การมีนโยบายเป็นลายลักษณ์อักษรช่วยให้ตัดสินใจได้รวดเร็วและลดเวลาหยุดทำงานเมื่อต้องเผชิญกับการโจมตี

ทดสอบว่ากฎทำงานจริงหรือไม่

หลังตั้งค่าไฟร์วอลล์ ควรทดสอบอย่างรอบคอบ เช่น สแกนพอร์ตจากเครือข่ายอื่น, ตรวจสอบว่า SSH ใช้งานได้เฉพาะ IP ที่อนุญาต, ตรวจสอบเว็บไซต์ผ่าน HTTPS, ยืนยันว่าพอร์ตฐานข้อมูลปิดจากภายนอก และถ้าใช้ CDN ให้ลองส่งคำขอ HTTP ตรงไปยัง IP จริงเพื่อยืนยันว่าถูกบล็อก

ในขั้นตอนทดสอบ หลีกเลี่ยงการสแกนที่รุนแรงมากจนกระทบระบบจริง วัตถุประสงค์คือยืนยันความปลอดภัย และควรบันทึกกฎทุกครั้งที่เปลี่ยนแปลง เพื่อให้สามารถย้อนกลับไปยังการตั้งค่าที่ปลอดภัยได้หากเกิดปัญหา

แผนดูแลรักษาและอัปเดต

ความปลอดภัยของเซิร์ฟเวอร์ไม่ใช่การตั้งค่าเพียงครั้งเดียว แต่ต้องดูแลอย่างต่อเนื่อง เมื่อเพิ่มบริการใหม่ต้องตรวจสอบพอร์ตที่ต้องเปิด เมื่อยกเลิกบริการต้องลบกฎที่เกี่ยวข้อง อัปเดตความปลอดภัยอย่างสม่ำเสมอ และตรวจสอบบันทึกเป็นประจำ การตรวจสอบพอร์ตเปิดอย่างน้อยเดือนละครั้ง และทบทวนกฎไฟร์วอลล์ทุก 3 เดือน เป็นแนวทางปฏิบัติที่ดี

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

สรุป

การตั้งค่ากำแพงไฟร์วอลล์เซิร์ฟเวอร์ช่วยลดความเสี่ยงจาก DDoS และบอท แม้จะไม่ทำให้เซิร์ฟเวอร์มองไม่เห็น แต่ช่วยลดพื้นทีเป้าหมายอย่างมาก ลดโอกาสการเข้าถึงโดยไม่ได้รับอนุญาต และทำให้การจัดการเหตุการณ์ง่ายขึ้น ผลลัพธ์ที่ดีที่สุดได้จากการใช้การป้องกันหลายชั้น ได้แก่ DDoS ระดับผู้ให้บริการ, CDN/WAF, นโยบายพอร์ตเข้มงวด, การจำกัด SSH, Fail2ban, การจำกัดอัตรา และการวิเคราะห์บันทึกอย่างสม่ำเสมอ

หากคุณกำลังเริ่มโปรเจกต์ใหม่ ควรวางแผนนโยบายไฟร์วอลล์ตั้งแต่แรก จะง่ายกว่าการแก้ไขภายหลัง เมื่อใช้ Hostragons ในการเลือกเซิร์ฟเวอร์, โฮสติ้ง, โดเมน และ SSL ควรพิจารณาความต้องการด้านความปลอดภัยร่วมกัน เพื่อสร้างสภาพแวดล้อมเว็บที่ทนทาน แนะนำเริ่มจากรายการตรวจสอบเล็ก ๆ คือ ปิดพอร์ตที่ไม่จำเป็น จำกัด SSH ให้เข้มงวด บังคับใช้ HTTPS และตรวจสอบบันทึกอย่างต่อเนื่อง

คำถามที่พบบ่อย

กำแพงไฟร์วอลล์เซิร์ฟเวอร์สามารถป้องกัน DDoS ได้ทั้งหมดไหม?

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

บนเซิร์ฟเวอร์เว็บควรเปิดพอร์ตอะไรบ้าง?

โดยปกติจะเปิดพอร์ต 80 และ 443 สำหรับเว็บ ส่วนพอร์ต SSH ควรเปิดเฉพาะ IP ของผู้ดูแลระบบ และพอร์ตฐานข้อมูลหรือบริการภายในอื่นๆ ควรปิดไม่ให้เข้าถึงจากอินเทอร์เน็ต

ควรใช้ UFW หรือ firewalld?

สำหรับ Ubuntu และ Debian UFW เหมาะสำหรับผู้เริ่มต้นใช้งานง่าย ส่วนระบบที่ใช้ AlmaLinux, Rocky Linux หรือ RHEL มักใช้ firewalld หากต้องการควบคุมขั้นสูงและกรณีเฉพาะ nftables เป็นตัวเลือกที่ดี

จะป้องกันบอทได้ไหมแค่บล็อก IP?

โดยทั่วไปไม่เพียงพอ บอทสมัยใหม่ใช้ IP และพร็อกซีหลากหลาย ควรใช้การจำกัดอัตรา, กฎ WAF, วิเคราะห์พฤติกรรม, CAPTCHA และโควต้าบนแอปพลิเคชันร่วมด้วย

ความเสี่ยงใหญ่ที่สุดตอนตั้งค่าไฟร์วอลล์คืออะไร?

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