DDoS-障害時の分散攻撃-大まかに言えば、いくつかのタイプがあります。 ネットワークレベルのDDoS — IP-TCP-HTTP、アプリケーションレベルのDDoS —リクエストの流れによりサーバーのパフォーマンスが大幅に低下する、または動作できなくなる場合、およびホストレベルのDDoSを追加する場合—サイトが実行されているが、サーバーの負荷がホストによって設定されたクォータを超えている場合、その結果、サイトの所有者にも問題があります。
ネットワークレベルで到達した場合、あなたのビジネスがそのような高さまで上昇したことを祝福することができ、あなたはおそらくこの場合に何をすべきかを知っているでしょう。 他の2つのタイプのDDoSを検討します。
ボット
すべてのCMSは、1秒間に1つのリクエストでも、Hetsner VDSで許容できない負荷がかかるように、入力、装飾、および調整できます。 したがって、一般的な場合、タスクは、可能であれば、サイトへの不要なリクエストをすべて除外することです。 同時に、DDoS保護の存在による不便を経験することなく、サイトにアクセスできることを保証する必要があります。
ボットにはいくつかの種類があります。 役に立つ（必要な検索）、役に立たない（不要な検索とクモ）そして有害な（有害な）。 最初の2つのタイプは、ユーザーエージェントで自分自身について真実を伝える立派なボットです。 役に立たないボットは.htaccessで除外され、有用なボットはサイトに渡され、有害なボットをキャッチします。 たとえば、悪意のあるボットがYandexボットで表される場合、簡単にするために省略します（解決策もあります-Yandexのipを使用すると、ボットかどうかを知ることができ、すぐに禁止できます）。
バックエンドに有害なボットを許可しないことで、サーバーの負荷を必要に応じて削減できます。
有害なボットは、スマート（CookieとJavaScriptを理解する）と愚か（理解しない）の2つのタイプに分類できます。 JavaScriptを理解するDDoSボットはまったく存在しないと考えられていますが、これは深刻なネットワークDDoS攻撃のためです。 私たちの状況では、過度にアクティブな匿名スパイダーでさえ正式にDDoSボットになります。
今のところ、愚かなボットを取り除きましょう。
保護
セキュリティコードは提供しません。シンプルです-数十行のphp; この記事よりもはるかに短く簡単です。 ロジックを説明しましょう。 クライアントにCookieを記録します（Cookie検証方法は、 強力なDDoS攻撃からの保護にも使用されます）。 任意の名前とコンテンツで、サイトによって既にインストールされているCookieを使用できます。
簡単にするために、サイトへの単一のエントリポイントがあると考え、そこにddos-shieldを埋め込みます。 リクエストに応じてCookieをすぐに確認します。Cookieがあれば、間違いなくサイトにスキップします。 そうでない場合は、IPペアとユーザーエージェントを別のディレクトリにある別のファイルとして書き込みます。 このファイルはip-ua.txtと呼ばれます。ここで、uaは10進数（crc32（$ _ SERVER ["HTTP_USER_AGENT"]））はユーザーエージェントの短いハッシュです。
クエリ時間、リクエストページ（url）、User-Agentで行を分割してファイル自体に書き込みます。SypexGeoを使用するかmaxmind.comに登録して、5日間geoipデータベースに無料でアクセスできます。 、このファイルにもあります。
同じ名前ip-ua.txtのファイルが既に存在する場合、新しいリクエストのすべての情報をファイルの最後に追加します。
別のポイント-私たちのサイトからのAJAXリクエスト。 もしそうなら、それらはラベルで識別するために、間違いなくスキップする必要があります。 ボットも攻撃する可能性は最小限です。
スキップされたステップ-ip-ua.txtを記録または追加する前に、このIPからのリクエストがすでに到着していることを確認し、ユーザーエージェントに注意を払いません。
count(glob(__DIR__ . "/suspected/$ip-*.txt")) > 0
重要なのは、各IPにCookieを受信する機会を1回与えることです。 彼がそれなしで2度目に到着した場合、この不平等は機能し、クライアントを別のページcheck-human.phpにリダイレクトし、そこで彼はGoogle recaptchaを使用してショーケースと車両でチューリングテストに合格します。 合格しなかった場合-さようなら（再度、キャプチャ）、合格した場合-さらに別の特別なディレクトリ/ホワイトリストにip-ua.txtファイルを作成します。 そして、最初に、Cookieのチェックと一緒に、ip-uaペアが/ホワイトリストに入るのをチェックします-もちろん、これらもスキップします。 この戦術により、ブラウザでCookieが無効になっており、JavaScriptが有効になっている（またはJavaScriptが無効になっているがCookieは機能する）ユーザーにサイトで作業する機会を与えることができます。
ボットネット
原則として、それだけです。 愚かなボットは除外され、スマートになりました。 スマートなものの場合、このアプローチはすでにインテリジェントです-/疑わしいディレクトリを開き、サイズでファイルをソートします。 一番上にあるのは最大のもので、数十キロバイトから数百キロバイトの持続的な試みが私たちを通り抜けようとしています。 私たちは開いて見て、これは本当にボットであると確信しています-IP、場所、要求時間、要求期間、要求ページ、ユーザーエージェントのシフトによって-これは通常はっきりと見えており、すべてが私の目の前にあります。 原則として、たとえば、10回以上失敗したすべてのファイルを選択し、.htaccess経由で禁止にipを送信できます。 しかし、これは良くありません、それらをcaptchaに送る方が良いです-結局のところ、複数の人が1つのIPを介してインターネットに行くことが起こります。
これは、スマートボットの問題を非常によく解決します。 なんで？ あなたが注文された場合、おそらく1つのdDozerだからです。 また、彼らは賢く、愚かでもあります。 そして、愚かな人は通常、スマートで愚かなボットに1つのボットネットを使用し、1つのIPを使用します。 したがって、Cookieを受け入れてJavaScriptを実行するボットをブロックします。 さらに、スマートボットははるかに少なく、コストも高く、動作も遅くなるため、この方法は問題の攻撃の大部分に対処するのに効果的です。
私の観察によれば、このスキームによると、サイトの実際のユーザーの約1％-2％はcaptchaを使用する必要があり、残りはまったく気付かなかった-これは非常にユーザーフレンドリーです。 さらに、初めてログインする人でも「投稿」の最初のリンク方法とは対照的に、「スタブ」は表示されませんが、サイトで静かに作業します。
匿名化のために特別なブラウザソフトウェアを使用しているユーザーには、特定の不便さがあります-Cookieを消去するIPおよびクライアントユーザーエージェントを動的に変更しますが、このオプションは考慮しません。
私の場合、サーバーの負荷はすぐに低下しました。 ボットはしばらくの間屠殺されました。 数日後、私はそれらがなくなったことに気づきました-ドーザーはまた、リソースをアイドル状態で使うことを好みません。 保護を削除しました。
ロジック開発
保護のロジックを変えることができます-JavaScriptのチェックを追加します（たとえば、Cookieを置きます）。 人に関連した「悪い」行動のケースを防ぐために、キャプチャにリダイレクトされてパスしなかった人を監視できます。 パーソナライズされたCookieを作成し、クライアントがアクセスする回数を監視し、制限を超えた場合はcaptchaに送信することもできます。 トークンシステムを実装できます。 時間を遅らせてリダイレクトチェーンでボットを起動し、速度を落とすことができます。 Roskomnadzorのように、IPボットを分析し、グリッド全体を禁止できますが、これは必要に応じて行います。 法律20-80によれば、最も単純な必要なソリューションは、必要なものすべてを解決します。
主なもの-明らかに悪意のあるIPを迅速に隔離および禁止し、疑わしい場合、サーバーの負荷を即座に大幅に削減し、攻撃を撃退するためのさらなるアクションを準備する時間を確保します。
このような簡単な方法で、不正な競争相手を金で罰することができます。
免責事項：この記事は、アプリケーションレベルでの軽度のDDoS攻撃、主に共有ホスティング上のサイトについてのみ記述されており、利用可能なリソースの制限は限られています。