BunkerWebでDockerウェブアプリを堅牢化：WAF、Fail2Ban、Let's Encrypt統合ガイド

Table of Contents

ウェブセキュリティの再考：統合アプローチ vs 分散アプローチ

深夜にサーバーがSSHブルートフォース攻撃を受けて以来、私は常に初期セットアップからセキュリティを最優先しています。その経験から学んだのは、セキュリティは後から付け加えるものではなく、システムの土台であるべきだということです。多くの人は、基本的なNginxコンテナから始め、SSLが必要だと気づいてCertbotを追加します。

次にSQLインジェクションが心配になり、ModSecurityをコンパイルしようと試みます。さらにログに数千の404スキャンを見つけると、ホストにFail2Banをインストールし、Dockerボリューム間でログをマッピングしようと苦労します。これでは、あっという間に壊れやすい「積木細工」のような構成になってしまいます。

分散型のアプローチは、専任のSecOpsチームがいれば機能しますが、複数のプロジェクトや中小規模のインフラを管理している身にとっては、メンテナンスの悪夢です。そこで「セキュリティ・ファースト・ゲートウェイ」という概念が登場します。5つの異なるツールをバラバラに管理する代わりに、これらの機能がコアロジックに組み込まれた、単一の堅牢なウェブサーバーを使用します。BunkerWebはNginxをベースに、セキュリティ設定の面倒な部分を自動化する管理レイヤーで包み込んだものです。

なぜBunkerWebなのか？現場から見たメリットとデメリット

私は長年、従来のWAF（Web Application Firewall）の設定に携わってきましたが、それらは高度にカスタマイズ可能である一方、学習曲線が非常に急です。BunkerWebは「ボタン一つでセキュリティ」と「完全な制御」のちょうど良い中間地点に位置しています。

メリット

自動化された堅牢化： HSTS、CSP、X-Frame-OptionsなどのNginxセキュリティヘッダーの適切なデフォルト設定を, 最初から適用します。
ネイティブなDocker統合： 他のコンテナを自動的に検出し、Dockerラベルに基づいてルーティングや保護を構成できます。
統合された設定： WAFルール、Fail2Banのしきい値、Let’s Encryptの設定をすべて環境変数で一括管理できます。
モダンなWAF： シグネチャベースの検出（ModSecurity/Core Rule Set）と振る舞い分析を組み合わせて使用します。

デメリット

リソースのオーバーヘッド： 状態管理用のローカルデータベースやPythonベースのロジックなど、複数のバックグラウンドプロセスを実行するため、最小構成のNginxイメージよりも多くのRAMを消費します。
抽象化による影響： 生のNginx設定ファイルを直接操作するのではなく、BunkerWebレイヤーを介してやり取りするため、トラブルシューティングが時として複雑になることがあります。

推奨セットアップ：Dockerオーケストレーションパターン

BunkerWebをデプロイする方法はいくつかありますが、最も拡張性が高いのはDocker Autoconfメソッドを使用する方法です。このセットアップでは、BunkerWebはDockerソケットへのアクセス権を持つスタンドアロンコンテナとして動作します。新しいアプリケーションコンテナを起動する際、いくつかのラベルを追加するだけで、BunkerWebが自動的にリバースプロキシ設定を生成し、SSL証明書をリクエストし、WAF保護を有効にします。

この「サイドカーレス」なアプローチにより、アプリケーションコンテナをクリーンに保つことができます。アプリ側はSSLやセキュリティヘッダーを意識する必要はありません。アプリはコードの実行に専念し、BunkerWebがネットワークの境界で堅牢な盾として機能します。

ステップバイステップの実装：堅牢なゲートウェイの構築

インフラレベルの設定をアプリケーションコードから分離するために、セキュリティゲートウェイ専用のディレクトリを作成することをお勧めします。

1. 初期のDocker Compose設定

docker-compose.ymlファイルを作成します。ここでは、BunkerWebコアとAutoconfヘルパーの2つのサービスを定義します。ヘルパーは、Dockerソケットを監視して新しいコンテナを検知する役割を担います。

version: "3.8"

