การโจมตี DDoS ครั้งใหญ่ที่สุดเป็นประวัติการณ์ แตะระดับสูงสุด 398 ล้าน rps
(cloud.google.com)- ขณะที่ขนาดของการโจมตี DDoS ขยายตัวอย่างรวดเร็ว Google ได้บรรเทาการโจมตีที่มีค่าสูงสุด 398 ล้าน rps ในเดือนสิงหาคม 2023 ซึ่งใหญ่กว่าสถิติเดิมในปีก่อนที่ 46 ล้าน rps ถึง 7.5 เท่า
- ผู้โจมตีใช้เทคนิค Rapid Reset ที่อาศัยช่องโหว่จากการทำ stream multiplexing ของ HTTP/2 และส่งผลกระทบต่อหลายบริษัทด้านโครงสร้างพื้นฐานอินเทอร์เน็ต
- ระลอกการโจมตีเริ่มขึ้นช่วงปลายเดือนสิงหาคม 2023 และต่อเนื่องไปจนถึงเดือนกันยายน โดยมี ผู้ให้บริการโครงสร้างพื้นฐาน รายใหญ่ รวมถึงบริการของ Google, โครงสร้างพื้นฐาน Google Cloud และลูกค้า เป็นเป้าหมาย
- Google ดูดซับการโจมตีที่ network edge และอัปเดตระบบป้องกัน ขณะที่ลูกค้าของ Application Load Balancer และ Cloud Armor ก็ได้รับการปกป้องบนพื้นฐานเดียวกัน
- เซิร์ฟเวอร์ พร็อกซี แอปพลิเคชันเซิร์ฟเวอร์ และโหลดบาลานเซอร์ที่รองรับ HTTP/2 อาจได้รับผลกระทบจาก CVE-2023-44487 จึงจำเป็นต้องตรวจสอบความเสี่ยงและติดตั้งแพตช์จากผู้ขาย
ขนาดการโจมตีและเทคนิค Rapid Reset
- DDoS Response Team ของ Google ยืนยันว่าในช่วงไม่กี่ปีที่ผ่านมา ขนาดของการโจมตี DDoS เติบโตแบบก้าวกระโดด
- การโจมตีที่ถูกบล็อกในเดือนสิงหาคม 2023 มีขนาด ใหญ่กว่าสถิติสูงสุดของปีก่อน 7.5 เท่า
- แตะระดับสูงสุดที่ 398 ล้าน requests per second (rps)
- การโจมตี DDoS ที่ใหญ่ที่สุดซึ่งบันทึกไว้ในปี 2022 อยู่ที่ 46 ล้าน rps
- การโจมตีที่กินเวลานาน 2 นาทีนี้สร้างคำขอมากกว่าจำนวนการเข้าชมบทความทั้งหมดที่ Wikipedia รายงานในเดือนกันยายน 2023 ทั้งเดือน
- เทคนิคหลักคือ HTTP/2 Rapid Reset แบบใหม่ที่ใช้ประโยชน์จากความสามารถ stream multiplexing ของ HTTP/2
เป้าหมายของการโจมตีและผลกระทบต่อบริการ
- ระลอกการโจมตีล่าสุดเริ่มขึ้นในช่วง ปลายเดือนสิงหาคม 2023 และยังถูกสังเกตต่อเนื่องตลอดเดือนกันยายน
- เป้าหมายของการโจมตีรวมถึงผู้ให้บริการโครงสร้างพื้นฐานรายใหญ่
- บริการของ Google
- โครงสร้างพื้นฐาน Google Cloud
- ลูกค้าของ Google
- Google ยังคงให้บริการต่อเนื่องผ่านระบบ global load balancing และโครงสร้างพื้นฐานสำหรับบรรเทา DDoS
- ด้วยความร่วมมือกับพาร์ตเนอร์ในอุตสาหกรรม Google สามารถระบุกลไกของการโจมตี และประสานแนวทางบรรเทาเพื่อปกป้อง Google ลูกค้า และอินเทอร์เน็ตโดยรวม
วิธีบรรเทาของ Google และการปกป้องลูกค้า Cloud
- ผลการตรวจสอบพบว่าการโจมตีนี้ใช้เทคนิค Rapid Reset โดยอาศัยความสามารถ stream multiplexing ของ โปรโตคอล HTTP/2 ที่ใช้งานอย่างแพร่หลาย
- Google บรรเทาการโจมตีที่ network edge
- ใช้การลงทุนด้านขีดความสามารถที่ edge เพื่อให้บริการของ Google และบริการของลูกค้าแทบไม่ได้รับผลกระทบ
- พัฒนาแนวทางบรรเทาหลังจากวิเคราะห์รูปแบบการโจมตีเพิ่มเติม
- อัปเดตระบบพร็อกซีและระบบป้องกันการปฏิเสธการให้บริการเพื่อลดผลของเทคนิคนี้อย่างมีประสิทธิภาพ
- Application Load Balancer และ Cloud Armor ของ Google Cloud ใช้โครงสร้างพื้นฐานฮาร์ดแวร์และซอฟต์แวร์เดียวกับที่ Google ใช้ให้บริการอินเทอร์เน็ตของตนเอง
- แอปเว็บและบริการที่เปิดสู่อินเทอร์เน็ตของลูกค้า Cloud ที่ใช้บริการเหล่านี้จึงได้รับการปกป้องในลักษณะเดียวกัน
CVE-2023-44487 และการรับมือร่วมกันของอุตสาหกรรม
- ทันทีหลังจากตรวจพบการโจมตีระยะแรกในเดือนสิงหาคม Google ได้ใช้กลยุทธ์บรรเทาเพิ่มเติม และประสาน การตอบสนองร่วมกันของอุตสาหกรรม กับผู้ให้บริการคลาวด์และผู้ดูแลซอฟต์แวร์ที่พัฒนา HTTP/2 protocol stack
- ระหว่างที่การโจมตียังดำเนินอยู่ มีการแบ่งปันข้อมูลการโจมตีและวิธีบรรเทาแบบเรียลไทม์
- ความร่วมมือนี้นำไปสู่แพตช์และเทคนิคการบรรเทาที่ถูกใช้งานโดยผู้ให้บริการโครงสร้างพื้นฐานรายใหญ่หลายราย
- วิธีการโจมตีแบบใหม่และความเปราะบางที่อาจเกิดขึ้นในพร็อกซี แอปพลิเคชันเซิร์ฟเวอร์ และโหลดบาลานเซอร์แบบโอเพนซอร์สและเชิงพาณิชย์ที่ใช้กันทั่วไป ถูกเปิดเผยภายใต้แนวทาง coordinated disclosure
- ความเปราะบางร่วมต่อการโจมตีนี้ถูกติดตามภายใต้ CVE-2023-44487
- ระดับความรุนแรงคือ High
- คะแนน CVSS คือ 7.5/10
ระบบที่อาจได้รับผลกระทบและมาตรการที่ต้องทำ
- บริษัทหรือบุคคลที่ให้บริการเวิร์กโหลดแบบ HTTP ผ่านอินเทอร์เน็ตอาจเผชิญความเสี่ยงจากการโจมตีครั้งนี้
- เว็บแอปพลิเคชัน บริการ และ API ที่ทำงานอยู่บนเซิร์ฟเวอร์หรือพร็อกซีซึ่งสื่อสารผ่าน HTTP/2 อาจมีช่องโหว่
- องค์กรควรตรวจสอบว่าเซิร์ฟเวอร์ที่รองรับ HTTP/2 ของตนไม่มีช่องโหว่ดังกล่าว
- หากใช้งานหรือดูแลเซิร์ฟเวอร์ที่รองรับ HTTP/2 เอง ไม่ว่าจะเป็นโอเพนซอร์สหรือเชิงพาณิชย์ ก็ควรติดตั้งแพตช์จากผู้ขายที่เกี่ยวข้องทันทีที่มีให้ใช้งาน
- แพตช์จากผู้ขายสำหรับ CVE-2023-44487 เป็นมาตรการที่ช่วยจำกัดผลกระทบของเวกเตอร์การโจมตีนี้
คำแนะนำด้านการป้องกันในสภาพแวดล้อม Google Cloud
- การป้องกันการโจมตี DDoS ขนาดใหญ่เป็นเรื่องยาก และไม่ว่าจะแพตช์แล้วหรือไม่ หากต้องการให้บริการทำงานต่อได้ท่ามกลางการโจมตีระดับกลางถึงใหญ่ ก็จำเป็นต้องมี การลงทุนโครงสร้างพื้นฐาน อย่างมาก
- องค์กรที่ให้บริการบน Google Cloud สามารถใช้ประโยชน์จากการลงทุนด้านขีดความสามารถระดับโลกของ Cross-Cloud Network เพื่อให้บริการและปกป้องแอปพลิเคชัน
- ลูกค้า Google Cloud ที่เปิดให้บริการผ่าน global หรือ regional Application Load Balancer จะได้รับการปกป้องจาก Cloud Armor always-on DDoS protection
- การโจมตีที่ใช้ประโยชน์จากช่องโหว่อย่าง CVE-2023-44487 จะถูกบรรเทาอย่างรวดเร็ว
- แม้ Cloud Armor always-on DDoS protection จะสามารถดูดซับคำขอที่ไม่พึงประสงค์ได้เป็นหลักร้อยล้านรายการต่อวินาทีที่ Google network edge แต่คำขอที่ไม่พึงประสงค์ระดับหลายล้านรายการต่อวินาทียังคงอาจผ่านเข้ามาได้
- สำหรับการรับมือการโจมตี Layer 7 แนะนำให้ใช้ custom security policies ของ Cloud Armor, กฎ rate limiting เชิงรุก และการติดตั้ง Adaptive Protection ที่ขับเคลื่อนด้วย AI
- ข้อมูลทางเทคนิคเกี่ยวกับระลอกการโจมตี DDoS ปัจจุบันสามารถดูได้ที่ การวิเคราะห์การโจมตี DDoS แบบ HTTP/2 Rapid Reset
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
The novel HTTP/2 'Rapid Reset' DDoS attack - https://news.ycombinator.com/item?id=37830987
HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks - https://news.ycombinator.com/item?id=37830998
แต่ถ้าผลลัพธ์เป็นแค่ทำให้บริษัทเทคโนโลยีสหรัฐฯ และลูกค้าไม่สะดวกอยู่ไม่กี่ชั่วโมง ก็ยังไม่เข้าใจว่าทำไมมันถึงเกิดขึ้นเรื่อย ๆ
แล้วใช้ชื่อเสียงนั้นรับเงินจากลูกค้าที่ไม่ค่อยสะอาดซึ่งอยากโจมตีคู่แข่ง ลูกค้านั้นบางทีก็เป็นรัฐบาล บางทีก็เป็นบริษัทน่าสงสัย ปีที่แล้วมีหลายกรณีที่บริษัทคริปโตโจมตีเว็บไซต์กันเอง
คนที่ทำเรื่องแบบนี้มักมีทักษะทางเทคนิคสูง แต่ด้วยถิ่นที่อยู่หรือสภาพแวดล้อมที่เติบโตมา ทำให้มีโอกาสหาเงินจากทักษะนั้นได้น้อย
ถ้าเป็นผู้โจมตีระดับสูง ก็อาจกำลังทดสอบขีดความสามารถและการตอบสนองอยู่ Taliban เคยจ่ายเงินให้เด็ก ๆ จุดประทัดนอกฐาน เพื่อดูยุทธวิธี เทคนิค และขั้นตอนการป้องกัน แถมยังทำให้คนชินกับเสียงปืนด้วย
ศัตรูที่เก่งจริงจะทำแบบหลังโดยทำให้ดูเหมือนแบบแรก
ในกรณีของ บอตเน็ต Mirai ผู้สร้างบางคนยังเปิดบริษัทบรรเทา DDoS ด้วย เท่ากับขายอาวุธด้านหนึ่ง และขายการป้องกันอาวุธนั้นอีกด้านหนึ่ง
บางครั้งแรงจูงใจก็เป็นชื่อเสียง การเล่นสนุก หรือความท้าทายในการสร้างบอตเน็ตเอง
ไม่ว่าจะเป็นการโจมตีระดับโครงสร้างพื้นฐานอินเทอร์เน็ต หรือเล็งไปที่บริษัทเฉพาะเจาะจง ผมสงสัยว่ามีใครที่เคยเกี่ยวข้องกับการโจมตีแบบนี้แล้วกล้าหรือบ้าพอจะสร้างบัญชีชั่วคราวมาเล่าแรงจูงใจให้ฟังไหม
เป้าหมายไม่ได้ตั้งใจทำให้เว็บไซต์ช้า แต่พยายามดึงข้อมูลด้วยความเร็วที่ทำให้ลูกค้าที่จ่ายเงินจริงรับค่าเซิร์ฟเวอร์ไม่ไหว
การโจมตีแบบนี้ต่างจาก DDoS จริง ๆ แต่จากประสบการณ์ของผมพบได้บ่อยกว่ามาก และสามารถบรรเทาได้ค่อนข้างง่ายด้วย Cloudflare หรือ Akamai ผมจึงมักแนะนำลูกค้าแบบนั้น
คนจาก Cloudflare, Google, AWS เข้าไปอยู่ในวิดีโอคอลสดเพื่อประสานงานกันในการบรรเทาหรือไม่ หรือแต่ละฝ่ายก็ดูสถานการณ์ของที่อื่นจากระยะไกลไปพร้อมกับมุ่งแก้ปัญหาของตัวเอง
ครั้งนี้ทุกฝ่ายตระหนักว่ากำลังเห็นสิ่งเดียวกัน และเพราะมันอาจส่งผลกระทบหนักมากต่อเป้าหมายขนาดเล็ก จึงร่วมกันทำความเข้าใจปัญหาและประสาน การตอบสนองด้านความปลอดภัย กับผู้ให้บริการเว็บเซิร์ฟเวอร์ทั้งหมด
สงสัยว่าเป็นแค่การมีแบนด์วิดท์ขาเข้าให้มากพอ เพื่อให้ทนการโจมตีระดับหลาย Gb/s ได้ และยังเหลือความจุสำหรับทราฟฟิกที่ถูกต้องตามกฎหมายหรือเปล่า
ทราฟฟิก DDoS จำนวนมากไม่ใช่ HTTP จริง ๆ แต่เป็นทราฟฟิกขยะที่มุ่งไปยังที่อยู่ IP เพื่ออัดท่อให้เต็ม ท่อที่ใหญ่ขึ้นและเซิร์ฟเวอร์หลายตัวที่กระจายตัวทางภูมิศาสตร์ช่วยได้ บางกรณีก็แค่เปิดการเชื่อมต่อ TCP อย่าง TCP SYN flood เพื่อทำให้พอร์ตที่พร้อมใช้งานหมดไป คำขอผิดปกติแบบนี้มักจัดการได้ด้วย reverse proxy แบบเรียบง่ายหลายตัวที่อยู่หน้าเซิร์ฟเวอร์
ส่วนคำขอที่ซับซ้อนกว่าซึ่งดูเหมือนส่งทราฟฟิก HTTP ปกติ สุดท้ายก็ต้องถูกประมวลผล อาจตอบจากแคช ใส่ CAPTCHA เพื่อหน่วงผู้โจมตีและระบุทราฟฟิกปกติ หรือใช้การจำกัดอัตรา เราอยากตัดสินว่าคำขอนั้นปกติหรือไม่ก่อนส่งต่อไปยังเซิร์ฟเวอร์จริง และสามารถ deploy เครื่องมือหลายอย่างเพื่อทำสิ่งนี้ได้
เพียงตั้งค่าเซิร์ฟเวอร์ให้ทิ้งทราฟฟิกทั้งหมดที่ไม่ได้มาจาก Cloudflare วิธีนี้ก็มีประสิทธิภาพ
โดยทั่วไปแล้ว ทราฟฟิกระหว่างดาต้าเซ็นเตอร์ภายในของ Google มีปริมาณมากกว่าที่ใครจะส่งมาเป็น DDoS ได้มาก จึงมักหาวิธีจัดการได้เสมอ
แต่ DDoS ไม่ได้อิงปริมาณความจุทั้งหมด บางกรณีก็ใช้ฟังก์ชันพื้นฐานของโปรโตคอลในทางที่ผิด เช่น การโจมตี slow loris
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
ในกรณีนี้ อาจเป็นการตรวจจับว่าไคลเอนต์รีเซ็ตสตรีมอย่างรวดเร็วหรือไม่ แล้วส่งทราฟฟิกนั้นไปเลนช้า หรือกรองทิ้งไปเลย
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
“ประเด็นสำคัญอย่างหนึ่งของการโจมตีที่ทำลายสถิตินี้คือ มีบอตเน็ตขนาดกลางที่ประกอบด้วยเครื่องประมาณ 20,000 เครื่องเข้ามาเกี่ยวข้อง”
ถ้าผู้ให้บริการรายใหญ่ทำแบบนี้ทั้งหมด ก็น่าจะแทรกหน้าเล็ก ๆ แบบ Turnstile ไว้หน้าการเข้าเว็บ Cloudflare ครั้งถัดไปได้
ถ้ามีอุปกรณ์ที่ติดมัลแวร์อยู่ในเครือข่ายของผม ผมก็อยากรู้ และตอนนี้ก็ไม่มีการมอนิเตอร์จริง ๆ ที่จะตรวจจับได้ นี่ไม่ใช่วิธีแก้ปัญหาสมบูรณ์ แต่การแจ้งผู้ใช้ให้รู้ว่ามีปัญหาก็เป็นจุดเริ่มต้นที่ดีอย่างน้อย