【AI でセキュリティ対策】WafCharm で学習・成長するファイアウォールを構築した話

こんにちは！
スペースマーケットのエンジニアの藤田です。

今回の記事ではスペースマーケットのセキュリティ対策の一環として導入した WafCharm について書こうと思います。

WAF とは

WafCharm の導入の話を書くにあたって、避けては通れない
「そもそも WAF とは何？」について、簡単におさらいしたいと思います。

まずは用語そのものから紐解いていきましょう。
WAF は Web Application Firewall の略です。

「ファイアウォール(FW)」はセキュリティ対策の世界でよく出てくる言葉で、「悪意のある攻撃からシステムを守ってくれる防御壁」みたいなイメージはみなさんもお持ちだと思います。

しかし、WAF はその名の通り「ウェブアプリケーションの FW」であり、通常の FW とはその守備範囲や得意分野が異なります。

FW は一般的に OSI 参照モデル上の「ネットワーク層/トランスポート層」の防御であるのに対して
WAF は基本的に OSI 参照モデル上の「アプリケーション層」の防御となります。
実際は FW, WAF に加えて、IPS/IDS といった防御機構がこれらの間の層の防御に使われることもありますし、WAF が一部「ネットワーク層/トランスポート層」の防御を担うこともありますが、基本的に WAF はアプリケーション層の攻撃の防御のための機構です。

アプリケーション層の攻撃として代表的なものは

・SQL インジェクション
・OSコマンドインジェクション
・クロスサイトスクリプティング (XSS)
・クロスサイトリクエストフォージェリ(XSRF)

などがあります。
それぞれ、その攻撃手法や対策を調べるだけでも一つの記事が書けそうなほど攻撃手法と防御手法の進化の歴史があるものです。

これらはウェブアプリケーションの実装によって生まれてしまう脆弱性を狙う攻撃で、システムの実装で回避できるものではありますが
WAF はシステムの実装の進化の過程で万が一、脆弱性が生まれてしまった場合にも「転ばぬ先の杖」となってくれるのです。

WafCharm とは

WAF の説明が長くなってしまいましたが、本題です。

WafCharm は サイバーセキュリティクラウド社 が運営している
「AWS WAF のルールの運用を AI 技術により自動化するサービス」です。

WafCharm（ワフチャーム）｜AIによるAWS WAFのルール自動運用サービス

ここでポイントとなるのが、WafCharm はただの WAF ではなく AWS WAF のためのサービスであることです。
AWS WAF は AWS が提供する WAF のサービスであり、
同じく AWS のサービスである CloudFront、API Gateway、 Application Load Balancer と関連付けを行い、アプリケーション層の防御を行うことができます。

AWS WAF（ウェブアプリケーションファイアウォール）| AWS

ちなみに、スペースマーケットのサービスの多くは AWS で運用されていることもあり、AWS の WAF の運用も始めようとしていました。

WafCharm は WAF の運用が抱える以下の課題を解決してくれます。

・適切なルールを考えるためにはセキュリティの専門的な知識が必要
・新たな脆弱性などに対応するための定期的なルールのメンテナンスが必要
・攻撃の検知状況などの把握が難しい

サイバーセキュリティクラウド社が持つ
セキュリティの攻撃手法や防御手法に関するノウハウ・ビッグデータ
＋
防御対象となるプロダクトのアクセスログ
＋
上記の情報の解析・学習する AI 機構 

があれば、確かに「日々進化する FW」を実現できそうな
イメージは湧きますね！！

導入前の準備

では、実際に導入していきましょう！
その前に、色々準備が必要です。
導入の前に事前に AWS 側で必要なものは下記のものです。

①防御対象の AWS リソース（CloudFront, ALB, API Gateway）
②防御対象に紐づけている AWS WAF の Web ACL
③防御対象のアクセスログが出力される S3 バケット
④WafCharm からのアクセスを許可するための IAM User と認証情報

①については「どこで防御（ブロック）したいか」に注目して、防御対象を設計する必要があります。
CDN のエッジサーバか？ロードバランサーか？API リソースの前か？
それぞれのリソースやシステムの特性に応じて戦略は様々ですね。

②については①で決めたリソースを守るための WAF の定義を作成します。
WafCharm はこの Web ACL のルールを外から自動更新することになります。
WafCharm に頼らずとも、明確にブロックしたいアクセスが決まっている場合は、この時点でカスタムルールを紐付けておくのが良いでしょう。

③については WafCharm が学習するための材料として、「防御対象にどのようなリクエストが来るのか？」を伝える手段となります。
CloudFront や ALB に関しては標準で S3 バケットにアクセスログを出力可能なので、既に出力している方も多いのではないでしょうか。

④については、WafCharm に AWS WAF の Web ACL と アクセスログが出力された S3 バケット へのアクセスを許可するために必要になります。

弊社では①〜④の事前準備や確認をまず行いました。
特に防御対象の AWS リソースを選定する部分は「対象のシステムにどんな攻撃が来そうか？」「対象のシステムにどんな攻撃が来たら困るか？」を知るいい機会でもあります。

更には「本当にインターネットに公開する必要があるシステムか？」を見直すだけでも、セキュリティ強度はグググっと上がります。

導入の設定

WafCharm のダッシュボードにアクセスしてみます。

2020/04 時点では WafCharm は new AWS WAF にも対応しているようです。
（2019/11/25 に AWS WAF は新しい機能をリリースしました）

次に Web ACL Config の設定画面に移動します。

事前準備で作成した AWS WAF の Web ACL の ID や、Web ACL へのルール適用を許可するために作成した IAM User の認証情報などを入れます。
Web ACL Name は自由なのですが、AWS WAF の Web ACL と名前を揃えることが推奨されています。 
Rule limit は WafCharm に適用を許可するルールの上限なので、組織で管理済みのルールの数と相談です。

Blacklist, Whitelist で IP を事前に指定することも可能です。
Default AWS WAF Action で AWS WAF にルールを適用する際のデフォルトの BLOCK/COUNT モードを指定することもできます。
「WafCharm にいきなり全てのルールを任せるのは不安」という場合は、COUNT モードで運用をはじめて、手動で BLOCK モードに変える運用が良いでしょう。

Web ACL Config を作成したら、次は Web Site Config です。

FQDN に防御対象のシステムの FQDN を入れ、S3 Path に対象のシステムのアクセスログの出力先の S3 バケットを入れます。
WafCharm に学習用のインプットを渡すとてもとても大事な作業ですね。
また、WafCharm に S3 バケットへのアクセスを許可するための IAM User の認証情報を入れるのも必要です。

Web ACL Config と Web Site Config を作成した時点で WafCharm の基本的な設定は完了です。
WafCharm が学習とルールの更新を開始します。
実際、上記の設定後に AWS WAF 側のルールに wafcharm-**** という名前のルールが追加されていました。

どうやら、初期状態では一般的な Web Application の脆弱性をついた攻撃に対するパスルールを追加してくれるようです。
(php の脆弱性、OS コマンドインジェクション、SQL インジェクションを意識したようなルールが多く見られました)

導入してみて

導入直後は全てのルールを COUNT モードで運用していました。
AWS WAF のダッシュボード上で各ルールへのアクセス数などをウォッチすることが可能なので、それらの数値をウォッチしていました。

しかし、そもそも作成されたルールの内容と弊社のプロダクトの性質を考慮した場合、一律ブロックしても、なんの問題もないルールも多くあったので、すぐにブロックモードに移行していきました。

その過程で、「攻撃に相当するアクセスが（少数ではあるが）確かに存在する」ということが明らかになりました。
一般的に広く知られている攻撃手法を、「引っかかればラッキー」ぐらいの気持ちで、とりあえず多くのプロダクトに対して総当りで試す攻撃者をまずブロックできたのは大きいと思います。

一方で、攻撃に相当するアクセスが少ないため
まだまだ 「AI × ビッグデータ」による能動的な防御機構の恩恵を受けられていないという現状でもあります。
攻撃がないことに越したことはないのですが、WafCharm の運用にもコストがかかるため、ある意味、セキュリティ分野への投資という捉え方も必要になってくると個人的には感じました。

また、弊社では CDN に Fastly を採用しているのですが
AWS の CDN である CloudFront 以外との連携においては、WafCharm による IP に関するルールは十分に効果を発揮できないという課題もあります。
理由は Fastly などの CDN 経由で AWS WAF の防御対象であるリソースに到達した場合、対象リソースには攻撃者の送信元 IP ではなく、エッジサーバの送信元 IP の情報が届くケースが多いためです。

最後に

今回は WafCharm の導入事例として弊社の事例をご紹介しました。
導入による一定レベルのセキュリティ対策を簡単にできるという恩恵は確かに受けられています。

一方で、まだまだ課題はあるのが実情です。
ちなみに Fastly + AWS WAF + WafCharm の構成における課題に関しては、実は弊社では独自の実装で回避しています。
（また、その回避方法についても記事にできればと思います）

つまり、どんなに便利なソリューションが生まれても
セキュリティ対策に銀の弾丸はないのだと思います。

「使えるものは使う」

その上で、一人一人のエンジニアが日々セキュリティ意識を持って、システムの設計や開発に取り組むことが重要だなと思いました。

エンジニア絶賛募集中です!

スペースマーケットに少しでも興味がある方は下記Watendlyからの応募をお待ちしております。