วิธีใช้โหมด "Under Attack" ของ Cloudflare ป้องกันเว็บไซต์ถูกโจมตี DDoS อย่างได้ผล

เมื่อเว็บไซต์ของคุณถูกโจมตีด้วย DDoS โหมด Cloudflare Under Attack จะช่วยกรองทราฟฟิกบอทด้วยการแสดงหน้าตรวจสอบความปลอดภัยสั้น ๆ แก่ผู้เยี่ยมชม ทำให้การโจมตีระดับ HTTP/HTTPS ชะลอลงในไม่กี่นาทีหลังเปิดใช้งานผ่านแผงควบคุม Cloudflare โดยเลือกเว็บไซต์ของคุณและเปิดใช้งานที่เมนู Security อย่างไรก็ตาม โหมดนี้ไม่ใช่ทางแก้ไขระยะยาว ควรใช้ร่วมกับการตั้งค่า DNS proxy ที่ถูกต้อง กฎ WAF การจำกัดอัตรา Cache และระบบความปลอดภัยของเซิร์ฟเวอร์ต้นทางเพื่อป้องกันอย่างครบถ้วน

บทความนี้จะสอนวิธีเปิดใช้งานโหมด Under Attack ของ Cloudflare, ช่วงเวลาที่เหมาะสมในการใช้, การตั้งค่าที่ควรเสริม และวิธีกลับสู่สภาพปกติหลังการโจมตี โดยเน้นให้คุณมีเช็คลิสต์ที่ช่วยควบคุมสถานการณ์ได้ทันท่วงทีและฟื้นฟูความพร้อมเว็บไซต์อย่างรวดเร็ว

โหมด Cloudflare Under Attack คืออะไร?

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

เป้าหมายหลักคือบรรเทาการโจมตีในระดับแอปพลิเคชัน (Layer 7) เช่น การยิงคำขอ GET จำนวนมากมายไปยังหน้าแรก, การพยายามเข้าสู่ระบบ WordPress อย่างหนัก, การทำคำค้นหาที่ใช้ทรัพยากรสูง หรือการส่งทราฟฟิกปลอมไปยังหน้ารถเข็นสินค้า โหมดนี้จึงเป็นแนวป้องกันขั้นต้นที่ช่วยบรรเทาภาระเซิร์ฟเวอร์ได้อย่างรวดเร็ว

อย่างไรก็ตาม หาก IP เซิร์ฟเวอร์ต้นทางถูกโจมตีโดยตรง หรือบริการที่ไม่ได้ผ่าน Cloudflare เปิดเผยอยู่ หรือเป็นการโจมตีระดับ Layer 3/4 จะต้องใช้มาตรการเสริมเพิ่มเติม เช่น การตั้งค่า DNS ให้ผ่าน Cloudflare แบบ proxied การซ่อน IP ต้นทาง และการตั้งค่าความปลอดภัยในฝั่งโฮสติ้ง สามารถดูข้อมูลเพิ่มเติมได้ที่ บริการโฮสติ้งเว็บที่ปลอดภัย และ การติดตั้งใบรับรอง SSL

สัญญาณบ่งชี้การโจมตี DDoS: ควรตรวจสอบอะไรบ้างก่อนเปิดโหมด Under Attack?

ไม่ใช่ทุกการช้าในการโหลดเว็บไซต์จะเกิดจาก DDoS บางครั้งอาจเกิดจากปลั๊กอินผิดพลาด, ฐานข้อมูลติดขัด, งาน cron ที่ใช้ CPU สูง หรือการตั้งค่าแคชผิดพลาด ดังนั้นควรตรวจสอบเบื้องต้นก่อนเปิดโหมดนี้ แต่ถ้าเซิร์ฟเวอร์ตอบสนองช้าเกินไป, ผู้ใช้เจอข้อผิดพลาด 502, 503, 504 หรือในล็อกมีคำขอที่ผิดปกติจำนวนมาก ควรเปิดโหมดฉุกเฉินทันที

สัญญาณบ่งชี้ DDoS ทั่วไป

