はじめに
Trend Micro Deep Securityについて学習するため，自宅の仮想環境にDeep Securityの検証環境を構築しました．
Deep Securityには，管理サーバとなるDeep Security Manager（以下，DSM）と，保護対象のサーバ上で動作するDeep Security Agent（以下，DSA）があります．
製品の概要を読むだけでも，
- DSMからAgentを管理する
- Agentをサーバへインストールする
- FirewallやIntrusion Preventionなどの機能を利用する
といった大まかな構成は理解できます．
しかし，
「Agentをインストールしたあと，どのようにDSMへ登録されるのか」
「DSMとDSAは実際にどの経路で通信しているのか」
「AgentがOnlineになるとは，具体的にどういう状態なのか」
「保護対象サーバへ攻撃・スキャン通信を送る場合，どのような検証環境を作ればよいのか」
といった部分は，実際に環境を作ってみないとなかなかイメージできませんでした．
そこで今回は，DSM，DSA，Kali Linuxをそれぞれ用意し，Deep Securityの基本的な管理構成を自宅環境で再現してみることにしました．
最終的には，DSM上でDSAを
Managed (Online)
として管理できるところまで確認しています．
また，構築途中では，
Agentは正常に起動している
↓
DSMへのTCP通信もできる
↓
それでもDSMではManaged (Offline)
という問題にも遭遇しました．
最終的には名前解決が原因だと分かりましたが，このトラブルを調査したことで，DSMとDSAの通信やHeartbeatの仕組みについても理解を深めることができました．
この記事では，単純なインストール手順だけではなく，
- なぜこのような構成にしたのか
- DSMとDSAはそれぞれ何をしているのか
- 管理通信と検証用通信をどのように分離したのか
- AgentのOnline／Offlineは何によって決まるのか
- 構築中にどのような問題が発生したのか
という点を中心にまとめます．
今回の検証でやりたかったこと
今回の一番の目的は，Deep Securityの構成を実際に動かして理解することです．
特に確認したかったのは，DSMとDSAの関係です．
Deep Securityでは，保護対象のサーバすべてをDSM自身が直接保護するわけではありません．
保護対象となるサーバにはDSAを導入し，DSMからそれらのAgentを管理する構成になります．
イメージとしては，
┌──────────────────────┐
│ Deep Security Manager │
│ DSM │
│ │
│ ・Agentの管理 │
│ ・設定の管理 │
│ ・状態の確認 │
│ ・イベントの確認 │
└──────────┬───────────┘
│
│ 管理通信
│
┌──────────▼───────────┐
│ Target Server │
│ │
│ Deep Security Agent │
│ DSA │
└───────────────────────┘
という関係です．
そこで今回は，DSMとDSAをあえて別々の仮想マシンに構築しました．
さらに，保護対象のTargetへ外部から検証用の通信を送るため，Kali Linuxも用意しました．
最終的には，
Kali Linux
│
│ スキャンなどの検証通信
▼
Target
└─ Deep Security Agent
│
│ 管理通信
▼
Deep Security Manager
という環境を作ることを目標としました．
検証環境
今回用意した仮想マシンは3台です．
| マシン | OS | アーキテクチャ | 役割 |
|---|---|---|---|
| DSM | RHEL 9.8 | x86_64 | Deep Securityの管理サーバ |
| Target | RHEL 9.8 | ARM64 | DSAを導入する保護対象サーバ |
| Kali Linux | Kali Linux | ARM64 | Targetへの検証用通信を発生させるマシン |
少し特殊なのは，これらが同じ仮想化基盤上に存在していない点です．
DSMはUbuntuマシン上のKVM/libvirtで動作させています．
一方，TargetとKali LinuxはMac mini上のVMware Fusionで動作させています．
構成としては次のようになります．
DSMとDSAを単純に同一の仮想ネットワークへ置くのではなく，物理的にも仮想化基盤的にも異なる環境に配置しています．
そのため，今回の構築ではDeep Securityそのものだけでなく，
- KVM/libvirt
- VMware Fusion
- 仮想ネットワーク
- ルーティング
- 名前解決
についても考える必要がありました．
DSMの役割
Deep Security Managerは，Deep Security環境全体を管理する中心的なコンポーネントです．
今回の環境では，RHEL 9.8の仮想マシンにDSMを構築しました．
また，DSMが利用するデータベースとしてPostgreSQLも使用しています．
DSMを構築するとWebブラウザから管理画面へアクセスでき，
- Computers
- Policies
- Events & Reports
- Administration
などからAgentや各種設定を管理できます．
今回特に使用したのが Computers です．
ここにはDSMの管理対象となったコンピュータが表示され，Agentの状態についても確認できます．
たとえば，
Managed (Online)
であれば，AgentがDSMの管理下にあり，管理通信が正常に行われている状態です．
一方，今回途中で発生した，
Managed (Offline)
では，Agent自体は登録されているものの，DSMとの継続的な通信に問題が発生していました．
単にAgentをインストールできたかどうかだけではなく，DSMから管理できる状態になっているかを見ることが重要になります．
DSAの役割
Deep Security Agentは，保護対象となるサーバにインストールします．
今回はRHEL 9.8 ARM64をTargetとして用意し，ARM64版のDSAをインストールしました．
今回使用したTargetがARM64であるため，DSMからAgentのインストーラを取得する際にも，対応するプラットフォームを確認しました．
DSMには複数のプラットフォーム向けAgentが用意されているため，
Red Hat Enterprise 9 (64-bit Arm)
に対応するAgentを使用しています．
Agentをインストールしただけでは，まだDSMの管理下には入りません．
インストール後にDSMに対するActivationを行うことで，AgentをDSMへ登録します．
大まかな流れは，
DSAをインストール
│
▼
ds_agentサービス起動
│
▼
DSMへActivation
│
▼
DSMへコンピュータとして登録
│
▼
DSM・DSA間で管理通信
│
▼
Managed (Online)
となります．
今回実際に構築したことで，「Agentのインストール」と「DSMへの登録」は別の処理であることが分かりやすくなりました．
DSMとDSAの通信
DSMとDSAの構築で重要だったのが，両者の通信です．
AgentをDSMへ登録したあとも，DSMとDSAは継続的に通信します．
その中で重要になるものの1つがHeartbeatです．
HeartbeatによってAgentとDSMの間で定期的な通信が行われ，Agentの状態などがDSMへ伝えられます．
そのため，
ds_agentが起動している
ことと，
DSMでManaged (Online)になっている
ことは，同じ意味ではありません．
Agentプロセスが正常に動作していても，DSMとの管理通信が失敗していれば，DSM側ではOfflineになる可能性があります．
今回まさにこの状態を経験しました．
Kali Linux用の検証ネットワーク
今回は管理環境だけでなく，将来的にDeep Securityの保護機能を試せるようにKali Linuxも用意しました．
Kali LinuxからTargetへ，
- ポートスキャン
- サービスの列挙
- 各種検証用トラフィック
などを送信できるようにします．
ただし，普段使用しているLANへ検証用トラフィックを流したくないため，Kali LinuxとTargetの間にはVMware Fusionのプライベートネットワークを用意しました．
┌──────────────────┐
│ Kali Linux │
│ 172.16.130.10 │
└────────┬─────────┘
│
│ VMware Private Network
│ 172.16.130.0/24
│
┌────────▼─────────┐
│ Target │
│ 172.16.130.20 │
│ DSA │
└──────────────────┘
Targetには，
- DSMとの通信などに利用する管理側のインタフェース
- Kali Linuxとの通信に利用する検証側のインタフェース
の2つを持たせています．
これによって，
管理通信
Target ─────────→ DSM
と，
検証通信
Kali ───────────→ Target
を分けて考えることができます．
トラブルが発生した際にも，「DSMとの管理通信がおかしいのか」「KaliとTarget間の検証ネットワークがおかしいのか」を切り分けやすくなります．
AgentのActivation
TargetへDSAをインストールしたあとは，DSMに対してActivationを行いました．
Activationによって，DSMはそのAgentを自身の管理対象として登録します．
Activationが成功するとDSMの Computers に対象が登録され，DSMからAgentの状態を確認できるようになります．
今回もActivation自体は正常に成功しました．
ところが，しばらくするとDSM上で，
Managed (Offline)
となりました．
ここから今回一番時間を使ったトラブルシューティングが始まりました．
Agentは動いているのにManaged (Offline)
最初に確認したのはTarget上のAgentです．
ds_agent のサービスそのものは正常に動作していました．
さらにTargetからDSMが待ち受けているポートへのTCP接続も可能でした．
つまり，
Agent停止
でも，
Target → DSMへの経路がない
でもありませんでした．
そこでAgentのログを確認しました．
すると，Heartbeatの際にAgentが，
https://dsm:4120/
へ接続しようとしていることが分かりました．
そして，その直後には，
getaddrinfo
による名前解決エラーが記録されていました．
つまり，問題はネットワーク到達性ではなく，
dsm
というホスト名をTargetが名前解決できないことでした．
なぜActivationは成功したのか
ここが今回特に興味深かったポイントです．
ActivationではDSMのIPアドレスを直接指定していました．
そのため，
Target
│
│ 192.168.122.82
▼
DSM
という通信ができればActivationは成功します．
しかし，Activation後のAgentはDSMから受け取った設定に従って，
dsm:4120
を接続先として使用していました．
その結果，
Activation
│
│ IPアドレスを直接指定
▼
成功
↓
Heartbeat
│
│ 「dsm」を名前解決
▼
失敗
という状態になっていました．
そのため，
Agentの登録には成功する
↓
DSMのComputersにも表示される
↓
しかしHeartbeatに失敗する
↓
Managed (Offline)
という，一見すると少し分かりにくい状態になっていました．
名前解決を修正
原因が分かったため，Target側で dsm がDSMのIPアドレスへ解決されるようにしました．
今回のような小規模な検証環境では，Targetのhosts設定で，
dsm → 192.168.122.82
となるようにしています．
これによってAgentは，
https://dsm:4120/
への接続時にDSMのIPアドレスを取得できるようになりました．
その後，再度DSMとの通信を発生させると，DSMのComputers画面で，
Managed (Online)
になることを確認できました．
今回のトラブルから分かったこと
今回のトラブルで重要だったのは，
IPアドレスで通信できることと，アプリケーションが実際に使用するホスト名で通信できることは別
という点です．
たとえば，
ping 192.168.122.82
や，
192.168.122.82:4120へのTCP接続
が成功していたとしても，Agentが実際には，
dsm:4120
を使用しているのであれば，dsm の名前解決ができなければ通信できません．
今回の場合，
ネットワーク到達性：OK
TCP 4120：OK
ds_agent：Running
Activation：OK
名前解決：NG
Heartbeat：NG
DSM表示：Offline
という状態でした．
名前解決を修正したことで，
ネットワーク到達性：OK
TCP 4120：OK
ds_agent：Running
Activation：OK
名前解決：OK
Heartbeat：OK
DSM表示：Online
となりました．
AgentがOfflineになった場合，サービスの起動状態だけを見るのではなく，
- Agentサービスが動いているか
- DSMへのネットワーク経路が存在するか
- 必要なTCPポートへ接続できるか
- AgentがDSMをどのホスト名で認識しているか
- そのホスト名をTargetから名前解決できるか
- AgentのログにHeartbeatのエラーがないか
という順番で確認すると，原因を切り分けやすいと感じました．
DSMで確認できたもの
AgentがOnlineになったあとは，DSMの管理画面からAgentの状態を確認できました．
Computers では，登録されたコンピュータとAgentのOnline／Offline状態を確認できます．
また，Events & Reports のSystem Eventsでは，
- AgentのActivation
- コンピュータの登録
- Policyの送信
- Agent関連の管理イベント
などを確認できました．
ここまでで，
Agentをインストールする
↓
DSMへ登録する
↓
DSMと継続的に通信する
↓
DSMから状態を確認する
というDeep Securityの基本的な管理の流れを実際に確認することができました．
FirewallとIntrusion Preventionについて
当初はここからさらに，Kali LinuxからTargetへポートスキャンなどの通信を送り，
Kali
│
│ 検証通信
▼
Target + DSA
│
│ Firewall / IPS
▼
DSM
├─ Firewall Events
└─ Intrusion Prevention Events
という流れでイベントを確認する予定でした．
しかし，今回のDSMでは，
Firewall and Intrusion Prevention
Not Licensed
となっていました．
そのため，FirewallおよびIntrusion Preventionを利用した検知・防御については今回の検証範囲から外しました．
Kali LinuxとTargetの間のネットワーク自体は構築できているため，Target上でパケットキャプチャを行えばKaliから送信した通信そのものを確認することはできます．
ただし，それはDeep SecurityのFirewall／IPSによるイベント検知とは別です．
今回の構築で，
「AgentをDSMで管理できること」と「Deep Securityの各保護機能を利用できること」は別
であることも確認できました．
今回構築できたところ
最終的に，今回の検証では次のところまで確認できました．
- RHEL 9.8へのDeep Security Managerの構築
- PostgreSQLとの連携
- KVM/libvirt上でのDSM運用
- ARM64版RHELへのDeep Security Agent導入
- DSMからARM64用Agentパッケージの取得
- Agentサービスの起動
- DSMへのAgent Activation
- DSMのComputersへのTarget登録
- DSM・DSA間の管理通信
- Heartbeatの確認
- Managed (Offline)からManaged (Online)への復旧
- Agentログを利用したトラブルシューティング
- DSM接続先の名前解決問題の特定
- DSMのSystem Eventsの確認
- Kali LinuxとTarget間のプライベートネットワーク構築
当初はFirewallやIPSの検証に目が向いていましたが，実際に構築してみると，その前段階にあるDSMとDSAの管理通信についても多くのことを確認できました．
構築してみて分かったこと
今回一番大きかったのは，Deep Securityの構成を「製品名」ではなく「通信」として考えられるようになったことです．
構築前は，
DSM = 管理画面
DSA = Agent
程度の理解でした．
実際に構築してみると，
DSM
↑
│ Activation
│ Heartbeat
│ 管理通信
│
DSA
↑
│
│ 保護対象への通信
│
Network
という関係になっていることが分かります．
また，仮想化基盤をまたいで構築したことで，単純にソフトウェアをインストールするだけではなく，
- IPアドレス
- ルーティング
- TCPポート
- NAT
- 名前解決
- Agentが認識しているManagerのアドレス
といったネットワーク側の要素についても意識する必要がありました．
特に今回の「IPアドレスではDSMへ到達できるのに，AgentはOffline」という問題は，疎通確認だけで問題なしと判断してはいけないことを改めて確認できる事例でした．
おわりに
今回は，自宅の仮想環境にTrend Micro Deep Securityの検証環境を構築しました．
DSMをUbuntu上のKVM/libvirt，DSAをMac mini上のVMware Fusionという異なる環境に配置し，DSMへのAgent登録から継続的な管理通信まで確認しました．
途中ではAgentが Managed (Offline) になる問題が発生しましたが，Agentログを確認することでDSMのホスト名を名前解決できていないことを特定し，最終的には Managed (Online) まで持っていくことができました．
今回の構築を通して，
DSMを構築する
↓
DSAをTargetへ導入する
↓
AgentをActivationする
↓
DSMの管理下へ登録する
↓
Heartbeatを含む管理通信を確立する
↓
DSMからAgentの状態を確認する
というDeep Securityの基本的な流れを一通り確認できました．
FirewallとIntrusion Preventionについてはライセンスの関係で今回検証できませんでしたが，それらの機能を試すための前段となる管理環境と検証ネットワークは構築できました．
実際に環境を作ってみることで，ドキュメントを読むだけでは見えにくかったDSM・DSA間の通信や，名前解決を含めたネットワーク設計の重要性を理解するよい機会になりました．
