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

作成者: Shayne BoyerBy Shayne Boyer

このガイドでは、CentOS 7 上にリバース プロキシ サーバーとして Apache をセットアップし、Kestrel サーバー上で実行されている ASP.NET Core Web アプリに HTTP トラフィックをリダイレクトする方法について説明します。Using this guide, learn how to set up Apache as a reverse proxy server on CentOS 7 to redirect HTTP traffic to an ASP.NET Core web app running on Kestrel server. mod_proxy 拡張機能および関連するモジュールは、サーバーのリバース プロキシを作成します。The mod_proxy extension and related modules create the server's reverse proxy.


  • CentOS 7 を実行しているサーバーと、sudo 特権を持つ標準ユーザー アカウント。Server running CentOS 7 with a standard user account with sudo privilege.
  • サーバーへの .NET Core ランタイムのインストール。Install the .NET Core runtime on the server.
    1. .NET Core のダウンロード」ページにアクセスします。Visit the Download .NET Core page.
    2. プレビューでない最新の .NET Core バージョンを選択します。Select the latest non-preview .NET Core version.
    3. [Run apps - Runtime](アプリの実行 - ランタイム) の下の表でプレビューでない最新のランタイムをダウンロードします。Download the latest non-preview runtime in the table under Run apps - Runtime.
    4. Linux の 「パッケージ マネージャーの手順」 リンクを選択し、CentOS の手順に従います。Select the Linux Package manager instructions link and follow the CentOS instructions.
  • 既存の ASP.NET Core アプリ。An existing ASP.NET Core app.

共有フレームワークをアップグレードした後の任意の時点で、サーバーによってホストされている ASP.NET Core アプリを再起動します。At any point in the future after upgrading the shared framework, restart the ASP.NET Core apps hosted by the server.

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

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

アプリがローカル環境で実行されていて、セキュリティで保護された接続 (HTTPS) を行うように構成されていない場合は、次の方法のいずれかを採用します。If the app is run locally and isn't configured to make secure connections (HTTPS), adopt either of the following approaches:

  • セキュリティで保護されたローカル接続を処理するようにアプリを構成します。Configure the app to handle secure local connections. 詳しくは、「HTTPS の構成」セクションをご覧ください。For more information, see the HTTPS configuration section.
  • Properties/launchSettings.json ファイルの applicationUrl プロパティから https://localhost:5001 を削除します (ある場合)。Remove https://localhost:5001 (if present) from the applicationUrl property in the Properties/launchSettings.json file.

開発環境から 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/www/helloapp)。It's common to locate web apps under the var directory (for example, var/www/helloapp).


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

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

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

プロキシ サーバーは、クライアント要求を処理せずに他のサーバーに転送するサーバーです。A proxy server is one which forwards client requests to another server instead of fulfilling requests itself. リバース プロキシは、一般的に任意のクライアントに代わって固定の送信先に転送します。A reverse proxy forwards to a fixed destination, typically on behalf of arbitrary clients. このガイドでは、Kestrel が ASP.NET Core アプリを提供しているものと同じサーバー上で実行されるリバース プロキシとして Apache を構成します。In this guide, Apache is configured as the reverse proxy running on the same server that Kestrel is serving the ASP.NET Core app.

要求はリバース プロキシによって転送されます。そのため、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 は、他のミドルウェアの前に実行する必要があります。Forwarded Headers Middleware should run before other middleware. この順序により、転送されるヘッダー情報に依存するミドルウェアが処理にヘッダー値を使用できます。This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. 診断およびエラー処理ミドルウェアの後に Forwarded Headers Middleware を実行する方法については、「Forwarded Headers Middleware の順序」を参照してください。To run Forwarded Headers Middleware after diagnostics and error handling middleware, see Forwarded Headers Middleware order.

他のミドルウェアを呼び出す前に、Startup.Configure の一番上にある UseForwardedHeaders メソッドを呼び出します。Invoke the UseForwardedHeaders method at the top of Startup.Configure before calling other middleware. ミドルウェアを構成して、X-Forwarded-For および X-Forwarded-Proto ヘッダーを転送します。Configure the middleware to forward the X-Forwarded-For and X-Forwarded-Proto headers:

