「オフライン」のAgent

Managerで設定した失われたハートビートのしきい値を超えると、コンピュータのステータスが「オフライン」または「管理対象 (オフライン)」に変わります。この状況はアラートとイベントにも示されます。

ハートビート接続が失敗する原因としては次のことが考えられます。

  • コンピュータの電源がオフになった。
  • コンピュータがプライベートネットワークのコンテキスト外に移動した。
    この状況は、オンプレミスのDeep Security Managerを使用していて、エンドポイント (ノートパソコンなど) がインターネット経由でプライベートな社内ネットワーク上のManagerに接続できない場合に発生します。
  • Amazon WorkSpaceのコンピュータの電源をオフにしようとしていて、ハートビート間隔が短い (1分など)。この場合、WorkSpaceの電源がオフになるまで待ちます。オフになった時点でステータスは「オフライン」から「仮想マシン停止」になります。
  • DNSが停止したか、Managerのホスト名を解決できなかった。
  • ファイアウォール、IPSルール、またはAWSセキュリティグループが、ハートビートポート番号をブロックしている。
  • 双方向通信が有効になっているが、許可されている、または安定しているのが一方向のみである。
  • Deep Security ManagerかAgent、またはその両方で、システムリソースの負荷が非常に高い。
  • Deep SecurityAgentプロセス (Windowsではds_agentサービス) が稼働していない可能性がある。
  • SSLまたはTLS接続の相互認証用証明書が無効になったか失効した、あるいはシステム時間が正しくない。
  • Deep Securityルールアップデート中で、接続が一時的に中断している。
Managerからの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更することを強く推奨します (クラウドアカウント環境の通信方向を参照)。

サービス、ルート、およびポート番号を調べて、Deep Security Agentが実行されていること、およびDeep Security Managerと通信できることを確認します。

  1. Deep Security Agentがインストールされたコンピュータで、Trend Micro Deep Security Agentサービスが実行されていることを確認します。方法はOSによって異なります。

    • Windowsの場合は、Microsoft Windowsサービスコンソール (services.msc) またはタスクマネージャーを開きます。
    • Linuxの場合は、ターミナルを開き、次のようなプロセスをリストするコマンドを入力します。

      sudo ps -aux | grep ds_agent

      sudo service ds_agent status

  2. AgentがIPアドレスではなくドメイン名またはホスト名でDeep Security Managerに接続する場合は、DNS解決をテストします。

    nslookup [Managerのドメイン名]

    テストが失敗した場合は、Agentが正しいDNSプロキシまたはDNS Serverを使用していることを確認します (GoogleやISPなどのパブリックDNS Serverでは内部ドメイン名を解決できません)。IPアドレスに正しいルートとファイアウォールポリシーが設定されていても、dsm.example.comなどの名前をIPアドレスに解決できないと、通信は失敗します。

  3. Deep Security Managerの必要なポート番号にtelnetで接続して、ルートが存在し、ポートが開いていることを確認します。

    telnet [ManagerのIP]:[ハートビートポート]

    Deep Security Managerの初期設定のセキュリティポリシーを使用するコンピュータでは、pingが無効になっています。攻撃者による予兆検索を阻止するためにネットワークがICMP pingとtracerouteをブロックすることがあるため、通常はManagerへpingを実行してテストすることはできません。ただしtelnetの成功はpingの成功とほぼ同意味を持ち、ルートと正しいファイアウォールポリシーが存在すること、およびEthernetフレームサイズが正しいことを示しています。

    一方telnetが失敗した場合は、いくつかの原因が考えられます。原因を迅速に突き止めるために、トラブルシューティングの間はpingとICMPトラフィックを一時的に有効にすることができます。

    telnetが失敗した場合は、ルートをトレースして、ネットワークのどのポイントで接続が中断されているかを特定します。方法はOSによって異なります。

    • Linuxの場合は次のコマンドを入力します。

      traceroute [AgentのIP]

    • Windowsの場合は次のコマンドを入力します。

      tracert [AgentのIP]

    ファイアウォールポリシー、ルート、NATポート転送、またはこの3つすべてを調整して問題を解決します。

    AgentからManagerへの接続テストが成功したら、次に逆方向の接続をテストする必要があります。(ファイアウォールおよびルータでは、1組のポリシー/ルートがないと接続が許可されないことがよくあります。2つ必要なポリシーまたはルートのうち1つしか存在しない場合は、一方向のパケットだけが許可され、逆方向は許可されません)。

  4. Deep Security ManagerからDeep Security Agentにpingを実行し、ハートビートポート番号にtelnetで接続して、ハートビートと設定のトラフィックがAgentに到達できることを確認します。

    ping [AgentのIP]

    telnet [AgentのIP]:[ハートビートポート]

    pingとtelnetが失敗した場合は、次のコマンドを実行します。

    traceroute [AgentのIP]

    これによって、ネットワークのどのポイントで接続が中断されているかを検出します。ファイアウォールポリシー、ルート、NATポート転送、またはこの3つすべてを調整して問題を解決します。

  5. IPSルールまたはファイアウォールルールがDeep Security AgentとDeep Security Managerの間の接続をブロックしている場合は、Deep Security Agentで次のコマンドを実行します。

    dsa_control -r

    これによって、Deep Security Agent上のポリシーがリセットされます。この場合、AgentのセキュリティによってDeep Security Managerとの通信がブロックされているために、Managerが接続して問題の原因であるポリシーを割り当て解除することができません。

    このコマンドを実行した後に、Agentを再び有効化する必要があります。