| Oracle® Traffic Director管理者ガイド 11g リリース1 (11.1.1.9) B66436-05 |
|
 前 |
 次 |
この項では、Webアプリケーションを主な攻撃から保護するためのルールについて説明します。
ブルート・フォース攻撃は、攻撃者がユーザー名、パスワード、電子メール・アドレスなどの資格証明を推測して、リソースへのアクセスを何度も試みる攻撃です。ブルート・フォース攻撃は防御機能がないシステムに対して非常に高い効力を発揮し、ユーザーが短くて覚えやすいパスワードを使用している場合の効力は顕著です。
ブルート・フォース攻撃を阻止する最も効果的な方法は、ログイン試行回数に制限を設け、制限回数を超えた後のログインを遅延させるかブロックする方法です。次に、Oracle Traffic DirectorのWebアプリケーション・ファイアウォールで、これを実現するための例を示します。
ログイン検証ページがyoursite.com/loginにあり、仮想サーバーwaf-vsによって提供される場合、仮想サーバー・レベルで構成されたwaf-vs.confファイル内の次のルールによって、ユーザーのログイン試行回数を追跡できます。
# Block further login attempts after 3 failed attempts
# Initalize IP collection with user's IP address
SecAction "initcol:ip=%{REMOTE_ADDR},pass,nolog"
# Detect failed login attempts
SecRule RESPONSE_BODY "Unauthorized" "phase:4,pass,setvar:ip.failed_logins=+1,expirevar:ip.failed_logins=60"
# Block subsequent login attempts
SecRule IP:FAILED_LOGINS "@gt 2" deny
このルールは、IPコレクションを初期化し、ログイン試行が失敗するたびIP:FAILED_LOGINSフィールドをインクリメントします。ログイン試行の失敗数が3回を超えると、それ以降の試行はブロックされます。ログイン試行の失敗回数は60秒後にexpirevarアクションによってゼロにリセットされるため、ブロックされる期間は最大で60秒です。
永続コレクションIPを使用する場合は、永続データを保存するパスをSecDataDirディレクティブを使用して指定する必要があります。このディレクティブのスコープはMainです。そのため、サーバー・レベルで指定する必要があります。これは次のようにして行います。
# The name of the debug log file SecDebugLog ../logs/brute_force_debug_log # Debug log level SecDebugLogLevel 3 # Enable audit logging SecAuditEngine On # The name of the audit log file SecAuditLog ../logs/brute_force_audit_log # Path where persistent data is stored SecDataDir "/var/run/otd/waf/"
このルール・ファイルがwaf-server.confという名前である場合、<instance-dir>/config/server.xmlは次のようになります。
<server>
...
...
<webapp-firewall-ruleset>/waf-rules/waf-server.conf</webapp-firewall-ruleset>
...
...
<virtual-server>
<name>waf-vs</name>
<host>yoursite.com</host>
...
<object-file>waf-vs-obj.conf</object-file>
<webapp-firewall-ruleset>/waf-rules/waf-vs.conf</webapp-firewall-ruleset>
</virtual-server>
...
...
</server>
Webアプリケーション・ファイアウォールおよびレスポンス本文の処理(SecResponseBodyAccessディレクティブと同等)を、waf-vs-obj.conf内の/login URIに対して有効にする必要があります。waf-vs-obj.confは次のようになります。
<Object name="default"> <If $uri eq "/login"> AuthTrans fn="webapp-firewall" process-response-body="on" </If> ... ... </Object>
ログイン試行が3回失敗すると、監査ログに次のメッセージが記録されます。
--5c4adf36-A-- [19/Mar/2013:05:06:57 --0700] ygfh3010000000000,0 127.0.0.1 49619 127.0.0.1 5021 --5c4adf36-B-- GET /acl/acl02.html HTTP/1.1 user-agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 accept: */* host: yoursite.com authorization: Basic YWxwaGE6YmV0YQ== --5c4adf36-F-- HTTP/1.1 403 Forbidden status: 403 Forbidden content-length: 208 content-type: text/html --5c4adf36-H-- Message: Warning. Unconditional match in SecAction. [file "/waf-rules/waf-vs.conf"] [line "10"] Message: Access denied with code 403 (phase 2). Operator GT matched 2 at IP:failed_logins. [file "/waf-rules/waf-vs.conf"] [line "25"] Action: Intercepted (phase 2) Stopwatch: 1363694817000000 898560 (- - -) Stopwatch2: 1363694817000000 898560; combined=370, p1=14, p2=336, p3=0, p4=0, p5=19, sr=131, sw=1, l=0, gc=0 Producer: ModSecurity for Apache/2.6.7 (http://www.modsecurity.org/). Server: Oracle Traffic Director/11.1.1.7 --5c4adf36-Z--
SQLインジェクション攻撃は攻撃者がWebアプリケーションにデータを送り込むことができる場合に発生し、サニタイズされていない形式のデータがSQL問合せで使用されます。そのため、Webアプリケーション開発者が意図したものとは完全に異なる動作をSQL問合せが実行する恐れがあります。たとえば、MySQL表からすべてのレコードを削除するなどの攻撃を受ける可能性があります。
http://www.example.com/login.php?user=user1';DELETE%20FROM%20users--
これは次のディレクティブを使用することで回避できます。
SecDefaultAction "phase:2,log,auditlog,deny,status:403" SecRule ARGS "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*" "t:lowercase,msg:'SQL Injection'"
Webアプリケーション・ファイアウォール・エンジンがこのようなリクエストを検知すると、次のようなコードがaudit_logに記録されます。
--3923b655-A-- [20/Mar/2013:02:58:35 --0700] Xkjx6010000000000,0 127.0.0.1 35971 127.0.0.1 5021 --3923b655-B-- GET /acl/acl02.html?user=user1';DELETE%20FROM%20users-- HTTP/1.1 host: waf.test.com connection: close --3923b655-F-- HTTP/1.1 403 Forbidden status: 403 Forbidden content-length: 208 content-type: text/html connection: close --3923b655-H-- Message: Access denied with code 403 (phase 2). Pattern match "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\\s*" at ARGS:user. [file "/waf-rules/sql_injection_attack.conf"] [line "2"] [msg "SQL Injection"] Action: Intercepted (phase 2) Stopwatch: 1363773515000000 668049 (- - -) Stopwatch2: 1363773515000000 668049; combined=131, p1=8, p2=104, p3=0, p4=0, p5=19, sr=0, sw=0, l=0, gc=0 Producer: ModSecurity for Apache/2.6.7 (http://www.modsecurity.org/). Server: Oracle Traffic Director/11.1.1.7 --3923b655-Z--
攻撃を受け、SecDefaultActionが適用されます。この場合、リクエストは拒否されてログに記録され、攻撃者には403エラーが返されます。リクエストをカスタムの警告メッセージを表示するHTMLページにリダイレクトするなど、別のアクションを実行する必要がある場合は、次のように、使用するアクションをルールで指定します。
SecRule ARGS "(select|create|rename|truncate|load|alter|delete|update|insert|desc)\s*" "t:lowercase,msg:'SQL Injection',redirect:http://yoursite.com/invalid_request.html
クロスサイト・スクリプティング(XSS)攻撃は、ユーザー入力が適切にサニタイズされずにページがユーザーに戻される攻撃です。そのため、攻撃者が悪意のあるスクリプトをページへの入力としてページに組み込むことが可能になります。このスクリプトはWebサイトの作成者がページに含めたスクリプトと違いがないため、cookieデータやセッションIDの読取り権限など、ページ内の通常のスクリプトと同様の権限を付与されます。
次に、リクエスト・パラメータ内の<scriptをブロックする簡単なルールの例を示します。
SecDefaultAction phase:2,deny,status:403,log,auditlog SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "(?i:<script.*?>)" "phase:2,capture,t:none,t:htmlEntityDecode,t:compressWhiteSpace,t:lowercase,block,msg:'Cross-site Scripting (XSS) Attack',id:'101'"
