サービス拒否攻撃を受けています。複数のネットワーク（異なるサブネット上の異なるIP）からのトラフィックを見る場合、分散型サービス拒否（DDoS）があります。すべてが同じ場所から来ている場合、単純な古いDoSがあります。可能であれば、確認しておくと役立ちます。netstatを使用して確認します。ただし、これは難しいかもしれません。
通常、サービス拒否は、トラフィックベースと負荷ベースの2つのカテゴリに分類されます。最後の項目（クラッシュするサービス）はエクスプロイトベースのDoSであり、まったく異なります。
発生している攻撃の種類を突き止めようとしている場合、（wireshark、tcpdump、またはlibpcapを使用して）トラフィックをキャプチャすることができます。可能であれば、できるだけ多くのトラフィックをキャプチャすることに注意してください。
頻繁ではないが、これらはボットネット（一部の攻撃者の中央制御下にある侵害されたホストのネットワークであり、そのホストが入札を行う）から発生します。これは、攻撃者がトラックをカバーしながら、異なるネットワーク上の多くの異なるホストのアップストリーム帯域幅を（非常に安価に）攻撃するための良い方法です。低軌道イオンキャノン（代わりマルウェア由来の自発的であるにもかかわらず）ボットネットの一例です。ゼウスはより典型的なものです。
トラフィックベース
トラフィックベースのDoSを使用している場合、サーバーへのトラフィックが非常に多く、インターネットへの接続が完全に飽和していることがわかります。他の場所からサーバーにpingを送信すると、パケット損失率が高くなります（使用中のルーティング方法によっては）場合によっては、非常に高い遅延が発生することもあります（pingが高い）。この種の攻撃は通常、DDoSです。
これは本当に「騒々しい」攻撃であり、何が起こっているのかは明らかですが、サーバー管理者が緩和することは困難です（そして、共有ホスティングのユーザーが緩和することは基本的に不可能です）。ISPの支援が必要になります。あなたがDDoSにさらされていることを彼らに知らせてください。
ただし、ほとんどのISPおよびトランジットプロバイダーは、何が起こっているかを積極的に認識し、サーバーのブラックホールルートを公開します。つまり、サーバーへのルートを可能な限り低コストで公開します。つまり、サーバーへの0.0.0.0トラフィックをインターネット上でルーティングできなくなります。これらのルートは通常/ 32sであり、最終的には削除されます。これはまったく役に立ちません。その目的は、ISPのネットワークを洪水から保護することです。この間、サーバーは事実上インターネットアクセスを失います。
ISP（または、ASを所有している場合はあなた）が支援できる唯一の方法は、可能性のあるDDoSトラフィックを検出してレート制限できるインテリジェントなトラフィックシェーパーを使用している場合です。誰もがこの技術を持っているわけではありません。ただし、トラフィックが1つまたは2つのネットワーク、または1つのホストから来ている場合は、前方のトラフィックもブロックできる可能性があります。
つまり、この問題についてできることはほとんどありません。最善の長期的ソリューションは、インターネット上のさまざまな場所でサービスをホストすることです。これらの場所は、個別にかつ同時にDDoS処理する必要があり、DDoSのコストが大幅に上がります。このための戦略は、保護する必要があるサービスによって異なります。DNSは、複数の権限のあるネームサーバー、バックアップMXレコードとメールエクスチェンジャーを使用したSMTP、ラウンドロビンDNSまたはマルチホーミングを使用したHTTPで保護できます（ただし、いずれにせよ、ある程度の低下が見られる場合があります）。
ロードバランサー自体が同じ問題の影響を受け、ボトルネックを作成するだけなので、ロードバランサーがこの問題の有効な解決策となることはめったにありません。問題はパイプが飽和状態になっていることであるため、IPTablesまたはその他のファイアウォールルールは役に立ちません。 ファイアウォールで接続が認識されると、すでに手遅れです。サイトへの帯域幅が消費されました。接続で何をするかは問題ではありません。着信トラフィックの量が通常に戻ると、攻撃は軽減または終了します。
可能であれば、Akamai、Limelight、CDN77などのコンテンツ配信ネットワーク（CDN）の使用を検討するか、CloudFlareやProlexicなどのDDoSスクラビングサービスの使用を検討してください。これらのサービスは、これらのタイプの攻撃を軽減するために積極的な対策を講じており、非常に多くの異なる場所で利用可能な帯域幅が非常に多いため、一般にそれらをフラッディングすることはできません。
CloudFlare（またはその他のCDN /プロキシ）を使用する場合は、サーバーのIPを非表示にしてください。攻撃者がIPを見つけた場合、CloudFlareをバイパスしてサーバーに直接DDoSを実行できます。IPを非表示にするには、安全でない限り、サーバーは他のサーバー/ユーザーと直接通信しないでください。たとえば、サーバーからユーザーに直接メールを送信しないでください。CDNですべてのコンテンツをホストし、独自のサーバーがない場合、これは適用されません。
また、一部のVPSおよびホスティングプロバイダーは、他の攻撃よりもこれらの攻撃を軽減するのに優れています。一般に、彼らが大きいほど、彼らはこれにより良くなります。非常によくピアリングされ、多くの帯域幅を備えたプロバイダーは当然ながら回復力があり、アクティブで完全にスタッフが配置されたネットワーク運用チームを持つプロバイダーは、より迅速に対応できます。
負荷ベース
負荷ベースのDDoSが発生している場合、負荷平均が異常に高いことに気づきます（プラットフォームや仕様に応じて、CPU、RAM、またはディスクの使用量）。サーバーは何も役に立たないように見えますが、非常に忙しいです。多くの場合、ログには異常な状態を示すエントリが大量にあります。多くの場合、これはさまざまな場所から来ており、DDoSですが、必ずしもそうではありません。 たくさんの異なるホストである必要すらありません。
この攻撃は、サービスに多くの高価な処理を実行させることに基づいています。これは、膨大な数のTCP接続を開いてそれらの状態を維持するように強制するか、サービスに過度に大きいファイルまたは多数のファイルをアップロードするか、非常に高価な検索を行うか、実際に処理が高価なことをするようなものです。トラフィックは計画した範囲内であり、引き受けることができますが、行われている要求のタイプは非常に多くのを処理するには高すぎます。
まず、この種の攻撃が可能であることは、多くの場合、構成の問題またはバグを示しています。あなたのサービスで。たとえば、過度に詳細なログを有効にし、書き込みが非常に遅いものにログを保存している場合があります。誰かがこれを認識し、大量のログをディスクに書き込む原因となる多くのことを行うと、サーバーのクロールが遅くなります。ソフトウェアは、特定の入力ケースに対して非常に非効率的な処理を行っている場合もあります。原因はプログラムと同じくらい多くありますが、2つの例は、サービスが終了しないセッションを閉じない状況と、子プロセスを生成して終了させる状況です。数万または数万の子プロセスを追跡する状態で数万の接続が開いている場合、問題が発生します。
最初にできることは、ファイアウォールを使用してトラフィックをドロップすることです。これは常に可能というわけではありませんが、着信トラフィックに特徴がある場合（トラフィックが少ない場合はtcpdumpが便利です）、ファイアウォールでそれをドロップすることができ、トラブルを引き起こすことはありません。他にすべきことは、サービスのバグを修正することです（ベンダーと連絡を取り、長いサポートエクスペリエンスに備えてください）。
ただし、構成に問題がある場合は、そこから開始します。本番システムでのロギングを妥当なレベルに下げます（プログラムによっては、これが通常デフォルトであり、通常は「デバッグ」および「冗長」レベルのロギングをオフにすることを含みます。ユーザーが行うすべてが正確にログインし、詳細は、ログが冗長すぎる）。また、子プロセスと要求の制限をチェック、おそらくスロットル該当するとして、着信要求、IPあたりの接続、および許可された子プロセスの数を。
サーバーの構成とプロビジョニングが適切であればあるほど、この種の攻撃は難しくなることは言うまでもありません。特にRAMとCPUにケチをしないでください。バックエンドデータベースやディスクストレージなどへの接続が高速で信頼できることを確認してください。
エクスプロイトベース
サービスが呼び出された後、サービスが不可解に非常に速くクラッシュする場合、特にクラッシュに先行するリクエストのパターンを確立でき、リクエストが非定型であるか、予想される使用パターンと一致しない場合、エクスプロイトベースのDoSが発生している可能性があります。これは、わずか1つのホスト（ほとんどすべての種類のインターネット接続を備えた）から、または多くのホストから発生します。
これは多くの点で負荷ベースのDoSに似ており、基本的に同じ原因と緩和策があります。違いは、この場合、バグによってサーバーが無駄になることはなく、死ぬことだけです。攻撃者は通常、入力の文字化けなどのリモートクラッシュの脆弱性を悪用して、null参照解除やサービス内の何かを引き起こします。
これを不正なリモートアクセス攻撃と同様に処理します。 発信元のホストとトラフィックの種類を固定できる場合は、それらに対するファイアウォール。 該当する場合は、検証リバースプロキシを使用します。 法医学的証拠を収集し（トラフィックの一部を試してキャプチャします）、ベンダーにバグチケットを提出し、発信元に対しても虐待苦情（または法的苦情）の提出を検討します。
これらの攻撃は、エクスプロイトが見つかった場合、実装するのにかなり安価であり、非常に強力である可能性がありますが、追跡と停止が比較的簡単です。ただし、トラフィックベースのDDoSに対して有用な手法は、通常、エクスプロイトベースのDoSに対しては役に立ちません。