hashdos攻撃をmod_securityで防御する(Ubuntu+apt-get編)

このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。Ubuntu環境でapt-getによりApacheを導入しているサイトに対して、apt-getによりmod_securityを導入するというシナリオで説明します。

はじめに

背景などについては昨日のブログを参照してください。
このエントリでは、hashdos対策を目的として、Ubuntu環境にapt-getによりmod_securityを導入する方法を説明しますが、mod_securityに対する情報があまりないため、いったんフルのmod_securityを導入した後、hashdos専用のカスタマイズを施すという流れで説明します。

Ubuntuにapt-getでmod_securityを導入する

ModSecurity Handbookによると、DebianおよびUbuntuに対して、mod_security用のパッケージが用意されている（同書P31）ということですので、試してみましょう。

# apt-get install libapache-mod-security

これでmod_securityのインストールは終わりです。簡単ですね。

mod_securityの設定

CentOSの場合と異なり、上記の状態では、mod_securityの設定はされていないようです。そこで、手動で設定する方法を説明します。
/usr/share/doc/mod-security-common にドキュメントとサンプルルール（実体はCRS2.0.3）がコピーされていますので、これを使います。最新のCRSはバージョン2.2.3ですので、サンプルとして導入されるCRSはかなり古いものですが、hashdos対策をする観点からは十分です。また、mod_securityとCRSはバージョン依存があるため、CRSのみ最新のものを入れてもエラーになる可能性が高いのです。最新のCRSを使いたい場合は、最新のmod_securityをソースからビルドしてください。その方法は次回説明します。

まず、/usr/share/doc/mod-security-common/examples/rules 以下のルールを/etc/apache2/modsecurity にコピーします。

# cd /etc/apache2/
# cp -R /usr/share/doc/mod-security-common/examples/rules modsecurity

ルールから logs というディレクトリをログ書き出し用に参照しているので、シンボリックリンクで /var/log/apache2 を指すようにしておきます。

# ln -s /var/log/apache2 logs

Ubuntuの習慣に従い、/etc/apache2/mods-available にmod_securityのconfファイルを作成します。

# vi /etc/apache2/mods-available/mod-security.conf

内容は以下の通りです。

