Tỷ lệ giới hạn * yêu cầu * không được xác thực

Nói rằng chúng tôi có một bộ cân bằng tải cũng giới hạn tốc độ. Giới hạn tốc độ có vẻ khá đơn giản đối với người dùng đã đăng nhập - chỉ cần nhìn vào JWT và có thể sử dụng kho lưu trữ dữ liệu trong bộ nhớ để xem có bao nhiêu yêu cầu trong 10 giây qua cho người dùng đó.

Tuy nhiên, những gì về người dùng không đăng nhập (không xác thực)? Chúng tôi không biết chắc chắn họ là ai hoặc yêu cầu đến từ đâu chính xác, vì vậy không thể dễ dàng giới hạn tỷ lệ các yêu cầu đó hay ..?

Có giải pháp tích hợp nào cho vấn đề này trên AWS và các nền tảng lưu trữ khác có phải là điều chúng tôi cần lo lắng không? Có vẻ như chúng ta cần xử lý logic giới hạn tỷ lệ của người dùng đã đăng nhập theo cách thủ công, nhưng đối với người dùng không đăng nhập thì sao?

Tôi đoán / hy vọng là có thể có một số cơ chế tích hợp cho các yêu cầu không được xác thực giới hạn tỷ lệ trên các nền tảng lưu trữ, vui lòng thông báo cho tất cả chúng tôi.

Tuy nhiên, những gì về người dùng không đăng nhập (không xác thực)? Chúng tôi không biết chắc chắn họ là ai hoặc yêu cầu đến từ đâu chính xác, vì vậy không thể dễ dàng giới hạn tỷ lệ các yêu cầu đó hay ..?

Có một vài cách tiếp cận bạn có thể thực hiện. Một là bạn cần một mã định danh nguồn gốc hợp lý đáng tin cậy, ví dụ địa chỉ IP. Bạn có thể xếp hạng giới hạn theo địa chỉ IP, do đó các cuộc tấn công vào một máy bị xâm nhập sẽ bị hạn chế. Đây là một cách tiếp cận khá đơn giản, nhưng có một nhược điểm là có các nhà cung cấp mạng lớn chỉ có thể sử dụng các địa chỉ IP gửi đi duy nhất để ẩn một số lượng lớn người dùng đằng sau NAT.

Một cách tiếp cận khác để giới hạn tỷ lệ bạn có thể thực hiện là yêu cầu bằng chứng công việc cho bất kỳ yêu cầu không được xác thực nào. Máy chủ của bạn đưa ra một mã thách thức mà bất kỳ khách hàng nào thực hiện yêu cầu không được xác thực (ví dụ: yêu cầu đăng nhập) phải tính toán một phản hồi chuyên sâu về tài nguyên trước khi yêu cầu được xử lý. Một triển khai chung của ý tưởng này đòi hỏi khách hàng phải tính toán đảo ngược một phần băm.

Để biết nếu một yêu cầu là từ một người dùng được xác thực hoặc từ một người dùng ẩn danh, bạn nhất thiết phải xử lý yêu cầu (mặc dù nhanh chóng). Điều này vẫn có nghĩa là ứng dụng của bạn dễ bị tấn công từ chối dịch vụ.

Bạn nên kiểm tra các yêu cầu tổng thể mỗi giây và nếu vượt quá một số lượng nhất định, bạn chỉ cần bỏ qua phần còn lại. Con số đó phải đủ cao để không gây ra vấn đề trong quá trình hoạt động bình thường, nhưng nên bảo vệ chống lại các cuộc tấn công như vậy.

Ngoài ra, theo nguyên tắc chung, có lẽ bạn không nên cho rằng một cuộc tấn công sẽ không đến từ người dùng được xác thực, ít nhất là đối với những gì liên quan đến các cuộc tấn công của DOS. Mật khẩu yếu sẽ dễ dàng cho phép ai đó đoán trước danh tính của người dùng cũ. Vì vậy, giả sử bạn có thể thực hiện kiểm tra như vậy, người dùng (con người) của bạn sẽ không bao giờ cần phải thực hiện các yêu cầu ở mức giá như vậy không chỉ đơn giản là vì bạn có nhiều người dùng cá nhân.

