自社のWebサイトや、顧客が使う予約・会員向けのWebアプリケーションを守る方法を調べると、WAF（Web Application Firewall）という言葉に行き当たります。名前にファイアウォールと付いていますが、従来のファイアウォールとは見ている場所が違います。この記事では、WAFが何を見て何を止めるのか、何は止められないのか、導入と運用で決めるべきことを整理します。

ファイアウォールとWAFは見ている場所が違う

従来のファイアウォールは、通信の宛先と種類を見て、通すか止めるかを決めます。どのIPアドレスから、どのポートへの通信かが判断の材料で、通信の中身までは見ません。建物でいえば、入口で「どの部屋に行く人か」を確認する守衛です。

WAFは、Webサイトやアプリケーションに届くHTTP／HTTPSの通信の中身を見ます。入力欄に何が書かれているか、どのURLに何が送られてきたか。その内容が攻撃のパターンに当てはまれば止めます。建物でいえば、窓口で書類の中身を確認する係です。

Webサイトへの攻撃の多くは、正規の入口（80番や443番のポート）を通って、正規の形式（HTTPリクエスト）で届きます。守衛は通してしまいます。だから、中身を見る係が別に必要になります。

WAFが防げる攻撃

WAFが得意なのは、Webアプリケーションの入力を悪用する攻撃です。

  • SQLインジェクション。入力欄にデータベースへの命令を紛れ込ませ、情報を抜き取ったり改ざんしたりする攻撃
  • クロスサイトスクリプティング。Webページに不正なスクリプトを埋め込み、閲覧した利用者の情報を盗む攻撃
  • OSコマンドインジェクション、パストラバーサル。サーバーに命令を実行させたり、見えないはずのファイルを読み出したりする攻撃
  • 公表された脆弱性を狙う既知の攻撃パターン。製品やプラグインの脆弱性が公表されると、その穴を突く通信が広く送られます。WAFのルールが対応していれば、修正版を適用するまでの時間を稼げます

ClickFixの記事で取り上げた改ざんされた5,400件のWebサイトの多くは、更新が止まったCMSでした。改ざんの入口になる脆弱性への攻撃を、WAFはある程度減らせます。ただし、後述するとおり、修正版を当てる作業の代わりにはなりません。

WAFが防げないもの

WAFを入れれば安全、とはなりません。防げないものを知っておくほうが、導入判断は正確になります。

  • 正規の操作を装う不正ログイン。盗まれたIDとパスワードでログインする通信は、形式としては正規の利用者と同じです。リスト型攻撃への対策は、多要素認証やログイン試行の制限が本筋です
  • アプリケーションの設計上の欠陥。他人のデータが見えてしまう権限の不備や、業務ロジックの誤りは、通信の形式だけでは判別できません
  • 未知の攻撃。ルールに登録されていない新しい手口は、通ることがあります
  • WAFを迂回する通信。クラウド型のWAFを使っていても、サーバー本体のIPアドレスに直接届く通信を受け付けていれば、WAFを経由しない攻撃が成立します
  • 運用の不備。誤検知を避けるためにルールを緩めすぎたり、検知するだけで止めない設定のまま放置したりすると、入れていないのと変わりません

WAFは、脆弱性を直す作業の代わりではありません。公表された脆弱性は、修正版を適用して塞ぐのが基本で、WAFはそれまでの時間を稼ぐ役目です（CVEとCVSSの記事）。

導入の形と費用の考え方

導入の形は3つあります。

  • クラウド型。CDNやセキュリティ事業者が提供するサービスで、DNSの設定を切り替えて通信を経由させます。月額の料金で始められ、機器の購入や保守が要りません。DDoS対策の記事で書いた「上流で守る」構成と同じ事業者で提供されていることが多く、まとめて検討できます
  • ホスト型。Webサーバーにソフトウェアとして組み込む形です。費用は抑えられますが、サーバーごとの設定と更新が必要です
  • 機器型。専用の装置を自社のネットワークに置く形です。自社で設定と運用を担える体制がある場合に向きます

自社で運用の担当を置けない場合は、クラウド型が現実的です。導入時に確認したいのは、ルールの更新を事業者が行うか、誤検知が出たときに誰がどう調整するか、ログを自社で見られるかの3点です。

入れた後の運用で決まる

WAFは、設定して終わる製品ではありません。

導入直後は、止めずに記録だけする「検知モード」で動かし、正規の通信が攻撃と判定されていないかを確認します。問題がなければ「遮断モード」に切り替えます。この手順を飛ばすと、顧客の正規の操作を止めてしまい、現場の判断でWAFを無効にする、という結末になりがちです。

その後は、ルールの更新、誤検知の調整、ログの確認を続けます。ログを見る人がいなければ、攻撃を受けていることにも、誤検知で顧客を止めていることにも気づけません。外部に委託するなら、月次で何を報告してもらうかを決めておきます。

もうひとつ大切なのは、WAFがあっても修正版の適用を止めないことです。WAFは時間を稼ぐ役目で、穴そのものは残っています。

実務者の持ち帰り

  • 自社が外部に公開しているWebサイト・Webアプリケーションを一覧にし、それぞれが誰に守られているかを確認する。公開資産の棚卸しの一部です
  • 導入するなら、まずクラウド型で検知モードから始め、誤検知を確認してから遮断に切り替える
  • WAFを入れた後も、CMSやプラグインの更新、多要素認証、ログの確認は続ける。WAFはそれらの代わりにはならない
WAFWebアプリケーションファイアウォール脆弱性対策クラウドサービス