services:
  bunkerweb:
    image: bunkerze/bunkerweb:1.5.8
    ports:
      - "80:8080"
      - "443:8443"
    volumes:
      - bw_data:/data
    environment:
      - API_WHITELIST_IP=127.0.0.1/32 172.18.0.0/16
      - HTTP_PORT=8080
      - HTTPS_PORT=8443
      - USE_CLIENT_IP=yes
      - USE_REAL_IP=yes
      - REAL_IP_FROM=172.18.0.0/16
      - REAL_IP_HEADER=X-Forwarded-For

  bw-autoconf:
    image: bunkerze/bunkerweb-autoconf:1.5.8
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - DATABASE_URL=sqlite:////data/db.sqlite3
    volumes:
      - bw_data:/data

volumes:
  bw_data:

私が学んだコツの一つは、API_WHITELIST_IPにDockerネットワークの範囲を必ず含めることです。これにより、autoconfサービスがメインインスタンスと安全に通信できるようになります。

2. コアセキュリティ機能の有効化

BunkerWebは、アプリの動作を妨げないよう、デフォルトでは多くの機能が無効になっています。本番環境向けのセットアップでは、常にWAFとバッドボットブロッカーを有効にしています。これらはbunkerwebサービスのenvironmentセクションに追加できます。

    environment:
      # ... 以前の変数 ...
      - USE_WAF=yes
      - USE_ANTIBOT=yes
      - USE_LIMIT_REQ=yes
      - LIMIT_REQ_RATE=10r/s
      - USE_GZIP=yes
      - SERVER_TOKENS=off

SERVER_TOKENS=offを設定することで、エラーページでNginxのバージョン番号が漏洩するのを防ぎます。これは、攻撃対象領域（アタックサーフェス）を減らすためのシンプルですが不可欠なステップです。

3. 保護されたアプリケーションのデプロイ

では、ウェブアプリケーションをどれほど簡単に追加できるか見てみましょう。シンプルなNode.jsアプリがあるとします。ゲートウェイの設定を変更する必要はありません。代わりに、アプリのdocker-compose.ymlにラベルを追加するだけです。

services:
  my-app:
    image: node:alpine
    # ... アプリの設定 ...
    labels:
      - "bunkerweb.SERVER_NAME=example.com"
      - "bunkerweb.USE_LETS_ENCRYPT=yes"
      - "bunkerweb.USE_REVERSE_PROXY=yes"
      - "bunkerweb.REVERSE_PROXY_URL=/"
      - "bunkerweb.REVERSE_PROXY_HOST=http://my-app:3000"
networks:
  default:
    external:
      name: bunkerweb_network

BunkerWebはこれらのラベルを検出し、Let’s EncryptのDNSまたはHTTPチャレンジを実行して、トラフィックのルーティングを開始します。誰かがexample.comに対してSQLインジェクションを試みた場合、BunkerWebのWAFがNode.jsコンテナに到達する前にそれを遮断します。

デプロイ後：監視とメンテナンス

自動化は素晴らしいものですが、盲信は危険です。WAFが何を検知しているかを確認するために、定期的にログをチェックすることをお勧めします。BunkerWebのログは以下のコマンドで確認できます。

docker compose logs -f bunkerweb

もし正当なトラフィックがブロックされている（誤検知）場合は、WAF_RESOURCES環境変数を使用するか、特定のルールIDをホワイトリストに登録することで、WAFルールを調整できます。私の経験では、デフォルトのCore Rule Set (CRS) はかなり強力なため、WordPressやNextcloudのような複雑なアプリでは、特定のルールを無効にする必要があるかもしれません。

もう一つのヒント：Fail2Banのステータスに注意を払ってください。BunkerWebは禁止されたIPのリストを内部データベースに保持しています。誤って自分自身をロックアウトしてしまった場合は、コンテナ内に入り、bwcliツールを使用してIPの禁止を解除する必要があります。少し手間はかかりますが、寝ている間にボットにサーバーを圧倒されないための小さな代償です。

セキュリティは継続的なプロセスです。BunkerWebがWAFやSSLの重労働をこなしてくれますが、ホストOSのアップデートやDockerイメージのパッチ適用は依然として必要です。しかし、このセットアップにより、少なくとも最も一般的な脆弱性を、単一のメンテナンス可能なソリューションで塞ぐことができます。