• ปริมาณทราฟฟิกเพิ่มขึ้น 5, 10 หรือ 50 เท่าในเวลาสั้น ๆ
• มีคำขอจำนวนมากต่อวินาทีไปยังหน้าเดียวหรือ endpoint เดียว
• ทราฟฟิกมาจากหลายประเทศแต่ใช้ user-agent คล้ายกัน
• เป้าหมายคือ URL ที่ใช้ทรัพยากรสูง เช่น หน้า admin, login, search หรือ cart ใน WordPress, WooCommerce, OpenCart หรือซอฟต์แวร์เฉพาะ
• ทรัพยากรของเซิร์ฟเวอร์ เช่น CPU, RAM, worker PHP-FPM หรือการเชื่อมต่อ MySQL ถูกใช้จนเต็ม
• ใน Cloudflare Analytics มีข้อผิดพลาด 4xx และ 5xx เพิ่มขึ้นอย่างรวดเร็ว
• ผู้ใช้จริงสามารถเข้าถึงเว็บไซต์เป็นบางช่วง แต่บอทยังยิงคำขอจำนวนมากอย่างต่อเนื่อง

ตัวอย่างเช่น เว็บไซต์อีคอมเมิร์ซที่ปกติรับคำขอต่อวินาที 2,000 ครั้ง แต่ภายใน 10 นาทีพุ่งเป็น 80,000 ครั้งและ 70% ของคำขอเหล่านั้นเป็นการเข้าถึงหน้ารถเข็นหรือค้นหา นี่คือสัญญาณโจมตี Layer 7 ที่ชัดเจน ควรเปิดโหมด Under Attack ภายใน 5 นาทีแรก แล้วตามด้วยการตั้งค่ากฎ WAF และ rate limiting เฉพาะจุดเป้าหมาย

ควรใช้โหมด Cloudflare Under Attack เมื่อใด?

โหมด Under Attack ไม่ใช่การตั้งค่าความปลอดภัยมาตรฐานที่ควรเปิดตลอดเวลา เพราะจะมีการแสดงหน้ารอให้ผู้ใช้จริงต้องผ่านการตรวจสอบซึ่งอาจส่งผลต่อประสบการณ์โดยเฉพาะในหน้าที่เน้นการแปลง เช่น หน้าเช็คเอาท์ หรือระบบ API ดังนั้นควรเปิดเฉพาะช่วงเวลาที่เกิดการโจมตี แล้วปิดเมื่อทราฟฟิกกลับสู่ปกติ

สถานการณ์ที่เหมาะสมในการใช้

• เว็บไซต์ถูกยิงคำขอ HTTP/HTTPS อย่างหนักและผิดปกติ
• ทรัพยากรเซิร์ฟเวอร์ลดลงอย่างรวดเร็วและมีข้อผิดพลาด 502/503 เพิ่มขึ้น
• ยังไม่มีการตั้งค่ากฎ WAF เฉพาะ และต้องการเกราะป้องกันชั่วคราวที่รวดเร็ว
• บอทยิงคำขอเกินกว่าผู้ใช้จริงอย่างเห็นได้ชัด
• เป้าหมายการโจมตีเป็นหน้าเว็บฟอร์ม, หน้าเข้าสู่ระบบ หรือ endpoint การค้นหา

สถานการณ์ที่ควรระวังในการใช้

• เว็บไซต์มีการใช้งาน API หนัก ๆ, แอปมือถือ, ระบบชำระเงิน หรือ webhook ที่ต้องการการเข้าถึงอย่างราบรื่น
• ช่วงที่บอทของเครื่องมือค้นหากำลังสแกนเว็บไซต์อย่างเข้มข้น
• ผู้ใช้ในองค์กรใช้เบราว์เซอร์รุ่นเก่าหรืออยู่ในเครือข่ายจำกัด
• มีซับโดเมนที่ไม่ได้ตั้งค่า Cloudflare proxy อยู่

สำหรับเว็บไซต์ที่มี API การเปิดโหมดนี้ทั้งโดเมนอาจทำให้การเชื่อมต่อบางอย่างล้มเหลว ควรตั้งกฎ WAF เฉพาะ แผน allowlist หรือระดับความปลอดภัยต่างหากสำหรับซับโดเมน API ดูข้อมูลเพิ่มเติมได้ที่ คู่มือความปลอดภัยของ API และการจำกัดอัตรา

