第3回 徹底解剖、アプリケーション識別と制御技術

乙部幸一朗
パロアルトネットワークス合同会社
技術本部長
2011/9/13

　アプリケーション識別と制御

　それでは、アプリケーションごとの通信制御を行うとしたらどうすればよいのだろう。

　そもそも「ファイアウォールでアプリケーション制御」といっても、前回紹介した4つのタイプの製品のうち、「パケットフィルタ型」「アプリケーションゲートウェイ型」「ステートフルパケットインスペクション型」という従来のタイプのファイアウォールでは、アプリケーションをベースとした通信制御には対応できない。これらのタイプのファイアウォールの中には、IPSのエンジンを搭載し、アプリケーションの識別や制御に対応しているとうたうものもあるが、ここで行う通信制御の内容はIPS製品と差がない（逆に機能やパフォーマンス制限が出てくる）。

　IPSの場合、ファイアウォールでは不可能であったアプリケーションまでの検知が可能である。従って、先ほどの例の「拳銃を持っている人だけは通さない」のと同じように、あらかじめ通したくないアプリケーションが決まっていて（例えばWinny）、それだけを不許可にするという制御は可能だ。

　しかしながらアプリケーションを“制御する”という観点では、ファイアウォールのように一部通信だけを許可するといった柔軟な制御はできない。また、シグネチャなどの条件に合致してはじめて検知ができる構造である点に注意が必要だ。仮にどのシグネチャにも合致しない通信があった場合には、アプリケーション情報が出てこず、ログとしても上がらないということになる。

　このようなアプリケーション制御を目的に開発されたのが、アプリケーションインスペクション型のファイアウォールだ。このタイプのファイアウォールでは、トラフィック分類処理の中で、アドレスやポート番号を抜き出すのと同じようにアプリケーション情報を抜き出し、それらの情報を用いた通信制御ができる。このため、ファイアウォールの強みであるポジティブセキュリティモデルを活用した通信制御を行うことができる。

　つまり、一部の通信だけ不許可にしたり、逆に一部だけを許可することが可能で、さらにいえばポリシーで許可しようがしまいが、通信ログ上にはアドレスやポート番号と同じようにアプリケーション情報が自動的に記載されることになる。

　アプリケーション識別処理における違い

　しかし、ここで疑問が出てくる。アプリケーションインスペクション型のファイアウォールであっても、アプリケーション識別で使っている技術はIPSと同じようにシグネチャ検知や振る舞い検知といった技術であるはずなのに、なぜトラフィック分類処理の時点でアプリケーション識別ができるのだろうか。

　そこで、内部での識別処理の違いを、もう少し具体的な例を交えてみていこう。

　例えば「2ちゃんねるの書き込み」というアプリケーションの通信をブロックしたいとする。IPSの場合は、通信に対する内部の識別処理も非常にシンプルだ。「2ちゃんねるの書き込み」という操作に該当する通信に対してシグネチャを設定し、このシグネチャパターンに該当するパケットが通過すればブロックされ、ログに上がることになる。

　しかし、アプリケーションインスペクション型のファイアウォールの場合には、話はもう少し複雑だ。

　前述のとおり、ファイアウォールはすべての通信に対して分類処理を行う必要がある。とはいえ、ファイアウォールがまるで預言者のように、2ちゃんねるの書き込み通信を行おうとしているユーザーをあらかじめ予想して、最初の通信パケットからブロックできるかというと、当然そんなことは不可能だ。

　なぜなら、その通信パケット（もっと具体的にいえばTCPのSYNパケット）には、アプリケーションを特定するために必要な情報が入っていないからだ。これはさらに後続のパケットが到着しても同じことで、この状況は、実際にユーザーによる「書き込み」操作に該当する通信パケットがやってくるまで変わらない。

　つまり、アプリケーションは変化する。従ってアプリケーションインスペクション型のファイアウォールも、IPSと同じように、継続的にパケットに対してシグネチャ検知などの処理を行って、もしアプリケーション情報に何がしかの変化があれば、トラフィック分類におけるアプリケーション情報も更新している。

　さらにいえば、このトラフィック分類というのは例外を作らず、すべてのパケットに対して必ず行わなければならない。このため、すべての通信パケットは必ず、何かしらのアプリケーションとして識別されることになる。つまり、“結果的に”2ちゃんねるの書き込みになる通信であっても、ユーザーが書き込み操作を行うまでは、別のアプリケーションとして分類され、その情報を基に通信制御が行われることになるのだ（図4）。

図4　通信フェイズにおけるアプリケーション識別処理の推移

　ここまでの話だけ聞くと、「ファイアウォールだとそんなに複雑な処理が必要になるなら、IPSで単にブロックすればいいではないか」と思われるかもしれない。確かに、先に述べたとおり、対象のアプリケーションがあらかじめ決まっていて、それだけを不許可にしたいというブロック制御であれば、内部処理の面から見てもIPSの方がシンプルでよさそうだ。

　だが、今企業ネットワークが置かれている状況を考えると、別の視点もある。インターネットへの接続環境も備えた一般的な企業ネットワークの管理者で、自分のネットワークにどのようなアプリケーションが流れているかをきちんと知っている人は、そう多くはないはずだ。アプリケーションをブロックするかどうか、そこに内在するリスクによって対応方法を検討しようにも、そもそもどのようなアプリケーションが流れているか分からないのでは対応のしようがない。

　連載の第1回でも触れたように、現在のアプリケーションの多くは、情報漏えいやマルウェアなどの脅威といったデメリットだけでなく、従業員の生産性を向上したり、コストを削減しながらビジネスを大きく発展させるようなメリットも数多く提供してくれる。これらを無視して盲目的にブロックしてしまうのでは、セキュリティリスクとともにビジネス拡大のチャンスも減らしてしまう。

　従って、ネットワーク上を流れるアプリケーション通信をすべて漏れなく監視しながら、必要に応じて許可／ブロックという制御が行えるかどうかがまさに重要となる。今回紹介したような通信制御のアプローチの違いも考慮しながら、管理者はIPSまたはファイアウォールによるアプリケーション制御を慎重に検討する必要があるだろう。

2/2

Index
今そこにある“機器”、最新技術を追う
	Page1 典型的なセキュリティ機器は新たな脅威にどう対応？ 「火を防ぐ壁」という名を冠するファイアウォール
	Page2 新しいアプリと脅威に対するファイアウォールの有効性 文字通り“攻撃を防ぐ”IPS 今日のアプリと脅威に対するIPSの有効性 ファイアウォール vs IPS、本命は？

ソーシャルアプリ時代のセキュリティ 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）