Häufige Probleme beheben

Unterstützt in:

Dieses Dokument enthält eine Sammlung von Tipps und Verfahren, mit denen Sie häufige Probleme bei der Bereitstellung und dem Betrieb des Google Security Operations Remote Agent diagnostizieren und beheben können.

Problem mit nicht übereinstimmenden Schlüsseln

Dieses Problem tritt auf, wenn die privaten Schlüssel in Google Security Operations und dem Remote-Agent nicht übereinstimmen. Prüfen Sie, ob der Schlüssel in den Agent-Ressourcen mit dem Schlüssel in der Siemplify-agent_db übereinstimmt.

Fehler beim Remote-Connector

Wenn ein Remote-Connector fehlschlägt, gehen Sie so vor:

  1. Prüfen Sie, ob eine Integrationsinstanz erfolgreich auf dem Agent installiert wurde.
  2. Prüfen Sie die Agentenprotokolle auf Fehlerebene, um Fehler im Verbindungsprozess zu finden.
  3. Testen Sie dieselbe Connector-Konfiguration lokal und prüfen Sie, ob Fehler auftreten.

Installationsfehler: Nicht unterstütztes Host-Betriebssystem oder EOL-Inkompatibilitäten

Wenn Neuinstallationen oder automatische Upgrades aufgrund von glibc-Tracking-Fehlern und Systemaufruf-Blockierungen fehlschlagen, gehen Sie so vor:

  1. Prüfen Sie, ob auf der Hostumgebung ein Legacy-Betriebssystem ausgeführt wird, dem möglicherweise moderne Systemaufruf-Hooks fehlen.
  2. Hosten Sie die Agent-Umgebung auf einer Enterprise-Linux-Distribution mit der neuesten offiziellen Version neu.
  3. Prüfen Sie bei manuellen Bereitstellungen des Installationsprogramms, ob auf dem Host ein unterstütztes Betriebssystem wie Debian 12 oder Red Hat Enterprise Linux (RHEL) 8.7 ausgeführt wird:

    Prüfen Sie /etc/os-release: Führen Sie den folgenden Befehl aus und suchen Sie nach NAME= und VERSION_ID=:

    cat /etc/os-release
    • Für Debian 12: Suchen Sie nach NAME="Debian GNU/Linux" und VERSION_ID="12".
    • Für RHEL 8.7: Suchen Sie nach NAME="Red Hat Enterprise Linux" und VERSION_ID="8.7".

    Wenn auf Ihrem Host RHEL 9 oder 10 (oder höher) ausgeführt wird, stellen Sie den Remote-Agenten mit einer unterstützten Container-Engine (Podman oder Docker) und nicht mit dem manuellen Installationsprogramm bereit. Vordefinierte Container-Images für Remote-Agent-Versionen nach 2.5.0.4 basieren auf Debian 12, wodurch auch binäre Inkompatibilitäten von Python-Wheels (.whl) (z. B. ModuleNotFoundError für TIPCommon oder SiemplifyAddressProvider) auf CentOS 7-Agents behoben werden. Weitere Informationen finden Sie unter Unterstützte Betriebssysteme.

Bei der Container-Einrichtung wird die vorherige Betriebsebene anstelle des „neuesten“ Builds abgerufen

Wenn beim erneuten Ausführen von Container-Einrichtungsbefehlen versehentlich eine vorherige Betriebsebene anstelle des neu veröffentlichten Software-Builds abgerufen wird, führen Sie die folgenden Befehle aus, um das neueste Image explizit abzurufen:

  • Für Docker:

    docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

  • Für Podman:

    podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

Damit die Bereitstellung mit der neuesten Softwareversion ausgeführt wird, sollten Sie immer das neueste Image abrufen, bevor Sie den Agent-Container ausführen. Wenn Sie beim Abrufen von docker.io aufgrund von Ratenbegrenzungen zur Eingabe von Anmeldedaten aufgefordert werden, rufen Sie das Image vom öffentlichen Artifact Registry-Endpunkt (us-docker.pkg.dev/siem-ar-public/images/agent:latest) ab. Informationen zu den erforderlichen Domains auf der Firewall-Zulassungsliste finden Sie unter Netzwerk- und Firewall-Anforderungen.

Fehler bei der Bereitstellung des Docker-Agents

