HOME > Scutumを支える技術 > Scutum技術ブログ

技術者ブログ

クラウド型WAF「Scutum(スキュータム)」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中!

2021年10月

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

シグネチャ依存型のWAFは避けよう

はじめに

先日、とあるScutumを利用中のお客様からうれしいフィードバックを頂きました。

「ウェブサーバをオンプレからクラウドに移した際に、WAFを(一時的にScutumをやめて)そのクラウドにメニューとして用意されていたWAFに切り替えてみたところ、誤検知が多発して本当に苦労した。Scutumがいかに楽なのかが実感できた」というものです。そのお客様はその後、そのクラウドのWAFから、再びScutumに戻ってきてくれました。

最近では著名なクラウドサービスにメニューとしてWAFがあるようですが、私が知っている範囲では、それらの多くは「シグネチャ」あるいは「ルール」を使って攻撃を見つけようとする種類のWAFのようです。本ブログではこれらの「シグネチャあるいはルールのみによって防御を行う」タイプのWAFを、「シグネチャ依存型」のWAFと定義します。

シグネチャ依存型のWAFは2020年という時代にそぐわない、古くて性能の低いものです。個人的に、上で例に挙げさせていただいたようなケース(WAFで、不必要に苦労してしまうこと)が増えることを危惧しています。

今回はシグネチャ依存型のWAFはできるだけ避けたほうがよい、という私の意見について、根拠を明確にして説明させて頂こうと思います。

WAFの仕事の本質は「攻撃を止めること」ではない

「そもそも、WAFというのは何をやるものですか?」という質問をされたら、何と答えますか?WAFの仕事の本質は、何でしょうか。

多くの人がすぐに思いつくのは「攻撃を止めること」という答えかと思います。ファイアウォールという言葉のイメージから、「止める」「遮断する」という役目こそがWAFの仕事であり本質だと考える人が多いかと思います。シンプルで、わかりやすいコンセプトです。

しかし極端な例をあげれば、「全ての通信を攻撃とみなし」「全ての通信を通さない」サーバを作れば、攻撃はすべて止まります。この場合、「攻撃を止めること」は実現できてしまいますが、もちろん、それでは正常な通信ができませんので、WAFとして良い仕事をしているとは到底言えません。つまり、WAFの仕事の説明としては、「攻撃を止めること」だけでは不正解なのです。

WAFには「攻撃は止め、正常な通信は止めないこと」が求められます。さらに考えを深くしてみましょう。

WAFの仕事の本質は「分類」である

前項で示したように、WAFに期待されているのは「攻撃は止め、正常な通信は止めないこと」です。つまりWAFが最初にやる必要があるのは、「ある通信が攻撃なのか、正常な通信なのか」を見極める、分類することです。

分類できれば、それに続いて通信を止めたり、あるいは止めなかったり、というのは自動的に決まる挙動なので、そこには技術的な開発の難しさやあいまいさはありません。

つまり多くの人がセキュリティプロダクトである「WAF」に始めに持つイメージである

  • 止める
  • 守る
  • 遮断する
というのは実はWAFの仕事の中では些細な処理に過ぎず、
  • 分類する
というのがWAFの仕事の本質なのです。WAFというのは、実は「ソフトウェアが、分類を行う場面」なのです

ちょっと意外でしたでしょうか。セキュリティプロダクトであり、防御する存在のイメージですが、実はWAFにとっては「データを分類すること」という地味に見える部分こそが役割の中核となっているのです。

WAFに期待される「分類」は難しい

WAFは「ファイアウォール」ではありますが、iptablesのようなネットワーク向けの一般的なファイアウォールとは、実はまったく似ていません。

一般的なファイアウォールでは、

  • あるアドレスからのアクセスは許可する
  • あるポート以外へのアクセスは拒否する
など、ルールを列挙することによって挙動が決まります。これは構造的にはシグネチャ型とまったく同じですが、WAFとは異なり、これで問題ありません。何故でしょうか?

それは、ファイアウォールに期待されている仕事がシンプルで、すべてルールとして明示的に定義できるからです。つまり人の要求と、ソフトウェア上の設定内容を完全に一致させることができるのです。

WAFであれば、次のような要求になるでしょう。

  • SQLインジェクションは拒否する
  • コマンドインジェクションは拒否する
「あ...なるほど」と感じられましたでしょうか。WAFの場合、上記のような「人の要求」は「ふわっとしてしまっている」のです。そのため、そのままソフトウェア上の設定として落とし込むことができず、「そもそも、SQLインジェクションって何なのだろう?」というステップが必要となります。

一般的なファイアウォールが行う分類は、例えばあるパケットが「(定義済みの)拒否すべきアドレスから来たか、そうでないか」というケースとなり、明確で間違えようがありません。つまり、とても簡単な分類です。

しかしWAFが行わなければいけない分類は、あるデータが「SQLインジェクションか、そうでないか」というように、難しい分類作業になるのです。

WAFは迷惑メールフィルター(スパムフィルター)に似ている

前項で示したように、WAFは「ファイアウォール」ではありますが、一般的なネットワーク用のファイアウォールとは似ていません。むしろ、WAFは迷惑メールフィルターに似ています。

迷惑メールフィルターに人が期待するのは

  • 迷惑メールは(ゴミ箱などに)分類する
