Debian/UbuntuでNginxを使用してModSecurityを設定する方法

このチュートリアルでは、 ModSecurityをインストールして使用する方法を説明します。 Debian/Ubuntuサーバー上のNginxを使用します。 ModSecurityは、最もよく知られているオープンソースのWebアプリケーションファイアウォールです。 （WAF）、SQLインジェクション、クロスサイトスクリプティング、ローカルファイルインクルードなどの幅広いレイヤー7（HTTP）攻撃に対して、Webアプリケーション（WordPress、Nextcloud、Ghostなど）を包括的に保護します。
>

注 ：このチュートリアルは、Debian 10、Ubuntu 18.04、Ubuntu 20.04、Ubuntu 20.10を含む、現在のすべてのDebianおよびUbuntuバージョンで機能します。

Webアプリケーションは本質的に安全ではありません。 WordPressの管理者であれば、ハッカーがWordPressのプラグインやテーマの脆弱性を悪用しているというニュースをたまに聞くでしょう。特に更新を受け取らない古いアプリケーションがある場合は、WebサーバーにWAFをデプロイすることが不可欠です。 ModSecurityは、もともと2002年にIvanRistićによって作成され、現在はTrustwaveSpiderLabsによって保守されています。これは、世界で最も広く展開されているWAFであり、100万を超えるWebサイトで使用されています。最も広く使用されているホスティングコントロールパネルであるcPanelには、WAFとしてModSecurityが含まれています。

iptables、UFW、Firewalldなどの他のホストベースのファイアウォールを聞いたことがあるかもしれません。違いは、OSIモデルのレイヤー3と4で動作し、IPアドレスとポート番号に基づいてアクションを実行することです。 ModSecurity、または一般にWebアプリケーションファイアウォールは、HTTPトラフィック（OSIモデルのレイヤー7）に焦点を当てることに特化しており、HTTP要求と応答のコンテンツに基づいてアクションを実行します。

ModSecurity 3

ModSecurityは、もともとApacheWebサーバー用に設計されました。バージョン3.0より前のNginxで動作する可能性がありましたが、パフォーマンスが低下していました。 ModSecurity 3.0（別名 libmodsecurity ）は2017年にリリースされました。これは、Nginxでネイティブに動作する最初のバージョンであるため、特にNginxユーザーにとって画期的なリリースです。 ModSecurity 3の注意点は、以前のバージョン（2.9）のようにまだすべての機能を備えていないことですが、新しいリリースごとに不足している機能の一部が追加されます。

ステップ1：最新バージョンのNginxをDebian/Ubuntuにインストールする

ModSecurityは動的モジュールとしてNginxと統合されているため、Nginx自体をコンパイルせずに個々のモジュールのソースコードをコンパイルできます。

Nginxバイナリは、-with-compatを使用してコンパイルする必要があります 引数。これにより、動的モジュールが既存のNginxバイナリとバイナリ互換になります。ただし、デフォルトのDebian / Ubuntuリポジトリから出荷されたすべてのNginxバイナリが、-with-compatでコンパイルされているわけではありません。 口論。作業を簡単にするために、 ondrej / nginx-mainlineから最新バージョンのNginxをインストールできます。 PPA。Debian開発者によって管理されています。

注 ：nginx.orgリポジトリは、最新バージョンのNginxも提供します。ただし、 ondrej / nginx-mainline PPAは、Brotliモジュールなど、役立つと思われる追加の動的モジュールを提供します。

Ubuntu

Ubuntu 16.04、18.04、20.04、または20.10を使用している場合は、次のコマンドを実行して最新バージョンのNginxをインストールします。

sudo add-apt-repository ppa:ondrej/nginx-mainline -y
sudo apt update
sudo apt install nginx-core nginx-common nginx nginx-full

インストールプロセス中に、パッケージディストリビューターがメイン構成ファイルの更新バージョンを出荷したことを通知する場合があります。 nを押すことをお勧めします 現在のバージョンを保持します。後でいつでも違いを調べることができます。

デフォルトでは、バイナリリポジトリのみが有効になっています。また、Nginxソースコードをダウンロードするには、ソースコードリポジトリを有効にする必要があります。 Nginxメインラインリポジトリファイルを編集します。

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

＃deb-srcで始まる行を見つけます 。

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main

＃を削除します このソースコードリポジトリを有効にする文字。

deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main

ファイルを保存して閉じます。次に、リポジトリインデックスを更新します。

