マシンへの攻撃：私たちの対応とあなたにできること

「攻撃」という言葉は、まったく異なる2つの状況で同じように使われます。チャネルがジャンクトラフィックで溢れかえっている場合と、毎秒数百件のリクエストでアプリケーションがダウンする場合です。この2つは対処法が異なるため、まずどちらに直面しているのかを特定する必要があります。

見分け方

/hosting/vds/m/<id> の「概要」で、過去24時間のプロセッサ、メモリ、トラフィックのグラフを確認してください。トラフィックが正常なのにプロセッサが上限に張り付いている場合は、アプリケーションの負荷であり、ご自身の側で対処する必要があります。

できること

nginxでリクエストをレート制限する：

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

ファイアウォールで接続数を制限する：

ufw limit 22/tcp

より柔軟なルールはnftablesの記事にあります。そこでは新しい接続のレート制限や、TTL付きのブロック済みアドレスリストの管理も行えます。

ログから送信元を特定する：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

アドレスまたはネットワークを一度だけブロックする：

ufw deny from 203.0.113.0/24

fail2banを使えば、ログに基づくブロックを自動化できます。

当社が行うこと

当社のインフラは、ノードに到達する前の段階でジャンクトラフィックをフィルタリングします。つまり、お客様の帯域を消費する前に除去します。これはチャネルに対するボリューム攻撃に有効で、お客様側での設定は不要です。

ノードレベルの保護でできないこと：アプリケーションのロジックを分析することはできません。外部から見て正常に見えるリクエストはお客様のマシンに到達するため、それらに対する防御はお客様自身の設定に限られます。

お客様のマシンが攻撃の送信元になった場合、たとえば侵害されて他者のスパムキャンペーンに加担している場合、利用規約に基づきアクセスが制限されます。侵害の兆候に照らしてマシンを確認してください。

キャッシュと静的ファイル

リクエストの洪水に対して最も効果的な手法は、同じ処理を二度行わないことです：

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

重いページはアプリケーション側でキャッシュしてください。キャッシュから配信されるリクエストのコストは数百倍低くなります。

よくある間違い

• burst を指定せずに limit_req を設定する — ページが20数個のファイルを読み込む一般ユーザーが遮断されてしまいます。
• 分散攻撃の最中にアドレスを1つずつ手作業でブロックする：数千件あるため、追いつけません。
• ICMPを完全にブロックする — パケットサイズのネゴシエーションが壊れます。MTUを参照してください。
• 自身のバグを攻撃と誤認する：コード内のループ、除外し忘れたディレクトリをクロールする検索ボット、終わらないクライアントのリトライ。

制限はあらかじめ、静かな状態のマシンで設定してください。リクエストの洪水の最中には rate と burst の値を調整できません。設定ファイルを手探りで、少しずつ編集することになります。