DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

必須のNginxセキュリティ：ベストプラクティスとトラブルシューティングFAQ

HTTPS、ファイル露出、プロキシヘッダー、レート制限、ログレビューをカバーする実践的なNginxセキュリティFAQ。

必須のNginxセキュリティ：ベストプラクティスとトラブルシューティングFAQ

必須のNginxセキュリティは、単一の設定や魔法のヘッダーではありません。それは、HTTPS、厳格なファイルアクセス、安全なプロキシ動作、限定的な露出、そして問題が大きくなる前に発見するのに役立つログといった、慎重なデフォルト設定の集合です。

このFAQは、チームがNginxをオンラインにした後、デフォルト設定が出発点に過ぎないことに気づいたときに通常尋ねる質問をカバーしています。

最初に確認すべきNginxセキュリティ設定は何ですか？

偶発的な露出を減らす基本から始めましょう。これらの設定は、高度な攻撃ではなく、一般的なミスから保護します。

まず、バージョントークンを無効にします：

server_tokens off;

これにより、Nginxがエラーページやヘッダーでバージョンを宣伝するのを防ぎます。サーバーが見えなくなるわけではありませんが、不要な詳細を削除します。

次に、ドキュメントルートが正しいことを確認します。よくある間違いは、rootを公開ビルドディレクトリではなくプロジェクトディレクトリに指定することです。これにより、ソースファイル、環境例、またはプライベートアセットが露出する可能性があります。

静的サイトの場合は、次のようにすることをお勧めします：

root /var/www/example.com/public;

ではなく：

root /var/www/example.com;

第三に、アプリケーションが本当に必要としない限り、隠しファイルをブロックします：

location ~ /\.(?!well-known) {
    deny all;
}

これにより、証明書検証で使用される.well-knownパスを許可し、.env、.git、.htpasswdなどのファイルを拒否します。

最後に、アップロード制限を確認します。サイトが大きなアップロードを受け入れない場合は、client_max_body_sizeを控えめに保ちます。これにより、偶発的な大きなリクエストの影響範囲が減少します。

NginxはどのようにHTTPSを処理すべきですか？

HTTPSは、公開ウェブサイトやAPIの通常のパスであるべきです。プレーンHTTPをHTTPSにリダイレクトし、有効な証明書を使用し、時代遅れのプロトコル設定を避けます。

シンプルなリダイレクトサーバーブロックは次のようになります：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

HTTPSサーバーブロックは、証明書ファイルを参照し、最新のTLS設定を含める必要があります。多くのチームは、Certbotやマネージドロードバランサーを使用して証明書を処理します。重要なのは、更新を自動化し監視することです。

セキュリティヘッダーは、ブラウザがより安全な決定を行うのにも役立ちます：

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Content Security Policyには注意してください。強力ですが、テストせずに適用すると、スクリプト、フォント、分析、埋め込みコンテンツが壊れる可能性があります。可能な場合は、レポート専用モードから始めてください。

HTTPSの実践的な手順については、NginxでHTTPSを保護するを参照してください。

リバースプロキシとしてNginxを保護するにはどうすればよいですか？

Nginxがアプリにトラフィックをプロキシする場合、クライアント入力を盲目的に信頼せずに、正しいリクエスト情報を保持する必要があります。

一般的なプロキシヘッダーは次のようになります：

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

これらのヘッダーは、アップストリームアプリケーションが元のリクエストを理解するのに役立ちます。ログ、リダイレクト、レート制限、セキュリティチェックに役立ちます。

Nginxが別の信頼できるプロキシやロードバランサーの背後にある場合は、実際のIP処理を慎重に設定します。既知のプロキシアドレスのみを信頼します：

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

オープンインターネットからのX-Forwarded-Forを信頼しないでください。クライアントはそのヘッダーを偽造できます。リクエストがロードバランサー、CDN、または内部プロキシからの場合にのみ信頼します。

また、アップストリームの実装詳細を隠す必要があります。アプリが不要なフレームワーク固有のヘッダーを返す場合は、プロキシまたはアプリケーションレイヤーで削除します。

レート制限を使用すべきですか？

レート制限は、ログインページ、検索エンドポイント、高価なAPI、攻撃者が安価に悪用できるルートに役立ちます。アプリケーションセキュリティの代わりにはなりませんが、ブルートフォース攻撃やノイズの多いトラフィックを遅くすることができます。

例：

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

これにより、クライアントIPでキー設定された共有メモリゾーンが作成され、ログインパスへのリクエストが制限されます。正確な値はユーザーによって異なります。企業のダッシュボードは、モバイルネットワーク上の公開コンシューマーアプリよりも厳しい制限に通常耐えられます。

レート制限は慎重にテストしてください。サイトがプロキシの背後にあり、実際のクライアントIP処理を設定していない場合、すべてのユーザーが同じアドレスから来ているように見える可能性があります。これにより、正当なトラフィックがブロックされる可能性があります。

なぜまだ不審なリクエストが見られるのですか？

公開Nginxサーバーは、常にバックグラウンドノイズを受け取ります：古い管理パネル、PHPファイル、WordPressパス、露出した環境ファイルのスキャンです。ログにこれらのリクエストが表示されても、必ずしも侵害されたわけではありません。

重要なのは、サーバーがどのように応答するかです。WordPress以外のサイトへの/wp-adminリクエストは、404または403を返すべきです。/.envへのリクエストは、決して秘密を返してはいけません。奇妙なパスのリクエストは、内部管理サービスにプロキシされるべきではありません。

アクセスログで以下を確認してください：

  • 繰り返される401または403応答
  • 1つのIPからの多数のリクエスト
  • 大きなリクエストボディ
  • 隠しファイルのプロービング
  • 異常なユーザーエージェント
  • 499、502、または504応答のスパイク

より広範なトラブルシューティングについては、Nginxの一般的なエラーを参照してください。

セキュリティの助けを求めるタイミング

Nginxが顧客データ、認証、支払いフロー、プライベートAPI、または内部管理ツールを保護する場合、セキュリティエンジニアまたは経験豊富なDevOpsコンサルタントを呼び入れてください。また、侵害が疑われる場合、予期しないファイル露出、または可用性に影響を与える繰り返しの攻撃トラフィックがあった場合にも助けを求めるべきです。

設定がCDN、ロードバランサー、Nginx、サービスメッシュ、アプリケーションフレームワークなど複数のレイヤーにまたがる場合、専門家のレビューは価値があります。安全なNginxファイルでも、他の場所で悪い信頼境界があると弱体化する可能性があります。

不要な露出を排除し、HTTPSを強制し、プロキシヘッダーを慎重に処理し、ログを監視することでNginxを安全にします。より安全になるために巨大な設定は必要ありません。明確なデフォルト、テストされた変更、そしてサーバーが実際に何を提供しているかを確認する習慣が必要です。