AWS WAFマネージドルールで誤検知した場合の対処法

AWS WAFマネージドルールを利用する際の課題の一つは誤検知の対策になります。万が一誤検知が起きた場合でもマネージドルールを無効化せず対処する方法をまとめました。

#セキュリティ

#AWS WAF

#AWS

臼田佳祐

2018.10.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

皆さんWAF使ってますか？

AWS WAFマネージドルールが実装されてから、安価ながらも用途に合わせたWAFのルールを利用できるようになったため、WAFの民主化が進んでいると思います。

しかしながら、マネージドルールは中身のルールがブラックボックスのため、現状では誤検知が発生した場合の対処が自分で定義したWAFよりも対処しづらい欠点があります。

今回はそれをカバーする方法を紹介します。

ログを取得し確認する

まずは誤検知が起きていることを検知し、原因を確認する必用があります。

以前はサンプルログのみしか取得できませんでしたが、今は下記のようにKinesis Firehose経由でフルログを取得することが可能になっていますので、これを利用してログを取得しましょう。

AWS WAFのログをFirehoseでS3に出力しブロックログをS3Selectで確認してみた

取得したログはS3に格納できるため、Athenaで下記のようにクエリをして確認しましょう。運用中に誤検知に気づく一つの手法は、Athenaでクエリした結果を確認することでしょう。他にはCloudWatchでの監視か、実際のユーザからの通報になると思います。

AWS WAFのフルログをAthenaで分析できるようにしてみた

ログを詳細に確認し、どのような内容のクエリが問題になっているか突き止めましょう。よくある誤検知はselect等のSQLに利用されるキーワードが引っかかるなどです。(AWS WAFマネージドルールでそのような単純な誤検知を確認したことはありませんが)

誤検知を対処する

誤検知に対処する一番簡単な方法は、検知してしまうパターンを明示的に許可することです。

AWS WAFのルールは上から順に適用され、明示的な許可があればその下の拒否ルールは評価されません。下記のようにマネージドルールがある場合には、その上に新しいルールを作成して適用すれば対処完了です。

私の経験上では誤検知が発生したことはありませんので、今回は明らかに止めるべきクエリを利用して対処してみます。

利用するルールはAWS WAF - Web Exploits Rules by F5です。OWASP Top 10に基づいてXSSやSQLiなどを止めてくれる優れものです。

下記はやられサーバで有名なDVWAを利用した例です。

WAFがない状態でSQLインジェクションとなる' or 1=1--'というクエリを送ると、DBにある他の情報を取ることができますが、

F5のルールを利用すると403となりブロックしてくれていることが確認できます。

本来は正しい動作ですが、これを回避するルールを追加します。

今回はクエリストリングに含まれる文字列がキーになっているので、これを条件に設定します。

WAFのコンディション作成の画面からstring match conditionを作成します。TypeをString matchとし、フィルターを作成します。GETのパラメータをマッチさせる方法はいくつかあり、クエリストリングをそのままマッチさせる方法もありますが、せっかくなので先日実装されたAll query parameters (values only)を利用します。これは、クエリストリング全体を意識せず、各パラメータの中身のみをマッチ対象とするフィルターになります。Match typeはContainsとし文字列が含まれていれば反応するようにします。GETパラメータのためURL encodeされるため、TransformationではURL decodeを選択します。Valueは許可したい文字列の一部である1=1とします。本当は、許可しないほうがいいですが。

Add filterして登録されていることが確認できたら、Createを押してコンディションを作成します。

コンディションを作成したら次はルールです。Create Ruleから作成画面に移りAdd conditionsで先程のコンディションを追加します。パターンに一致したものを許可したいため、does, ...string match condition, 先程のコンディションを選択して作成したコンディションの内容が表示されていることを確認したらCreateします。