Làm thế nào để chặn bot AWS gửi 2 tỷ yêu cầu mỗi tháng?

• Trên hạ tầng AWS đã phát sinh vấn đề lượng lớn yêu cầu web ngoài dự kiến
• Ghi nhận lưu lượng tăng vọt từ 200 triệu lên 2 tỷ yêu cầu mỗi tháng
• Kết quả phân tích log xác nhận có các yêu cầu lặp lại từ một User-Agent cụ thể
• Đã liên hệ đội hỗ trợ AWS nhưng chưa nhận được giải pháp rõ ràng
• Cần xem xét nhiều phương án chặn khác nhau như thiết lập quy tắc tường lửa, chặn User-Agent, v.v.

---

Giới thiệu vấn đề

• Một người dùng AWS đã đặt câu hỏi về hiện tượng có 2 tỷ yêu cầu đến máy chủ web trong vòng một tháng
• Các yêu cầu này đến từ một bot dùng User-Agent cụ thể và là lưu lượng bất thường, không khớp với mẫu sử dụng bình thường
• Sự gia tăng lưu lượng đột ngột có nguy cơ dẫn đến chi phí tăng cao và gây tải cho hệ thống

Phân tích nguyên nhân

• Phần lớn trong số lượng yêu cầu khổng lồ này đến từ các dải IP AWS đáng ngờ
• Qua bản ghi truy cập, xác định nguyên nhân là một bot hoặc script cụ thể
• User-Agent có mẫu chung nên có thể lọc được

Ứng phó hiện tại và giới hạn

• Đã liên hệ đội hỗ trợ AWS nhưng chưa nhận được phương án mang tính quyết định
• Lượng yêu cầu lớn như vậy có khả năng cao gây ra gián đoạn dịch vụ và tăng gánh nặng chi phí

Hướng giải quyết và các điểm cần cân nhắc

• Cần xem xét sự cần thiết của nhiều chính sách chặn như bổ sung quy tắc tường lửa, chặn lưu lượng dựa trên User-Agent và áp dụng danh sách đen IP
• Về lâu dài, cần tăng cường hệ thống giám sát lưu lượng và xây dựng cơ chế phát hiện, tự động chặn truy cập bất thường

[GN⁺]

Ý kiến trên Hacker News

• Đã từng thử dùng chuyển hướng 30x, ví dụ trả về 301 để dẫn sang các tệp cực lớn được lưu trữ bởi những công ty mà tôi không ưa; nếu khiến các instance AWS của họ đồng thời tải xuống 70.000 bản ISO Windows thì chắc chắn họ sẽ nhận ra; ngoài ra, dù không dễ với Cloudflare, cũng có thể dùng chiến lược gọi là “tar pit”, tức là sau khi nhận request thì gửi response từng ký tự một, mỗi ký tự chậm 30 giây; với header/response 10KB cho mỗi request mà có 700 request mỗi giây thì server sẽ trông như đang cực kỳ chậm
  • Nếu không thích chỉ định một công ty cụ thể làm đích 301 thì có thể trỏ sang nơi như Amazon
  • Tôi nghĩ chiến lược nhận request rồi gửi thật chậm từng ký tự là cách làm hoàn toàn ngược lại với tấn công DDoS Slow Loris; có thể xem giải thích về Slow Loris trên Cloudflare, tức là không phải phía tấn công dùng kết nối chậm mà phía phòng thủ đáp trả bằng kết nối chậm
  • Một phương án khác là 301 sang trang chính phủ chính thức của .sg để cơ quan thực thi pháp luật địa phương xử lý
  • Chỉ ra rằng traffic inbound của AWS là miễn phí, nên dù chủ instance có nhận một lượng dữ liệu khổng lồ thì AWS cũng không tính thêm phí vì việc đó
• Một cách khác là làm cho bot độc hại trở nên tốn kém về chi phí vận hành; đặc biệt các kiểu như gzip bomb sẽ hiệu quả nếu bot có lỗ hổng, nhưng ngay cả chỉ cần trì hoãn khoảng 10 giây trước khi trả response cũng có thể buộc phía đó tiêu tốn khoảng 7.000 cổng trên server, và phần lớn tiến trình Linux sẽ không chịu nổi mà chết; có thể triển khai dễ dàng bằng nginx + mod-http-echo
  • Thực tế đã có người triển khai chiến lược này; có thể thấy qua danh sách user agent trong mã nguồn open source, và bản thân việc triển khai cũng rất đơn giản; xem source liên quan tại đây
  • Khách hàng AWS phải trả tiền cho traffic outbound, nhưng ngược lại tôi cũng tò mò liệu có cách nào khiến AWS hoặc Cloudflare gửi lưu lượng lớn về phía chúng ta không
  • Tôi từng gặp tình huống tương tự; scraping độc hại lặp đi lặp lại để lấy dữ liệu giá trên site của chúng tôi, trong khi catalog có tới hàng triệu sản phẩm nên việc tính giá động tiêu tốn tài nguyên khủng khiếp; những đợt request tăng đột biến suýt làm hạ tầng không chịu nổi và dịch vụ gần như tê liệt; chiến lược phòng thủ là gắn thẻ traffic spam để cache riêng, không ảnh hưởng khách hàng thật, đồng thời cũng từng bàn tới việc thêm sai số ngẫu nhiên vào giá để bản thân dữ liệu trở nên vô nghĩa; cuối cùng chúng tôi ổn định với phương án phối hợp cùng Cloudflare để chặn nhanh các request độc hại, nhưng cái giá về thời gian và chi phí là không nhỏ; kẻ tấn công có vẻ là một dịch vụ thuê ngoài của đối thủ, và điều đáng tiếc là họ hoàn toàn có thể liên hệ trực tiếp vì chúng tôi có thể cung cấp API chính thức; trước đây người ta hay có quan điểm kiểu “không chịu nổi traffic thì là lỗi của site”, nhưng dạo này cảm giác nhận thức đó đã thay đổi khá nhiều
  • Tôi thắc mắc liệu làm vậy thì server của tôi cũng sẽ bị tiêu tốn 7.000 cổng hay không
  • Hỏi rằng nếu dùng kỹ thuật đó thì phía server của mình cũng sẽ phát sinh tương ứng rất nhiều kết nối phải không
