この記事は Retty Part1 Advent Calendar 2021 の19日目の記事です。
Retty でインフラエンジニアをしている幸田です。気づけばもうこんな時期ですね。
はじめに
12月8日に開催された Fastly 主催の Yamagoya 2021 にて『Retty における Signal Sciences の導入事例』というタイトルで登壇しました。
Yamagoya では Signal Sciences の機能や使い方の話はあまりせず、選定した理由や導入方法、PoC の内容などにフォーカスしてお話しました。
発表だけだと「どのように WAF が機能するのか」や「実際の使用感」などはイメージしにくかったかと思いますので、本エントリでは Signal Sciences の基本機能やより具体的な事例について書きたいと思います。
なおイベントのアーカイブ動画は、Vimeo で公開されていますので併せて見ていただけると嬉しいです。
イベントページ にログインするとオンラインブースより他の方の発表も見れますのでお時間ある方はぜひ。
発表資料については Speaker Deck で公開しています。 speakerdeck.com
Signal Sciences とは？
Signal Sciences は Fastly 社が提供する次世代 WAF (Web Application Firewall) です。
正規表現のパターンマッチング手法に依存する従来型の Web アプリケーションファイアウォール (WAF) は、正当なトラフィックのブロックにつながる誤検知を防ぐために継続的なルール調整が必要なほか、管理も困難です。Fastly の次世代 WAF (旧 Signal Sciences) は、ルール調整の必要がない、根本的に異なるアプローチを使用することで、悪意のあるトラフィックを効果的に検出してブロックします。
Fastly 公式サイトより引用
書かれていることが全てですが最大の特徴は「根本的に異なるアプローチを使用することで、悪意のあるトラフィックを効果的に検出してブロックしている点」だと思います。
WAF でマネージドなルールを使用した場合、False Positive が懸念されることがよくあると思いますが、単純な正規表現によるマッチングではないため非常に精度が高い です。
公開されている情報だと 10 Key Capabilities of Signal Sciences Next-gen WAF and RASP の "2. Automated blocking that scales without rules tuning" や Architecture Overview が参考になるかと思います。
Signal Sciences では自動的にリクエストが解析された後、内容に応じて Signal と呼ばれるタグのようなものがリクエスト毎に付与されます。
「ルール調整の必要がない」と書かれているのはまさにこの部分で、今まで正規表現などでパターンマッチングさせていた部分をすべて Signal Sciences にオフロードすることができ、利用者は付与された Signal を利用してルールを作成したり、しきい値を設けて悪意のあるリクエストをブロックすることができます。
もちろんカスタムで正規表現やその他様々な条件を組み込んだルールを設定することも可能です。
導入方法
10 Key Capabilities of Signal Sciences Next-gen WAF and RASP にも書かれているように、非常に豊富な導入手段が用意されています。
Yamagoya でも紹介しましたが、大きく Agent WAF と Cloud WAF の2つで、Agent WAF の中には更に複数の選択肢があります。
Retty では Cloud WAF と Agent WAF の両方を採用しています。
Cloud WAF
Cloud WAF は WAF 導入時に必要な Agent を Signal Sciences が管理するタイプのもので、自社での Agent 構築を必要とせず、サービスに設定されている DNS レコード (CNAME) として Signal Sciences のバックエンドを向けることで導入できます。一般的な CDN の導入をイメージして頂くと分かりやすいかもしれません。
Agent 運用もすべてマネージドです。その代わり、次に紹介する Agent WAF に比べて料金が少し高めです。
Agent WAF
Agent WAF は Agent を自前で構築して運用するタイプのものです。こちらは Cloud WAF と比べると少し安いです。
イメージ図にもあるように、豊富な選択肢が用意されています。
Reverse Proxy
一番スタンダード(?)な導入方法だと思います。アプリケーションサーバの前段に Reverse Proxy として Agent を動作させるタイプです。
各ディストリビューションのパッケージや Docker イメージ も用意されているので、基本的にどこでも動かせます。Windows にも対応しているそうです。すごい。
また Kubernetes 向けに、後述する NGINX モジュール が予めインストールされた sigsci-nginx-ingress-controller も用意されています。
Web Server Module
こちらは NGINX や Apache などのモジュールとして Agent を呼び出すことができます。
ドキュメント に下記のような設定例が書かれていますが、非常にシンプルでなんとなく設定方法が想像できますね。
# sigsci_enabled set to "on" location /inspect/ { sigsci_enabled on; proxy_pass http://127.0.0.1:80/inspect/; }
まずは特定の path だけ有効にするといった使い方も簡単にできそうです。
Other Module
Web Server Module の利用や Reverse Proxy 以外のアプローチとして、アプリケーション側から Agent にリクエスト情報を渡すこともできるようです。
例えば Go の場合は http.Handler のラッパーとして利用できる sigsci-module-golang が用意されています。
他にも対応しているものがいくつもあり、All Other Modules から確認できます。
攻撃の検出
まずはどのようにして攻撃が検出され、分類されるのかについて書きます。冒頭にも書いたように、リクエスト内容に応じて Signal と呼ばれる属性が追加されます。
Attack Signal
Attack Signal は攻撃と思われる内容を含むリクエストに対して付与されます。例えば、Cross Site Scripting を含むと疑われるリクエストに対しては XSS が付与されます。
画像は Web UI から確認できるリクエスト情報の例です。
XSS 以外にもデフォルトで下記のような Signal が用意されています。これらは事前に設定を行うことなく、導入すると自動的に分類/付与されます。
Attack ToolingAWS SSRFBackdoorCMDEXESQLITraversal
この Attack Signal の分類が非常に優秀で、いわゆる False Positive (誤検知) がかなり少ない です。 そして何よりも 自分たちでチューニングをする必要がない点 がポイントです。
かといって何でも通してしまうのではなく、しっかりと怪しい攻撃に対しては相応の Signal が付与されています。
従来型の WAF で一番苦労していたのはこのチューニング作業ではないでしょうか？導入してから今まで一度も通常のリクエストが遮断されたことはなく、少ないメンバーでも十分に運用できています。
Anomaly Signal
Anomaly Signal は攻撃とまでいかなくとも、通常とは異なるリクエストに対して付与されます。
こちらは種類が多いですが、下記がその一例です。
SigSci IP
また Anomaly Signal の1つに SigSci IP と呼ばれるものがあります。 Signal Sciences は Agent を通して、匿名化された攻撃データ1を収集しており、この収集したデータを分析して悪意があると判断された IP アドレスに付与される Signal です。
SigSci IP は、 他の利用者に対して送られてきたリクエスト情報なども含めて判断しているため、更新頻度が高く False Positive が少ない のが特徴だそうです。
Custom Signal
Attack Signal と Anomaly Signal は予め用意されたものですが、カスタムの Signal を作成することも可能です。例えば、特定のリクエストに目印をつけたい場合などに便利です。
Custom Signal は後述する Rule で使用することができます。
攻撃のブロック
続いて攻撃をブロックする手順について書きます。
Site Alerts を利用した閾値ベースのブロック
前述の Signal を用いて閾値ベースでブロックするための機能が Site Alerts です。
デフォルトでは下記の Attack Signal を含むリクエストが一定回数以上確認された場合に、その IP アドレスを Flagged IP として扱い、以降その IP アドレスからの Attack Signal を含むリクエストについては全てブロックするようになっています2。
Attack ToolingAWS SSRFBackdoorCMDEXESQLITraversal
デフォルトの閾値は下記の通りです。変更可能です。
Site Alerts は追加可能で、Anomaly Signal や Custom Signal を利用することもできます。
Signal の付与と Attack Signal による Site Alerts はデフォルトで有効化されているため、サイト規模に応じて閾値を調節すれば、特別なチューニングを必要とせずとも主要な攻撃は防御できるのではないでしょうか？
Retty でもリクエストを継続的にモニタリングしていますが、短時間で機械的にリクエストを送ってきて Attack Signal が含まれているものが大半です。
Rule を利用したカスタム条件での攻撃のブロック
デフォルトで付与される Attack Signal と Site Alerts で主要な攻撃はカバーできそうですが、当然それ以外にも攻撃はありますし、カスタムでルールを作りたい場合もあると思います。
Rule を利用すると様々な条件で攻撃をブロックしたり、任意の Signal を付与することができます。
Site Rule
Site Rule は任意の条件で、Signal の付与やブロックが行える Rule です。
ほとんどないですが、False Positive が発生した場合に条件を指定して特定の Signal が付与されないようにすること (Signal exclusion) も可能です。
ドキュメント に書かれているように、IP アドレスや HTTP メソッド、クエリパラメータなど様々なフィールドを指定し、Signal の付与やブロックなどが設定できます。
下記のスクリーンショットは「Signal として SigSci IP が付与されていて、User Agent の文字列に Scrapy もしくは Namp が含まれている」を条件にしている例です。
画像にもあるように条件をグループ化したり、そのグループに対して AND / OR などの Operator も指定可能です。
Rule 作成画面に限らず、Web UI が全体的に分かりやすいのも気に入っているポイントの1つです。
また Site Rule などで利用可能な List と呼ばれるものも用意されています。List では下記のような種類のリストを定義しておくことができます。
- Country
- IP (CIDR も可)
- Signal
- String
- Wildcard
Rule からは Is in list や Is not in list などを Operator として指定することで、複数の条件を指定したい場合に Rule の条件をシンプルにすることができます。
アクセスを拒否したい User Agent が複数ある場合や、特定の IP アドレス(例えばオフィスからのアクセス)に Signal を付与したい場合などに便利ですね。
Templated Rule
Templated Rule はプリセット的に用意されている Rule です。
Site Rule のように自分たちで細かい条件を指定しなくとも、複数のフィールドを設定するだけで Signal の付与やブロックの設定を行うことができます。
下記は「ログインの失敗」を検出するための Templated Rule の設定例です。いくつかリクエストの条件を入力すると Login Failure という Signal を付与したりしきい値に応じてブロックする Rule を作成することができます。
この他にも CVE 系のリクエストに対して Signal の付与を行うための Templated Rule も用意されています。先日話題になった CVE-2021-44228 もすぐに追加されました。
リクエストの確認
ここまで Signal による攻撃の分類と Site Alerts や Rule による攻撃のブロックを紹介しました。
最後に「どのようにしてリクエストの確認や可視化を行うのか？」といった部分についてお話します。
Signal Dashboard を利用した攻撃の可視化
Signal が付与されたリクエストを可視化するための Signal Dashboard と呼ばれるものが用意されています。Attack Signal に加えて Anomaly Signal や Custom Signal もここから確認することができます。
グラフをクリックするとリクエスト回数やアタックされたページ、ホスト情報などが表示されます。
どのホストが、どのページに何回リクエストを送っているかなどざっくりとした情報がここから確認できます。
Request を利用した攻撃の調査
Request を利用するとリクエストの詳細を確認できます。
ここでは攻撃等を含まない通常のリクエストなどは表示されません。また Attack Signal と CVE の Signal を含むリクエストは全件表示されますが、CVE 以外の Anomaly Signal や独自に生成した Custom Signal についてはサンプリングされたリクエスト情報3が表示されます。
検索欄にはいくつかのクエリが利用可能で、特定の Signal に絞ることはもちろん HTTP ヘッダやレスポンスコードや User-Agent の文字列で絞ることも可能です。詳しくは Search Syntax に書かれています。
View request detail からは詳細なリクエスト情報が確認できます。キャプチャにはありませんが、リクエストヘッダやクエリパラメータを確認することもできます。 ちなみに Authorization ヘッダなどの情報は redacted になりマスクされています。
また右上の Convert to rule をクリックすると、該当のリクエストを元に Site Rule を作成することも可能です。下記のような画面で条件としたいものをクリックすると、簡単にルールを作成することができます。
導入してみて
ここまで Signal Sciences の基本機能を紹介しました。実際の利用イメージがなんとなく伝わっていると嬉しいです。
いくつか Yamagoya で話したものと重複していますが、最後に導入してみた良かったところを書いて終わりにしたいと思います。
安全に攻撃の遮断ができる
攻撃を遮断するための WAF なので当たり前ですが、今まで入れていなかったのでやはり安心感が違います。
WAF を導入するまでに NGINX や Apache でどうにか対策しようと考えていましたが、様々な事情により断念しました。最終的に、攻撃を検知したら VPC のネットワーク ACL に Deny ルールを追加するという方法で遮断する運用を続けていました。この辺りの話は昨年の AdventCalendar に書かれています。
この方法では、WAF の代替とするには登録できる IP アドレスの数が少なかったり(使い方が違うので当然ですが)、IP アドレスによる拒否しかできないため限界がありました。また IP アドレス登録時のオペミスによるインシデントも発生しました4。
話が脱線しましたが、 Site Alerts や Templated Rule を用いて様々な条件で事前に攻撃を対策できるのと、短時間に大量のリクエストを送ってくるタイプの攻撃があった際にも、安全に該当のホストを遮断できるようになりました5。
運用コストがかなり低い
Yamagoya でもお話したように、一時期 AWS WAF を試験的に導入したことがありました。
自分たちのチューニング不足ではあると思いますが、いくつかのマネージドルールだけだと大量の False Positive が確認され、実際に運用するためにはチューニングにそれ相応の時間やコストをかける必要があると判断しました。
その経験もあって False Positive が出ることや、導入後に継続的なチューニング作業が発生することを懸念していましたが杞憂でした。90% 以上のユーザがブロックモードを利用しているのも納得です6。
Terraform が利用できる
Signal Sciences では公式の Terraform Provider が用意されています。
Terraform を利用することで設定のコード化と PR ベースのレビュープロセスを整備することができます。
Retty では専用のリポジトリを作成し、原則 CI から terraform apply を実行するようにしています。変更内容のレビューと Git によるバージョン管理ができるのでより安全に設定を適用することができるようになりました。
なおすべての機能に対応しているわけではなく、一部未対応のものもあるため今後のアップデートに期待しています。
おわりに
ここまで読んでいただきありがとうございました。
Signal Sciences を検討していたり、WAF の導入を検討している人の助けになれば幸いです。
今年は Part 1 に加えて Part2 の Advent Calendar もありますので、引き続きお楽しみください〜
それではよいお年を
- リクエストデータがバックエンドに収集される際には、Agent 側で予め機密情報がマスキングされるようになっており、必要に応じてマスキング対象の属性を追加することも可能です。詳しくは 公式ドキュメント を参照してください。↩
-
デフォルトでは
Flagged IPであっても悪意のない通常のリクエストは通す挙動になっています。Rule を作成することでブロックすることも可能です。↩ - 一部データはサンプリングされたものが利用されます。ドキュメントの Data Storage and Sampling に詳しく書かれています。↩
- タイトルにもある「サービス断」を出してしまったのは私です。ネットワーク ACL で Allow を消すと本当に全部のメトリクスが0になるので、自分だと気づいた瞬間に頭が真っ白になったのを覚えています。↩
- Signal Sciences では Rate Limit 機能も用意されており、Premium Platform を契約した場合に利用することができます。詳しくは Rate Limit Rules を参照してください。↩
- 公式サイト より↩
