IPテーブルでIPをブロックすると、DOS（DDOSではない）攻撃から保護されますか？

Question

私はネットワークセキュリティにかなり慣れていないので、エクスプロイトの自動検出/防止に使用できるFail2Banフレームワークについて学んだところです。構成された時間内に構成された試行回数の後にIPをIPTablesに追加することでIPを自動的にブロックするルールを設定することにより、DOS攻撃から身を守ることができると述べています。私の質問は、あなたがしているすべてが彼らの要求を拒否しているなら、それでも彼らはそのポートで情報を送信することを試みるためにアクセスすることができるということです。彼らはまだあなたのサーバーをリクエストで過負荷にできませんか？

私はこれについていくつかの調査を行いましたが、見つけることができる唯一の潜在的な理由は、DOS攻撃では、ダウンロード帯域幅よりも小さいことがほぼ保証されているアップロード帯域幅によって制限されているためです。 IPをブロックして情報の処理を行わない場合は、リクエストでできる限り激しく攻撃し、実際にレンガの壁に小石を投げています。これは正しいです？この方法でこれをDOSから保護する他の理由は何ですか？

Slartibartfast · Accepted Answer

私の質問は、あなたがしているすべてが彼らの要求を拒否しているなら、それでも彼らはそのポートで情報を送信することを試みるためにアクセスすることができるということです。彼らはまだあなたのサーバーをリクエストで過負荷にできませんか？

はい、攻撃者のサブセットはできます。彼らの帯域幅があなたの帯域幅よりも大きい場合、または彼らが彼らの帯域幅よりも速くあなたの帯域幅を使用して違いを相殺する方法を見つけた場合、あなたは帯域幅が不足し、正当なトラフィックが通過できなくなります。

これは実際にはいつでもtrueであり、attacker_effective_bandwidth + legitimate_bandwidth> server_bandwidthなので、攻撃者のリソースだけに依存するのではなく、過剰にプロビジョニングする度合いにも依存します。

Fail2banは、ユーザーがログに記録または監視するアクセスの試みとエクスプロイトに焦点を合わせていることにも注意してください。一部のサービス拒否攻撃は、ログに記録されない可能性がある通信（ICMPエコー要求など）に依存しており、fail2banをトリガーしない可能性があります。

iPをブロックし、情報の処理を何も行わない場合、実際にレンガの壁に小石を投げています。これは正しいです？

保存しているリソースがCPUであり、fail2banがCPU使用率の原因となるすべてのトラフィックに基づいて/ triggerを監視する場合のみ、これは正しいです。パケットのドロップにはかなりの量のCPUが必要ですが、パケットを使用して他のことを行うよりもはるかに小さくなります。

この方法でこれをDOSから保護する他の理由は何ですか？

私はこの質問を理解していませんが、fail2banはあなたが使用するツールの1つであり、妥当なツールだと思います。ただし、サイトのダウンによるコストが、それを防ぐために必要なツールを取得して維持するコストよりも大きい場合は、他のツールを追加することを検討する必要があります。

dFrancisco · Answer

あなたの質問に答えるために、はい、攻撃者のIPをブロックしてサーバーをDoSすることは効果的な緩和策です。これには2つの基本的な理由があります。

理由＃1：仮説的に、攻撃者が帯域幅でサーバーを圧倒する（ファイルをアップロードするなど）ことを意図して基本的なフラッドベースの攻撃を行っている場合、IPをブロックすると、サーバーの帯域幅が大幅に減少します。（サーバーがRaspberry Piに電力を供給するホイールで動作しているハムスターでない限り）サーバーに影響を与えない程度に攻撃する必要があります。

現実的には、単一の攻撃ノードにはリクエストでフラッディングしてサーバーをクラッシュさせる帯域幅機能がないため、＃1はDoS攻撃のまれな攻撃戦略です。より一般的なケースは

理由＃2：アプリケーションレベルのDoS攻撃ははるかに効果的です。たとえば、ウェブサイトに、提供されたパスワードのサーバー側の暗号ハッシュを実行するログインページがあるとします。スマートな攻撃者は、DoS攻撃をそのログインリクエストに集中させることでサーバーをクラッシュさせ、通常の負荷がはるかに軽いときにサーバーが数百または数千の同時ログインを計算できるようにする可能性があります。この場合、説明したFail2Banフレームワークは、攻撃者が偽のログインリクエストをフィルタリングするため、完全に機能するはずです。

攻撃者のメモでスプーフィングされたIPアドレスを頻繁にローテーションすることで、緩和策全体を回避できますが、これは奇妙なDDoS/DoSハイブリッドになり、古い方法のDoSについて具体的に質問しました。したがって、答えは立っています。攻撃するIPを単にブロックするだけで十分な防御になります。

ximaera · Answer

ここでおそらく最も重要なことは、緩和に関して、最近のDoS攻撃とDDoS攻撃を区別することはほとんど役に立たないことです。単一の固定IPソースから実際のサービス拒否攻撃が発生することはもうありません。

明らかな唯一の例外は、攻撃者が特別に細工したパケットを生成して、DoSの可能性がある脆弱性を悪用する場合です（例 nullポインタ参照解除パケット処理コードのどこかにあるここに例そのような脆弱性の）。しかし、エクスプロイトを実行するソースIPアドレスをブロックすることは、それを軽減するための本当に良い方法ではありません。脆弱なシステムにパッチを当てることです。

理論的には、分散型攻撃よりも単純なDoS攻撃を処理する方が簡単です。ただし、それらは緩和するのが簡単すぎるため、今日ではほとんど絶滅しており、（Fail2Ban）について質問しているツールは、絶滅した攻撃を防ぐためのものではなく、実際のアプリケーションを想定して記述されています。

これを考慮して、IPアドレスのブロック（Fail2Banまたは手動による）は、2つの条件が同時に満たされた場合にのみ意味があります。

進行中のDDoS攻撃は、サーバー自体（またはWebアプリケーションの背後にあるデータベースサーバーなどの背後にあるもの）のパフォーマンスのみに影響します。ただし、その前のネットワークトランスポートには影響しません;
攻撃に関与するすべての送信元IPアドレスがスプーフィングされていないことを何らかの方法で確認できます。例えば。 DDoS攻撃はハンドシェイクベースのネットワークサービス（クライアントに対してシークレットをネゴシエートし、クライアントが実際にシークレットを受信したことを確認できる）をターゲットとし、基本的なハンドシェイクを正常に渡します。別の例を考え出すこともできますが、上記の説明は、最も頻繁なシナリオをかなり要約しています。

典型的なHTTPSサーバーに関しては、たとえばTCP接続フラッド、SSL/TLSハンドシェイクフラッド、POSTフラッド、Slowloris、など（単純なフラッドを超えてレイヤー7攻撃を分類するのはかなり困難です）、ほとんどすべての場合、両方の要件を満たします。

ただし、十分な大きさのPOSTフラッドは実際にはサーバーの前のネットワークトランスポートに影響を与える可能性がありますが、基礎となるTCPを防ぐため、IPブロッキングはそれでも役立ちます。接続が確立されていないため、悪意のあるボットはその後大きなPOST本体をサーバーに送信できません。これにより、残りの悪意のある着信トラフィックを、ほとんどの場合処理が容易な低速のSYNフラッドに効果的に制限できます。

さらに、HTTPベースのフラッドがネットワークトランスポートにもたらす主な影響は、サーバーが応答として生成するアウトバウンドトラフィック（今日のHTTPではインバウンドトラフィックの約11〜12倍になる）と、 HTTPフラッドのIPソースは、上記で概説した理由により、これも排除します。

同時に、IPブロッキングは、ICMPフラッド、SYNフラッド、UDPフラッドなど、少なくとも要件＃2を満たさない攻撃に対してはほとんど役に立ちません。そして増幅攻撃に対して、これは、ほとんどの条件下で、インバウンドトラフィックに関して非常に強力であるため、要件＃1を満たしません。

たとえば、SYNフラッドの送信元IPアドレスを検証できないということは、必ずしも偽装されているとは限らないことに注意してください。ただし、なりすましの可能性があるIPアドレス範囲をブロックすると、正当なユーザーがサービスにアクセスできなくなる可能性があります。実際、攻撃者の意図は、トラフィックに存在するソースがほとんどないときに、パケットベースのフラッドのソースIPアドレスを自動的に（たとえば、上記のFail2Banツールを介して）ブロックし、重要なスプーフィングを開始するように仕向けることです。お住まいの国で最大のISPのIP範囲などのIPアドレス範囲、または毎秒100メガビットの任意のフラッドレートで、およそ1時間で列挙できる、最大40億アドレスのグローバルIPv4アドレス範囲全体—私は実際にそれを私の人生で数回見ました。