そのWAF、本当に効いてますか？

・実運用から得られた知見を元に、クラウドに標準搭載されているWAFや、SaaS型WAF製品等について、あまり認識されていない危うい挙動の解説と、付き合い方について解説します。
・特定の製品について非難や言及を行うものではありません。特性を知ったうえで自身のWebサイトをより強固にするための参考資料として活用頂けますと幸いです。
・記載内容は公開情報を基にしています。

Transcript

1. 1 伊藤忠サイバー＆インテリジェンス株式会社 そのWAF、本当に効いてますか？ 2025/4/23
2. 2 構成 2 WAFとは？ 総括 WAFの危うい挙動と付き合い方 WAF選定時のクライテリア(参考) 01 04 02 03
3. 3 3 このスライドについて • 実運用から得られた知見を元に、クラウドに標準搭載されているWAFや、 SaaS型WAF製品等について、あまり認識されていない危うい挙動の解説と、 付き合い方について解説します。 • 特定の製品について避難や言及を行うものではありません。特性を知ったうえ で自身のWebサイトをより強固にするための参考資料として活用頂けますと幸 いです。 • 記載内容は公開情報を基にしています。 ※筆者はWebへの攻撃、及び防御手法の研究。それらを用いたWAFの検知ロジックの開発経験を有しています。
4. 4 4 01 WAFとは
5. 5 5 WAF (Web Application Firewall) とは • Webへの攻撃に特化したファイアウォール。 • Webアプリケーションの手前に配置することで、Webアプリへの攻撃を遮断する。 ※一部、サーバーにインストールするタイプもあります
6. 6 6 WAFの防御戦略 – シグネチャ • シグネチャ • キーワードや正規表現を使用して、攻撃パターンとマッチする特徴を検知・ブロックする。 • 難読化が容易な言語の場合、bypassが容易。 • 攻撃において特定のキーワードが必須な場合に効力を発揮する。 • 例 • SQLi • ['"]¥W{0,}OR¥W{0,}¥d++¥W{0,}=¥W{0,}¥d++ • ‘ OR 1= 1 や “ OR 2 = 2 にマッチ • XSS • on¥w{4,}=(eval|alert|import|write)[`(] • <svg/onload=eval(`‘`+URL)> や <iframe/onload=eval(`’`+URL)> にマッチ
7. 7 7 WAFの防御戦略 • ロジック • スコアの加算や AI/ML などを使用したより包括的な検知で、難読化にも対応できる。 • モデルのチューニングによる検知精度の変動あり。 • 検知を集約しすぎると、誤検知対応でAI/MLを無効化したことによるセキュリティレベル の低下が著しくなる。 ※モデルを小分けにしたり、検知の閾値を開放するなど、上手くやってるWAFもあります • レピュテーション • 外部のインテリジェンスや他で観測した情報をもとに、アクセス元の信頼値を計算 • 信頼度が低い場合はブロックを行う。 • レピュテーションの鮮度に気を遣う必要がある。
8. 8 8 02 WAFの危うい挙動、付き合い方 7選
9. 9 9 サイズ制限 • 最初の nKbyte のみ検査 • 大抵は、nKbyte を超えるリクエストは Drop するシグネチャが提供されている ※標準でONになっているかは製品次第 • ヘッダー、パラメータ、ボディ、メソッドごとに細かく決まっているWAFも • サイズ制限はセキュリティ対策ではない • 攻撃者としては無意味な文字をペイロードの前に置けばいいだけ • 大抵は超えない、ファイルアップロードなどで超える • 画像末尾のメタデータ領域にWebShellを仕込んでいた事例を観測したことがある。 • 除外の大原則は、可能な限り範囲を限定すること • サイズ制限を除外する場合は、ドメイン、URL、パラメータ、シグネチャIDまで指定し て除外できるとベスト 02. WAFの危うい挙動と付き合い方 (1/10)
10. 10 10 HTTPリクエストの構造 • パーツごとの検査サイズ • 例えば、 • Bodyは8KBまで • ヘッダーは100行まで • など • 課金による上限緩和 • 課金で検査サイズの上限を上げ られる場合がある HTTPリクエストの構造 02. WAFの危うい挙動と付き合い方 (2/10)
11. 11 11 検査範囲 • 特定のパーツのみ検査 • 検査サイズと似た話 • 設定しない限り、特定のパーツのみ検査が行われる • 可能な限り全体を検査 • Log4ShellやShellshockの様に、脆弱性が刺さるパーツは多岐に渡る。 • 可能な限り全体を検査する。 • ただし、パフォーマンスに影響が出る可能性があるため、試験を推奨。 02. WAFの危うい挙動と付き合い方 (3/10)
12. 12 12 IP遮断 • アクセス元IPが変わる • CDN -> WAFの構成が多い。 • 手前に箱があると、アクセス元IPがそのIPに変わる。 • XFFなどを解釈しないWAFだと事故につながる可能性。 • 共有IPを遮断するリスク • ビルで共有していたり、ゲートウェイ製品のIPをブロックするリスクあり。 • 特に、ゼロトラストなどの台頭でProxy経由でのアクセスが増えている。 • 許可IPを登録する機能がある確認しよう • 誤検知は機会損失に繋がるため、緊急除外の手順を確立しておく。 02. WAFの危うい挙動と付き合い方 (4/10)
13. 13 13 アクセス元IP制限 • WebサーバーのIPは特定される場合がある • 後からWAFを入れると、CensysやNetcraftの履歴に残っているから特定される。 • OSINTによりWebサーバーを特定するツールもある。 • WAFからのアクセスのみに限定 • WAFからのみアクセスを受け付けるように制限する。 • その他のポートが空いていれば、もちろん攻撃される。 02. WAFの危うい挙動と付き合い方 (5/10)
14. 14 14 ブロックされるタイミング • 遅延ブロック • 受診した攻撃通信をWebアプリへ一旦渡して、別スレッドで解析した結果、悪性と 判断した場合、次の通信から遮断を行う製品も存在する。 • この挙動を持つ製品は多くないが、事前の確認を推奨。 • 要求レベルはビジネス判断。 02. WAFの危うい挙動と付き合い方 (6/10)
15. 15 15 OWASP CRSベース • OWASP CRS (Core Rule Set) とは • OSSなWAFである、ModSecurity向けのOSSなWAFルール。 • 正規表現とスコア加算方式。 • 誰でもbypassの研究ができる • OSSがゆえに、誰でもbypassの研究ができる • 過去に何度かbypassが見つかっている • とはいえ、そんなに弱くはない。むしろ、工夫されたシグネチャの宝庫。 • CRS以外のルールも使用する • CRS以外のルールが提供されているなら、それも組み合わせる。 • Bypassが見つかった場合の対応速度はベンダー次第。 02. WAFの危うい挙動と付き合い方 (7/10)
16. 16 16 入手の容易性 • 誰でもbypassの研究ができる • 入手が容易ということは、攻撃者にとっても手が届きやすいということ。 • 標準搭載されているWAFは、クラウドアカウントさえ持っていれば誰でも触れる。 • 著名なWAFはbypassの研究が盛ん。 • SNSでもたまにbypassのペイロードを見かける。 • ベンダー次第 • bypassへの対処はベンダー次第。 • 100%の検知は不可能。（過検知と隣り合わせ） • WAFは保険、予算が許すなら脆弱性診断などで重ね掛けの保険を。 02. WAFの危うい挙動と付き合い方 (8/10)
17. 17 17 誤検知とチューニングの粒度 • 構成次第で正常通信の半分がブロックされる • フルセットをデプロイすると正常通信が半分以上ブロックされるケースがあった。 ※他のWAFではそんな事は起きなかったので、アプリとの相性が悪いわけではなさそう • 検知のみから始める • 相性が悪いシグネチャもあるため、検知のみから始めて初期チューニングを行う。 • 除外の範囲は最小限に • ドメイン、URL、パス、パラメータ、シグネチャIDまで指定できるとベスト • そこまで絞れないWAFもある、その場合は、サイト全体で SQLi に対して無防備に なることも。 02. WAFの危うい挙動と付き合い方 (9/10)
18. 18 18 データ転送 • 分析のために転送 • 検査のために、受信したHTTP通信を製品側のインフラへ転送。 • クレカ情報等の機微な情報を扱う場合は要注意。 • オプトアウトの有無を確認 • データ収集のオプトアウトやデータの保持ポリシーを確認 02. WAFの危うい挙動と付き合い方 (10/10)
19. 19 19 03 WAF選定時のクライテリア
20. 20 20 クライテリア • 価格 • 導入想定サイトのドメイン数、トラフィック量 • より検知を行ってくれるモジュールは別売りのパターンがある • 動作 • 悪性通信に対する挙動の確認 • サイズ制限についての確認 • CDNなどと組み合わせたときの動作 • 性能 • PoCなどで誤検知などの多さを見る • パフォーマンスや負荷テストも視野に入れる ※負荷テストはメーカーと事前に協議しましょう
21. 21 21 04 総括
22. 22 22 総括 • 挙動や提供形態から攻撃者に有利な面がある。 • シグネチャを除外する場合は影響範囲を可能な限り狭める。 • 100%の検知は不可能、予算が許すなら脆弱性診断も。