Nginx 搭載の Linux で ASP.NET Core をホストするHost ASP.NET Core on Linux with Nginx

Sourabh Shirhatti による投稿By Sourabh Shirhatti

このガイドでは、Ubuntu 16.04 サーバーで本稼働対応の ASP.NET Core 環境をセットアップする方法について説明します。This guide explains setting up a production-ready ASP.NET Core environment on an Ubuntu 16.04 server. これらの手順は、Ubuntu のより新しいバージョンで動作する可能性が高いですが、手順はまだ新しいバージョンでテストされていません。These instructions likely work with newer versions of Ubuntu, but the instructions haven't been tested with newer versions.

ASP.NET Core でサポートされている他の Linux ディストリビューションについて詳しくは、「Linux における .NET Core の前提条件」をご覧ください。For information on other Linux distributions supported by ASP.NET Core, see Prerequisites for .NET Core on Linux.

注意

Ubuntu 14.04 の場合、Kestrel プロセスを監視するためのソリューションとして supervisord が推奨されます。For Ubuntu 14.04, supervisord is recommended as a solution for monitoring the Kestrel process. systemd は Ubuntu 14.04 ではご利用いただけません。systemd isn't available on Ubuntu 14.04. Ubuntu 14.04 の手順については、このトピックの前のバージョンを参照してくださいFor Ubuntu 14.04 instructions, see the previous version of this topic.

このガイドでは:This guide:

  • リバース プロキシ サーバーの背後に既存の ASP.NET Core アプリを配置します。Places an existing ASP.NET Core app behind a reverse proxy server.
  • Kestrel Web サーバーに要求を転送するようにリバース プロキシ サーバーを設定します。Sets up the reverse proxy server to forward requests to the Kestrel web server.
  • Web アプリを起動時にデーモンとして実行します。Ensures the web app runs on startup as a daemon.
  • Web アプリの再起動に役立つようにプロセス管理ツールを構成します。Configures a process management tool to help restart the web app.

必須コンポーネントPrerequisites

  1. Ubuntu 16.04 サーバーへのアクセスと sudo 特権が与えられた標準ユーザー アカウント。Access to an Ubuntu 16.04 server with a standard user account with sudo privilege.
  2. サーバーへの .NET Core ランタイムのインストール。Install the .NET Core runtime on the server.
    1. .NET の「All Downloads」 (すべてのダウンロード) ページに移動します。Visit the .NET Core All Downloads page.
    2. プレビューではない最新のランタイムを、Runtime (ランタイム) の一覧から選択します。Select the latest non-preview runtime from the list under Runtime.
    3. サーバーの Ubuntu のバージョンに一致する Ubuntu の説明を選択し、これに従います。Select and follow the instructions for Ubuntu that match the Ubuntu version of the server.
  3. 既存の ASP.NET Core アプリ。An existing ASP.NET Core app.

アプリを介して発行およびコピーするPublish and copy over the app

フレームワークに依存する展開用にアプリを構成します。Configure the app for a framework-dependent deployment.

開発環境から dotnet publish を実行し、サーバー上で実行できるディレクトリ (たとえば、bin/Release/<target_framework_moniker>/publish) にアプリをパッケージします。Run dotnet publish from the development environment to package an app into a directory (for example, bin/Release/<target_framework_moniker>/publish) that can run on the server:

dotnet publish --configuration Release

サーバーで .NET Core ランタイムを管理しない場合、アプリは独立した展開として発行することもできます。The app can also be published as a self-contained deployment if you prefer not to maintain the .NET Core runtime on the server.

組織のワークフローに統合されているツール (SCP や SFTP など) を使用して、サーバーに ASP.NET Core アプリをコピーします。Copy the ASP.NET Core app to the server using a tool that integrates into the organization's workflow (for example, SCP, SFTP). Web アプリは一般的に var ディレクトリの下に配置されます (たとえば、var/aspnetcore/hellomvc)。It's common to locate web apps under the var directory (for example, var/aspnetcore/hellomvc).

注意

運用展開シナリオの場合、継続的インテグレーション ワークフローが、アプリの発行処理とサーバーへの資産のコピーを行います。Under a production deployment scenario, a continuous integration workflow does the work of publishing the app and copying the assets to the server.

アプリをテストします。Test the app:

  1. コマンド ラインから dotnet <app_assembly>.dll アプリを実行します。From the command line, run the app: dotnet <app_assembly>.dll.
  2. ブラウザーで、http://<serveraddress>:<port> に移動し、アプリが Linux のローカルで動作することを検証します。In a browser, navigate to http://<serveraddress>:<port> to verify the app works on Linux locally.

リバース プロキシ サーバーを構成するConfigure a reverse proxy server

リバース プロキシは、動的 Web アプリを提供するための一般的な仕組みです。A reverse proxy is a common setup for serving dynamic web apps. リバース プロキシは HTTP 要求を終了させ、ASP.NET Core アプリに転送します。A reverse proxy terminates the HTTP request and forwards it to the ASP.NET Core app.

注意

リバース プロキシ サーバーの有無に関わらず、いずれの構成も有効で、ASP.NET Core 2.0 またはそれ以降のアプリ用にホスティング構成がサポートされている必要があります。Either configuration—with or without a reverse proxy server—is a valid and supported hosting configuration for ASP.NET Core 2.0 or later apps. 詳細については、「When to use Kestrel with a reverse proxy」 (Kestrel とリバース プロキシを使用するタイミング) を参照してください。For more information, see When to use Kestrel with a reverse proxy.

リバース プロキシ サーバーを利用するUse a reverse proxy server

Kestrel は、ASP.NET Core から動的なコンテンツを提供するのに役立ちます。Kestrel is great for serving dynamic content from ASP.NET Core. ただし、Web サーバーとしての機能は、IIS、Apache、Nginx などのサーバーと比べると制限されます。However, the web serving capabilities aren't as feature rich as servers such as IIS, Apache, or Nginx. リバース プロキシ サーバーは、静的コンテンツ サービス、要求のキャッシュ、要求の圧縮、HTTP サーバーからの SSL 終了などの作業の負荷を軽減します。A reverse proxy server can offload work such as serving static content, caching requests, compressing requests, and SSL termination from the HTTP server. リバース プロキシ サーバーは専用コンピューター上に置かれることもあれば、HTTP サーバーと並んで展開されることもあります。A reverse proxy server may reside on a dedicated machine or may be deployed alongside an HTTP server.

このガイドの目的のために、単一インスタンスの Nginx が使用されます。For the purposes of this guide, a single instance of Nginx is used. HTTP サーバーと並んで、同じサーバー上で実行されます。It runs on the same server, alongside the HTTP server. 要件に応じて、別のセットアップを選択することも可能です。Based on requirements, a different setup may be chosen.

要求はリバース プロキシによって転送されます。そのため、Microsoft.AspNetCore.HttpOverrides パッケージの Forwarded Headers Middleware を使用します。Because requests are forwarded by reverse proxy, use the Forwarded Headers Middleware from the Microsoft.AspNetCore.HttpOverrides package. リダイレクト URI とその他のセキュリティ ポリシーを正しく機能させるために、このミドルウェアは、X-Forwarded-Proto ヘッダーを利用して、Request.Scheme を更新します。The middleware updates the Request.Scheme, using the X-Forwarded-Proto header, so that redirect URIs and other security policies work correctly.

認証、リンクの生成、リダイレクト、および地理的位置情報など、スキームに依存するすべてのコンポーネントは、Forwarded Headers Middleware の呼び出し後に配置する必要があります。Any component that depends on the scheme, such as authentication, link generation, redirects, and geolocation, must be placed after invoking the Forwarded Headers Middleware. 一般的な規則として、Forwarded Headers Middleware は、診断およびエラー処理ミドルウェアを除くその他のミドルウェアより前に実行される必要があります。As a general rule, Forwarded Headers Middleware should run before other middleware except diagnostics and error handling middleware. この順序により、転送されるヘッダー情報に依存するミドルウェアが処理にヘッダー値を使用できます。This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing.

UseAuthentication や同様の認証スキームのミドルウェアを呼び出す前に、Startup.ConfigureUseForwardedHeaders メソッドを呼び出します。Invoke the UseForwardedHeaders method in Startup.Configure before calling UseAuthentication or similar authentication scheme middleware. ミドルウェアを構成して、X-Forwarded-For および X-Forwarded-Proto ヘッダーを転送します。Configure the middleware to forward the X-Forwarded-For and X-Forwarded-Proto headers:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

ミドルウェアに対して ForwardedHeadersOptions が指定されていない場合、転送される既定のヘッダーは None です。If no ForwardedHeadersOptions are specified to the middleware, the default headers to forward are None.

プロキシ サーバーとロード バランサーの背後でホストされているアプリでは、追加の構成が必要になる場合があります。Additional configuration might be required for apps hosted behind proxy servers and load balancers. 詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

Nginx をインストールするInstall Nginx

apt-get を利用し、Nginx をインストールします。Use apt-get to install Nginx. インストーラーにより systemd init スクリプトが作成されます。このスクリプトがシステム起動時に Nginx をデーモンとして実行します。The installer creates a systemd init script that runs Nginx as daemon on system startup.

sudo -s
nginx=stable # use nginx=development for latest development version
add-apt-repository ppa:nginx/$nginx
apt-get update
apt-get install nginx

Ubuntu パーソナル パッケージ アーカイブ (PPA) は、ボランティアによって管理されており、nginx.org が配布しているものではありません。詳細については、「Nginx: Binary Releases: Official Debian/Ubuntu packages」 (Nginx: バイナリ リリース: 公式 Debian/Ubuntu パッケージ) を参照してください。The Ubuntu Personal Package Archive (PPA) is maintained by volunteers and isn't distributed by nginx.org. For more information, see Nginx: Binary Releases: Official Debian/Ubuntu packages.

注意

オプションの Nginx モジュールが必要な場合、Nginx をソースからビルドする必要がある場合があります。If optional Nginx modules are required, building Nginx from source might be required.

Nginx は初めてのインストールとなるので、次を実行して明示的に起動します。Since Nginx was installed for the first time, explicitly start it by running:

sudo service nginx start

ブラウザーで Nginx の既定のランディング ページが表示されることを確認します。Verify a browser displays the default landing page for Nginx. ランディング ページは http://<server_IP_address>/index.nginx-debian.html からアクセスできます。The landing page is reachable at http://<server_IP_address>/index.nginx-debian.html.

Nginx を構成するConfigure Nginx

Nginx をリバース プロキシとして構成し、ASP.NET Core アプリに要求を転送するには、/etc/nginx/sites-available/default を変更します。To configure Nginx as a reverse proxy to forward requests to your ASP.NET Core app, modify /etc/nginx/sites-available/default. テキスト エディターで開き、中身を次のものに変更します。Open it in a text editor, and replace the contents with the following:

