WAF(Web Application Firewall)とは、通常のレイヤー2や3（IP, TCP/UDP）レベルのファイアーウォールよりもさらに上のレベルのアプリケーション層のファイアーウォールです。アプリケーションはレイヤー7とも言われ、ネットワークスイッチなどではアプリケーションの中身まで参照してスイッチングするスイッチはレイヤー7スイッチと呼ばれてきましたが、ファイアーウォールではレイヤー7ファイアーウォールと呼ばれる事は少なく、WAFと呼ばれる事が多いです。
WAFの目的は名前からも明白です。Webアプリケーションを脅威から守るために利用されます。WAFはWebアプリケーションをセキュリティ上の脅威から守る事ができますが、昔レイヤー2/3のファイアーウォールの能力が誇大に広告され、誤った認識で利用されていたように、WAFの能力も誤解されている事が少なくありません。
国連サイトがマルウェアを配布
国連のサイトは昨年8月にページが改竄されました。
画像では分かり辛いですが、クラッカーにより反戦のメッセージが右下の部分に書き込まれています。
こちらは文字が大きいので反戦のメッセージが書き込まれている事が判別できると思います。
当然国連はこの問題に対処しました。しかし、CNET NEWSではこの改竄事件後のWebサイト改修後にもリスクが残っている事を報道しています。
Hacked U.N. Web site still at risk?
http://www.news.com/8301-10784_3-9758843-7.html
国連のサイトにSQLインジェクションの脆弱性があるとレポートされた方によると国連は脆弱性自体を修正するのではなくWAFだけ導入したそうです。その結果マルウェア配布に利用されてしまいました。
サイトの記述からするとWAFだけ入れいたので、最近流行りのASPサイトを目標としたSQLインジェクション攻撃でドライブバイダウンロードに利用されたようです。
ところでゴールデンウィーク明けからISS/ASPサイトに対するSQLインジェクション攻撃の第2波が観測されています。ご注意ください。
WAFに対する誤解
- WAFが対応する脆弱性なら大丈夫
- WAFを導入すればセキュリティ監査が不必要になる
- 脆弱性は修正しなくても大丈夫
WAFを導入していてもアプリケーションの脆弱性は修正しなければ、攻撃可能となってしまう状態は当たり前のようにあります。WAFの防御を回避した攻撃は多くあるのです。さらに、WAFが対応している脆弱性でもその攻撃に対する対処が無効であれば役に立ちません。WAFが対応していたにも関わらず防御が有効でなかったため、結局攻撃可能であった例もよくあります。この様な事例は私もセキュリティチェックを行っている際に発見した事があります。
WAFだけでは防御不可能
WAFを導入してもアプリケーションの脆弱性を完全に保護することは不可能です。WAFの防御方法はブラックリスト方式であるため予め分かっている脆弱性しか保護できません。しかも、全ての防御用の定義を利用すると、負荷の高いサイトでは、速度が遅すぎて使い物にもなりません。仮に速度が十分に速かったとしても全ての定義を有効にするとアプリケーションが正常に動作できなくなります。
アプリケーションロジックに誤りがあってもWAFには判別不可能です。例えば、権限を持たないユーザが本来参照または変更できてはならないデータを参照・変更できてしまう。認証済みのユーザだけが利用できる機能が認証無しで利用できてしまう。クッキーに保存してはならないデータ、パスワード等、を保存している、などこれらの脆弱性はWAFでは判別できません。今時クッキーにユーザ名とパスワードを保存するようなアプリケーションは無い、と思うかもしれませんがPloneやSerendipidy等、最近までユーザ名とパスワードをクッキーに保存していた有名で人気も高いアプリケーションもあります。オープンソースのアプリケーションですらこの有様です。セキュリティを意識せずに作られたアプリケーションにこれらの脆弱性があっても不思議ではありません。
今までの説明からも明らかなように、WAFがあるからといってセキュリティ監査が不要になる訳ではありあません。セキュリティ基準の中にはWAFの導入かセキュリティ監査の実施を求める物もあります。新しいPCI DSS（Payment Company Industry Data Security Stantdard）ではWAFを導入するか、セキュリティ監査を受けるかどちらかを行うように求めています。この要求事項はどちらか行えばよいようになっていますが、実際には両方必要です。どちらか一つを選択するならアプリケーション全体のセキュリティ監査を行った方がよいでしょう。
WAFの導入を検討するよりセキュリティ監査を検討すべき
セキュリティ監査には、リスク分析も含まれます。セキュリティ監査から得られる脆弱性情報も重要ですが、リスク分析やベストプラクティスとの比較も非常に有用です。自分が利用しているアプリケーションにどれほどのリスクが有るのか分析しないと、どの程度のコストをかけて対処すべきか判断できません。セキュリティ対策としてWAFを導入するのであれば、セキュリティ監査を受けそのリスク分析の結果から判断すべきです。
前回のエントリのような簡単なWAFであっても十分IPSとして機能できます。Apacheを利用しているならmod_securityでより高度な制御も可能です。大規模なサイトでなければアプリケーション自身を安全な状態に保ち簡易なWAFで防御する方がコストメリットが大きいでしょう。
WAFは無用の長物か
WAFは不必要なネットワークコンポーネントではありません。サイトを安定運用させるには重要なコンポーネントです。例えば、内部監査や善意ある外部のハッカーにより脆弱性が指摘された場合でも、直ぐに脆弱性に対処、修正するのは難しい場合も少なくありません。利用しているアプリケーションの新しいバージョンで脆弱性が修正されていても、直ぐにバージョンアップできない事もは良くあることです。
この様な場合、攻撃されるリスクを最小限にしつつ運用を継続するためWAFは非常に有効です。
基本的な攻撃ならWAFでも効果的に排除できる場合もあります。これは簡易WAFでも可能です。ヌル文字、改行文字などの特殊文字がユーザエージェントやクッキー等に含まれていないかチェックし、挿入が検出された場合に送信元のIPアドレスからの接続を無条件で拒否する等の対処していれば、うっかりミスで脆弱性があった場合でも攻撃されずに済む事もあるでしょう。
Leave a Comment