• Tôi là tác giả chính của Anubis; tôi từng thấy rằng nếu cấu hình Cloudflare trả về HTTP 200 thì bot sẽ ngừng đập vào đó cho tới khi nhận được 200
  • Nhân tiện, có vẻ trang chính hiện đang gặp sự cố
  • Tôi cũng từng thử cách cưỡng bức ngắt hẳn kết nối khi bị phát hiện ở application layer; khi phần cấu hình phía Cloudflare khó xử lý thì cách thô sơ này dường như vẫn có tác dụng với các bot đơn giản
• Trước đây tôi từng gặp chuyện tương tự với blog cá nhân; khoảng 7~8 năm trước, traffic bỗng tăng vọt, ban đầu tôi tưởng là bài viết bị viral nhưng thấy quá máy móc nên nghi ngờ; lần theo nguyên nhân thì hóa ra có bot/crawler của ai đó đang cào site của tôi để thử nghiệm; sau vài tháng lịch sự yêu cầu nhiều lần mà không ăn thua, cuối cùng tôi chuyển hướng bot đó sang các trang web khiêu dâm ngẫu nhiên thì việc crawling dừng lại
  • Cách này thực tế là tốt nhất, hãy redirect sang nơi mà họ không muốn xuất hiện trong log crawler, hoặc sang chính họ, nhà cung cấp dịch vụ của họ, hay nội dung mà họ không mong muốn
• Nhét chuỗi kiểm thử EICAR vào body của phản hồi 200 để gây ô nhiễm dữ liệu cũng là một kiểu trả đũa khá hả dạ, xem giải thích về tệp kiểm thử EICAR
  • Như một khái niệm ngược với tấn công SSRF, tôi nghĩ cũng sẽ thú vị nếu redirect bot tới cloud metadata API để dụ nó gọi các endpoint như <shutdown>, rồi còn có thể nhét luôn chuỗi kiểm thử EICAR vào response redirect để kích hoạt cả hệ thống phát hiện bảo mật tự động
• Nếu hoàn toàn không có lý do gì phải nhận traffic hợp lệ từ AWS Singapore thì một lựa chọn khác là blackhole toàn bộ dải đó
  • Có thể dùng WAF để drop hẳn các packet đó; tính năng "block" của Cloudflare WAF là dành cho mục đích như vậy
  • Tôi cũng từng làm vậy; bot Byte Spider của Byte Dance đã cào hàng triệu ảnh, cuối cùng tôi phải nhờ phía Cloudinary chặn user agent đó và lúc đầu còn chặn cả Singapore; tôi thực sự bực vì các công ty AI scraping vận hành bot một cách quá ác ý; nhờ dùng một dịch vụ tốt như Cloudinary nên còn tiết kiệm được chi phí, còn dạo này thì tôi xử lý dứt điểm bằng cách chặn toàn bộ bot AI trên Cloudflare
  • Tham khảo thêm, có thể xem dải IP theo từng region của AWS tại đây
• Năm 2018 tôi từng gặp chuyện tương tự ở quy mô nhỏ hơn nhiều; tôi đã tự viết một công cụ đọc danh sách json dải IP chính thức của AWS rồi chặn các dải đó trong Windows Firewall; có thể tham khảo bài blog liên quan ở đây và readme của công cụ tại đây; nó đã chạy tốt nhiều năm dưới dạng tác vụ định kỳ trên server, nhưng tôi không dám chắc giờ còn hoạt động không; nếu bạn quan tâm thì tôi có thể công khai mã nguồn hoặc chuyển lại cho người khác, còn nếu tự triển khai thì cũng không quá khó; chúc may mắn
• Cơ quan quản lý viễn thông ở Singapore còn cấm cả việc sở hữu nội dung khiêu dâm, nên tôi đề xuất chiến lược gửi softcore để đáp trả bot độc hại đồng thời gửi email báo cáo cho cơ quan đó và cho AWS
  • Khi ai đó liên tục gây hại trên Internet, cách hiệu quả nhất là tận dụng luật pháp của quốc gia đó để phản ứng; với các cơ quan khác thì thường rất khó kỳ vọng họ sẽ làm gì
• Nếu báo cho Cloudflare biết rằng traffic đó là độc hại, họ có thể chặn từ bên ngoài tài khoản nên sẽ xử lý mà không làm tăng gánh nặng cho số liệu traffic phía bạn
• Tôi cũng từng có trải nghiệm tương tự: người ta request một trình cài đặt phần mềm 80MB với số lượng khổng lồ; tôi redirect các request vi phạm sang một tệp tên là "please-stop.txt", trong đó giải thích vấn đề và đề nghị họ dừng lại, và cuối cùng họ thực sự đã dừng