// using Microsoft.AspNetCore.HttpOverrides;

app.UseForwardedHeaders(new ForwardedHeadersOptions
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto


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

標準 localhost アドレス ( など、ループバック アドレス (、[::1]) 上で実行するプロキシは、既定で信頼されます。Proxies running on loopback addresses (, [::1]), including the standard localhost address (, are trusted by default. 組織内のその他の信頼されているプロキシまたはネットワークによってインターネットと Web サーバーの間の要求が処理される場合は、それらを、ForwardedHeadersOptions を使用して KnownProxies または KnownNetworks のリストに追加します。If other trusted proxies or networks within the organization handle requests between the Internet and the web server, add them to the list of KnownProxies or KnownNetworks with ForwardedHeadersOptions. 次の例では、IP アドレス にある信頼されているプロキシ サーバーが Startup.ConfigureServices 内の Forwarded Headers Middleware KnownProxies に追加されます。The following example adds a trusted proxy server at IP address to the Forwarded Headers Middleware KnownProxies in Startup.ConfigureServices:

// using System.Net;

services.Configure<ForwardedHeadersOptions>(options =>

詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。For more information, see プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する.

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

CentOS パッケージを最新の安定したバージョンに更新します。Update CentOS packages to their latest stable versions:

sudo yum update -y

1 つの yum コマンドで、CentOS に Apache Web サーバーをインストールします。Install the Apache web server on CentOS with a single yum command:

sudo yum -y install httpd mod_ssl

コマンド実行後の出力例:Sample output after running the command:

Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm               | 2.7 MB  00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 
Verifying  : httpd-2.4.6-40.el7.centos.4.x86_64      1/1 

httpd.x86_64 0:2.4.6-40.el7.centos.4



この例では、CentOS 7 のバージョンが 64 ビットなので、出力は httpd.86_64 を反映しています。In this example, the output reflects httpd.86_64 since the CentOS 7 version is 64 bit. Apache がインストールされている場所を確認するには、コマンド プロンプトから whereis httpd を実行します。To verify where Apache is installed, run whereis httpd from a command prompt.

Apache を構成するConfigure Apache

Apache の構成ファイルは、/etc/httpd/conf.d/ ディレクトリ内にあります。Configuration files for Apache are located within the /etc/httpd/conf.d/ directory. /etc/httpd/conf.modules.d/ 内のモジュール構成ファイルに加え、拡張子が .conf のファイルがアルファベット順で処理されます。このディレクトリには、モジュールの読み込みに必要な構成ファイルが含まれています。Any file with the .conf extension is processed in alphabetical order in addition to the module configuration files in /etc/httpd/conf.modules.d/, which contains any configuration files necessary to load modules.

アプリ用に helloapp.conf という名前の構成ファイルを作成します。Create a configuration file, named helloapp.conf, for the app:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

<VirtualHost *:80>
    ProxyPreserveHost On
    ProxyPass /
    ProxyPassReverse /
    ServerName www.example.com
    ServerAlias *.example.com
    ErrorLog ${APACHE_LOG_DIR}helloapp-error.log
    CustomLog ${APACHE_LOG_DIR}helloapp-access.log common

VirtualHost ブロックは、サーバー上の 1 つまたは複数のファイルに複数回出現することができます。The VirtualHost block can appear multiple times, in one or more files on a server. 上記の構成ファイルでは、Apache はポート 80 でパブリック トラフィックを受け入れます。In the preceding configuration file, Apache accepts public traffic on port 80. ドメイン www.example.com が提供されており、別名 *.example.com は同じ Web サイトに解決されます。The domain www.example.com is being served, and the *.example.com alias resolves to the same website. 詳しくは、「名前ベースのバーチャル ホスト」をご覧ください。See Name-based virtual host support for more information. 要求は、ルートにおいて、 にあるサーバーのポート 5000 にプロキシされます。Requests are proxied at the root to port 5000 of the server at 双方向通信の場合は、ProxyPassProxyPassReverse が必要です。For bi-directional communication, ProxyPass and ProxyPassReverse are required. Kestrel の IP/ポートを変更するには、Kestrel のエンドポイントの構成に関するセクションを参照してください。To change Kestrel's IP/port, see Kestrel: Endpoint configuration.


VirtualHost ブロックで適切な ServerName ディレクティブを指定しないと、アプリにセキュリティ上の脆弱性が生じます。Failure to specify a proper ServerName directive in the VirtualHost block 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.

ErrorLog および CustomLog ディレクティブを使って、VirtualHost ごとにログを構成できます。Logging can be configured per VirtualHost using ErrorLog and CustomLog directives. ErrorLog は、サーバーがエラーをログに記録する場所です。CustomLog には、ログ ファイルのファイル名と形式を設定します。ErrorLog is the location where the server logs errors, and CustomLog sets the filename and format of log file. この例では、要求の情報がログに記録される場所です。In this case, this is where request information is logged. 1 つの要求につき 1 行が記録されます。There's one line for each request.

ファイルを保存し、構成をテストします。Save the file and test the configuration. すべてに合格すると、応答は Syntax [OK] になります。If everything passes, the response should be Syntax [OK].

sudo service httpd configtest

Apache を再起動します。Restart Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

アプリを監視するMonitor the app

これで、http://localhost:80 に対して行われた要求を Kestrel で実行されている ASP.NET Core アプリ ( に転送するように Apache が設定されました。Apache is now setup to forward requests made to http://localhost:80 to the ASP.NET Core app running on Kestrel at ただし、Apache は Kestrel プロセスを管理するようには設定されていません。However, Apache isn't set up to manage the Kestrel process. systemd を使って、基礎 Web アプリを起動して監視するサービス ファイルを作成します。Use systemd and 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-helloapp.service

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

Description=Example .NET Web API App running on CentOS 7

ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
# Restart service after 10 seconds if the dotnet service crashes:


前の例では、サービスを管理するユーザーは User オプションによって指定されています。In the preceding example, the user that manages the service is specified by the User option. ユーザー (apache) が存在し、アプリのファイルの適切な所有権を持っている必要があります。The user (apache) must exist and have proper ownership of the app's files.

アプリが最初の割り込み信号を受信してからシャットダウンするのを待機する期間を構成するには、TimeoutStopSec を使用します。Use TimeoutStopSec to configure the duration of time to wait for the app to shut down after it receives the initial interrupt signal. この期間内にアプリがシャットダウンしない場合は、SIGKILL を発行してアプリを終了します。If the app doesn't shut down in this period, SIGKILL is issued to terminate the app. タイムアウトを無効にするには、値として、単位なしの秒数 (150 など)、期間の値 (2min 30s など)、または infinity を指定します。Provide the value as unitless seconds (for example, 150), a time span value (for example, 2min 30s), or infinity to disable the timeout. TimeoutStopSec は、既定ではマネージャー構成ファイル (systemd-system.confsystem.conf.dsystemd-user.confuser.conf.d) 内の DefaultTimeoutStopSec の値に設定されます。TimeoutStopSec defaults to the value of DefaultTimeoutStopSec in the manager configuration file (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). ほとんどのディストリビューションにおいて、タイムアウトの既定値は 90 秒となります。The default timeout for most distributions is 90 seconds.

# The default value is 90 seconds for most distributions.

構成プロバイダーが環境変数を読み取れるようにするために、一部の値 (たとえば 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>"

コロン (:) 区切り記号は、環境変数の名前ではサポートされていません。Colon (:) separators aren't supported in environment variable names. コロンの代わりに 2 つのアンダースコア (__) を使用します。Use a double underscore (__) in place of a colon. 環境変数が構成に読み取られるときに、環境変数構成プロバイダーによって 2 つのアンダースコアがコロンに変換されます。The Environment Variables configuration provider converts double-underscores into colons when environment variables are read into configuration. 次の例では、接続文字列キー ConnectionStrings:DefaultConnection はサービス定義ファイルでは ConnectionStrings__DefaultConnection と設定されています。In the following example, the connection string key ConnectionStrings:DefaultConnection is set into the service definition file as ConnectionStrings__DefaultConnection:

コロン (:) 区切り記号は、環境変数の名前ではサポートされていません。Colon (:) separators aren't supported in environment variable names. コロンの代わりに 2 つのアンダースコア (__) を使用します。Use a double underscore (__) in place of a colon. 環境変数が構成に読み取られるときに、環境変数構成プロバイダーによって 2 つのアンダースコアがコロンに変換されます。The Environment Variables configuration provider converts double-underscores into colons when environment variables are read into configuration. 次の例では、接続文字列キー ConnectionStrings:DefaultConnection はサービス定義ファイルでは ConnectionStrings__DefaultConnection と設定されています。In the following example, the connection string key ConnectionStrings:DefaultConnection is set into the service definition file as ConnectionStrings__DefaultConnection:

Environment=ConnectionStrings__DefaultConnection={Connection String}

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

sudo systemctl enable kestrel-helloapp.service

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

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
    Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
    Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
    CGroup: /system.slice/kestrel-helloapp.service
            └─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.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. 応答ヘッダーを調べると、Server ヘッダーでは ASP.NET Core アプリが Kestrel によって提供されていることが示されています。Inspecting the response headers, the Server header indicates that the ASP.NET Core app is 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

ログを表示するView logs

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

sudo journalctl -fu kestrel-helloapp.service

時間フィルタリングの場合は、コマンドで時間のオプションを指定します。For time filtering, specify time options with the command. たとえば、現在の日付でフィルター処理するには --since today を使い、前の 1 時間のエントリを参照するには --until 1 hour ago を使います。For example, use --since today to filter for the current day or --until 1 hour ago to see the previous hour's entries. 詳しくは、journalctl の man ページをご覧ください。For more information, see the man page for journalctl.

sudo journalctl -fu kestrel-helloapp.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:

アプリをセキュリティで保護するSecure the app

ファイアウォールを構成するConfigure firewall

Firewalld は、ネットワーク ゾーンをサポートするファイアウォールを管理するための動的デーモンです。Firewalld is a dynamic daemon to manage the firewall with support for network zones. ポートとパケットのフィルター処理は、iptables によって引き続き管理できます。Ports and packet filtering can still be managed by iptables. Firewalld は既定でインストールされます。Firewalld should be installed by default. yum を使ってパッケージをインストールしたり、インストールされていることを確認したりできます。yum can be used to install the package or verify it's installed.

sudo yum install firewalld -y

アプリに必要なポートのみを開くには、firewalld を使います。Use firewalld to open only the ports needed for the app. この場合、ポート 80 と 443 が使用されています。In this case, port 80 and 443 are used. 次のコマンドは、ポート 80 と 443 が永続的に開かれるように設定します。The following commands permanently set ports 80 and 443 to open:

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent

ファイアウォールの設定を再度読み込みます。Reload the firewall settings. 既定のゾーンで使用できるサービスとポートを確認します。Check the available services and ports in the default zone. オプションは firewall-cmd -h を調べることで使用できます。Options are available by inspecting firewall-cmd -h.

sudo firewall-cmd --reload
sudo firewall-cmd --list-all
public (default, active)
interfaces: eth0
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
rich rules: 

HTTPS の構成HTTPS configuration

セキュリティで保護された (HTTPS) ローカル接続用にアプリを構成するConfigure the app for secure (HTTPS) local connections

dotnet run コマンドでは、アプリの Properties/launchSettings.json ファイルが使用されます。このファイルでは、applicationUrl プロパティによって提供される URL でリッスンするように、アプリが構成されます (例: https://localhost:5001;http://localhost:5000)。The dotnet run command uses the app's Properties/launchSettings.json file, which configures the app to listen on the URLs provided by the applicationUrl property (for example, https://localhost:5001;http://localhost:5000).

次のいずれかの方法を使用して、dotnet run コマンド用の開発または開発環境 (Visual Studio Code の F5 または Ctrl + F5 キー) で証明書を使用するように、アプリを構成します。Configure the app to use a certificate in development for the dotnet run command or development environment (F5 or Ctrl+F5 in Visual Studio Code) using one of the following approaches:

セキュリティで保護された (HTTPS) クライアント接続用にリバース プロキシを構成するConfigure the reverse proxy for secure (HTTPS) client connections

HTTPS 用に Apache を構成するには、mod_ssl モジュールを使います。To configure Apache for HTTPS, the mod_ssl module is used. httpd モジュールがインストールされていると、mod_ssl モジュールもインストールされています。When the httpd module was installed, the mod_ssl module was also installed. インストールされていない場合は、yum を使って構成に追加します。If it wasn't installed, use yum to add it to the configuration.

sudo yum install mod_ssl

HTTPS を強制するには、mod_rewrite モジュールをインストールして URL の書き換えを有効にします。To enforce HTTPS, install the mod_rewrite module to enable URL rewriting:

sudo yum install mod_rewrite

helloapp.conf ファイルを変更して、URL の書き換えを有効にし、ポート 443 での通信をセキュリティで保護します。Modify the helloapp.conf file to enable URL rewriting and secure communication on port 443:

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

<VirtualHost *:443>
    ProxyPreserveHost On
    ProxyPass /
    ProxyPassReverse /
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key


この例では、ローカルで生成された証明書を使います。This example is using a locally-generated certificate. SSLCertificateFile は、ドメイン名のプライマリ証明書ファイルです。SSLCertificateFile should be the primary certificate file for the domain name. SSLCertificateKeyFile は、CSR の作成時に生成されるキー ファイルです。SSLCertificateKeyFile should be the key file generated when CSR is created. SSLCertificateChainFile は、証明機関から提供された中間証明書ファイル (存在する場合) です。SSLCertificateChainFile should be the intermediate certificate file (if any) that was supplied by the certificate authority.

ファイルを保存し、構成をテストします。Save the file and test the configuration:

sudo service httpd configtest

Apache を再起動します。Restart Apache:

sudo systemctl restart httpd

Apache に関するその他の推奨事項Additional Apache suggestions

共有されたフレームワークの更新プログラムを使用してアプリを再起動するRestart apps with shared framework updates

サーバー上で共有フレームワークをアップグレードしたら、サーバーによってホストされている ASP.NET Core アプリを再起動します。After upgrading the shared framework on the server, restart the ASP.NET Core apps hosted by the server.

その他のヘッダーAdditional headers

悪意のある攻撃から防御するために、変更または追加する必要があるヘッダーがいくつかあります。In order to secure against malicious attacks, there are a few headers that should either be modified or added. 必ず mod_headers モジュールをインストールします。Ensure that the mod_headers module is installed:

sudo yum install mod_headers

Apache をクリックジャッキング攻撃から保護するSecure Apache from clickjacking attacks

クリックジャッキングは "UI 着せ替え攻撃" とも呼ばれ、Web サイトの訪問者を騙して現在訪れているものとは異なるページのリンクやボタンをクリックさせる悪意のある攻撃です。Clickjacking, also known as a UI redress attack, is a malicious attack where a website visitor is tricked into clicking a link or button on a different page than they're currently visiting. サイトをセキュリティで保護するには、X-FRAME-OPTIONS を使います。Use X-FRAME-OPTIONS to secure the site.

クリックジャッキング攻撃を軽減するには、次の手順に従います。To mitigate clickjacking attacks:

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

    sudo nano /etc/httpd/conf/httpd.conf

    Header append X-FRAME-OPTIONS "SAMEORIGIN" を追加します。Add the line Header append X-FRAME-OPTIONS "SAMEORIGIN".

  2. ファイルを保存します。Save the file.

  3. Apache を再起動します。Restart Apache.

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

X-Content-Type-Options ヘッダーは、Internet Explorer を "MIME スニッフィング" から防ぎます (ファイルの内容からファイルの Content-Type を判断します)。The X-Content-Type-Options header prevents Internet Explorer from MIME-sniffing (determining a file's Content-Type from the file's content). サーバーが nosniff オプションを指定して Content-Type ヘッダーを text/html に設定すると、Internet Explorer はファイルの内容に関係なく text/html として内容をレンダリングします。If the server sets the Content-Type header to text/html with the nosniff option set, Internet Explorer renders the content as text/html regardless of the file's content.

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

sudo nano /etc/httpd/conf/httpd.conf

Header set X-Content-Type-Options "nosniff" を追加します。Add the line Header set X-Content-Type-Options "nosniff". ファイルを保存します。Save the file. Apache を再起動します。Restart Apache.

負荷分散Load Balancing

この例では、同じインスタンス コンピューターに CentOS 7 と Kestrel をインストールし、Apache をセットアップおよび構成する方法を示します。This example shows how to setup and configure Apache on CentOS 7 and Kestrel on the same instance machine. 単一障害点を持たないように、mod_proxy_balancer を使い、VirtualHost を変更することで、Apache プロキシ サーバーの背後で複数インスタンスの Web アプを管理できるようにします。In order to not have a single point of failure; using mod_proxy_balancer and modifying the VirtualHost would allow for managing multiple instances of the web apps behind the Apache proxy server.

sudo yum install mod_proxy_balancer

次に示す構成ファイルでは、ポート 5001 上で実行するように helloapp の追加インスタンスを設定しています。In the configuration file shown below, an additional instance of the helloapp is set up to run on port 5001. Proxy セクションは、2 メンバーのバランサー構成を使って byrequests を負荷分散するように設定されています。The Proxy section is set with a balancer configuration with two members to load balance byrequests.

<VirtualHost *:*>
    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

<VirtualHost *:443>
    ProxyPass / balancer://mycluster/ 

    ProxyPassReverse /
    ProxyPassReverse /

    <Proxy balancer://mycluster>
        ProxySet lbmethod=byrequests

    <Location />
        SetHandler balancer
    ErrorLog /var/log/httpd/helloapp-error.log
    CustomLog /var/log/httpd/helloapp-access.log common
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

速度の制限Rate Limits

httpd モジュールに含まれる mod_ratelimit を使って、クライアントの帯域幅を制限できます。Using mod_ratelimit, which is included in the httpd module, the bandwidth of clients can be limited:

sudo nano /etc/httpd/conf.d/ratelimit.conf

次のファイルの例では、ルートの場所の下での帯域幅を 600 KB/秒に制限しています。The example file limits bandwidth as 600 KB/sec under the root location:

<IfModule mod_ratelimit.c>
    <Location />
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 600

要求ヘッダー フィールドが長すぎますLong request header fields

プロキシ サーバーの既定の設定では、通常、要求ヘッダー フィールドが 8190 バイトに制限されます。Proxy server default settings typically limit request header fields to 8,190 bytes. アプリでは、既定値よりも長いフィールドが必要になる場合があります (たとえば、Azure Active Directory を使用するアプリ)。An app may require fields longer than the default (for example, apps that use Azure Active Directory). 長いフィールドが必要な場合は、プロキシ サーバーの LimitRequestFieldSize ディレクティブに対して調整が必要になります。If longer fields are required, the proxy server's LimitRequestFieldSize directive requires adjustment. 適用する値は、シナリオによって異なります。The value to apply depends on the scenario. 詳細については、ご利用のサーバーのドキュメントを参照してください。For more information, see your server's documentation.


必要な場合を除いて、LimitRequestFieldSize の既定値を増やさないでください。Don't increase the default value of LimitRequestFieldSize unless necessary. 値を増やすと、悪意のあるユーザーによるバッファー オーバーラン (オーバーフロー) とサービス拒否 (DoS) の攻撃のリスクが増加します。Increasing the value increases the risk of buffer overrun (overflow) and Denial of Service (DoS) attacks by malicious users.

その他の技術情報Additional resources