Apacheのセキュリティ設定ガイド（情報の露出・アクセス制御・TLS・WordPress向けの設定と確認方法）

Apache のセキュリティ設定は「余計な情報を出さない」「不要な機能を止める」「見せてはいけないファイルへのアクセスを拒否する」「通信を暗号化する」の4つに整理できます。この記事では、Apache 2.4 を前提に、それぞれの設定をどのファイルに書くか、書いたあと curl や apachectl でどう確認するかを順に説明し、最後に WordPress サイトで追加しておきたい設定をまとめます。読み終えると、自分のサーバーの設定を項目ごとに点検し、変更の影響を確かめながら強化できるようになります。

作業前の準備

Apache の設定ファイルの場所は、ディストリビューションによって異なります。

• Debian / Ubuntu：/etc/apache2/ 配下。セキュリティ関連の基本設定は conf-available/security.conf にまとまっており、a2enconf / a2enmod で有効化します。
• RHEL 系：/etc/httpd/conf/httpd.conf と /etc/httpd/conf.d/ 配下。

設定を変える前に、設定ディレクトリ全体をバックアップします。

sudo cp -a /etc/apache2 /etc/apache2.bak-$(date +%Y%m%d)   # RHEL 系は /etc/httpd

変更のたびに構文を確認し、問題がなければ graceful で再読み込みします。graceful は処理中のリクエストを切らずに設定を反映する方法です。

sudo apachectl configtest      # Syntax OK と出ることを確認
sudo apachectl graceful

構文エラーのまま restart すると Apache が起動せず、サイトが止まります。configtest を省略しないことが、設定作業でいちばん大切な習慣です。

1. サーバー情報の露出を減らす

既定の設定では、レスポンスヘッダーやエラーページに Apache のバージョンや OS の情報が表示されることがあります。バージョンを隠しても脆弱性そのものはなくなりませんが、攻撃者に手がかりを与えずに済みます。

# Debian 系: /etc/apache2/conf-available/security.conf
ServerTokens Prod
ServerSignature Off
TraceEnable Off

• ServerTokens Prod：Server ヘッダーを「Apache」だけにします。
• ServerSignature Off：エラーページの末尾にバージョンを表示しません。
• TraceEnable Off：診断用の TRACE メソッドを無効にします。

確認は curl で行います。

curl -sI https://example.com/ | grep -i '^server'
curl -s -o /dev/null -w '%{http_code}\n' -X TRACE https://example.com/

Server ヘッダーが Apache のみになり、TRACE が 405 などで拒否されれば反映されています。PHP を使っている場合は、php.ini の expose_php = Off で X-Powered-By ヘッダーも止めておきます。

2. 不要なモジュールと機能を止める

読み込まれているモジュールは次のコマンドで一覧できます。

apachectl -M

使っていないモジュールは、攻撃に使える機能を減らすために無効化します。よく見直し対象になるのは、ディレクトリ一覧を作る autoindex、サーバー状態を表示する status、CGI 関連、使っていないプロキシ関連のモジュールなどです。Debian 系では sudo a2dismod autoindex のように無効化します。

ただし、無効化したモジュールのディレクティブが設定ファイルに残っていると起動できなくなります。1つずつ無効化して configtest を通し、サイトの動作を確認してから次に進みます。mod_status を監視に使っている場合は、無効化せずにアクセス元を限定します。

ディレクトリごとの機能は Options で制御します。

<Directory /var/www/>
    Options -Indexes -Includes +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

-Indexes で、index ファイルがないディレクトリのファイル一覧表示を止めます。WordPress のパーマリンクは .htaccess の mod_rewrite を使うため、ドキュメントルートでは AllowOverride を無効にできないことが多いです。.htaccess を使わない構成にするなら AllowOverride None にして、ルールを VirtualHost 側に移すと、性能面でも有利です。

3. 見せてはいけないファイルへのアクセスを拒否する

まず、サーバー全体のルートディレクトリへのアクセスを拒否し、公開するディレクトリだけを許可する形になっているか確認します。多くのディストリビューションの既定設定はこの形ですが、過去の設定変更で崩れていることがあります。

<Directory />
    Options None
    AllowOverride None
    Require all denied
</Directory>

次に、ドキュメントルートに置かれがちな公開すべきでないファイルを拒否します。

# .git や .env などのドットファイル（Let's Encrypt の認証用ディレクトリは除外）
<LocationMatch "/\.(?!well-known/)">
    Require all denied
</LocationMatch>

# バックアップや設定の残骸
<FilesMatch "\.(bak|old|orig|sql|log|swp|ini)$">
    Require all denied
</FilesMatch>

デプロイで .git ディレクトリが公開領域に残っていると、ソースコードや過去の設定値を取得される危険があります。設定を入れたら、実際に存在するファイルに curl でアクセスして 403 または 404 になるか確認します。

Apache 2.2 の Order allow,deny / Deny from all という書き方は、2.4 では互換モジュール経由でしか動きません。古い記事の設定を流用している場合は、Require の書き方に置き換えておくと、意図しない許可を防げます。

4. リクエストの制限とタイムアウト

大きすぎるリクエストや、わざと遅く送ってくる接続（Slowloris 型の攻撃）で接続枠を埋められるのを防ぎます。

# 本文の最大サイズ（バイト）。WordPress のアップロード上限より少し大きくする
LimitRequestBody 67108864

# mod_reqtimeout: ヘッダーと本文の受信に時間の上限を設ける
<IfModule reqtimeout_module>
    RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>

Timeout 60

LimitRequestBody は PHP の upload_max_filesize や post_max_size と整合させます。Apache 側を小さくしすぎると、メディアのアップロードやプラグインのインストールが失敗します。値はサイトの用途に合わせて決めてください。

ログイン画面へのブルートフォースのような繰り返しのアクセスは、Apache の設定だけでは防ぎきれません。fail2ban でログから IP を遮断する方法や、mod_security のような WAF の導入を組み合わせます。

5. TLS の設定とセキュリティヘッダー

HTTPS の設定では、古いプロトコルを無効にし、強い暗号スイートだけを使います。

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder off
SSLSessionTickets off

暗号スイートの細かい指定は、Apache と OpenSSL のバージョン、対応したい端末によって最適な値が変わります。自分で一から組むより、Mozilla の SSL Configuration Generator で自分のバージョンを指定して出力した設定を参考にするのが現実的です（2026年10月現在）。設定後は外部の SSL 診断サービスで結果を確認します。

セキュリティヘッダーは mod_headers で追加します。

<IfModule headers_module>
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

HSTS（Strict-Transport-Security）は HTTPS を強制する強力なヘッダーですが、一度ブラウザに記録されると取り消しに時間がかかります。サブドメインを含めて HTTPS 化が済んでいることを確かめ、短い max-age から段階的に延ばしてください。Content-Security-Policy は WordPress のプラグインやテーマと衝突しやすいため、まず Report-Only で影響を確認するのが安全です。

6. WordPress サイトで追加したい設定

WordPress 特有の対象には、次のような設定を VirtualHost または .htaccess に追加します。

# wp-config.php への直接アクセスを拒否
<Files wp-config.php>
    Require all denied
</Files>

# アップロードディレクトリでの PHP 実行を拒否
<Directory /var/www/example/wp-content/uploads>
    <FilesMatch "\.(php|phar|phtml)$">
        Require all denied
    </FilesMatch>
</Directory>

uploads は Web から書き込みが可能な場所なので、悪意のある PHP ファイルが置かれても実行されないようにしておくと、被害を大きく減らせます。設定後、テスト用の PHP ファイルを置いて 403 になることを確認し、確認が終わったらそのファイルを削除します。

xmlrpc.php はブルートフォースの標的になりやすい一方、Jetpack や一部のモバイルアプリ、外部連携サービスが利用しています。拒否する前に、自分のサイトで使っている機能がないか確認してください。

wp-admin へのアクセス元を IP で制限する方法もありますが、admin-ajax.php はフロントエンドからも使われるため、wp-admin 全体を拒否するとサイトの機能が壊れることがあります。制限する場合は admin-ajax.php を除外し、ステージング環境で動作を確認します。

7. 実行ユーザーとログ

Apache のワーカーは www-data や apache などの専用ユーザーで動かし、そのユーザーが書き込めるディレクトリは uploads やキャッシュなどに限定します。WordPress のファイル全体を Web サーバーのユーザーが書き換えられる状態だと、1つの脆弱性でサイト全体を改ざんされるおそれがあります。

アクセスログとエラーログは、異常に気づくための材料です。ログのローテーションが設定されているか、ディスクを圧迫していないかも定期的に確認します。

まとめ

• 設定前にバックアップを取り、変更のたびに apachectl configtest を通してから graceful で反映する
• ServerTokens Prod、ServerSignature Off、TraceEnable Off で情報の露出を減らす
• apachectl -M で不要なモジュールを洗い出し、Options -Indexes でファイル一覧を止める
• ルートは Require all denied、ドットファイルやバックアップファイルへのアクセスも拒否する
• リクエストサイズとタイムアウトを用途に合わせて制限する
• TLS は古いプロトコルを止め、暗号スイートは Mozilla の生成ツールを参考にする
• WordPress では wp-config.php の保護と uploads での PHP 実行の拒否を入れ、xmlrpc.php や wp-admin の制限は影響を確認してから行う

• ApacheにModSecurityを導入してWAFを設定する
• アップロードディレクトリでのPHP実行を.htaccessで防ぐ