Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Häufige Probleme beheben

Unterstützt in:

Google SecOps SOAR

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.

Remote-Connector-Fehler

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

Prüfen Sie, ob eine Integrationsinstanz erfolgreich auf dem Agent installiert wurde.
Prüfen Sie die Agentenprotokolle auf Fehlerebene, um Fehler im Verbindungsprozess zu finden.
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, führen Sie die folgenden Schritte aus:

Prüfen Sie, ob auf der Hostumgebung kein Legacy-Betriebssystem ausgeführt wird, da dieses möglicherweise keine modernen Systemaufruf-Hooks hat.
Hosten Sie die Agent-Umgebung auf einer Enterprise-Linux-Distribution mit der neuesten offiziellen Version neu.
Prüfen Sie, ob der Host eine unterstützte Plattform ist: Debian 12 (offizielle Basis), RHEL 8.7:
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".

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 Befehl zum Ausführen des Agents ausführen.

Fehler bei der Bereitstellung des Docker-Agenten

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

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
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
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
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:

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 bei der Internetverbindung des Hosts.
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 wieder zu starten:
  
  docker start
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.

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:

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
Führen Sie den folgenden Befehl aus, um den Netzwerkdienst neu zu starten:
systemctl restart network
Führen Sie den folgenden Befehl aus, um den Docker-Dienst neu zu starten:
sudo systemctl restart docker
Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Container ausgeführt wird:
docker ps
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
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
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 Agenten 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:

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.
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.
Wenn Sie keine gezielte SELinux-Ausnahme konfigurieren können, können Sie SELinux alternativ dauerhaft über Neustarts hinweg in den Permissive-Modus versetzen, indem Sie SELINUX=permissive in /etc/selinux/config auf dem Host festlegen.

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