WordPressのApacheへのmod_securityインストール

Pocket

先日からAWSでWordPress(bitnami)を稼働させているのですが、ログイン履歴を見てみるとアカウントへのブルートフォース攻撃を受けていることがわかりました。
そこで、その他にも攻撃を受けていないか確認する為に、WordPressで利用しているApacheにmod_security(WAF)導入してみることにしました。

bitnamiのApache環境はやはり標準と異なる

1.パッケージインデックスファイルの更新

apt-getは、APT(Advanced Package Tool)ライブラリを利用してパッケージを操作・管理するubuntuのコマンドです。
このコマンドを利用して、パッケージインデックスファイルを更新します。

$ sudo apt-get update

2.mod_securityをインストール

1.に続いて、apt-getを利用して、mod_securityをインストールします。

$ sudo apt-get install libapache2-mod-security2 -y

3.httpd.confの修正

bitnamiに入っているApacheの場合、httpd.confの場所が通常と異なります。

$ sudo vi /home/bitnami/stack/apache2/conf/httpd.conf

上記のコマンドでhttpd.confファイルを開いた後、まずは以下の2行を追加します。

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so 

またその後、以下の行をファイルの最後に追加します。

Include “/etc/modsecurity/modsecurity.conf”  

4.modsecurity.confの修正

httpd.confを修正した後は、そのファイルの中で指定したmodsecurity.confを修正します。

$ sudo vi /etc/modsecurity/modsecurity.conf

以下の5行をファイルの最後あたりに追記してください。IncludeOptionalで検知するルールを読み込ませるようにしています。

<IfModule security2_module> 
    SecDataDir /var/cache/modsecurity
    IncludeOptional /usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf
    IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf
</IfModule>  

なお、最初は/usr/share/modsecurity-crs/activated_rulesの配下にルールはありませんので、以下のコマンドを例にして、適用したいルールへのシンボリックリンクを貼ってください。

$ cd /usr/share/modsecurity-crs/activated_rules/
$ sudo ln -s ../base_rules/modsecurity_crs_35_bad_robots.conf .

5.Apacheの再起動

confファイルの修正が完了したら、bitnamiのApacheを以下のコマンドで再起動します。このコマンドも通常のApache環境とは異なるところです。

$ sudo /opt/bitnami/ctlscript.sh restart apache

無事再起動したら、念の為、以下のコマンドを実装して見ましょう。出力に「+ security2_module(shared)+」と表示されたら、mod_securityが組み込まれています。

sudo apachectl -M | grep –color security2

6.監査ログが出力されていることを確認

/home/bitnami/stack/apache2/logsにmodsec_audit.logが出力されていることを確認します。

–9e18e84c-H–
(省略)
[file “/etc/modsecurity/modsecurity.conf”] [line “61”] [id “200002“] [msg “Failed to parse request body.”] [data “”] [severity “CRITICAL“]
(省略)
Engine-Mode: “DETECTION_ONLY”

上記は、Hセクションで severityが表示されているログの例です。

なお、WordPressで記事を保存する場合などには、上記の 200002のルールで引っかかってしまい、保存できないことがありますので、modsecurity.confに書かれているルールをコメントアウトしておいた方が良さそうです。

7.監視モードから遮断モードへ切り替え

WordPressの通常の操作でmodsec_audit.logにログが表示されないことを確認したら、modsecurity.confを編集して、SecRuleEngineの設定を”DetectionOnly”から”On”に変更しましょう。

# SecRuleEngine DetectionOnly
SecRuleEngine On

この後、再度ctlscript.shでApacheを再起動すれば、遮断モードになります。

あとはチューニングを頑張る

mod_securityのログには、ロードバランサーからのハートビートログなども載ってくるようですので、稼働させた後もチューニングをしていかないと重要なログが埋れてしまいそうです。

また、ルールについても適宜見直しをしていくと良いと思います。

(2020.5.9)とりあえず、WordPressで記事の編集を行う場合、以下のルールは外しておかないとエラーになってしまうようです。

idmsg発生する現象
200002Failed to parse request body.記事の保存に失敗する
200004Multipart parser detected a possible unmatched boundary.画像のアップロードに失敗する
960024Meta-Character Anomaly Detection Alert – Repetative Non-Word CharactersWPのログインに失敗する
WordPress環境で無効化しておいたほうが良いルール