Wenn die Docker-Bereitstellung fehlschlägt, gehen Sie so vor:

  1. Entfernen Sie den Docker-Container:

    1. Führen Sie den folgenden Befehl aus, um die ausgeführten Container aufzulisten:

      docker ps 

    2. Führen Sie den folgenden Befehl aus, um die fehlerhaften Container zu entfernen:

      docker rm -f container_id_or_name
  2. Bilder entfernen:

    1. Führen Sie den folgenden Befehl aus, um die Images aufzulisten:

      docker images 

    2. Führen Sie den folgenden Befehl aus, um das Image zu entfernen:

      docker rmi image_id_or_name
  3. Volumes entfernen:

    1. Führen Sie den folgenden Befehl aus, um die Volumes aufzulisten:

      docker volume ls

    2. Führen Sie den folgenden Befehl aus, um die Volumes zu entfernen:

      docker volume rm volume_name
  4. Stellen Sie den Agenten noch einmal bereit. Weitere Informationen finden Sie unter Agent mit Docker erstellen.

KI-Agent bleibt im Status „Warten auf KI-Agent“ hängen

Wenn der Agent erfolgreich bereitgestellt wurde, der Status aber weiterhin „Warten auf Agent“ lautet, führen Sie die folgenden Schritte aus, um das Problem zu beheben:

  1. Hostverbindung prüfen: Testen Sie die Internetverbindung des Agent-Hostcomputers (z. B. curl www.google.com oder ping 8.8.8.8). Wenn dies fehlschlägt, liegt das Problem an der Internetverbindung des Hosts.

  2. Containerverbindung prüfen: Wenn der Hosttest erfolgreich ist, rufen Sie die Container-Shell mit docker exec -it container_ID bash auf und prüfen Sie die Verbindung noch einmal. Wenn der Container keine Verbindung hat, starten Sie den Docker-Dienst auf dem Hostcomputer neu (service docker restart).

    1. Führen Sie dazu diesen Befehl aus:

      docker exec -it bash

    2. Prüfen Sie die Verbindung noch einmal wie zuvor.
    3. Wenn keine Verbindung besteht, führen Sie den folgenden Befehl aus, um den Docker-Dienst auf dem Hostcomputer (nicht im Container) neu zu starten:

      service docker restart

    4. Führen Sie den folgenden Befehl aus, um den Container noch einmal zu starten:

      docker start

  3. Containerlogs auf Fehler prüfen

    Wenn der vorherige Schritt nicht geholfen hat und der Agent-Status nach dem Aktualisieren der Seite Remote-Agent in Google SecOps immer noch „Warten auf Agent“ lautet, melden Sie sich wieder im Container an und rufen Sie die Logs ab.

    1. Suchen Sie die Logs im Verzeichnis /var/log/SiemplifyAgent/.
    2. Suchen Sie in den Logdateien nach Fehlern, um die Ursache zu ermitteln.

  4. Prüfen Sie, ob Ihre Firewall ausgehenden HTTPS-Traffic über TCP-Port 443 zu Ihrem Publisher, der standortbezogenen Chronicle API und den Authentifizierungsendpunkten von Google Cloud zulässt. Prüfen Sie außerdem, ob Proxys auf Anwendungsebene oder DPI-Firewalls (Deep Packet Inspection) die SSL/TLS-Prüfung für den Remote-Agent-Host umgehen. Eine Liste der erforderlichen Domains finden Sie unter Netzwerk- und Firewallanforderungen.

DNS-Netzwerkprobleme

Wenn im Container DNS-Auflösungsfehler oder Probleme mit der Netzwerkverbindung auftreten, fügen Sie --network host zum Befehl docker run hinzu. Im Hostnetzwerkmodus kann der Container den Netzwerkstack und die DNS-Konfiguration des Hostcomputers direkt nutzen.

Docker-Image kann nicht geladen werden (IPv4-Weiterleitung ist deaktiviert)