Một trong những dịch vụ chính của Cloudflare là bảo vệ chống lại các cuộc tấn công từ chối dịch vụ bằng cách cung cấp proxy thông minh cho API / máy chủ web của bạn. Dịch vụ cơ bản là miễn phí; họ kiếm tiền từ các dịch vụ liên quan khác như dịch vụ CDN và cân bằng tải. Họ cũng cung cấp các dịch vụ Giới hạn tỷ lệ tinh vi và có thể kiểm soát hơn , hiện ở mức 0,05 đô la Mỹ cho mỗi 10k yêu cầu tốt (không tính phí cho các yêu cầu bị từ chối), nhưng bạn phải nâng cấp lên các gói trả phí để có nhiều hơn một quy tắc toàn cầu.

Bạn có thể sử dụng dịch vụ của Cloudflare với AWS hoặc bất kỳ nền tảng nào khác miễn là bạn có quyền kiểm soát máy chủ tên miền của mình (như trong, bạn có thể thay đổi máy chủ tên đã đăng ký cho tên miền của mình).

Bạn có thể cung cấp các giới hạn tỷ lệ riêng cho người dùng ẩn danh và người dùng đăng nhập bằng cách hướng người dùng đăng nhập vào các URL khác nhau. Ví dụ: bạn có thể chỉ cần tiền tố tất cả các đường dẫn URL ẩn danh có sẵn với '/ u' để tạo một điểm cuối luôn yêu cầu xác thực và có giới hạn tốc độ khác nhau.

Lưu ý rằng giới hạn tốc độ của Cloudflare (giống như tất cả giới hạn tỷ lệ thương mại cho người dùng ẩn danh mà tôi biết) xác định một khách hàng theo địa chỉ IP của nó. Điều này có thể gây ra sự cố cho những người sử dụng VPN thương mại hoặc Tor, vì họ có xu hướng ẩn một số lượng lớn khách hàng đằng sau 1 địa chỉ IP để tăng thêm quyền riêng tư.

Trong AWS, có các dịch vụ liên quan AWS Shield và AWS WAF . Chúng chủ yếu nhằm ngăn chặn các cuộc tấn công DDoS nhưng cũng cung cấp hỗ trợ cho việc giới hạn tỷ lệ dựa trên địa chỉ IP.

Trong WAF, khái niệm này được gọi là Quy tắc dựa trên tỷ lệ . Ngăn chặn các nỗ lực đăng nhập dựa trên lực lượng vũ phu được đề cập như một trường hợp sử dụng trong thông báo ban đầu :

Loại quy tắc mới này bảo vệ các trang web và API của khách hàng khỏi các mối đe dọa như các cuộc tấn công DDoS của lớp web, các nỗ lực đăng nhập bạo lực và các bot xấu. Quy tắc dựa trên tỷ lệ được tự động kích hoạt khi yêu cầu web từ máy khách vượt quá ngưỡng có thể định cấu hình nhất định.

Các nhà cung cấp đám mây khác nên có các dịch vụ tương tự. Đây là bảng so sánh dạng bảng: Google Cloud Armor so với AWS WAF so với Cloudflare WAF .

Vì bạn đã sử dụng Nginx, sử dụng giới hạn tỷ lệ dựa trên IP tích hợp cũng có thể là tùy chọn đơn giản. Mô-đun được gọi là ngx_http_limit_Vq_module . Bài đăng blog này mô tả làm thế nào nó có thể được sử dụng.

Xin lưu ý rằng giới hạn tỷ lệ dựa trên IP là một khái niệm tương đối đơn giản nhưng nó không hoàn hảo:

• Địa chỉ IP có thể được chia sẻ (những người làm việc trong cùng một văn phòng) dẫn đến dương tính giả
• Kẻ tấn công có thể dễ dàng truy cập vào nhiều địa chỉ IP và sử dụng chúng để vượt qua các giới hạn (tấn công đăng nhập vũ phu phân tán)

Nói chung, địa chỉ IP là một khởi đầu tốt. Nhưng nếu bạn cần bảo vệ mạnh mẽ hơn, các lựa chọn tốt nhất của bạn sẽ phụ thuộc vào mô hình luồng của bạn (loại tấn công nào bạn muốn ngăn chặn).