sudo apt update

Debian

Debian10またはDebian11を使用している場合は、次のコマンドを実行して最新バージョンのNginxをインストールします。

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x
sudo apt update 
sudo apt install nginx-core nginx-common nginx nginx-full

インストールプロセス中に、パッケージディストリビューターがメイン構成ファイルの更新バージョンを出荷したことを通知する場合があります。 nを押すことをお勧めします 現在のバージョンを保持します。後でいつでも違いを調べることができます。

デフォルトでは、バイナリリポジトリのみが有効になっています。また、Nginxソースコードをダウンロードするには、ソースコードリポジトリを有効にする必要があります。 Nginxメインラインリポジトリファイルを編集します。

sudo nano /etc/apt/sources.list.d/nginx-mainline.list

Nginxバイナリリポジトリを有効にする1行が見つかります。次の行を追加して、Debian10でNginxソースコードリポジトリを有効にします。

deb-src https://packages.sury.org/nginx-mainline/ buster main

Debian 11を使用している場合は、代わりに次の行を追加してください。

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

ファイルを保存して閉じます。次に、リポジトリインデックスを更新します。

sudo apt update

Nginx構成引数の確認

次に、次のコマンドを使用してNginxのconfigure引数を確認します。

sudo nginx -V

PPA内のすべてのNginxバイナリは、-with-compatでコンパイルされます。 引数。

ステップ2：Nginxソースパッケージをダウンロードする

Nginx自体をコンパイルする必要はありませんが、ModSecurity動的モジュールをコンパイルするにはNginxソースコードパッケージが必要です。次のコマンドを実行して、 nginxを作成します / usr / local / src /の下のディレクトリ Nginxソースコードパッケージを保存します。 usernameを置き換えます 実際のユーザー名で。

sudo chown username:username /usr/local/src/ -R 

mkdir -p /usr/local/src/nginx

Nginxソースディレクトリにcdします。

cd /usr/local/src/nginx/

以下のコマンドを使用してNginxソースパッケージをダウンロードします：

sudo apt install dpkg-dev

apt source nginx

次の警告メッセージが表示された場合は、無視しても問題ありません。

W: Download is performed unsandboxed as root as file 'nginx_1.19.5.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

ダウンロードしたソースコードファイルを確認してください。

ls

サンプル出力：

nginx-1.19.5
nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz
nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dsc
nginx_1.19.5.orig.tar.gz

ソースコードのバージョンがNginxバイナリバージョンと同じであることを確認してください（ sudo nginx -v 。

ステップ3：libmodsecurity3をインストールする

libmodsecurrity WebアプリケーションのHTTPフィルタリングを実際に実行するModSecurityライブラリです。 Debian10およびUbuntu20.04、20.10では、 sudo apt install libmodsecurity3を使用してインストールできます。 、ただし、ソースからコンパイルすることをお勧めします。

libmodsecurityをコンパイルするには 、最初にGithubからソースコードのクローンを作成します。

sudo apt install git

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

cd /usr/local/src/ModSecurity/

ビルドの依存関係をインストールします。

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen

必要なサブモジュールをインストールします。

git submodule init

git submodule update

ビルド環境を構成します。

./build.sh 

./configure

次のエラーが表示された場合は、無視してかまいません。

fatal: No names found, cannot describe anything.

次のコマンドでソースコードをコンパイルします。デフォルトでは、 make 1つのCPUコアのみを使用します。サーバーに4つのCPUコアがあるので、4つのジョブを指定します（ -j4 ） makeの場合 コンパイルプロセスをスピードアップします。 4を変更します 独自のCPUコア数に。

make -j4

makeの後 コマンドはエラーなしで終了しました。バイナリをインストールしてください。

sudo make install

/ usr / local / modsecurity /の下にインストールされます ディレクトリ。

コンパイルエラーのトラブルシューティング

エラー＃1

makeの実行中に次のエラーが表示された場合 コマンド、サーバーのRAMが不足している可能性があります。

g++: internal compiler error: Killed (program cc1plus)

/ var / log / syslogの次の行 ファイルはサーバーのメモリが不足していることを示しているため、サーバーの仕様をアップグレードすることを検討してください。

または、スワップスペースを作成して、メモリ不足の問題を解決することもできます。ただし、これは一時的な手段としてのみ使用する必要があります。 SSDサーバーでスワップスペースを使用すると、システムパフォーマンスに悪影響を与える可能性があります。

エラー＃2

