Trend Micro Agent

Siehe auch

Verwandte Artikel

• SELinux

• ClamAV

• Security: Grundlagen

• Security: Tools

Offizielle Dokumentation

• Deep Security 20 Uninstall Agent

• Server & Workload Protection - Activate the Agent

• Server & Workload Protection - Agent Command-Line Interface

• Server & Workload Protection - Communication Ports, URLs, IPs

• Server & Workload Protection - Install the Agent

• Server & Workload Protection - SELinux Support

Unter Linux tritt Trend Micro praktisch immer als derselbe Agent auf: ds_agent. Er stammt aus Deep Security (on-premise Manager), wird unverändert für Server & Workload Protection (SWP, der Cloud-Nachfolger unter Trend Vision One) weiterverwendet und bildet die einzige Linux-Linie von Trend Micro. Apex One existiert dagegen nur für Windows und macOS und taucht auf RHEL-Hosts nicht auf.

Paketierung, Service und Pfade

Der Agent installiert sich als RPM-Paket ds_agent und hinterlegt seine Dateien unter /opt/ds_agent/. Laufzeitdaten (State-DB, Diagnose-Bundles) liegen unter /var/opt/ds_agent/.

Die Service-Unit heisst ds_agent:

systemctl status ds_agent
systemctl restart ds_agent

CLI-Werkzeuge

Alle Werkzeuge liegen unter /opt/ds_agent/. Für den Alltag reichen drei:

dsa_control steuert den Agent gegenüber dem Manager. Wichtige Subkommandos:

• dsa_control -m: einen Heartbeat/Check-in an den Manager erzwingen.

• dsa_control -a dsm://<url>: den Agent gegen einen Manager aktivieren (siehe unten).

• dsa_control -r: Aktivierung zurücksetzen (Reset).

• dsa_control -d: ein Diagnose-Paket unter /var/opt/ds_agent/diag/ erzeugen. Das ist der Output, den Trend Micro im Support-Fall sehen will.

• dsa_control -s 0|1: Self-Protection deaktivieren bzw. aktivieren.

• dsa_control -x dsm_proxy://<url>: HTTP-Proxy für die Manager-Kommunikation.

dsa_query fragt den lokalen Status ab, ohne mit dem Manager zu sprechen. Nützlich:

• dsa_query -c "GetAgentStatus": aktueller Aktivierungs- und Online-Status.

• dsa_query -c "GetHostInfo": was der Agent über sich selbst meldet.

• dsa_query -c "GetComponentInfo": installierte Engine-/Pattern-Komponenten.

dsa_scan löst einen On-Demand-Malware-Scan aus, mit --target, --action pass|delete|quarantine und --log.

Aktivierung und Check-in

Frisch installierte Agents sind inaktiv. Die Aktivierung gegen Vision One / SWP erfolgt mit einem Kommando, das die Management-Konsole unter Support > Deployment Scripts fertig generiert:

/opt/ds_agent/dsa_control -a dsm://agents.workload.<region>.cloudone.trendmicro.com:443/ \
    "tenantID:<id>" "token:<token>"

Nach der Aktivierung taucht der Host mit Status Online in der Konsole auf. Lokal lässt sich dasselbe mit dsa_query -c "GetAgentStatus" prüfen. Einen manuellen Check-in, etwa nach einem Policy-Update in der Konsole, löst dsa_control -m aus.

Netzwerk (Ports und URLs)

Für SWP / Vision One muss der Host ausgehend TCP/443 zur regionalen Manager-URL erreichen. Zusätzlich sind DNS und NTP Pflicht. Die relevanten Hostname-Muster:

• agents.workload.<region>.cloudone.trendmicro.com (Aktivierung)

• agent-comm.workload.<region>.cloudone.trendmicro.com (Heartbeats, Policy-Download)

Verfügbare Regionen sind au-1, ca-1, de-1, gb-1, in-1, jp-1, sg-1 und us-1. Manager-initiierte Rückwärtskommunikation (TCP/4118) ist optional und nur nötig, wenn die Policy das erzwingt; für reine Heartbeat-Setups reicht 443 outbound.

SELinux

Trend Micro verlangt, dass der Agent in einer unconfined domain läuft. Eigene SELinux-Policies, Booleans oder File-Contexts liefert das Paket nicht aus; wer SELinux auf enforcing betreibt und spezifische Denials sieht, generiert sich das Policy-Modul aus dem Audit-Log:

grep ds_agent /var/log/audit/audit* | audit2allow -M ds_agent
semodule --install=ds_agent.pp

Die offizielle Doku weist diesen Workflow explizit aus. Andere Absicherungen (Application Whitelisting, Custom Confinement) brechen den Agent erfahrungsgemäss.

Kernel-Module

Die Feature-Module Anti-Malware, Web Reputation, Firewall, Integrity Monitoring, Intrusion Prevention und Application Control laden Kernel-Module nach. Trend Micro signiert diese Module für Secure Boot über den eigenen MOK-Prozess; ohne enrollten Key bleibt der betroffene Feature-Teil inaktiv. Eine kanonische Liste der Modulnamen dokumentiert Trend Micro in den Produkt-Docs nicht.

Deinstallation

Vor dem Entfernen die Self-Protection abschalten, sonst sperrt der Agent seine eigene Deinstallation:

/opt/ds_agent/dsa_control -s 0
rpm --erase ds_agent

rpm --erase lässt Reste unter /var/opt/ds_agent/ stehen (State-DB, Diagnose-Bundles). Wer den Host vollständig bereinigen will, räumt dieses Verzeichnis nach der RPM-Deinstallation manuell ab. Eine offizielle Aussage von Trend Micro zu den Resten gibt es nicht; der Pfad ist aber aus den Diagnose-Dokumenten bekannt und mit rpm --query --list ds_agent bzw. nach dem erase per find /var/opt/ds_agent nachvollziehbar.