BETA

WAFについて(QrunchはWAFの設定を見直したほうがいいのでは…)

投稿日:2019-06-28
最終更新:2019-06-28

投稿がブロックされる

こんなこと書くと怒られるかもしれませんが、直前のエントリ(Qiitaのクロス投稿)を書いたとき、
以下のようなエラーがガツガツ出てきて、全く捗りませんでした(Qiitaのコピペだけど)。

このカスタムされていないエラーを見て、直感的に「WAF」かな?
と思ったのです。

せっかくのテックブログですから、長文を書いてブロックされるのは残念だと思い
自身の整理も含めWAFについて簡単にまとめることにしました。

WAFを利用している方、検討中の方は参考になれば幸いです。

なお自分自身はWAFを専門的に扱っている訳ではないので
間違っているところがあればご指摘いただけますと幸いです。

WAFとは

Web Application Firewall の略で、その名の通りWebアプリケーションに特化した保護策です。
Webアプリケーションへの攻撃を受けたら検知や遮断をします。

IPS (Intrusion Prevention System; 侵入防止システム) と似ていますが、
IPSはネットワーク全般に対するパターンマッチが中心なのに対し、
WAFはWebに特化し、単純なパターンマッチやスコア評価など様々存在しているのが特徴です。

HTTPのリバースプロキシとしてフロントに立つことが多く、
SSL/TLSを受け持っていて、暗号化通信についてもしっかりと検知・遮断をしてくれます。

昔は自社ネットワークにオンプレでWAFの機器を設置し、運用者が頑張って設定していましたが、
昨今はクラウド型のWAFが主流です。

例えばScutumのように高性能クラウドWAFを標榜しているものがあります。
また、AWS ShieldやAzure Application Gatewayのようなクラウドサーバーは無料・格安で使えるものもあります。

どういうときにブロックしているのか

前回のエントリは最終的には文字を一部削ったりして投稿できましたが、
特定のパターンマッチではなく、文字量によってWAFに引っかかったり引っかからなかったりしているようです。

この動きは、自分が知る数少ないWAFの中ではAzure Application Gatewayとよく似ています

Azure Application Gatewayは検知のベースが OWASP ModSecurity Core Rule Set version 3です。
(CRS 2系も選べます)
CRS 3はAnomaly Scoring Modeというスコア評価であり、一定の閾値を超えるとブロックする動きになっています。
ということは送信するデータサイズが大きければ大きいほど閾値が超えやすくなる形になります。

QrunchのWAFエラーと思われるHTTPレスポンスは以下のような内容でした。

HTTP/2.0 500 Internal Server Error  
date: Thu, 27 Jun 2019 14:32:22 GMT  
content-type: text/html  
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"  
server: cloudflare  
cf-ray: 4ed821428d51a54c-NRT  
X-Firefox-Spdy: h2  

CloudflareもWAFのサービスを展開しており、無料からエンタープライズまでプランが存在します。
このページの"技術的な詳細"を見ると書いてありました。

CloudflareのWAFでは、OWASP ModSecurity Core Rule Setと次のアプリケーション固有のルールセットをデフォルトでご利使っただけます。
(中略)
すべてのルールセットを有効にすることも、Webサイトに適用する個々のルールを選択することもできます。管理インタフェースを使用するコンテンツ管理システムの場合は、CloudflareのPage Ruleを作成して、より強力なWAFルールを管理セクションに適用できます。

バージョンは書いていませんが、やはりAzure Application Gatewayと同じCRSを使っているようです。
スコア評価のような動きですから version 3 でしょう。

どうしたらいいのか

WAFの検知ルールを調整していくのですが、このさじ加減が難しい…。
CloudflareのWAF設定画面は見たことがないので当てはまらないかもしれませんが、一般的には以下のような形でしょう。

  • できるだけユーザーのサービスを止めたくない場合はWAFを検知モードにする。
    止めてでもセキュリティが優先なら遮断モードのままにする。
  • しばらく様子を見てログをためる。
  • 検知が多いものは、その検知内容が誤検知かどうかを判断し、
    リスクが許容(もしくは別の方法で対策)できるならルールから外す。
    (閾値が変えられるなら調整する)

Azure Application Gatewayの場合は下記記事が参考になると思います。
Application Gateway (WAF) での脆弱性検知について

検知内容が誤検知かどうか、そのリスクが許容できるかどうかは難しい判断が要求されますが、
個人的には以下のような優先順をつけています。

- 能動的攻撃 受動的攻撃
重大な情報漏洩につながる攻撃手法 1 2
そうでないもの 3 4

1の代表例は「SQLインジェクション」などのインジェクション攻撃です。
能動的攻撃というのは「攻撃者が単独で成立する」ものです。
これはアプリケーションで対策するのはもちろんですが、
人間ですから漏れも生じたときの保険としてWAFもできるだけルールを有効にしておくのがよいと思います。

ただどうしてもサービスが提供できずルールを外す場合は、アプリケーション側でしっかりと対策をしておく必要があります。
自分自身で検査するのも限界がありますので、Webアプリケーション脆弱性診断を受けるとよいでしょう。

2の代表例は「XSS(クロスサイト・スクリプティング)」です。
受動的攻撃は他者(ユーザーなど)が介在する攻撃です。
罠を踏ませるといった誘導が必要で攻撃難易度が高くなりますが、
格納型XSSというコンテンツ改ざんなどで恒久的に埋め込んだXSSは攻撃難易度が低く、被害を大きく拡大します。
アプリケーションで対策はもちろんのこと、「X-XSS-Protection」などXSSに効果があるヘッダを応答しても保険的に防げますので、
そこが問題なければWAFルールは適宜調整しても大丈夫でしょう。

3の例は「DoS」でしょうか。
ただサービスの性質によってはこちらのほうが2より優先ということもあるでしょう。

4の例は「CSRF」でしょうか。
こちらもサービスの性質によっては重要度が増します。
特にCSRFは「犯罪予告を投稿する」といったことができると、冤罪で捕まったりすることがあります。
(CSRFの脆弱があるサイトより、誤認逮捕した警察側へのバッシングのほうが大きそうですが)

まとめ

  • OWASP ModSecurity Core Rule Set はそのまますべてのルールを有効にしていると誤検知が結構出る。
  • 特にたくさんテキストを送ると、ほとんど正常なテキストでも割とブロックされる。
  • 検知内容を常にチェックし、誤検知が多ければリスクを勘案してルールを外す。
  • ただ外すとセキュリティレベルが下がるので、代わりにアプリケーションや別の方法で補強する。

よりよいサービスになることを願って。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

セキュリティエンジニアを目指すアプリケーションエンジニアから見た、Webアプリケーションのセキュリティとか品質のあれこれ。

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる
技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
or 外部アカウントではじめる
10秒で技術ブログが作れます!