LinuxのApache（httpd）セキュリティ設定入門｜バージョン非表示・ヘッダー制御・mod_securityで攻撃者の手口を封じる実践ガイド

「うちのWebサーバー、デフォルトのApache設定のままで大丈夫かな？」

そう感じながらも、設定変更のきっかけがつかめずにいる情シス担当者は少なくありません。Apacheはデフォルト状態だと、バージョン情報・OSの種類・インストール済みモジュールまで、HTTPレスポンスヘッダーに丁寧に記載して外部へ公開してしまいます。攻撃者にとっては「事前調査完了」と同じ状態です。

この記事では、Linuxサーバー上のApache（httpd）を堅牢化するための設定手順を、情シス1人でも今日から実施できるレベルで解説します。バージョン情報の隠蔽から、セキュリティヘッダーの設定、mod_securityによるWAF機能の有効化まで、優先度順に説明します。

Apacheが狙われる理由（デフォルト設定の危険性）

Apacheは世界で最も普及しているWebサーバーソフトウェアの一つです。普及率が高いということは、攻撃者がApacheの既知の脆弱性や設定の弱点を研究し尽くしていることを意味します。

もう一つ重要な問題があります。Apacheはデフォルト設定のままだと、次のような情報を外部に漏らします。

・サーバーバージョン: 「Apache/2.4.54」のような文字列がレスポンスヘッダーに含まれる
・OS情報: 「(Rocky Linux)」「(Ubuntu)」のようにOSの種類まで公開される
・有効モジュール: mod_ssl・mod_phpなど、インストール済みモジュールが確認できてしまう
・ディレクトリ一覧: index.htmlがなければファイル一覧がブラウザに表示される

攻撃者はこの情報を見て「このバージョンに有効な脆弱性はどれか」を即座に検索できます。設定変更だけで防げるリスクを放置するのはもったいないことです。

攻撃の準備段階でサーバー情報を奪われないために

攻撃者がまず行うのはターゲットの情報収集です。Apacheから得られる情報を絞ることで、攻撃のハードルを上げることができます。

1. バージョン情報を非表示にする（ServerTokens・ServerSignature）

最優先で対処すべき設定です。`/etc/httpd/conf/httpd.conf`（RHEL系）または `/etc/apache2/apache2.conf`（Debian系）に以下を追記または変更します。

# デフォルト: ServerTokens Full（バージョン+OS+モジュール全開示）
# → Prod に変更することで "Apache" のみ表示
ServerTokens Prod

# エラーページなどに表示されるバージョン情報も非表示にする
# デフォルト: ServerSignature On
ServerSignature Off

設定変更後はApacheを再起動して反映させます。

# RHEL/Rocky Linux/AlmaLinux
sudo systemctl restart httpd

# Ubuntu/Debian
sudo systemctl restart apache2

`curl -I https://your-server/` でレスポンスヘッダーを確認し、`Server: Apache` のみが返れば成功です。

2. ETagヘッダーのinode情報漏洩を防ぐ

あまり知られていませんが、ApacheのETagヘッダーはデフォルトでファイルのinode番号を含んでいます。inode番号が分かると、複数のクラスタサーバーを使っていることが推測できたり、内部構成の調査に悪用される場合があります。

# inode番号をETagから除外し、更新時刻とサイズのみを使う
FileETag MTime Size

または、ETagを完全に無効化してキャッシュ制御はCache-Controlヘッダーに委ねる方法もあります。

# ETagを完全に無効化する場合
FileETag None

3. 不要なモジュールの無効化

使っていないモジュールは脆弱性の窓口になります。有効なモジュールを確認してから、不要なものは無効化します。

# 有効なモジュールを一覧表示
httpd -M

# Ubuntu/Debian系の場合: モジュールの無効化
sudo a2dismod autoindex  # ディレクトリリスティング無効化
sudo a2dismod status     # サーバーステータスページの無効化

RHEL系では `/etc/httpd/conf.modules.d/` 配下のファイルをコメントアウトすることでモジュールを無効化できます。`mod_status`（サーバー状態の表示）、`mod_info`（設定情報の表示）は、本番環境で有効のままにしておくと内部情報が漏れる可能性があります。

セキュリティヘッダーで攻撃の入口を塞ぐ

