UTMとは
ファイアウォールはセキュリティのためのアプライアンス NW 機器ですが、できることはレイヤー 4 までの制御、つまり、送信元、宛先の IP アドレスや TCP/UDP のポート番号により、通信を制御することまでです。
しかし、昨今ではマルウェア対策を始め、様々なセキュリティ対応が求められるようになってきており、 そのセキュリティ対策 1 つ 1 つに設備投資するのは効率的ではありません。
そこで登場したのが UTM (Unified Threat Management) です。
UTM は従来のファイアウォール機能に加え、アンチウィルスや IPS、スパム、URL フィルタ等の様々なセキュリティ機能が搭載しており、ライセンスを追加することで必要な機能を必要なタイミングで適用することができるセキュリティ製品です。
UTM の役割、機能
UTM の機能には、主に以下の4つがあります。
アンチウィルス、アンチマルウェア
http やメール通信 (SMTP/POP3/IMAP4)、ファイル共有通信 (SMB) のウィルスを検知・ブロックします。シグネチャベースが多いですが、最近はサンドボックス (ふるまい検知) によるゼロデイ攻撃対策も増えてきています。
アンチスパム
スパムメールを検知・メール件名へのタグ付け・隔離します。
検知は管理者へログによる通知、メール件名へのタグ付けはメール受信者へ注意喚起や迷惑メールフォルダへの誘導、隔離は UTM 本体の HDD に格納し、エンドユーザからログインして隔離されたメールを見れるようにする、等の機能を提供します。
Webコンテンツフィルタ/URLフィルタ
好ましくない Web サイトへのアクセスを制限します。
URL フィルタのデータベースを作成する業者が、全てのサイトをカテゴリー (ブログ、SNS、アダルト、薬物といった区分) に分類しており (産まれ立てのサイトは「未分類」)、UTM はそのデータベースを利用してフィルタリングを行います。
URL フィルタでエンドユーザのアクセスを制限する NW 管理者は、カテゴリ単位で制限したり、NW 管理者が特定した URL を許可 (ホワイトリスト) したり拒否 (ブラックリスト) したりできます。
IPS/IDS
既知の脆弱性をついた通信をする悪意のある通信や、好ましくないソフト (P2P 等) の通信を検知・ブロックします。
SSL インスペクションと SSL/TLS の復号
アンチウィルスと IPS/IDS は主にレイヤ 4 より上位層のパケットの中身を見るので、https 等の SSL/TLS で暗号化された通信については検知することができません。
Google のレポートによると、日本を含む世界の Chrome ブラウザを使った通信の 90% 近くが https である、と報告されています。
つまり、せっかくアンチウィルス、IPS/IDS の有償ライセンスを買って導入したけど、12% の通信しかチェックできていませんでした、ということになりかねません。
もし完全な機能としてアンチウィルス、IPS/IDS を使うためには、UTM 自体で https を SSL/TLS 復号させたりします。
このことを一般的に SSL インスペクションと呼びます。
なお、FortiGate の場合、SSL/TLS 復号をするタイプを「ディープインスペクション」と呼び、復号をせず SNI で宛先のみを特定するタイプを「Certificate インスペクション」と呼んでいます。
UTM で SSL/TLS 復号を実現する方法 (SSL/TLS 復号化方法) は以下の 2 パターンがあります。
1. 透過プロキシ
UTM でサーバ証明書を自ら生成し、https を取り次ぎます。
サーバ証明書の秘密鍵が手に入らないような、社外の https サーバ等への通信を管理したい場合に使う方法です。
例えば、https://www.example.com へ通信する際には UTM が自ら「SANs = www.example.com のサーバ証明書」を作成し、それをクライアントへ提示します。
上図の構成の通り、UTM はサーバ証明書を偽装するため、クライアントには UTM のルート証明書を「信頼された証明機関」として PC へインストールする必要があります。
PC へのインストール方法や確認方法については以下を参照ください。
このルート証明書インストールは、端末キッティングの際にマスターイメージに埋め込んでおくか、ActiveDirectory のグループポリシーで配布するのが一般的です。
ルート証明書は一般的なもの (Very Sign や Glogal Sign 等) は Windows OS として最初からインストール (= 信頼) していますが、今回のように自前で作成するルート証明書については設定として入れ込む必要があります。この構成により UTM 自体が SSL/TLS の暗号化/復号を多く処理することになるので負荷は高くなります。機器選定の際には上位機種を選ぶなど考慮が必要です。メーカや機種によっては SSL/TLS 暗号化/復号専用のオフロードカードを搭載していますので、そのような機種を選ぶのが無難でしょう
2. リバースプロキシ
対象サーバの証明書と秘密鍵を UTM 内にインストールし、https を取り次ぎます。
主に秘密鍵が手に入る社内サーバなどを守るために使う方法です。リバースプロキシのようにクライアントとの https 通信をいったん終端し、復号してチェックをした後、UTM から対象の Web サーバに対して https 通信を代理で行います。
メリットとしては証明書を偽装する必要がないのでクライアント側でのルート証明書の準備が不要なことです。
デメリットとしては、セキュリティの絶対的な要である秘密鍵をサーバから抜き出すこと、2 箇所で管理する必要があることです。(まあ、大した問題ではありません。)
SNI の仕組み
SNI とコモンネーム、SANs、ワイルドカード
FortiGate や PaloAlto 等の多くの UTM は、https であっても、TLS handshake 時の Client Hello の SNI を読み取り、そこに記載された URL を通信先としてURLフィルタの検査を行います。
昔はサーバから送られるサーバ証明書のコモンネームや SANs (サブジェクト代替名) を見て URL を特定する時代もありましたが、ワイルドカードを使われると大きくアクセス許可できてしまい、さらに悪意のあるサーバがワイルドカードを使えば大きなリスクになります。一方、SNI はクライアントが提示する、特定の 1 つの URL になるため安全です。
このあたりの用語の意味や仕組みについては以下をご参照下さい。
SNI による FQDN 特定
下図は www.wireshark.org へアクセスしたときのパケットキャプチャです。TCP 3way Handshake の後に ClientHello (TLS handshake の 1 パケット目) が送信されており、その中に SNI extension が含まれており、『Server Name: www.wireshark.org 』となっているのが見えます。
なお、1 つ注意点としては、SNI ではフルパスを見ることができません。つまり、https://www.example.com/hogehoge/fuga.html というアクセスをするときであっても、SNI で読み取れる情報は [ www.example.com ] のみです。つまり、/hogehoge/fuga.html は (http ヘッダのみに存在し、暗号化されているため、) 見ることができません。
コンテンツフィルタを行う上で、フルパスを見ないと分類ができないようなサイトは、SNI だけの判定ではうまく判別できない可能性があります。
このあたりについては以下の記事も併せてご参照下さい。
UTM は必要ないという意見
UTM は様々な機能がついたセキュリティ万能機器という位置づけですが、万全とは言い難い面もあります。
例えばウィルスチェック等は、数 MB のマルウェアファイルの検知を、高々 1500 Bytes 程度のパケット単位で実施します。
キャッシュ領域にファイルを組み上げてチェックする、という方式もありますが、速度が極端に遅くなることから、最近ではあまり使われない方式になっています。
なので UTM のアンチウィルス等は、マルウェアの大部分をバサッと取り除く程度に考え、それに加え、エンドポイントによる保護 (つまり PC 側のアンチウィルスソフト) と併せて実施する、と考えるほうが良いでしょう。
おすすめメーカ
個人的なオススメは、PaloAlto か Fortigate です。
理由は、設定の構造が分かりやすく設定変更やファームアップ等が行いやすい、安定して動作する、の2点です。
【厳選 4 冊】ネットワークセキュリティを学ぶための本
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント