6.2 WAF(mod_security)の設定

2018年4月24日

 Webサーバを建てていると、いつの間にか色々なちょっかいを出してくる輩が湧いてきます。今頃こんな古い脆弱性をついてどうするんだ?というのも多く見受けられ放置でもよいのですが、勉強の一環で今回はWAFを導入してみました。

 WAF(Web Application Firewall)は、読んで字の如くアプリケーションレベルで実施するファイアウォールになります。大手企業等では、アプライアンスで導入されることも多いと思いますが、個人で建ててる野良Webサーバなので、apache対応の無償利用可能な ModSecurity を導入します。

 ModSecurity は超簡単に誤解を恐れず言えば apache の通信をフックして、設定されたルールに従い、様々なレベルでパータンマッチングを行い、脅威判定したものは、エラーコードを返して通信を遮断してくれます。

1.ModSecurity とルールセットのインストール
 FreeBSD は pkg が完備しているので、バイナリーパッケージで入れてしまうのが簡単です。
   今回は以下のように 2.9.1 というバージョンが入りました。
 因みに入れた環境は OS が FreeBSD 10.2-RELEASE-p19、apache は 2.4.23。(2016/7/30時点)

 次にModSecurity が使用するルールセット(CRS-Core Rule Set-)を導入します。サイトから最新版をダウンロードしても良いのですが、上記のメッセージに従い git で落とし、 /usr/local/etc/modsecurity へ配置しました。

2.稼働設定と起動
 ModSecurity を稼働させる設定を行います。
 /usr/local/etc/apache24/modules.d/280_mod_security.conf
 に設定ファイルを落としてくれていますが、今回は、apache の httpd.conf に設定してしまいます。

ロードモジュールとして mod_unique_id.so と mod_security2.so を読み込む様に追加指定します。次に適用するルールセットとして以下の2つのディレクトリ下の .conf を読み込む指定をします。
Include /usr/local/etc/modsecurity/*.conf
Include /usr/local/etc/modsecurity/owasp-modsecurity-crs/activated_rules/*.conf

適用するルールセットとしては、base_rules、optional_rules、experimental_rules とします。(本当は最初からこんなに指定すると後が大変なのですが。。。)
Include で指定した activated_rules には何も入っていません。必要なルールをシンボリックリンクするように書かれています(README)。
なので、

とかやって使用するルールのリンクを貼ります。または、直接 Include 指定したほうが簡単かもしれません。また、/usr/local/etc/modsecurity/modsecurity.conf 内の SecRuleEngine が “DetectionOnly” (検知のみ行う)になっているのを確認します。
ここまで終わったら apache の config をチェックして、リスタートさせます。

3.偽陽性のテスト
 この状態で、検知モードのみで稼働しているので、Webサーバに対して外部からの参照と同じ一通りの操作をします。
検知したログは、/var/log/modsec_audit.log にでます。が、一気に4M,5M当たりまえの世界で出力されました(ギョギョギョ!!-お前はさかな君か!)。

 上記の様なログが大量に出力されています。このログを見て、検知してほしくないルールを無効化していきます。
 上記のボールド体で示した部分、[–????-H–] 部に検知ルールと検知IDが出ていますので、IDをメモります。ログ量は多い(レスポンスボディ部が入っているので)ですが、同一IDで複数回検知しているので、種類はそれ程でもないはずです。メモったIDを SecRuleRemoveById として先程の httpd.conf へ記載します。お仕事であれば、ルールを調べ検知理由を考えアプリの対策を考え、どうしてもダメならルール削除となるのでしょうが、ここは、バッサリ落としてしまいます(オイオイ)。
 当サイトの参照では、以下の11のルールを設定しました。

 設定後、apache を再起動して、サイト表示させ、検知されない事を確認します。スマフォや外部のPCからも参照して、他のIDが出ていない事を確認します。

 このまま、しばらく様子見にしたいのですが、WordPress で編集モードにすると、また、大量に出力されるため、編集を行うローカルLANはチェック対象から外す指定を入れます。

 従って、最終的に httpd.conf に追加した内容は、以下の様になりました。

/var/log/modsec_audit.log の出力設定を変更します。こちらのサイト様を参照させていただき
以下の様に変更(「E」のレスポンスボディは記録からはずした)しました。

SecAuditLogPartsはどのパートをロギングするかを以下から選択して指定する。

AとZは必須。Reservedとなっているパートは将来利用される。

A AuditLogヘッダー
B リクエストヘッダー
C リクエストボディ
D Reserved
E レスポンスボディ
F レスポンスヘッダー
G Reserved
H 追加情報。パターンにマッチしたアクセスだとここにタグが付与される。
I ファイルを除外した、コンパクトなリクエストボディ
J Reserved
K トランザクションにマッチした全てのルール
Z 最後の境界線

しばらく検知オンリーで動かし、怪しいアクセスを検知しているか、他に影響がないか見て、OKならば、
/usr/local/etc/modsecurity/modsecurity.conf
の SecRuleEngine を “DetectionOnly” から “On” に変更して apache を再起動します。

検知オンリーでも検知結果は、先のmodsec_audit.log とapache のエラーログ (/var/log/httpd-error.log等)に出力されるので、随時確認していきます。

こんな感じで検知してますね。って Bash Attack ってかなり前に問題となった bash の脆弱性をつく攻撃ですね。いまさらこんなのに引っかかる方はいないだろう~。IP が本当ならベトナムからのアクセスで、複数のブラックリストに記載されてるアドレスですね。

【参考にさせて頂いたサイト様】
オープンソースの WAF である ModSecurity を CentOS にインストールする
WAF(mod_security)の導入
OpenGroove ModSecurity2のインストール
bashの脆弱性を狙った不正アクセスを検知・ブロックする
ModSecurity


FreeBSDへ  サイトTOPへ

Posted by null-a