เราไม่ทำอะไรเลยกับความพยายามโจมตี DDoS ที่ดำเนินต่อเนื่องมาหลายสัปดาห์

 (tableplus.com)
1 คะแนน โดย GN⁺ 2024-03-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

กำลังถูกโจมตี DDoS แต่ไม่ได้ทำอะไรเลย

  • ตลอดหลายสัปดาห์ที่ผ่านมา มีใครบางคนพยายามโจมตีแบบ DDoS
  • พวกเขาส่งคำขอเข้ามายังเซิร์ฟเวอร์นับล้านครั้ง เพื่อพยายามดาวน์โหลดไฟล์คอนฟิกนับล้านครั้ง
  • เฉพาะในช่วง 5 วันที่ผ่านมา มีความพยายามดาวน์โหลดมากกว่า 800,000 ครั้ง โดยไฟล์คอนฟิกมีขนาดประมาณ 200MB ต่อการดาวน์โหลดหนึ่งครั้ง
  • ทราฟฟิกส่วนใหญ่มาจากสหภาพยุโรป โดยเฉพาะเยอรมนีและสหราชอาณาจักร
  • การโจมตียังคงดำเนินอยู่แม้ในขณะที่กำลังเขียนบล็อกโพสต์นี้

สิ่งที่เราทำในสถานการณ์เร่งด่วนนี้

  • ไม่บล็อกที่อยู่ IP ของผู้โจมตี
  • ใช้ Cloudflare แต่ไม่ได้เปิดโหมด "Under Attack"
  • ระหว่างการโจมตี CPU ของเซิร์ฟเวอร์แทบจะว่างอยู่เกือบตลอดเวลา
  • โดยทั่วไปคือแทบไม่ได้ทำอะไรเลย

ทำไมถึงเป็นแบบนั้น?

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

เป็นไปได้อย่างไร?

  • การออกแบบของแอป TablePlus เรียบง่าย และแนวคิดนี้ก็ถูกนำมาใช้กับบริการแบ็กเอนด์ที่คงความมินิมอลไว้เช่นกัน
  • ไม่ใช้บริการจากผู้ให้บริการภายนอกอย่าง Vercel หรือ Netlify แต่ใช้เว็บเซิร์ฟเวอร์ที่ไม่มีข้อจำกัดแทน
  • ในอดีต สถาปัตยกรรมแบบ monolithic เคยกลายเป็นคอขวดเพราะ VPS/โปรเซสเซอร์ที่อ่อนแอ แต่ทุกวันนี้ VPS ที่ทรงพลังสามารถรองรับคำขอได้หลายพันล้านครั้งต่อเดือนบนอินสแตนซ์เดียว
  • ดังนั้นจึงสร้างบริการแบบ monolithic สำหรับแต่ละแอป ทำให้ง่ายต่อการดีพลอยและบำรุงรักษา

มาคุยกันเรื่อง monolithic

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

เฟรมเวิร์กเว็บเดี่ยวใน Go หรือ Rust หากพัฒนาได้อย่างถูกต้อง ก็สามารถรองรับคำขอได้หลายพันล้านครั้งต่อเดือน

  • เลือกเฟรมเวิร์กประสิทธิภาพสูง
  • ทำดัชนีฐานข้อมูลเพื่อลดเวลาในการดึงข้อมูลเมื่อชุดข้อมูลมีขนาดใหญ่ขึ้น
  • แยกฐานข้อมูลหลักออกจากฐานข้อมูล log/usage เพื่อไม่ให้ปัญหาด้านประสิทธิภาพมากระทบธุรกิจหลัก
  • ใช้ reverse proxy ที่ทรงพลังอย่าง Nginx เพื่อจัดการและกระจายคำขอไปยัง API หลัก
  • วางทุกอย่างไว้หลัง Cloudflare และตั้งค่าอย่างเหมาะสม
  • ใช้ CDN ที่มีการป้องกัน DDoS
  • อย่าเก็บไฟล์ดาวน์โหลดขนาดใหญ่ไว้บน VPS โดยไม่มี CDN หรือแคช

มาคุยกันเรื่องการดีพลอย

  • ที่ TablePlus กระบวนการดีพลอยถูกทำให้ง่ายที่สุดเท่าที่จะเป็นไปได้
  • ไม่ใช้ Docker, Kubernetes หรือคอนเทนเนอร์ และไม่ต้องตั้งค่า environment
  • ใช้ไบนารี ไบนารีสามารถคัดลอกแล้วรันเป็นโปรเซสบนเซิร์ฟเวอร์ Linux ได้
  • เลือกใช้ Go และ Rust เพราะเป็นภาษาประสิทธิภาพสูงและสามารถสร้างไฟล์ไบนารีสำหรับการดีพลอยได้

อัปเดต

  • Vercel ได้ติดต่อเข้ามาและบอกว่ามีฟีเจอร์ที่ช่วยปกป้องเว็บไซต์ในสถานการณ์แบบนี้ได้
  • ผ่านการจัดการค่าใช้จ่าย สามารถตั้งขีดจำกัดการใช้จ่ายได้ และมีโหมด challenge สำหรับการโจมตีที่คล้ายกับโหมด "Under Attack" ของ CF

ความเห็นของ GN⁺

  • บทความนี้เน้นย้ำถึงความสำคัญของโครงสร้างพื้นฐานที่แข็งแกร่งและกลยุทธ์การดีพลอยที่เรียบง่าย ซึ่งทำให้สามารถให้บริการได้อย่างเสถียรแม้เผชิญการโจมตี DDoS
  • สถาปัตยกรรมแบบ monolithic แสดงให้เห็นถึงข้อดีในด้านการลดความซับซ้อน ทำให้การดีพลอยง่ายขึ้น และเอื้อต่อการปรับแต่งประสิทธิภาพ
  • การใช้บริการคลาวด์และ CDN อย่างมีประสิทธิภาพเพื่อสร้างความทนทานต่อการโจมตี DDoS เป็นกรณีศึกษาที่ดีสำหรับบริษัทอื่น
  • แนวทางนี้ยังมอบมุมมองเกี่ยวกับการสร้างโครงสร้างพื้นฐานที่คุ้มค่าต้นทุน โดยเฉพาะสำหรับสตาร์ทอัพระยะเริ่มต้นหรือธุรกิจขนาดเล็กและกลาง
  • อย่างไรก็ตาม แนวทางแบบ monolithic ไม่ได้เหมาะกับทุกระบบหรือทุกแอปพลิเคชันเสมอไป ดังนั้นการเลือกสถาปัตยกรรมให้เหมาะกับความต้องการและสถานการณ์ของแต่ละกรณีจึงเป็นสิ่งสำคัญ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-31
ความคิดเห็นจาก Hacker News

  • สรุปความคิดเห็นแรก:

    • ผู้แสดงความคิดเห็นคิดว่าการอวดเรื่องประสิทธิภาพของเว็บไซต์นั้นเกินจริง
    • "1 พันล้านคำขอต่อเดือน" เทียบได้กับเพียงไม่กี่ร้อยคำขอต่อวินาที ซึ่งเป็นระดับเล็กน้อยและยังถือเป็น DDoS ไม่ได้
    • เนื่องจากไซต์อยู่หลัง CDN (Cloudflare) จึงดูเหมือนไม่ได้ทำอะไรเป็นพิเศษในด้านประสิทธิภาพ
    • การที่ไฟล์ขนาด 200MB ถูกแคชและให้บริการผ่าน CDN เป็นเรื่องปกติอยู่แล้ว และการนำมาอวดจึงดูเหมือนเป็นการออกแบบที่ไม่เหมาะสม

  • สรุปความคิดเห็นที่สอง:

    • ทราฟฟิก 4TB ต่อเดือนยากจะมองว่าเป็นการโจมตี DDoS
    • 6 ล้านคำขอต่อเดือนคิดเป็นเพียง 2 คำขอต่อวินาที และในระดับนี้การรันบริการเดี่ยว (monolith service) ก็ไม่ใช่ปัญหา
    • คาดว่าคำขอส่วนใหญ่จะถูก Cloudflare จัดการด้วยการแคชในระดับ CDN

  • สรุปความคิดเห็นที่สาม:

    • เว็บไซต์เป็นเพียงไซต์การตลาดแบบสแตติกธรรมดา ไม่มีฟอรัมสนทนา และรับฟีดแบ็กผ่าน GitHub Issues
    • การอวดว่าสามารถจัดการการดาวน์โหลดไฟล์สแตติกหลายล้านครั้งต่อวันด้วยการดีพลอยแบบง่าย ๆ นั้นดูแปลก
    • Cloudflare เป็นผู้ทำงานบรรเทาทั้งหมด และจริง ๆ แล้วทราฟฟิกอาจน้อยเกินกว่าจะต้องใช้ด้วยซ้ำ

  • สรุปความคิดเห็นที่สี่:

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

  • สรุปความคิดเห็นที่ห้า:

    • 50 ล้านคำขอต่อเดือนจากสหราชอาณาจักรอาจเกิดจากสคริปต์ตัวเดียวที่รันอยู่ได้
    • ผู้เขียนคาดว่าเซิร์ฟเวอร์ Go จะรองรับคำขอได้มากกว่านี้ 250 เท่าต่อวินาทีแม้ไม่ต้องปรับแต่ง
    • ตัวคำแนะนำเองไม่ได้แย่ แต่ตัวเลขของพวกเขาไม่ได้เป็นหลักฐานรองรับคำแนะนำนั้น

  • สรุปความคิดเห็นที่หก:

    • การแจกจ่ายไบนารีอาจน่าพึงพอใจกว่าการใช้ Docker แต่ก็มีประเด็นด้านความปลอดภัยของโฮสต์ที่รันไบนารีนั้น
    • บริการเดี่ยว (monolith service) เพียงตัวเดียวที่โฮสต์บน VPS เดียวนั้นราคาถูกและดี แต่หากฮาร์ดแวร์มีปัญหาก็อาจเกิดดาวน์ไทม์ค่อนข้างมาก
    • การรวมทุกอย่างไว้ในบริการเดียวอาจทำให้สูญเสียการป้องกันหลายชั้น (defence in depth) และหากเกิดปัญหาด้านความปลอดภัย ก็อาจเปิดทางให้เข้าถึงที่เก็บข้อมูลได้

  • สรุปความคิดเห็นที่เจ็ด:

    • "1 พันล้านคำขอต่อเดือน" เป็นระดับที่เซิร์ฟเวอร์เดี่ยวจัดการได้ และสคริปต์ที่ผิดพลาดเพียงตัวเดียวก็อาจสร้างทราฟฟิกระดับนี้ได้

  • สรุปความคิดเห็นที่แปด:

    • ตั้งคำถามว่าคำขอระดับหลายพันล้านต่อเดือนถือเป็นการโจมตี DDoS ขนาดใหญ่จริงหรือไม่

  • สรุปความคิดเห็นที่เก้า:

    • การสร้างบริการเดี่ยว (monolith service) สำหรับแต่ละแอปทำให้ดีพลอยและบำรุงรักษาได้ง่าย
    • ไม่ต้องใช้ Docker, Kubernetes, dependency หรือ runtime environment แค่ดีพลอยไฟล์ไบนารีเท่านั้น

  • สรุปความคิดเห็นที่สิบ:

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