「オフライン」のAgent

「オフライン」または「管理下の(オフライン)」のコンピュータステータスとは、Workload SecurityがDeep Securityと通信していないことを意味します。 Agentのインスタンスがしばらく停止していて、ハートビートのしきい値を超えています。このステータスの変化はアラートおよびイベントにも示されます。

原因

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

  • Agentは、シャットダウンしたワークステーションまたは他のコンピュータにインストールされます。Workload Securityを使用してコンピュータを保護する場合は、ハートビートが検出されなかった場合にそれらのコンピュータに割り当てられたポリシーでアラートが生成されないようにしてください。ポリシーエディタで、[設定]→[一般]→[ハートビート数]の順に移動して、アラートが発生する前にに移動し、設定を[無制限]に変更します。
  • ファイアウォール、IPSルール、またはセキュリティグループが、ハートビートポート番号をブロックしている。
  • 送信 (エフェメラル) ポートが誤ってブロックされた。トラブルシューティングのヒントについては、「Activation Failed - Blocked port」を参照してください。
  • 双方向通信は有効ですが、一方向のみが許可または信頼されます。
  • コンピュータの電源がオフになった。
  • コンピュータがプライベートネットワークの コンテキスト を終了しました。これは、移動先エンドポイント(ラップトップなど)が現在の場所で Workload Security に接続できない場合に発生します。たとえば、ゲストWi-Fiではオープンポートを制限することが多く、トラフィックがインターネットを通過するときにNATを使用します。
  • Amazon WorkSpaceコンピュータの電源がオフになり、ハートビートの間隔が高速(1分など)になる。この場合、WorkSpaceの電源が完全にオフになるのを待ってください。その時点で、ステータスは「オフライン」から「VM停止」に変わります。
  • DNS がダウンしていたか、Workload Securityホスト名が解決されていません
  • Workload Security、エージェント、またはその両方がシステムリソースの負荷が非常に高い
  • Agentプロセスが稼働していない可能性がある。
  • エージェントのシステム時間が正しくありません(SSL / TLS接続で必要です)。
  • ルールのアップデートはまだ完了していません。一時的に接続が中断されています。
  • AWS EC2で、ICMPトラフィックが必要だが、ブロックされている。

Managerからの通信または双方向の通信で問題が発生した場合は、Agentからのリモート有効化に変更することを強く推奨します (「Agentからのリモート有効化およびAgentからの通信を使用してAgentを有効化して保護する」を参照)。エラーのトラブルシューティングを実行するには、エージェントが実行中であることを確認し、エージェントが Workload Security (マネージャ)と通信できることを確認します。

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を検証する

ドメイン名またはホスト名(IPアドレスではなく)を介してエージェントがWorkload Securityに接続する場合は、DNS解決をテストします。

nslookup [manager domain name]

DNSサービスは信頼できるものでなければなりません。

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

コンピュータがDHCPを使用している場合は、コンピュータまたはポリシー設定の Advanced Network Engine 領域で、 Force Allow DHCP DNS を有効にする必要があります( の[コンピュータとポリシーエディタの設定]を参照)。

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

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

telnet agents.deepsecurity.trendmicro.com:443

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

ファイアウォールポリシー、ルート、NATポート転送、またはこれら3つすべてを調整して、問題を解決します。WindowsファイアウォールやLinuxのiptablesなど、ネットワークおよびホストベースのファイアウォールの両方を確認します。AWS EC2インスタンスの場合は、Amazonのドキュメントの「Linux インスタンスの Amazon EC2 セキュリティグループ」または「Windows インスタンスの Amazon EC2 セキュリティグループ」を参照してください。Azure VMインスタンスについては、 のMicrosoft社のAzureドキュメント( Network Security グループの変更)を参照してください。

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

AWSクラウドでは、ルータにICMP type3 code4が必要です。このトラフィックがブロックされていると、AgentとManager間の接続が中断される場合があります。

このトラフィックを強制的に許可するには、Workload Securityを使用します。強制的に許可するファイアウォールポリシーを作成するか、コンピュータまたはポリシーの [ネットワークエンジンの詳細オプション] で、[ICMP type3 code4を強制的に許可] を有効にします (ネットワークエンジンの詳細設定を参照)。

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

Solaris 11にDeep Security Agent 9.0がインストールされている場合、先に9.0.0-5616以降の9.0 AgentをインストールせずにAgentソフトウェアを11.0へ直接アップグレードすると、問題が発生することがあります。このシナリオでは、エージェントはアップグレード後に起動に失敗し、 Workload Securityでオフラインとして表示されることがあります。この問題を解決するには、次の手順に従います。

  1. サーバからAgentをアンインストールします。「Deep Security Agentをアンインストールする」を参照してください。
  2. Deep Security Agent 11.0をインストールします。エージェントを手動でインストールするを参照してください。
  3. Workload Securityでエージェントを再度有効化してください。「Agentの有効化」を参照してください。