วิธีเปิดใช้งานโหมด Cloudflare Under Attack: ขั้นตอนทีละขั้น

ด้านล่างนี้คือเช็คลิสต์ที่ช่วยให้คุณตั้งค่าอย่างรวดเร็วในช่วงเกิดเหตุการณ์ โครงสร้างและเมนูใน Cloudflare อาจเปลี่ยนแปลงเล็กน้อยตามเวลา แต่หลักการคือเลือกโดเมนที่ต้องการ ตั้งระดับความปลอดภัย และบังคับให้ตรวจสอบทราฟฟิกผ่าน Cloudflare

1. เข้าสู่ระบบบัญชี Cloudflare

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

2. ตรวจสอบสถานะ DNS ว่าเป็น proxied หรือไม่

เพื่อให้โหมด Under Attack ทำงานได้เต็มประสิทธิภาพ ทราฟฟิกเว็บไซต์ต้องผ่าน Cloudflare เท่านั้น ตรวจสอบให้แน่ใจว่าในส่วน DNS ของโดเมน A, AAAA และ CNAME มีไอคอนเมฆสีส้ม (proxied) แสดงอยู่ หากเป็นเมฆสีเทา (DNS only) ทราฟฟิกจะไม่ผ่าน Cloudflare และไม่ได้รับการป้องกัน

หาก IP ของเซิร์ฟเวอร์ต้นทางยังเปิดเผยอยู่ ผู้โจมตีอาจข้าม Cloudflare และโจมตีตรงได้ ดังนั้นควรตั้งค่าไฟร์วอลล์ที่เซิร์ฟเวอร์ให้อนุญาตเฉพาะ IP ของ Cloudflare เท่านั้น ดูคำแนะนำเพิ่มเติมได้ที่ การตั้งค่า DNS ของ Cloudflare ทำอย่างไร

3. เปิดใช้งานโหมด Under Attack ที่เมนู Security

ในแผงควบคุม Cloudflare เลือกโดเมนที่ต้องการ จากนั้นไปที่หน้า Security หรือ Overview หาเมนู Under Attack Mode และเปิดใช้งาน บางเวอร์ชันอาจใช้ชื่อว่า I am Under Attack ใต้เมนู Security Level

การเปิดใช้งานจะมีผลทันที และควรติดตามข้อมูลใน Cloudflare Analytics, Security Events และการใช้ทรัพยากรเซิร์ฟเวอร์ร่วมกัน หาก CPU และจำนวนการเชื่อมต่อลดลง แสดงว่าโหมดนี้เริ่มช่วยได้ แต่ถ้ายังเจอปัญหาควรตั้งกฎเพิ่มเติม

4. ทดสอบประสบการณ์ผู้ใช้จริง

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

5. ระบุ URL เป้าหมายของการโจมตี

โหมด Under Attack เป็นเกราะป้องกันภาพรวม แต่ประสิทธิภาพสูงสุดได้จากการตั้งค่ากฎเฉพาะเป้าหมาย ตรวจสอบข้อมูลจาก Cloudflare Security Events, Web Analytics, และล็อกเซิร์ฟเวอร์เพื่อหา URL ที่ได้รับคำขอมาก เช่น /wp-login.php, /xmlrpc.php, /search, /cart, /api/login หรือ /checkout

เมื่อระบุ URL ได้แล้ว ให้ตั้งกฎ WAF แบบกำหนดเองที่จำกัดตามประเทศ, user-agent, วิธีการ HTTP หรือคะแนนบอท เช่น บังคับ challenge กับ IP ที่ส่งคำขอเกินขีดจำกัดสำหรับ login endpoint ดูเพิ่มเติมที่ มาตรการความปลอดภัย WordPress

เปรียบเทียบโหมด Under Attack กับเครื่องมือความปลอดภัย Cloudflare อื่น ๆ

Cloudflare มีเครื่องมือความปลอดภัยหลายตัวที่เหมาะกับวัตถุประสงค์ต่างกัน โดย Under Attack เป็นฟิลเตอร์ฉุกเฉินที่รวดเร็วและทั่วถึง ในขณะที่ WAF และ Rate Limiting มุ่งเน้นการป้องกันแบบเจาะจงและรักษาสมดุลประสบการณ์ผู้ใช้มากกว่า

