Debian 12 または 11 に Apache で ModSecurity 2 をインストールする方法

最終更新日: 2024年9月17日 午前11時06分 投稿者: Joshua James
推定読了時間: 14 分
Debian 12 または 11 に Apache で ModSecurity 2 をインストールする方法

ModSecurity 2 は、Apache HTTP サーバーを保護するために不可欠な Web アプリケーション ファイアウォール (WAF) であり、リアルタイムの監視とルールベースのフィルタリングを提供します。Debian 12 または 11 Linux サーバーにインストールされた ModSecurity は、SQL インジェクション、クロスサイト スクリプティング (XSS)、およびその他の攻撃の防止に役立ちます。Digitalwave ModSecurity リポジトリはインストールを簡素化し、最新の安定したバージョンを使用することを保証します。

セキュリティを強化するために、OWASP Core Rule Set (CRS) は、一般的な脆弱性をターゲットにした事前設定されたルールを提供します。これを設定することで、管理者は最小限の手動設定で防御を強化できます。このガイドでは、Digitalwave リポジトリを使用して Debian に ModSecurity 2 をインストールし、最適な保護のために OWASP CRS を設定する方法を説明します。

ModSecurity 2 インストール用の Debian システム パッケージを更新する

最初のステップは、Debian システムが更新されていることを確認することです。これにより、既存のすべてのパッケージが最新の状態に保たれ、最適なパフォーマンスが確保され、セキュリティ リスクが最小限に抑えられます。これを実現するには、次のコマンドを実行します。

sudo apt update && sudo apt upgrade

システムを更新した後、Apache がインストールされているかどうかを確認します。インストールされていない場合は、次のコマンドを使用してインストールします。

sudo apt install apache2

ModSecurity モジュール PPA をインポートする

必要なリポジトリの設定

次のタスクは、ModSecurity Apache モジュールをインストールすることです。Debian のデフォルト リポジトリで利用できるバージョンは最新ではない可能性があり、それを使用するとすぐにエラーが発生する可能性があります。代わりに、サードパーティのリポジトリをインポートして、Apache 用の最新の ModSecurity モジュールをインストールします。Digitalwave によって管理されているこのサードパーティのリポジトリは、安定したバイナリで有名です。

まず、必要なパッケージのセットをインストールします。

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

次に、ModSecurity 2モジュールPPAリポジトリをインポートします。 GPGキー:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

GPG キーを取得したら、リポジトリをシステムに追加します。

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

新しい Apache モジュール PPA リポジトリの優先順位付け

リポジトリを配置したら、ModSecurity に関連する特定のパッケージに対してこのリポジトリを優先するように APT ポリシーを調整する必要があります。これは、次のコマンドで実行できます。

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

次に、新しくインポートされたソースを反映するために APT アップデートを実行します。

sudo apt update

さらに、設定を確認するには、次の方法でこのポリシーの変更を確認できます。

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3
Debian Linux 上の Apache で ModSecurity 2 の PPA を追加する
Digitalwave PPA を追加して Debian の Apache に ModSecurity 2 をインストールする

ModSecurity 2 モジュールをインストールする

リポジトリの準備ができたので、libapache2-mod-security2 モジュールのインストールに進みます。

sudo apt install libapache2-mod-security2

インストール後、モジュールを有効にする必要があります。これを行うには、次のコマンドを使用します。

sudo a2enmod security2

Apache サービスの再起動

最後に、すべての変更が有効になり、新しく追加された ModSecurity モジュールが正しく統合されていることを確認するために、Apache サービスを再起動します。

sudo nano /etc/apache2/mods-enabled/security2.conf

Apache HTTP で ModSecurity 2 モジュールを有効にする

ModSecurity 構成ファイルへのアクセス

Apache ModSecurity の設定ファイルは、/etc/apache2/mods-enabled/security2.conf にあります。nano テキスト エディター (またはお好みのテキスト エディター) を使用して、次のコマンドでこのファイルにアクセスします。

sudo nano /etc/apache2/mods-enabled/security2.conf

次の行を探します:

IncludeOptional /etc/modsecurity/*.conf

この行には /etc/modsecurity ディレクトリのその他の必要な設定ファイルが含まれているため、必ずコメントを解除してください。デフォルトではコメントが解除されているはずです。

Debian 上の Apache の ModSecurity 設定行のコメント解除
Debian の Apache 設定で必要な ModSecurity 行のコメントを解除する

ModSecurity 2 構成の変更

アクティブにするには、modsecurity.conf 推奨構成ファイルの名前を modsecurity.conf に変更する必要があります。これは次のコマンドで実行できます。

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

次に、新しく名前が付けられた構成ファイルを開きます。

sudo nano /etc/modsecurity/modsecurity.conf

このファイル内では、ModSecurity ルール エンジンはデフォルトで DetectionOnly に設定されています。つまり、潜在的に悪意のある動作をブロックせずに識別してログに記録します。これを変更して ModSecurity のブロック機能を有効にするには、SecRuleEngine 行 (7 行目付近) を見つけて、DetectionOnly を On に置き換えます。

から：

SecRuleEngine DetectionOnly

に：

SecRuleEngine On
Debian 上の Apache で ModSecurity 2 の検出エンジンを切り替える
Debian 上の Apache の ModSecurity 検出エンジンを切り替える

Apache のログ設定の調整

構成ファイルのさらに下には、SecAuditLogParts 行 (行 224 付近) があります。この行のデフォルト設定は正確ではありません。すべてのトランザクション情報を正確に記録するには、調整する必要があります。

変化：

SecAuditLogParts ABDEFHIJZ

に：

SecAuditLogParts ABCEFHJKZ

これらの変更を行ったら、変更を保存してエディターを終了します。

Debian 上の Apache で ModSecurity 2 のエンジン ログ部分を変更する
Debian の Apache 上の ModSecurity 2 のエンジン ログ部分を調整する

変更を適用するためにApacheを再起動する

このプロセスの最後のステップは、ModSecurity 構成の変更を有効にするために Apache サービスを再起動することです。これは、次のコマンドを使用して実行します。

sudo systemctl restart apache2

ModSecurity2 用の OWASP コア ルール セットをインストールする

ModSecurity だけでは、Web サーバーを保護できません。潜在的な脅威を特定し、悪意のあるアクティビティをブロックするには、ルール セットが必要です。OWASP (Open Web Application Security Project) Core Rule Set (CRS) は、さまざまな Web サーバーや Web アプリケーション ファイアウォール (WAF) で使用されている、高く評価されているルール セットです。このルール セットを導入すると、インターネット上で発生するさまざまな脅威に対してサーバーを強力に保護できます。

先に進む前に、OWASP CRSの最新バージョンがインストールされていることを確認することが重要です。 OWASP リリース タグ ページこの手順により、サーバーに最新のセキュリティ対策をダウンロードしてインストールできるようになります。

OWASP CRS の親ディレクトリの作成

まず、mkdir コマンドを使用して、OWASP の主要な親ディレクトリを作成しましょう。

sudo mkdir /etc/apache2/modsec/

Debian で OWASP CRS アーカイブをダウンロード

次に、wget コマンドを使用して、執筆時点での安定バージョンである OWASP CRS 3.3.4 アーカイブを取得します。前述のリンクを使用してバージョンを確認する必要があることに注意してください。

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

ナイトリービルドでは、より最新のセキュリティ対策が提供される場合がありますが、開発段階のため問題が発生する可能性があります。新規ユーザーの場合は、潜在的な問題を回避するために安定バージョンを使用することをお勧めします。

注: 常に更新を確認する必要があります。安定したルールは毎週ではなく、四半期ごとに、または緊急の更新が必要な場合を除き変更されます。

アーカイブの抽出

アーカイブをダウンロードしたら、先ほど作成したディレクトリに解凍します。

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

ダウンロードした OWASP CRS のバージョンに応じてコマンドを変更することを忘れないでください。

ルールセットの設定

OWASP CRS にはサンプル構成ファイルがあり、元のファイルをバックアップとして保持しながら名前を変更する必要があります。これは、「cp コマンド」を使用して実行できます。

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

注: /coreruleset-3.3.4/ を、選択した OWASP CRS の正確なバージョンに置き換えることを忘れないでください。

ルールを有効にする

ルールを有効にするには、/etc/apache2/mods-enabled/security2.conf ファイルを開きます。

sudo apt install unzip -y

次に、次の 2 行を挿入します。

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

注: ダウンロードする coreruleset はガイドの例よりも新しい可能性が高いため、/coreruleset-3.3.4/ を選択した OWASP CRS の正確なバージョンに置き換えてください。

さらに、次の行をコメントアウトまたは削除します。

IncludeOptional /usr/share/modsecurity-crs/*.load

完了したら、ファイルを保存して終了します。

Debian 上の Apache を使用して ModSecurity 2 に OWASP コア ルール セットを追加する
セキュリティ強化のため、Apache の ModSecurity 2 に OWASP コア ルール セットを追加する

変更を適用するためにApacheを再起動する

最後のステップは、変更を有効にするために Apache サービスを再起動します。

sudo systemctl restart apache2

OWASP コア ルール セットと ModSecurity 2 の使用開始

OWASP コア ルール セット (CRS) は、多数のカスタマイズ可能なオプションを備えた包括的なツールです。デフォルト構成では、本物の訪問者や検索エンジン最適化 (SEO) ボットに影響を与えることなく、ほとんどのサーバーのセキュリティを即座に強化できます。このセクションでは CRS の重要な側面をいくつか説明しますが、構成ファイルを調べて利用可能なすべてのオプションを完全に理解することは常に有益です。

CRS 構成の調整

まず、crs-setup.conf ファイルを開いて、CRS 設定のほとんどを変更します。

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

CRS スコアリング システムを理解する

ModSecurity は 2 つの異なるモードで動作します。

  • 異常スコアリング モード: ほとんどのユーザーに推奨されるこのモードでは、ルールが一致するたびに「異常スコア」が割り当てられます。インバウンド ルールとアウトバウンド ルールの両方を処理した後、異常スコアがチェックされ、必要に応じて中断アクションがトリガーされます。このアクションは、多くの場合、403 エラーの形式をとります。このモードでは、正確なログ情報が提供され、ブロック ポリシーをより柔軟に設定できます。
  • 自己完結型モード: このモードでは、ルールが一致するたびにアクションが即座に適用されます。リソース使用量は削減できますが、柔軟性が低く、監査ログの情報量が少なくなります。最初のルールが満たされ、指定されたアクションが実行されると、ルール一致プロセスは停止します。

パラノイアのレベルを理解する

OWASP CRS は、4 つのパラノイア レベルを定義します。

  • パラノイア レベル 1: デフォルトのレベルはほとんどのユーザーに適しています。
  • パラノイア レベル 2: 上級ユーザー向け。
  • パラノイア レベル 3: 上級ユーザー向け。
  • パラノイアレベル 4: 特別な状況でのみ推奨されます。

パラノイア レベルを高くすると、追加のルールが有効になり、セキュリティが強化され、誤検知により正当なトラフィックがブロックされる可能性が高くなります。専門知識とセキュリティのニーズに合ったパラノイア レベルを選択することが重要です。

サーバー上で OWASP CRS をテストする

OWASP CRS がサーバー上で正しく動作していることを確認するには、インターネット ブラウザーを使用して次の URL にアクセスします。「yourdomain.com」を実際のドメインに置き換えることを忘れないでください。

https://www.yourdomain.com/index.html?exec=/bin/bash

403 Forbidden エラーが表示された場合、OWASP CRS は期待どおりに機能します。そうでない場合は、セットアップ プロセスで注意が必要なミスが発生した可能性があります。最も一般的な問題は、DetectionOnly を On などに変更し忘れることです。

OWASP CRS を搭載した ModSecurity 2 が Debian 上の Apache でのテストをブロックする
OWASP CRS を搭載した ModSecurity 2 が Debian の Apache でテスト要求をブロックすることに成功

誤検知とカスタム除外ルールに対処する

ModSecurity と OWASP Core Rule Set (CRS) による誤検知の管理は、継続的な作業になる可能性があります。ただし、これらのシステムはさまざまな脅威に対して強力な防御を提供するため、この作業は不可欠です。誤検知を最小限に抑えるには、まずパラノイア レベルを低く設定することをお勧めします。

数週間または数か月間、低いパラノイア レベルでルール セットを実行すると、膨大な数の誤検知が発生する可能性を減らすことができます。このアプローチにより、徐々にパラノイア レベルを上げてセキュリティを強化する前に、アラートと適切な対応に慣れる時間が得られます。

OWASP、ModSecurity 2 を使用した Debian 上の既知のアプリケーションの誤検知の管理

ModSecurity には、意図せず誤検知を引き起こす可能性のある特定のアクションをホワイトリストに登録する機能が含まれています。例:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

WordPress、phpBB、phpMyAdminなどのアプリケーションのホワイトリストを有効にするには、それぞれの行のコメントを解除し、値（1）を維持します。使用していないサービスのホワイトリスト化を防ぐには、値を（0）に調整します。

更新された構成は次のようになります。

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

この例では、不要なオプションが削除され、必要な構成の正しい構文が残されています。

CRS 実装前のルール除外の作成

カスタム除外を作成するには、まず次のコマンドを使用して「REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf」ファイルの名前を変更します。

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Apache2 サービスのテスト中にエラーが発生しないようにするには、各除外ルールに一意の「idnumber」を設定する必要があることに注意してください。

たとえば、一部の「REQUEST_URI」は誤検知を引き起こす可能性があります。次の例は、Google PageSpeed ビーコンと WordPress の WPMU DEV プラグインに関連する 2 つのケースを示しています。

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

これらのルールは、指定されたパスで始まるすべての URL を自動的に許可します。

特定の IP アドレスをホワイトリストに登録することもできます。

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

最初のルールでは、単一の IP アドレスがホワイトリストに登録されますが、2 番目のルールでは、より広範なサブネットの一致のために '@ipMatch' ディレクティブが使用されます。サブネットまたは IP アドレスをブロックするには、'allow' を 'deny' に置き換えるだけです。この柔軟性により、詳細なブラックリストとホワイトリストを作成でき、これを Fail2Ban と統合してセキュリティ戦略を強化できます。

OWASP、ModSecurity 2 を使用して Debian で特定のルールを無効にする

パス全体をホワイトリストに登録する代わりに、永続的な誤検知を引き起こす特定のルールを無効にするという方法もあります。この方法ではより多くのテストが必要になりますが、長期的なメリットがあります。

たとえば、「/admin/」エリアのルール 941000 と 942999 がチームに対して誤検知をトリガーする場合、ModSecurity ログでルール ID を見つけ、「RemoveByID」コマンドを使用して特定の ID のみを無効にすることができます。

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

ログの監視とパターンの特定

Apache、ModSecurity、OWASP で誤検知を処理する場合、継続的なログ監視が不可欠です。これにより、誤検知を引き起こすパターンを特定し、それらに対処するためのカスタム ルールを作成できます。

たとえば、特定のルールが常に誤検知を引き起こす場合は、これらの特定のインスタンスを処理するための除外ルールを作成できます。このカスタマイズされたアプローチにより、誤検知をより効果的に管理できます。

定期的にログを確認し、ルールを調整することで、アプリケーションのより安全で効率的な環境を維持できます。

ModSecurity 2 のログローテーション

Web トランザクションの動的な性質により、ModSecurity ログは急速に増大する可能性があるため、効果的なログ管理が重要になります。ログ ローテーションはこれらのログを管理するのに便利なツールですが、ModSecurity ではデフォルトで構成されていません。このセクションでは、ModSecurity 専用のログ ローテーションの設定について説明します。

ModSecurity ローテーションファイルの作成

まず、ModSecurity ログローテーション専用のファイルを作成する必要があります。これを行うには、次のコマンドを使用して、modsec という名前の新しいファイルを作成して開きます。

sudo nano /etc/logrotate.d/modsec

ローテーションファイルの設定

新しく作成された ModSecurity (modsec) 構成ファイルに、以下を追加します。

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

この設定では、ログは 31 日間保持されますが、必要に応じて数値を変更できます。たとえば、「rotate 7」に変更すると、代わりに 1 週​​間分のログが保持されます。

「daily」ディレクティブはログが毎日ローテーションされることを保証し、「compress」は古いログを圧縮してスペースを節約します。「delaycompress」オプションは、2 回目のローテーション サイクルまで圧縮を遅らせ、「missingok」はログ ファイルが存在しない場合にエラーを防止します。さらに、「notifempty」は空のログ ファイルがローテーションされないことを保証します。

ヒント: 分析に時間がかかる原因となる、大きすぎるログ ファイルの処理を回避するために、毎日ログをローテーションすることをお勧めします。

結論

これで、Digitalwave リポジトリを使用して Debian 12 または 11 サーバーに ModSecurity 2 をインストールし、OWASP Core Rule Set を構成しました。これらのツールを導入すると、サーバーは多くの一般的な Web アプリケーションの脅威をブロックできるようになります。

CRS を定期的に更新し、誤検知や脆弱性の見逃しがないか監視することを忘れないでください。一貫したテストと調整は、堅牢なセキュリティ設定を維持するための鍵となります。

Joshua James
私に従ってください
Joshua James による最新の投稿 (すべてを見る)

Rocky Linux 9 または 8 に Remi RPM をインストールする方法

コメントを残す


記事の提案など、正当な質問がある場合は、遠慮なく LinuxCapable までご連絡ください。メッセージは必ず英語で記入してください。

お問い合わせ
私たちについて 免責事項 プライバシーポリシー 利用規約