| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.3.0) E90199-04 |
|
 前 |
Webアプリケーション・ファイアウォールには、監査ロギング、任意のリクエスト(本文など)およびレスポンスの一部へのアクセス、柔軟性の高いルール・エンジン、ファイル・アップロード遮断、リアルタイム検証、バッファ・オーバーフロー保護などの機能があります。
Webアプリケーション・ファイアウォールの機能は主に4つの領域に分類できます。
解析: パーサーはリクエストまたはレスポンス(あるいはその両方)のビットを抽出して保存します。これらのビットはルールで使用されます。
バッファ: 標準的なインストールではリクエスト本文とレスポンス本文の両方がバッファされるため、通常このモジュールはリクエスト(処理を行うアプリケーションに送信される前)とレスポンス(クライアントに送信される前)を完全な形で確認できます。バッファは、信頼性の高い阻止機能を実現するのに最も適した手段です。
ロギング: ロギングではHTTPトラフィックが完全な形で記録されるため、すべてのレスポンス/リクエストのヘッダーおよび本文をログ記録できます。
ルール・エンジン: ルール・エンジンは他のコンポーネントからの情報に対して機能し、トランザクションを評価して、必要に応じてアクションを実行します。
収集した情報に特定のコンテンツや悪意のあるコンテンツが含まれていないかどうかは、Webアプリケーション・ファイアウォールのルール・エンジンでチェックされます。
この項では、基本的なルール記述構文とWebアプリケーションを攻撃から保護するためのルール・ディレクティブについて説明します。
ルールの作成に使用するメインのディレクティブはSecRuleです。SecRuleの構文は次のとおりです。
SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]
VARIABLES: チェックするHTTPトランザクション内の場所を指定します。Webアプリケーション・ファイアウォールによってrawトランザクション・データが前処理されるため、ルールの処理を検知ロジックに限定させることができます。ルールでは1つ以上の変数を指定する必要があります。| 演算子を使用すると、1つの変数で複数のルールを使用できます。
OPERATORS: 変換された変数の分析方法を指定します。演算子は常に文字@で始まり、次に空白が続きます。1つのルールに指定できる演算子は1つのみです。
TRANSFORMATION_FUNCTIONS: ルール演算子が実行される前に入力を変更します。ルールでは1つ以上の変換関数を指定できます。
ACTIONS: ルールがtrueに評価されたときに実行するアクションを指定します。たとえば、エラー・メッセージを表示したり、別のルールに進んだり、別のタスクを実行するなどのアクションです。
次にルールの例を示します。
SecRule ARGS|REQUEST_HEADERS "@rx <script" msg:'XSSAttack',deny,status:404
ARGSとREQUEST_HEADERSは変数です(リクエスト・パラメータとリクエスト・ヘッダー)。
@rxは正規表現演算子です。これは変数内のパターンと照合する場合に使用します。
この例では、<scriptがパターンです。
msg、denyおよびstatusは、パターンが一致したときに実行するアクションです。
この例のルールはXSS攻撃を阻止するためのルールです。リクエストのパラメータおよびヘッダーに<scriptパターンがないかどうかをチェックし、XSS攻撃のログ・メッセージを生成します。404ステータス・レスポンスとともに一致したリクエストは拒否されます。
この項では、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'"
