はじめに
ModSecurity はオープンソースの WAF (Web Application Firewall) で広く利用されています。ですが、Windows 版はなぜか IIS 7 対応版をリリースした後、リリースが止まっていました。
公式なアナウンスはないのですが、バージョン 2.8 で IIS 7 の表記がなくなったこと、VC++ のランタイムが Visual Studio 2013 になったことから、広く Windows をサポートするようになったと推測されます。
実際、Windows Server 2012 R2 (IIS 8.5) に、ModSecurity のバージョン 2.8 をインストールして設定してみましたが、正常に動作しました。
この記事では、このバージョン 2.8 の Windows 版 ModSecurity をインストールし、動作するよう設定する方法をご紹介します。
Windows Server 2012 R2 や IIS 8.5 のインストール、ModSecurity の一般的なことは下記記事をご参照ください。
- VirtualBox に Windows Server 2012 R2 をインストールする（ISO/VHD）
- Windows Server 2012 R2 に IIS 8.5 をインストールする
- オープンソースの WAF である ModSecurity を CentOS にインストールする
目次
Visual Studio 2013 VC++ ランタイムのインストール
ModSecurity には、Visual Studio 2013 VC++ ランタイムのインストールが必要です。ですが、公式サイトにある URL からはダウンロードができないので、以下のサイトよりダウンロードしてください。
ランタイムは、32 ビット版と 64 ビット版がありますが、64 ビット版をダウンロードしてインストールしてください。
特別なことはないので、問題なくインストールすることができると思います。
ModSecurity のインストール
ModSecurity のサイトにアクセスして、Code ページより ModSecurity のインストーラーをダウンロードします。インストーラーは 32 ビット版と 64 ビット版があるので、64 ビット版をダウンロードしてください。
そうそう。なぜか、Internet Explorer では、インストーラーのダウンロードが異常終了してしまったので、同じ現象が起きた方は Google Chrome でダウンロードしてみてください。
ダウンロードしたインストーラーを起動し、インストールを行います。デフォルトのままインストールすれば問題ありません。
インストールが終了したら、IIS を再起動することで ModSecurity が全サイトに対して有効になります。
但し、デフォルトの設定が検知のみなので、不正な URL でアクセスしても何も起きないのでがっかりしないでください。これは WAF としては正しい挙動だと思いますが、説明がどこにもないので最初はインストールがうまくいっていないのかと試行錯誤してしまいました。
ModSecurity は、以下のフォルダにインストールされます。設定なども、この中にある設定ファイルで行います。設定変更後は、IIS の再起動が必要になります。
- C:\Program Files\ModSecurity IIS
ModSecurity の設定
ModSecurity をインストールしたら、不正なアクセスはブロックして欲しいですよね。
ですので、まずは以下のファイルを編集して不正なアクセスをブロックするように設定してみます。
- C:\Program Files\ModSecurity IIS\modsecurity.conf
modsecurity.conf の最初の方にある SecRuleEngine を DetectionOnly から On に変更することで、不正なアクセスをブロックするようになります。
具体的には以下のように記述してください。
SecRuleEngine On
IIS を再起動して、http://servername/?union+select でサイトにアクセスしてみましょう。
すると、以下のように不正なアクセスがブロックされることが分かります。
ログの出力先の変更
ModSecurity のログはエラーを含めイベントのアプリケーションログに出力されます。
ここでは監査ログ(Audit log)をテキストファイルに「も」出力するように変更します。本当は、テキストファイルに出力するのは一時的な用途にする方がよいような記述が設定ファイルに記載があったことは付記しておきます。
先ほどの、modsecurity.conf の Audit log セクションを以下のように変更します。変更といっても、ほぼコメントを外すだけです。ですが、デフォルトのログの出力先フォルダ名が log になっているのですが、これは本当は logs が正しいというのははまりどころですね。
# -- Audit log configuration ------------------------------------------------- # Log the transactions that are marked by a rule, as well as those that # trigger a server error (determined by a 5xx or 4xx, excluding 404, # level response status codes). # SecAuditEngine RelevantOnly SecAuditLogRelevantStatus "^(?:5|4(?!04))" # Log everything we know about a transaction. SecAuditLogParts ABIJDEFHZ # Use a single file for logging. This is much easier to look at, but # assumes that you will use the audit log only ocassionally. # SecAuditLogType Serial SecAuditLog c:\inetpub\logs\modsec_audit.log # Specify the path for concurrent audit logging. #SecAuditLogStorageDir c:\inetpub\log\
設定ファイルを変更するだけではダメで、以下のフォルダに IIS ユーザー(IIS_IUSRS)の書き込み権限を付ける必要があります。
- C:\inetpub\logs
また、下記ファイルを空のテキストファイルで作成しておく必要もあります。
- C:\inetpub\logs\modsec_audit.log
この設定をしておかないと、後でエラーが出たりすることになりますので注意してください。
IIS を再起動して設定終了です。
設定がうまくいくと、以下のようなログが出力されるようになります。
--ba2c0000-A-- [27/Sep/2014:18:27:28 +0900] 18230571293743251523 192.168.11.8:50244 80 127.0.0.1 80 --ba2c0000-B-- GET /?union+select HTTP/1.1 Cache-Control: max-age=0 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: ja,en-US;q=0.8,en;q=0.6 Cookie: wp-settings-1=editor%3Dtinymce%26libraryContent%3Dbrowse; wp-settings-time-1=1407040546 Host: 192.168.11.9 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 --ba2c0000-F-- HTTP/1.1 500 Internal Server Error --ba2c0000-H-- Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:(?:s(?:t(?:d(?:dev(_pop|_samp)?)?|r(?:_to_date|cmp))|u(?:b(?:str(?:ing(_index)?)?|(?:dat|tim)e)|m)|e(?:c(?:_to_time|ond)|ssion_user)|ys(?:tem_user|date)|ha(1|2)?|oundex|chema|ig?n|pace|qrt)|i(?:s(null|_(free_lock|ipv4_compat|ipv4_mapped|ipv4|ipv ..." at ARGS_NAMES:union select. [file "C:\/Program Files/ModSecurity IIS/owasp_crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "143"] [id "959073"] [rev "2"] [msg "SQL Injection Attack"] [data "Matched Data: union select found within ARGS_NAMES:union select: union select"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.9"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"] Action: Intercepted (phase 2) Apache-Handler: IIS Stopwatch: 1411810048243251 2481 (- - -) Stopwatch2: 1411810048243251 2481; combined=810, p1=0, p2=810, p3=0, p4=0, p5=0, sr=0, sw=0, l=0, gc=0 Producer: ModSecurity for IIS (STABLE)/2.8.0 (http://www.modsecurity.org/); OWASP_CRS/2.2.9. Server: ModSecurity Standalone Engine-Mode: "ENABLED" --ba2c0000-Z--
偽陽性の解消
偽陽性の解消は、WAF 導入の大きな課題ですが避けては通れない道でもあります。
偽陽性とは誤検知のことで、正常なリクエストなのに攻撃と検知してしまうことです。ですので、これを放置してしまっては Web サイトとして成り立ちません。
偽陽性が発生したら監査ログ(Audit log)を確認して、ID を見つけます。先ほどのログなら 959073 が ID になります。この ID のシグネチャを監査対象から外すことで、偽陽性の問題を解消します。
解消方法ですが、これといった正解がありませんが、今回は以下のファイルを作成し、対象 ID を除外します。
- C:\Program Files\ModSecurity IIS\customrules.conf
customrules.conf には、以下のように記述します。
SecRuleRemoveById 959073
この customrules.conf を ModSecurity に読み込ませるために、以下のファイルを編集します。
- C:\Program Files\ModSecurity IIS\modsecurity_iis.conf
modsecurity_iis.conf の最後の行に、customrules.conf を読み込ませる命令を記述します。
Include modsecurity.conf Include modsecurity_crs_10_setup.conf Include owasp_crs\base_rules\*.conf Include customrules.conf
これで、IIS を再起動することで、この ID のシグネチャは検査されなくなります。
おわりに
Windows 版 ModSecurity について、いろいろ見てきましたがいかがでしたでしょうか。
正直、めんどうくさいと感じると思います。ですが、こういうめんとうくさいことをしないと Web サイトを安全に守れないのが実情です。WAF の導入は強めの推奨レベルになってきていると思います。
Web サイトを守るために、最新の Windows Server で実績のある ModSecurity を使用できるというのは大きなメリットだと思います。ModSecurity はオープンソースで無料で使用できるというのも大きなメリットです。
この記事によって、皆さんの Web サイトがよりセキュアになれば幸いです。
WAF設定まとめ
WAFの設定については以下のページにまとめていますので、こちらもどうぞ。
コメント