13

私は asp.net MVC Web アプリケーションを開発していますが、クライアントから、サービス拒否攻撃に対して可能な限り回復力を持たせるために最善を尽くすよう要求されています。彼らは、サイトを遅くしたり、サイトを閉鎖したりする意図で、サイトが悪意のある大量のリクエストを受信する可能性があることを心配しています.

これは、実際の Web アプリケーションの権限外であるとして、プロダクト オーナーと話し合ったことがあります。トラフィックを監視し、悪意のあるリクエストに対応するのは、ホスティング/ネットワーク チームの責任だと思います。

ただし、アプリケーションにはいくつかの予防措置が組み込まれている必要があると断言しています。ただし、CAPTCHA の実装は望んでいません。

特定の時間枠内でセッションに対して行うことができるリクエストの数を制限することが提案されています。私はこのようなことを考えてい ました ASP.NET MVC で要求スロットリングを実装する最良の方法は? ただし、クライアント IP ではなくセッション ID を使用すると、企業のファイアウォールの背後からアクセスするユーザーに問題が発生するため、IP はすべて同じになります。

彼らはまた、サイトの特定の領域をオフにする機能を追加することを提案しました-管理者ユーザーがデータベース集約的な領域をオフにできることを示唆しています.....しかし、これはUIを介して制御され、DOS攻撃を受けている場合は確かに管理者とにかく、ユーザーはそれにアクセスできません。

私の質問は、これを行う価値があるかどうかです。確かに、実際の DOS 攻撃はもっと高度なものでしょうか?

他に提案はありますか？

4

3 に答える 3

8

サービス拒否攻撃は、他の人々に対するサービスの安定性に影響を与える可能性がほとんどあります。この場合、ネットワーク DoS について話しているのですが、既に述べたように、これは通常、アプリケーション レベルでは発生しません。

理想的には、この種の攻撃はネットワーク レベルで軽減されます。Cisco ASA 5500 シリーズなど、このために構築された専用のファイアウォールがあり、基本的な保護から高スループットの緩和まで機能します。それらは非常にスマートなボックスであり、得られるスループットの正しいモデルが使用されている限り、これらのタイプの攻撃をブロックする効果を保証できます.

もちろん、これを行うハードウェア ファイアウォールにアクセスできない場合は、これらの種類の攻撃からの防御を支援するためにいくつかの一時的な対策を講じることができます。これらのいずれも、専用のファイアウォールの効果の半分にもならないことに注意してください。

そのような例の 1 つは、同時要求の最大数の制限を定義できるIIS モジュールの動的 IP 制限です。ただし、実際には、スクリプトや画像などをダウンロードするための同時要求スループットが高いブラウザーからの正当な要求をブロックし始める可能性があるという欠点があります。

最後に、私が以前に書いたような、非常に大雑把でありながら非常に効果的なことを行うことができます。基本的に、これは同じ IP からの重複したリクエストのログ ファイルを監視する小さなツールでした。/Homeでは、から 2 秒以上に 10 件のリクエストがあるとしましょう1.2.3.4。これが検出された場合、ファイアウォール ルール (シェル コマンドを使用して追加された Windows Advanced Firewall 内) が追加され、この IP からの要求がブロックされ、30 分後にルールが削除される可能性があります。

私が言うように、それは非常に大雑把ですが、サーバーレベルでそれを行う必要がある場合、それが行われるべき場所ではないため、実際には多くの賢明なオプションはありません. 責任はホスティングプロバイダーにあるという点で、あなたは正確です。

最後に、CAPTCHA についても正しいです。どちらかといえば、イメージ生成 (リソースを大量に消費する可能性があります) を何度も実行することで DoS を支援し、リソースをさらに枯渇させる可能性があります。ただし、CAPTCHA が有効になるのは、サイトが自動登録ボットによってスパムされた場合ですが、それはすでにご存知だと思います。

その能力を満足させるためだけにアプリケーション レベルで本当に何かをしたい場合は、アプリに IP ベースのリクエスト制限を実装することは可能ですが、90% 効果はありません (まだリクエストを処理する必要があるため)。

于 2013-02-05T12:11:37.307 に答える
2

絶対に稼働し続ける必要がある場合は、ソリューションをクラウドに実装してサーバーをスケーリングできますが、費用がかかる可能性があります...

別のアイデアは、登録ユーザーの IP アドレスをログに記録することです。DOS の場合、すべてのトラフィックを「善良な」ユーザーからの要求に制限します。

于 2013-02-05T11:30:39.490 に答える
2

アプリケーション レベルで真の DoS 攻撃を防止することは、実際には実行可能ではありません。これは、アプリケーションがアプリケーション プールに関連付けられているため、アプリケーションがアプリケーションを強制終了する前に Web サーバーを強制終了する可能性が高いためです。使用しているサーバー テクノロジによって定義されます。

この興味深い記事 http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 には、Windows 7、Windows Vista、および Windows 8 で最大 10 の同時実行があると記載されています。リクエスト。さらに、「高負荷下で非同期メソッドの利点を確認するには、Windows サーバー オペレーティング システムが必要です」という記述もあります。

アプリケーションに関連付けられているアプリケーション プールの HTTP.sys キュー制限を増やして、(スレッドの準備ができたときの後の計算のために) キューに入れられる要求の量を増やすことができます。これにより、HTTP プロトコル スタック (HTTP .sys) が、制限を超え、それ以上の要求を処理するためのワーカー プロセスがない場合に、HTTP エラー 503 を返さないようにします。

あなたは、顧客が「サービス拒否攻撃に対して可能な限り回復力を持たせるために最善を尽くす」ことを要求していると述べています。私の提案はあなたの状況では適切な手段ではないかもしれませんが、顧客の要件に対応するために、この記事で言及されているタスクベースの非同期パターン (TAP) の実装を検討することができます。

このパターンは、長時間の操作が実行されている間にスレッドを解放し、スレッドをさらなる要求に使用できるようにします (したがって、HTTP.sys キューを低く保ちます)。同時に、サードパーティ サービスへの複数の要求時にアプリケーションの全体的なパフォーマンスが向上するという利点もあります。または複数の集中的な IO 計算が実行されます。

この手段によって、アプリケーションが DoS 攻撃に対して回復力を持つようになるわけではありませんが、アプリケーションが提供されるハードウェアに対して可能な限り責任を持つようになります。

于 2013-02-05T20:50:09.153 に答える