จะหยุดบอตบน AWS ที่ส่งคำขอ 2 พันล้านครั้งต่อเดือนได้อย่างไร?

• เกิดปัญหา คำขอเว็บปริมาณมหาศาล แบบไม่คาดคิดบน โครงสร้างพื้นฐาน AWS
• มีรายงานว่าทราฟฟิกพุ่งขึ้นอย่างรวดเร็วจาก 200 ล้านครั้งเป็น 2 พันล้านครั้ง ต่อเดือน
• จากการวิเคราะห์ล็อกพบว่ามีการส่งคำขอซ้ำจาก User-Agent เฉพาะตัวหนึ่ง
• แม้จะติดต่อทีมสนับสนุนของ AWS แล้ว แต่ก็ยังไม่ได้รับ แนวทางแก้ไขที่ชัดเจน
• จำเป็นต้องพิจารณาวิธีบล็อกหลายรูปแบบ เช่น การตั้งกฎไฟร์วอลล์ การบล็อก User-Agent เป็นต้น

---

เกริ่นนำปัญหา

• ผู้ใช้ AWS รายหนึ่งตั้งคำถามเกี่ยวกับปรากฏการณ์ที่มี คำขอ 2B (2 พันล้านครั้ง) เกิดขึ้นบนเว็บเซิร์ฟเวอร์ตลอดหนึ่งเดือน
• คำขอเหล่านี้มาจาก บอตที่ใช้ User-Agent เฉพาะ และเป็นทราฟฟิกผิดปกติที่ไม่สอดคล้องกับรูปแบบการใช้งานตามปกติ
• การเพิ่มขึ้นของทราฟฟิกอย่างฉับพลันมีความเสี่ยงที่จะนำไปสู่ ค่าใช้จ่ายที่สูงขึ้นและภาระต่อระบบ

การวิเคราะห์สาเหตุ

• ในบรรดาคำขอจำนวนมหาศาลนั้น ส่วนใหญ่ไหลเข้ามาจาก ช่วง IP ของ AWS ที่น่าสงสัย
• จากบันทึกการเข้าถึงพบว่า บอตหรือสคริปต์บางตัว เป็นสาเหตุ
• มีรูปแบบร่วมกันอยู่ใน User-Agent จึงสามารถนำไปใช้ในการ กรอง ได้

การรับมือเดิมและข้อจำกัด

• แม้จะสอบถาม ทีมสนับสนุน AWS แล้ว แต่ก็ยังไม่ได้รับแนวทางที่ชี้ขาด
• คำขอจำนวนมหาศาลลักษณะนี้มีโอกาสสูงที่จะทำให้เกิด บริการล่มและภาระด้านค่าใช้จ่าย เพิ่มขึ้น

แนวทางแก้ไขและประเด็นที่ต้องพิจารณา

• ต้องพิจารณานโยบายการบล็อกหลายรูปแบบ เช่น เพิ่มกฎไฟร์วอลล์, บล็อกทราฟฟิกตาม User-Agent, การใช้บัญชีดำ IP เป็นต้น
• ในระยะยาว มีความจำเป็นที่จะต้อง เสริมความแข็งแกร่ง ให้ระบบมอนิเตอร์ทราฟฟิก และวางโครงสร้างสำหรับการตรวจจับการเข้าถึงผิดปกติและบล็อกอัตโนมัติ

[GN⁺]

ความเห็นจาก Hacker News

• เคยลองใช้ 30x redirect มาก่อน เช่น ส่ง 301 เพื่อนำไปยังไฟล์ขนาดใหญ่มากที่โฮสต์โดยบริษัทที่ฉันไม่ชอบ ถ้าทำให้ AWS instance ของบริษัทนั้นดาวน์โหลด Windows ISO 70,000 ไฟล์พร้อมกัน พวกเขาก็น่าจะสังเกตเห็นแน่ นอกจากนี้แม้จะทำกับ Cloudflare ได้ไม่ง่าย แต่ก็ยังใช้กลยุทธ์ที่เรียกว่า ‘tar pit’ ได้ คือหลังรับคำขอแล้วค่อย ๆ ส่งคำตอบออกไปทีละตัวอักษร โดยหน่วง 30 วินาทีต่ออักขระ ถ้ามีคำขอ 700 ครั้งต่อวินาที โดยมี header/response ขนาด 10KB ต่อคำขอ มันจะทำให้ดูเหมือนเซิร์ฟเวอร์ช้ามาก
  • ถ้าไม่ชอบจะให้ redirect ไปยังบริษัทใดบริษัทหนึ่ง ก็แนะนำให้ชี้ไปที่อย่าง Amazon แทน
  • กลยุทธ์รับคำขอแล้วค่อย ๆ ส่งทีละตัวอักษร ดูเหมือนจะเป็นวิธีตรงข้ามกับการโจมตี DDoS แบบ Slow Loris สำหรับคำอธิบายเรื่อง Slow Loris ดูได้จาก Cloudflare กล่าวคือไม่ใช่ฝ่ายโจมตีที่ใช้การเชื่อมต่อช้า แต่เป็นฝ่ายป้องกันที่ตอบโต้ด้วยการเชื่อมต่อช้าแทน
  • อีกทางเลือกคือทำ 301 redirect ไปยังเว็บไซต์รัฐบาลทางการของ .sg เพื่อให้หน่วยงานบังคับใช้กฎหมายท้องถิ่นจัดการ
  • ชี้ให้เห็นว่า inbound traffic ของ AWS ฟรี ดังนั้นต่อให้เจ้าของ instance รับข้อมูลมหาศาล AWS ก็จะไม่คิดค่าใช้จ่ายเพิ่ม
• อีกวิธีคือทำให้บอตที่เป็นอันตรายมีต้นทุนในการรันสูงขึ้น โดยเฉพาะวิธีอย่าง gzip bomb ที่ได้ผลถ้าบอตมีช่องโหว่ แต่แค่หน่วงก่อนตอบกลับสัก 10 วินาทีก็อาจบังคับให้เซิร์ฟเวอร์ใช้พอร์ตราว 7,000 พอร์ตได้แล้ว ซึ่ง process บน Linux ส่วนใหญ่รับไม่ไหวจนตายได้ ทำได้ง่ายด้วย nginx + mod-http-echo
  • มีคนทำกลยุทธ์แบบนี้ใช้งานจริงแล้ว ดูได้จากรายชื่อ user agent ในโค้ดโอเพนซอร์ส และตัว implementation เองก็ง่ายมาก ซอร์สที่เกี่ยวข้องดูได้ที่นี่
  • ลูกค้า AWS ต้องจ่ายค่า outbound traffic แต่ก็สงสัยเหมือนกันว่ามีวิธีทำให้ทราฟฟิกปริมาณมากถูกส่งจากฝั่ง AWS หรือ Cloudflare มาหาเราแทนได้หรือไม่
  • เคยเจอสถานการณ์คล้ายกัน มีการ scrape ข้อมูลราคาบนเว็บเราแบบมุ่งร้ายซ้ำ ๆ และสินค้าบนแคตตาล็อกมีเป็นล้านรายการ การคำนวณราคาแบบไดนามิกจึงใช้ทรัพยากรมหาศาล พอมีคำขอถาโถมเข้ามากะทันหัน อินฟราของเราก็แทบรับไม่ไหวจนเกือบล่ม กลยุทธ์ป้องกันที่ลองคือแท็ก spam traffic แยกออกมาเพื่อ cache โดยไม่กระทบลูกค้าจริง และยังเคยคุยกันเรื่องใส่ค่าความคลาดเคลื่อนแบบสุ่มลงในราคาเพื่อทำให้ข้อมูลไร้ความหมาย สุดท้ายก็มาจบที่ทำงานร่วมกับ Cloudflare เพื่อบล็อกคำขออันตรายอย่างรวดเร็ว แต่ก็เสียทั้งเวลาและค่าใช้จ่ายมาก คาดว่าผู้โจมตีน่าจะเป็นบริการรับจ้างของคู่แข่ง ทั้งที่จริง ๆ เราก็มี API ทางการให้ใช้อยู่แล้ว น่าเสียดายที่เขาไม่ติดต่อมาโดยตรง สมัยก่อนคนมักมองว่า "ถ้าเว็บรับทราฟฟิกไม่ไหวก็เป็นความผิดเว็บเอง" แต่เดี๋ยวนี้ความคิดคนเปลี่ยนไปมากแล้ว
  • ถ้าทำแบบนั้น เซิร์ฟเวอร์ของฉันเองก็จะกินพอร์ต 7,000 พอร์ตด้วยหรือเปล่า
  • ถามว่าถ้าใช้เทคนิคนี้ ฝั่งเซิร์ฟเวอร์ของเราก็จะมีการเชื่อมต่อจำนวนมากเท่ากันด้วยหรือไม่
• ฉันเป็นผู้เขียนหลักของ Anubis เอง เคยเจอว่าถ้าตั้งค่าให้ Cloudflare ส่ง HTTP 200 กลับไป บอตจะหยุดยิงเมื่อได้รับ 200
  • อ้างอิงไว้ก่อนว่าตอนนี้เว็บไซต์หลักน่าจะมีปัญหาอยู่
  • ถ้าตรวจพบใน application layer ก็เคยลองใช้วิธีตัดการเชื่อมต่อทิ้งไปเลย ซึ่งดูเหมือนจะใช้ได้กับบอตแบบบ้าน ๆ ตอนที่ตั้งค่าฝั่ง Cloudflare ทำได้ยาก