แนวทางป้องกันที่ดีคือเริ่มด้วยโหมด Under Attack เพื่อลดแรงกดดันทันที ตามด้วยวิเคราะห์รูปแบบโจมตี ตั้งกฎ WAF และ Rate Limiting เฉพาะจุด สุดท้ายปรับแต่ง Cache และ Firewall ที่ฝั่งเซิร์ฟเวอร์เพื่อความมั่นคงถาวร

ตั้งค่าที่แนะนำเพิ่มเติมระหว่างการโจมตี

แม้เปิดโหมด Under Attack ได้ง่าย แต่อุปสรรคความสำเร็จของการป้องกัน DDoS อยู่ที่การตั้งค่ารองรับที่เหมาะสม ดังนี้

ใช้กฎ WAF เพื่อป้องกันเป้าหมายเฉพาะ

กฎ WAF ช่วยให้คุณตั้งค่าการจัดการคำขอที่มาจากเงื่อนไขต่าง ๆ เช่น เฉพาะ POST จากบางประเทศไปยัง /wp-login.php สามารถตั้ง challenge ได้โดยไม่ทำให้เว็บไซต์ทั้งหมดช้าลง

• จำกัดการเข้าถึงหน้า admin และ login เฉพาะบางประเทศหรือ IP
• บล็อก endpoint ที่ไม่ได้ใช้ เช่น XML-RPC
• ใช้ managed challenge กับ user-agent ที่น่าสงสัย
• ตั้ง rate limit กับ IP ที่ยิงคำขอถี่เกินบน URI เฉพาะ

ตั้งค่า Cache ให้เหมาะสม

เมื่อเซิร์ฟเวอร์ต้นทางต้องตอบคำขอทุกครั้งในช่วงโจมตี ทรัพยากรจะหมดเร็ว ควรตั้งค่าให้ Cloudflare ให้บริการไฟล์สแตติก เช่น รูปภาพ CSS JavaScript และหน้าเว็บที่แคชได้ผ่าน edge server สำหรับเว็บที่มีเนื้อหาส่วนใหญ่เป็นไดนามิกอย่าง WordPress สามารถใช้ปลั๊กอินแคชร่วมกับกฎ Cache ของ Cloudflare และ header cache-control ได้

เช่น เว็บไซต์ข่าวหรือบล็อกที่มีผู้เยี่ยมชมทั่วไป สามารถตั้งค่าให้แคชหน้าเว็บ 5-30 นาที ช่วยลดเวลาตอบสนอง (TTFB) และลดภาระโฮสติ้ง ดูเทคนิคเพิ่มได้ที่ คู่มือการเร่งความเร็วเว็บไซต์

กำหนดค่า Rate Limiting อย่างเหมาะสม

Rate limiting มีประสิทธิภาพสูงกับ endpoint ที่ใช้ทรัพยากรมาก แต่หากตั้งค่าผิดอาจบล็อกผู้ใช้จริง เช่น หน้า search ปกติผู้ใช้ค้นหาได้ 5-15 ครั้งต่อนาที แต่ 100 ครั้งต่อนาทีถือว่าผิดปกติ หน้า login ที่มีการลองผิดลองถูกเกิน 10 ครั้งใน 5 นาทีควรตั้งข้อสงสัย

ตัวอย่างเช่น ตั้ง managed challenge กับ IP ที่ยิงเกิน 10 ครั้งต่อนาทีที่ /wp-login.php และบล็อกชั่วคราว IP ที่เกิน 50 ครั้งใน 5 นาที สำหรับ API ควรกำหนดจำกัดละเอียดตาม session, IP, token และ method

ซ่อน IP ต้นทางและจำกัดด้วยไฟร์วอลล์

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

ควรตั้งค่าไฟร์วอลล์ให้เซิร์ฟเวอร์เปิดพอร์ต 80 และ 443 เฉพาะกับ IP ของ Cloudflare เท่านั้น และล็อกพอร์ตอื่น ๆ เช่น SSH, แผงควบคุม ฐานข้อมูล ให้จำกัด IP, ใช้รหัสผ่านแข็งแรง, เปิดใช้งาน 2FA หรือ VPN ดูคำแนะนำเพิ่มได้ที่ การตั้งค่าความปลอดภัย cPanel และ การกำหนดค่าฟิลด์วอลล์ VPS

