Posted inSecurity

Server IPへの不正アクセスを遮断：Authenticated Origin Pullsの設定 (Cloudflare & Nginx)

Security tutorial - IT technology blog
Security tutorial - IT technology blog

5分で完了するクイック導入

CloudflareとNginxをお使いですか？これは、Cloudflareのプロキシを経由しないすべてのリクエストをブロックし、サーバーを「ロック」する最も速い方法です。これにより、Webサーバーへの不正なアクセスを遮断できます。

  1. Cloudflareからルート証明書を取得する： Nginxが検証に使用するCAファイルが必要です。以下のコマンドを実行してください：
sudo mkdir -p /etc/nginx/certs
sudo curl -s https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem -o /etc/nginx/certs/cloudflare.crt
  1. Nginxの設定： ドメインの設定ファイル（通常は /etc/nginx/sites-available/ 内）を開きます。server ブロック（ポート443）に以下の2行の認証設定を追加します：
server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /path/to/your/fullchain.pem;
    ssl_certificate_key /path/to/your/privkey.pem;

    # クライアント認証を有効化
    ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
    ssl_verify_client on;

    location / {
        try_files $uri $uri/ =404;
    }
}
  1. 設定の適用： 構文を確認し、サービスをリロードします。
sudo nginx -t && sudo systemctl restart nginx
  1. ダッシュボードで有効化： Cloudflareダッシュボードにアクセスし、SSL/TLS -> オリジンサーバー を選択。Authenticated Origin Pulls のスイッチを オン にします。

この瞬間から、サーバーのIPへの直接のリクエストは、Nginxによって「400 Bad Request」として即座に拒否されます。

なぜIP制限（ホワイトリスト）だけでは不十分なのか？

多くのシステム管理者は、Firewall（UFW/iptables）を使用してCloudflareの15のIPレンジを制限するだけで安全だと考えています。しかし、脆弱性スキャナーによる調査や巧妙な攻撃を想定すると、現実はそれほど単純ではありません。

攻撃者もCloudflareを使用している場合を想像してみてください。彼らは自分のドメイン（例：attack-site.com）をあなたのサーバーのIPアドレスに向けることができます。もしNginxの default_server 設定が不十分だと、サーバーはそのリクエストをCloudflareからの正当なトラフィックとして処理してしまいます。その結果、Webサイトの全コンテンツが質の低いドメインに「盗用」され、SEOやブランドの信頼性に深刻な影響を及ぼす可能性があります。

Authenticated Origin Pullsは、相互TLS (mTLS) の仕組みによってこの問題を根本的に解決します。ブラウザがサーバーを検証するだけでなく、サーバー側もCloudflareに対して「身分証明書」（クライアント証明書）の提示を要求するようになります。

適切な証明書モードの選択

必要なセキュリティレベルに応じて、次の2つの方法から選択できます：

グローバル証明書（Global Certificate）を使用する

これはデフォルトのオプションです。Cloudflareはすべてのユーザーで共通の証明書を使用します。導入が非常に簡単で、一般的なWebサイトの90%において十分な安全性を提供します。Nginxは server_name とこの証明書を組み合わせてチェックし、偽装されたリクエストを排除します。

カスタム証明書（Custom Certificate）を使用する

金融システムや機密データを扱っている場合は、独自の証明書を作成してください。Cloudflareダッシュボードのオリジンサーバーセクションで Upload Custom Certificate を選択します。これにより、あなた自身のCloudflareアカウントを経由するトラフィックのみが、サーバーへのアクセスを許可されます。

「要塞」のテスト方法

感覚に頼らず、実際のデータで確認しましょう。サーバーのIPに直接 curl を実行して、攻撃をシミュレートしてみます（1.2.3.4を実際のIPに置き換えてください）：

curl -k https://1.2.3.4

サーバーが 400 No required SSL certificate was sent というエラーを返せば、システムは安全です。プロトコルレイヤーで非常に強固なトラフィック分析層を構築できたことになります。

リソースの最適化：ネットワーク層のFirewallを忘れずに

mTLSは非常に安全ですが、Nginxに大量のTLSハンドシェイクエラーを処理させることはリソースの無駄につながります。ハンドシェイクが失敗するたびに、サーバーのCPUと少量のRAMが消費されます。

私のアドバイスは、「門前払い」をすることです。

自動スクリプトを使用して、CloudflareのIPレンジを ufw に同期させましょう。そうすれば、攻撃者はポート443が開いていることすら確認できなくなります（ステータスは Filtered）。IP FirewallとmTLS、さらにIPSを組み合わせることで、完璧な二重のセキュリティレイヤーが形成されます。

重要な注意点

  • ポート80の脆弱性： mTLSはHTTPSでのみ動作します。ポート80を閉じ忘れたり、301リダイレクトを徹底していない場合、攻撃者は依然としてこのポートから侵入できる可能性があります。Cloudflareで Always Use HTTPS を即座に有効にしてください。
  • Certbotとの競合： Let’s Encryptは通常 http-01 チャレンジを使用します。サーバーを完全にロックダウンすると、CertbotはSSL証明書を更新できなくなります。Cloudflare APIを介した dns-01 チャレンジに切り替えることで、更新をバックグラウンドで安全に行うことをお勧めします。
  • ログの監視： ウェブサイトで突然502エラーが発生した場合は、/var/log/nginx/error.log を確認してください。正当なIPから client sent no required SSL certificate というエラーが出ている場合、CloudflareのCA証明書が期限切れになっている可能性があります（通常は非常に長い有効期限ですが、念のため注意が必要です）。

Authenticated Origin Pullsの導入は「コストゼロ」で大きなセキュリティ価値をもたらす投資です。インターネット上の無差別なIPスキャンからサーバーが完全に隠蔽されていることを知れば、より安心して運用できるでしょう。

Share:
Tags: