Higher Wall

WAFという言葉が出てきたのはいつからだろう。

オライリーの『ファイアウォール構築』を読んだのはかなり昔だ。表紙は城門の絵だったと思う。中身はパケットフィルタリングとプロキシの話で、L3とL4の世界だった。IPアドレスとポート番号で通すか止めるかを決める。DMZやBastion Hostといったネットワーク分離の概念はあったが、アプリケーション層の中身まで見る発想はなかった。WAFという言葉は少なくともあの本には出てこなかった。

ファイアウォールは門番だった。怪しい人間を門前で止める。でも門を通った後に何をするかまでは見ない。HTTPのリクエストがポート80を通過してしまえば、その中身がSQLインジェクションだろうがXSSだろうが、門番の管轄外だ。

Webアプリケーションが主戦場になって、攻撃はL7に移った。正規のHTTPリクエストの形をした悪意がやってくる。門番では止められない。それでWAFが要るようになった。リクエストの中身を読んで、パターンマッチで弾く。OWASPのTop 10に載っている攻撃を片っ端からルール化する。

AWSならALBの前にAWS WAFを置いて、マネージドルールを適用すれば、とりあえずの防御はできる。CloudflareもWAFを標準で持っている。昔なら専用アプライアンスを買って、ラックに積んで、ルールをチューニングしていた作業が、コンソールからポチポチで終わる。

ただし万能ではない。WAFはパターンマッチだから、未知の攻撃は通す。正規のリクエストを誤検知で止めることもある。ルールを緩めれば攻撃が通り、締めれば正常なリクエストが死ぬ。このチューニングが地味に厄介で、結局はアプリケーション側でまともなバリデーションとエスケープをやるしかない。

城門が立派になっても、中の住人が鍵をかけ忘れていたら意味がない。Cookieにsecure属性をつけ忘れるような人間が言っても説得力はないが。