ModSecurityのコンパイル時に次のエラーが表示された場合

utils/geo_lookup.cc: In member function ‘bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function<bool(int, const std::__cxx11::basic_string<char>&)>) const’:
utils/geo_lookup.cc:124:32: error: invalid conversion from ‘const MMDB_s*’ to ‘MMDB_s*’ [-fpermissive]
r = MMDB_lookup_string(&mmdb, target.c_str(), &gai_error, &mmdb_error);

古いバージョンのlibmaxminddb-devをインストールしたことが原因である可能性があります 。このパッケージは削除できます。

sudo apt remove libmaxminddb-dev

そして、 libgeoip-devをインストールします 、これは libmaxminddb-devの代替です 。

sudo apt install libgeoip-dev

次に、ModSecurityを再コンパイルします。

make clean

./configure

make -j4

バイナリをインストールします。

sudo make install

ステップ4：ModSecurityv3Nginxコネクタのソースコードをダウンロードしてコンパイルする

ModSecurityNginxコネクタ リンクlibmodsecurity NginxWebサーバーに接続します。 ModSecurity v3 NginxConnectorGitリポジトリのクローンを作成します。

git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Nginxソースディレクトリにいることを確認してください。

cd /usr/local/src/nginx/nginx-1.19.5/

Nginxのビルド依存関係をインストールします。

sudo apt build-dep nginx

sudo apt install uuid-dev

次に、次のコマンドで環境を構成します。 Nginx自体はコンパイルしませんが、ModSecurityNginxコネクタをコンパイルします。 モジュールのみ。 -with-compat フラグを立てると、モジュールは既存のNginxバイナリとバイナリ互換になります。

./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

ModSecurityNginxコネクタを構築します モジュール。

make modules

モジュールはobjs/ ngx_http_modsecurity_module.soとして保存されます 。 / usr / share / nginx / modules /にコピーします ディレクトリ。

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

ステップ5：ModSecurityv3Nginxコネクタモジュールをロードする

メインのNginx構成ファイルを編集します。

sudo nano /etc/nginx/nginx.conf

ファイルの先頭に次の行を追加します。

load_module modules/ngx_http_modsecurity_module.so;

また、 http {...}に次の2行を追加します セクションがあるため、ModSecurityはすべてのNginx仮想ホストで有効になります。

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;

ファイルを保存して閉じます。次に、 / etc / nginx / modsec /を作成します ModSecurity構成を保存するディレクトリ

sudo mkdir /etc/nginx/modsec/

次に、ModSecurity構成ファイルをコピーします。

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

ファイルを編集します。

sudo nano /etc/nginx/modsec/modsecurity.conf

次の行を見つけます。

SecRuleEngine DetectionOnly

この構成は、ModSecurityにHTTPトランザクションをログに記録するように指示しますが、攻撃が検出された場合はアクションを実行しません。次のように変更すると、ModSecurityがWeb攻撃を検出してブロックします。

SecRuleEngine On

次に、次の行（224行目）を見つけます。これは、ModSecurityに監査ログに含める必要のある情報を示しています。

SecAuditLogParts ABIJDEFHZ

ただし、デフォルト設定は間違っています。後でModSecurityログを理解する方法を説明すると、その理由がわかります。設定を次のように変更する必要があります。

SecAuditLogParts ABCEFHJKZ

コーディングWebサイトがある場合は、応答本文の検査を無効にすることをお勧めします。無効にしないと、大量のコードコンテンツを含むWebページをロードするだけで403の禁止エラーが発生する可能性があります。

SecResponseBodyAccess Off

ファイルを保存して閉じます。次に、 /etc/nginx/modsec/main.confを作成します ファイル。

sudo nano /etc/nginx/modsec/main.conf

次の行を追加して、 /etc/nginx/modsec/modsecurity.confを含めます ファイル。

Include /etc/nginx/modsec/modsecurity.conf

ファイルを保存して閉じます。 Unicodeマッピングファイルもコピーする必要があります。

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

次に、Nginx構成をテストします。

sudo nginx -t

テストが成功したら、Nginxを再起動します。

sudo systemctl restart nginx

ステップ6：OWASPコアルールセットを有効にする

ModSecurityでWebアプリケーションを保護するには、悪意のあるアクターを検出してブロックするルールを定義する必要があります。初心者の場合は、既存のルールセットをインストールすることをお勧めします。そうすれば、すぐに始めて、将来の要点を学ぶことができます。 ModSecurityにはいくつかの無料のルールセットがあります。 OWASPコアルールセット （CRS）は、ModSecurityで使用される標準のルールセットです。

