MENU
  1. ホーム
  2. Apache
  3. Apacheでmod_securityを使ったWebアプリケーションファイアウォールの設定方法

Apacheでmod_securityを使ったWebアプリケーションファイアウォールの設定方法

Apache

WebサイトやWebアプリケーションを運用する際、外部からの攻撃や不正アクセスを防ぐことは非常に重要です。特に、SQLインジェクションやクロスサイトスクリプティング（XSS）といった脆弱性を狙った攻撃は年々巧妙化しており、一般的なセキュリティ対策だけでは十分とは言えません。

こうした攻撃からWebアプリケーションを保護するための手段として、Webアプリケーションファイアウォール（WAF）の導入が有効です。WAFはアプリケーションの通信を監視し、不正なリクエストを遮断することで、脆弱性を突く攻撃を防ぎます。

本記事では、Apacheに導入可能なオープンソースのWAFモジュールである「mod_security」を使用して、効果的にWebアプリケーションを防御する方法を解説します。

mod_securityは、OWASP Core Rule Set (CRS) などの強力なルールセットと組み合わせることで、さまざまな攻撃を自動的にブロックできます。インストールから基本設定、カスタムルールの作成方法、さらにパフォーマンス最適化まで、初心者でも理解できるようにステップバイステップで説明します。

この記事を通じて、Apache環境におけるセキュリティ強化の具体的な方法を学び、Webアプリケーションを安全に保護するための知識を身につけましょう。

目次

mod_securityとは


mod_securityは、Apache HTTPサーバー上で動作するWebアプリケーションファイアウォール（WAF）モジュールです。アプリケーションレベルでの不正なリクエストを検知し、遮断することで、Webアプリケーションをさまざまな攻撃から保護します。

mod_securityの役割


mod_securityの主な役割は以下の通りです。

  • リクエストの検査：HTTPリクエストの内容を解析し、SQLインジェクションやクロスサイトスクリプティング（XSS）などの不正なコードを検知します。
  • リアルタイムでのブロック：不正なリクエストをリアルタイムで遮断し、攻撃を未然に防ぎます。
  • ログ記録：攻撃を受けた際の詳細なログを記録し、分析や再発防止に役立てます。

特徴と利点

  1. オープンソース：無料で利用可能であり、幅広いコミュニティによって開発・メンテナンスが行われています。
  2. 高いカスタマイズ性：ルールを自由に作成・変更できるため、特定の脅威に対する防御を強化できます。
  3. OWASP Core Rule Set（CRS）との連携：OWASPが提供するセキュリティルールセットを簡単に導入でき、多くの一般的な脅威からアプリケーションを保護します。
  4. 幅広いプラットフォームで利用可能：Apacheだけでなく、NginxやIISなどでも利用できます。

WAFとしての重要性


Webアプリケーションは公開されているため、攻撃者にとって格好のターゲットとなります。脆弱性が発見されると、瞬時に攻撃が開始される可能性が高いため、アプリケーションの防御は不可欠です。
mod_securityを導入することで、既知の脆弱性だけでなく、未知の脅威にも対応可能なセキュリティ層を構築できます。

Apacheにmod_securityをインストールする方法


Apacheにmod_securityをインストールすることで、Webアプリケーションの防御機能を強化できます。以下では、UbuntuおよびCentOSを例に、mod_securityのインストール手順を説明します。

Ubuntuでのmod_securityインストール

  1. パッケージリストの更新
   sudo apt update
  1. mod_securityのインストール
   sudo apt install libapache2-mod-security2
  1. モジュールの有効化
   sudo a2enmod security2
  1. Apacheの再起動
   sudo systemctl restart apache2


これで、mod_securityがインストールされ、有効になります。

CentOSでのmod_securityインストール

  1. EPELリポジトリの追加
   sudo yum install epel-release
  1. mod_securityのインストール
   sudo yum install mod_security
  1. Apacheの再起動
   sudo systemctl restart httpd

インストール確認方法


インストールが完了したら、以下のコマンドでmod_securityが正しく読み込まれているかを確認します。

sudo apachectl -M | grep security2


security2_module が表示されていれば、mod_securityは正しく動作しています。

次のステップ


インストール後は、初期設定とチューニングが必要です。続くセクションでは、mod_securityの基本設定と推奨設定について解説します。

mod_securityの基本設定


mod_securityをインストールした後は、適切な設定を行うことで効果的に不正アクセスを防ぐことができます。ここでは、mod_securityの初期設定と推奨される基本設定について解説します。