Wenn Sie in der Befehlszeile einen Fehler sehen, wenn Sie versuchen, ein Google SecOps-Docker-Image (System) oder einen Agent zu laden, ist die IP4-Weiterleitung möglicherweise deaktiviert. So aktivieren Sie die Funktion und starten den Agenten neu:

  1. Fügen Sie der Datei /etc/sysctl.conf die folgende Zeile hinzu:

    net.ipv4.ip_forward=1 Beachten Sie, dass Sie einen Dateieditor verwenden müssen (z. B. nano): yum install nano -y

  2. Führen Sie den folgenden Befehl aus, um den Netzwerkdienst neu zu starten:

    systemctl restart network

  3. Führen Sie den folgenden Befehl aus, um den Docker-Dienst neu zu starten:

    sudo systemctl restart docker

  4. Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Container ausgeführt wird:

    docker ps

  5. Wenn der Container nicht ausgeführt wird, führen Sie den folgenden Befehl aus, um alle Container (einschließlich der beendeten) aufzulisten:

    docker ps -a

  6. Wenn der Container aufgeführt, aber beendet ist, führen Sie den folgenden Befehl aus, um ihn zu starten:

    docker start container_id_or_name
  7. Wenn der Agent oder das System nach dem Neustart von Docker und dem Container immer noch nicht ausgeführt wird:

    1. Führen Sie den folgenden Befehl aus, um den Container zu beenden:

      docker stop container_id_or_name

    2. Führen Sie den folgenden Befehl aus, um den Container zu löschen:

      docker rm container_id_or_name

    3. Führen Sie den folgenden Befehl aus, um das Image zu löschen:

      docker rmi image_name
    4. Laden Sie das Bild noch einmal.

Fehler nach Herunterfahren oder Neustart des Agents

Führen Sie den folgenden Befehl aus, um den Start des Installer-Agents zu erzwingen:
systemctl start supervisord

Führen Sie den folgenden Befehl aus, um den Start des Docker-Agents zu erzwingen:
docker start

Remote-Agent-Aufgaben schlagen in gehärteten Umgebungen fehl

Wenn Sie einen Remote-Agent auf einem gehärteten Linux-Host wie RHEL 8 bereitstellen, können Agent-Aufgaben (einschließlich Speichern oder Aktualisieren einer Integration oder Ausführen von Connectors und Aktionen) fehlschlagen oder in der Benutzeroberfläche ein Zeitüberschreitungsfehler auftreten, während der Agent-Status Live bleibt. Dieses Problem tritt auf, wenn die Sicherheitserzwingung des Host-Betriebssystems, z. B. SELinux im Enforcing-Modus, AppArmor oder Endpoint-Sicherheitssoftware, Betriebssystembefehle blockiert, die vom Agent im Container ausgeführt werden.

Um dieses Problem zu beheben, muss der Remote-Agent von den Host-Sicherheitsrichtlinien ausgenommen werden, die seine Betriebssystembefehle blockieren. Gehen Sie so vor, um das Problem zu diagnostizieren und zu beheben:

  1. Prüfen Sie, ob sich SELinux auf dem Hostcomputer im Enforcing-Modus befindet:

    getenforce
sestatus

    Führen Sie den folgenden Befehl aus, um /var/log/audit/audit.log auf kürzlich blockierte Befehle oder abgelehnte Vorgänge zu prüfen, ohne die gesamte Logdatei zurückzugeben:

    sudo grep -i "denied" /var/log/audit/audit.log | tail -n 50

    Sie können auch die Logs zur Endpunktsicherheit auf dem Host auf blockierte Vorgänge im Zusammenhang mit den Agent-Containerprozessen prüfen.

  2. Nehmen Sie den Remote-Agent von der blockierenden Sicherheitsrichtlinie auf dem Host aus:

    • Bei containerisierten Bereitstellungen (Docker oder Podman) müssen Sie den gesamten Remote-Agent-Container beim ersten Start ausnehmen. Fügen Sie dazu --security-opt label=disable (für SELinux) oder --security-opt apparmor=unconfined (für AppArmor) zu Ihrem docker run- oder podman run-Befehl hinzu.
    • Konfigurieren Sie benutzerdefinierte SELinux-Richtlinienregeln, AppArmor-Profile oder Ausnahmen für die Host-Endpunktsicherheit für die Remote-Agent-Verzeichnisse (/opt/SiemplifyAgent, /home/siemplify_agent/agent_source und /var/log/SiemplifyAgent) und ausführbaren Dateien (/usr/local/bin/python3.11, /usr/local/bin/pip3 und /usr/bin/supervisord), damit Betriebssystembefehle nicht blockiert werden.

  3. Wenn Sie keine gezielte SELinux-Ausnahme konfigurieren können, können Sie SELinux auch dauerhaft über Neustarts hinweg in den Permissive-Modus versetzen. Setzen Sie dazu SELINUX=permissive in /etc/selinux/config auf dem Host.

    Wenn Sie /etc/selinux/config nicht ändern können oder die Änderung sofort ohne Neustart anwenden müssen, führen Sie den folgenden Befehl aus, um SELinux vorübergehend in den Permissive-Modus zu versetzen:

    sudo setenforce 0

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten