Cuộc tấn công DDoS lớn nhất từ trước đến nay, đạt đỉnh 398 triệu rps
(cloud.google.com)- Khi quy mô các cuộc tấn công DDoS tăng rất nhanh, Google cho biết đã giảm thiểu một cuộc tấn công đạt đỉnh 398 triệu rps vào tháng 8/2023, lớn gấp 7,5 lần kỷ lục 46 triệu rps của năm trước
- Kẻ tấn công đã sử dụng kỹ thuật Rapid Reset khai thác tính năng ghép kênh luồng của HTTP/2, ảnh hưởng đến nhiều doanh nghiệp hạ tầng Internet
- Làn sóng tấn công bắt đầu vào cuối tháng 8/2023 và kéo dài sang tháng 9, nhắm vào các nhà cung cấp hạ tầng lớn, bao gồm dịch vụ Google, hạ tầng Google Cloud và khách hàng
- Google đã hấp thụ cuộc tấn công ở rìa mạng và cập nhật các hệ thống phòng vệ; khách hàng của Application Load Balancer và Cloud Armor cũng được bảo vệ trên cùng nền tảng
- Các máy chủ, proxy, application server và load balancer hỗ trợ HTTP/2 có thể bị ảnh hưởng bởi CVE-2023-44487, vì vậy cần kiểm tra mức độ dễ tổn thương và áp dụng bản vá từ nhà cung cấp
Quy mô tấn công và kỹ thuật Rapid Reset
- DDoS Response Team của Google xác nhận rằng trong vài năm gần đây, quy mô các cuộc tấn công DDoS đã tăng theo cấp số nhân
- Cuộc tấn công bị chặn vào tháng 8/2023 có quy mô lớn gấp 7,5 lần kỷ lục cao nhất của năm trước
- Đạt đỉnh 398 triệu requests per second (rps)
- Cuộc tấn công DDoS lớn nhất được ghi nhận trong năm 2022 là 46 triệu rps
- Cuộc tấn công kéo dài 2 phút này tạo ra nhiều request hơn tổng số lượt xem trang mà Wikipedia báo cáo trong cả tháng 9/2023
- Kỹ thuật cốt lõi là HTTP/2 Rapid Reset mới, tận dụng tính năng ghép kênh luồng của HTTP/2
Mục tiêu tấn công và ảnh hưởng tới dịch vụ
- Làn sóng tấn công gần đây bắt đầu vào cuối tháng 8/2023 và tiếp tục được quan sát trong suốt tháng 9
- Mục tiêu của các cuộc tấn công bao gồm những nhà cung cấp hạ tầng lớn
- Dịch vụ Google
- Hạ tầng Google Cloud
- Khách hàng của Google
- Google vẫn duy trì hoạt động dịch vụ nhờ hạ tầng cân bằng tải toàn cầu và giảm thiểu DDoS
- Thông qua hợp tác với các đối tác trong ngành, Google đã xác định cơ chế tấn công và điều phối các biện pháp giảm thiểu để bảo vệ Google, khách hàng và Internet nói chung
Cách Google giảm thiểu và bảo vệ khách hàng Cloud
- Kết quả điều tra cho thấy cuộc tấn công sử dụng kỹ thuật Rapid Reset khai thác tính năng ghép kênh luồng của giao thức HTTP/2 được sử dụng rộng rãi
- Google đã giảm thiểu cuộc tấn công tại rìa mạng
- Tận dụng đầu tư vào năng lực ở edge để bảo đảm dịch vụ của Google và dịch vụ của khách hàng phần lớn không bị ảnh hưởng
- Sau khi hiểu rõ hơn về phương thức tấn công, Google đã phát triển các biện pháp giảm thiểu
- Google cập nhật các proxy và hệ thống phòng thủ chống từ chối dịch vụ để giảm hiệu quả kỹ thuật này
- Application Load Balancer và Cloud Armor của Google Cloud sử dụng cùng hạ tầng phần cứng và phần mềm mà Google dùng để cung cấp các dịch vụ Internet-facing của chính mình
- Các ứng dụng web và dịch vụ Internet-facing của khách hàng Cloud sử dụng các dịch vụ này cũng nhận được mức bảo vệ tương tự
CVE-2023-44487 và phản ứng phối hợp toàn ngành
- Ngay sau khi phát hiện các cuộc tấn công ban đầu vào tháng 8, Google đã áp dụng thêm các chiến lược giảm thiểu và điều phối phản ứng phối hợp toàn ngành với các nhà cung cấp cloud và đơn vị bảo trì phần mềm triển khai HTTP/2 protocol stack
- Trong thời gian cuộc tấn công diễn ra, thông tin về tấn công và phương pháp giảm thiểu được chia sẻ theo thời gian thực
- Sự hợp tác này đã dẫn tới các bản vá và kỹ thuật giảm thiểu được nhiều nhà cung cấp hạ tầng lớn áp dụng
- Phương thức tấn công mới cùng khả năng dễ bị tổn thương tiềm ẩn của nhiều proxy, application server và load balancer mã nguồn mở lẫn thương mại phổ biến đã được công bố có trách nhiệm chung
- Lỗ hổng tập thể liên quan đến cuộc tấn công này được theo dõi dưới mã CVE-2023-44487
- Mức độ nghiêm trọng: High
- Điểm CVSS: 7.5/10
Các đối tượng có thể bị ảnh hưởng và hành động cần thiết
- Doanh nghiệp hoặc cá nhân cung cấp workload dựa trên HTTP ra Internet đều có thể đối mặt với rủi ro từ cuộc tấn công này
- Các web application, service và API chạy trên máy chủ hoặc proxy có thể giao tiếp bằng HTTP/2 có thể dễ bị tấn công
- Các tổ chức cần xác minh rằng máy chủ hỗ trợ HTTP/2 của mình không bị ảnh hưởng
- Nếu đang vận hành hoặc quản lý máy chủ tự hỗ trợ HTTP/2, cần áp dụng bản vá liên quan từ nhà cung cấp ngay khi có sẵn, bất kể là mã nguồn mở hay thương mại
- Bản vá của nhà cung cấp cho CVE-2023-44487 là biện pháp nhằm hạn chế tác động của vector tấn công này
Khuyến nghị phòng vệ trong môi trường Google Cloud
- Việc phòng thủ trước các cuộc tấn công DDoS quy mô lớn là rất khó, và để tiếp tục vận hành dịch vụ trước các cuộc tấn công từ quy mô trung bình trở lên, bất kể đã vá hay chưa, vẫn cần đầu tư hạ tầng đáng kể
- Các tổ chức vận hành dịch vụ trên Google Cloud có thể tận dụng khoản đầu tư về năng lực ở quy mô toàn cầu của Cross-Cloud Network để phân phối và bảo vệ ứng dụng
- Khách hàng Google Cloud công bố dịch vụ bằng Application Load Balancer toàn cầu hoặc theo khu vực được bảo vệ bởi Cloud Armor always-on DDoS protection
- Các cuộc tấn công khai thác lỗ hổng như CVE-2023-44487 được giảm thiểu nhanh chóng
- Dù Cloud Armor always-on DDoS protection có thể hấp thụ phần lớn hàng trăm triệu request mỗi giây tại rìa mạng của Google, vẫn có thể còn hàng triệu request không mong muốn mỗi giây đi qua
- Để ứng phó tấn công Layer 7, Google khuyến nghị triển khai custom security policies của Cloud Armor, các quy tắc rate limiting chủ động và Adaptive Protection dựa trên AI
- Thông tin kỹ thuật về làn sóng tấn công DDoS hiện tại có thể xem tại Phân tích cuộc tấn công DDoS HTTP/2 Rapid Reset
1 bình luận
Các ý kiến trên 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
Dù vậy, nếu kết quả chỉ là làm các công ty công nghệ Mỹ và khách hàng của họ bất tiện trong vài giờ, tôi vẫn không hiểu vì sao chuyện này cứ tiếp diễn
Với danh tiếng đó, họ nhận tiền từ các khách hàng kém trong sạch muốn tấn công đối thủ; đôi khi khách hàng đó là chính phủ, đôi khi là một công ty đáng ngờ. Năm ngoái có rất nhiều vụ các công ty tiền mã hóa tấn công website của nhau
Những người làm việc này thường có trình độ kỹ thuật cao, nhưng vì nơi sống hoặc môi trường trưởng thành mà họ có ít cơ hội kiếm tiền từ kỹ năng đó
Nếu là kẻ tấn công cao cấp thì họ đang thử nghiệm năng lực và phản ứng phòng thủ. Trước đây Taliban từng trả tiền cho trẻ em đốt pháo bên ngoài căn cứ để quan sát chiến thuật, kỹ thuật và quy trình phòng thủ; việc đó cũng có tác dụng làm người ta bớt nhạy cảm với tiếng súng
Một đối thủ thật sự giỏi biết cách làm điều thứ hai nhưng khiến nó trông như điều thứ nhất
Với botnet Mirai, một số tác giả của nó cũng vận hành công ty giảm thiểu DDoS. Nói cách khác, họ bán vũ khí ở một bên và bán phòng thủ chống lại vũ khí đó ở bên kia
Đôi khi động cơ là danh tiếng, trò nghịch ngợm, hoặc chính thử thách tạo ra botnet
Dù là ở quy mô hạ tầng Internet hay nhắm vào một công ty cụ thể, tôi tự hỏi liệu có ai từng tham gia những cuộc tấn công như vậy đủ dũng cảm hoặc đủ điên để tạo tài khoản tạm và kể về động cơ không
Họ không định làm website mục tiêu chậm lại, nhưng thực tế họ đang cố lấy dữ liệu với tốc độ khiến chi phí server của khách hàng trả tiền thật sự trở nên không chịu nổi
Kiểu tấn công này khác với DDoS thực sự, nhưng theo kinh nghiệm của tôi thì phổ biến hơn nhiều, và có thể giảm thiểu khá dễ bằng những dịch vụ như Cloudflare hoặc Akamai, nên tôi thường khuyên khách hàng như vậy
Không biết người của Cloudflare, Google, AWS có cùng vào một cuộc họp video thời gian thực để phối hợp giảm thiểu, hay mỗi bên quan sát tình hình nơi khác từ xa và tập trung xử lý vấn đề của mình
Lần này, mọi người nhận ra rằng họ đều đang thấy cùng một thứ; vì tác động với các mục tiêu nhỏ có thể rất lớn, họ đã cùng tìm hiểu vấn đề và phối hợp ứng phó bảo mật với tất cả nhà cung cấp web server
Không biết có phải chỉ là có đủ băng thông đầu vào để chịu được vài Gb/s, đồng thời vẫn chừa dung lượng cho lưu lượng hợp pháp hay không
Nhiều lưu lượng DDoS không phải HTTP thật sự, mà là lưu lượng rác nhắm vào địa chỉ IP để lấp đầy đường truyền. Đường truyền lớn hơn và nhiều máy chủ phân tán theo địa lý sẽ giúp ích. Cũng có trường hợp như TCP SYN flood, chỉ mở các kết nối TCP để làm cạn kiệt các cổng khả dụng. Những yêu cầu bất thường như vậy thường có thể được xử lý bằng nhiều reverse proxy đơn giản đặt phía trước máy chủ
Các truy vấn tinh vi hơn, bề ngoài gửi lưu lượng HTTP bình thường, cuối cùng vẫn phải được xử lý. Chẳng hạn phản hồi từ cache, chèn CAPTCHA để làm chậm kẻ tấn công và nhận diện lưu lượng bình thường, hoặc áp dụng giới hạn tốc độ. Bạn sẽ muốn xác định yêu cầu có hợp lệ hay không trước khi chuyển đến máy chủ thật, và có thể triển khai nhiều công cụ để làm việc này
Chỉ cần cấu hình máy chủ loại bỏ mọi lưu lượng không do Cloudflare gửi đến, và cách này hiệu quả
Nhìn chung, lưu lượng giữa các trung tâm dữ liệu nội bộ của Google lớn hơn rất nhiều so với lượng mà bất kỳ ai có thể gửi dưới dạng DDoS, nên luôn có thể tìm ra cách xử lý
Nhưng không phải mọi DDoS đều dựa trên dung lượng. Cũng có trường hợp lợi dụng các chức năng cơ bản của giao thức, như tấn công slow loris
https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
Trong trường hợp này, có thể là nhận ra client có đang reset stream nhanh hay không, rồi đưa lưu lượng đó vào làn chậm hoặc lọc bỏ hẳn
https://blog.cloudflare.com/zero-day-rapid-reset-http2-recor...
“Một điểm cốt lõi cần lưu ý về cuộc tấn công phá kỷ lục này là có một botnet cỡ trung bình gồm khoảng 20.000 máy tham gia”
Có vẻ các nhà cung cấp lớn đều có thể làm như vậy, chèn một trang nhỏ kiểu Turnstile trước trang Cloudflare tiếp theo mà người dùng truy cập
Nếu trong mạng của tôi có thiết bị bị nhiễm, tôi muốn biết, và hiện tôi cũng không có hệ thống giám sát thực tế nào để phát hiện việc này. Đây không phải giải pháp hoàn chỉnh, nhưng ít nhất báo cho người dùng rằng có vấn đề là một khởi đầu tốt