20 Häufig gestellte Fragen¶
20.1 Warum ist der Scanprozess so langsam?¶
Die Geschwindigkeit eines Scans hängt von vielen Faktoren ab.
Es wurden mehrere Portscanner gleichzeitig aktiviert.
Falls eine individuelle Scan-Konfiguration genutzt wird, sollte nur ein einziger Portscanner in der VT-Familie Port scanners gewählt werden (siehe Kapitel 10.9.2). Der VT Ping Host kann trotzdem aktiviert sein.
Unbelegte IP-Adressen werden zeitintensiv gescannt.
Im ersten Schritt wird festgestellt, ob für jede IP-Adresse ein aktives System vorhanden ist oder nicht. Falls nicht, wird die IP-Adresse nicht gescannt. Firewalls und andere Systeme können solch eine erfolgreiche Feststellung verhindern. Der VT Ping Host (1.3.6.1.4.1.25623.1.0.100315) in der VT-Familie Port scanners bietet eine Feineinstellung der Feststellung.
Die zu scannenden Ports führten zu einer Portdrosselung oder es wurde UDP-Port-Scanning gewählt.
Weitere Informationen befinden sich in Kapitel 17.2.1.2 und 17.2.1.2.1.
20.2 Wodurch wird die Scankapazität beeinflusst?¶
Die Scankapazität – die scannbare Anzahl an IP-Adressen pro 24 Stunden – hängt vom Appliance-Modell ab (siehe Kapitel 3). Die angegebenen Werte für die geschätzte Scankapazität können jedoch nur als Richtwerte verstanden werden, da die Scankapazität von vielen Faktoren beeinflusst wird.
Die folgenden Faktoren beeinflussen die Scankapazität:
- Komplexität der verwendeten Scan-Konfiguration
In derselben Zeitspanne können viel mehr Discoveryscans als Schwachstellenscans ausgeführt werden. Weitere Informationen zu den Scan-Konfigurationen befinden sich in Kapitel 10.9.
- Verwendung der Appliance außerhalb ihrer Spezifikationen
Das Starten zu vieler Scans oder das gleichzeitige Scannen zu vieler Ziele kann zu Leistungsproblemen führen.
- Leistung der Netzwerk-Infrastruktur und des/der Zielsysteme(s)
Wenn die Systeme nur langsam auf Netzwerkanfragen reagieren, wird der Scanvorgang langsamer.
- Art des gescannten Zielsystems/der gescannten Zielsysteme
Die Art bestimmt, welche und wie viele Schwachstellentests während eines Scans ausgeführt werden. Mehr Schwachstellentests bedeuten in der Regel langsamere Scans.
Einige Scanszenarien erhöhen die Ressourcennutzung, was sich auf die Leistung auswirken kann, z. B. das Scannen von virtuellen Hosts (vHosts) oder das Scannen von Webservern mit aktiviertem CGI-Caching. Weitere Informationen zu den Konfigurationsoptionen für diese Szenarien befinden sich in Kapitel 10.9.
- Parallele Verwendung der Appliance während des Scannens
Wenn andere ressourcenintensive Vorgänge (z. B. Feed-Updates, Erstellung großer Berichte) laufen, stehen weniger Systemressourcen für Scans zur Verfügung.
- Verwendung von Sensoren
Die Verwendung von Sensoren kann die Anzahl der scannbaren IP-Adressen pro 24 Stunden erhöhen.
20.3 Warum wird ein Dienst/Produkt nicht gefunden?¶
Das Ziel wird nicht als online/erreichbar erkannt.
- Lösung(en):
Netzwerkeinrichtung/Routing zum Ziel korrigieren.
Die Kriterien/die Testkonfiguration, um das Ziel als erreichbar zu erkennen, aktualisieren (siehe Kapitel 10.2.1).
Sicherstellen, dass die Scan-Konfiguration die folgenden VTs aus der VT-Familie Port scanners enthält: * Nmap (NASL wrapper) (OID: 1.3.6.1.4.1.25623.1.0.14259) * Ping Host (OID: 1.3.6.1.4.1.25623.1.0.100315)
Alle Netzwerkgeräte (Firewall, IDS/IPS, WAF usw.) zwischen dem Scanner und dem Ziel sowie alle Sicherheitsmechanismen auf dem Ziel selbst überprüfen und entfernen. IP-Adresse des Scanners auf die Whitelist setzen.
Der Dienst/das Produkt läuft auf einem bestimmten Port, der nicht in der Portliste enthalten ist.
- Lösung(en):
Eine geeignete Portliste erstellen (siehe Kapitel 10.7). Dies ist besonders wichtig für UDP-Ports.
Es gibt einen Erkennungs-VT für einen Dienst/ein Produkt, aber der Dienst/das Produkt wird bei einem Scan nicht gefunden.
- Lösung(en):
Netzwerkeinrichtung/Routing zum Ziel korrigieren.
Die Kriterien/die Testkonfiguration, um das Ziel als erreichbar zu erkennen, aktualisieren (siehe Kapitel 10.2.1).
Alle Netzwerkgeräte (Firewall, IDS/IPS, WAF usw.) zwischen dem Scanner und dem Ziel sowie alle Sicherheitsmechanismen auf dem Ziel selbst überprüfen und entfernen. IP-Adresse des Scanners auf die Whitelist setzen.
Eine geeignete Portliste erstellen (siehe Kapitel 10.7). Dies ist besonders wichtig für UDP-Ports.
Wenn die oben genannten Lösungen nicht helfen, kann der Greenbone Enterprise Support kontaktiert werden. Dafür weitere Informationen über den Dienst/das Produkt (Produktname, konkret laufende Version usw.) bereitstellen.
Das Ziel ist nicht stabil/reagiert langsam während eines Scans.
- Lösung(en):
Gleichzeitig ausgeführte VTs reduzieren (siehe Kapitel 10.2.2).
Den Dienst/das Produkt auf eine neuere Version aktualisieren (z. B. um ausgelöste Bugs zu beheben).
Dem Ziel mehr Ressourcen (CPU, RAM usw.) zuweisen, um es bei Scans stabiler zu machen.
20.4 Warum wird eine Schwachstelle nicht gefunden?¶
Der betroffene Dienst/das betroffene Produkt wird überhaupt nicht erkannt.
- Lösung(en):
Siehe Kapitel 20.3.
Der Dienst/das Produkt wurde erkannt, aber die Erkennung einer Version war nicht möglich.
- Lösung(en):
Einen authentifizierten Scan durchführen (siehe Kapitel 10.3).
Wenn die oben genannten Lösungen nicht helfen, kann der Greenbone Enterprise Support kontaktiert werden. Dafür weitere Informationen über den Dienst/das Produkt (Produktname, konkret laufende Version usw.) bereitstellen.
Es gibt nur eine Versionsprüfung mit einer niedrigeren Qualität der Erkennung (QdE) und die Schwachstelle wird standardmäßig nicht angezeigt.
Falls ein authentifizierter Scan durchgeführt wurde, ist der Login fehlgeschlagen.
- Lösung(en):
Korrektheit der Anmeldedaten prüfen.
Verifizieren, dass der Nutzer nicht geblockt ist.
Verifizieren, dass sich der Benutzer auf dem Ziel anmelden darf.
Wenn die oben genannten Lösungen nicht helfen, kann der Greenbone Enterprise Support kontaktiert werden. Dafür weitere Informationen über den Dienst/das Produkt (Produktname, konkret laufende Version usw.) bereitstellen.
Der Dienst/das Produkt selbst stürzte ab oder reagierte nicht mehr während des Scans.
- Lösung(en):
Gleichzeitig ausgeführte VTs reduzieren (siehe Kapitel 10.2.2).
Den Dienst/das Produkt auf eine neuere Version aktualisieren (z. B. um ausgelöste Bugs zu beheben).
Dem Ziel mehr Ressourcen (CPU, RAM usw.) zuweisen, um es bei Scans stabiler zu machen.
Die Schwachstelle wurde erst vor Kurzem entdeckt und es existiert noch kein VT dafür.
- Lösung(en):
Den Greenbone Enterprise Support kontaktieren und einen neuen VT anfragen oder erfragen, ob ein VT bereits geplant ist.
Die spezifische Erkennung ist veraltet.
- Lösung(en):
Den Greenbone Enterprise Support kontaktieren.
20.5 Warum unterscheiden sich die Ergebnisse für dasselbe Ziel bei mehreren aufeinanderfolgenden Scans?¶
Die Ergebnisse aufeinanderfolgender Scans können aus folgenden Gründen voneinander abweichen:
Es gab einen Verbindungsverlust über unzuverlässige Netzwerkverbindungen (zwischen dem Scanner-Host und dem Ziel).
Die Netzwerkverbindung oder die Ausrüstung (zwischen dem Scanner-Host und dem Ziel) war überlastet.
Ein überlasteter Zielhost und/oder -dienst hat aufgehört zu reagieren.
„Fragile“ Protokolle (z. B. das Remote Desktop Protocol) reagieren nicht immer wie erwartet.
Eine frühere Prüf-/Angriffsanfrage hat dazu geführt, dass der Dienst für eine kurze Zeit nicht reagiert hat.
Obwohl der Scanner versucht, das Auftreten solcher Situationen durch interne Wiederholungsroutinen zu reduzieren, können sie nicht vollständig ausgeschlossen werden.
20.6 Warum ist es nicht möglich, Scan-Konfigurationen, Portlisten, Compliance-Richtlinien oder Berichtformate zu bearbeiten?¶
Scan-Konfigurationen, Portlisten, Compliance-Richtlinien und Berichtformate von Greenbone (im Folgenden als „Objekte“ bezeichnet) werden über den Feed verteilt. Diese Objekte müssen einem Nutzer, dem Feed Import Owner, gehören. Die Objekte werden während eines Feed-Updates heruntergeladen und aktualisiert, falls ein Feed Import Owner festgelegt wurde.
Die Objekte können nicht bearbeitet werden. Dies ist beabsichtigt, damit sichergestellt ist, dass die Objekte wie von Greenbone beabsichtigt funktionieren.
20.7 Warum ist es nicht möglich, Scan-Konfigurationen, Portlisten, Compliance-Richtlinien oder Berichtformate zu löschen?¶
Scan-Konfigurationen, Portlisten, Compliance-Richtlinien und Berichtformate von Greenbone (im Folgenden als „Objekte“ bezeichnet) werden über den Feed verteilt. Diese Objekte müssen einem Nutzer, dem Feed Import Owner, gehören. Die Objekte werden während eines Feed-Updates heruntergeladen und aktualisiert, falls ein Feed Import Owner festgelegt wurde.
Nur der Feed Import Owner, ein Super-Administrator oder Nutzer, die entsprechende Berechtigungen erhalten haben, können Objekte löschen.
Wenn die Objekte gelöscht werden, werden sie während des nächsten Feed-Updates erneut heruntergeladen. Falls keine Objekte heruntergeladen werden sollen, darf kein Feed Import Owner festgelegt sein.
20.8 Warum erscheint ein VNC-Dialog auf dem gescannten Zielsystem?¶
Beim Prüfen des Ports 5900 oder beim Konfigurieren eines VNC-Ports, erscheint ein Fenster zum Erlauben der Verbindung auf dem gescannten System. Dies wurde für UltraVNC Version 1.0.2 beobachtet.
Lösung: Port 5900 oder andere konfigurierte VNC-Ports von der Zielspezifikation ausschließen. Alternativ könnte ein Upgrade auf eine neuere Version von UltraVNC hilfreich sein (UltraVNC 1.0.9.6.1 nutzt lediglich Sprechblasen zum Informieren von Benutzern).
20.9 Warum löst der Scan Alarme bei anderen Sicherheitstools aus?¶
Bei vielen Schwachstellenprüfungen wird das Verhalten eines echten Angriffs simuliert. Zwar findet kein tatsächlicher Angriff statt, aber einige Sicherheitstools könnten einen Alarm ausgeben.
Ein bekanntes Beispiel ist:
Symantec meldet einen Angriff bezüglich CVE-2009-3103, falls der VT Microsoft Windows SMB2 ‚_Smb2ValidateProviderCallback()‘ Remote Code Execution Vulnerability (1.3.6.1.4.1.25623.1.0.100283) ausgeführt wird. Dieser VT wird nur ausgeführt, falls der Radiobutton Nein für safe_checks in den Scanner-Vorgaben gewählt wird (siehe Abb. 20.1). Andernfalls kann das Zielsystem betroffen sein.
Abb. 20.1 Deaktivieren der Scanner-Vorgabe safe_checks¶
20.10 Wie kann ein Factory-Reset auf der Appliance durchgeführt werden?¶
Ein Factory-Reset kann durchgeführt werden, um Benutzerdaten sicher von der Appliance zu entfernen.
Bemerkung
Der Greenbone Enterprise Support kann kontaktiert werden, um detaillierte Informationen zum Factory-Reset zu erhalten.
20.11 Warum funktionieren nach einem Factory-Reset weder Feed-Update noch GOS-Upgrade?¶
Der Factory-Reset löscht das gesamte System, einschließlich des Subskription-Schlüssels für den Greenbone Enterprise Feed. Der Subskription-Schlüssel ist für Feed-Updates und GOS-Upgrades zwingend erforderlich.
Den Subskription-Schlüssel reaktivieren:
Ein Backup-Schlüssel wird mit jeder Appliance geliefert (siehe Kapitel 7.1.1). Dieser Schlüssel kann genutzt werden, um die Appliance zu reaktivieren. Die Aktivierung ist im Setup-Guide des entsprechenden Appliance-Modells beschrieben (siehe Kapitel 5).
Das System auf die aktuelle Version aktualisieren:
Abhängig von der GOS-Version muss der entsprechende Upgradevorgang durchgeführt werden.
20.12 Wie kann ein älteres Backup oder Beaming-Image wiederhergestellt werden?¶
Ausschließlich Backups und Beaming-Images, die mit der momentan genutzten GOS-Version oder der Vorgängerversion erstellt wurden, können wiederhergestellt werden. Für GOS 22.04 können nur Backups und Beaming-Images aus GOS 21.04 oder GOS 22.04 importiert werden. Falls ein älteres Backup oder Beaming-Image importiert werden soll, z. B. aus GOS 6 oder GOS 20.08, muss eine Appliance mit der passenden GOS-Version genutzt werden.
Backups und Beaming-Images aus GOS-Versionen, die neuer sind als die momentan genutzte GOS-Version, werden ebenfalls nicht unterstützt. Falls ein neueres Backup oder Beaming-Image importiert werden soll, muss eine Appliance mit der passenden GOS-Version genutzt werden.
Falls Fragen auftreten, kann der Greenbone Enterprise Support kontaktiert werden.
20.13 Was kann getan werden, falls das GOS-Administrationsmenü nicht korrekt in PuTTY dargestellt wird?¶
Window > Translation im linken Panel wählen, um die Einstellungen in PuTTY zu prüfen. UTF-8 muss in der Drop-down-Liste Remote character set gewählt werden (siehe Abb. 20.2).
Abb. 20.2 Auswahl des Remotezeichensatzes¶
20.14 Wie kann der GMP-Status ohne Anmeldedaten geprüft werden?¶
Eine SSH-Verbindung zur Appliance mithilfe der Kommandozeile unter Nutzung des GMP-Benutzers aufbauen:
ssh gmp@<appliance>
<appliance> durch die IP-Adresse oder den DNS-Namen der Appliance ersetzen.
Bemerkung
Es wird keine Eingabeaufforderung angezeigt, aber der Befehl kann trotzdem eingegeben werden.
<get_version/>eingeben.→ Falls GMP aktiviert ist, sollte die Ausgabe wie folgt aussehen:
<get_version_response status="200" status_text="OK"><version>8.0</version></get_version_response>.
20.15 Was ist zu tun, wenn der Self-Check „RAID Array degraded“ anzeigt?¶
Die Appliance-Modelle Greenbone Enterprise 6500/6400/5400/5300 verwenden RAID (Redundant Array of Independent Disks) 6 als Software-RAID. RAID ist eine Technologie zur Datenspeichervirtualisierung, bei der mehrere Festplattenkomponenten zum Zwecke der Datenredundanz zu einer oder mehreren logischen Einheiten zusammengefasst werden. Für RAID 6 sind mindestens 4 Festplatten erforderlich, damit das RAID und damit die Datenredundanz funktioniert. Die Appliance selbst funktioniert noch, wenn bis zu 2 Festplatten ausfallen.
Falls eine oder mehrere Festplatte(n) ausfallen, zeigt GOS die Self-Check-Warnungen RAID Array degraded mit dem Hinweis Replace the failed disk und Check for system integrity status mit dem Hinweis The system integrity may be endangered. Please contact the support. an. Die Integritätsprüfung schlägt aufgrund der ausgefallenen Festplatte(n) fehl.
Ausgefallene Festplatten müssen ersetzt und das RAID muss repariert werden. Der Greenbone Enterprise Support bietet hierzu Unterstützung an.