横になる
先ほどサイトをサポートしていた顧客は、サイトが嘘をついていると不満を言い、500エラーを出しました。 彼はASP.NET WebFormsに標準サイトを持っています。非常に負荷が高いとは言いませんが、データベースのパフォーマンス（別のサーバー上のMS SQL Server）に問題がありました。 最近、データベースサーバーが変更され、データが転送されました。
このサイトは顧客のメインビジネスではないため、実際にはメンテナンスされていません。 彼は、監視およびメトリックの収集を設定しておらず、一般的には特に監視されていません。
テレメトリデータ
どのような異常が目を引きましたか：
- w3wpプロセスはCPUの50％以上を使用しました（通常ははるかに少ない）。
- このプロセスのスレッド数は着実に増加しています（サイトには顧客にサービスを提供する時間がありませんでした）。
- データベースサーバー上のディスクが100％（アクティブ時間）で使用されました。
- プロジェクトベースのあるディスクへのアクセスのキューの長さが長かった（通常はゼロ単位の領域）。
- データベースサーバーのRAMは完全に使用されます。
- プロファイラーは、データベースにアクセスするホットメソッドが1つあることを示しました。
DBMSのチューニング
私の最初の仮説は、その転送によるデータベースのサーバー側の問題に関連していました：彼らは何かを設定するのを忘れ、統計の収集やインデックスの再構築などの仕事をしません。
メモリ-DBMSを転送するときに、新しいサーバーでのRAMの使用を制限することを忘れていたことがすぐに明らかになりました-それを制限します。 過去の経験によると、この構成は24GBで十分でした（合計32個のうち）。
ジョブの確認-すべてのルール。 チューニングアドバイザーを起動し、不足しているインデックスを終了します（プロファイラーからのホットリクエスト用のインデックスもありました）。 排気はゼロに近く、サイトはダウンしています。
IIS
ログにアクセスすると、すぐにすべてが明らかになります-DDoS：
初めてこの状況になったとき、誰がそれを必要としていたのかは不明です。 より多くのリクエストがありますが、ログはどうですか？
ログには、1秒あたり約200のリクエストがあります（通常のユーザーは、メトリックで1分あたり最大10を生成します）。 異なるIPからのすべてのリクエスト、同様のユーザーエージェントのみがそれらを結合します。
これはよく知られたタイプの攻撃です。Pingbackが有効になっている（デフォルトで有効になっている）WordPressサイトは、他のサイトのDDOS攻撃で使用できます。 Habréの詳細な
記事 。
クエリフィルターの構成
要求をフィルタリングできるレベルはいくつかあります。 最初はファイアウォールです。 私たちはipを食べます-新しいものを収集するスケジュールに従って、それらをファイアウォールに追加します。 長所-優れた速度、ログにジャンクリクエストはありません。 短所-スクリプトを記述して従う必要があります。
2番目のレベルはIIS自体です（明らかなマイナスから-ガベージリクエストはログに送られます）。 3番目のレベルは、モジュールを作成して使用することです。 これは最も柔軟なアプローチですが、時間がかかり、生産性が低くなります。
最小限のアクションで解決策を得るために、2番目のレベルで停止しました。
IISには、要求をフィルタリングするための多くの機能があります。 この場合、
リクエストのフィルタリングが適しています。
インストールとセットアップの詳細。サイトを選択→フィルタリングのリクエスト→ルール→フィルタリングルールの追加
そして、Header：User-AgentにWordPressという単語があるすべてのリクエストを除外することを示します。
または、web.configファイルで適切な設定を指定できます。
<system.webServer> <security> <requestFiltering> <filteringRules> <filteringRule name="ddos" scanUrl="false" scanQueryString="false"> <scanHeaders> <clear /> <add requestHeader="User-Agent" /> </scanHeaders> <denyStrings> <clear /> <add string="WordPress" /> </denyStrings> </filteringRule> </filteringRules> </requestFiltering> </security> </system.webServer>
このフィルターを適用した直後に、サイトが獲得しました。 すべてのインジケータが正常に戻りました。 すぐにログを確認した場合、すべてが30分もかからなかったでしょう。
IISで他にできることは何ですか？
IISは、Webアプリケーション用の非常にクールで強力なサーバーです。 要求を管理された環境に転送することに加えて、彼は多くのことを行う方法を知っており、パフォーマンスの観点から、管理されたソリューションよりもはるかに優れています。
[
リクエストフィルタリング]セクションでは、メソッド、URLセグメント、クエリパラメーター、拡張機能など、さらに多くの異なるフィルターを構成できます。 asp.netプロジェクトでPHP固有のクエリパラメーターを無効にできます（htaccessまたはパスワードを使用してファイルにアクセスしようとします）。 たとえば、SQLインジェクションを含む悪意のあるクエリを禁止できます。 これは、これらの攻撃に対する保護としてではなく、サーバーリソースを節約するために行われます。IISはこれらの要求を個別に拒否し、最小限のメモリとプロセッサ時間で迅速に実行します。
別のメカニズムは、
IPアドレスとドメインの制限と呼ばれ
ます 。 このメカニズムにより、IPアドレスのホワイトリストとブラックリストを作成して、サイトへのアクセスを制限できます。 特定のIPからのみ、テストサイトまたは管理パネルへの悪意のあるパーサーまたはその逆のオープンアクセスをブロックできます。 詳細については
公式ドキュメントをご覧ください。
そして、DDoS攻撃や不要なパーサーに対抗するのに役立つ3番目のメカニズムは、
動的IPアドレス制限です。常に変化する攻撃者のIPアドレスを監視できるとは限りません。 ただし、このツールを使用すると、リクエストの頻度を制限できます。 このため、IISは1つのIPアドレスからの異常に多数の要求に403または404を迅速に返します。
公式ドキュメント 。
結論
ログをオフにせず、監視を設定します。これにより、インジケータの異常について明確に警告されます。 これは迅速かつ安価に行うことができ、インシデントを調査する時間を節約できます。 監視の設定、および管理および組織の対策はこの記事の範囲外です。