投稿者: keitsu

先日から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のログインに失敗する