Include modsecurity/*.conf
Include modsecurity/base_rules/*conf

保存した後、a2enmodコマンドでこの設定を反映します。

# a2enmod mod-security

modsecurity_crs_10_config.confというファイルを変更します。

# vi /etc/apache2/modsecurity/modsecurity_crs_10_config.conf

変更内容は以下の通りです。

SecResponseBodyAccess Off ← On から Off にする

これは、レスポンスの中身のチェックをしないという設定です。以上でmod_securityの通常設定は終わりです。

mod_securityの動作確認

次に、mod_securityの動作確認をします。apacheを起動してください。/var/log/apache2以下に、modsec_audit.log と modsec_debug.log ができていれば、正常に起動されています。
まず正常系のアクセスを確認します。以下のURLはサンプルですので、既存コンテンツのURLを指定して下さい。

http://example.jp/index.php

次に、以下がmod_securityによりブロックされることを確認します。既存コンテンツの後ろに、「?union+select」をつけてアクセスします。

http://example.jp/index.php?union+select

403 Forbiddenのエラーが表示されれば、mod_securityが稼働していることになります。

mod_securityのカスタマイズ

次に、hashdos向けのカスタマイズです。再び、modsecurity_crs_10_config.confを変更します。

# vi /etc/apache2/modsecurity/modsecurity_crs_10_config.conf

変更内容は以下の通りです。

SecRequestBodyInMemoryLimit 131072 の後ろに以下を追加する
# 追加
SecRequestBodyLimit 5242880
SecRequestBodyNoFilesLimit 51200

この例では、リクエストボディサイズを5Mバイトに増やし、SecRequestBodyNoFilesLimitを50Kに設定しています。SecRequestBodyNoFilesLimitは、ファイルアップロード以外のPOSTサイズの制限（application/x-www-form-urlencoded形式の場合に有効）なので、hashdosに効果があります。5Mと50Kは、Webサイトの要件にあわせて調整して下さい。

次に、/etc/apache2/modsecurity/base_rules/modsecurity_crs_23_request_limits.conf を修正します。以下の部分を修正します。

# Maximum number of arguments in request limited
SecRule &ARGS "@gt 255" "phase:2,t:none,block,nolog,auditlog,status:403,msg:'Too many arguments in request',id:'960335',severity:'4',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+5,setvar:tx.policy_score=+1,setvar:tx.%{rule.id}-POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"

変更後の内容は以下の通りです。

# Maximum number of arguments in request limited
SecRule &ARGS "@gt 255" "phase:2,t:none,deny,nolog,auditlog,ctl:auditLogParts=ABDFGH,status:413,msg:'Too many arguments in request',id:'960335',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+20,setvar:tx.policy_score=+1,setvar:tx.%{rule.id}-POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"

主な変更点は以下の通りです。

• パラメータ数が255を超えたら直ちに遮断する
• ログを取得するが、リクエストボディは出力しない（昨日の記事参照）

パラメータ数上限値255がハードコーディングされているので、Webアプリケーションの正常系のパラメータ数が255を超える場合は、この値を変更してください。
以上でhashdos向けのカスタマイズは終わりですが、昨日の記事同様、hashdos以外のルールを無効にします。本格的にmod_securityを使う（SQLインジェクションやXSS等の対策にも用いる）場合は、以下の作業は省略しますが、その代わりmod_securityの過剰検知を検出して該当するルールを無効化するというチューニングが必要です。

*追記(2012/1/18)
Cookieによるhashdos攻撃が可能であり、上記のルールではCookieによる攻撃を防御できませんので、以下のルールを追加するとよいでしょう。

SecRule &REQUEST_COOKIES "@gt 30" "phase:2,t:none,deny,nolog,auditlog,ctl:auditLogParts=AF
HZ,status:413,msg:'Too many cookies in request',id:'960336',severity:'2',setvar:'tx.msg=%{
rule.msg}',setvar:tx.anomaly_score=+20,setvar:tx.policy_score=+1,setvar:tx.%{rule.id}-POLI
CY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"

"@gt 30"がCookie数の上限でハードコーディングされています。適宜変更してください。

(追記終わり)

mod-security.confを修正します。

# vi /etc/apache2/mods-available/mod-security.conf

Include modsecurity/*.conf
### Include modsecurity/base_rules/*conf ← 削除またはコメントアウト
# 以下を追加
Include modsecurity/base_rules/modsecurity_crs_23_request_limits.conf
Include modsecurity/base_rules/modsecurity_crs_49_enforcement.conf
Include modsecurity/base_rules/modsecurity_crs_60_correlation.conf

昨日の記事では、49と60のルールも無効化していましたが、CRSの仕組みをきちんと動かすにはこれらのルールがあった方が良いようですので、残しています。なくてもhashdosに対する保護はできます。

以上の修正の後、apacheを再起動してください。
昨日も書きましたが、mod_securityの副作用の可能性があるので、一通りのアプリケーションのチェックをしておくべきです。とくに、ファイルアップロードが影響を受けやすいので、ファイルアップロード機能がある場合（このエントリが想定しているサイトですが）は、必ずファイルアップロードが正常に動作することを確認してください。

まとめ

Ubuntにapt-get環境でApacheを導入している環境向けに、mod_securityによるhashdos対策の方法を説明しました。
次回は、mod_securityをソースからビルドする方法について説明します。


[PR]
hashdosやApacheKillerその他、Webサイトのセキュリティ強化策についての相談は、HASHコンサルティング株式会社まで。
「安全なWebアプリケーションの作り方」DRMフリーのPDFによる電子版もあります。