คำแนะนำเฉพาะสำหรับ WordPress, WooCommerce และไซต์องค์กร

เว็บไซต์แต่ละประเภทมีลักษณะทราฟฟิกต่างกัน โหมด Under Attack อาจส่งผลต่างกัน จึงควรตั้งค่าให้เหมาะสมกับแต่ละประเภท

เว็บไซต์ WordPress

ไฟล์ที่ถูกโจมตีบ่อยคือ /wp-login.php และ /xmlrpc.php หากไม่ใช้ XML-RPC ควรบล็อกได้เพื่อความปลอดภัย สำหรับหน้าแอดมินควรจำกัดประเทศหรือ IP และตรวจสอบว่าปลั๊กอินความปลอดภัยไม่ขัดแย้งกับ Cloudflare challenge เพราะอาจทำให้ผู้ใช้ติดลูปตรวจสอบ

ร้านค้า WooCommerce

หน้ายอดนิยม เช่น รถเข็น, ชำระเงิน และบัญชีผู้ใช้ เป็นหน้าที่มีเนื้อหาไดนามิก จึงไม่ควรตั้ง cache อย่างเข้มงวด โหมด Under Attack ควรตรวจสอบให้ callback จากผู้ให้บริการชำระเงินและ webhook ทำงานได้ หากจำเป็นให้เพิ่ม IP ของผู้ให้บริการใน allowlist หรือเขียนกฎเฉพาะสำหรับ endpoint เหล่านั้น

เว็บไซต์องค์กรและ API

พอร์ทัลองค์กร, การเชื่อมต่อ CRM และ API สำหรับแอปมือถืออาจไม่รองรับหน้าจอ challenge ของ JavaScript ดังนั้นควรแยกจัดการ API ด้วยการตั้งค่า WAF, rate limiting และ allowlist แยกต่างหาก เช่น เปิดโหมด Under Attack เฉพาะ www.example.com และตั้งความปลอดภัยแบบ token หรือ allowlist สำหรับ api.example.com

ตัวชี้วัดที่ควรติดตามหลังเปิดโหมด Under Attack

การประเมินผลความสำเร็จต้องดูข้อมูลเชิงตัวเลข ไม่ใช่แค่เว็บไซต์เปิดได้เท่านั้น ต้องดูความผิดพลาด, ภาระเซิร์ฟเวอร์ และพฤติกรรมผู้ใช้ร่วมกัน

• Cloudflare Security Events: แสดงกฎที่บล็อกหรือท้าทายคำขอกี่รายการ
• รหัสสถานะ HTTP: ดูการเปลี่ยนแปลงของข้อผิดพลาด 403, 429, 502, 503, 504
• การใช้ CPU และ RAM ของเซิร์ฟเวอร์: ควรลดลงหลังเปิดโหมด
• การเชื่อมต่อ PHP-FPM และ MySQL: ช่วยบ่งชี้ว่าระบบแอปพลิเคชันผ่อนคลายไหม
• แบนด์วิดท์และจำนวนคำขอ: เปรียบเทียบคำขอที่ถูกกรองกับคำขอทั้งหมด
• อัตราการแปลงของผู้ใช้จริง: ตรวจสอบฟอร์ม คำสั่งซื้อ การเข้าสู่ระบบ และขั้นตอนชำระเงิน

ตัวอย่างเช่น หากจำนวนคำขอรวมเท่าเดิม แต่คำขอที่ถึง origin ลดลง 60% แสดงว่า Cloudflare ดูดซับภาระได้ดี ถ้า MySQL และ CPU ยังสูง อาจมีคำขอซับซ้อนที่ต้องตรวจสอบในล็อกแอปพลิเคชัน

ปิดโหมด Under Attack หลังโจมตีเสร็จอย่างไรให้ปลอดภัย?

ไม่แนะนำให้เปิดโหมดนี้ถาวรหลังการโจมตี เพราะการแสดงหน้าตรวจสอบกับผู้ใช้ทุกคนอาจลดอัตราการแปลงและประสิทธิภาพ SEO การปิดต้องทำอย่างรอบคอบ