という「ふわっとした」動作です。迷惑メールフィルターが行う分類作業は難しく、ときに間違えます。誰でも、ビジネス用のメールが迷惑メール扱いされたり、逆に迷惑メールが正常なメール用のフォルダに混ざっていたという経験があるのではないでしょうか。

WAFがやろうとしている仕事もこれに似ていて、難しい分類作業です。そして難しいために、ときに誤った分類を行います。

iptablesのような一般的なネットワーク用ファイアウォールが「誤った分類」を行うことはありません。拒否しなければいけないアドレスからのパケットがたまに通ってしまったり、あるいは許可されるはずの通信がたまに止まってしまう、ということはまず経験がないでしょう。

それとは異なり、迷惑メールフィルターやWAFは「誤った分類」を行うことがあります。これは、要求される分類が難しいことが原因です。現状ではどんな迷惑メールフィルターやWAFでも、分類のミスをゼロにすることはできないでしょう。

そこで、WAFを使う立場から考える場合、このミスがなるべく少ないWAF、つまり「できるだけ分類の性能がよいもの」を選ぶことが重要になります。

なぜシグネチャではダメか

ここでやっとシグネチャの話に戻ってきます。「なぜシグネチャではダメか」というと、純粋に「シグネチャは分類が得意でないから」です。

前項でピンと来た人がいるかもしれませんが、WAFの本質である「ソフトウェアが分類を行う場面」というのは、近年強烈な進化を遂げている人工知能・データサイエンス技術そのものです。

この10年ほどで、ソフトウェアは分類がものすごく得意になりました。よくインターネット上で話題になる例は「画像の分類」が多いですが、画像以外でも同じように分類をうまく行えるようになっています。

ソフトウェアの分類能力が著しく向上した理由は、より高度なアルゴリズムが発見されたからです。そして「シグネチャ」あるいは「ルールベース」というのは、これらの高度なアルゴリズムには含まれません。

迷惑メールフィルターもシグネチャ依存をやめて性能を上げており、10年前に比べると格段に迷惑メールに悩まされずに済むようになりました。

ソフトウェアに分類させるためのデータサイエンス関連のライブラリはオープンソースで誰でも開発が可能になっており、また同時にコンピュータの性能が上がったため、WAFが動いているような一般的なLinuxサーバ上で分類するためのコードを高速に動かすことができるようになりました。10年前とは、完全に時代が違うのです。

シグネチャ(あるいはルール)というのはデータサイエンスの分野では決定株(あるいは非常に深さが浅い決定木)にあたりますが、いずれも2020年の現時点では性能が低いものとされており、データ分類のアルゴリズムとして中心的な役割を担うことはほぼありません。

WAFの世界ではなぜか未だにシグネチャを使って分類をしているWAFの数が多いですが、これは主に歴史的な理由があるからであり、分類性能を理由にシグネチャを使っているWAFは存在しないでしょう。

「シグネチャを使って分類している」というのは、この10〜15年の間に多くの研究者・開発者の集合知によってもたらされた、ソフトウェアの分類性能の革命的な進化の恩恵をすべて無視していることになるのです。

Scutumはどうなの?

Scutumは、2009年にサービスを開始した当初は、シグネチャ依存型でした。当時は上記のような「WAFは分類を行う場面である」というような認識を持っておらず、当時の常識である「WAFといえばシグネチャ」という感覚で開発と運用を続けていました。

しかし順調にユーザさん・利用サイトが増えるのに伴い、分類ミスによる誤検知に出会う回数が増え、シグネチャ依存型の限界を自ら体感することになりました。誤検知(誤って正常通信を止めてしまうタイプ)があると、その原因となったシグネチャを無効にする、というような対応を採ることが増えてしまい、その結果防御能力が落ちてしまいます。

「もっとうまく分類できるようにしないと、WAFは役に立たない存在になってしまう」

という強い危機感からデータサイエンスの勉強を始め、2013年頃にベイジアンネットワークに出会い、Scutumの脱「シグネチャ依存型」に成功しました。(当時のブログはこちら)

現在も、このベイジアンネットワークによる分類がScutumの中心となっています。ベイジアンネットワークはシグネチャに比べて分類が非常にうまく、誤検知の確率は個人的な手元の感覚では1/20〜1/50程度に減っています。

「シグネチャの低い分類性能のせいで非常に人的コストがかかり、とても苦労する」というのは、私が既に通ってきた、辛く険しい道のりです。Scutumを選んでもらえれば、私と同じ苦労をする必要がなくなりますよ、というのが、このエントリで伝えたいメッセージです。

まとめ

今回はWAFの仕事の本質が、実は「分類する」ことだったことについて、そしてシグネチャでは分類の性能が不十分であることについて簡単にまとめてみました。

しかしシグネチャには実はメリットもあります。Scutumでも、ベイジアンネットワークだけでなく、シグネチャを使う場面もあります。そして多くのWAFが、未だにシグネチャ依存型である、という謎もあります。そのあたりについては、後日稿を改めたいと思います。

なお、WAFにおける「誤検知」という用語は厳密には定義されておらず、「正常通信が誤って攻撃と判断されてしまうこと」だけを誤検知と呼ぶ場合と、それに加えて「攻撃が正常通信と判断されてしまうこと」も含めて誤検知と呼ぶ場合があるようです。私は普段前者の意味で使うことが多いため、本ブログでもそのようなニュアンスで「誤検知」という用語を使うことが多くなっています。