企業がWAFを導入するにあたって頭を悩ませるポイントはいくつかありますよね。
いま世の中ではどんな攻撃が蔓延ってるのか、それらの攻撃からサービスを守るにはどんなポリシーを定義すればいいのか、そのポリシーの運用をどうするか等々。社内に専門のセキュリティチームがいれば良いですが、そうでない場合にWAFを0から設計するというのはなかなかに骨が折れる作業です。
AWS WAFではそんな負担を軽減する為にマネージドルールなるものが提供されているんですが、個人的にはこれがどうにもこうにもイケてないんじゃないかと思っています。というのもマネージドルールでは誤検知対策がほぼできないからです。
今回は一見便利そうに思えるマネージドルールでも実際使ってみるとハマリポイントがいくつかあるよって話をします。
マネージドルールとは
AWS WAFのマネージドルールとは、セキュリティベンダが独自に作成したWAFのルールセットを、我々ユーザが簡単に使えるようにしたサービスです。以下、公式からの抜粋です。
つまりセキュリティベンダが用意したWAFルールを使えば、最新の脆弱性や攻撃手法からアプリを守るようにポリシーが自動更新されるので、自分たちでルールの管理を行う必要がなく楽をできるということですね。話だけ聞くと良さげな感じなんですが、残念ながらそう簡単ではありません。
マネージドルールの何が厄介なのか、メリットとデメリットを順に説明します。
マネージドルールのメリット
マネージドルールを導入することで得られるメリットは大きく分けてこの2つです。
- 1つのルール枠で複数の保護ポリシーを定義できる
- ルールの運用をセキュリティベンダに任せられる
1つのルール枠で複数の保護ポリシーを定義できる
AWS WAFにはレギュラールール、レートベースルール、マネージドルールという3種類のルールタイプがあり、これらをWebACLに関連付けることでWAFを機能させることができます。
2018年6月現在、1つのWebACLに関連付けられるルール数の上限は10個までです。従って、様々な攻撃に対する保護ルールやそれらを部分的に除外するバイパスルールなどをふんだんに盛り込みたくとも、そもそものルール枠が10しかないのでどうしても防御できる範囲は限られてしまいます。
しかしながら、実は1つのマネージドルールの中には複数の攻撃に対する保護ポリシーが定義されています。例えば「Fortinet Managed Rules for AWS WAF – Complete OWASP Top 10」であれば、OWASPで防御が推奨されているクロスサイトスクリプティングやSQLインジェクションなどへの対策や、セキュリティベンダ(ここではFortinet)によってスパムと判断されているIPやUserAgentなどを検知するポリシーが盛り込まれています。
自前でレギュラールールやレートベースルールを作ってマネージドルールと同等の保護をするには複数のルールを用意しなければなりませんが、マネージドルールを使えば1ルールのみで済むのでルール枠を節約することができ、より広範な防御が可能です。
ポリシーの運用をセキュリティベンダに任せられる
マネージドルールであれば、ベンダが業界の動向を追いながら最新の保護ポリシーを定義・更新してくれるので、我々ユーザの運用コストを軽減できるのもメリットです。
最初に挙げた「いま世の中ではどんな攻撃が蔓延ってるのか、それらの攻撃からサービスを守るにはどんなポリシーを定義すればいいのか」という課題を解決するのにマネージドルールは役立つと思います。
ただし、それはあくまでも保護対象のアプリケーションがマネージドルールに適応できればの話です。マネージドルールを適用することで誤検知が発生してしまうようなアプリケーションの場合、マネージドルールの導入は非常に困難になります。
マネージドルールのデメリット
マネージドルールの致命的なデメリットを2つ挙げます。
- ポリシーの仕様がブラックボックス
- ポリシーのチューニングができない
他にも「提供元が海外ベンダだとサポートが日本語非対応」だったり「レギュラールールに比べて利用コストがかかる」など細かいデメリットもあるんですが、何よりマネージドルールの最大の欠点はポリシーの仕様が分からないのでチューニングもできないというこの2点に尽きます。
つまりこれは誤検知の対策が全くできないことを意味します。
マネージドルールが抱える誤検知問題
WAFを適切に導入すれば悪意あるアクセスをブロックすることができます。この「適切に」がWAFの設計において最も難しいポイントです。
ポリシーが弱すぎれば攻撃を素通ししてしまいますし、ポリシーが強すぎれば攻撃ではない正常なアクセスまでブロックしてしまいます。攻撃をブロックしつつ、正常なアクセスをブロックしないようにポリシーをチューニングできるかどうかがWAF導入の要と言えるでしょう。
あいにく、現時点でのマネージドルールではこのチューニングがほとんどできません。なぜチューニングができないのか、誤検知事例と共にその理由を説明します。
UserAgentの制御による誤検知事例
マネージドルールは「セキュリティベンダが業界の動向を追いながら最新の保護ポリシーを定義・更新してくれる」サービスです。当然、我々ユーザ個々のアプリケーションの挙動を考慮した設計にはなっていません。
先ほどFortinetのマネージドルールは「スパムと判断されているUserAgentを検知できる」と書きました。このマネージドルールを適用させたWebACLは、”特定のUserAgent名” が “リクエストパラメータのどこか” に含まれている場合に「悪意ある攻撃である」と解釈します。
ここ注意が必要です。
“特定のUserAgent名” が “リクエストヘッダのUser-Agentパラメータ” に含まれている場合ではありません。
“特定のUserAgent名” が “リクエストパラメータのどこか” に含まれている場合です。
(※2018年6月現在の挙動です)
これはなかなか厄介な仕様です。
例えば保護対象のアプリケーションが何かしらのランダム文字列をパラメータとして受け取る仕組みだとしましょう。通販サイトの楽天で言えば商品IDやアフィリエイトリンク用のユーザIDなどの識別コードがURIに含まれてます。このランダム文字列がたまたま該当のUserAgent名と一致していたり、部分的にUserAgent名を含んでしまっているだけで、マネージドルールは「リクエストURIに悪意ある文字列が含まれている」と解釈し、そのリクエストをブロックしてしまうんです。
もちろん識別コードについてはアプリケーション側の設計を変えてしまえば回避できるかもしれませんが、ではSNSなどのユーザ投稿を受け付けるサービスを運営している場合はどうでしょうか。やはりこの場合も同様に、あるユーザがあるUserAgent名を含むツイートや検索をしただけで（決して悪意ある攻撃ではなくとも）ブロックされてしまうんです。これはちょっとユーザビリティ的に問題がありますよね。
ポリシーの仕様がブラックボックス
では実際にどんなUserAgent名がブロックされてしまうのでしょうか。残念なことに、マネージドルール内で定義されてるパラメータは我々ユーザには一切公開されていません。公開するということは抜け道を教えるということにもなるので、セキュリティベンダとしては今のところ非公開の方針のようです。
僕が検証した限りでは、少なくともFortinetのOWASP Top10のルールでは”libwww”というUserAgent名がブロックされることは確認しました。もし楽天がこのマネージドルールを導入してしまうと、サイト内検索で”libwww”を検索した場合に100%ブロックされてしまいます。
興味のある方は実際にご自身で検証用のwebサーバを用意して、OWASP Top10のマネージドルールをブロックアクションで適用させてからURIにlibwwwを含めてアクセスしてみてください。仕様が変更されていなければ、403 Forbiddenエラーが返ってくるはずです。
どうやら今はURIでは検知されなくなっているようですが「リクエストヘッダ」に含まれている場合はまだ検知されてしまいます。従って、User-Agentヘッダはもちろん、それ以外のヘッダでもlibwwwが含まれている場合は403 Forbiddenエラーが返ってきます。
当然、libwwwだけでなく他にもスパム判定されるUserAgent名は色々あるはずです。企業によっては、自社の商品名がたまたまこれらのUserAgent名と一致するケースだってあるかもしれません。ユーザが商品検索やお問い合わせフォームなどからその商品名を送信しようものなら、それだけでスパムとみなされて誤検知ブロックされてしまうリスクがマネージドルールにはあります。
POSTのリクエストパラメータはサンプルリクエストに残らない
ちょっと面倒なのがPOSTで誤検知した場合です。
GETのリクエストパラメータならサンプルリクエスト(AWS WAFのログ)に検知された原因がURIとして残りますが、POSTのリクエストパラメータはサンプルリクエストには残りません。CloudFrontやALBのログにも吐かれませんし、apacheやnginxなど代表的なwebサーバのアクセスログにもデフォルトでは吐かれません。つまり、デフォルトではPOSTのリクエストパラメータはどこにも残らないんです。したがって、POSTリクエストをブロックしてしまうと原因調査ができず迷宮入りする可能性が高くなります。
まぁこれはレギュラールールでもレートベースルールでも同じなんですが、これらは自前で作るものなので「条件」を見れば検知の原因をある程度推測することは可能です。マネージドルールは仕様が非公開なので調査が本当に難しくなります。
ポリシーのチューニングができない
このような誤検知が発生した場合の回避策としては、ブロックされるルールよりも上位にバイパスルール(回避ルール)を定義して、「ブロックされる前に許可をする」方法が考えられます。
WebACLは1～10までの優先順位でそれぞれのルールがリクエストを評価する仕組みので、マネージドルールを下位に置き、それより上位にバイパスルールを定義することで理屈上は回避が可能です。しかし、上述の通りマネージドルールは仕様が完全に非公開であるため、どんな文字列をバイパスすべきか予測がつきません。libwwwをいい感じにバイパスしたとしても、また別の文字列が誤検知されるリスクは残るので結局焼け石に水です。
そもそもルール枠は10個しかないので、仮にベンダから情報が公開されたとしてもバイパスルール枠が足りない可能性すらあります。
他にも誤検知いろいろあるよ
分かりやすそうな例としてUserAgent名での誤検知を紹介していますが、マネージドルールで定義されているポリシーは各ベンダによってそれぞれ異なります。webサーバの脆弱性に対する攻撃に特化したマネージドルールもあれば、WordPressなどCMSへの攻撃に特化したマネージドルールもあり内容は様々です。
これら全てで誤検知は起こり得ますし、そのリスクに対する回避策も打ちにくいというのが現状のマネージドルールの作りです。
ポリシーが更新されることで生まれる誤検知リスク
導入時点では誤検知が全くなくても、ベンダがポリシーを更新することで将来的に誤検知が発生するようになるリスクも当然あります。おそらくベンダはユーザの都合などお構いなしにポリシーを更新するでしょうから、いつ誤検知が発生してもおかしくない状態に陥ります。ポリシー更新のタイミングだけ一時的にカウントアクションに切り替えて様子を見るといった対策が打てればいいのですが、現時点ではそのような制御を行う機能も提供されていません。
まとめ
ということで、個人的に現時点のマネージドルールでは、不特定多数のユーザが利用するサービスを保護するのはなかなか難しいんじゃないかなという印象です。マネージドルールを導入する場合には、自分たちのアプリケーションが本当に適応できるのか事前に充分な検証を進めた方が良いと思います。少なくとも誤検知を許容できないアプリには導入すべきではないです。
- マネージドルール内で定義されているポリシーの公開（さらに言えば各ポリシーを個別に有効化/無効化する制御）
- ベンダ側がポリシーを更新するときの一時的なカウントへの切り替え（これも有効化/無効化する制御）
- WebACLに適用できるルール数の上限撤廃（少なくとも10は少なすぎ）
- 完全なブロックログの出力（サンプルではなく、漏れなく完全に網羅したブロックログ）
みたいなところを対応してくれると使いやすくなってきそうですが、AWSさん対応して頂けるでしょうか。現状の仕様でAWS WAFを採用するなら、マネージドルールを使わずに自前でアプリケーションの挙動に沿ったポリシーを定義したほうが誤検知リスクは確実に抑制できると思います。
こんな記事も読まれてます
 |
20代30代の客先常駐ITエンジニアが最速で年収を上げる方法 この記事の所要時間： 約 14分56秒
この記事の所要時間： 約 14分56秒 もしあなたが以下の3つ全てに該当するエンジニアであれば、今すぐにでも転職をオススメします。 客先常駐型のエンジニアとして働いている 案件の途中で契約を切られるこ … |