ขั้นตอนกลับสู่สภาพปกติอย่างปลอดภัย

• รอให้ทราฟฟิกกลับสู่ระดับปกติอย่างน้อย 30-60 นาที
• ตรวจสอบจำนวนการท้าทายและบล็อกใน Cloudflare Security Events ว่าลดลงแล้ว
• ก่อนปิดโหมดตรวจสอบว่ากฎ WAF และ rate limiting เฉพาะจุดถูกเปิดใช้งานแล้ว
• ปรับระดับความปลอดภัยเป็น High หรือ Medium เพื่อความสมดุล
• ทดสอบเว็บไซต์จากหลายอุปกรณ์และติดตามข้อผิดพลาด 5xx
• ตรวจสอบล็อกอย่างน้อย 24 ชั่วโมงเพื่อเฝ้าระวังการโจมตีซ้ำ

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

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

ในสถานการณ์ตึงเครียด การตัดสินใจผิดพลาดมักเกิดขึ้นบ่อย เช่น

• คิดว่าเปิดโหมด Under Attack โดยไม่ตั้ง DNS เป็น proxied ก็ปลอดภัย
• ปล่อยให้ IP ต้นทางเปิดเผยและไม่จำกัดการเข้าถึงนอก Cloudflare
• ตั้ง challenge กับโดเมนทั้งหมดโดยไม่ทดสอบ API, webhook หรือ callback ชำระเงิน
• ตั้งกฎ WAF ที่กว้างเกินไปจนบล็อกผู้ใช้จริง
• ตั้งค่าแคชอย่างเข้มงวดกับหน้ารถเข็น, ชำระเงิน หรือบัญชีผู้ใช้
• ปล่อยให้โหมดเปิดนานเป็นสัปดาห์หลังโจมตีเสร็จ
• ตัดสินใจจากหน้าจอ Cloudflare อย่างเดียวโดยไม่ดูล็อกเซิร์ฟเวอร์

โดยเฉพาะเว็บไซต์อีคอมเมิร์ซ การบล็อก callback การชำระเงินอาจทำให้เสียรายได้อย่างรุนแรง จึงควรทดสอบกฎแบบบันทึกรายการก่อน (log หรือ managed challenge) ก่อนเพิ่มความเข้มข้น

การวางแผนป้องกันที่แข็งแกร่งบนโครงสร้าง Hostragons

Cloudflare เป็นชั้นป้องกันแรกที่แข็งแรง แต่การป้องกัน DDoS ที่สมบูรณ์ต้องผสานกับโครงสร้างโฮสติ้ง การปรับแต่งซอฟต์แวร์ การตั้งค่า SSL การจัดการ DNS และกลยุทธ์สำรองข้อมูลสำหรับเว็บที่โฮสต์บน Hostragons ควรตั้งแนวทางว่า Cloudflare กรองทราฟฟิกก่อนเข้าโฮสต์จริง โฮสต์รับเฉพาะทราฟฟิกที่ผ่านการกรองแล้ว และแอปพลิเคชันต้องออกแบบให้ลดภาระฐานข้อมูล

ก่อนเปิดตัวโปรเจ็กต์ใหม่ ต้องมั่นใจว่า DNS ถูกตั้งอย่างถูกต้อง, SSL ติดตั้งเรียบร้อย และเซิร์ฟเวอร์เหมาะกับโปรไฟล์ทราฟฟิกของคุณ ดูข้อมูลเพิ่มเติมได้ที่ การตรวจสอบโดเมนและการลงทะเบียนชื่อโดเมน, แพ็คเกจการโฮสต์เว็บไซต์, โซลูชันโฮสติ้งธุรกิจ, และ ใบรับรอง SSL ฟรี

