Clever Geek Handbook

WebアプリケーションレベルのDDoS保護

ご存じのように、サイトに対するDDoS攻撃の強度はさまざまであり、攻撃に関与するホストの数、ネットワークパケットの数、および転送されるデータの量が重要です。 最も深刻なケースでは、特殊な機器とサービスを使用することによってのみ攻撃を撃退できます。







攻撃の量がネットワーク機器の帯域幅およびサイトにサービスを提供するサーバー（サーバープール）の計算能力よりも小さい場合、サードパーティのサービスに頼らずに攻撃を「黙らせる」ことができます。つまり、サイトに着信するトラフィックのソフトウェアフィルターを有効にします。 このフィルタは、攻撃に参加しているボットのトラフィックを除外し、「ライブ」サイト訪問者の正当なトラフィックをスキップします。







サイトに対するDDoS攻撃からのソフトウェアフィルターのスキーム



このフィルターは、DDoS攻撃に関与するボットがJavaScriptコードを実行できないという事実に基づいているため、ボットはフィルターの停止を超えないため、フロントエンド/バックエンドおよびサイトデータベースが大幅に軽減されます。 なぜなら DDoS攻撃の各GET / POSTリクエストを処理するには、サイトのバックエンドで20行以下のコードを実行し、2Kb未満のデータでスタブページを発行する必要があります。













  1. 残りのアプリケーションコードを呼び出す前に、フィルターをWebアプリケーションの最初の行と呼びます。 そのため、サーバーのハードウェアを可能な限りアンロードし、ボットに送信されるトラフィックの量を減らすことができます。
  2. 訪問者がフィルター条件に該当する場合、訪問者に特別なスタブページを提供します。 ページで、

    • リクエストされたページではなく、特別なページを発行する理由をお知らせします
    • JavaScriptを使用して、ユーザーのブラウザーに特別なCookieをインストールします。
    • ソースページへのJavaScriptリダイレクトコードを実行します。
  3. 訪問者に特別なCookieがインストールされている場合、フィルターはサイトの要求されたページに訪問者を透過的に渡します。
  4. 訪問者のIPアドレスが除外リストから自律システムに属している場合、トラフィックも透過的に渡されます。 この条件は、検索エンジンボットのフィルタリングを除外するために必要です。


github.comのプロジェクトをフィルターします 。







合成フィルターテスト



ノードの1つから負荷を取り除いた後、戦闘サイトのメインページでApache Foundationのabユーティリティをテストしました。







無効な結果をフィルターします。 







ab -c 100 -n 1000 https://cleantalk.org/ Total transferred: 27615000 bytes HTML transferred: 27148000 bytes Requests per second: 40.75 [#/sec] (mean) Time per request: 2454.211 [ms] (mean) Time per request: 24.542 [ms] (mean, across all concurrent requests) Transfer rate: 1098.84 [Kbytes/sec] received


フィルターをオンにした状態でも同じです。 







 Total transferred: 2921000 bytes HTML transferred: 2783000 bytes Requests per second: 294.70 [#/sec] (mean) Time per request: 339.332 [ms] (mean) Time per request: 3.393 [ms] (mean, across all concurrent requests) Transfer rate: 840.63 [Kbytes/sec] received


テスト結果からわかるように、フィルターを含めると、Webサーバーはフィルターなしの場合よりもほぼ1桁以上多くのリクエストを処理できます。 当然、私たちはJavaScriptをサポートしていない訪問者からのリクエストについてのみ話します。







実際のフィルターの適用、1つの小さなDDoS攻撃からサイトを保存した履歴



時々、当社の自社ウェブサイトhttps://cleantalk.orgで DDoS攻撃に遭遇します 。 実際、最後の攻撃中に、サイトのWebアプリケーションのレベルでDDoSからのフィルターを適用しました。







攻撃開始



攻撃は2018年1月18日18:10 UTC + 5に開始され、URL https://cleantalk.org/blacklistsでGETリクエストを使用して攻撃されました。 追加の1000-1200 kbit /秒の着信トラフィックが、フロントエンドサーバーのネットワークインターフェースに現れました。 各サーバーに150 /秒のGET要求の負荷を受け取りました。これは標準負荷の5倍です。 その結果、フロントエンドサーバーとデータベースサーバーの平均負荷は劇的に増加しました。 その結果、無料のphp-fpmプロセスがないため、サイトでエラー502が生成され始めました。







攻撃分析



ログの調査にしばらく時間を費やした結果、これがDDoS攻撃であることが明らかになりました。

















したがって、上記のアルゴリズムに従ってウェブサイト訪問者用のフィルターを追加し、さらにブラックリストデータベースの着信トラフィックのチェックを含めることで、正当なウェブサイト訪問者に停止ページが発行される可能性を減らすことにしました。







フィルターオン



フィルターの準備にもう少し時間を費やして、19：15-19：20にフィルターをオンにしました。













数分後、最初の肯定的な結果が得られ、最初に負荷平均が通常に戻り、その後ネットワークインターフェイスの負荷が低下しました。 数時間後、攻撃は2回繰り返されましたが、その結果はほとんど感知できず、フロントエンドはエラーなしで機能しました502。







おわりに



その結果、最も単純なJavaScriptコードを使用して、ボットからのトラフィックをフィルタリングする問題を解決し、DDoS攻撃を消滅させ、サイトの可用性を通常の状態に戻しました。







正直なところ、このボットフィルタリングアルゴリズムは、上記の攻撃の日に発明されたものではありません。 数年前、SpamFireWallはAntispamサービスに追加の機能を実装しましたが、SpamFireWallは1万以上のWebサイトを使用しており、別の記事があります。







SpamFireWallは、主にスパムボットと戦うために設計されましたが、スパムボットのリストは疑わしい目的で使用される他のボットのリストと重複するため、SFWの使用はサイトでの小さなDDoS攻撃を阻止するためにも非常に効果的です。







CleanTalkについて



CleanTalkは、 スパムボットからWebサイトを保護するためのクラウドベースのサービスです。 CleanTalkは、Webサイトの訪問者には見えないセキュリティメソッドを使用します。 これにより、ユーザーが自分であることを証明する必要がある保護方法（キャプチャ、質問応答など）を放棄できます。







More articles:


All Articles