• これは無料で、コミュニティが管理し、最も広く使用されているルールセットであり、ModSecurityの販売済みのデフォルト構成を提供します。
• SQLインジェクション（SQLi）、クロスサイトスクリプティング（XSS）など、一般的な攻撃ベクトルを阻止するためのルールが含まれています。
• ProjectHoneypotと統合できます。
• ボットとスキャナーを検出するためのルールも含まれています。
• 誤検知がほとんどないように、広範囲にわたる露出によって調整されています。

GitHubから最新のOWASPCRSをダウンロードします。

wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz

ファイルを抽出します。

tar xvf v3.3.0.tar.gz

ディレクトリを/etc / nginx / modsec /に移動します 。

sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/

crs-setup.conf.exampleの名前を変更します ファイル。

sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf

次に、メインの構成ファイルを編集します。

sudo nano /etc/nginx/modsec/main.conf

次の2行を追加すると、NginxにCRS構成ファイルと個々のルールが含まれるようになります。

Include /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf

ファイルを保存して閉じます。次に、Nginx構成をテストします。

sudo nginx -t

テストが成功したら、Nginxを再起動します。

sudo systemctl restart nginx

ステップ7：OWASPCRSの仕組みを学ぶ

CRSの動作に関する優れたドキュメントを提供するCRS構成ファイルを見てみましょう。

sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf

OWASPCRSは2つのモードで実行できることがわかります。

• 自己完結型モード 。これは、CRSv2.xで使用される従来のモードです。 HTTPリクエストがルールに一致する場合、ModSecurityはHTTPリクエストをすぐにブロックし、残りのルールの評価を停止します。
• 異常スコアリングモード 。これは、CRSv3.xで使用されるデフォルトのモードです。 ModSecurityはすべてのルールに対してHTTPリクエストをチェックし、一致する各ルールにスコアを追加します。しきい値に達すると、HTTPリクエストは攻撃と見なされ、ブロックされます。インバウンドリクエストのデフォルトスコアは5、アウトバウンドレスポンスのデフォルトスコアは4です。

異常スコアリングモードで実行している場合、4つのパラノイアレベルがあります。

• パラノイアレベル1（デフォルト）
• パラノイアレベル2
• パラノイアレベル3
• パラノイアレベル4

パラノイアレベルが上がるたびに、CRSは追加のルールを有効にして、より高いレベルのセキュリティを提供します。ただし、パラノイアレベルが高いと、誤警報が原因で一部の正当なトラフィックがブロックされる可能性も高くなります。

これらは、CRSを使用する前に理解する必要がある2つの基本的な概念です。これで、ファイルを閉じることができます。個々のCRSルールは/etc/nginx/modsec/coreruleset-3.3.0/rules/に保存されます ディレクトリ。一致するルールごとに、異常スコアが増加します。

ステップ8：テスト

ModSecurityが機能しているかどうかを確認するために、自分のWebサイトで単純なSQLインジェクション攻撃を開始できます。 （許可なく他の人のWebサイトでセキュリティテストを行うことは違法であることに注意してください。）Webブラウザに次のURLを入力します。

https://yourdomain.com/?id=3 or 'a'='a'

ModSecurityが正しく機能している場合、NginxWebサーバーは403forbiddenエラーメッセージを返す必要があります。

Firefoxブラウザは403エラーメッセージを表示できない場合があります。 Ctrl + Shift + Iを押すことができます 開発者ツールウィンドウを開き、 networkを選択します タブ。次に、 F5を押します Webページをリロードします。 Firefoxに403エラーコードが表示されるはずです。

ModSecurityがDetectionOnlyで実行されている場合 モードの場合、このSQLインジェクション攻撃はブロックされません。

ステップ9：ModSecurityログを理解する

ModSecurityログを分析することが重要です。これにより、Webアプリケーションに向けられた攻撃の種類を把握し、脅威の攻撃者から防御するためのより適切なアクションを実行できます。 ModSecurityには主に2種類のログがあります：

• デバッグログ：デフォルトで無効になっています。
• 監査ログ： /var/log/modsec_audit.log

ModSecurity監査ログを理解するには、ModSecurityの5つの処理フェーズを知る必要があります。これらは次のとおりです。

