【入門編】 DDoS攻撃に対するファイアウォールとクラウド型WAF/DDoS対策サービスの連携 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者さんや、これからセキュリティの勉強を始める開発者さんにとって、「DDoS（ディードエス）攻撃」や「クラウドWAF」といった言葉は、なんだか難しそう壁のように感じられるかもしれませんよね。

でも、安心してください。セキュリティの本質は、私たちの日常生活にある「防犯」の仕組みと全く同じです。
今回は、家を守る防犯対策に例えながら、大量の不正アクセスからシステムを守る「ファイアウォール」と「クラウド型DDoS対策サービス」の連携について、一歩ずつ優しく紐解いていきましょう！

—

1. 家の防犯に例える「DDoS攻撃」と「境界防御」の限界

想像してみてください。あなたが大切なお店（Webサイト）を経営しているとします。
お店の入り口には、頑丈なドアと鍵（ファイアウォール）がついていますよね？通常の泥棒であれば、このドアや鍵がしっかりしていれば侵入を防ぐことができます。

しかし、もしある日突然、何千人もの「一見すると普通のお客さんに見えるサクラ」がお店のドアの前に押し寄せ、一斉に「ドアを開けろ！」「中に入らせろ！」と大声で叫び続けたらどうなるでしょうか？

本当のお客さんが入れなくなる： ドアの前に人が溢れ返り、お店に入ることができません。
お店がパンクする： 店員が対応しきれなくなり、お店全体の営業がストップしてしまいます。

これが、DDoS攻撃（分散型サービス拒否攻撃）の正体です。攻撃者は世界中にある乗っ取ったパソコン（ボットネット）などから、膨大な量のアクセスをあなたのサーバーへ同時に送りつけ、リソースを枯渇させます。

ここで、社内のオンプレミス環境（自社オフィスのサーバーやデータセンター）にあるファイアウォールだけに頼っているとどうなるでしょう？
ファイアウォール自体は優秀ですが、そもそも「お店の入り口の道幅（回線の太さ）」そのものが、押し寄せる何万、何億人もの大群によって埋め尽くされてしまいます。道がふさがれてしまっては、どんなに頑丈なドアも意味がなくなってしまうのです。

—

2. 道路の手前で食い止める！「クラウド型DDoS対策」という名の交通整理

「じゃあ、どうすればいいの？」と思いますよね。
そこで登場するのが、クラウド型のDDoS対策サービスやWAF（Web Application Firewall）です。

これを防犯に例えるなら、「お店のずっと手前の高速道路の料金所や交差点で、警察官が怪しい大群を交通整理・排除してくれる仕組み」だと言えます。

私たちのWebサイトの前に、強靭なクラウドのネットワーク（エッジサーバー）を一枚挟みます。ユーザーからのアクセスは、まずすべてこのクラウドエッジに到着します。

1. トラフィッククリーニング（お掃除機能）：
クラウド側で「これは本物のユーザーかな？それとも攻撃者のサクラかな？」と厳しくチェックします。
2. 悪者をブロック：
攻撃と判定された不正なアクセスは、クラウドの段階でキレイに「お掃除（クリーニング）」され、捨てられます。
3. 本物だけをサーバーへ通す：
安全が確認された本物のお客さんのアクセスだけが、あなたの会社のファイアウォールを通過してサーバーに届きます。

これなら、自社のサーバーやファイアウォールに過剰な負担がかかるのを防ぐことができますよね。

—

3. 具体的な連携設計と設定のイメージ

では、実務の世界ではこの「オンプレミス境界」と「クラウドエッジ」をどのように連携させるのでしょうか？
基本の考え方は、「クラウドを最前線の盾にし、自社のファイアウォールはその背後で最後の砦になる」という役割分担です。

① DNS（ドメインネームシステム）の向き先変更

まず、ユーザーがあなたのサイトにアクセスするときの住所（ドメイン）の向き先を、自社サーバーのIPアドレスではなく、クラウド型DDoS対策サービスのIPアドレスに変更します。

② クラウドWAF・DDoS対策側のルール設定

クラウド側では、不審なリクエストを弾くためのルールを設定します。例えば、特定の国からの異常なアクセスや、短時間に何度もリクエストを送ってくるボットを自動で弾く設定を行います。

以下は、一般的なWebサーバー（Nginxなど）の前段にあるクラウドやリバースプロキシで設定される、レートリミット（回数制限）や不正ヘッダーを検知する概念的な設定ファイルのサンプルです。

# クラウドエッジまたはリバースプロキシでの防御設定のイメージ
http {
    # 1秒間に同じIPアドレスからのアクセスを10回までに制限（DDoSやブルートフォース対策）
    limit_req_zone $binary_remote_addr zone=anti_ddos:10m rate=10r/s;

    server {
        listen 80;
        server_name example.com;

        location / {
            # レートリミットを適用し、超えた場合は503エラーを返す
            limit_req zone=anti_ddos burst=20 nodelay;

            # 疑わしいUser-Agent（攻撃ツール名など）をブロック
            if ($http_user_agent ~* (BadBot|Scanner|AttackerTool)) {
                return 403;
            }

            # 安全と判定された通信のみ、バックエンドの自社サーバーへ転送
            proxy_pass http://internal_origin_server;
            
            # クライアントの本当のIPアドレスをバックエンドに伝えるヘッダー
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

③ 自社ファイアウォール（オンプレミス）の堅牢化

クラウドエッジを導入したからといって、自社のファイアウォールを緩めていいわけではありません。
ここで重要なのが、「クラウドサービスのIPアドレス範囲（CIDR）からの通信以外は、すべて拒否する」というファイアウォールの設定です。

もし攻撃者がクラウドの盾をバイパスして、直接あなたの会社のサーバーのIPアドレスを狙って攻撃してくる（ダイレクトオリジン攻撃）のを防ぐためです。

以下は、Linuxのファイアウォール（iptablesやufw）を用いた設定の考え方です。

# 【重要】クラウドDDoS対策サービスの公式IPアドレスリスト（例として 192.0.2.0/24）からのアクセスのみを許可する
# それ以外の直接の外部からのアクセスはすべて遮断（DROP）します

# 1. 既存のルールをクリア
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. クラウドエッジからの通信のみポート80番と443番を許可
sudo ufw allow from 192.0.2.0/24 to any port 80 proto tcp
sudo ufw allow from 192.0.2.0/24 to any port 443 proto tcp

# 3. ファイアウォールを有効化
sudo ufw enable

このように、クラウド側で大きな波（大規模なDDoSトラフィック）を受け止めてキレイにし、自社のファイアウォールでは「信頼できるクラウドからの道」以外をすべて塞ぐという二段構えの連携こそが、モダンなインフラセキュリティの鉄則となります。

—

4. 新人のIT担当者・開発者へのメッセージ

セキュリティと聞くと、なんだか難解な暗号や、複雑な機器の設定を思い浮かべるかもしれません。
でも、基本にあるのは「誰がお店に入ってきていい人で、誰が危ない人なのか」を見極めるシンプルな仕組みづくりです。

自社のサーバーだけで全部を守ろうとしないこと。
大きな攻撃は、力持ちのクラウドエッジにお任せ（アウトソーシング）すること。
自社のファイアウォールは、信頼できるパートナー（クラウド）からの道だけを通すようにしっかり鍵をかけること。

この役割分担を意識するだけで、インフラ全体の耐久性は劇的に向上します。
一歩ずつ、焦らずに安全なシステム作りを楽しんでいきましょう！