Giới hạn tỷ lệ yêu cầu URL cá nhân

Tôi có một ứng dụng Flask tôi đang phát triển dựa nhiều vào tương tác trang web bên ngoài và được người dùng cuối khởi xướng. Nếu tôi rời khỏi ứng dụng mà không có bất kỳ loại giới hạn kiểm soát / tốc độ băng thông nào thì ứng dụng này có thể bị các tác nhân lạm dụng với mục đích bất chính.

Mục tiêu của tôi là một cách tiếp cận 2 giai đoạn khá đơn giản:

1. Tỷ lệ giới hạn các nguồn IP riêng lẻ thực hiện nhiều hơn xsố lượng kết nối một phút. Điều này có thể dễ dàng đạt được với iptables. Đây là một ví dụ tương tự với mục tiêu của tôi:

    iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 15 \
      --connlimit-mask 32 -j REJECT --reject-with tcp-reset  
   

2. Tỷ lệ giới hạn khả năng ứng dụng thực hiện nhiều hơn xsố lần tra cứu trên mỗi URL . Thí dụ:

    APP ---- 10 pps --->  stackexchange.com   PERMIT
    APP ---- 25 pps --->  google.com          DENY / 15 SECOND BACKOFF
   

Theo như tôi có thể nói, iptableskhông có cách nào để theo dõi các URL riêng biệt. Nó chỉ có thể đánh giá giới hạn các kết nối này nói chung. Đó dường như cũng không phải là giới hạn duy nhất cho những gì tôi đang cố gắng đạt được. Nếu có một cách để thiết lập iptablestheo cách này, nó có thể cung cấp một số vấn đề với ứng dụng web của tôi vì các yêu cầu này do người dùng khởi tạo.

Tôi đang sử dụng Flask, một tùy chọn khả thi có thể là sử dụng before_requesthook và theo dõi thủ công các điểm đến này bằng một kho lưu trữ dữ liệu như Redis. Tuy nhiên, điều này là khá cao trong ngăn xếp để xử lý các kết nối theo cách này. Những gì tôi thực sự cần (hoặc nghĩ rằng tôi làm) là một ứng dụng tường lửa thông minh có thể phân tích các yêu cầu theo cách tùy chỉnh và đóng các kết nối khi đã đạt đến một số điểm dừng nhất định.

Có cách nào để đạt được những gì tôi đang cố gắng làm không?

Nếu vậy thì thế nào?

iptables giao dịch với các lớp Internet và Giao thông (trong mô hình Internet) hoặc các lớp 3 và 4 khác trong mô hình OSI, với một vài ngoại lệ (lọc trên địa chỉ MAC, trình trợ giúp giao thức NAT).

Các URI là một phần của lớp Ứng dụng. iptableskhông đối phó với họ.

Bạn có thể sử dụng iptables để điều hướng tất cả lưu lượng truy cập cổng TCP 80 đi qua proxy web, điều này có thể làm hạn chế tốc độ của bạn (ví dụ: có thể các nhóm trì hoãn của Squid có thể làm được. Hoặc Apache có thể làm được mod_proxy.) Làm điều này với HTTPS khó khăn hơn ( mặc dù có lẽ bạn chỉ có thể định cấu hình ứng dụng của mình để sử dụng proxy web, đây sẽ là cách tiếp cận tốt hơn so với proxy minh bạch.

Nhưng bạn thực sự nên chuyển cả hai giới hạn tỷ lệ của bạn vào ứng dụng của bạn. Lý do là UX bạn thiết lập là rất tệ ; "từ chối kết nối" không giải thích được tất cả những gì đang xảy ra. Sẽ tốt hơn nhiều cho người dùng của bạn nếu thay vào đó bạn đưa ra một trang lỗi giải thích rằng họ đang yêu cầu quá nhanh, liên hệ với ai để được hỗ trợ, có thể đưa ra một tùy chọn để giải quyết CAPTCHA để tiếp tục, v.v.

Thật hợp lý khi có giới hạn tốc độ kết nối cho các kết nối đến, nhưng điều đó là để bảo vệ ứng dụng không bị đổ do tấn công DoS, vì vậy nhiều yêu cầu mà ứng dụng của bạn thậm chí không thể phục vụ trang lỗi vượt quá tốc độ cho người dùng. Nó phải cao hơn một chút so với khi bạn bắt đầu phục vụ trang lỗi (và có thể phải là giới hạn toàn cầu, không phải là giới hạn trên mỗi nguồn-IP). Lưu ý rằng nếu ứng dụng của bạn đang chạy qua máy chủ web và / hoặc proxy ngược, bạn có thể định cấu hình các giới hạn tốc độ đến đó (thay vì thông qua iptables), và từ chối rất rẻ bằng cách gửi trang lỗi tĩnh và thậm chí không gửi yêu cầu vào ứng dụng của bạn.