25/12/15 11:38

【多層防御で強化】Netskopeで実現。EDR/EPPを補完するランサムウェア対策

面白説明おじさんになりたいはんです。

ここ最近のランサムウェア被害は、EDRを入れていても被害拡大を止めきれなかった事例が目立ちます。考えられる原因の一つに侵入後の通信を止め切れていないことでが挙げられます。端末での対策は重要ですが、それだけでは十分ではありません。侵入後に行われる「通信」が被害を広げてしまうからです。

本エントリでは「通信」の防御が必要なのかを整理し、ネットワークの可視化と制御で現実的に備える方法を解説します。

1. 攻撃者の戦術：暗号化トンネル悪用とDNSの盲点

EDR/EPPは侵入阻止と早期検知・封じ込めの第一防御です。しかし攻撃は日々巧妙になっており、EDR/EPPの無効化を狙ったりや監視の目をかいくぐるような通信を行うことで検知されないような行動をとります。そのため、マルウェアに突破されてしまった後に被害が拡大するかどうかは、不正なネットワーク通信をいかに阻止するかが重要となります。

1-1. 悪性トラフィックの隠れ蓑として多用されるDNS

マルウェアの攻撃は、監視の目をかわす暗号化トンネルを多用します。典型的なものは下記のようなDNS関連の暗号化です。DNSはインターネット接続に必須で、ファイアウォールで許可されていることが多いため、悪用されやすいプロトコルです。

DoH (DNS over HTTPS)
- 仕組み： DNSの問い合わせをHTTPS（HTTP/2やHTTP/3）プロトコルに乗せて行う
- 特徴：誰でも簡単に盗聴・改ざんを防げる
- リスク：Web通信に紛れるため、識別・遮断が困難。マルウェアが悪用しやすい。
DoT (DNS over TLS)
- 仕組み：従来のDNS通信をTLS暗号化して行う
- 特徴：システム全体を堅牢に暗号化できる
- リスク：専用ポート(TCP:853)を使うため遮断は容易だが、許可すると中身は見えない
QUIC
- 仕組み：UDPを利用した高速な通信。DNSの問い合わせもQUICプロトコルに乗せて行う
- 特徴：通信が高速で、モバイル環境に強い
- リスク：解析ツールが未対応なケースが多く、通信内容の監査がほぼ不可能に近い

ネットワークセキュリティにおいて何らかの対策を行わなかった場合、これらの通信は実質的に検査が困難になります。DNSは業務必須ゆえに許可されやすく、悪用余地が大きいのが実情です。

1-2. DNSトンネリング／エクスフィルトレーションの実際

攻撃者は、これらの「名前解決をするだけの安全なプロトコル」だという妄信を利用して悪用してきます。

C2通信（Command & Control）

マルウェアはまず端末に潜伏し、DoHで外部の攻撃者DNSへ問い合わせます。TXTレコードで受け取った小さな断片を端末側で復元し、次の行動（追加のマルウェア取得や暗号鍵の取得）を決定します。単純なファイアーウォールでは「普通のWeb通信」であるHTTPS(TCP433)にみえるため許可せざるを得ず、検知・ブロックする手立てがありません。

情報漏洩（DNS Exfiltration）

機密データをエンコードしてサブドメインに埋め込みDNSクエリとして外部へ搬送します。

マルウェアは機密データを暗号化してサブドメインに埋め込みDNSクエリを発行。プロトコルはDoH(DNS over HTTPS)を利用
ファイアウォールはTCP433のHTTPSであるため許可。なお暗号化されているため中身の検査はできない
攻撃者のDNSサーバーは、クエリを受け取り復号化して情報を抽出

暗号化トンネル（DoH/DoT/QUIC）に包まれると、ネットワーク側の観測や制御はさらに難しくなります。

2. 「見えない通信」を止める対策

エンドポイント監視を補完する形で、通信の可視化・制御を担うネットワーク防御（第二防線）が対策として必要となります。

対策1：検査が困難なトンネルの識別と制御

DoH/DoT/QUICなど、初期C2や漏洩経路に悪用されやすいプロトコルをアプリケーションレベルで識別し、原則ブロックします。

補足）DoH/DoTをブロックすると多くの実装で平文DNSへフォールバックしますが、アプリ内蔵DoHや強制設定環境では影響が出る場合があります。事前検証と例外設計が必要です。

対策2：リスクに基づくドメインアクセス制御

ランサムウェア等のマルウェアの通信の何割かは既知の悪性ドメインにアクセスしているとの報告があります。またこれらを回避するために短期間でドメインを使い捨てするといった方法をとることもあります。これらの既知の悪性・高リスク・未分類ドメインなどをセキュリティ専門家の評価に基づいてブロックすることで、攻撃を大幅に緩和することができます。

補足）従来のポート中心の許可モデルでは見逃しやすいです。アプリ識別とインライン復号を前提に、社外アクセスやローミング端末にも等しく適用できる基盤が求められます。

対策3：暗号化通信のインライン復号とリアルタイム検査

暗号化トンネルを利用したDNSが使えなくないとなると、ファイアウォールで許可されがちなWeb通信がフォーカスされます。そこで重要となるのがSSL暗号化がなされたHTTPS通信の復号化と検査、つまり「SSLインスペクション」です。

このインスペクションを元に悪性ペイロード、C2通信、漏洩兆候をリアルタイムで検査・抑止するのが重要となります。

3. Netskope SSEで実装する防御

NetskopeのSSEは、主に次の機能で「見えない通信」を止めます。

4-1. C2初期接続を断つ（DoH/DoT/QUICの制御）

不正な通信の隠れ蓑となるDNSにおける暗号化トンネルをブロックします。
NetskopeはクラウドファイアウォールとCASBが高度に統合しているため、一つの管理コンソールで設定が可能です。

Netskopeの管理コンソールですべてを設定できる

DoHのブロック

管理コンソール > Policies > Real-time Protection にて [NEW POLICY]ボタンから [Cloud App Access] を選択
- Application = のところで [DNS over HTTPS] を選択
- Profile & Actions では「Block」「No Notification (Mute)」を選択
- ここで「Don't generate Alerts」をチェックしておくとアラートが抑制されるので管理が容易

DoTのブロック

ファイアウォールアプリにてDoT定義 > ポリシー設定の順に行います
管理コンソール > Settings > Security Cloud Platfom > App Definition > [CLOUD & FIREWALL APPS]タブにて [NEW APP DEFINITION] から[Firewall App]を選択し以下のような定義を作成

管理コンソール > Policies > Real-time Protection にて [NEW POLICY]ボタンから [Firewall] を選択
- Application = のところで先ほど定義した [DNS over TLS] を選択
- Profile & Actions では「Block」を選択

QUIC のブロック

ファイアウォールアプリにてDoT定義 > ポリシー設定の順に行います
管理コンソール > Settings > Security Cloud Platfom > App Definition > [CLOUD & FIREWALL APPS]タブにて [NEW APP DEFINITION] から[Firewall App]を選択し以下のような定義を作成

管理コンソール > Policies > Real-time Protection にて [NEW POLICY]ボタンから [Firewall] を選択
- Application = のところで先ほど定義した [QUIC] を選択
- Profile & Actions では「Block」を選択