• เคยเจอเรื่องคล้ายกันกับบล็อกส่วนตัวเมื่อก่อน ประมาณ 7–8 ปีก่อน อยู่ ๆ ทราฟฟิกก็พุ่งจนคิดว่าไวรัล แต่ดูเป็นกลไกเกินไปเลยรู้สึกแปลก พอหาสาเหตุก็พบว่ามีบอต/ครอว์เลอร์ของใครสักคนกำลัง scrape เว็บฉันเพื่อทดสอบอะไรบางอย่าง ฉันขออย่างสุภาพหลายครั้งตลอดหลายเดือนก็ไม่เป็นผล สุดท้ายเลย redirect บอตนั้นไปยังเว็บโป๊แบบสุ่ม แล้วการ crawl ก็หยุดลง
  • วิธีนี้ใช้ได้ผลจริงที่สุดแล้ว ลอง redirect ไปยังที่ที่ไม่อยากให้ไปโผล่ใน crawler log หรือส่งกลับไปหาตัวเอง ผู้ให้บริการของมัน หรือคอนเทนต์ที่มันไม่ต้องการก็ได้
• การส่ง 200 response ที่มี EICAR test string อยู่ใน body เพื่อทำให้ข้อมูลปนเปื้อน ก็เป็นวิธีแก้เผ็ดที่สะใจพอสมควร ดูคำอธิบาย ไฟล์ทดสอบ EICAR
  • นึกสนุกว่าในฐานะแนวคิดตรงข้ามกับการโจมตี SSRF อาจ redirect บอตไปยัง cloud metadata API เพื่อหลอกให้เรียก endpoint อย่าง <shutdown> ก็ได้ และยังใส่ EICAR test string ลงใน response redirect เพื่อให้ระบบตรวจจับความปลอดภัยอัตโนมัติทำงานด้วย
• ถ้าไม่มีเหตุผลที่จะต้องรับทราฟฟิกปกติจาก AWS Singapore เลย การ blackhole ทั้งช่วงไอพีนั้นทิ้งไปก็เป็นอีกทางเลือกหนึ่ง
  • ใช้ WAF ให้ดรอปแพ็กเก็ตพวกนั้นไปเลยก็ได้ ฟังก์ชัน "block" ของ Cloudflare WAF ก็มีไว้เพื่อการนี้
  • ฉันก็เคยทำแบบนี้มาก่อน ตอนนั้นบอต Byte Spider ของ Byte Dance มากวาดรูปภาพไปหลายล้านรายการ สุดท้ายถึงขั้นต้องขอให้ Cloudinary ช่วยบล็อก user agent และช่วงแรกก็เคยบล็อกทั้งสิงคโปร์ไปเลยด้วย รู้สึกโมโหมากที่บริษัท scrape AI รันบอตกันอย่างมุ่งร้าย ดีที่ใช้บริการดี ๆ อย่าง Cloudinary เลยยังพอประหยัดค่าใช้จ่ายได้ ช่วงนี้ก็จบด้วยการใช้ Cloudflare บล็อกบอต AI ทั้งหมด
  • อ้างอิงว่าแต่ละ region ของ AWS ใช้ช่วงไอพีใดบ้าง ดูได้ที่นี่
• ในปี 2018 เคยเจอเรื่องคล้ายกันแต่ขนาดเล็กกว่ามาก ฉันเลยทำเครื่องมือขึ้นมาเองให้อ่าน json list ช่วงไอพีอย่างเป็นทางการของ AWS แล้วไปบล็อกช่วงเหล่านั้นใน Windows Firewall ได้โดยตรง ดูโพสต์บล็อกที่เกี่ยวข้องได้ที่นี่ และดู readme ของเครื่องมือได้ที่นี่ มันรันเป็น scheduled job บนเซิร์ฟเวอร์มาหลายปีได้ดี แต่ตอนนี้ยังใช้ได้อยู่ไหมก็ไม่แน่ใจนัก ถ้าสนใจก็อาจเปิดโค้ดหรือส่งต่อให้คนอื่นได้ จะเขียนเองก็ไม่ได้ยากมากนัก โชคดี
• หน่วยงานกำกับดูแลการสื่อสารของสิงคโปร์ถึงขั้นห้ามการครอบครองสื่อลามกด้วย ดังนั้นจึงเสนอให้ตอบโต้บอตอันตรายด้วยการส่ง softcore กลับไป พร้อมทั้งส่งอีเมลแจ้งหน่วยงานและ AWS ไปด้วย
  • ถ้าใครสร้างความเสียหายซ้ำ ๆ บนอินเทอร์เน็ต การใช้กฎหมายของประเทศนั้นตอบโต้กลับมักได้ผลที่สุด เพราะกับหน่วยงานอื่นส่วนใหญ่แทบคาดหวังการดำเนินการอะไรไม่ได้
• ถ้าแจ้ง Cloudflare ว่าทราฟฟิกนั้นเป็นอันตราย พวกเขาสามารถบล็อกจากนอกบัญชีได้ ทำให้ฝั่งเรารับภาระด้านการนับทราฟฟิกน้อยลง
• เคยมีประสบการณ์คล้ายกัน เป็นกรณีที่มีการขอไฟล์ตัวติดตั้งซอฟต์แวร์ขนาด 80MB จำนวนมหาศาล ฉันเลย redirect คำขอที่เป็นปัญหาไปยังไฟล์ชื่อ "please-stop.txt" และเขียนอธิบายสถานการณ์พร้อมขอให้หยุดไว้ในไฟล์นั้น ปรากฏว่าเขาหยุดจริง