Đối phó khi website public bị “cào dữ liệu”

Trong quá trình vận hành website live map, mình gặp phải tình huống hàng loạt IP lạ request liên tục, với 1 số lượng request cố định (187 req/ip). Dù đã áp dụng các biện pháp cơ bản như ký HMAC cho các request, giới hạn tốc độ truy cập theo IP và làm rối các thuật toán trên client, attacker vẫn vượt qua được. Họ thuê khoảng 1.000 IP từ nước ngoài (AWS EC2 và nhiều VPS khác khắp thế giới, cái này mình không rõ nên chỉ nghĩ họ thuê IP/service) để thay đổi liên tục địa chỉ IP gửi request, đánh bại giới hạn theo IP của mình (số lượng IP này được tính đến khi mình phát hiện). Những IP này sau đó giải mã thuật toán HMAC (bằng cách phân tích mã client của mình) và spam yêu cầu qua API Reverse để lấy data, làm gián đoạn trải nghiệm người dùng thật.

Giải pháp và hướng xử lý

Đối mặt với tình huống trên, mình triển khai thêm 1 ít biện pháp phòng thủ, vừa ngăn chặn tấn công, vừa phải không ảnh hưởng đến người dùng hiện tại:

Giới hạn lưu lượng API với IP nước ngoài:

Phân giải IP & check theo dải IP được cung cấp cho Việt Nam, từ đó phân loại được các IP đến từ Việt Nam và quốc tế. Danh sách này tham khảo từ nguồn APNIC và IANA. Cụ thể, mình chỉ cho phép vài chục lượt request mỗi IP nước ngoài đối với API Reverse, giảm thiểu tối đa lượng request attacker có thể thực hiện, đồng thời dựa trên lượt req trung bình của lượng khách hàng quốc tế đang sử dụng. Biện pháp này tương tự cách chặn hoặc hạn chế truy cập từ các quốc gia chứa nhiều proxy nguy cơ cao. Mình thấy hầu hết các request tấn công đều đến từ một vài nhà cung cấp dịch vụ đám mây (ví dụ AWS), mình có thể chặn tạm thời toàn bộ dải IP đó. Thực tế cho thấy việc chặn dải AWS ngay lập tức ngăn được tấn công, nhưng có thể vô hiệu hóa nhầm một phần ít user chính đáng, nên mình quyết định không block theo hướng này.

Thường xuyên xoay vòng thuật toán/chìa khóa:

Bởi kẻ tấn công đã phân tích được thuật toán HMAC ban đầu, nên mình thực hiện thay đổi định kỳ (ví dụ hàng tuần) các tham số tạo mã HMAC hoặc đổi biến thể thuật toán nhẹ, giúp giảm thiểu rủi ro khóa bị lộ. Cách này khiến mỗi lần attacker phải giải mã lại từ đầu, tăng sai sót và công sức. Bằng cách thay đổi liên tục, thông tin thu được từ mỗi phiên tấn công trở nên “không còn nhiều giá trị so với nỗ lực bỏ ra”. Đồng thời, hệ thống sẽ phát sinh nhiều lỗi (do dùng thuật toán cũ) khiến phía tấn công mất thêm tài nguyên xử lý. Việc này tương tự như tạo maze thử thách bổ sung cho bên tấn công, mà họ phải liên tục đối mặt để chọn lọc dữ liệu, trong khi người dùng bình thường ít bị ảnh hưởng.

Cân bằng bảo mật và trải nghiệm người dùng:

Mọi biện pháp hạn chế đều được thiết kế sao cho không ảnh hưởng tới UX của người dùng thật. Theo kinh nghiệm công nghệ, giới hạn quá nghiêm ngặt dễ gây khóa nhầm user hợp lệ và hạ chất lượng dịch vụ. Do đó, mình phải liên tục giám sát và log chi tiết các request bất thường để có thể kích hoạt biện pháp bổ sung (hầu hết là ném vào blacklíist) thay vì áp dụng đồng loạt. Nhờ vậy, người dùng thật vẫn duy trì kết nối mượt mà, trong khi các bot lưu loát từ nguồn nghi vấn dần bị phân tách.

Kết quả và bài học kinh nghiệm

Qua tình huống này, mình thấy phòng thủ đa lớp (IP filtering, HMAC, giới hạn luồng, v.v.) luôn cần thiết cho các API public. Cụ thể, xác thực mọi request bằng HMAC là bước khởi đầu tốt, nhưng không thể phụ thuộc độc lập vào nó. Khi đối thủ có thể thay đổi IP liên tục và phân tích thuật toán, việc bổ sung cơ chế như hạn chế địa lý, xoay khóa thường xuyên và danh sách ưu tiên giúp gia tăng hiệu quả bảo vệ. Nhờ áp dụng các biện pháp trên, mình đã giảm đáng kể lưu lượng bất thường và đảm bảo dịch vụ hoạt động ổn định cho user thật. Dù website miễn phí và có phần lỏng lẻo hơn các dịch vụ quy mô lớn, những giải pháp này vẫn đảm bảo trải nghiệm mượt mà cho người dùng hợp pháp trong nước, đồng thời triệt tiêu đáng kể hoạt động của attacker.

Mình đang chờ đợt tiếp theo, nếu bên tấn công thuê thêm vài nghìn IP trong nước thì xử lý thế nào, do hiện tại lượng users đang phục vụ chủ yếu là người Việt Nam.

Các phần code của mình chủ yếu dùng Copilot Agent (model GPT 5 Codex), mình chỉ đưa ra mỗi ý tưởng cho nó làm.

Lưu ý: Nội dung trên là chia sẻ kinh nghiệm thực tế từ góc nhìn của dev mobile tự nghiên cứu bảo mật. Mình không phải chuyên gia bảo mật và không đưa ra tư vấn chính thức. Các biện pháp được nêu ra nhằm mục đích chia sẻ, mình sẵn sàng tiếp thu thêm các giải pháp khác từ các bạn ạ.