先日からAWSでWordPress（bitnami）を稼働させているのですが、ログイン履歴を見てみるとアカウントへのブルートフォース攻撃を受けていることがわかりました。
そこで、その他にも攻撃を受けていないか確認する為に、WordPressで利用しているApacheにmod_security（WAF）導入してみることにしました。
bitnamiのApache環境はやはり標準と異なる
１．パッケージインデックスファイルの更新
apt-getは、APT（Advanced Package Tool）ライブラリを利用してパッケージを操作・管理するubuntuのコマンドです。
このコマンドを利用して、パッケージインデックスファイルを更新します。
$ sudo apt-get update
２．mod_securityをインストール
１．に続いて、apt-getを利用して、mod_securityをインストールします。
$ sudo apt-get install libapache2-mod-security2 -y
３．httpd.confの修正
bitnamiに入っているApacheの場合、httpd.confの場所が通常と異なります。
$ sudo vi /home/bitnami/stack/apache2/conf/httpd.conf
上記のコマンドでhttpd.confファイルを開いた後、まずは以下の２行を追加します。
LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so
またその後、以下の行をファイルの最後に追加します。
Include “/etc/modsecurity/modsecurity.conf”
４．modsecurity.confの修正
httpd.confを修正した後は、そのファイルの中で指定したmodsecurity.confを修正します。
$ sudo vi /etc/modsecurity/modsecurity.conf
以下の５行をファイルの最後あたりに追記してください。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 .
５．Apacheの再起動
confファイルの修正が完了したら、bitnamiのApacheを以下のコマンドで再起動します。このコマンドも通常のApache環境とは異なるところです。
$ sudo /opt/bitnami/ctlscript.sh restart apache
無事再起動したら、念の為、以下のコマンドを実装して見ましょう。出力に「+ security2_module（shared）+」と表示されたら、mod_securityが組み込まれています。
sudo apachectl -M | grep –color security2
６．監査ログが出力されていることを確認
/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に書かれているルールをコメントアウトしておいた方が良さそうです。
７．監視モードから遮断モードへ切り替え
WordPressの通常の操作でmodsec_audit.logにログが表示されないことを確認したら、modsecurity.confを編集して、SecRuleEngineの設定を”DetectionOnly”から”On”に変更しましょう。
# SecRuleEngine DetectionOnly
SecRuleEngine On
この後、再度ctlscript.shでApacheを再起動すれば、遮断モードになります。
あとはチューニングを頑張る
mod_securityのログには、ロードバランサーからのハートビートログなども載ってくるようですので、稼働させた後もチューニングをしていかないと重要なログが埋れてしまいそうです。
また、ルールについても適宜見直しをしていくと良いと思います。
（2020.5.9）とりあえず、WordPressで記事の編集を行う場合、以下のルールは外しておかないとエラーになってしまうようです。
| id | msg | 発生する現象 |
|---|---|---|
| 200002 | Failed to parse request body. | 記事の保存に失敗する |
| 200004 | Multipart parser detected a possible unmatched boundary. | 画像のアップロードに失敗する |
| 960024 | Meta-Character Anomaly Detection Alert – Repetative Non-Word Characters | WPのログインに失敗する |
