8 Häufig gestellte Fragen¶

8.1 Welche Firewall-Zugriffsregeln sind für die Kommunikation zwischen dem Greenbone Scan Cluster (GSC) und dem VPN-Gateway erforderlich?¶

Das Gateway nutzt die folgenden ausgehenden Verbindungen:

443/TCP ausgehend zum GSC (45.135.106.140)
443/TCP ausgehend zum Greenbone Cloud Service (217.72.202.36)
443/TCP ausgehend zum Updatedienst (gpublic.azurecr.io)

Wenn ein externer DNS-Server – wie 8.8.8.8 von Google – konfiguriert ist, müssen die Ports 53/UDP und 53/TCP auf die Whitelist gesetzt werden.

8.2 Welche Firewall-Zugriffsregeln sind für die Kommunikation zwischen dem Greenbone Scan Cluster (GSC) und externen Zielen erforderlich?¶

Der Greenbone Scan Cluster (GSC) verwendet den IP-Adressbereich 45.135.106.0/25 für den Scanverkehr zu externen Zielen. Die verwendeten Ports werden entsprechend der beim Erstellen des Ziels konfigurierten Portliste ausgewählt (siehe Kapitel 6.2.1 und 6.9).

8.3 Welche Technologie wird für die VPN-Verbindung genutzt?¶

Für die VPN-Verbindung zum Greenbone Scan Cluster (GSC) (45.135.106.140) wird ein SSH-Schicht-2-basiertes VPN mit 443/TCP genutzt.

8.4 Was muss getan werden, falls MAC-NAT nicht funktioniert?¶

Mit der Gateway-Version 1.5.1 oder höher treten in der Regel keine Probleme auf.

Falls MAC-NAT nicht funktioniert, muss die Checkbox MAC-NAT nutzen beim Erstellen eines Gateways deaktiviert und die folgenden Einstellungen in VMware ESXi oder Oracle VirtualBox vorgenommen werden:

In VMWare ESXi:

Separate Portgruppe für das Gateway erstellen und das Gateway damit verbinden.
Einstellungen Promiscuous-Modus und Gefälschte Übertragungen für die Portgruppe auf Akzeptieren setzen.

In Oracle VirtualBox:

In den Netzwerk-Einstellungen Erweitert öffnen und die Einstellung Promiscuous Mode auf erlauben für alle VMs und den Host setzen.

8.5 Was passiert mit dem Nutzeraccount, wenn das Abonnement endet?¶

Wenn das Abonnement endet, kann der Nutzer sich weiterhin einloggen und alle fertiggestellten Berichte ansehen. Das Starten neuer Scans ist nicht mehr möglich.

Falls der Account nicht mehr genutzt wird, wird er nach einiger Zeit gelöscht. Der Nutzer wird zuvor darüber informiert.

8.6 Warum ist der Scanprozess so langsam?¶

Die Geschwindigkeit eines Scans hängt von vielen Faktoren ab. Ein möglicher Grund ist das zeitintensive Scannen von ungenutzten IP-Adressen.

Um dies zu vermeiden, sollte vor dem eigentlichen Scan ein „Discovery“-Scan ausgeführt werden. Dieser Scan erkennt für jede IP-Adresse, ob diese aktiv ist oder nicht. Inaktive IP-Adressen werden während des eigentlichen Scans nicht untersucht. Firewalls und andere Systeme können solch eine erfolgreiche Feststellung verhindern.

Zusätzlich wird die Dauer eines Scans hauptsächlich durch die Netzwerkkonfiguration und die Anzahl der zu prüfenden Ports bestimmt. Der Dienst hinter jedem Port, der abgefragt wird, reagiert mit mindestens einem Log-Eintrag. Andere Kriterien sind die Abwehrmechanismen, die durch vollständige Portscans ausgelöst werden und Gegenmaßnahmen oder Benachrichtigungen einleiten. Selbst bei gewöhnlichen Scans können Firewalls simulieren, dass alle 65535 Ports aktiv sind und somit den Scan mit sogenannten Time-outs ausbremsen. In Situationen, in denen Portdrosselung auftritt, kann das Scannen aller TCP- und UDP-Ports eines einzelnen Systems bis zu 24 Stunden oder länger dauern. Da einige Gegenmaßnahmen die Dauer eines Scans erhöhen können, kann eine Drosselung vermieden werden, indem die Konfiguration des Abwehrsystems geändert wird. Bei Verdachtsfällen einer Kompromittierung oder höchsten Sicherheitsansprüchen ist ein vollständiger Scan unerlässlich.

8.7 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.

8.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).

8.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 VTs, die Schaden am Hostsystem anrichten könnten, durch die Scan-Konfiguration aktiviert sind. Andernfalls kann das Zielsystem betroffen sein.