ビュー:
コンピュータのステータスがオフラインまたは管理対象 (オフライン) である場合、Deep Security ManagerがDeep Security Agentのインスタンスとしばらく通信しておらず、ハートビートのしきい値を超えたことを意味します (ハートビートの設定を参照)。ステータスの変更は、アラートやイベントにも表示されることがあります。

原因

ハートビート接続が失敗する理由は次のとおりです:
  • エージェントはシャットダウンされたワークステーションや他のコンピュータにインストールされています。Deep Securityを使用して、時々シャットダウンされるコンピュータを保護する場合、それらのコンピュータに割り当てられたポリシーがハートビートの欠落時にアラートを発しないようにしてください。ポリシーエディタで[設定]→[一般]→[次の数を超えるハートビートが失われた場合にアラートを発令]に移動し、設定を無制限に変更します。
  • ファイアウォール、IPSルール、またはセキュリティグループが、ハートビートポート番号をブロックしている。
  • 送信 (エフェメラル) ポートが誤ってブロックされた。トラブルシューティングのヒントについては、Activation Failed - Blocked portを参照してください。
  • 双方向通信が有効になっているが、許可されている、または安定しているのが一方向のみである (通信方向を設定するを参照)。
  • コンピュータの電源がオフになった。
  • コンピュータはプライベートネットワークのコンテキストを離れました。これは、ローミングエンドポイント (例えば、ノートパソコン) が現在の場所でマネージャに接続できない場合に発生することがあります。例えば、ゲストWi-Fiはしばしばオープンポートを制限し、インターネットを介してトラフィックが流れる際にNATを使用します。
  • Amazon WorkSpaceコンピュータの電源がオフになっており、ハートビート間隔が速くなっています (例えば、1分)。この場合、WorkSpaceが完全に電源オフになるまで待ち、その時点でステータスがオフラインからVM停止に変わるはずです。
  • DNSが停止したか、Managerのホスト名を解決できなかった。
  • Manager、Agent、またはその両方で、システムリソースの負荷が非常に高い。
  • Agentプロセスが稼働していない可能性がある。
  • SSLまたはTLS接続における相互認証の証明書が無効または失効しました (Deep Security Manager SSL証明書の置き換えを参照)。
  • エージェントまたはマネージャのシステム時間が正しくありません（SSL/TLS接続で必要です）。
  • Deep Securityルールアップデートはまだ完了しておらず、一時的に接続が中断されています。
  • AWS EC2で、ICMPトラフィックが必要だが、ブロックされている。
  • エージェントバージョン20.0.0.6313以降にアップグレードした後も、エージェントがSHA-1アルゴリズムを使用している場合、エージェントはマネージャとの通信に対して新しく、より安全な暗号アルゴリズムのみを許可します。
ヒント
ヒント
Managerからの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更する必要があります (Agentからのリモート有効化と通信を使用してAgentを有効化および保護するを参照)。
エラーをトラブルシューティングするには、エージェントが実行中であり、マネージャと通信できることを確認してください。

Agentが実行されていることを確認する

エージェントがインストールされているコンピュータで、Trend Micro Deep Security Agentサービスが実行中であることを確認します。方法はOSによって異なります。
  • Windowsの場合は、Microsoft Windowsサービスコンソール (services.msc) またはタスクマネージャーを開きます。ds_agentという名前のサービスを探します。
  • Linuxの場合は、ターミナルを開き、プロセスをリストするコマンドを入力します。次のコマンドを実行して、ds_agentまたはds-agentという名前のサービスを検索します。
    sudo ps -aux | grep ds_agent
    sudo service ds_agent status
  • Solarisの場合は、ターミナルを開き、プロセスリストのコマンドを入力します。次のコマンドを実行して、ds_agentという名前のサービスを検索します。
    sudo ps -ef | grep ds_agent
    sudo svcs -l svc:/application/ds_agent:default

DNSを検証する

AgentがIPアドレスではなくドメイン名またはホスト名でManagerに接続する場合は、DNS解決をテストします。
nslookup [Managerのドメイン名]
DNSサービスは信頼できる必要があります。
テストが失敗した場合、エージェントが正しいDNSプロキシまたはサーバを使用していることを確認してください (内部ドメイン名はGoogleやISPなどのパブリックDNSサーバでは解決できません)。dsm.example.comのような名前がIPアドレスに解決できない場合、正しいルートとファイアウォールポリシーがIPアドレスに対して存在していても、通信は失敗します。
コンピュータがDHCPを使用している場合、コンピュータまたはポリシー設定の[ネットワークエンジンの詳細]エリアで[DHCP DNSを強制的に許可]を有効にする必要があるかもしれません (コンピュータおよびポリシーエディタ設定を参照)。