server {
    listen        80;
    server_name   example.com *.example.com;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

server_name が一致しない場合、Nginx では既定のサーバーが使用されます。When no server_name matches, Nginx uses the default server. 既定のサーバーが定義されていない場合、構成ファイルの最初のサーバーが既定のサーバーとなります。If no default server is defined, the first server in the configuration file is the default server. ベスト プラクティスとして、構成ファイルで 444 の状態コードを返す既定のサーバーを具体的に追加します。As a best practice, add a specific default server which returns a status code of 444 in your configuration file. 既定のサーバーの構成例は次のとおりです。A default server configuration example is:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

上記の構成ファイルと既定のサーバーでは、Nginx は、ホスト ヘッダー example.com または *.example.com で、ポート 80 でパブリック トラフィックを受け入れます。With the preceding configuration file and default server, Nginx accepts public traffic on port 80 with host header example.com or *.example.com. これらのホストと一致しない要求は、Kestrel に転送されません。Requests not matching these hosts won't get forwarded to Kestrel. Nginx は一致する要求を Kestrel (http://localhost:5000) に転送します。Nginx forwards the matching requests to Kestrel at http://localhost:5000. 詳細については、「How nginx processes a request」(Nginx が要求を処理する方法) をご覧ください。See How nginx processes a request for more information. Kestrel の IP/ポートを変更する場合は、Kestrel のエンドポイントの構成に関するセクションを参照してください。To change Kestrel's IP/port, see Kestrel: Endpoint configuration.

警告

適切な server_name directive を指定しないと、アプリにセキュリティ上の脆弱性が生じます。Failure to specify a proper server_name directive exposes your app to security vulnerabilities. 親ドメイン全体を制御する場合、サブドメイン ワイルドカード バインド (たとえば、*.example.com) にこのセキュリティ リスクはありません (脆弱である *.com とは対照的)。Subdomain wildcard binding (for example, *.example.com) doesn't pose this security risk if you control the entire parent domain (as opposed to *.com, which is vulnerable). 詳細については、rfc7230 セクション-5.4 を参照してください。See rfc7230 section-5.4 for more information.

Nginx の構成を確立したら、sudo nginx -t を実行して構成ファイルの構文を確認します。Once the Nginx configuration is established, run sudo nginx -t to verify the syntax of the configuration files. 構成ファイルがテストに合格したら、sudo nginx -s reload を実行することで、強制的に Nginx に変更を反映させます。If the configuration file test is successful, force Nginx to pick up the changes by running sudo nginx -s reload.

アプリをサーバーで直接実行するには、次を実行します。To directly run the app on the server:

  1. アプリのディレクトリに移動します。Navigate to the app's directory.
  2. アプリの実行可能ファイルである ./<app_executable> を実行します。Run the app's executable: ./<app_executable>.

アクセス許可エラーが発生した場合は、アクセス許可を変更します。If a permissions error occurs, change the permissions:

chmod u+x <app_executable>

アプリがサーバーで実行されているにも関わらず、インターネット上で応答がない場合、サーバーのファイアウォールを確認し、ポート 80 が開かれていることを確認します。If the app runs on the server but fails to respond over the Internet, check the server's firewall and confirm that port 80 is open. Azure Ubuntu VM を使用している場合、受信ポート 80 のトラフィックを有効にするネットワーク セキュリティ グループ (NSG) 規則を追加します。If using an Azure Ubuntu VM, add a Network Security Group (NSG) rule that enables inbound port 80 traffic. 送信トラフィックは、受信規則が有効になると自動的に生成されるので、送信ポート 80 規則を有効にする必要はありません。There's no need to enable an outbound port 80 rule, as the outbound traffic is automatically granted when the inbound rule is enabled.

アプリのテストが終了したら、コマンド プロンプトで Ctrl+C を使用してアプリをシャットダウンします。When done testing the app, shut the app down with Ctrl+C at the command prompt.

アプリの監視Monitoring the app

サーバーは、http://<serveraddress>:80 に対する要求を Kestrel で実行されている ASP.NET Core アプリ (http://127.0.0.1:5000) に転送するようにセットアップされました。The server is setup to forward requests made to http://<serveraddress>:80 on to the ASP.NET Core app running on Kestrel at http://127.0.0.1:5000. ただし、Nginx は Kestrel プロセスを管理するようには設定されていません。However, Nginx isn't set up to manage the Kestrel process. systemd を使用してサービス ファイルを作成し、基になる Web アプリを起動して監視できます。systemd can be used to create a service file to start and monitor the underlying web app. systemd は init システムであり、プロセスを起動、停止、管理するためのさまざまな高性能機能を提供します。systemd is an init system that provides many powerful features for starting, stopping, and managing processes.

サービス ファイルを作成するCreate the service file

次のように、サービス定義ファイルを作成します。Create the service definition file:

sudo nano /etc/systemd/system/kestrel-hellomvc.service

アプリのサービス ファイルの例を次に示します。The following is an example service file for the app:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/aspnetcore/hellomvc
ExecStart=/usr/bin/dotnet /var/aspnetcore/hellomvc/hellomvc.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

ユーザー www-data が構成で使用されない場合、ここで定義するユーザーを先に作成し、ファイルの適切な所有権を与える必要があります。If the user www-data isn't used by the configuration, the user defined here must be created first and given proper ownership for files.

Linux のファイル システムは大文字と小文字を区別します。Linux has a case-sensitive file system. ASPNETCORE_ENVIRONMENT を "Production" に設定すると、構成ファイル appsettings.Production.json が検索されます。appsettings.production.json ではありません。Setting ASPNETCORE_ENVIRONMENT to "Production" results in searching for the configuration file appsettings.Production.json, not appsettings.production.json.

注意

構成プロバイダーが環境変数を読み取れるようにするために、一部の値 (たとえば SQL の接続文字列) をエスケープする必要があります。Some values (for example, SQL connection strings) must be escaped for the configuration providers to read the environment variables. 次のコマンドを使用して、構成ファイルで使用するために適切にエスケープされた値を生成します。Use the following command to generate a properly escaped value for use in the configuration file:

systemd-escape "<value-to-escape>"

ファイルを保存し、サービスを有効にします。Save the file and enable the service.

systemctl enable kestrel-hellomvc.service

サービスを起動し、動作を確認します。Start the service and verify that it's running.

systemctl start kestrel-hellomvc.service
systemctl status kestrel-hellomvc.service

● kestrel-hellomvc.service - Example .NET Web API App running on Ubuntu
    Loaded: loaded (/etc/systemd/system/kestrel-hellomvc.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-hellomvc.service
            └─9021 /usr/local/bin/dotnet /var/aspnetcore/hellomvc/hellomvc.dll

リバース プロキシが構成され、Kestrel は systemd 経由で管理されます。これで Web アプリは完全に構成され、http://localhost でローカル コンピューター上のブラウザーからアクセスできます。With the reverse proxy configured and Kestrel managed through systemd, the web app is fully configured and can be accessed from a browser on the local machine at http://localhost. 妨げとなるファイアウォールがなければ、リモート コンピューターからもアクセスできます。It's also accessible from a remote machine, barring any firewall that might be blocking. 応答ヘッダーを調べると、ASP.NET Core アプリが Kestrel によってサービス提供されていることが Server ヘッダーに示されています。Inspecting the response headers, the Server header shows the ASP.NET Core app being served by Kestrel.

HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked

ログを表示するViewing logs

Kestrel を利用する Web アプリは systemd を使用して管理されるため、すべてのイベントとプロセスが記録され、中心的ジャーナルが生成されます。Since the web app using Kestrel is managed using systemd, all events and processes are logged to a centralized journal. ただし、このジャーナルには、systemd が管理するすべてのサービスとプロセスのすべてのエントリが含まれます。However, this journal includes all entries for all services and processes managed by systemd. kestrel-hellomvc.service 固有の項目を表示するには、次のコマンドを使用します。To view the kestrel-hellomvc.service-specific items, use the following command:

sudo journalctl -fu kestrel-hellomvc.service

さらに絞り込むには、時間オプションとして --since today--until 1 hour ago、あるいはこの 2 つの組み合わせを利用すれば、返されるエントリの数を減らすことができます。For further filtering, time options such as --since today, --until 1 hour ago or a combination of these can reduce the amount of entries returned.

sudo journalctl -fu kestrel-hellomvc.service --since "2016-10-18" --until "2016-10-18 04:00"

データの保護Data protection

ASP.NET Core データ保護スタックは、認証ミドルウェア (Cookie ミドルウェアなど) やクロスサイト リクエスト フォージェリ (CSRF) 保護を含む、いくつかの ASP.NET Core ミドルウェアで使用されます。The ASP.NET Core Data Protection stack is used by several ASP.NET Core middlewares, including authentication middleware (for example, cookie middleware) and cross-site request forgery (CSRF) protections. データ保護 API がユーザーのコードから呼び出されない場合でも、永続的な暗号化キー ストアを作成するようにデータ保護を構成する必要があります。Even if Data Protection APIs aren't called by user code, data protection should be configured to create a persistent cryptographic key store. データ保護を構成しない場合、既定でキーはメモリ内に保持され、アプリが再起動すると破棄されます。If data protection isn't configured, the keys are held in memory and discarded when the app restarts.

キーリングがメモリに格納されている場合、アプリを再起動すると次のことが行われます。If the key ring is stored in memory when the app restarts:

  • すべての cookie ベースの認証トークンは無効になります。All cookie-based authentication tokens are invalidated.
  • ユーザーは、次回の要求時に再度サインインする必要があります。Users are required to sign in again on their next request.
  • キーリングで保護されているデータは、いずれも復号化できなくなります。Any data protected with the key ring can no longer be decrypted. これには、CSRF トークンASP.NET Core MVC TempData cookie が含まれます。This may include CSRF tokens and ASP.NET Core MVC TempData cookies.

キー リングを永続化して暗号化するようにデータ保護を構成する場合は、次を参照してください。To configure data protection to persist and encrypt the key ring, see:

アプリのセキュリティ保護Securing the app

AppArmor を有効にするEnable AppArmor

Linux Security Modules (LSM) は、Linux 2.6 以降の Linux カーネルに含まれるフレームワークです。Linux Security Modules (LSM) is a framework that's part of the Linux kernel since Linux 2.6. LSM は、セキュリティ モジュールのさまざまな実装に対応しています。LSM supports different implementations of security modules. AppArmor は Mandatory Access Control システムを実装する LSM です。このシステムは、プログラムのリソース範囲を限定できます。AppArmor is a LSM that implements a Mandatory Access Control system which allows confining the program to a limited set of resources. AppArmor が有効であり、正しく構成されていることを確認します。Ensure AppArmor is enabled and properly configured.

ファイアウォールの構成Configuring the firewall

使用されていないすべての外部ポートを閉じます。Close off all external ports that are not in use. ufw (uncomplicated firewall/複雑ではないファイアウォール) は iptables のフロント エンドとなり、ファイアウォールを構成するためのコマンド ライン インターフェイスを提供します。Uncomplicated firewall (ufw) provides a front end for iptables by providing a command line interface for configuring the firewall.

警告

ファイアウォールが正しく構成されていない場合、システム全体にアクセスできません。A firewall will prevent access to the whole system if not configured correctly. 正しい SSH ポートを指定しないと、SSH を使用してシステムに接続する場合に、そのシステムから事実上閉め出されることになります。Failure to specify the correct SSH port will effectively lock you out of the system if you are using SSH to connect to it. 既定のポートは 22 です。The default port is 22. 詳細については、ufw の概要マニュアルを参照してください。For more information, see the introduction to ufw and the manual.

ufw をインストールし、必要なすべてのポートでトラフィックを許可するように構成します。Install ufw and configure it to allow traffic on any ports needed.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Nginx のセキュリティを強化するSecuring Nginx

Nginx 応答名を変更するChange the Nginx response name

src/http/ngx_http_header_filter_module.c を編集します。Edit src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

構成オプションConfigure options

必要なその他のモジュールでサーバーを構成します。Configure the server with additional required modules. アプリのセキュリティを強化するために、ModSecurity のような Web アプリのファイアウォールの使用を検討してください。Consider using a web app firewall, such as ModSecurity, to harden the app.

SSL を構成するConfigure SSL

  • 信頼できる証明機関 (CA) が発行した、有効な証明書を指定することで、ポート 443 で HTTPS トラフィックを待ち受けるようにサーバーを構成します。Configure the server to listen to HTTPS traffic on port 443 by specifying a valid certificate issued by a trusted Certificate Authority (CA).

  • 次の /etc/nginx/nginx.conf ファイルで示されているプラクティスの一部を採用することで、セキュリティを強化します。Harden the security by employing some of the practices depicted in the following /etc/nginx/nginx.conf file. たとえば、強力な暗号を選択したり、HTTP 経由のすべてのトラフィックを HTTPS にリダイレクトしたりします。Examples include choosing a stronger cipher and redirecting all traffic over HTTP to HTTPS.

  • HTTP Strict-Transport-Security (HSTS) ヘッダーを追加すると、クライアントが行う後続のすべての要求が HTTPS 経由のみになります。Adding an HTTP Strict-Transport-Security (HSTS) header ensures all subsequent requests made by the client are over HTTPS only.

  • Strict-Transport-Security ヘッダーを追加しないでください。または、今後 SSL を利用できないことがあれば、適切な max-age を選択してください。Don't add the Strict-Transport-Security header or chose an appropriate max-age if SSL will be disabled in the future.

/etc/nginx/proxy.conf 構成ファイルを追加します。Add the /etc/nginx/proxy.conf configuration file:

proxy_redirect 			off;
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;
client_max_body_size 	10m;
client_body_buffer_size 128k;
proxy_connect_timeout 	90;
proxy_send_timeout 		90;
proxy_read_timeout 		90;
proxy_buffers			32 4k;

/etc/nginx/nginx.conf 構成ファイルを編集します。Edit the /etc/nginx/nginx.conf configuration file. この例では、1 つの構成ファイルに http セクションと server セクションの両方が含まれています。The example contains both http and server sections in one configuration file.

http {
    include    /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens off;

    sendfile on;
    keepalive_timeout 29; # Adjust to the lowest possible value that makes sense for your use case.
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream hellomvc{
        server localhost:5000;
    }

    server {
        listen *:80;
        add_header Strict-Transport-Security max-age=15768000;
        return 301 https://$host$request_uri;
    }

    server {
        listen *:443    ssl;
        server_name     example.com;
        ssl_certificate /etc/ssl/certs/testCert.crt;
        ssl_certificate_key /etc/ssl/certs/testCert.key;
        ssl_protocols TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
        ssl_ecdh_curve secp384r1;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;
        ssl_stapling on; #ensure your cert is capable
        ssl_stapling_verify on; #ensure your cert is capable

        add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass  http://hellomvc;
            limit_req   zone=one burst=10 nodelay;
        }
    }
}

Nginx をクリックジャッキングから守るSecure Nginx from clickjacking

クリックジャッキングは、感染したユーザーのクリックを集めるという悪意のある手法です。Clickjacking is a malicious technique to collect an infected user's clicks. クリックジャッキングは被害者 (訪問者) をだまし、感染したサイトでクリックさせます。Clickjacking tricks the victim (visitor) into clicking on an infected site. X-FRAME-OPTIONS を使用して、サイトをセキュリティで保護します。Use X-FRAME-OPTIONS to secure the site.

nginx.conf ファイルを編集します。Edit the nginx.conf file:

sudo nano /etc/nginx/nginx.conf

add_header X-Frame-Options "SAMEORIGIN"; を追加し、ファイルを保存し、Nginx を再起動します。Add the line add_header X-Frame-Options "SAMEORIGIN"; and save the file, then restart Nginx.

MIME タイプ スニッフィングMIME-type sniffing

このヘッダーは応答コンテンツの種類をオーバーライドしないようにブラウザーに指示するので、ほとんどのブラウザーで MIME スニッフィングが阻止されます。This header prevents most browsers from MIME-sniffing a response away from the declared content type, as the header instructs the browser not to override the response content type. nosniff オプションを指定すると、サーバーがコンテンツを "text/html" と読むとき、ブラウザーはそれを "text/html" として表示します。With the nosniff option, if the server says the content is "text/html", the browser renders it as "text/html".

nginx.conf ファイルを編集します。Edit the nginx.conf file:

sudo nano /etc/nginx/nginx.conf

add_header X-Content-Type-Options "nosniff"; を追加し、ファイルを保存し、Nginx を再起動します。Add the line add_header X-Content-Type-Options "nosniff"; and save the file, then restart Nginx.

その他の技術情報Additional resources