DDoS対策が実際にどう機能するかを人が知る瞬間は二つある。一つ目は穏やかだ——購入時に「DDoS対策込み」という機能一覧を読み、その一文がすべてをカバーしていると何となく思い込む瞬間。二つ目は朝の三時、サイトがダウンし、グラフの様子がわけもわからず狂っていて、その「込み」だったはずの対策が——正しくも、そして設計通りに——まったく何もしていない瞬間だ。
どちらの瞬間も同じ製品と同じ真実にかかわっている。ホスティングプロバイダーは生のボリュームとして届く攻撃をフィルタリングできる。なぜならそのパケットが通る回線を所有しているのはプロバイダーであって、あなたではないからだ。一方で、通常に見えるリクエストとして届く攻撃はフィルタリングできない。ネットワークの視点からすれば、それは通常に見えるリクエストそのものだからだ。この境界線——ホストが吸収するフラッドと、自分自身で生き延びなければならないフラッドの間の境界線——こそが本ガイド全体の主題である。以下すべては、自分がその境界線のどちら側にいるかを見極め、それぞれの側で何をすべきかについて述べる。
同じ名前を共有する二つの異なる攻撃
「DDoS」は一語でありながら、結果以外にほとんど共通点のない二つの問題を覆っている。それぞれ違う場所で、違う人間が、違う道具を使って止めるものであり、この二つを混同することこそ、対策の労力の大半が間違った層に注ぎ込まれる理由だ。
| ボリューム型——レイヤー3・4 | アプリケーション型——レイヤー7 | |
|---|---|---|
| 届くもの | SYNフラッド、オープンDNS・NTP・memcachedリフレクターを経由したUDP増幅、ACKフラッド、ただのゴミパケット | 通常のHTTPリクエスト：GETフラッド、POSTフラッド、slow-loris、キャッシュを無効化するクエリ文字列 |
| 単位 | ギガビットおよび毎秒数百万パケット | 毎秒リクエスト数——多くの場合わずか数千 |
| 打撃を与えるのに必要な帯域 | 膨大。これは容量の勝負だ | ほぼゼロ。エンドポイントが十分に高コストならノートPC1台でも足りる |
| 止めなければならない場所 | 上流、あなたのプロバイダーによって。パケットがあなたのポートに届いた時点で、被害はすでに発生している | あなたのサーバー上で、あなた自身が、あるいはその手前にあなたが管理するプロキシで |
| ボックス上での見え方 | インターフェースが飽和し、パケットカウンターが異常な値になる。CPUはアイドルのこともある | 帯域はほどほどだが、すべてのワーカーがビジーになり、負荷が上昇し、データベースのキューが伸びていく |
| 誰が直すか | ホストのスクラビングが、自動的に、たいてい数秒以内に | あなたの設定——レート制限、キャッシュ、接続上限 |
最後の二行をもう一度読んでほしい。ここに実務上の要点が詰まっている。インターフェースが飽和しているなら、サーバーに何を打ち込んでも助けにはならない——パケットはすでにポートを消費してしまっており、それを落とせるのは上流のルーターを所有する当事者だけだ。逆にインターフェースは静かなのにサイトが落ちたままなら、話は逆になる。ホストの層では何もおかしくないため、ホストには異常が見えておらず、直すのは完全にあなたの仕事だ。
「DDoS対策込み」が実際に買っているもの
ネットワーク層の対策は本物であり、価値があり、そしてほぼ常に誤解されている。プロバイダーがL3/L4フィルタリングを謳うとき、それが意味しているのは、あなたのアドレス宛のトラフィックをネットワークが監視し、フラッドを検知するとトラフィックをスクラビング用のハードウェアへ迂回させ、悪意のある部分を落として正当に見えるものだけを転送する、ということだ。これはサポートチケットなしに行われ、たいていは一瞬の乱れ以上には気づかれない。
この一文は多くのことを語っているので、何を含み何を含まないのかを分解しておく価値がある。
- 自分一人では生き延びられない攻撃をカバーする。1Gbpsのポートを持つサーバーに対する200Gbpsの増幅フラッドは設定の問題ではない。単なる算数だ。上流でのスクラビングだけが唯一存在する答えである。
- あなたのアプリケーションについては無頓着だ。このフィルタは、どのURLが高コストか、どの訪問者がログイン済みか、検索エンドポイントへのリクエストがロゴ画像へのリクエストの400倍のコストだということを知らない。
- 反応するのはしきい値であって、あなたの苦しみではない。検知はトラフィック量をトリガーにする。しきい値を一度も超えない攻撃は、どれほど徹底的にサイトを落としていようと、一切トリガーされない。
- 極端な場合には一時的にヌルルーティングされることがある。どのネットワークにも上限がある。攻撃が共有インフラを脅かすなら、そのアドレスは一定期間切り離されることがある——これは標準的かつ普遍的な措置であり、事が起きている最中ではなく起きる前に知っておく価値がある。
一行でまとめると。あなたのホストは自らのネットワークを守り、あなたはその恩恵を受ける。だがあなたのアプリケーションは守らないし、守る手段もない。レイヤー7は出し惜しみされたアップセルではなく、プロバイダーがTLSを終端しない限り中身を覗けない層なのであり、オフショアでホスティングする者にとって、それは重大な代償を伴う取引にほかならない。
まず、そもそも攻撃かどうかを見極める
DDoSだと疑われるインシデントのかなりの割合は、実は別の何かがその皮を被っているにすぎず、対処法は互換性がない。何かにレート制限をかける前に、まず2分かけて偽物を除外しておくこと——ここでの誤診は1時間を無駄にし、時には本物のユーザーまで失わせる。
- 人気が出ただけ。大手アグリゲーターに載ったリンクは、レイヤー7フラッドとまったく同じ形のトラフィックを生み出す。違うのはリファラーが本物で、リクエストされているのが人間が見たがるページだという点だけだ。これは原因が幸福な容量の問題であり、レート制限をかけるのは自傷行為に等しい。
- クローラーが行儀を忘れた。強引なスクレイパーやAI学習用ボットは、小規模サーバーを軽々と圧倒しうる。たいていはユーザーエージェントが正体を白状しており、対処は一般的な制限ではなく
robots.txtと的を絞った制限だ。 - 自分で何かを壊した。キャッシュを無効化してしまったデプロイ、暴走したcronジョブ、インデックスを失ったデータベース——どれも「突然の負荷、明白な原因なし」という形で現れる。タイミングが自分が行った変更と一致するなら、その変更を疑うべきだ。
- 自分自身の監視こそがフラッドだった。まれで、間が悪く、そして誰もが認める以上によくある話だ。バックオフなしにリトライするヘルスチェックのループは、本当に見事なリクエストレートを生み出しうる。
見分けるための問いはシンプルだ。そのトラフィックは何かを求めているか?本物の負荷は——たとえ敵意があるように見える本物の負荷であっても——形を持つ。実在するページを叩き、リンクをたどり、アセットを読み込み、もっともらしく分散したネットワークからやってくる。攻撃はたいてい、そこまで律儀にやらない。
サーバー自身から攻撃を読み取る
何が起きているかを分類するのにダッシュボードは要らない。順番に実行する四つのコマンドが、自分がどの層と戦っているのかを1分足らずで教えてくれる——それが分かれば、次にすべきことはすべて決まる。
回線は埋まっているか。インターフェースのカウンターを見る。スループットがポートの上限に張り付いているなら、ボリューム型攻撃の最中であり、やるべきことは設定変更ではなくサポートチケットだ。
vnstat -tr 10——10秒間の平均スループット。飽和状況を最速かつ正直に読み取れる。cat /proc/net/devを1秒間隔で2回——インターフェースごとのパケット数・バイト数の差分を、ツールなしで得られる。
SYNフラッドか。半開状態の接続がSYN-RECVに積み上がる。数個なら正常だが、数千となれば話は別だ。
ss -s——サマリー行。状態別の接続数がひと目で分かる。ss -tn state syn-recv | wc -l——本当に重要な、その具体的な数値。
レイヤー7か。帯域はごく普通なのに何もかもが遅いなら、アクセスログでクライアントごとのリクエスト数を数える。1つのアドレスから数万ヒットが来ているなら素人の仕業であり、10万個のアドレスからそれぞれ3ヒットずつ来ているなら本物だ。
tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30$1を$7に置き換えれば、代わりにリクエストされたパスをランキングできる。1つの高コストなエンドポイントが突出しているなら、標的を見つけたことになり、対処法も半分見つかったことになる。
実際に何が枯渇しているのか。ロードアベレージ単体ではほとんど何も分からない。自分がぶつかった具体的な上限を探すこと——PHP-FPMの子プロセスが全部ビジー、データベース接続が上限に達している、ファイルディスクリプタが枯渇している、あるいはワーカーがディスク待ちでD状態のまま固まっている、など。サイトを落としたのはトラフィックそのものではなくその上限であり、それを引き上げる方が何かをフィルタリングするより速いことが多い。
調べている間、これを頭に置いておくこと。プライバシー重視のサービスを運用しているなら、攻撃の最中こそロギングを強化してそのままにしておきたい誘惑に最も駆られる瞬間だ。必要なら強化してよいが、その後は必ず元に戻し、ログファイルを積極的にローテーションすること。1か月分の詳細な訪問者ログをディスクに残したままのインシデントは、一つの問題をより悪くより長く続く問題と交換しただけだ。この規律については当社のサーバーOpSecガイドで扱っている。
最初の10分間
プレッシャーの下では、人は手近にある最大のレバーに手を伸ばしがちだが、その最大のレバーはたいてい間違っている。以下は被害を抑える順序であり、おおむね最速かつ最も安全なものから並べてある。
- 行動する前に分類する。インターフェースが飽和していればボリューム型、静かなインターフェースでワーカーがビジーならレイヤー7。ここに30秒かけることで、間違った層を1時間かけて直す羽目にならずに済む。
- ボリューム型なら、直ちにチケットを開く。宛先アドレス、開始時刻、インターフェースのカウンターを添えること。そのあとはサーバーに手を出すのをやめる——これは中からは直せない。
- レイヤー7なら、まずキャッシュ。匿名訪問者向けに積極的なフルページキャッシュを有効にすることは、障害を肩をすくめるだけの出来事に変える最速の手段であり、本物のトラフィックに対しても等しく役立つ唯一の対策でもある。
- 次にレート制限をかける。まず狙われているエンドポイント、それから他のすべて。控えめに始めること。自分のユーザーまで巻き添えにする制限は、攻撃の続きを自分の手で行っているようなものだ。
- 疑いようのないものだけをブロックする。それぞれ10万リクエストを送ってくる十数個のアドレス、明らかに偽のユーザーエージェント、自分のユーザーが一人もいない国、など。攻撃を受けている最中に凝ったルールを書きたい衝動は抑えること——来月には覚えていない。
- 必要なら意図的に負荷を切り捨てる。未認証の訪問者には静的な「メンテナンス中」ページを出すことで、ボックスを生かし続け、APIを稼働させ続け、考える時間を稼げる。何を犠牲にするかは自分で決める方が、勝手に決められるよりましだ。
- やったことを書き残す。追加した一時的なルールはすべて、未来の自分にとっての地雷になる。役に立ったルールは恒久化し、残りは翌日には外す。
効くレート制限と、誰もがやってしまう間違い
レイヤー7に対する主要な道具はレート制限であり、nginxは本当に異なる二つの問題を解決する二つのディレクティブでそれをうまくこなす。limit_reqはリクエストの頻度を制限する——クライアントがどれだけの頻度で要求できるか。limit_connは同時接続数を制限する——1クライアントが同時に開いておける接続がいくつか。フラッドを防ぐには前者が要り、ワーカープールを枯渇させるためにほぼアイドル状態の接続を数千も保持するslow-loris攻撃を防ぐには後者が要る。どちらか一方しか導入していなければ、問題の半分にしか対応できていない。
効く制限と、見せかけだけの制限を分ける細部が三つある。
- バーストを使い、
nodelayも使う。本物のブラウザはバースト的だ——1回のページ閲覧が、ほぼ同時に十数件のアセットリクエストを発生させる。余裕のない制限は本物の訪問者を締め付ける一方で、しきい値のすぐ下でペースを合わせる攻撃者はすり抜けてしまう。 - 高コストなエンドポイントは個別に制限する。検索ページ、ログインフォーム、パスワードリセット、データベースに書き込むあらゆるエンドポイントには、静的アセットよりはるかに厳しい予算を割り当てるべきだ。攻撃者は苦労せずこれらを見つけ出す。痛手になるのがまさにそこだからだ。
- 503ではなく429を返す。このステータスコードは、行儀の良いクライアントや検索エンジンに対して、これが失敗ではなくスロットリングであるという合図になる——そしてひどい午後がランキングの問題に発展するのを防いでくれる。
それをすべて静かに無効化してしまう間違い。サーバーの手前に何か——CDN、ロードバランサー、自前のリバースプロキシ——が挟まっていると、すべてのリクエストは訪問者のアドレスではなくその何かのアドレスから届くことになる。すると、クライアント単位のレート制限はインターネット全体を1クライアントとして数えてしまい、まったく発動しないか、あるいはユーザー全員を一度に締め出すかのどちらかになる。制限が意味を持つよりも前に、real-IPの取得元を設定しなければならない（nginxでは、プロキシのアドレス範囲に対するset_real_ip_fromと、プロキシが送るヘッダーに対するreal_ip_header）。これもプロキシ自身のアドレス範囲だけに限定すること——オープンなインターネットからクライアントが提示したヘッダーを信用してしまうと、攻撃者はリクエストごとに新しい身元を偽装でき、あなたが持つすべての制限をまっすぐすり抜けてしまう。
キャッシュは、あなたが導入する中で最も安上がりな対策だ
レート制限は仕事を拒否する。キャッシュは仕事そのものを存在しないことにする。匿名訪問者が見るものである限り、フルページキャッシュは攻撃全体の経済性を変えてしまう——データベースへの往復、テンプレートのレンダリング、PHPワーカーを1つ消費するはずだったリクエストが、マイクロ秒単位のファイル読み込みになる。毎秒400件の動的リクエストで潰れていたのと同じサーバーが、キャッシュされたリクエストなら数万件を涼しい顔でさばく。
本番でこれを有効にする際に重要なことは以下の通りだ。
- キャッシュするのは匿名訪問者向けのものだけ。セッションクッキーがあればバイパスする。ログイン中のあるユーザーのページを別のユーザーに出してしまうのは、直そうとしていた障害よりはるかに深刻な事態だ。
- 意図的にstaleを返す。nginxの
proxy_cache_use_staleをupdating error timeoutとともに使えば、バックエンドが苦しんでいるときに訪問者はエラーの代わりに少し古いページを受け取れる。攻撃の最中、これは「無事に見えるサイト」と「死んでいるように見えるサイト」を分ける違いになる。 - 重複したミスを一つにまとめる。
proxy_cache_lockは、キャッシュされていない同一ページへの1000件の同時リクエストが、1000件ではなく1件のバックエンドリクエストになることを保証する。これがないと、キャッシュを無効化する攻撃はキャッシュをすり抜けてそのままデータベースに全力で着弾する。 - キャッシュを無効化するクエリ文字列を無力化する。定番の手口は
?とランダムな値を付け加え、すべてのリクエストを一意のキーにして永遠にミスさせることだ。アプリケーションが実際には使っていないクエリパラメータを無視するよう、キャッシュキーを正規化しておくこと。
ここには心に留めておく価値のある心地よい非対称性がある。キャッシュに費やす時間はどれも、サイトが最も調子の良い日にもサイトを速くし、運用コストを下げ、成功に耐える力を高めてくれる。何も問題が起きていないときに配当を払ってくれる防御策は、他にはほとんどない。
倒れるかどうかを決める上限値
ほとんどのサーバーはCPUが尽きて死ぬわけではない。誰も意図的に設定した覚えのない見えない上限にぶつかって死ぬ——もう誰も使っていないハードウェアの上でなら理にかなっていた、十年前のデフォルト値だ。攻撃を受けたとき、実際に最初に壊れるのは次のものだ。
- アプリケーションワーカー。PHP-FPMの
pm.max_children、Pythonのワーカー数、Nodeのクラスターサイズ。これがサイトの実質的な同時実行数の上限だ。全部ビジーになると、追加の訪問者はすべてキューに入り、CPUがどれほど暇そうに見えていようとサイトはダウンする。引き上げるのはメモリが許す範囲までにとどめること——スワップが起きるくらいならキューイングの方がましだ。 - acceptキュー。
net.core.somaxconnとlistenのバックログが、acceptを待てる接続数を決める。バックログが小さいと、本来は乗り切れるはずのバーストが接続拒否に変わってしまう。 - SYNクッキー。
net.ipv4.tcp_syncookiesは、決して完了しない接続のために状態を確保することなく、カーネルがSYNフラッドに応答できるようにする。最近のカーネルはデフォルトで有効になっているが、思い込まず確認すること。コストはゼロで、最も一般的なフラッドから身を守れる。 - ファイルディスクリプタ。すべての接続はディスクリプタを1つ消費する。デフォルトの
nofile上限は、さばこうとしている接続数より低いことが多く、その障害の現れ方——他はすべて健全に見えるのにacceptだけが失敗する——は、朝の3時には本当に頭を悩ませる。 - データベース接続。コネクションプールを増やさずにワーカー数だけ増やしても、キューが見えにくい場所に移動するだけだ。この二つの数値は必ず一緒に調整すること。
これらはインシデントの最中ではなく、平穏な日に調整しておくこと。これらを知っておく意味は、サイトが倒れたときに、当て推量ではなくぶつかった上限をその場で名指しできる点にある——そして名指しできる上限は、直せる上限だ。
オリジンの手前に何かを置く
ここまではすべてサーバー上で起きることだった。次に決めるべきは、そもそもサーバー自身がトラフィックを直接受け取るべきかどうかだ。正直な選択肢は三つあり、正解を決めるのは予算よりも、あなたが何をホストしているかの方だ。
| 方式 | 得られるもの | 代償 |
|---|---|---|
| オリジンを直接公開し、固める | シンプルさ、第三者不在、自分の管理下にないTLS終端がないこと | アドレスが公開・恒久的になる。レイヤー7の対応は完全に自分の仕事 |
| 商用CDNまたはスクラビングサービス | 圧倒的な吸収容量、ワンクリックのチャレンジページ、グローバルなキャッシュ | あなたのコンテンツについて意見を持つ苦情処理窓口と、あなたのトラフィックを見ることができる企業。オフショアやDMCAに敏感なプロジェクトにとっては、他をどれほど注意深く構成していても、これが最も弱い環になりうる |
| 自前のフロントノード——nginxを動かす小さなVPSが、ファイアウォールで守られたオリジンへプロキシする | 完全な制御、リクエスト経路に第三者がいないこと、焼き捨てて交換できるアドレス、そして隠されたままの本物のアドレス | それ自体の容量制限と、運用するマシンが1台増えること。異なるネットワークに2、3個のフロントを置けば、落とすのを意味のある程度まで難しくできる |
自前でホストするフロントノードは、通常与えられる以上の注目に値する。特に、大手CDNが必ずしも同情してくれるとは限らない理由でオフショアホスティングを選んだ人にとってはそうだ。そのパターンは地味そのものだ——手前に安価なプロキシノードを置き、オリジンはファイアウォールでそれらのノードからの接続だけを受け付けるようにし、DNSはフロント群を指す。フロントが攻撃されたら、数分で新しいアドレスに交換すればよく、オリジンは何も気づかない。このアーキテクチャの全貌——それでもオリジンアドレスが漏れてしまう六つの経路も含めて——は、当社のオリジンサーバーIPを隠すガイドで扱っている。
隠されたオリジンは、どんなフィルタよりも価値がある
これは率直に述べておく価値がある。通常の優先順位をひっくり返す話だからだ——あなたが利用できる最も安上がりなDDoS対策は、攻撃者が持っていないアドレスである。フィルタリングは、それがすでに失敗したときに行うことにすぎない。
これは聞こえる以上に重要だ。オリジンアドレスは絶えず、しかも静かに漏れ続けるからだ。プロキシを手前に置く前の過去のDNSレコードは、その変更よりも何年も長生きする。アプリケーションから直接送られるメールは、そのアドレスをヘッダーに載せている。生のアドレスに対して発行されたTLS証明書は、Certificate Transparencyログに恒久的に公開される。エラーページ、リダイレクト、あるいは一度もプロキシされたことのないマイナーなサブドメインも、すべて正体を明かしてしまう。かつて公開されていたサーバーの手前にCDNを置いたのであれば、アドレスを変更するまでは、古いアドレスは知られていると考えておくべきだ。
その帰結はファイアウォールルールであり、本ガイド中で最も価値のある一行だ。何かが手前に置かれた時点で、オリジンはフロントのアドレス以外からの80番・443番への接続をすべて拒否すべきである。これがなければ、プロキシは単なる提案にすぎない——本物のアドレスを知った者は誰でもそれを迂回して直接攻撃でき、フロント側で設定したことはすべて見せかけになってしまう。
攻撃を退屈なものにとどめるためのハードウェアとロケーションの選び方
この一部は、攻撃が起きるよりずっと前、プランを選ぶ瞬間にすでに決まっている。スペック表が示唆する以上に重要な性質が三つある。
- 帯域無制限課金。従量課金プランでは、攻撃は障害であるだけでなく請求書でもある。頼んでもいないし断ることもできなかったトラフィックが、それでも割り当てに計上されてしまう。無制限課金の転送量は、金銭的リスクを純粋に技術的なリスクへと変えてくれる。これははるかにましな部類の問題だ。
- ポートが自分専用かどうか。共有型の仮想化ホストでは、攻撃を受けている隣人があなたの性能まで劣化させることがあり、対策の上限も他人と共有することになる。専用ポートを持つ専用ハードウェアは、この両方の影響を取り除く。敵意ある注目を予期するプロジェクトにとって、コア数やRAM以上に、これこそがVPSから一段上へ移行する最も明確な理由だ。
- ネットワークがどこにあるか。実際のトランジット容量を持つ、接続性の良いヨーロッパのネットワークは、ピアリングの乏しいネットワークでは吸収できないフラッドを吸収できる。そして法的な理由で選んだ法域には、ネットワーク上の特性もある。利用可能なロケーションから選ぶ際には、この両方を確認する価値がある。
また、静かにシンプルさを後押しする規模の議論もある。控えめなサーバー上でキャッシュの背後にある静的サイトは、驚くほど落としにくい。同じコンテンツを、キャッシュされない検索エンドポイントを持つ重量級CMSで動かせば、スクリプトを書く気になった一人の人間に壊されうる。動的な部分を減らすこと自体が対策であり、しかも無料だ。プロジェクトが本当に持続的な負荷にさらされているなら、当社の高トラフィック向けホスティングの記事が、同じ問題のサイジング面を扱っている。
やってはいけない五つのこと
ここでの失敗パターンは一覧にできるほど一貫しており、そのどれもが誰かの週末を犠牲にしてきた。
- 自分自身をヌルルーティングしない。自分のアドレスをブラックホール化することは、最も文字通りの意味で攻撃を終わらせる——ユーザーを含め、誰もあなたに到達できなくなる。これはプロバイダーにとっての最終手段であり、自分から進んで行う行動ではない。
- fail2banをDDoS対策だと思わない。少数のアドレスからのブルートフォースには良い道具だ。分散フラッドに対しては、数秒で届くものに数分かけて反応することになり、しかも数千のアドレスをBANするルールは、攻撃そのものよりファイアウォール処理に多くのコストをかけてしまうことがある。
- 身代金を払わない。壊滅的な攻撃をちらつかせる恐喝メールの圧倒的多数は、能力のない人間が同一のメッセージを何千通も送っているだけのものだ。実際にやり遂げられるごく少数は、あなたが払うと証明してしまったがゆえに、また戻ってくる。
- 報復しない。ほぼどこでも違法であることに加えて、送信元は乗っ取られた第三者だ。あなたは被害者を攻撃することになり、しかも紛れもなく自分のものだと分かるアドレスからそれを行うことになる。
- パニックで移行しない。攻撃の最中にホストを移すと、新しいアドレスは数分で公開され、しかも動作する設定が手元にない状態になる。まず安定させ、移行は後で計画的に行うこと——実際に移行するなら、当社のダウンタイムなしの移行ガイドは、まさにその移行が第二のインシデントにならないようにするために存在している。
要約版
理屈をそぎ落とせば、実用モデルは8行に収まる。
- まず分類する。インターフェースが飽和していればボリューム型であり、ホストの領分。静かなインターフェースでワーカーが枯渇していればレイヤー7であり、自分の領分。
- ボリューム型なら、アドレス、タイムスタンプ、カウンターを添えてチケットを出す——そのあとサーバーに触るのをやめる。
- 匿名訪問者向けに積極的にキャッシュし、負荷が高いときはstaleを返し、重複したミスを一つにまとめる。これが打てる中で最もレバレッジの高い変更だ。
- リクエスト頻度と同時接続数の両方でレート制限をかけ、最もコストのかかるエンドポイントほど厳しくし、429を返す。
- 何よりも先にreal-IPの設定を直す。そうでなければ、プロキシの背後にあるクライアント単位の制限はすべて、無意味であるか破滅的であるかのどちらかになる。
- 自分の上限を知っておく——ワーカー、バックログ、ディスクリプタ、データベース接続——そして平穏な日に計画的に引き上げておく。
- オリジンアドレスを秘密にし、フロントノードだけにファイアウォールで限定する。これはどんなフィルタを全部合わせたものより価値がある。
- 帯域無制限課金を選ぶ。頼んでもいないトラフィックが、そのまま請求書になることのないように。
これで無敵になるわけではなく、無敵を売る者は何か別のものを売っている。実際に起きるのは、暇な10代の若者にオフラインへ追いやられる側の集団から抜け出し、本物のリソースと本物の意図を必要とする側の集団へ移ることだ——そしてこれは、圧倒的多数のプロジェクトにとって、安全と区別がつかない。残りは、サーバーを他のあらゆる面でも優れたものにするのと同じ地味な作業だ——初日に固めておくこと、最悪の日に復元できること、そしてあなたのトラフィックを自分自身のビジネスとして扱ってくれる場所で動かすこと。