送信ポートを許可する (Agentからのハートビート)

Managerの必要なポート番号にtelnetで接続して、ルートが存在し、ポートが開いていることを確認します。
telnet [manager IP]:4120
Telnetの成功は、pingと同じことのほとんどを証明します: ルートと正しいファイアウォールポリシーが存在し、イーサネットフレームサイズが正しいことです。マネージャのデフォルトのセキュリティポリシーを使用するコンピュータでは、pingは無効になっています。ネットワークは、攻撃者の攻撃の予兆スキャンをブロックするために、ICMP pingとtracerouteをブロックすることがあります。そのため、通常はマネージャにpingを送信してテストすることはできません。
telnetが失敗した場合は、ルートをトレースして、ネットワークのどのポイントで接続が中断されているかを特定します。
  • Linuxの場合は次のコマンドを入力します。
    traceroute [AgentのIP]
  • Windowsの場合は次のコマンドを入力します。
    tracert [AgentのIP]
ファイアウォールポリシー、ルート、NATポートフォワーディング、またはそのすべてを調整して問題を修正します。WindowsファイアウォールやLinux iptablesなど、ネットワークおよびホストベースのファイアウォールの両方を確認してください。AWS EC2インスタンスの場合は、AmazonのドキュメントAmazon EC2 Security Groups for Linux InstancesまたはAmazon EC2 Security Groups for Windows Instancesを参照してください。Azure VMインスタンスの場合は、Microsoft AzureのドキュメントModifying a Network Security Groupを参照してください。
エージェントからマネージャへの接続テストが成功した場合、次に逆方向の接続をテストする必要があります (ファイアウォールやルーターは、接続を許可するためにポリシールートペアを必要とすることがよくあります。必要なポリシーやルートのうち一方のみが存在する場合、パケットは一方向には許可されますが、もう一方向には許可されません)。

受信ポートを許可する (Managerからのハートビート)

ManagerからAgentにpingを実行し、ハートビートポート番号にtelnetで接続して、ハートビートと設定のトラフィックがAgentに到達できることを確認します。
ping [AgentのIP]
telnet [agent IP]:4118
pingとtelnetが失敗した場合は、次のコマンドを実行します。
traceroute [AgentのIP]
これによって、ネットワークのどのポイントで接続が中断されているかを検出します。ファイアウォールポリシー、ルート、NATポート転送、またはこれら3つすべてを調整して、問題を解決します。
IPSルールまたはファイアウォールルールがAgentとManagerの間の接続をブロックしている場合は、Managerが接続して問題の原因であるポリシーを割り当て解除することができません。解決するには、コンピュータで次のコマンドを実行してAgentのポリシーをリセットします。
dsa_control -r
このコマンドを実行した後に、Agentを再び有効化する必要があります。

Amazon AWS EC2インスタンスでICMPを許可する

AWSクラウドでは、ルータにICMP type 3 code 4が必要です。このトラフィックがブロックされていると、AgentとManager間の接続が中断される場合があります。
Deep Securityで強制的にこのトラフィックを許可できます。強制的に許可するファイアウォールポリシーを作成するか、コンピュータまたはポリシーの [ネットワークエンジンの詳細] で、[ICMP type3 code4を強制的に許可] を有効にします (ネットワークエンジンの詳細設定を参照)。

Solaris 11でのアップグレードの問題を解決する

以前に Solaris 11 に Deep Security Agent 9.0 をインストールし、その後エージェントソフトウェアを 9.0.0-5616 またはそれ以降の 9.0 エージェントをインストールせずに直接 11.0 にアップグレードした場合、問題が発生する可能性があります。このシナリオでは、アップグレード後にエージェントが起動に失敗し、Deep Security Manager でオフラインとして表示されることがあります。この問題を解決するには:
  1. サーバからAgentをアンインストールします。Deep Security Agentをアンインストールするを参照してください。
  2. Deep Security Agent 11.0をインストールします。 手動でエージェントをインストールするを参照してください。。
  3. マネージャでエージェントを再アクティブ化します。エージェントをアクティブ化するを参照してください。