Die folgenden Abschnitte behandeln häufige Fehlerfälle im Zusammenhang mit dem Netzwerk Check und dem Gateway.
Ausgangslage:
Die Gateway-VM wurde konfiguriert und wird als verbunden angezeigt. Falls gewünscht, kann das Standard-CLI-Passwort des Gateways geändert werden. Wird diese Option im Menü ausgewählt, werden das alte und das neue Passwort abgefragt.
Problemfall:
Das Passwort kann nicht erfolgreich geändert werden. Er erschient die Fehlermeldung “Could not update password”.
Mögliche Ursache:
Die Ursache für diese Fehlermeldung ist in den meisten Fällen, dass das neue Passwort nicht den erforderlichen Passwortrichtlinien entspricht. Dies tritt häufig auf, wenn ein zu einfaches Passwort gewählt wurde. Um diesen Fehler zu vermeiden, empfehlen wir, ein mindestens 10 Zeichen langes Passwort mit Sonderzeichen zu verwenden.
Ausgangslage:
Das Gateway wird als verbunden angezeigt und der Scan kann gestartet werden.
Problemfall:
Der Netzwerk Check bricht nach dem Start ab. In manchen Fällen wird das Gateway anschließend als als offline angezeigt. Erst nach einem Neustart wird es wieder als verbunden angezeigt.
Mögliche Ursache #1:
Fehlende Firewall-Freigaben. Das Gateway muss externe Adressen erreichen können. Damit der Netzwerk Check korrekt funktioniert, sind folgende Freischaltungen notwendig:
Sowohl die Scanner-IP-Adresse als auch die IP-Adresse des Gateways müssen die Zielgeräte im internen Netzwerk vollständig erreichen können. Es müssen alle Ports dieser Geräte erreichbar sein.
Außerdem müssen die IP-Adresse des Gateways und die IP-Adresse des Scanners folgende externe Adressen erreichen können:
443/tcp outgoing zu 45.135.106.140
443/tcp outgoing zu https://gateway.lywand.com (217.72.202.36)
443/tcp outgoing zu https://gpublic.azurecr.io (Update-Service)
Mögliche Ursache #2:
Vertauschte IP-Adressen. Dieser Fehlerfall kann auch auftreten, wenn bei der Konfiguration der Gateway-VM versehentlich die IP-Adresse des Scanners statt der IP-Adresse des Gateways angegeben wird. (Vgl. die roten Pfeile in den nachfolgenden Screenshots.)
Ausgangslage:
Der Scan konnte gestartet werden und wurde abgeschlossen. In der Infrastrukturtabelle der internen Netzwerkziele ist in der Spalte “Zuletzt überprüft” ein Zeitpunkt ersichtlich.
Problemfall:
Der Scan hat keine Ergebnisse geliefert. In den Check Insights sind die gescannten Netzwerkgeräte aufgelistet, es werden aber keine Schwachstellen dazu angezeigt.
Mögliche Ursache #1:
Dieser Fehlerfall deutet darauf hin, dass die Ziele im Prüfumfang durch den Scanner nicht erreichbar sind. Folglich sollten die notwendigen Firewall-Freigaben überprüft werden:
Die IP-Adresse des Scanners muss die zu überprüfenden Geräte im internen Netzwerk vollständig erreichen können. Es müssen alle Ports dieser Geräte erreicht werden können.
Mögliche Ursache #2:
Die IP-Adresse des Scanners wird von einem anderen System im selben Netzwerk verwendet. Bei der Konfiguration muss dem Scanner unbedingt eine im Netzwerk noch freie IP-Adresse zugewiesen werden.
Ausgangslage & Problemfall:
Scans werden prinzipiell abgeschlossen und es werden Schwachstellen gefunden. Die Anzahl der gefundenen Schwachstellen schwankt aber zwischen den durchgeführten Netzwerk Checks (ohne dass Schwachstellen geschlossen wurden).
Mögliche Ursache #1:
Die IP-Adresse des Scanners wird von einem anderen System im selben Netzwerk verwendet. Bei der Konfiguration muss dem Scanner unbedingt eine im Netzwerk noch freie IP-Adresse zugewiesen werden.
Mögliche Ursache #2:
Der Scanner wird während des Checks von einer Web Application Firewall (WAF) oder Ähnlichem blockiert. Dies kann auch nur kurzzeitig der Fall sein und muss nicht alle Ziele betreffen. Dadurch können Timing-Probleme auftreten, die dann die Scan-Ergebnisse beeinträchtigen.
Ausgangslage:
Der Scan konnte gestartet werden und ist “in progress”.
Problemfall:
Je nach Prüfumfang und Auslastung des Scan-Clusters kann es mehrere Stunden dauern, bis ein Scan abgeschlossen ist. Wenn der Netzwerk Check jedoch über einen längeren Zeitraum nicht abgeschlossen wird oder beim gleichen Prozentsatz des Fortschritts stehen bleibt, kann dies auf ein Problem hindeuten.
Mögliche Ursache #1:
Wenn der Netzwerk Check überdurchschnittlich lange dauert, kann dies auf eine Überlastung des Greenbone Scan-Clusters hindeuten. In diesem Fall verlängert sich die Dauer des Scans. Der Scan wird jedoch fertig durchgeführt, sobald das Lastproblem behoben ist. Ein Abbruch des Scans ist in diesem Fall unwahrscheinlich, kann aber nicht ausgeschlossen werden.
Mögliche Ursache #2:
Dieser Fehlerfall kann auch darauf hindeuten, dass die Ziele im Prüfumfang durch den Scanner nicht erreichbar sind. Folglich sollten die notwendigen Firewall-Freigaben überprüft werden:
Die IP-Adresse des Scanners muss die zu überprüfenden Geräte im internen Netzwerk vollständig erreichen können. Es müssen alle Ports dieser Geräte erreicht werden können.
