一回コーヒーブレイクを挟みましたが、引き続きWAFの検証を行っていきます。
前回はWAFをaptでインストールするところまでやりましたので、実際に動作を確認したいと思います。
aptでインストールした際にCSRというルールも一緒にインストールされましたので、こちらを適用して実際に防御されるのかを確認していきます。
結構最近の構成が変わっていますので、まずは設定を確認していきます。
まずはApacheの設定ファイルを見てみます。
$ cd /etc/apache2/ $ less -N apache2.conf # apacheの設定ファイルを確認 145 # Include module configuration: 146 IncludeOptional mods-enabled/*.load 147 IncludeOptional mods-enabled/*.conf
146、147行目に「mods-enabled/*.conf」という記述があるので「mods-enabled」のディレクトリを見に行きます。「cd /mods-enabled」でディレクトリを移動してファイル一覧を「ls」で確認します。以下のようになっていました。
「security2.conf」というファイルがあるので「less security2.conf」と入力してファイルを覗いてみましょう。
「/etc/modsecurity」の配下にあるconfファイルを読み込んでいるようですので、ディレクトリを「/etc/modsecurity」に移動してみましょう。「cd /etc/modsecurity」
ディレクトリの一覧を見てみると以下のようになっており、.confのファイルはありません。
なので、まずは「/etc/modsecurity」の配下にある「modsecurity.conf-recommended」をリネームして「modsecurity.conf」とし、confファイルとして有効に動作するようにします。元ファイルはバックアップ用に、残しておきます。
$ sudo cp modsecurity.conf-recommended modsecurity.conf #元ファイルをコピーして「modsecurity.conf」を作成
そして、WAFが動作するように「modsecurity.conf」を編集していきます。
$ sudo nano modsecurity.conf #「modsecurity.conf」ファイルを編集する
今回は以下の個所を編集します。（今後は色々操作して遊んでいきたいと考えています。）
SecRuleEngine DetectionOnly ↓ SecRuleEngine On
「DetectionOnly」の場合は攻撃の検知は行いますが、ブロックはしません。
またログの保存先やログファイル名、どういった情報が保存されるのかを確認しておきます。
SecAuditLog /var/log/apache2/modsec_audit.log #ログは「/var/log/apache2/」の配下のmodsec_audit.logに保存される SecAuditLogParts ABDEFHIJZ #A、B等でどのパートをロギングするかを決めている
詳細は公式のページに記載してあるとおり以下になっています。
B – request headers
C – request body
D – intended response headers (NOT IMPLEMENTED)
E – intended response body
F – response headers
G – response body (NOT IMPLEMENTED)
H – audit log trailer
I – reduced multipart request body
J – multipart files information (NOT IMPLEMENTED)
K – matched rules information
Z – audit log footer
前に作成したSQLインジェクションのコンテンツを使用します。
まずは「http://192.168.70.131/index.html?union+select」でアクセスし、WAFが反応するか確認します。「union+select」はSQLインジェクションで使用される攻撃のコードの一部ですね。
すると以下の通りステータスコード403の画面が表示されます。
GETパラメータに対する検知は行っているようですので、次はPOSTパラメータで動作するか確認しましょう。
以下のようにフォームに「’ and ‘1’=’1」と入力し「ログイン」ボタンを押します。
すると先ほどと同じようにステータスコード403の画面が表示されます。ちゃんと機能しているようです。
さてログを見に行ってみましょう。
$ cd /var/log/apache2/ #ログが保存されているディレクトリへ移動 $ sudo less modsec_audit.log #内容を確認、「sudo」がないと「許可がありません」と表示され見ることができませんでした。
ここで、ログを見ていて驚いたんですが、普通にPOSTのパラメータと入力値が保存されていました・・・
あれ、設定は「SecAuditLogParts ABDEFHIJZ」となってるんでPOSTは保存されないと思っていたんですが、なぜでしょう？（「–d6bb372d-C–」ってなってるけど「C」は入ってないんだけどな・・・）
「I – reduced multipart request body」こいつが少し怪しいので、「I」を抜いて再起動してもう一回試してみます。
すると今度は、保存されない状態になりました。
こちらについては詳しい方がいたら教えてもらえると助かります。（今のバージョンのバグ？）
ModSecurityについては今後とも遊びたいなと思っていますので、自前のルール作成とかも面白そうですし！
質問や不明点、こういうこともやって欲しい等あれば、コメントやツイッター等でご連絡頂ければ幸いです。
コメント
こんにちは
初期インストール以降のメンテナンスが大事と思います。CSRのルール更新の仕方も一緒にぜひ記事にしてください。
きたきたさん
こんにちは、コメントありがとうございます。
>初期インストール以降のメンテナンスが大事と思います。CSRのルール更新の仕方も一緒にぜひ記事にしてください。
そうですね。入れて終わりになっていましたね（セキュリティ的に一番よくないパターン・・・）。CSRルールの更新の仕方について、了解しました。
調べて早めに記事にしたいと思います。