目次

「オフライン」のAgent

コンピュータの ステータス が「オフライン」または「管理対象(オフライン)」の場合は、 Workload Security がエージェントのインスタンスとしばらく通信しておらず、ハートビート不足のしきい値を超えています。このステータスの変化はアラートおよびイベントにも示されます。

原因

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

  • 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が実行されていることを確認する

エージェントエージェントが実行されていることを確認します。方法は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でのアップグレードの問題を解決する

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

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