Nginxは、トラフィックの多いWebサイトのホスティングに使用される最も広く使用されている無料のオープンソースWebサーバーの1つです。安定性、優れたパフォーマンス、低リソース消費、無駄のない構成でよく知られています。 Nginxを利用した人気のあるサイトには、WordPress.com、GitHub、Netflix、Airbnb、Hulu、Eventbrite、Pinterest、SoundCloudなどがあります。
強力で安定していますが、デフォルトの構成は安全ではなく、Webサーバーを強化し、攻撃や侵害を防ぐために非常に必要なセキュリティを提供するために、追加の調整が必要です。
この記事では、Nginx Webサーバーを強化および保護し、それを最大限に活用するために実行できるいくつかの手順に基づいて説明します。
1)SSL証明書を実装する
Nginx Webサーバーを強化するための予備的かつ重要な手順の1つは、SSL証明書を使用してサーバーを保護することです。 SSL証明書は、Webサーバーとサイトの訪問者のWebブラウザー間のトラフィックを暗号化する暗号化デジタル証明書です。また、サイトで安全なHTTPSプロトコルを使用し、プレーンテキストでトラフィックを送信するHTTPをドロップするように強制します。そうすることで、ユーザー名、パスワード、クレジットカード情報などの機密情報を盗聴して盗もうとするハッカーからの通信が保護され、安全に保たれます。
インストールと構成が簡単で、90日間有効なFree Let’sEncryptSSL証明書を利用できます。インストールしたら、 SSL Labs でドメインをテストすることで、SSL暗号化の強度を確認できます。 。結果を以下に示します。
ご覧のとおり、黄色で強調表示されているプロトコルサポートが弱いため、使用しているドメインのスコアはグレードBです。グレードAに移行するには、まだいくつかの調整が必要です。次のステップでプロトコルサポートを改善する方法を見てみましょう。
2)弱いSSL/TLSプロトコルを無効にする
結果からわかるように、SSLの実装は、必ずしもサイトが完全に保護されていることを意味するわけではありません。 TLS 1.0、TLS 1.1、SSL 3などの非推奨バージョンは脆弱であると見なされ、ハッカーが悪用して最終的にWebサーバーを危険にさらす可能性のある脆弱性を提示します。これらのプロトコルは、POODLE、BEAST、CRIMEなどの脆弱性を抱えている傾向があります。
実際、最も人気があり広く使用されているWebブラウザーは、示されている期限内にTLS1.0およびTLS1.1のサポートの終了を発表しました。
- ブラウザ名日付
- GoogleChrome2020年1月
- MozillaFirefox2020年3月
- Safari /Webkit2020年3月
- MicrosoftEdge2020年6月
この情報が手元にあれば、最新のセキュリティプロトコルに準拠するのが賢明です。この記事の執筆時点では、最新のプロトコルはTLS 1.2であり、TLS1.3は2020年後半に予定されています。
TLS1.2とTLS1.3を実装するために、2つのファイルを編集します。
- /etc/nginx/nginx.conf –これはメインのnginx構成ファイルです
- /etc/nginx/sites-available/example.com(または/ default)
Let's Encrypt SSLを実行している場合は、必ず次のファイルを編集してください
- /etc/nginx/nginx.conf
- /etc/letsencrypt/options-ssl-nginx.conf
弱いSSL/TLSプロトコルを無効にするには、次の手順を使用します
ステップ1)nginx.confファイルを編集します
まず、変更を加える前に、/ etc / nginx/nginx.confファイルのバックアップを作成してください。次に、選択したテキストエディタを使用してファイルを開きます
$ sudo vi /etc/nginx/nginx.conf
次の行を見つけます
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
弱いプロトコルを無効にするには、TLSv1およびTLSv1.1プロトコルを削除し、最後にTLSv1.2およびTLSv1.3を追加するだけです。
ssl_protocols TLSv1.2 TLSv1.3 ; # Dropping SSLv3, ref: POODLE
これは、36行目に次のように表示されます
構成ファイルを保存して終了します。
ステップ2)Nginxサーバーブロックファイルを編集します
廃止されたプロトコルは、それぞれのNginxサーバーブロック構成ファイルに残っている可能性があります。ブロック構成ファイルは、/ etc / nginx /sites-available/ディレクトリに含まれています。
したがって、先に進んでブロック構成ファイルを変更してください
$ sudo vi /etc/nginx/sites-available/example.com OR $ sudo vi /etc/nginx/sites-available/default
前と同じように、スクロールして次の行を見つけます
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ここでも、TLSv1およびTLSv1.1プロトコルを削除し、最後にTLSv1.3を追加します。
注: Let's Encrypt SSLを使用している場合は、SSLファイルを変更します。
$ sudo vi /etc/letsencrypt/options-ssl-nginx.conf
変更を保持するには、NginxWebサーバーを再起動します
$ sudo systemctl restart nginx
次に、SSL Labsテストに進み、ドメインをもう一度テストします。今回は、示されているようにA評価を取得する必要があります。
3)情報開示の防止
サーバーを強化することの一部には、Webサーバーでの情報開示を可能な限り制限することが含まれます。情報は、HTTPヘッダーまたはエラー報告を通じて漏洩する可能性があります。この情報の一部には、実行しているNginxのバージョンが含まれているため、ハッカーに開示したくない場合があります。
デフォルトでは、コマンドを実行するとNginxはHTTPヘッダー情報を表示します:
$ curl -I http://localhost
2行目の出力から、Nginxのバージョンとそれが実行されているオペレーティングシステムが開示されていることがわかります
サーバー:nginx / 1.14.0(Ubuntu)
404エラーページなどのエラーページが次のように表示された場合、バージョンはWebブラウザにも表示されます。
この情報漏えいを回避するには、 nginx.confを編集します ファイルとhttp{セクションの下で、次の行のコメントを解除します
server_tokens off;
変更を保存して終了します。次に、変更を反映するためにWebサーバーを再起動します。
$ sudo systemctl restart nginx
エラーページをリロードして、違いに注意してください。実行中のバージョンとOSNginxは省略されています。
Webサーバーから漏洩している情報の量を確認するもう1つの方法は、サーバー署名サイトにアクセスすることです。 ドメインを確認してください。すべてが順調であれば、次の出力が得られます。
4)不要なHTTPメソッドを削除します
もう1つの適切な方法は、Webサーバーによって実装されない不要なプロトコルを無効にすることです。以下の行は、GET、POST、およびHEADメソッドの実装を許可し、TRACEおよびDELETEを含む他のすべてのメソッドを除外します。サーバーブロックファイルに次の行を追加します。
location / { limit_except GET HEAD POST { deny all; } }
5)弱い暗号スイートを無効にする
SSLの実装に加えて、RC4暗号を含む弱くて安全でない暗号を無効にすることを目標にします。これらは、以前のNginxリリースとの下位互換性を目的としてデフォルトでバンドルされており、悪用される可能性のある潜在的な脆弱性として機能するため、これらを使用する正当な理由はありません。したがって、ssl.confファイルで、暗号を次の暗号スイートに置き換えます。
'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
6)不要なモジュールを削除します
脅威の状況をさらに最小限に抑えるために、デフォルトのサーバー設定から不要なモジュールを削除することをお勧めします。ベストプラクティスでは、無駄のないプロファイルを維持し、Webサーバーからのコンテンツの提供に使用されるモジュールのみを有効にする必要があります。ただし、必要になる可能性のあるモジュールをアンインストールまたは削除しないように注意してください。推奨事項として、無効にするモジュールとWebサーバーに必要なモジュールを決定する前に、QAまたはテスト環境でテストを実行してください。
7)より良いオーバーフローを防ぐ
メモリ管理では、バッファは、あるメモリ位置から別のメモリ位置への転送を開始するときにデータを一時的に収容するストレージ位置です。
データ量がメモリバッファの容量を超えると、バッファオーバーフローが発生します。つまり、バッファオーバーフローは、プログラムが保持または処理できるメモリブロックにさらに多くのデータを書き込むときに発生します。
攻撃者はこの脆弱性を悪用して、システムを危険にさらす可能性のある悪意のあるコードを送信する可能性があります。標準的な方法として、このような問題を軽減するために、Webサーバーにいくつかの調整を加えることをお勧めします。以下のコード行をnginx.confファイルに追加します。
##buffer policy client_body_buffer_size 1K; client_header_buffer_size 1k; client_max_body_size 1k; large_client_header_buffers 2 1k; ##end buffer policy
8)XSS攻撃を防ぐ
XSS(クロスサイトスクリプティング)攻撃は、ハッカーがWebアプリケーションを使用して、悪意のあるコードまたはブラウザ側のスクリプトを信頼できるサイトに挿入する攻撃です。サイトへの訪問者がサイトにアクセスすると、スクリプトがダウンロードされ、Cookieやセッショントークンなどのさまざまなブラウザリソースにアクセスできます。
このようなタイプの攻撃に対する防止策の1つは、ssl.confファイルに以下の行を追加することです。
add_header X-XSS-Protection "1; mode=block";
9)クリックジャッキング攻撃を回避する
クリックジャッキング攻撃を回避するには、次のようにnginx.confファイルのHTTPヘッダーにX-Frame-Optionsを追加します
。add_header X-Frame-Options "SAMEORIGIN";
完了したら、NginxWebサーバーを保存して再起動します。
10)自動化されたユーザーエージェントを拒否する
攻撃者がサイトから情報を取得するために展開する可能性のあるボットやその他の自動スクリプトからサーバーを保護するには、特定のユーザーエージェントを明示的に拒否することが賢明です。これにより、最終的にサービス拒否攻撃がDOSにつながる可能性があります。 nginx.confファイルに次の行を追加します。
if ($http_user_agent ~* LWP::Simple|BBBike|wget) { return 403; }
11)画像のホットリンクを防止する
ホットリンクは、ユーザーが自分のサイトに画像を直接アップロードするのではなく、画像をWebサイトにリンクする方法です。これが発生すると、あなたの画像が彼らのサイトに表示され、これの裏側はあなたが余分な帯域幅を支払うことになるということです。
これを防ぐには、Nginx構成ファイル内でlocationディレクティブを探し、次のスニペットを追加します
# Stop deep linking or hot linking location /images/ { valid_referers none blocked www.example.com example.com; if ($invalid_referer) { return 403; } }
次のように画像の拡張子を指定することもできます:
valid_referers blocked www.example.com example.com; if ($invalid_referer) { rewrite ^/images/uploads.*\.(gif|jpg|jpeg|png)$ http://www.example.com/banned.jpg last }
12)Nginxを最新の状態に保つ
簡単ですよね? Webサーバーを最新の状態に保つことは、サーバーを保護する方法の1つです。 Webサーバーを更新すると、ハッカーがサーバーを危険にさらす可能性のある既存の脆弱性に対処するために必要なパッチが適用されます。
これは、Nginx Webサーバーを強化し、一般的な悪用手法からサーバーを保護するために実行できるいくつかの重要な手段のまとめです。これは、Webサイトのファイルとサイトの訪問者を保護するのにも大いに役立ちます。
また読む :LinuxでNGINXをTCP/UDPロードバランサーとして構成する方法