個別のURLリクエストのレート制限


8

私が開発しているFlaskアプリケーションは、外部のWebサイトの相互作用に大きく依存しており、エンドユーザーによって開始されます。帯域幅の制御やレート制限を一切行わずにアプリケーションをそのままにしておくと、悪意のある攻撃者によってこのアプリケーションが悪用される可能性があります。

私の目標は、かなりシンプルな2段階のアプローチです。

  1. 個々のIPソースがx1分あたりの接続数を超えて実行するのをレート制限します。これはで簡単に実現できますiptablesここに私の目標に似た例があります:

     iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 15 \
       --connlimit-mask 32 -j REJECT --reject-with tcp-reset  
    
  2. URLあたりxのルックアップの数を超えるアプリケーションの能力をレート制限します。例:

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

私が知る限り、iptables個別のURLを追跡する方法はありません。これらの接続全体をレート制限することしかできません。それも、私が達成しようとしていることに対する唯一の制限のようではありません。iptablesこの方法でセットアップする方法があった場合、これらの要求はユーザーが開始するため、私のWebアプリケーションに問題が発生する可能性があります。

私はFlaskを使用しています。実行可能なオプションは、before_requestフックを使用して、Redisなどのデータストアでこれらの宛先を手動で追跡することです。ただし、これは、スタックでこのように接続を処理するためにかなり上位にあります。私が本当に必要とする(またはそう思う)のは、特定のブレークポイントに達したときにカスタムの方法で要求を分析し、接続を閉じることができるインテリジェントなファイアウォールアプリケーションです。

私がやろうとしていることを達成する方法はありますか?

もしそうなら、どうですか?

回答:


3

iptables (インターネットモデルの)インターネットレイヤーとトランスポートレイヤー、またはOSIモデルのレイヤー3および4を扱いますが、いくつかの例外があります(MACアドレスのフィルタリング、NATプロトコルヘルパー)。

URIはアプリケーション層の一部です。iptablesそれらを扱いません。

iptablesを使用して、すべての送信TCPポート80トラフィックをWebプロキシ経由で転送し、レート制限を行うことができます(たとえば、Squidの遅延プールがそれを行う可能性があります。または、Apacheはおそらくmod_proxy。を使用できます)。これをHTTPSで行うのはより困難です(ただし、Webプロキシを使用するようにアプリを構成するだけでよい場合もあります。これは、透過プロキシよりも優れたアプローチです。

ただし、実際には両方のレート制限をアプリケーションに移動する必要があります。あなたが設定しているUXである理由はひどいです。「接続拒否」は何が起こっているのかをまったく説明できません。それはなるだろうずっとあなたが代わりにサポートの連絡先に、多分、などを継続するためにCAPTCHAを解決するためのオプションを提供し、彼らは、あまりにも速く要求を作っていることを説明するエラーページを与えた場合は、より良いユーザーのために

着信接続に接続レート制限を設けることは妥当ですが、DoS攻撃によるアプリのフォールオーバーを防ぐ必要があります。これにより、アプリがレート超過エラーページを処理できないという多くのリクエストをユーザーに提供できます。エラーページの提供を開始するときよりもかなり高くする必要があります(ソースIPごとの制限ではなく、グローバルな制限である必要があります)。アプリがウェブサーバーやリバースプロキシを介して実行されている場合は、受信レート制限を(iptables経由ではなく)構成できる可能性が高く、静的エラーページを送信してリクエストを渡さなくても、非常に安価な拒否を行うことができます。あなたのアプリに。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.