k2-ornata（個人的「やってみたこと」ブログ）

modsecurity（WAF）をWordPressと同じサーバ上に導入できたものの、出力されたログファイルを生で読むのはなかなか厳しそうです。

また、modsecurityのログを可視化してくれるjwallというツールがあるようですが、導入はなかなかむずかしそう（ubuntu用に提供されていない？）に感じています。
そこで、とりあえずコマンドラインで簡単にログの内容を確認する方法を記載しておきます。

コマンドラインでログを分析

Linuxのコマンドである、cat やgrep, sortなどを駆使することで、ログをいろいろな角度から分析できそうです。

１．ルールIDでカウント

以下のコマンドを利用することで、ルールID毎に何件検知されているかを確認することが可能です。

$ sudo cat modsec_audit.log | grep “\[id” | sed -e “s/^.*\[id/\[id/g”| sed -e “s/”\].*$/”\]/g” | sort | uniq -c | sort -n -r

これを実行すると、以下の様な実行結果が表示されます。これで、ルールID毎の検知数が分かります。

＜コマンドの実行例＞
362 [id "990012"]
 88 [id "959151"]
 14 [id "990002"]
 12 [id "950120"]
  4 [id "960024"]
  2 [id "950005"]
  2 [id "950907"]

ちなみに各 sed の構文では以下の処理をしています。

２．送信元IPアドレスでカウント

今度は、通信の送信元でアラートをカウントしてみます。
なお私の環境の場合、AWSのゲートウェイでNATされている関係上、modsec_audit.logのBセクションに記載されている X-Forwarded-For のIPアドレスで調べてみました。　

$ sudo cat /home/bitnami/stack/apache2/logs/modsec_audit.log | grep X-Forwarded-For | sort | uniq -c | sort -n -r | more

＜コマンド実行例＞
 90 X-Forwarded-For: 44.224.22.196
 45 X-Forwarded-For: 122.97.215.50
 44 X-Forwarded-For: 103.86.49.187
 33 X-Forwarded-For: 106.161.128.84
 30 X-Forwarded-For: 44.225.84.206
 19 X-Forwarded-For: 106.161.129.59
 12 X-Forwarded-For: 195.54.160.121
 12 X-Forwarded-For: 106.161.131.223
  8 X-Forwarded-For: 5.101.0.209
  5 X-Forwarded-For: 198.71.239.46
  5 X-Forwarded-For: 106.161.117.191
  4 X-Forwarded-For: 66.249.79.211
  4 X-Forwarded-For: 66.249.71.97
  4 X-Forwarded-For: 131.72.236.178
  3 X-Forwarded-For: 91.234.217.2
  3 X-Forwarded-For: 80.82.78.104
  3 X-Forwarded-For: 210.212.250.45
  3 X-Forwarded-For: 198.71.238.22
  3 X-Forwarded-For: 194.31.64.180
  3 X-Forwarded-For: 118.157.150.165
  2 X-Forwarded-For: 97.74.24.222
  2 X-Forwarded-For: 97.74.24.201
  2 X-Forwarded-For: 97.74.24.140
--More--

IPアドレスを逆引きしたところ、一番多い 44.224.22.196 はアメリカのAmazon、122.97.215.50 は中国の China Unicom という通信会社のネットワークを使っている機器からのようですね。

こんな感じでもう少しmodsecurityのチューニングをしていきたいと思っています。

先日から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で記事の編集を行う場合、以下のルールは外しておかないとエラーになってしまうようです。