セキュリティヘッダーは、ブラウザに「このサイトのコンテンツをどう扱うか」を指示するHTTPヘッダーです。適切に設定することで、XSS・クリックジャッキング・MIMEスニッフィングといった攻撃を大幅に防げます。

セキュリティヘッダー全般についてはセキュリティヘッダー完全ガイド（CSP・HSTS・X-Frame-Options）でも詳しく解説しています。ここではApacheの設定ファイルへの具体的な記述を示します。

`mod_headers` が有効であることを前提として、以下を `httpd.conf` または仮想ホスト設定に追記します。

# mod_headersが有効であることを確認（RHEL系）
# httpd.conf か conf.modules.d/00-base.conf で以下が有効になっていること
# LoadModule headers_module modules/mod_headers.so


    # クリックジャッキング対策: iframeへの埋め込みを同一オリジンのみ許可
    Header always set X-Frame-Options "SAMEORIGIN"

    # MIMEタイプスニッフィングの防止
    Header always set X-Content-Type-Options "nosniff"

    # XSS対策（モダンブラウザは非推奨だが古いブラウザ対策として残す）
    Header always set X-XSS-Protection "1; mode=block"

    # HTTPS強制（HSTS）: max-ageは最低6ヶ月（15768000秒）から
    # HTTPSが完全に設定された後に有効化すること
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # リファラー情報の制御: 外部サイトへのリンク時に詳細URLを渡さない
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Permissons-Policy: 不要なブラウザ機能の制限
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

1. Content-Security-Policy（CSP）の設定

CSPはXSS対策の中でも特に強力なヘッダーですが、設定を誤るとサイトが動かなくなることもあります。まずはレポートモードで動作確認から始めることを推奨します。

# 最初は Content-Security-Policy-Report-Only で動作確認
# 違反があってもサイトは動くが、ブラウザのコンソールにレポートが出る
Header always set Content-Security-Policy-Report-Only \
    "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"

# 動作確認後、Content-Security-Policy に切り替える（違反ブロック）
# Header always set Content-Security-Policy "default-src 'self'; ..."

Directory設定とアクセス制御の強化

1. ディレクトリリスティングの無効化

最も基本的でありながら、見落とされがちな設定です。`Options Indexes` が有効だと、ディレクトリにindex.htmlがない場合にファイル一覧が丸見えになります。

    # Indexes を除去することでディレクトリリスティングを無効化
    # FollowSymLinks は必要なければ除去も検討
    Options -Indexes +FollowSymLinks

    # .htaccessによる設定オーバーライドを禁止（後述）
    AllowOverride None

    # 全アクセスを許可（アクセス制御が別途必要な場合は変更）
    Require all granted

2. 機密ファイルへのアクセスを遮断する

`.git`ディレクトリ、バックアップファイル、設定ファイルへのアクセスをブロックします。

# .htaccessや.envなどの隠しファイルへのアクセスを遮断

    Require all denied


# バックアップファイルや設定ファイルへのアクセスを遮断

    Require all denied


# .gitディレクトリへのアクセスを遮断（コードが漏洩する典型的な事故）

    Require all denied

3. HTTPメソッドの制限

WebサーバーとしてGETとPOSTのみ許可するのが基本です。PUTやDELETEなど、不要なHTTPメソッドを制限します。

    Require all denied

mod_securityでWAF機能を追加する

mod_securityはApacheに組み込めるオープンソースのWAF（Webアプリケーションファイアウォール）です。SQLインジェクションやXSSのパターンを検知してブロックできます。WAFの基本概念についてはWAFとは？仕組み・選び方・導入手順も参照してください。

# RHEL/Rocky Linux/AlmaLinux の場合
sudo dnf install mod_security

# Ubuntu/Debian の場合
sudo apt install libapache2-mod-security2
sudo a2enmod security2

インストール後、まずは「検知のみ・ブロックしない」のDetectionOnly（検知モード）で動作確認します。

# /etc/httpd/conf.d/mod_security.conf または
# /etc/modsecurity/modsecurity.conf を編集

# 最初は DetectionOnly で稼働させ、誤検知がないか確認する
SecRuleEngine DetectionOnly

# ログを確認しながら問題なければ On に変更（攻撃をブロック）
# SecRuleEngine On

OWASP（Open Web Application Security Project）が公開しているCore Rule Set（CRS）を導入すると、SQLインジェクション・XSS・ローカルファイルインクルードなどの一般的な攻撃パターンを幅広くカバーできます。

# OWASP CRS のインストール（RHEL系）
sudo dnf install mod_security_crs

# Ubuntu系（パッケージ名が異なる場合は GitHubから直接取得）
# sudo apt install modsecurity-crs

fail2banとの連携でブルートフォース対策を強化する

Apacheのアクセスログをfail2banで監視することで、同一IPから大量のエラーが発生した場合に自動でアクセスをブロックできます。

# /etc/fail2ban/jail.local に以下を追記
[apache-auth]
enabled  = true
port     = http,https
filter   = apache-auth
logpath  = /var/log/httpd/error_log
maxretry = 5
bantime  = 3600

[apache-badbots]
enabled  = true
port     = http,https
filter   = apache-badbots
logpath  = /var/log/httpd/access_log
maxretry = 2
bantime  = 86400

SELinuxとApacheの連携を整理する

RHEL系LinuxでSELinuxが有効な環境では、ApacheがアクセスできるディレクトリやポートをSELinuxのポリシーで制御します。SELinuxの基本設定と合わせて確認しておくべきポイントを示します。

# SELinuxのコンテキスト確認: Webコンテンツは httpd_sys_content_t が正しい
ls -lZ /var/www/html/

# ファイルのコンテキストが間違っている場合は修正
sudo chcon -R -t httpd_sys_content_t /var/www/html/

# 恒久的な修正（restoreconで上書きされないように）
sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -Rv /var/www/html/

SELinuxをPermissiveモードにして一時的に問題を回避する対処は、セキュリティ上の穴を開けることになるため避けてください。audit2allowを使ってポリシーを追加する正攻法で対処します。

中小企業でも今日からできること

全ての設定を一度に導入するのが難しい場合、優先度順に対応を進めましょう。

・最優先（即日対応）: ServerTokens Prod・ServerSignature Off でバージョン情報を隠す
・優先度高（1週間以内）: セキュリティヘッダーの設定（X-Frame-Options・X-Content-Type-Options・HSTS）
・優先度高（1週間以内）: ディレクトリリスティングの無効化とファイルアクセス制限
・優先度中（1ヶ月以内）: mod_securityの導入（DetectionOnlyで開始）
・優先度中（1ヶ月以内）: 不要モジュールの無効化
・優先度低（定期対応）: Lynis等のセキュリティ監査ツールで定期チェック

設定変更後は必ずApacheの構文チェックを行ってから再起動します。

# 設定ファイルの構文チェック（エラーがあれば詳細を表示）
sudo apachectl configtest

# 問題なければ再起動
sudo systemctl restart httpd  # RHEL系
# sudo systemctl restart apache2  # Ubuntu系

セキュリティ監査ツールのLynisを使うと、Apache設定の弱点を自動でチェックしてくれます。定期的な監査サイクルの中に組み込むと効果的です。

よくある誤解と注意点

「バージョンを隠せば完全に安全」は誤り
ServerTokensの変更は「情報を渡さない」対策であり、根本的な脆弱性をなくすわけではありません。Apacheのアップデートを継続することが最重要です。パッチ管理の基本サイクルと合わせて運用しましょう。

「HTTPSにすれば全部解決」は誤り
TLS化でも通信の暗号化だけです。HSTSの設定・セキュリティヘッダー・アクセス制御は別途必要です。

「.htaccessに書けば安全」も誤り
.htaccessはAllowOverrideで許可されていれば確かに設定を追加できますが、httpd.confに集約した方が管理しやすく、処理のオーバーヘッドも少ないです。AllowOverride Noneに設定してhttpd.confで一元管理することを推奨します。

HSTS設定は慎重に
HSTSを有効にすると、設定期間中はブラウザがHTTPS以外でのアクセスを拒否します。HTTPSが確実に動作していることを確認してから有効にしてください。間違えると自分でアクセスできなくなります。

本記事のまとめ

Apache単体の設定変更だけで、攻撃者に渡せる情報量を大幅に減らし、一般的なWeb攻撃の多くをブロックできます。まずはバージョン情報の非表示とセキュリティヘッダーの設定から着手し、mod_securityへと段階的に強化していきましょう。Linuxサーバーのセキュリティ設定全般については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。