• フェーズ1：リクエストヘッダーを検査する
• フェーズ2：リクエスト本文を検査する
• フェーズ3：応答ヘッダーを検査する
• フェーズ4：応答本体を検査する
• フェーズ5：アクション（悪意のあるリクエストのログ記録/ブロック）

これらも2種類のログファイルです。

• シリアル ：すべてのログに対して1つのファイル。これがデフォルトです。
• 同時 ：ロギング用の複数のファイル。これにより、書き込みパフォーマンスが向上します。 ModSecurityを有効にした後、Webページの速度が低下していることに気付いた場合は、同時ロギングタイプを使用することを選択できます。

ログ内のイベントはいくつかのセクションに分かれています。

• セクションA：監査ログヘッダー
• セクションB：リクエストヘッダー
• セクションC：リクエスト本文
• セクションD：予約済み
• セクションE：中間応答機関
• セクションF：最終応答ヘッダー
• セクションG：予約済み
• セクションH：監査ログトレーラー
• セクションI：ファイルを除外するコンパクトなリクエスト本文の代替案
• セクションJ：アップロードされたファイルに関する情報
• セクションK：一致した順に、イベントによって一致したすべてのルール
• セクションZ：最終境界

トラフィックの多いWebサイトを実行している場合、ModSecurity監査ログがすぐに大きくなりすぎる可能性があるため、ModSecurity監査ログのログローテーションを構成する必要があります。 ModSecurityのログローテーション構成ファイルを作成します。

sudo nano /etc/logrotate.d/modsecurity

このファイルに次の行を追加します。

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

これにより、ログファイルが毎日ローテーションされます（毎日 ）、古いバージョンを圧縮します（圧縮 ）。以前の14個のログファイルは保持されます（ローテーション14 ）、ファイルが空の場合はローテーションは発生しません（ notifempty ）。ファイルを保存して閉じます。

ModSecurityログが空の場合は、おそらくNginxを再起動する必要があります。

sudo systemctl restart nginx

ステップ10：誤検知の処理

ModSecurityは汎用のWebアプリケーションファイアウォールであり、特定のWebアプリケーション用に設計されたものではありません。 OWASPコアルールセットも、特定のアプリケーションを考慮していない一般的なルールセットであるため、ModSecurityとOWASPCRSを有効にした後に誤検知が発生する可能性があります。 CRSのパラノイアレベルを上げると、誤検知が増えます。

たとえば、デフォルトでは、CRSは sudoを入力するようなUnixコマンドの挿入を禁止しています。 私のブログではかなり一般的なWebページで。誤検知を排除するには、CRSにルールの除外を追加する必要があります。

アプリケーション固有のルールの除外

OWASP CRSに付属している、ビルド済みのアプリケーション固有の除外がいくつかあります。 crs-setup.confを編集します ファイル。

sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf

アプリケーション固有のルールの除外に移動します セクションを作成し、次の行を見つけます。

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

たとえば、WordPressの除外を有効にする場合は、上記の行を次のように変更する必要があります。構文に注意してください。 t：none、\の間にコメントがあってはなりません およびsetvar：tx.crs_exclusions_wordpress =1 " 。 （バックスラッシュ \ 最後の文字は、次の行が現在の行の続きであることを示します。）

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

ファイルを保存して閉じます。次に、Nginx構成をテストします。

sudo nginx -t

テストが成功した場合は、変更を有効にするためにNginxをリロードします。

sudo systemctl reload nginx

同じサーバーに（WordPress、Nextcloud、Drupalなど）などの複数のアプリケーションがインストールされている場合、上記のルールの除外がすべてのアプリケーションに適用されることに注意してください。セキュリティリスクを最小限に抑えるには、1つのアプリケーションに対してのみルールの除外を有効にする必要があります。これを行うには、 /etc/nginx/modsec/coreruleset-3.3.0/rules/に移動します ディレクトリ。

cd /etc/nginx/modsec/coreruleset-3.3.0/rules

REQUEST-900-EXCLUSION-RULES-BEFORE-CRSの名前を変更します ファイル。

sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

次に、このファイルを編集します。

sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

このファイルの最後に次の行を追加します。 WordPressがblog.yourdomain.comを使用している場合 サブドメインと訪問者のブラウザから送信されるリクエストヘッダーにこのサブドメインが含まれている場合、ModSecurityはWordPressのルール除外を適用します。

SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"

同じサーバーにNextcloudをインストールしている場合は、このファイルに次の行を追加することもできます。そのため、訪問者がNextcloudサブドメインにアクセスしている場合、ModSecurityはNextcloudルールの除外を適用します。

SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"

このファイルを保存して閉じます。次に、Nginx構成をテストします。

sudo nginx -t

テストが成功した場合は、変更を有効にするためにNginxをリロードします。

sudo systemctl reload nginx

カスタムルールの除外

事前に作成されたアプリケーション固有のルールの除外を有効にしても、すべての誤検知が排除されない場合があります。その場合は、ModSecurity監査ログ（ /var/log/modsec_audit.log ）を調べる必要があります ）、誤検知の原因となったルールを確認し、 REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confにカスタムルールの除外を追加します ファイル。

監査ログのセクションHは、どのルールが一致するかを示します。たとえば、 ... を使用しようとすると コメントフォームのHTML、ModSecurityは私のコメントをブロックします。次のログは、HTTPリクエストが REQUEST-941-APPLICATION-ATTACK-XSS.confのルールに一致したことを示しています。 （527行目）。ルールIDは941310です。リクエストURIは/wp-comments-post.phpです。 。

不正な形式のエンコーディングXSSフィルター攻撃として検出されます。ただし、ユーザーが ... を使用できるようにしたい および<pre> ... コメントフォームのHTMLタグなので、ルールの除外を作成しました。 REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confの下部に次の行を追加します ファイル。

SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"

この行は、リクエストURIが /wp-comments-post.phpの場合にModSecurityに通知します。 、ルールID941310を適用しないでください。ファイルを保存して閉じます。次に、Nginx構成をテストします。

sudo nginx -t

テストが成功したら、Nginxをリロードします。

sudo systemctl reload nginx

誤検知が複数のルールIDに一致する場合は、次のように1行でルールの除外を追加できます。

SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160,ctl:ruleRemoveById=941310,ctl:ruleRemoveById=942100"

注 ：OWASP CRSでレベル1のルールを無効にしすぎると、Webサイトがハッキングされやすくなるため、お勧めしません。自分が何をしているのかがわかっている場合にのみ、ルールを無効にしてください。

IPホワイトリスト

自分のIPアドレスに対してModSecurityを無効にし、他のすべてのIPアドレスに対しては有効のままにする場合は、 REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.confに次のカスタムルールを追加します。 ファイル。 12.34.56.78を置き換えます 実際のIPアドレスを使用します。

SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"

サブネットをホワイトリストに登録するには、次の構文を使用します。これにより、 10.10.10.0 / 24がホワイトリストに登録されます。 ネットワーク。

SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"

ファイルを保存して閉じます。次に、Nginx構成をテストします。

sudo nginx -t

テストが成功した場合は、変更を有効にするためにNginxを再起動します。

sudo systemctl restart nginx

チェーンルール

Nginxに複数の仮想ホストがある場合は、特定の仮想ホストのIPアドレスをホワイトリストに登録することをお勧めします。次のように2つのルールを連鎖させる必要があります：

SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"

チェーン 最初のルールの最後にあるキーワードは、 ruleEngine =off 次のルールの条件も真である場合にのみ、アクションが実行されます。

sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf

#SecHttpBlKey XXXXXXXXXXXXXXXXX
#SecAction "id:900500,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.block_search_ip=1,\
#  setvar:tx.block_suspicious_ip=1,\
#  setvar:tx.block_harvester_ip=1,\
#  setvar:tx.block_spammer_ip=1"

sudo systemctl reload nginx

sudo nano /etc/nginx/modsec/main.conf

SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'

sudo nginx -t

sudo systemctl reload nginx

curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'

sudo apt install libnginx-mod-brotli

sudo nano /etc/nginx/nginx.conf

        brotli on;
        brotli_comp_level 6;
        brotli_static on;
        brotli_types application/atom+xml application/javascript application/json application/rss+xml
             application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
             application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
             font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
             image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;

sudo nginx -t

sudo systemctl restart nginx

sudo apt-mark hold nginx

sudo apt-mark unhold nginx

sudo apt upgrade nginx

sudo apt-mark hold nginx

apt-mark showhold

modsecurity on;

modsecurity off;

sudo systemctl reload nginx

fork() failed while spawning "worker process" (12: Cannot allocate memory)
sendmsg() failed (9: Bad file descriptor)
sendmsg() failed (9: Bad file descriptor)
sendmsg() failed (9: Bad file descriptor)

sudo nginx -t

sudo systemctl reload nginx