สำหรับโปรเจ็กต์ที่มีทราฟฟิกสูงหรือเสี่ยงถูกโจมตี ควรพิจารณา VPS หรือเซิร์ฟเวอร์จัดการ แทนการใช้โฮสติ้งแชร์ธรรมดา เพื่อให้สามารถตั้งค่า firewall, เว็บเซิร์ฟเวอร์, PHP-FPM, Redis, object cache และฐานข้อมูลได้ยืดหยุ่น แต่ไม่ว่าจะเลือกโครงสร้างใด โหมด Under Attack ควรใช้เป็นเครื่องมือฉุกเฉินเท่านั้น และต้องมีระบบความปลอดภัยถาวรด้วย WAF, วิเคราะห์ล็อก และอัปเดตสม่ำเสมอ

เช็คลิสต์ด่วน: 15 นาทีแรกเมื่อเกิดการโจมตี DDoS

เวลาคือสิ่งสำคัญในเหตุการณ์โจมตี ด้านล่างคือรายการที่ทีมเทคนิคหรือเจ้าของเว็บไซต์ควรทำใน 15 นาทีแรก

• ล็อกอินแผงควบคุม Cloudflare และเลือกโดเมนถูกต้อง
• ตรวจสอบ DNS ว่าเป็น proxied (เมฆส้ม) แล้ว
• เปิดใช้งานโหมด Under Attack
• ทดสอบหน้าแรก, หน้า login, รถเข็น, การชำระเงิน และ API endpoint
• วิเคราะห์ Cloudflare Security Events เพื่อหาจุดเป้าหมาย
• ตั้งกฎ WAF หรือ rate limiting สำหรับ URL ที่โจมตีมากที่สุด
• ตรวจสอบการใช้ CPU, RAM, PHP-FPM และ MySQL ของเซิร์ฟเวอร์
• ทดสอบว่า IP ต้นทางถูกปิดไม่ให้เข้าถึงโดยตรงหรือไม่
• ตรวจสอบว่าจำเป็นต้องตั้ง allowlist สำหรับผู้ให้บริการชำระเงิน, webhook หรือระบบสำคัญอื่น ๆ
• จดบันทึกเวลาทำงานและการตั้งค่าทุกขั้นตอน

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

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

โหมด Cloudflare Under Attack ป้องกันเว็บไซต์ได้เต็มที่ไหม?

ไม่ใช่ โหมดนี้เน้นลดทราฟฟิกบอทและ flood ที่ระดับ HTTP/HTTPS เท่านั้น ไม่ใช่การป้องกันแบบครบวงจร ต้องใช้ร่วมกับ DNS proxied, ซ่อน IP ต้นทาง, กฎ WAF, rate limiting, cache และไฟร์วอลล์ของเซิร์ฟเวอร์

โหมด Under Attack ส่งผลเสียต่อ SEO หรือไม่?

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

ควรเปิดโหมด Under Attack นานแค่ไหน?

เปิดจนกว่าการโจมตีจะลดลง จากนั้นติดตามอย่างน้อย 30-60 นาที ก่อนปิด พร้อมกับตั้งกฎ WAF และ rate limiting เพื่อป้องกันต่อเนื่อง

โหมดนี้กระทบ API หรือระบบชำระเงินไหม?

กระทบได้ เพราะบาง API หรือระบบ webhook ไม่รองรับการตรวจสอบแบบเบราว์เซอร์ จึงต้องทดสอบและตั้ง allowlist หรือกฎเฉพาะสำหรับ endpoint เหล่านั้น

ต้องตั้งค่าความปลอดภัยฝั่งโฮสติ้งเพิ่มไหม?

ต้องทำแน่นอน Cloudflare ช่วยกรองทราฟฟิกชั้นแรก แต่ต้องซ่อน IP ต้นทาง จำกัดไฟร์วอลล์ อัปเดตซอฟต์แวร์ และตั้งค่า cache อย่างถูกต้อง เพื่อความปลอดภัยและความเสถียรในระยะยาว

สรุป

โหมด Cloudflare Under Attack เป็นเครื่องมือฉุกเฉินที่มีประสิทธิภาพเมื่อต้องรับมือกับ DDoS ช่วยลดทราฟฟิกบอทและลดภาระเซิร์ฟเวอร์ได้ทันทีเมื่อเปิดใช้งานอย่างถูกต้องร่วมกับ DNS proxied การตั้งกฎ WAF, rate limiting, การปรับแต่ง cache และไฟร์วอลล์ของเซิร์ฟเวอร์ต้นทาง

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