Cloudflare 04：DDoS 対策 ― 網の大きさで洪水を受け止める

DDoS は「たくさんの機械から、一斉に」

DDoS は Distributed Denial of Service の略で、日本語では分散型サービス妨害と呼びます。

「サービス妨害」は、盗むのではなく止めるのが目的だという意味です。ネットショップが1時間止まれば、その間の売上はゼロになり、「あのサイトはよく落ちる」という評判も残ります。競合への嫌がらせ、身代金の要求、抗議活動など、動機はさまざまです。

「分散型」は、攻撃がたくさんの機械から同時に来るという意味です。攻撃者は、乗っ取ったパソコン、ネットワークカメラ、家庭用ルーター、クラウドのサーバーなどを何万台も束ねて使います。この群れをボットネットと呼びます。

1台から来る攻撃なら、その IP アドレスを拒否すれば終わりです。ところが何万台に分散されると、1つずつ拒否していくのは現実的ではありません。しかも、送り元の IP を偽る攻撃もあります。

だから DDoS には、受け止める側がもっと大きいという形でしか根本的に対抗できません。これが、1台のサーバーではなく、世界規模の網である Cloudflare が役に立つ理由です。

攻撃には2つの層がある：L3/4 と L7

DDoS 攻撃は、どの層を狙うかで大きく2つに分かれます（L は OSI 参照モデルの層＝Layer の意味です）。

L3/4 の攻撃は、とにかく量で押し流します。たとえば「反射・増幅攻撃」では、攻撃者は送り元を被害者の IP に偽って、DNS などのサーバーに小さな問い合わせを大量に送ります。サーバーは大きな返事を被害者に送り返すので、被害者には何倍にも膨らんだ通信が届きます。

L7 の攻撃は、1本1本は普通の HTTP リクエストに見えます。ブラウザと同じようにページを取りに来るので、「量が多い」以外に見分ける手がかりが少なく、止めるのが難しい攻撃です。量が少なくても、データベースを重く使うページを狙えば、サーバーは簡単に疲れ切ります。

Cloudflare は、この両方をそれぞれ別の仕組みで見分けています。

世界中の拠点で、分けて受け止める

Cloudflare の守りの土台は、00号で見たエニーキャストです。同じ IP アドレスを世界中の拠点が同時に名乗っているので、インターネットの小包は、それぞれ送り元にいちばん近い拠点に届きます。

ボットネットは世界中に散らばっています。すると攻撃も、ブラジルのボットはサンパウロの拠点へ、ヨーロッパのボットはロンドンの拠点へ、と自然に分散して届きます。1か所で受け止めるには大きすぎる攻撃でも、網全体で割れば、1つの拠点が受け持つ量はずっと小さくなります。

もう1つ大事なのは、攻撃を見分ける処理が、すべての拠点で動いていることです。攻撃の小包を拠点の中心の設備まで運んでから判定するのではなく、受け取ったその拠点のサーバーで判定し、その場で捨てます。攻撃が集中する場所をつくらない作りです。

さらに、たくさんのサイトを同じ網で守っているので、あるサイトを狙った新しい手口を見つけると、その知識がすぐに他のサイトの守りにも使われます。規模そのものが、守りの材料になっています。

まず、回線を詰まらせる攻撃を落とす

エッジの中で最初に働くのが、ネットワーク層の DDoS ルールです。Cloudflare の管理画面では、「Network-layer DDoS Attack Protection」というマネージドルールセットとして見えます。

マネージドルールセットとは、Cloudflare が作り、Cloudflare が更新し続けるルールの束のことです。利用者はルールを1本も書く必要がありません。

このルールは、エッジに届く小包を常に見張り、SYN フラッドや反射攻撃のようなよく知られた攻撃の形と、量の急な増え方を見つけると、その特徴に当てはまる小包だけを捨てます。人が気づいて対応するのを待たず、多くの場合は数秒以内に自動で止まります。

図で、「攻撃」の札がエッジの下のほうに溜まっているのは、ここで捨てられたことを表しています。一方で、普通のリクエストは止められずにオリジンまで進みます。

利用者から見ると、この層の守りは何も設定しなくても、プロキシを通した瞬間から効いています。逆に言えば、プロキシを通っていない通信は守られません。この点は、あとのページでもう一度出てきます。

次に、HTTP の洪水を見分ける

L7 の攻撃を受け持つのが、HTTP の DDoS ルール（HTTP DDoS Attack Protection のマネージドルールセット）です。これも全プランで最初から有効になっています。

HTTP の攻撃は、1本1本が普通のリクエストに見えるので、「量が多いから止める」だけでは、人気が出て本当にアクセスが増えたときにも止めてしまいます。そこで、このルールは攻撃の群れの特徴を見ます。

同じ特徴を持つリクエストの群れを「指紋」のように見つけ、その群れだけを止めます。だから、同じ時間帯に来ている本物の利用者は、そのまま通ることができます。

誤って普通のアクセスを止めてしまう（誤検知）ときは、管理画面でルールの感度を下げたり、動作を変えたりできます。どこまで細かく変えられるかは、プランによって違います。

量に上限なし・追加料金なし、全プランで

Cloudflare の DDoS 対策でいちばん大きな特徴は、全プランで、量の上限なく（unmetered）提供されていることです。無料プランも例外ではありません。

これは当たり前のことではありません。多くのクラウドや CDN は、使った通信量に応じて料金を請求します。そのため昔は、DDoS を受けると「サイトは守られたが、通信量の請求書が跳ね上がった」ということが起こりえました。攻撃者から見れば、相手を止められなくても、お金を使わせることができたわけです。

Cloudflare は 2017年に「攻撃の大きさで料金を変えない」方針を打ち出し、今もそれを続けています。攻撃を受けたから契約を打ち切られる、ということもありません。

最後の行が大事です。「全部守ってくれる」のではなく、「通ってきたものを守ってくれる」のです。次のページで、その意味を見ます。

オリジンの IP が漏れると、守りを素通りされる

ここまでの守りは、すべてエッジで行われています。エッジは、オリジンの前に立つ門です。攻撃者が門を叩いてくれる限り、網の大きさで受け止められます。

では、攻撃者がオリジンの本当の IP アドレスを知っていたらどうなるでしょうか。攻撃者は、Cloudflare の名前（ドメイン）を使わず、その IP に直接小包を送ればよいのです。小包はエッジを一度も通らずに、オリジンに届きます。図の赤い回り道が、それです。

こうなると、Cloudflare の網がどれだけ大きくても関係ありません。守りの外側から、あなたのサーバー1台の回線に直接洪水が流れ込みます。

Cloudflare を使う意味の半分は、オリジンの IP を隠すことにあります。プロキシを通すと、DNS で example.com を引いた人に返るのは Cloudflare の IP です。オリジンの IP は表に出ません。

ところが、この「隠す」は意外と簡単に破れます。次のページで、よくある漏れ口を見ていきます。

IP はどこから漏れるのか

オリジンの IP が漏れる道は、たいてい Cloudflare の外側にあります。

対策は2つです。1つは、漏れたと思ったら IP を変えること。Cloudflare に移る前から同じ IP を使っているなら、履歴に残っている可能性が高いので、移行と同時に変えるのが安全です。

もう1つは、漏れても入れないようにすることです。こちらが本命で、次のページで見ます。

裏口を閉じる：Cloudflare からしか受けない

IP を隠し通すのは難しいので、本当に頼るべきなのは「知られても入れない」状態です。

いちばん基本の方法は、オリジンのファイアウォールで、Cloudflare の IP 範囲からの接続だけを許可することです。Cloudflare は、自分たちが使う IP の範囲を https://www.cloudflare.com/ips/ で公開しています。Web の入口（443番ポートなど）はこの範囲だけに開き、それ以外は拒否します。クラウドを使っているなら、セキュリティグループなどで同じことができます。

こうすれば、攻撃者が IP を知って直接送ってきても、門前払いになります。ただし、ファイアウォールで捨てる前に回線自体が詰まるほどの量が来た場合は、守りきれないこともあります。そこで、さらに強い方法もあります。

Tunnel を使うと、そもそも外から入る口がなくなるので、IP が漏れても攻撃の宛先になりません。

導入と設定：プロキシを通し、裏口を閉じる

DDoS 対策そのものには、「オンにする」ボタンがありません。プロキシを通した時点で、もう効いています。導入でやることは、その守りに穴を開けないことです。

3のオリジン側の設定は、Ubuntu の ufw なら次のようになります（IPv6 の範囲 ips-v6 も同じように許可します）。

# Cloudflare の IPv4 の範囲からだけ、443番を許可する
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from "$ip" to any port 443 proto tcp
done
# それ以外からの 443番は拒否する
sudo ufw deny 443/tcp

範囲の一覧はまれに変わるので、定期的に取り直します。Cloudflare の側では、ふだんは何もしなくて構いません。調整が必要になるのは、次のような場面です。

I'm Under Attack モードは、すべての訪問者にブラウザで短い確認を通ってもらう非常ボタンです。アプリや API のようにブラウザではない相手も止めてしまうので、ずっとオンにはしません。

料金と制限

基本の DDoS 対策は、全プランで無料・量の上限なしです。上位のプランや製品で増えるのは、主に細かく調整する力と守れる範囲です。

制限というより前提として覚えておきたいのは、守られるのは Cloudflare のプロキシを通る通信だけ、ということです。グレーの雲の行、漏れた IP への直接攻撃、Cloudflare を通さないメールやゲームの通信は、この号の守りの外です。

どの機能がどのプランに含まれるかは、見直されることがあります。この号は 2026年9月時点の情報です。導入のときは、公式の料金ページとドキュメントで最新の内容を確かめてください。

よくある落とし穴

DDoS 対策でつまずくのは、たいてい Cloudflare の設定ではなく、その周りです。

とくに4つ目は見落としがちです。キャッシュが効いているページは、攻撃がエッジで返されてオリジンまで来ません。速くするための設定が、そのまま守りにもなるのです。

もう1つ、「Cloudflare を入れたから安心」と思って、オリジン側のソフトウェアの更新を怠るのも危険です。DDoS 対策は洪水を止めるものであって、脆弱性を突く攻撃を止めるのは WAF（05号）の仕事です。

他の号とのつながり

DDoS 対策は、エッジのいちばん前にいる守りです。ここで洪水を止めたあと、残った「普通に見えるけれど悪いリクエスト」は、後ろにいる別の機能が止めます。

「量で押す攻撃」はこの号、「中身が悪い攻撃」は 05〜08号、と覚えておくと整理しやすくなります。