デフォルト設定でも、Nginxは非常に安全で信頼性の高いWebサーバーです。ただし、Nginxをさらに保護する方法はたくさんあります。
この記事では、いくつかの一般的なWebサーバーの強化方法とセキュリティ標準に準拠しながら、オープンソースソフトウェアのみを使用します。つまり、情報漏えいの防止、暗号化の実装、監査の実行、アクセスの制限について説明します。
このチュートリアルを実行する前に、必ず以下を完了してください。
Ubuntu 14.04 [CVM](https://cloud.tencent.com/product/cvm?from=10680)、サーバーをお持ちでない学生は[こちら](https://cloud.tencent.com/product/cvm?from=10680)から購入できますが、個人的には無料のTencent Cloud [Developer Lab](https://cloud.tencent.com/developer/labs/lab/10081?from=10680)を使用して実験することをお勧めします。 [サーバーの購入](https://cloud.tencent.com/product/cvm?from=10680)インストールを学習した後。
NginxWebサーバーをインストールして構成します。
登録されたドメインまたはサブドメインは、CVMのIPを指します。 SSL設定をテストするために必要になります。
ドメイン名をお持ちの場合、Webサイトを保護する最も簡単な方法は、無料の信頼できる証明書を提供する[Tencent Cloud SSL Certificate Service](https://cloud.tencent.com/product/ssl?from=10680)を使用することです。 【TencentCloudSSL証明書インストール操作ガイド】(https://cloud.tencent.com/document/product/400/6814?from=10680)を設定します。
ドメイン名をお持ちでない場合は、最初にここ[ドメイン名の登録](https://dnspod.cloud.tencent.com/)にアクセスすることをお勧めします。この構成をテストまたは個人使用のみに使用する場合は、ドメイン名を購入する代わりに、自己署名証明書を使用できます。自己署名証明書は同じタイプの暗号化を提供しますが、ドメイン名検証のアナウンスはありません。自己署名証明書については、[Apacheの自己署名SSL証明書の作成](https://cloud.tencent.com/developer/article/1165840?from=10680)と[Nginxの自己署名SSL証明書の作成方法](https://cloud.tencent.com/developer/article/1160294?from=10680)の2つの記事を参照してください。
sudo
コマンド権限を持つ非rootユーザー(詳細については、[Linuxシステムで非rootユーザーにsudo権限を追加する](https://cloud.tencent.com/developer/article/1200218?from=10680)を参照してください)
特に明記されていない限り、root権限を必要とするこのチュートリアルのすべてのコマンドは、sudo権限を持つ非rootユーザーとして実行する必要があります。
ソフトウェアを最新バージョンに更新することは、Nginxだけでなくシステム全体を保護するための最初のステップです。
警告:システム上のすべてのパッケージを更新する前に、これがNginx以外のシステムでの実行に問題を引き起こすかどうかを必ず確認してください。非常に多くのパッケージに影響を与える操作を実行する前に、システム全体をバックアップすることをお勧めします。すべてのパッケージを更新した後に問題が発生した場合は、バックアップを復元できます。リポジトリパッケージリストを更新してから、 apt-get
を使用してUbuntuサーバーで管理されている現在インストールされているすべてのパッケージを更新するには、次のコマンドを実行します。
sudo apt-get update && sudo apt-get upgrade
または、UbuntuリポジトリでNginxを最新バージョンにアップグレードすることもできます。これにより、Nginxパッケージと必要な依存関係がアップグレードされます。
sudo apt-get upgrade nginx
Nginx Webサーバーの強化を開始するには、まず、公開する情報を制限する必要があります。 HTTPサーバーヘッダーからアプリケーションエラーレポートまで、すべてのレベルで貴重な情報が漏洩します。
それでは、HTTPヘッダーから始めましょう。デフォルトでは、Nginxはその名前とバージョンをHTTPヘッダーに表示します。この情報 curl
は次のように確認できます。
curl -I http://localhost
出力は次のようになります。
HTTP/1.1200 OK
Server: nginx/1.4.6(Ubuntu)...
ご覧のとおり、上記の出力でNginxのバージョンとオペレーティングシステムの名前を確認できます。これは必ずしも深刻な問題ではありませんが、攻撃者がNginxサーバーに損害を与えるために解決しようとしているパズルの一部です。これが、メインのNginx構成ファイル / etc / nginx / nginx.conf
をnanoで次のように開くことによってこの情報を非表示にする理由です。
sudo nano /etc/nginx/nginx.conf
次に、 http
構成セクションにserver_tokensoff;
行を追加します。
http {
##
# Basic Settings
##
server_tokens off;...
その後、ファイルを保存して終了し、変更を有効にするためにNginxをリロードします。
sudo service nginx reload
ここで、同じcurlコマンドを再試行すると、次のようになります。
curl -I http://localhost
表示される情報は少なくなります。
HTTP/1.1200 OK
Server: nginx
...
上記の出力は、これがNginxサーバーであるという事実のみを開示しています。あなたもそれを削除できるかどうか疑問に思うかもしれません。残念ながら、これには構成オプションがないため、実装は簡単ではありません。代わりに、ソースからNginxを再コンパイルする必要があります。これは価値があります。
「サーバー」のタイトルに加えて、機密情報を含む別のタイトル「X-Powered-By」があります。このヘッダーは通常、PHP、Tomcat、またはNginxの背後にあるサーバー側エンジンのバージョンを示します。 PHPでNginxを実行すると、出力 curl
は次のようになります。
HTTP/1.1200 OK
Server: nginx
...
X-Powered-By: PHP/5.5.9-1ubuntu4.14...
上記の X-Powered-By
ヘッダーは、サーバーがPHPバージョン5.5.9を実行しているUbuntu14であることを示しています。 X-Powered-By
のタイトルからこの情報を隠すことは非常に重要です。 Nginxでこれを行うことはできませんが、バックエンドエンジンで対応するオプションを見つける必要があります。たとえば、PHPの場合、メインの php.ini
構成ファイルで expose_php = Off
オプションを設定する必要があります。デフォルトでは、このオプションは「オン」に設定されています。
次に行うことは、攻撃者が使用できる4xx(クライアント側)エラーページを変更することです。通常、これらは「無許可の401」および「禁止された403」のエラーページです。問題をデバッグしているのでない限り、通常、これらのエラーを通常の訪問者に表示する必要はありません。これらのエラーを理解する必要がある場合でも、Nginxエラーログ( / var / log / nginx / error.log
)で見つけることができます。
これらの2つのエラーページを変更するには、デフォルト値などのサーバーブロックの構成ファイルを開きます。
sudo nano /etc/nginx/sites-enabled/default
メインサーバーの server
構成セクションで次のように指定します。
server {...
error_page 401403404/404.html;...
ファイルへの変更を保存した後、コマンドに対して有効になるようにNginxをリロードしてください。
sudo service nginx reload
上記のヒントは、情報漏えいを防ぐためのアイデアを提供します-不要なWebコンテンツをできるだけ少なく表示します。 Nginxでサービスとデバッグ情報を非表示にするだけでなく、バックエンドエンジン(PHP、Tomcatなど)でサービスとデバッグ情報を非表示にし、もちろんWebアプリケーションで非表示にする必要があります。
NginxでSSLを使用して安全なHTTPSプロトコルを実行することは、機密情報(ユーザーの資格情報、個人データなど)を処理するすべてのサイトにとって必須です。 SSLは、サイトユーザーの場所やインターネット接続に関係なく、ユーザーが使用する情報、ユーザーが送受信する情報を確実に保護する唯一の方法です。
この記事は良いスタートですが、データを効果的に保護することはできません。現在、デフォルトのSSL設定とアルゴリズムは、攻撃者がトラフィックを復号化するのを防ぐのに十分なほど強力ではありません。
そのため、より強力な暗号化アルゴリズムを使用して、NginxのSSL証明書を構成します。これにより、データの保護レベルが高くなり、HTTPSサービスが最高のセキュリティ基準と慣行を満たします。
次のコマンドを使用して、SSL証明書用のディレクトリを作成することから始めましょう。
sudo mkdir /etc/nginx/ssl/
SSLの場合、強力な署名アルゴリズムSHA256を使用した証明書が必要です。テスト目的または非実稼働環境では、自己署名証明書を使用して、SSL警告を無視できます。次のコマンドで作成してみましょう。
sudo openssl req -x509 -nodes -sha256 -days 365-newkey rsa:2048-keyout /etc/nginx/ssl/nginx.key -out /etc/nginx/ssl/nginx.crt
このコマンドは、サイトとビジネスの詳細についていくつかの簡単な質問をします。その後、 / etc / nginx / ssl / nginx.key
ファイルに2048ビットのRSA暗号化キーを作成し、 / etc / nginx / ssl / nginx.crt
ファイルにSHA256証明書を作成します。
次に、より強力な4096ビット長の[DHパラメーター](https://wiki.openssl.org/index.php/Diffie-Hellman_parameters)を生成する必要があります。 CVMによっては、最大30分かかる場合があります。しばらく待つ準備をしてください。次のコマンドを実行します。
sudo openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
これで、サーバーブロックのSSL部分を構成できます。たとえば、デフォルトのサーバーブロックを構成しましょう。 nanoを使用して構成ファイルを編集します。
sudo nano /etc/nginx/sites-enabled/default
このファイルで、以下に示すように、サーバー構成セクションを編集し、 server_name
ディレクティブの後にSSLセクションを追加します。
server {...
server_name localhost;
### SSL Part
listen 443 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
...
上記の手順を使用して指定した手順は次のとおりです。
listen
-HTTPSポートであるポート443でSSLリスナーを有効にします。 ssl_protocols
-現在安全であると見なされているこれらの3つのプロトコルのみを有効にします-TLSv1TLSv1.1TLSv1.2
。 ssl_ciphers
-次の安全なSSL暗号のみを有効にします: EECDH + AESGCM:EDH + AESGCM:AES256 + EECDH:AES256 + EDH
ssl_prefer_server_ciphers
-クライアントがサーバーの暗号設定を尊重していることを確認します。 ssl_dhparam
-以前に生成したカスタムの強力なDHパラメーターを使用します。 ssl_certificate
-自己署名SSL証明書を使用します。別の証明書を使用する場合は、必ず変更してください。 ssl_certificate_key
-以前に生成したSSL秘密鍵を使用します。上記の設定を有効にするには、次のコマンドを使用してnginxをリロードする必要があります。
sudo service nginx reload
新しいSSL構成をテストするには、[SSL Labs](https://www.ssllabs.com/ssltest/analyze.html)が提供するツールなどの外部ツールを使用するのが最適です。そこでは、SSLの信頼できない警告を無視する必要があります。これは自己署名の証明書であるため、当然のことです。このサイトは、登録されたドメイン名を持つサイトのみをテストすることに注意してください。 CVMのIPアドレスのみを使用してSSL接続をテストすることはできません。
全体的な結果は「テスト」と同じように「T」になりますが、基本的にはA(可能な限り最高)であるため、「信頼の問題を無視した場合:A」と表示されます。
後で、SSL警告を削除して、SSLテストを「A」にすることができます。 1つのオプションは、記事[Ubuntu 14.04の使用方法](https://cloud.tencent.com/developer/article/1007173?from=10680)で説明されているように、** ** Let's Encrypt ** **を使用することです。Let'sEncrypt[を使用してNginxを保護する](https://cloud.tencent.com/developer/article/1007173?from=10680)。これは無料で、最大4096のRSAキーサイズを指定でき、自己署名に関する警告を発行しません。それ以外の場合は、任意の商用SSLプロバイダーを選択できます。いずれかを選択するときは、必ずSHA256証明書を選択してください。
パスワード認証は、サイトのコントロールパネル、phpmyadminなど、サイトの機密領域のセキュリティを確保するのに必ずしも十分ではありません。攻撃者は、これらの領域で弱いパスワードやソフトウェアの脆弱性を使用して、不正アクセスを取得することがあります。そのため、正当なユーザーのIPを判別できる場合は、IP制限を追加することを強くお勧めします。
たとえば、WordPressサイトがあり、その管理領域が / wp-admin /
にある場合は、自分のIPまたはすべての管理者のIPへのアクセスを制限する必要があります。これを行うには、対応するサーバーブロックを開きます。Nginxのデフォルトのサーバーブロックは / etc / nginx / sites-enabled / default
です。
sudo nano /etc/nginx/sites-enabled/default
server
構成セクションに追加します。
server {...
location /wp-admin/{
allow 192.168.1.1/24;
allow 10.0.0.1/24;
deny all;}......
必ず上記のIPを 192.168.1.1
と 10.0.0.1
に置き換えてください。同様に、ネットワークマスク( / 24
)を変更して、他のIPやネットワークへのアクセスを許可することもできます。
これらの設定を有効にするには、次のコマンドを使用してNginxをリロードする必要があります。
sudo service nginx reload
これで、 / wp-admin /
で許可されているIPアドレスの範囲外のブラウザーでサイトの特定の部分にアクセスしようとすると、エラーが発生します。このエラーは、403禁止ページになります(前述のように、このエラーを404 not foundに変更した場合を除く)。同時に、次のコマンドを使用すると、エラーログに実際のエラーコードが表示されます。
sudo tail /var/log/nginx/error.log
accessforbidden
エラーはこれを示します:
...2016 /01/0204:16:12[error]4767#0:*13 access forbidden by rule, client: X.X.X.X, server: localhost, request:"GET /wp-admin/ HTTP/1.1", host:"Y.Y.Y.Y"...
複数のセキュリティ方法(エラーページの変更やIPアクセスの制限など)を適用することの組み合わせは、Nginxを強化することの累積的な効果を示しています。例によると、攻撃者と攻撃者が使用する自動ツールには、通常のWordPress管理ページの代わりに404個の見つからないページが表示されます。これは非常に紛らわしく、WordPressを壊すために他の方法を試すことができない場合があります。
自分の意見とは関係なく、セキュリティチェックを実施することをお勧めします。このために、セキュリティ監査ツールを使用してWebの脆弱性をスキャンできます。商用ツールを含む多くのそのようなツールがあり、最初から無料でオープンソースのwapitiを使用できます。 Wapitiには、より高度なツールの機能の一部が欠けている場合がありますが、セキュリティ監査の内容を通知します。
aptを介してUbuntuにwapitiをインストールできます。
sudo apt-get install wapiti
次に、次のコマンドを使用して、wapitiを使用してサイトのスキャンを開始します。
wapiti http://example.org -n 10-b folder
必ず example.org
をあなたのウェブサイトの名前に置き換えてください。コマンドに2つの追加パラメーターを指定しました。最初の -n 10
は、無限のループを防ぐために、同じパターンのURLの数を10に制限します。 2番目のパラメーター -b folder
は、スキャン範囲を指定されたドメインにのみ設定します。
スキャンが完了すると、スキャンを実行したディレクトリで呼び出されたディレクトリに「generated_report」の結果が表示されます。最高の表示効果を得るには、このディレクトリをローカルコンピュータにダウンロードしてから、Webブラウザで index.html
ファイルを開いてください。
レポートには、SQLインジェクション、ブラインドSQLインジェクション、ファイル処理、クロスサイトスクリプト、CRLF、コマンド実行、リソース消費、Htaccessバイパス、バックアップファイル、潜在的に危険なファイルの10の異なるカテゴリに分類された脆弱性が表示されます。
理想的には、レポートは次のようになり、脆弱性は見つかりません。
脆弱性がある場合は、スキャンの対応する部分を展開して、より多くの情報を取得できます。
NginxとWebサイトの最も包括的で徹底的な監査を確実にするために、このようなスキャンを頻繁に実行するためにさまざまなツールを使用するようにしてください。
Nginxのセキュリティに関連するいくつかのトピックは、すでに優れた記事があるため、この記事では取り上げていません。以下に精通してください。
Naxsiは、Nginx用のWebアプリケーションファイアウォールです。悪意のある署名のコンパイルを使用して、既知および未知のWebの脆弱性からユーザーを保護します。
Naxsiは複雑なソフトウェアであり、その調整にはある程度の時間と労力が必要であることを知っておく必要があります。幸い、最も人気のあるWebアプリケーションには、必要に応じてさらにカスタマイズできる既製の構成があります。
Fail2banは、Webセキュリティを新しいレベルに引き上げ、nginxサーバーを積極的に保護できる優れたツールです。これまでのところ、ユーザーが特定の情報を見つけたり、ウェブサイトの一部にアクセスしたりすることを制限してきました。 fail2banを使用すると、攻撃者が悪意のあるアクティビティを実行していることを検出すると、攻撃者をさらにブロックできます。
監視はセキュリティに不可欠です。MonitはNginxに優れたサポートを提供できる優れたツールです。 Webログには、悪意のあるアクティビティの痕跡が表示されるだけでなく、CPU負荷とメモリ使用量のピークも表示されます。
この記事では、5番目のステップであるエラーとキーワードのログを監視することに特に注意してください。そこで、誰かがサイトの機密部分にアクセスしたりアクセスしようとしたりした場合など、セキュリティイベントが送信されたときに送信されるカスタムアラートを設定できます。
ファイアウォールを持つことは、nginxとCVM全体のセキュリティにとって非常に重要です。着信接続を許可するには、必ずhttps(tcp 443)ポートを標準のhttp(tcp 80)ポートに追加してください。
上記の記事は少し古く、Ubuntu専用には書かれていません。ただし、簡単に調整してUbuntu14.04に適用できるはずです。 AIDEまたは他の同様のツールを構成するときは、Webログおよび一時ファイル(Webキャッシュなど)の監視を必ず除外してください。
この記事を読んだ後は、Nginxのセキュリティにもっと自信を持つ必要があります。機能性とセキュリティのバランスをとることを忘れないでください。そうすれば、Web環境が設計どおりに機能し、安全で信頼できるので安心できます。また、Nginxの保護は継続的なタスクであり、定期的な更新、再構成、スキャンなどが必要になることを忘れないでください。
Ubuntuのオープンソース情報チュートリアルの詳細については、[Tencent Cloud + Community](https://cloud.tencent.com/developer?from=10680)にアクセスして詳細をご覧ください。
参照:「Ubuntu14.04でNginxを保護する方法」
Recommended Posts