DDoS攻撃からの保護のためのプロキシ：15分で攻撃を防ぐ方法

```html

DDoS攻撃は、数分であらゆるウェブサービスの機能を麻痺させることができます。攻撃者は、異なるIPアドレスから何千ものリクエストを送信し、サーバーを過負荷にし、実際のユーザーに対してアクセスできなくします。プロキシサーバーは、悪意のあるトラフィックをフィルタリングし、負荷を分散し、サーバーの実際のIPアドレスを隠すことができる効果的な保護手段の一つです。

このガイドでは、DDoSからの保護のためのプロキシの設定方法、使用すべきプロキシの種類、および多層セキュリティシステムの構築方法について説明します。内容は、システム管理者、ウェブサービスの所有者、DevOps専門家を対象としています。

DDoS攻撃の仕組みとプロキシが役立つ理由

DDoS（Distributed Denial of Service）は、サービス拒否攻撃の一種です。攻撃者は、何千もの感染したデバイスからなるボットネットを使用して、同時にあなたのサーバーにリクエストを送信します。目的は、サーバーのリソース（CPU、メモリ、通信回線）を使い果たし、正当なユーザーに対してアクセスできなくすることです。

主なDDoS攻撃の種類:

ボリュメトリック攻撃 — 大量のトラフィックで通信回線を埋め尽くす（DNS増幅、UDPフラッド）
プロトコル攻撃 — ネットワークプロトコルの脆弱性を悪用する（SYNフラッド、Ping of Death）
アプリケーション層攻撃 — ウェブアプリケーションへの正当なリクエストを模倣する（HTTPフラッド、Slowloris）

プロキシサーバーは、以下の方法でDDoSからの保護を助けます:

サーバーの実際のIPアドレスを隠す — 攻撃者はプロキシのIPしか見えず、あなたのメインサーバーは見えません
悪意のあるトラフィックのフィルタリング — プロキシはリクエストを分析し、疑わしいものをブロックします
負荷の分散 — 複数のプロキシサーバーがバックエンドサーバー間でトラフィックを分散します
レート制限 — 一つのIPアドレスからのリクエスト数を制限します
静的コンテンツのキャッシュ — メインサーバーへの負荷を軽減します

プロキシはすべてのDDoSタイプに対する万能薬ではないことを理解することが重要です。強力なボリュメトリック攻撃は、プロキシサーバーへの通信回線を埋め尽くす可能性があります。したがって、プロキシはCDN、クラウドのanti-DDoSサービス（Cloudflare、AWS Shield）、ファイアウォールなどの他の保護手段と組み合わせて使用することが効果的です。

DDoSからの保護のためのプロキシの種類: リバース vs フォワード

DDoSからの保護には、2つの主要なプロキシサーバーの種類が使用されます:

リバースプロキシ

リバースプロキシは、あなたのウェブサーバーの前に配置され、クライアントからのすべての受信リクエストを受け取ります。クライアントは、サーバーの実際のIPアドレスを知らずにプロキシとだけ対話します。これはDDoSからの保護のための主要なツールです。

リバースプロキシの人気のあるソリューション:

Nginx — リバースプロキシ機能を持つ高速で軽量なウェブサーバー
HAProxy — 強力なフィルタリング機能を持つ専門のロードバランサー
Apache mod_proxy — Apache用のモジュールで、Nginxよりも性能が劣ります
Varnish — キャッシュに重点を置いたHTTPアクセラレーター

フォワードプロキシ

フォワードプロキシは、クライアント側での発信リクエストに使用されます。DDoSからの保護の文脈では、使用頻度は低いですが、以下の目的に役立ちます:

外部APIへのアクセス時にサーバーのIPアドレスを隠す
複数のIPアドレスを介して発信トラフィックを分散する
潜在的な攻撃に関する情報を収集する際のブロックを回避する

これらのタスクには、レジデンシャルプロキシが適しています — これらは家庭ユーザーの実際のIPアドレスを持ち、通常のトラフィックのように見えるため、検出とブロックが困難です。

プロキシの種類	DDoSからの保護のための適用	利点
リバースプロキシ (Nginx, HAProxy)	受信トラフィックの受け入れ、フィルタリング、負荷分散	サーバーの実際のIPを隠し、攻撃をフィルタリングし、コンテンツをキャッシュします
レジデンシャルプロキシ	インフラストラクチャの隠蔽、脅威の監視	実際のIP、ブロックが難しい
データセンタープロキシ	追加の保護層、高速処理	高い速度、低コスト

サーバー保護のためのNginxでのリバースプロキシの設定

Nginxは、リバースプロキシを作成するための最も人気のあるツールの一つです。受信リクエストを迅速に処理し、レート制限をサポートし、疑わしいトラフィックをフィルタリングできます。

リバースプロキシの基本設定

Nginxを別のサーバーにインストールし、すべての受信トラフィックを受け取ります。実際のウェブサーバーはプロキシの後ろに隠れており、プロキシからのリクエストのみを受け取ります。

# /etc/nginx/nginx.conf

http {
    # 一つのIPからの接続数の制限
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # リクエスト数の制限（レート制限）
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Slowlorisからの保護のためのタイムアウト
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # 実際のウェブサーバーのIP
        server 192.168.1.100:80;
        # 負荷分散のために複数のサーバーを追加できます
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # リクエストをバックエンドに転送
            proxy_pass http://backend;
            
            # クライアントの元のIPを転送
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # プロキシのタイムアウト
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

疑わしいUser-Agentのブロック

多くのDDoS攻撃は、特有のUser-Agentを持つボットを使用します。これらをブロックするためのルールを追加します:

# 知られているボットのブロック
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # 空のUser-Agent
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

不正な国からのGeoブロック

あなたのサービスが特定の国でのみ機能する場合、GeoIPモジュールを使用して他の地域からのトラフィックをブロックできます:

# GeoIPモジュールのインストール
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # ロシアとウクライナからのトラフィックのみを許可
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

負荷分散とトラフィックフィルタリングのためのHAProxy

HAProxyは、トラフィックフィルタリングのための強力なロードバランサーです。アプリケーションレベルでの攻撃をブロックするための複雑なACL（アクセス制御リスト）をサポートしています。

HAProxyの基本設定

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # ロギング
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # タイムアウト
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # リクエストサイズの制限（POSTフラッドからの保護）
    maxconn 3000

frontend http_front
    bind *:80
    
    # レート制限: 一つのIPからの最大100リクエストを10秒間
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Hostヘッダーなしのリクエストをブロック
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # 疑わしいUser-Agentのブロック
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # バックエンドに転送
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # バックエンドサーバーのリスト
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

ACLを使用したHTTPフラッドからの保護

HTTPフラッドは、攻撃者が多数の正当なHTTPリクエストを送信する攻撃です。HAProxyは、これらを検出するための複雑なルールを作成できます:

frontend http_front
    bind *:80
    
    # 一つのIPからのリクエスト数を追跡
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # 制限を超えた場合にブロック
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # 存在しないパスへのリクエストをブロック（スキャン）
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

信頼されたIPアドレスのホワイトリスト

信頼されたIP（例えば、オフィスのアドレスやパートナー）のホワイトリストを作成し、レート制限を受けないようにします:

frontend http_front
    bind *:80
    
    # 信頼されたIPのホワイトリスト
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # ホワイトリスト以外のIPに対してのみレート制限
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

インフラストラクチャを隠すためのレジデンシャルプロキシの使用

あなたのサーバーの前にリバースプロキシを設置するだけでなく、レジデンシャルプロキシを使用してインフラストラクチャを追加的に保護することができます。これは、以下のような場合に特に重要です:

監視サーバーのIPアドレスを隠す — DDoS攻撃を監視したり、脅威に関する情報を収集したりする場合、レジデンシャルプロキシはあなたの行動を隠すのに役立ちます
インフラストラクチャを開示せずに外部APIにアクセスする — あなたのサーバーはレジデンシャルプロキシを介してリクエストを行うことができ、検出を困難にします
DDoSからの保護をテストする — 異なるIPアドレスから攻撃を模倣して、フィルタの効果を確認します

レジデンシャルプロキシは、実際の家庭ユーザーのIPアドレスを持っているため、通常のトラフィックと区別がつきません。これにより、ブロックが困難になり、geo制限を回避できます。

例: レジデンシャルプロキシを介した脅威の監視

あなたがボットネットの活動を監視したいと仮定しましょう。レジデンシャルプロキシを使用することで、あなたのサーバーのIPアドレスを開示せずに情報を収集できます:

import requests

# レジデンシャルプロキシの設定
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# 潜在的な脅威に関する情報を収集
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # 攻撃パターンを特定するために応答を分析
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"{source}へのアクセス中にエラーが発生しました: {e}")

フィルタリングルール: 攻撃と正当なトラフィックを区別する方法

アプリケーションレベル（L7）でのDDoSからの保護の主な難しさは、悪意のあるトラフィックと正当なトラフィックを区別することです。現代の攻撃は、実際のユーザーの行動を模倣するため、検出が困難です。

DDoS攻撃の兆候

リクエスト数の急増 — 短期間で通常の2〜10倍
同一のUser-Agentからのリクエスト — ボットはしばしば同じUser-Agentを使用します
Refererの欠如 — 他のページからの遷移なしの直接リクエスト
同様のリクエスト — 最小限の変化で同じURLへのリクエスト
JavaScriptの欠如 — ボットはページ上のJSコードを実行しません
ページ上の滞在時間が短い — ボットは応答を受け取った後すぐに接続を閉じます
疑わしいIP範囲 — 一つのサブネットからの大量のリクエスト

多層フィルタリング

効果的な保護は、複数のフィルタリングレベルを使用します:

レベル1: IPの評判

知られているボットネット、プロキシサーバー、VPNのデータベースに基づいてIPアドレスを確認します。悪評のあるIPをブロックします。

レベル2: レート制限

一つのIPからのリクエスト数を制限します。例えば、通常のユーザーには1分あたり50リクエストを超えないようにします。

レベル3: 行動分析

User-Agent、Referer、クッキー、JavaScriptの実行を確認します。これらのパラメータがないリクエストをブロックします。

レベル4: CAPTCHA

疑わしいトラフィックにはCAPTCHAを表示します。ボットはこれを通過できませんが、正当なユーザーは一度だけ通過します。

例: NginxでのJavaScriptチャレンジ

ボットをフィルタリングする簡単な方法は、クッキーの設定のためにJavaScriptの実行を要求することです:

server {
    listen 80;
    server_name example.com;

    # クッキーの存在を確認
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # クッキーがない場合、JSチャレンジを表示
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verification</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>JavaScriptを有効にしてください</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

リアルタイムでのDDoSの監視と対応

DDoSからの効果的な保護には、トラフィックの継続的な監視と異常への迅速な対応が必要です。重要なメトリックを追跡する監視システムを設定します:

1秒あたりのリクエスト数 — 急増は攻撃の兆候かもしれません
ユニークなIPアドレスの数 — DDoSはしばしば多数のIPから発生します
4xx/5xxエラーの割合 — エラーの増加は過負荷の兆候かもしれません
サーバーの応答時間 — レイテンシの増加は問題を示します
リソースの消費 — CPU、メモリ、ネットワークトラフィック

監視ツール

ツール	目的	特徴
Prometheus + Grafana	メトリックの収集と可視化	アラートの柔軟な設定、美しいダッシュボード
ELKスタック（Elasticsearch、Logstash、Kibana）	リアルタイムのログ分析	強力なログ検索、パターンの特定
Netdata	システムリソースの監視	簡単なインストール、リアルタイムメトリック
Fail2ban	IPの自動ブロック	ログを分析し、疑わしいIPをブロックします

Prometheusでのアラート設定

異常を検出した際に自動的に通知するためのルールを作成します:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # リクエスト数の急増時にアラート
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "高いリクエスト率が検出されました"
          description: "リクエスト率は{{ $value }} req/sです"

      # 5xxエラーの増加時にアラート
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "高い5xxエラー率"
          description: "5xxエラー: {{ $value }} req/sです"

      # CPUの高負荷時にアラート
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "高いCPU使用率"
          description: "CPU使用率は{{ $value }}%です"

Fail2banによる自動対応

Fail2banはログを分析し、リクエストの制限を超えたIPアドレスを自動的にブロックします:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

多層保護: プロキシと他の方法の組み合わせ

プロキシサーバーはDDoSからの保護の重要な要素ですが、他の方法と組み合わせることで最も効果的です。多層保護のアーキテクチャを考えてみましょう:

レベル1: ネットワーク保護 (L3/L4)

クラウドのanti-DDoSサービス — Cloudflare、AWS Shield、Google Cloud Armorは、トラフィックがあなたのサーバーに到達する前にフィルタリングします
ハードウェアファイアウォール — ネットワークトラフィックをフィルタリングするための専門機器
BGPブラックホール — プロバイダーのレベルで悪意のあるトラフィックを「ブラックホール」にリダイレクトします

レベル2: CDNとキャッシング

CDN（コンテンツ配信ネットワーク） — 静的コンテンツを多数のサーバーに分散させ、オリジンサーバーへの負荷を軽減します
プロキシでのキャッシング — Varnish、Nginxは人気のあるページをキャッシュし、バックエンドにアクセスせずに提供します
コンテンツの最適化 — CSS/JSのミニファイ、画像の圧縮はトラフィック量を減少させます

レベル3: プロキシと負荷分散 (L7)

リバースプロキシ — Nginx、HAProxyはアプリケーションレベルでリクエストをフィルタリングします
負荷分散 — 複数のバックエンドサーバー間での負荷分散
レート制限 — 一つのIPからのリクエスト数を制限します
WAF（Webアプリケーションファイアウォール） — ModSecurity、AWS WAFはウェブアプリケーションへの攻撃をブロックします

レベル4: バックエンドの最適化

データベースの最適化 — インデックス、リクエストのキャッシング、リードレプリカ
非同期処理 — 重いタスクはバックグラウンドでキューを介して実行されます（RabbitMQ、Redis）
水平スケーリング — 負荷が増加した際に新しいサーバーを追加します

アーキテクチャの例

クライアント
  ↓
Cloudflare（anti-DDoS L3/L4、CDN）
  ↓
Nginxリバースプロキシ（レート制限、フィルタリング）
  ↓
HAProxy（負荷分散）
  ↓
バックエンドサーバー（ウェブアプリケーション）
  ↓
データベース（レプリケーション付き）

このようなアーキテクチャは、ネットワーク、トランスポート、アプリケーションの各レベルで保護を提供します。攻撃が一つのレベルを突破しても、次のレベルがそれを阻止します。

CDNとあなたのサーバーの間にデータセンタープロキシを追加する

場合によっては、データセンタープロキシをCDNとあなたのサーバーの間に中間層として追加することが有効です。これにより、高速な処理が可能になり、追加のトラフィックフィルタリングを実行できます。データセンタープロキシはレジデンシャルやモバイルプロキシよりも安価であり、大量のトラフィックを処理するための経済的な解決策となります。

結論

プロキシサーバーを使用したDDoS攻撃からの保護は、悪意のあるトラフィックをフィルタリングし、サーバーの実際のIPアドレスを隠し、負荷を分散させる効果的な方法です。NginxやHAProxyをベースにしたリバースプロキシは、フィルタリングルールの柔軟な設定、レート制限、疑わしいリクエストのブロックを提供します。

私たちが考察した重要なポイントは次のとおりです:

リバースプロキシ（Nginx、HAProxy） — アプリケーションレベル（L7）での保護のための主要なツール
レート制限とUser-Agent、IP評判によるフィルタリングは、ほとんどの攻撃を排除するのに役立ちます
レジデンシャルプロキシは、監視インフラストラクチャを隠し、脅威に関する情報を収集するのに役立ちます
多層保護（CDN + プロキシ + WAF + バックエンドの最適化）は、最大の耐障害性を提供します
監視と自動対応は、攻撃を迅速に検出し、ブロックするために重要です

DDoS攻撃は常に進化しているため、保護システムは定期的な更新とテストが必要です。負荷テストを実施し、ログを分析し、フィルタリングルールを更新し、新しい攻撃手法に注意を払いましょう。

多層保護システムをプロキシを使用して構築する予定がある場合は、重要なインフラストラクチャを隠すためにレジデンシャルプロキシを検討し、大量のトラフィックを高速で処理するためにデータセンタープロキシを検討することをお勧めします。異なるタイプのプロキシの組み合わせは、安全性、パフォーマンス、コストの最適なバランスを提供します。

```

プロキシを使用してDDoS攻撃からサーバーを保護する方法：15分で設定