Web APIでのハック/ DOS攻撃を止める方法
私のウェブサイトは先週、サービス拒否/ハック攻撃を受けています。攻撃は、ループ内でランダムに生成された無効なAPIキーを使用してWeb APIにヒットしています。
キーを推測しようとしているか（64ビットキーとしては数学的に不可能）、サーバーをDOS攻撃しようとしているかどうかはわかりません。攻撃は分散されているため、数百のクライアントから発生するため、すべてのIPアドレスを禁止することはできません。
私の推測では、それはIPによるAndroidアプリであるため、誰かがAndroidアプリにマルウェアを持ち、すべてのインストールを使用してサーバーを攻撃します。
サーバーはTomcat/Javaです。現在、Web APIは無効なキーに400だけを応答し、無効なキーを何度か試行したIPをキャッシュしますが、依然として不正な要求ごとに処理を行う必要があります。
攻撃を止める方法はありますか？ HTTPヘッダーからリクエストを行うAndroidアプリを識別する方法はありますか？
ブルートフォース攻撃の防止：
これを行うのに役立つツールと戦略の膨大な配列があり、使用するものはサーバーの実装と要件に完全に依存します。
ファイアウォール、IDS、または他のネットワーク制御ツールを使用しないと、アプリケーションへのサービスを拒否することからDDOSを実際に停止することはできません。ただし、アプリケーションを変更して、ブルートフォース攻撃を大幅に困難にすることができます。
これを行う標準的な方法は、lockoutまたはprogressive delay。ロックアウトは、N回ログインに失敗した場合、IPがX分間ログイン要求を行うことを防ぎます。プログレッシブ遅延は、各不正ログイン要求の処理にますます長い遅延を追加します。
Tomcatの認証システムを使用している場合（つまり、<login-constraint>要素をwebapp設定で使用する場合） Tomcat LockoutRealm を使用する必要があります。これにより、多数の不正なリクエストを行った場合にIPアドレスを簡単にロックアウトに配置できます。
Tomcatの認証システムを使用していない場合は、より具体的な情報を取得するために、使用しているものに関する詳細情報を投稿する必要があります。
最後に、APIキーの長さを単純に増やすことができます。 64ビットは、検索するのに乗り越えられないほど巨大なキースペースのように見えますが、現代の標準ではその重みが低くなっています。予想よりもはるかに安全性を低下させる要因はいくつかあります。
- ボットネット（または他の大規模ネットワーク）は、保護が設定されていない場合、毎秒何万回も試行する可能性があります。
- キーの生成方法とエントロピーの収集方法によっては、de factoキースペースがはるかに小さくなる場合があります。
- 有効なキーの数が増えると、有効なキーを見つけるために試行する必要のあるキーの数が（少なくとも理論的には）急激に減少します。
APIキーの長さを128（または256、または512）に増やすことはそれほどコストがかからず、ブルートフォース攻撃の検索スペース（ひいては難易度）を大幅に増やすことができます。
DDOS攻撃の緩和：
ただし、DDOS攻撃を軽減するには、もう少し足を踏み入れる必要があります。 DDOS攻撃はハードに対して防御するのが難しく、サーバーが接続されているネットワークを制御しない場合は特に困難です。
そうは言っても、サーバー側でできることはいくつかあります。
- mod_security などのWebアプリケーションファイアウォールをインストールおよび構成して、定義したルールに違反する着信接続を拒否します。
- Snort などのIDSシステムをセットアップして、DDOS攻撃が発生したことを検出し、それを軽減するための最初のステップを実行します
- @ Martin Mullerの投稿 を参照してください。別の優れたオプション、 fail2ban
- here の説明に従って、独自のTomcat
Valveを作成し、User-Agents（またはその他の基準）を最後の防衛線として。
ただし、最終的には、DDOS攻撃を無料で阻止するためにできることは限られています。サーバーには、非常に多くのメモリ、非常に多くのCPUサイクル、非常に多くのネットワーク帯域幅があります。十分な着信接続がある場合、最も効率的なファイアウォールでさえ、あなたがダウンするのを防ぎません。より高い帯域幅のインターネット接続とより多くのサーバーに投資する場合、または Amazon Web Services にアプリケーションをデプロイする場合、または多くのコンシューマーの1つを購入する場合、DDOS攻撃をよりうまく乗り切ることができます。エンタープライズDDOS緩和製品（ @ SDudeの投稿には優れた推奨事項があります ）。これらのオプションはいずれも安価、迅速、簡単ではありませんが、利用可能なものです。
ボトムライン：
DDOSを軽減するためにアプリケーションコードに依存している場合、すでに失われています
十分に大きい場合は、それだけで止めることはできません。必要なすべての最適化をアプリレベルで実行できますが、それでもダウンします。予防のためのアプリレベルのセキュリティ（FSQの答えのように）に加えて、実績のあるソリューションを使用して、重荷を専門家に任せる必要があります（ビジネスに真剣な場合）。私のアドバイスは：
- CloudFlare または Incapsula にサインアップします。これは彼らにとって日々です。
- APIリクエストの第2段階として AWS APIゲートウェイ を使用することを検討してください。 Amazon scaleでAPIのフィルタリング、スロットル、セキュリティ、自動スケーリング、およびHAをお楽しみいただけます。その後、有効なリクエストをマシンに転送できます（Amazon内外）
インターネット-> CloudFlare/Incapsula-> AWS API Gateway-> APIサーバー
0,02
PS：この質問は Sec に属すると思う
最善の方法は、失敗したIPアドレス（たとえば3回）に対してサービスへのアクセスを完全に防ぐことです。 Tomcatがこのユーザーのスレッドを開始する前に攻撃者がブロックされるため、これによりサーバーからの負荷の大部分がかかります。
これを達成するための最良のツールの1つはfail2ban（ http://www.fail2ban.org ）と呼ばれます。すべての主要なLinuxディストリビューションでパッケージとして提供されます。
基本的に、失敗した試行をファイルに記録し、fail2banのカスタムフィルターを作成する必要があります。 Darryn van Tonderが彼のブログに独自のフィルターを作成する方法の良い例を示しています： https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/
D-DOSの攻撃が深刻な場合、アプリケーションレベルのチェックはまったく機能しません。帯域幅全体がD-DOSクライアントによって消費され、アプリケーションレベルのチェックはトリガーされません。実際には、Webサービスはまったく実行されません。
重度のD-DOS攻撃からアプリケーションを安全に保つ必要がある場合は、お金を払ってサードパーティのツールに依存する以外の選択肢はありません。クリーンパイププロバイダー（良好なトラフィックのみを送信する）ツールの1つで、過去の経験を活用できます。 Neustar
WebサイトでD-DOS攻撃が軽度の場合、アプリケーションレベルのチェックを実装できます。たとえば、以下の構成では、 単一IPからの呼び出しを制限する で引用されているように、単一IPからの接続の最大数を制限します
<Directory /home/*/public_html> -- You can change this location
MaxConnPerIP 1
OnlyIPLimit audio/mpeg video
</Directory>
D-DOS攻撃の詳細については、 Wikiリンク をご覧ください。以下を含む予防および対応ツールのリストを提供します：ファイアウォール、スイッチ、ルーター、IPベースの予防、D-DOSベースの防御
そして最後に
Clean pipes（すべてのトラフィックは、「クリーニングセンター」または「スクラビングセンター」を経由します。 「悪い」トラフィック（DDoSおよびその他の一般的なインターネット攻撃）を分離し、良好なトラフィックのみをサーバーに送信するプロキシ、トンネル、直接回線などのさまざまな方法）
クリーンパイプの販売代理店は12社あります。
ここにいくつかのアイデアがあります。さらに多くの戦略がありますが、これで開始できます。また、Amazonが頻繁にddosを取得し、システムがこれらの攻撃からそれらを強化するいくつかのヒューリスティックを持っている傾向があることを認識します（したがって、とにかく使用する必要があるElastic Load Balancingを使用している場合は特に）。
- CDNを使用します-多くの場合、ddoを検出して防御する方法があります。アカマイ、マスター、またはアマゾン独自のクラウドフロント。
- 不快なIPをブラックリストに登録するには、iptablesを使用します。この周辺のツールが多ければ多いほど、ブロック/ブロック解除の速度が上がります
スロットルメカニズムを使用して、大量のリクエストを防止する
アプリケーションに到達する前に、非常に大きい要求（たとえば、1〜2 MBを超える、写真アップロードサービスまたは同様のものがない限り）を自動的に拒否します。
システム内の他のコンポーネントへの接続の総数に制限を設けることにより、連鎖障害を防ぎます。たとえば、データベースサーバーへの接続を1,000回開いてデータベースサーバーを過負荷にしないでください。
標的を絞った高度に分散したDOS攻撃の場合、唯一の実用的な解決策は（攻撃を吸収する能力を提供する以外）、攻撃のプロファイルを作成し、「tells」を特定し、そのトラフィックを低リソースハンドラーにルーティングすることです。
あなたの質問にはいくつかの情報があります-リクエストは無効ですが、おそらくそれを決定するのにコストがかかりすぎると思われます。要求が特定のネットワークグループから発信され、おそらくバーストで発生すること。
あなたのコメントでは、少なくとも1つの他のテルを教えました-ユーザーエージェントはnullです。
追加のコンポーネントを追加せずに、接続をターピットすることから開始できます。プロファイルに一致する要求が来たら、先に進み、キーを検証しますが、コードを1〜2秒間スリープさせます。これにより、これらのクライアントからのリクエストのレートがわずかなコストで削減されます。
別の解決策は、tellに一致するログ障害を使用し、 fail2ban を使用して、ファイアウォールをリアルタイムで再構成して、送信元アドレスからすべてのパケットをしばらくドロップすることです。
いいえ、影響を受けるデバイスをつかまなくてもアプリを識別できる可能性は低いでしょう。