Linuxを使用するvds /専用サーバーの所有者向けのDDoS攻撃に対処する方法

実際に実証され、非常に成功していることが実証されているDDoS攻撃に対処するための実証済みの方法を説明する、ウラルWeb開発者会議用に準備された資料で、Habréでのプレゼンスを開始することにしました。 この記事の対象読者は、vdsを持っているか、自由に使うことができるプログラマーです。 この記事は、本格的なリーダーシップのふりをするものではなく、その中の多くのシステム管理者のニュアンスは意図的に省略されています。 httpフラッディングタイプのDDoSのみが、DDoSの最も一般的なタイプであり、顧客にとって最も安価なものであると考えています。



この記事の対象読者は、VDSまたはDedicatedを自由に使用できるプログラマーです。

nginxの束-Apache-fastcgi / wsgi。 ボトルネック

Webアプリケーションの典型的な組織は、リバースプロキシサーバー（nginxなど）、Apache（Webサーバー）、fastcgi / wsgi / ...アプリケーションの3つのレベルで構成されます。 実際には、Apacheがない場合、またはmod_php / mod_pythonを使用する場合、専用アプリケーション（Webサーバーに組み込まれている）がない場合、退化するケースがありますが、スキームの本質は変更されず、そのレベルの数のみが変更されます。



Fcgiサーバーは、着信要求を並行して処理する数十のプロセスを実行できます。 プロセスがメモリに配置されている間、この値は特定の制限までしか増やすことができません。 さらに増加すると、スワッピングが発生します。 DDoS攻撃または高トラフィックの場合、現在のすべてのfcgiプロセスがすでに着信要求の処理でビジーである場合、apgiはfcgiプロセスのいずれかが解放されるか、キューにタイムアウトが発生するまで（この場合は）エラー503が発生します）。



また、Apacheには接続数に制限があり、通常は数百（fcgiよりも1桁大きい）です。 Apacheへのすべての接続が使い果たされた後、リクエストはnginxによってすでにキューに入れられています。

Nginxは、その非同期アーキテクチャにより、非常に控えめなメモリ消費で数千の接続を簡単に保持できるため、通常のDDoS攻撃は、nginxが適切に構成されている場合、nginxが新しい接続を受け入れられないレベルに達しません。

nginxでのトラフィックのフィルタリング。 nginxログの解析

提案する手法は、特定の値（たとえば、現在のサーバー容量で耐えられるサイトエンジンのヒット数に応じて毎分1500など）を使用して、サイトへのリクエストの合計数を制限することに要約されます。 この値を超えるすべてのものは、最初にnginx（limit_req_zone $ host zone = hostreqlimit：20m rate = 1500r / m;）でフィルタリングします。

次に、nginxログを調べて、一定期間（たとえば、5分間に100回以上）一定回数以上除外されたIPアドレスを計算し、ファイアウォール経由でこれらのIPアドレスへのアクセスを拒否します。



同じIPアドレス（limit_req_zone $ binary_remote_addr ...）からの従来の、しばしば推奨される接続制限を使用しないのはなぜですか？ まず、natに座っているプロバイダーのクライアントはこの制限に該当します。 第二に、普遍的なしきい値を確立することは不可能です。なぜなら、ajaxと多数のjs / css / imagesを備えたサイトがあり、原則として1ページをロードするのに数十回のヒットが必要になる可能性があり、そのようなしきい値は各サイトで個別にのみ使用できるからです。 第三に、いわゆる「緩慢な」DDoS攻撃の場合、ボットはこのしきい値をまったく下回らない-多くのボットが存在しますが、それぞれが個別に短時間で少数のリクエストを行うため、何もフィルタリングできません。サイトは機能しません。



この方法を使用するには、nginxがApacheのリバースプロキシとして機能する場合、nginx構成ファイルは次のようになります。

http { limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m; ... server { listen 1.2.3.4; server_name domain.ru www.domain.ru; limit_req zone=hostreqlimit burst=2500 nodelay; location / { proxy_pass http://127.0.0.1:80; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構成は、apacheが127.0.0.1:80のループバックインターフェイス、および外部IPアドレス（1.2.3.4）の80番目のポートと127.0.0.1のポート8080でnginxをリッスンしていることも意味します。



nginxによってフィルタリングされたヒットの後には、nginxのerror.logに次のようなエントリが続きます。

 2012/01/30 17:11:48 [error] 16862#0: *247484 limiting requests, excess: 2500.200 by zone "hostreqlimit", client: 92.255.185.237, server: domain.ru, request: "GET / HTTP/1.1", host: "domain.ru", referrer: "http://www.yahoo.com/"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

error.logからすべてのブロックされたIPアドレスのリストを取得するには、次のようにします。

 cat error.log | awk '/hostreqlimit/ { gsub(", ", " "); print $14}' | sort | uniq -c | sort -n
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、この場合、ヒットカウンターが1分間に1,500回カウントされた後にサイトにアクセスしたすべてのユーザーをブロックするため、ブロックされたすべてがボットであるとは限りません。 ただし、ロックの数に条件付きの線を引くと、ボットを区別できます。 通常、値は5〜15分で数百回選択されます。 たとえば、ボットのリストを5分ごとに補充し、nginxが200回を超えてブロックした人はすべてボットであると見なします。



現在、2つの問題に直面しています。

1. ログから期間「最後の5分間」を選択する方法は？
2. N回以上ブロックされた人だけをソートする方法は？

最初の問題は、tail -c + OFFSETを使用して解決されます。 つまり、error.logを解析した後、現在のサイズをバイト単位で補助ファイルに書き込み（stat -c '％s' error.log>オフセット）、次の分析中にerror.logを最後に表示された位置に巻き戻します（末尾-c + $（cat offset））。 したがって、5分ごとにログの分析を開始し、最後の5分間を参照するログの部分のみを調べます。



2番目の問題は、awkスクリプトを使用して解決されます。 その結果、次のようになります（THRESHOLDはロック数の制限と同じです。その後、対応するIPアドレスは攻撃ボットに属していると見なされます）。

 touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \ tail -c +$(cat offset) error.log | awk -v THRESHOLD=200 '/hostreqlimit/ { gsub(", ", " "); a[$14]++; } \ END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; stat -c '%s' error.log > offset
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この一連のコマンドは、nginxのerror.logが存在するディレクトリで実行されます。つまり、原則として/ var / log / nginxです。 結果のリストをファイアウォールに送信して、ブロックします（詳細は以下を参照）。

禁止するネットワークのリストを作成するのは簡単です

ボットネットには何万台ものコンピューターが含まれることがあり、すべてのボットをキャッチするよりもサブネット全体で不要なIPアドレスを遮断する方が簡単な場合が多いため、DDoSで直面するもう1つのタスクは、潜在的な訪問者ではないユーザーにサイトへのアクセスを制限することです個別に。



最初に役立つのは、 NOCマスターホスト WebサイトのRunetネットワークのリストです。 現在、このリストには約5,000のネットワークがあります。 ほとんどのロシアのサイトはロシアからの訪問者に焦点を当てているため、すべての外国人訪問者、およびすべての外国人ボットを遮断することは論理的な決定のように見えます。 しかし、最近、ますます多くの独立したボットネットがロシアのネットワーク内に登場しているため、この決定は正当化されているものの、攻撃から救われることはほとんどありません。



サイトに確立されたコミュニティ（コア）がある場合、過去3〜4週間のWebサーバーログから定期訪問者のIPアドレスのリストを選択できます。 新しい訪問者は攻撃中にサイトにアクセスできませんが、古いアクティブユーザーは攻撃に気付かないでしょう。 さらに、ボットは通常の訪問者には含まれない可能性が高いため、この方法は原則として、しばらくの間攻撃を阻止できます。



サイトがローカルで重要な場合は、ローカルプロバイダーのネットワークと検索エンジンネットワーク（Yandex）を除くすべてのユーザーをファイアウォールで禁止できます。

iptablesの概要、単純なファイアウォールの例

Linuxでは、ファイアウォールはiptablesで実行されます。 実際、iptablesの本質は、外部から受信またはサーバーから送信されるトラフィックの各パケットに対して、このパケットの運命に影響を与える可能性のある特定のルールセットが適用されるようにすることです。 最も単純なケースでは、ルールは単にパケットを受信する（ACCEPT）か、ドロップする（DROP）必要があることを示しています。 ルールはチェーンに分割されます。 たとえば、サーバーがインターネットから受信したパケットはINPUTチェーンに分類され、チェーン内のルールの最初からの各パケットについて、パケットがルールで説明されている条件に適しているかどうかがチェックされ、一致する場合はこのルールがパケットに適用され、そうでない場合はパケット次のルールに渡されます。 パッケージのルールがいずれも適用されていない場合、デフォルトのポリシーがパッケージに適用されます。



簡単な例として、オフィス（IPアドレス1.2.3.4）からのみサーバーへのssh接続を許可し、他のすべてのユーザーのsshへのアクセスをブロックするファイアウォールルールを作成します。

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP COMMIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの行は、iptables-restore <firewall.txtを使用してテキストファイルに書き込み、ファイアウォールにダウンロードし、ファイアウォールの現在の状態をファイルに保存できます：iptables-save> firewall.txt。



これらのルールは次のように機能します。 最初の行-すでに開いているすべての接続のすべてのトラフィックを許可します（ハンドシェイクが渡されます）。 2行目-IPアドレス1.2.3.4からのトラフィックを許可し、これがオフィスであることをコメントでマークします。 実際、接続を確立するパケット、つまりsynおよびackタイプのパケットのみがここに到達し、他のすべてのパケットは最初の行のみを通過します。 3行目-すべてのユーザーがtcpを介してポート22に接続することを禁止します。 私たちのオフィスを除く全員からssh経由で接続（syn、ack）する試みがここに来ます。



興味深いことに、最初の行は安全に削除できます。 このような回線を使用する利点は、ファイアウォールで既に開いている接続に対して1つのルールのみが機能し、すでに開いている接続内のパケットが受信するパケットの大部分であるということです。つまり、最初にこのような回線を持つファイアウォールは、実際には追加の遅延を導入しませんサーバーのネットワークスタックに。 マイナス-この行はconntrackモジュールをアクティブにし、確立されたすべての接続のテーブルのコピーをメモリに保持します。 より高価なのは、接続テーブルのコピーを保持したり、各パケットに対して複数のファイアウォールルールを処理する必要があるためです。 これは、各サーバーの個々のニュアンスです。 ファイアウォールに含まれるルールが少数の場合、conntrackモジュールがアクティブにならないようにルールを作成する方が正しいと考えています。



iptablesでは、追加のユーザー定義チェーンを作成できます。 ある意味では、プログラミング言語の関数呼び出しの類似物のように見えます。 新しいチェーンの作成は簡単です：iptables -N chain_name。 この方法で作成されたチェーンは、ファイアウォールを異なる論理ブロックに分割するために使用されます。

DDoSに対抗するための推奨ファイアウォール構造

DDoSに対抗するために推奨される構造は、次の論理ブロックで構成されています。

1. すでに確立された接続を介したトラフィックを許可します。
2. 「私たちの」IPアドレスの許可を登録します。
3. ホワイトリストテーブルは例外です。
4. DDoSテーブルは、特定したボットです。
5. friendsテーブルはRunetネットワークであり、パッケージがこのレベルに達した場合にアクセスを許可します。
6. 他のすべてのユーザーは-j DROPです。

iptablesの観点では、次のようになります。

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :ddos - [0:0] :friends - [0:0] :whitelist - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP -A INPUT -j whitelist -A INPUT -j ddos -A INPUT -j friends -A INPUT -j DROP -A whitelist -s 222.222.222.222 -j ACCEPT -A whitelist -s 111.111.111.111 -j ACCEPT -A ddos -s 4.3.2.0/24 -j DROP -A friends -s 91.201.52.0/22 -j ACCEPT COMMIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繰り返しになりますが、2行目の適切性は問題であり、ファイアウォールのフルサイズに応じて、作業の速度を上げたり遅くしたりできます。



friendsテーブルに入力します。

 for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do iptables -A friends -s $net -j ACCEPT; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなファイアウォールの問題は、その一風変わった性質です：Runetの場合のfriendsテーブルには、約5000のルールが含まれます。 多かれ少なかれ平均的なDDoSの場合、DDoSテーブルにはさらに1〜2千件のレコードが含まれます。 ファイアウォール全体は5〜7千行で構成されます。 同時に、外部の送信者から到着するすべてのパケットは、単に破棄する必要がありますが、最後のルールに到達するまで、実際に5〜7千のルールをすべて通過します。-A INPUT -j DROP。 それ自体では、このようなファイアウォールは膨大な量のリソースを使い果たします。

IPSET-巨大なファイアウォールのソリューション

Ipsetは、送信者または受信者のアドレスが異なるパケットをどう処理するかを説明する何千行ものモンステロイドファイアウォールの問題を完全に解決します。 Ipsetは、特別なセット（同じタイプのデータのセット）を管理するためのユーティリティです。このセットでは、いくつかの定義済みデータタイプに対して特別なハッシュテーブルが作成されており、このテーブル内の特定のキーの有無を非常に迅速に確立できます。 ある意味では、これはmemcachedの類似物ですが、はるかに高速であり、特定のデータ型のみを格納できます。 DDoSボットのIPアドレスに関する情報を保存するための新しいデータセットを作成しましょう。

 ipset -N ddos iphash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、最後のパラメーターは作成されるテーブルのタイプを示します。nethashはネットワークのリストに設定され、iphashは個々のIPアドレスに設定されます。 さまざまなテーブルオプションがあり、詳細はman ipsetにあります。 したがって、ホワイトリストと友人はネットハッシュテーブルであり、DDoSはiphashです。

作成したipsetテーブルをファイアウォールで使用するには、1つのルール（ファイアウォールの行）で十分です。次に例を示します。

 -A INPUT -m set --match-set whitelist src -j ACCEPT -A INPUT -m set --match-set ddos src -j DROP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように、新しく作成したテーブルにIPアドレスを追加できます。

 ipset -A ddos 1.2.3.4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ipsetを使用する場合のファイアウォール全体は次のようになります。

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP -A INPUT -m set --match-set whitelist src -j ACCEPT -A INPUT -m set --match-set ddos src -j DROP -A INPUT -m set --match-set friends src -j ACCEPT -A INPUT -j DROP COMMIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

セットの友達を入力します（nethashタイプ）：

 for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do ipset -A friends $net; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前に示したコマンドからset ddos​​を入力します。

 touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \ for ip in $(tail -c +$(cat offset) error.log | awk -v THRESHOLD=300 \ '/hostreqlimit/ { gsub(", ", " "); a[$14]++; } END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; \ stat -c '%s' error.log > offset); do ipset -A ddos $ip; done
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TARPITモジュールを使用します

tarpitと呼ばれるiptablesモジュールは、いわゆる「トラップ」です。 ターピットの原理は次のとおりです。クライアントはハンドシェイク（tcp接続の開始）をインストールするためにsynパケットを送信します。 Tarpitはsyn / ackパケットで応答しますが、すぐに忘れます。 ただし、実際に接続が開かれることはなく、リソースは割り当てられません。 最後のACKパケットがボットから到着すると、ターピットモジュールは、サーバーにデータを送信するためのウィンドウサイズをゼロに設定するパケットを送り返します。 その後、ターピットによってボットの側からこの接続を閉じようとしても無視されます。 クライアント（ボット）は接続が開いていると信じていますが、「スタック」（ウィンドウサイズは0バイト）し、この接続を閉じようとしますが、タイムアウトが期限切れになるまで何もできません。タイムアウトは、設定に応じて約12-24です。分。



次のように、ファイアウォールでターピットを使用できます。

 -A INPUT -p tcp -m set --match-set ddos src -j TARPIT --tarpit -A INPUT -m set --match-set ddos src -j DROP
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

xtables-addonsをビルドする

残念ながら、ipsetおよびtarpitモジュールは、最新のディストリビューションの標準セットから欠落しています。 追加でインストールする必要があります。 多かれ少なかれ最近のDebianおよびUbuntuディストリビューションの場合、これは単純に行われます。

 apt-get install module-assistant xtables-addons-source ma ai xtables-addons
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、システム自体がソフトウェアのビルドに必要なすべてをダウンロードし、すべてを収集してすべてをインストールします。 他のLinuxディストリビューションの場合も同じことを行う必要がありますが、詳細についてはリファレンスマニュアルを参照することをお勧めします。

コアチューニング

原則として、DDoS攻撃との戦いについての話は、OSカーネルのチューニングに関する推奨事項から始まります。 ただし、原則としてリソースが少ない場合（たとえば、メモリが1 GB未満の場合）、カーネルはほとんど何もしないので、カーネルのチューニングは意味がありません。 この場合に有用な最大値は、いわゆるものを含めることです。 syncookies。 syncookiesを有効にすると、サーバーに多数のsynパケットがスローされた場合に、synフラッドなどの攻撃に効果的に対処できます。 syn-packetを受信すると、サーバーは新しい接続を開くためのリソースを割り当てる必要があります。 syn-packetの後に接続セットアップ手順が続かない場合、サーバーはリソースを割り当て、タイムアウトが発生するまで（数分）待機します。 最終的に、syncookieがなく、十分な数のsynパケットがサーバーに送信されると、システムはすべてのリソースを使い切ってハーフオープン接続に関する情報を保存するため、接続を受け入れられなくなります。



説明するカーネルパラメータは、sysctlコマンドを使用して修正されます。

 sysctl [-w] option
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-wオプションは、あるパラメーターに新しい値を書きたいことを意味し、その不在は、このパラメーターの現在の値を読みたいことを意味します。 以下のパラメーターを修正することをお勧めします。

 net.ipv4.tcp_syncookies=1 net.ipv4.ip_local_port_range = 1024 65535 net.core.netdev_max_backlog = 30000 net.ipv4.tcp_max_syn_backlog = 4096 net.core.somaxconn = 4096 net.core.rmem_default = 124928 net.core.rmem_max = 124928 net.core.wmem_max = 124928
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• net.ipv4.tcp_syncookiesパラメーターは、syncookiesメカニズムを有効にします。 net.core.netdev_max_backlogは、カーネルが処理できるよりも速くインターフェイスがパケットを受信する場合、処理キュー内のパケットの最大数を決定します。
• net.ipv4.tcp_max_syn_backlogは、接続クライアントから確認を受信して​​いない記憶された接続要求の最大数を定義します。
• net.core.somaxconnは、接続を待機している開いているソケットの最大数です。
• 最後の行は、tcp接続用のさまざまなバッファーです。

この記事がVDSまたは専用サーバーの所有者に役立つことを願っています。 コメントやコメントを残してください。