mod_security設定ファイルの場所

  • Ubuntu: /etc/modsecurity/
  • CentOS: /etc/httpd/modsecurity.d/

主要な設定ファイルは modsecurity.conf です。このファイルを編集して、mod_securityの動作をカスタマイズします。

初期設定の手順

  1. 設定ファイルのコピー
    デフォルトの設定ファイルを modsecurity.conf にコピーします。
   sudo cp /usr/share/modsecurity-crs/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
  1. mod_securityを有効化
    modsecurity.conf 内の以下の行を編集し、mod_securityを有効化します。
   SecRuleEngine On
  • On：mod_securityが有効で、リクエストをブロックします。
  • DetectionOnly：攻撃の検知のみ行い、ブロックはしません（テスト時に推奨）。
  1. セキュリティログの設定
    mod_securityのログ出力先を指定します。
   SecAuditEngine RelevantOnly
   SecAuditLog /var/log/modsec_audit.log
  • RelevantOnly：重要なリクエストのみログに記録します。
  • ログファイルのパスは任意で変更可能です。
  1. リクエストサイズ制限
    大きなリクエストは攻撃の温床になる可能性があるため、リクエストボディのサイズ制限を設定します。
   SecRequestBodyLimit 1310720
   SecRequestBodyNoFilesLimit 1048576
  • デフォルトは1MB程度ですが、アプリケーションに応じて調整してください。

設定の反映


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

sudo systemctl restart apache2  # Ubuntu  
sudo systemctl restart httpd    # CentOS

初期設定の確認


Apacheのエラーログや modsec_audit.log を確認し、mod_securityが正しく動作していることを確認します。

次のステップ


次は、OWASP Core Rule Set (CRS) を導入して、より高度なセキュリティルールを適用します。

OWASP Core Rule Set (CRS)の導入


OWASP Core Rule Set (CRS) は、Webアプリケーションを狙う一般的な攻撃から防御するための事前定義されたセキュリティルールセットです。SQLインジェクション、クロスサイトスクリプティング（XSS）、ディレクトリトラバーサルなど、多様な脅威を検知・ブロックするルールが含まれています。mod_securityと組み合わせることで、強力なWAF環境を構築できます。

CRSの特徴と利点

  1. 包括的な防御：一般的なWeb攻撃パターンを幅広くカバーしています。
  2. 容易な導入：インストールして設定するだけで、多くの攻撃に対する防御が可能です。
  3. コミュニティのサポート：OWASPによる継続的なアップデートとサポートが提供されています。
  4. カスタマイズ性：プロジェクトに応じてルールを追加・変更できます。

CRSのインストール手順

1. CRSのダウンロード


公式リポジトリから最新版のCRSをダウンロードします。

cd /usr/share  
sudo git clone https://github.com/coreruleset/coreruleset.git


または、パッケージからインストールする方法もあります。

sudo apt install modsecurity-crs  # Ubuntu  
sudo yum install mod_security_crs  # CentOS

2. ルールセットの配置


ダウンロードしたルールセットをmod_securityのディレクトリにコピーします。

sudo cp -r /usr/share/coreruleset/rules /etc/modsecurity/

3. 設定ファイルの変更


mod_security設定ファイル（/etc/modsecurity/modsecurity.conf）に以下を追加し、CRSを読み込ませます。

Include /etc/modsecurity/rules/*.conf

4. 初期設定ファイルのコピー

sudo cp /usr/share/coreruleset/crs-setup.conf.example /etc/modsecurity/crs-setup.conf


これにより、CRSの基本設定が反映されます。

Apacheへの適用と動作確認


設定が完了したら、Apacheを再起動して反映させます。

sudo systemctl restart apache2  # Ubuntu  
sudo systemctl restart httpd    # CentOS

次に、mod_securityのログを確認し、CRSが正しく適用されていることを確認します。

sudo tail -f /var/log/modsec_audit.log

次のステップ


CRSを導入したら、次はカスタムルールの作成や特定の攻撃に対するチューニングを行い、さらにセキュリティレベルを向上させましょう。

カスタムルールの作成と適用


OWASP Core Rule Set (CRS) だけでなく、独自のカスタムルールを追加することで、特定の攻撃やアプリケーション固有の脆弱性に対処できます。mod_securityでは、ルールを柔軟に作成・適用できるため、セキュリティポリシーを強化できます。

カスタムルールの基本構造


mod_securityのルールは、SecRuleディレクティブを使用して記述します。以下は基本的な構文です。

SecRule VARIABLES "OPERATOR" "ACTIONS"
  • VARIABLES：リクエストやレスポンスの対象（例：REQUEST_URI, ARGS）
  • OPERATOR：マッチ条件（例：@rxは正規表現）
  • ACTIONS：ルールが一致した際の動作（例：deny、log）

例：SQLインジェクションの簡易検知ルール

SecRule ARGS "@rx select.*from" "id:1001,phase:2,deny,status:403,msg:'SQL Injection Detected'"
  • 説明：リクエストパラメータ（ARGS）内にselect fromが含まれている場合、403エラーを返してリクエストを拒否します。
  • id:1001：ルールの識別子（ルール管理のために必須）
  • phase:2：リクエストの処理段階（2はリクエストボディの解析段階）

カスタムルールの適用方法

1. カスタムルールファイルの作成


以下のようにカスタムルール用のファイルを作成します。

sudo nano /etc/modsecurity/custom_rules.conf

2. ルールの追加


ファイル内に独自ルールを記述します。

# XSS攻撃検知ルール
SecRule ARGS "@rx <script>" "id:1002,phase:2,deny,status:403,msg:'XSS Attack Detected'"

# SQLインジェクション対策
SecRule ARGS "@rx union.*select" "id:1003,phase:2,deny,status:403,msg:'SQL Injection Detected'"

3. Apache設定ファイルへの追加


mod_securityの設定ファイルに、作成したルールファイルを読み込む記述を追加します。

Include /etc/modsecurity/custom_rules.conf

4. 設定の反映


Apacheを再起動してルールを反映します。

sudo systemctl restart apache2  # Ubuntu  
sudo systemctl restart httpd    # CentOS

ルールの検証


ブラウザやコマンドラインからテストリクエストを送信し、ルールが正しく適用されているかを確認します。

curl http://example.com/?param=<script>


403エラーが返ればルールが正しく動作しています。

次のステップ


カスタムルールを定期的に見直し、必要に応じてログ解析やルールのチューニングを行うことで、より高度なセキュリティ対策が可能になります。

ログの分析とチューニング方法


mod_securityは、不正なリクエストを検出・ブロックするだけでなく、詳細なログを記録します。これにより、攻撃パターンの分析や誤検知（False Positive）の修正が可能になります。ログの正確な分析とチューニングを行うことで、セキュリティと利便性のバランスを最適化できます。

mod_securityログの種類


mod_securityは主に以下の2種類のログを出力します。

  • エラーログ（/var/log/apache2/error.log または /var/log/httpd/error_log）：mod_securityがブロックしたリクエストや設定エラーが記録されます。
  • 監査ログ（/var/log/modsec_audit.log）：リクエストの詳細な情報が記録され、攻撃のトレースが可能です。

監査ログの形式


監査ログは以下のような形式で記録されます。

---d6a4df8c-B---  
[28/Dec/2024:12:45:32 +0900] W3 example.com 192.168.0.1 12345  
GET /index.php?id=<script> HTTP/1.1  
Host: example.com  
---d6a4df8c-H---  
Message: Warning. Pattern match "<script>" at ARGS:id. [id "1002"] [msg "XSS Attack Detected"]  
Apache-Handler: application/x-httpd-php  
Action: Intercepted (phase 2)
  • Bセクション：リクエストの概要
  • Hセクション：攻撃検知の詳細（どのルールが適用されたか）

ログの分析方法

1. エラーログの確認


mod_securityがブロックしたリクエストの概要を確認します。

sudo tail -f /var/log/apache2/error.log


または

sudo tail -f /var/log/httpd/error_log

2. 監査ログの詳細確認


監査ログでブロックされたリクエストの詳細を確認します。

sudo cat /var/log/modsec_audit.log | grep --context=5 "Message"

誤検知の対処方法

1. 誤検知を確認


監査ログのmsg（メッセージ）やid（ルールID）を確認し、正当なリクエストが誤検知されていないかを確認します。

2. ルールの除外（ホワイトリスト化）


誤検知が発生したルールを除外することで、正当なリクエストを通過させることができます。

SecRuleRemoveById 1002


modsecurity.conf または custom_rules.conf に追加します。

3. 特定のパスでのみルールを無効化


以下のように、特定のURLでのみルールを無効化することも可能です。

<Location /safe-path>  
    SecRuleRemoveById 1002  
</Location>

ルールのチューニング

1. チューニング対象の特定


ログを分析し、頻繁にブロックされるルールを特定します。

2. ルールの緩和


検知のみでブロックしない設定に変更できます。

SecRule ARGS "@rx select.*from" "id:1001,phase:2,log,pass,msg:'SQL Injection Detected (Monitoring Only)'"

Apache再起動


ルールを変更したらApacheを再起動して反映します。

sudo systemctl restart apache2  # Ubuntu  
sudo systemctl restart httpd    # CentOS

次のステップ


ログの分析とチューニングを繰り返し行い、誤検知を減らしつつ攻撃を効果的に防御できる環境を構築します。次は、パフォーマンスへの影響と最適化について解説します。

パフォーマンスへの影響と最適化


mod_securityは強力なセキュリティ機能を提供しますが、すべてのリクエストを解析するため、Webサーバーのパフォーマンスに影響を与える可能性があります。ここでは、パフォーマンス低下を防ぎつつ、mod_securityを効率的に運用するための最適化方法を解説します。

パフォーマンス低下の要因

  1. ルールの過剰適用：不要なルールが多数適用されると、処理コストが増加します。
  2. 大きなリクエストの解析：ファイルアップロードや大量のPOSTデータは、mod_securityの処理負荷を増大させます。
  3. ログ出力の頻度：すべてのリクエストを詳細に記録すると、ディスクI/Oが増加します。

最適化の方法

1. 不要なルールの無効化


OWASP CRSには多くのルールが含まれますが、アプリケーションに関係のないルールは無効化することでパフォーマンスを向上させることができます。

SecRuleRemoveById 920230 920240


上記の例では、特定のルールIDを無効化しています。

2. 重要なルールのみ適用


最も脅威の高い攻撃（SQLインジェクションやXSSなど）のみを対象にするルールセットを作成します。

SecRuleEngine On
Include /etc/modsecurity/crs-setup.conf
Include /etc/modsecurity/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
Include /etc/modsecurity/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf


SQLインジェクションとXSSのルールセットだけを有効にしています。

3. リクエストサイズの制限


大規模なファイルアップロードやリクエストがmod_securityに過剰な負荷をかける可能性があります。サイズ制限を設定し、過大なリクエストをブロックします。

SecRequestBodyLimit 1048576  # 1MB
SecRequestBodyNoFilesLimit 512000  # 500KB


ファイルを伴わないリクエストのボディサイズを500KBに制限します。

4. リクエストの段階的解析


処理を段階的に行うことで、早期に不正なリクエストを検出し、無駄な処理を省きます。

SecRuleEngine On
SecDefaultAction "phase:1,log,auditlog,pass"
SecRule ARGS "@rx select.*from" "id:1005,phase:2,deny,status:403,msg:'SQL Injection Detected'"
  • phase:1で軽いチェックを行い、phase:2で本格的な解析を実施します。

5. ログレベルの調整


すべてのリクエストを記録するとディスクI/Oが増加します。必要なリクエストのみログに記録することで負荷を軽減します。

SecAuditEngine RelevantOnly
SecAuditLogParts ABIJDEFHZ
  • RelevantOnly：攻撃とみなされたリクエストのみログに記録します。

チューニング例


特定のURIに対してのみmod_securityを適用する設定です。パフォーマンスの重要なページにはmod_securityを適用せず、管理画面などに限定します。

<LocationMatch "/admin">
    SecRuleEngine On
</LocationMatch>

<LocationMatch "/static">
    SecRuleEngine Off
</LocationMatch>


これにより、/admin ではmod_securityが有効ですが、/static では無効になります。

Apacheの再起動


設定後はApacheを再起動して変更を適用します。

sudo systemctl restart apache2  # Ubuntu  
sudo systemctl restart httpd    # CentOS

次のステップ


パフォーマンスを維持しながらセキュリティを最大化するには、ルールの見直しやログの分析を定期的に行うことが重要です。次は、実践例としてmod_securityを活用した攻撃防御シナリオを紹介します。

実践例：mod_securityを使った攻撃防御シナリオ


ここでは、実際の攻撃シナリオを例に、mod_securityがどのように不正アクセスや脆弱性攻撃を防ぐのかを解説します。SQLインジェクションやクロスサイトスクリプティング（XSS）、ディレクトリトラバーサルといった代表的な攻撃に対する防御例を紹介します。

シナリオ1：SQLインジェクションの防御


攻撃例：
攻撃者が以下のようなリクエストを送信し、データベースを操作しようとします。

http://example.com/login.php?user=admin' OR '1'='1


目的：パスワードを知らなくても、1=1が常に真となることで不正ログインを試みます。

mod_securityルール：

SecRule ARGS "@rx select.*from" \
    "id:1001,phase:2,deny,status:403,msg:'SQL Injection Detected'"
  • ARGSはリクエストパラメータを対象とし、select fromが含まれるリクエストを拒否します。

結果：
攻撃リクエストは403エラーを返し、ログに以下のように記録されます。

Message: Warning. Pattern match "select.*from" at ARGS:user. [id "1001"] [msg "SQL Injection Detected"]

シナリオ2：クロスサイトスクリプティング（XSS）の防御


攻撃例：
攻撃者がユーザーのブラウザで任意のスクリプトを実行しようとします。

http://example.com/profile.php?name=<script>alert('XSS')</script>


目的：悪意のあるスクリプトを埋め込み、クッキーの盗難やフィッシングを行います。

mod_securityルール：

SecRule ARGS "@rx <script>" \
    "id:1002,phase:2,deny,status:403,msg:'XSS Attack Detected'"
  • <script>タグが含まれるリクエストを検知し、拒否します。

結果：
攻撃者はスクリプトの埋め込みに失敗し、エラーが記録されます。

Message: Warning. Pattern match "<script>" at ARGS:name. [id "1002"] [msg "XSS Attack Detected"]

シナリオ3：ディレクトリトラバーサルの防御


攻撃例：
攻撃者がサーバー内の任意のファイルを読み取ろうとします。

http://example.com/download.php?file=../../etc/passwd


目的：サーバーの重要なシステムファイル（例：/etc/passwd）を閲覧し、認証情報を盗み出します。

mod_securityルール：

SecRule ARGS "@rx \.\./" \
    "id:1003,phase:2,deny,status:403,msg:'Directory Traversal Attack Detected'"
  • ../が含まれるパスを検出し、不正なファイルアクセスを防ぎます。

結果：
リクエストは403エラーで拒否され、ログに記録されます。

Message: Warning. Pattern match "\.\./" at ARGS:file. [id "1003"] [msg "Directory Traversal Attack Detected"]

シナリオ4：ブルートフォース攻撃の防御


攻撃例：
攻撃者が何度もログイン試行を繰り返し、認証突破を試みます。

http://example.com/login.php?user=admin&pass=1234


目的：大量のパスワードリストを用いて不正ログインを試みます。

mod_securityルール：

SecRule ARGS_NAMES "@streq pass" "id:1004,phase:2,track:'ip',block,status:403,msg:'Brute Force Attack Detected'"
  • 一定回数ログインを試行したIPアドレスをブロックします。

効果的な運用ポイント

  1. ルールのチューニング：不要なルールを無効化し、誤検知を減らす。
  2. ログ分析：監査ログを定期的に確認し、新たな攻撃手法に対応する。
  3. 例外設定：誤検知が発生した場合は特定のルールを無効化し、必要に応じてルールを緩和する。

次のステップ


これらの防御例を参考に、自社アプリケーションに特化したカスタムルールを作成し、Webアプリケーションのセキュリティをさらに強化しましょう。次は、記事のまとめを行います。

まとめ


本記事では、Apacheでmod_securityを使ったWebアプリケーションファイアウォール（WAF）の設定方法について解説しました。

mod_securityは、SQLインジェクションやXSSなどの多様な攻撃からWebアプリケーションを保護する強力なツールです。OWASP Core Rule Set (CRS) を導入することで、既知の脆弱性に対する包括的な防御が可能になります。さらに、カスタムルールの作成やログの分析を通じて、アプリケーションに特化したセキュリティ強化が図れます。

主なポイントは以下の通りです。

  • mod_securityのインストールと基本設定
  • CRSの導入と適用
  • SQLインジェクションやXSSなどの攻撃シナリオに対する防御例
  • 誤検知の対応とパフォーマンスの最適化

Webセキュリティは継続的な監視とチューニングが不可欠です。定期的にログを確認し、ルールの見直しやチューニングを行うことで、安全なWebアプリケーション環境を維持できます。

mod_securityを活用して、攻撃に強い堅牢なWebアプリケーションを構築しましょう。

Apache
Apache WAF mod_security Webアプリケーションファイアウォール

コメント

コメントする

目次