NGINXの人気は高まり続けています。2017年10月のNetcraftの統計によると、NGINXはApacheにほぼ追いついており、この軽量で超高速なウェブサーバーを利用する人が増えていることを意味します。これは、NGINXの導入環境をセキュリティ保護する必要性がますます高まっていることを意味します。そのためには、多くの可能性が秘められています。
NGINXを初めてお使いになる方は、基盤が安全であることを確認した上でサーバーをデプロイする必要があります。NGINXのセキュリティを強化するための5つの方法を、スキルや決意をあまり試すことなくご紹介します。NGINX管理者なら誰もが知っておくべき、実践すべきヒントをご紹介します。
1. 情報漏洩を防ぐ
ターミナル ウィンドウを開き、次のコマンドを発行します。
curl -I http://SERVER_ADDRESS
おそらく、図 Aに示すようなものが表示されるでしょう。
図A
これらの情報は攻撃を招きかねません。なぜでしょうか？攻撃者はこれらの情報を利用してシステムをハッキングするからです。これを防ぐため、NGINXのリリース情報とホスティングプラットフォーム情報を表示しないように設定します。sudo nano /etc/nginx/nginx.confコマンドで設定ファイルを開きます。以下の行が表示されるまで下にスクロールします。
# server_tokens off;
次のように、# 文字を削除してその行のコメントを解除します。
server_tokens off;
ファイルを保存して終了します。sudo systemctl reload nginxコマンドでNGINXをリロードすると、curl -IコマンドでNGINXのバージョンやホストプラットフォームが表示されなくなります（図B）。
図B
2. PHP設定を非表示にする
PHPでNGINXを使用する場合、NGINXの設定ファイルでPHPの情報を隠すことはできません。代わりに、php.iniファイルを編集する必要があります。sudo nano /etc/php/7.0/fpm/php.iniコマンドを実行し、 expose_phpがoffになっていることを確認してください。設定オプションは359行目あたりにあります。設定を変更したら、ファイルを保存して閉じます。NGINXをリロードすると、PHPの情報が第三者の目に触れないように隠されます。
3. リダイレクトサーバーエラー
次に、デフォルトのサイト対応設定でエラーページを設定する必要があります。401（権限がありません）と403（アクセスできません）のエラーは、自動的に404（見つかりません）のエラーページにリダイレクトされます。401と403のエラーを表示することは、機密情報を漏洩させることに等しいと考える人が多いため、404エラーにリダイレクトすることで、サーバー情報を非表示にするのと同様に、ある程度の難読化によるセキュリティ対策を実現できます。
これを行うには、コマンドsudo nano /etc/nginx/sites-enabled/default を実行します。生成された設定ファイルで、server { セクションまでスクロールダウンし、次の行を追加します。
error_page 401 403 404 /404.html;
ファイルを保存して閉じます。sudo systemctl reload nginxコマンドで NGINX をリロードすると、サーバーは 401 エラーと 403 エラーを 404 エラーにリダイレクトするようになります。
4. 機密ディレクトリを保護する
特定のディレクトリへのアクセスを、特定のアドレス以外からブロックしたいとします。WordPressサイトがあり、ローカルLANアドレス以外からのwp-adminフォルダへのアクセスをブロックしたいとします。また、ローカルLANのIPアドレススキームは192.168.1.0/24とします。これを行うには、コマンドsudo nano /etc/nginx/sites-enabled/default を実行します。server { の場所までスクロールし、 location /ディレクティブの下に以下のコードを追加します。
location /wp-admin {
allow 192.168.1.0/24;
deny all;
}
NGINX をリロードすると、誰かが wp-admin フォルダーにアクセスしようとすると、NGINX がエラー 404 にリダイレクトするように設定していない限り、エラー 403 ページにリダイレクトされます。その場合は、エラー 404 ページにリダイレクトされます。
5. リクエストのレートを制限する
NGINX が受信するリクエストのレートを制限することができます。例えば、/wp-admin セクションへの受信リクエストの受け入れを制限したいとします。これを実現するには、limit_req_zone ディレクトリを使用し、one という名前の共有メモリゾーン（指定されたキーのリクエストを格納する）を設定し、1 分あたり 30 リクエストに制限します。指定されたキーには、binary_remote_addr（クライアント IP アドレス）を使用します。これを行うには、コマンドsudo nano /etc/nginx/sites-enabled/default を実行します。server {セクションの上に次の行を追加します。
limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;
wp-adminセクションを追加したlocationディレクティブまでスクロールダウンします。そのディレクティブ内に、次の行を追加します。
limit_req zone=one;
したがって、wp-admin セクションは次のようになります。
location /wp-admin {
allow 10.10.1.0/24;
deny all;
limit_req zone=one;
}
デフォルトファイルを保存して閉じます。sudo systemctl reload nginx コマンドでNGINXをリロードします。wp-adminセクションでは、1分あたり30件のリクエストしか許可されなくなります。30件目のリクエスト以降、ユーザーには次のエラーが表示されます（図B）。
図B
このようなメカニズムによって保護する必要がある任意のディレクトリにレート制限を設定できます。
NGINXはもう少し安全
おめでとうございます。NGINX インストールのセキュリティが少し向上しました。もちろん、セキュリティをさらに強化する方法は他にもたくさんありますが、まずはここから始めるのが良い基礎となるでしょう。
