ModSecurity、多くの場合 Modsec、と呼ばれます は無料のオープンソースWebアプリケーションファイアウォールです（WAF） 。 ModSecurityは、ApacheHTTPサーバーのモジュールとして作成されました。ただし、初期の頃からWAFは成長し、Microsoft IIS、Nginx、そしてもちろんApacheなどのさまざまなプラットフォーム向けの一連のハイパーテキスト転送プロトコルの要求および応答フィルタリング機能をカバーしています。
WAFがどのように機能するか、ModSecurityエンジンはWebアプリケーションの前にデプロイされ、エンジンが着信および発信HTTP接続をスキャンできるようにします。 ModSecurityは、 OWASPコアルールセット（CRS）と組み合わせて最も一般的に使用されます。 、ModSecurityのSecRules言語で記述されたオープンソースのルールセットであり、セキュリティ業界で高く評価されています。
ModSecurityを使用したOWASPルールセットは、サーバーを次のことからほぼ瞬時に保護するのに役立ちます。
- 悪いユーザーエージェント
- DDOS
- クロスサイトスクリプティング
- SQLインジェクション
- セッションハイジャック
- その他の脅威
次のチュートリアルでは、 Debian11BullseyeデスクトップまたはサーバーにNginxを使用してModSecurityをインストールする方法を学習します。
- 推奨OS： Debian11ブルズアイ。
- ユーザーアカウント： sudoまたはrootアクセス権を持つユーザーアカウント。
- 必要なパッケージ： チュートリアル全体にリストされています
Debianを更新します 既存のすべてのパッケージが最新であることを確認するためのオペレーティングシステム：
sudo apt update && sudo apt upgrade -yチュートリアルでは、sudoコマンドを使用します およびsudoステータスがあると仮定 。
アカウントのsudoステータスを確認するには：
sudo whoamisudoステータスを示す出力例：
[joshua@debian~]$ sudo whoami
root既存または新規のsudoアカウントを設定するには、DebianのSudoersへのユーザーの追加に関するチュートリアルにアクセスしてください。 。
rootアカウントを使用するには 、rootパスワードを指定して次のコマンドを使用してログインします。
suCURLとUNZIPパッケージをインストールする
チュートリアルでは、 curlandunzipコマンドを使用します 特定の部分の間に。これがインストールされていることを確認するには、ターミナルで次のコマンドを実行します。
sudo apt install curl unzip -y最新のNginxをインストールする
まず、Nginxをインストールする必要があります。これは、最新の安定版またはメインラインのNginxバージョンで行うことをお勧めします。続行する前に、既存のインストールを削除することをお勧めします Nginxを使用して、最新のNginx安定版またはメインラインバージョンをインストールします 。
既存のNginxインストールを削除する
現在のNginxサービスを停止します：
sudo systemctl stop nginx次に、既存のNginxインストールを次のように削除します。
apt-get purge nginx -y && sudo apt autoremove nginx -y最新のNginxリポジトリをインポートしてインストール
nginx mainlineまたはstableの最新バージョンを使用するには、最初にリポジトリをインポートする必要があります。
メインラインリポジトリをインポートするには：
curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x安定したリポジトリをインポートするには：
curl -sSL https://packages.sury.org/nginx/README.txt | sudo bash -x新しい変更を反映するようにリポジトリを更新します：
apt updateこれで、Nginxリポジトリがインストールされました リポジトリリストを更新し、次のようにNginxをインストールします。
apt install nginx-core nginx-common nginx nginx-full既存の/ etc / nginx /を保持または置き換えるように求められる場合があることに注意してください nginx.conf インストール中の構成ファイル。 （n）を押して、現在の構成ファイルを保持することをお勧めします 。メンテナのバージョンに関係なくコピーが作成され、将来的に確認することもできます。
Nginxソースコードをリポジトリに追加
Nginxメインラインの最新バージョンまたはデフォルトで安定版をインストールする場合、バイナリのみがインストールされます。ただし、チュートリアルでModsecurityをさらにコンパイルするには、ソースが必要です。
まず、 /etc/apt/sources.list.dにある構成ファイルを開きます。 以下のようにnanoを使用：
メインライン：
nano /etc/apt/sources.list.d/nginx-mainline.list安定：
nano /etc/apt/sources.list.d/nginx.listメインラインと安定版の両方で、ファイルを開くと、次のように1行しか表示されません。
#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main元の行の下に、次の行を追加します。
メインライン：
deb-src https://packages.sury.org/nginx-mainline/ bullseye main安定：
deb-src https://packages.sury.org/nginx-mainline/ bullseye mainどのように表示されるかの例（メインラインの例のみ）：
Nginxソースをダウンロード
ModSecurity動的モジュールをコンパイルするには、Nginxソースコードをダウンロードする必要があります 。これを行うには、ソースパッケージをダウンロードしてディレクトリの場所に保存する必要があります / etc / local / src / nginx 。
ディレクトリの作成と構成
次のように場所を作成します。
mkdir /usr/local/src/nginx && cd /usr/local/src/nginxオプション–必要に応じて、以下のようにディレクトリに権限を割り当てます。
chown username:username /usr/local/src/ -R 依存関係をインストールしてダウンロードを実行する
次に、次のソースパッケージをダウンロードします。
apt install dpkg-dev -y && sudo apt source nginx以下のようなエラーメッセージが表示されることに注意してください。
dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)これは無視しても問題ありません。
ソースバージョンの確認
次に、 lsを使用してディレクトリファイルを一覧表示します 次のようにコマンドを実行します：
ls/ usr / src / local / nginxに次の出力が表示されます。 ディレクトリ：
nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc次に、ソースパッケージがDebianオペレーティングシステムにインストールされているNginxバージョンと同じであることを確認します。これを行うには、次の nginx -vを使用します 次のようにコマンドを実行します：
sudo nginx -vダウンロードしたソースは、システムにインストールされているバイナリバージョンと一致している必要があります。
例：
nginx version: nginx/1.21.1ModSecurity用のlibmodsecurity3をインストールします
パッケージlibmodsecurity3 HTTPフィルタリングを実行するWAFの実際の部分です Webアプリケーション用。 Debian 11では、これをデフォルトのDebian11リポジトリからインストールできます。ただし、これはほとんどの安定したバージョンのように推奨されておらず、遅れることがよくあります。代わりに、次のようにはるかに最新のソースからコンパイルします。
GithubからModSecurityRepsoitoryのクローンを作成
最初のステップはGithubからのクローンであり、gitがインストールされていない場合は、次のコマンドを実行する必要があります。
apt install git -y次に、libmodsecurity3GITリポジトリのクローンを次のように作成します。
git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/クローンを作成したら、 CDを作成する必要があります ディレクトリへ：
cd /usr/local/src/ModSecurity/libmodsecurity3の依存関係をインストールする
コンパイルするには、次の依存関係を次のようにインストールする必要があります。
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 -y最後に、次のGITサブモジュールを次のようにインストールします。
git submodule init次に、サブモジュールを更新します：
git submodule updateModSecurity環境の構築
次のステップは、実際に最初に環境を構築することです。次のコマンドを使用します：
./build.sh次に、configureコマンドを実行します：
./configure次のエラーが表示される可能性があることに注意してください。
fatal: No names found, cannot describe anything.これを無視して、次のステップに進むことができます。
ModSecurityソースコードのコンパイル
libmodsecurity3の環境を構築および構成したので、次はコマンド makeを使用して環境をコンパイルします。 。
make
便利なトリックは、-j
make -j 6ソースコードをコンパイルしたら、ターミナルでインストールコマンドを実行します。
make installインストールは/usr / local /modsecurity/で行われることに注意してください これについては、ガイドの後半で参照します。
ModSecurity-nginxコネクタをインストール
ModSecurity-nginxコネクタ nginxとlibmodsecurity間の接続ポイントです。基本的に、これはNginxとModSecurity （libmodsecurity3）の間で通信するコンポーネントです。 。
CloneModSecurity-GithubのnginxRepsoitory
libmodsecurity3リポジトリのクローンを作成する前の手順と同様に、次のコマンドを使用してコネクタリポジトリのクローンを再度作成する必要があります。
sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/ModSecurity-nginxの依存関係をインストールする
次に、次のようにCDディレクトリをNginxソースディレクトリに追加します。
cd /usr/local/src/nginx/nginx-1.21.1ガイドのバージョンをシステム内の現在のNginxバージョンに置き換えてください。
次に、Debianターミナルでコマンドを実行して、必要な依存関係をインストールします。
apt build-dep nginx && sudo apt install uuid-dev -y次に、ModSecurity-nginxコネクタをコンパイルします –with-compatのみのモジュール 次のようにフラグを立てます：
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx今作る 次のコマンドで動的モジュールを作成します：
make modules次に、Nginxソースディレクトリで、次のコマンドを使用して、 objs / ngx_http_modsecurity_module.soの場所に保存された作成した動的モジュールを移動します。 / usr / share / nginx / modulesにコピーします ディレクトリ。
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/ロード時にフルパスを指定する限り、ダイナミックモジュールをどこにでも保存できます。
NginxWebサーバーでModSecurity-nginxコネクタをロードして構成する
動的モジュールをコンパイルし、それに応じて配置したので、 /etc/nginx/nginx.confを編集する必要があります。 ModSecurityをNginxWebサーバーで動作させるための構成ファイル。
nginx.confでModSecurityを有効にする
まず、 load_moduleを指定する必要があります およびmodsecurityモジュールへのパス。
nginx.confを開きます 任意のテキストエディタで。チュートリアルでは、nanoを使用します：
sudo nano /etc/nginx/nginx.conf次に、上部近くのファイルに次の行を追加します。
load_module modules/ngx_http_modsecurity_module.so;モジュールを別の場所に配置した場合は、必ずフルパスを含めてください。
次に、 HTTP {}の下に次のコードを追加します 次のセクション：
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;例のみ：
モジュールを別の場所に配置した場合は、必ずフルパスを含めてください。
nginx.confを保存します ファイル（CTRL + O）、 次に、（CTRL + X）を終了します 。
ModSecurity用のディレクトリとファイルの作成と構成
構成ファイルと将来のルールを保存するためのディレクトリ、チュートリアル用のOWASPCRSを作成する必要があります。
次のコマンドを使用して、 / etc / nginx / modsecを作成します 次のようなディレクトリ：
sudo mkdir /etc/nginx/modsec/次に、サンプルのModSecurity構成ファイルを複製されたGITディレクトリからコピーして戻す必要があります。
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.confお気に入りのテキストエディタを使用して、次のようにmodsecurity.confファイルを開きます。
sudo nano /etc/nginx/modsec/modsecurity.confデフォルトでは、ModSecurity構成のルールエンジンは（DetectionOnly）として指定されています つまり、ModSecurityを実行し、すべての悪意のある動作を検出しますが、フラグを立てたすべてのHTTPトランザクションをブロックしたり、禁止したり、ログに記録したりすることはありません。これは、誤検知が多い場合、またはセキュリティレベルの設定を極端なレベルに上げて、誤検知が発生するかどうかをテストする場合にのみ使用してください。
この動作を（オン）に変更するには 、7行目で次を見つけてください ：
SecRuleEngine DetectionOnly行をこれに変更して、ModSecurityを有効にします：
SecRuleEngine Onここで、行224にある次のものを見つける必要があります。 ：
# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZこれは正しくないため、変更する必要があります。行を次のように変更します：
SecAuditLogParts ABCEFHJKZ次に、 modsecurity.confを保存します （CTRL + O）を使用したファイル 次に、（CTRL + X）を終了します 。
次の部分は、次のファイル modsec-config.confを作成することです。 。ここで、 modsecurity.confを追加します OWASP CRSなどの他のルールに沿って後でファイルする 、WordPressを使用している場合は、 WPRS CRS ルールセット。
次のコマンドを使用してファイルを作成し、開きます。
sudo nano /etc/nginx/modsec/modsec-config.confファイル内に移動したら、次の行を追加します。
Include /etc/nginx/modsec/modsecurity.confmodsec-config.confを保存します （CTRL + O）のファイル 次に（CTRL + X） 終了します。
最後に、ModSecurityの unicode.mappingをコピーします CPのファイル 次のようにコマンドを実行します：
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/次に進む前に、次のターミナルコマンドを使用してNginxサービスをドライランする必要があります。
sudo nginx -tすべてを正しく設定すると、次の出力が得られます。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful変更を公開するには、systemctlコマンドを使用してNginxサービスを再起動します。
sudo systemctl restart nginxModSecurity用のOWASPコアルールセットをインストールする
ModSecurity自体はWebサーバーを保護しないため、ルールが必要です。最も有名で、尊敬され、よく知られているルールの1つは、OWASPCRSルールセットです。ルールは、Webサーバーや他のWAFの間で最も広く使用されており、他のほとんどの同様のシステムは、ほとんどのルールをこのCRSに基づいています。このルールセットをインストールすると、悪意のある攻撃者を検出してブロックすることにより、インターネット上のほとんどの新たな脅威に対する優れた保護ソースが自動的に提供されます。
wgetコマンドを使用する OWASPCRS3.3.2アーカイブをダウンロードします 次のように：
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zipエッジで生きたい人のために、ナイトリービルドをダウンロードできます。 CoreRuleSet Githubの再コンパイルと更新を頻繁にチェックし、問題をより確実に把握する準備ができている場合にのみ、毎晩使用してください。技術的には、夜間の方が安全ですが、問題が発生する可能性があります。
初心者ユーザーの場合は、安定版を使用し、以下のバージョンは使用しないでください。
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.zip解凍パッケージをインストールします これをサーバーにインストールしていない場合：
sudo apt install unzip -y今すぐ解凍 master.zip 次のようにアーカイブします：
sudo unzip v3.3.2.zip -d /etc/nginx/modsec以前は、 modsecurity.confのように サンプル構成、 OWASP CRS 名前を変更する必要があるサンプル構成ファイルが付属しています。 CPを使用するのが最適です コマンド 再起動が必要になった場合に備えて、将来のためにバックアップを取っておきます。
sudo cp /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.confルールを有効にするには、 /etc/nginx/modsec/modsec-config.confを開きます テキストエディタを再度使用する：
sudo nano /etc/nginx/modsec/modsec-config.confファイル内に戻ったら、次の2行を追加します。
Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.confファイルを保存します（CTRL + O） （CTRL + X）を終了します 。
以前と同様に、Nginxサービスを公開する前に、Nginxサービスへの新しい追加をテストする必要があります：
sudo nginx -t次の出力が表示されます。これは、すべてが正しく機能していることを意味します。
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulNginxサービスを再起動して、次のように変更を有効にします。
sudo systemctl restart nginxOWASPCRSの使用と理解
OWASP CRSには非常に多くのオプションがありますが、デフォルト設定では、実際の訪問者や優れたSEOボットを傷つけることなく、ほとんどのサーバーをすぐに保護できます。以下では、説明に役立ついくつかの領域について説明します。構成ファイル自体のすべてのオプションを調査するのが最善です。それらには、それらが何であるかを説明するためのかなりの量のテキストデータがあるからです。
CRS-setup.confを開きます 次のようにファイルします：
nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.confこれは、バージョン3.3と比較して追加の項目を含む開発バージョンの構成であることに注意してください。
ここから、OWASPCRS設定のほとんどを変更できます。
OWASPCRSスコアリング
それを分解するために、ModSecurityには2つのモードがあります：
異常スコアリングモード
# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.自己完結型モード
# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.異常スコアリングは、通常、ほとんどのユーザーにとって使用するのに最適なモードです。
4つのパラノイアレベルがあります：
- パラノイアレベル1– デフォルトレベルで、ほとんどのユーザーに推奨されます。
- パラノイアレベル2– 上級ユーザーのみ。
- パラノイアレベル3– エキスパートユーザーのみ。
- パラノイアレベル4– 例外的な状況を除いて、まったくお勧めしません。
# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
# are enabled. PL1 is advised for beginners, installations
# covering many different sites and applications, and for setups
# with standard security requirements.
# At PL1 you should face FPs rarely. If you encounter FPs, please
# open an issue on the CRS GitHub site and don't forget to attach your
# complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
# many regexp-based SQL and XSS injection protections, and adding
# extra keywords checked for code injections. PL2 is advised
# for moderate to experienced users desiring more complete coverage
# and for installations with elevated security requirements.
# PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
# limits on special characters used. PL3 is aimed at users experienced
# at the handling of FPs and at installations with a high security
# requirement.
# - Paranoia level 4 further restricts special characters.
# The highest level is advised for experienced users protecting
# installations with very high security requirements. Running PL4 will
# likely produce a very high number of FPs which have to be
# treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.サーバーでOWASPCRSをテストする
OWASP CRSがサーバーで機能しているかどうかをテストするには、インターネットブラウザを開き、次を使用します。
https://www.yourdomain.com/index.html?exec=/bin/bash403禁止エラーが表示されます。 そうでない場合は、ステップが失敗しています。
最も一般的な問題は、 DetectionOnlyを変更するために欠落しています オン チュートリアルの前半で説明したように。
誤検知とカスタムルールの除外への対処
多くの場合、終わりのないタスクの1つは誤検知の処理です。ModSecurityとOWASP CRSは一緒に素晴らしい仕事をしますが、時間はかかりますが、保護があれば、それだけの価値があります。手始めに、パラノイアのレベルを最初から高くしないことが黄金律です。
経験則としては、誤検知がほとんどない状態でルールセットを数週間から数か月間実行してから、たとえば、パラノイアレベル1からパラノイアレベル2に増やして、同時に1トンに圧倒されないようにすることです。
>誤検知の既知のアプリケーションを除外する
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を有効にするには 3つすべてを使用するときは、行のコメントを外してください （1）を離れます 番号はそのままにして、使用しない他のサービス（Xenforoなど）を（0）に変更します。 これらのルールをホワイトリストに登録したくないためです。
以下の例：
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_cpanel=0,\
setvar:tx.crs_exclusions_dokuwiki=0,\
setvar:tx.crs_exclusions_drupal=0,\
setvar:tx.crs_exclusions_nextcloud=0,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1,\
setvar:tx.crs_exclusions_xenforo=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"ご覧のとおり、不要なオプションは削除され、（“）が追加されました。 正しい構文のためにWordPressの最後に。
CRS以前のルールの除外
カスタム除外を処理するには、まず、名前を REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.confから変更する必要があります。 cpコマンドを使用したファイル 次のように：
sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf除外ルールを作成するときは、それぞれにid：<ルール番号>があり、一意である必要があります。そうでない場合、Nginxサービスをテストするときにエラーが発生します。例“ id：1544、phase：1、log、allow、ctl：ruleEngine =off” 、ID1544を2番目のルールに使用することはできません。
たとえば、一部のREQUEST_URIは誤検知を発生させます。以下の例は、WordPress用のGoogleページスピードビーコンとWMUDEVプラグインを使用した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はすべて自動的に許可されます。
もう1つのオプションは、IPアドレスをホワイトリストに登録することです。これについては、いくつかの方法があります。
SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
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"@ipMatch サブネットに対してより広範囲に使用できます。 サブネットを拒否する場合 またはIPアドレス 変更、拒否を許可します。少しのノウハウがあれば、ブラックリストとホワイトリストを作成し、これを fail2banで構成することもできます。 。多くの場合、可能性は無限大です。
最後の例は、最初のREQUEST_URIの例で見たように、パス全体を包括的にホワイトリストに登録するのではなく、誤検知をトリガーするルールのみを無効にすることです。ただし、これにはより多くの時間とテストが必要です。たとえば、ルールを削除したい 941000 および942999 / admin /領域から、チームの誤った禁止とブロックをトリガーし続けます。modsecurityログファイルでルールIDを見つけ、 RemoveByIDでそのIDのみを無効にします。 以下の例のように：
SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"例は、ModSecurityGITwikiページにあります。 LinuxCapableは、カバーすることが非常に多いため、将来、この部分に関するチュートリアルを作成する予定です。
オプション–プロジェクトハニーポットを含める
プロジェクトハニーポット は、スパマーと、スパマーがWebサイトからアドレスを取得するために使用するスパムボットを識別するための最初で唯一の分散システムです。 Project Honey Potシステムを使用すると、サイトへの訪問者の時間とIPアドレスにカスタムタグ付きアドレスをインストールできます。これらのアドレスの1つが電子メールの受信を開始すると、メッセージがスパムであることがわかり、アドレスが収集された正確な瞬間と、それを収集したIPアドレスがわかります。
ModSecurityには、Project Honeypotを統合するオプションがあります。これにより、データベースにクエリが実行され、HoneyPotブラックリストにあるすべてのアドレスがブロックされます。これを使用すると誤検知が発生する可能性がありますが、全体として、同様の代替手段と比較して非常に信頼性が高いと見なされます。
ステップ1。 無料のアカウントを作成します。
ステップ2。 サインアップしてログインしたら、ダッシュボードで（http：BL APIキー）の行を見つけます。 取得をクリックします 。
ステップ3。 テキストエディタを使用してCRS-setup.confファイルを開き、ファイルに戻ります。
sudo nano /etc/nginx/modsec/coreruleset-3.3.3/crs-setup.confステップ4。 Find the line starting with #SecHttpBlKey, which is on line 629.
#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"Step 5. Change the SecHttpBlKey XXXXXXXXXXXXXXXXX with your key from Project HoneyPot.
例：
SecHttpBlKey amhektvkkupeStep 6. Next, uncomment all the lines to enable the rule. To deactivate a rule, instead of (1), put (0) instead if you wish to have any of the rules disabled. By default, block_search_ip=0 is for search engine bots, do not enable this unless you want Bing, Google, and other good bots coming to your site.
SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.block_search_ip=0,\
setvar:tx.block_suspicious_ip=1,\
setvar:tx.block_harvester_ip=1,\
setvar:tx.block_spammer_ip=1"Note, do not use amhektvkkupe. Use your key instead!
Step 7. Test Nginx to make sure no errors have occurred with the following:
sudo nginx -tExample output if all correct:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successfulNow restart your Nginx service:
sudo systemctl restart nginxWordPress WPRS Rule Set for ModSecurity
Another option for WordPress users is to install and run alongside your OWASP CRS rule set, a well-known project entitled WPRS rule set. As this is optional and isn’t for everyone, the tutorial will not cover it in this section. However, if you would like to install this for extra protection if you use WordPress on your server, please visit our tutorial on Installing WordPress ModSecurity Rule Set (WPRS).
Create ModSecurity LogRotate File
Given how many lines and information it can log, ModSecurity will grow quite quickly. As you are compiling the module and it isn’t installed through any official repository from Debian, you will need to create your own log rotate file.
First, create and open your ModSecurity rotate file modsec ：
sudo nano /etc/logrotate.d/modsecAdd the following code:
/var/log/modsec_audit.log
{
rotate 31
daily
missingok
compress
delaycompress
notifempty
}This will keep logs for 31 日々。 If you prefer to have less, change 31 to say 7 days equally a week’s worth of logs. You should be rotating daily for ModSecurity. If you need to review the log files having a weekly file will be a disaster to sift through, given how large it will be.