nmap TCP-Connect-Scan

Nachdem ich im letzten Beitrag über den SYN-Scan geschrieben habe, folgt heute ein kurzer Beitrag über einen weiteren Scan-Typ. Der SYN-Scan wurde auch als halboffener Scan beschrieben, da er den Three-Way-Handshake nicht vervollständigt und somit keinerlei Kommunikation zustande kommen kann. Dem entgegen steht der TCP-Connect-Scan.

Wie der Name bereits sagt, wird hierbei eine komplette TCP-Sitzung aufgebaut und die Verbindung anschließen vom Client beendet.

Zum Aufbau der Verbindung müssen entsprechend mehr Pakete gesendet und vom Server verarbeitet werden. Gleichzeitig besteht somit auch eine größere Chance, dass Log-Systeme diesen Scan erkennen und dies protokollieren. Auch ist, bei gleichem Ergebnis, die Scan-Dauer höher. Dieser Scan-Typ ist somit nicht ganz so „geräuschlos“ wie der SYN-Scan. Anders als dieser benötigt der TCP-Connect-Scan jedoch keine administrativen Berechtigungen, was auf manchen Systemen von Vorteil sein kann.

#Syntax für einen TCP-Connect-Scan
nmap -sT 192.168.0.119

Im Wireshark stellt sich der TCP-Connect-Scan folgendermaßen darf. Der Übersichtlichkeit halber, habe ich hier auf den offenen Port 443 gefilter.

Zu erkennen ist der Three-Way-Handshake und ein anschließender Reset der Verbindung durch den Client. Auch dem TCP-Connect-Scan geht eine ICMP-Host-Discovery voraus, sofern diese nicht durch einen Parameter deaktiviert wurde.
Falls das System nicht auf ICMP-Anfragen reagiert, kann man nmap mitteilen, dass man den Host als „online“ behandeln möchte. In diesem Fall versucht nmap keine Host-Erkennung und fängt direkt an das Ziel zu scannen.

#Syntax für einen Scan ohne Host-Erkennung
nmap -Pn 192.168.0.119

Time-to-Live bei verschiedenen Betriebssystemen

Anhand der Time-to-Live (TTL) kann man in manchen Fällen auf das Zielbetriebssystem schließen. Hintergrund ist, dass verschiedenen Betriebssysteme verschiedene Standardwerte für die TTL haben. Da die TTL bei einem Ping mit zurückgemeldet werden muss, kann man so die ein oder andere Information über das Zielsystem erhalten.

Ohne viele Geschreibe, hier die „Ergebnisse“ aus dem Homelab

Schon anhand dieses einfachen Beispiels ist das Verhalten gut zu erkennen. Natürlich ist dieses nicht in Stein gemeißelt. Die Werte können verändert werden und können sich auch, je nach Betriebssystemversion, unterscheiden. Es ist eher als kleine Hilfestellung gedacht, um mit einfachen Mitteln einen unbekannten Host im eigenen Netzwerk grob zu identifizieren. Der ein oder andere Kollege wird über diesen „Kniff“ auch staunen.

Nachfolgend noch eine kleine Tabelle verschiedener Betriebssystemen und deren Standard TTL.

SystemTTL
Windows 95/98/ME32
Linux/MacOS/FreeBSD64
Windows 7/8/10128
Solaris255
Standard TTL verschiedener Betriebssysteme

Logischerweise funktioniert diese Methode nur in lokalen Netzwerken, bzw. bei bekanntem Hop-Count. Übers Internet lassen sich Dienste so jedenfalls nicht genauer identifizieren.

nmap SYN-Scan

Das Tool nmap ist wohl einer des bekanntesten Netzwerkscanner und erfreut sich, spätestens seit der Implementation der WSL 2, nicht nur bei Linux-Administratoren, großer Beliebtheit.

Zwar gibt es ein passendes Frontend namens Zenmap, jedoch geht, für mein Empfinden, damit ein Teil der „Leichtigkeit“ dieses Tools verloren. Die für einen Scan benötigte Befehlszeile ist eben schneller getippt, als ein Frontend konfiguriert, sogar inklusive dem Start über die WSL.

Beim ersten Aufruf des Programms wird man dann aber regelrecht erschlagen, Scantypen, Host-Detektion, IDS-Evasion und noch viele andere Parameter sind in der Hilfe aufgelistet.

Die wichtigsten Kommandos und ihre Bedeutung und Anwendung möchte ich in dieser Serie erläutern.

Einsteig

Nmap erwartet mindestens einen Parameter in Form einer IP-Adresse oder eines Netzwerks in CIDR-Schreibweise. Der Scan ganzer Netzwerke ist zwar ohne Weiteres möglich, jedoch kann dies, abhängig von der Scan-Einstellung, recht lange dauern. Der Einfachheit halber nehme ich in nachfolgenden Beispielen immer nur eine Adresse.

#Aufruf von nmap mit einer Zieladresse als Parameter
nmap 192.168.0.119

Wird nmap wie im obigen Beispiel aufgerufen, wird ein sogenannter SYN-Scan durchgeführt.
Wie der Name schon sagt, werden hierfür SYN-Pakete an den angegebenen Zielhost gesendet um einen TCP-Verbindungsaufbau (Three-Way-Handshake) zur simulieren. Wie das auf der Gegenseite aussieht, kann man in nachfolgendem Screenshot erkennen.

Ist ein Port verfügbar, wird der Server eine entsprechende Antwort, mit gesetzten SYN und ACK-Flag, senden. Anhand dieser Antwort weiß nmap dann, dass der Port erreichbar ist. Lauscht auf der Seite des Zielhosts kein Dienst kann kein SYN-ACK gesendet werden. Was jedoch möglich ist, ist das Übermitteln eines ICMP-Paketes mit dem Statuscode 3 an den vermeintlichen Client. Anhand dieser Informationen kann nmap den Portzustand ebenfalls interpretieren.

Damit ist die Arbeit von nmap bereits beendet. Es werden keine weiteren Anfragen an den Zielhost gesendet und das empfangene SYN-ACK auch nicht bestätigt. Die Kommunikation versackt sozusagen auf halber Strecke.

Der Vorteil des SYN-Scan liegt in seiner Einfachheit. Für den Zielhost erscheint die Anfrage als valide Clientanfrage zum Aufbau einer Verbindung. Zusätzlich hat eine einzelnen SYN-Anfrage erstmal gute Chancen durch eine Firewall, oder ein anderes Sicherheitssystem hindurch zu gelangen. Da SYN-Pakete im Grunde leere Datenpakete sind, können diese auch sehr schnell und massenhaft versendet werden.

Im oben gezeigten Screenshot sind noch ganz zu Beginn des Mitschnitts drei ICMP-Pakete zu erkennen. Diese nutzt nmap um vor Beginn eines Scans eine Host Erkennung durchzuführen. Ist der angegebene Zielhost offline, bzw. antwortet nicht auf ICMP-Pakete, wird der Scan abgebrochen.

Homelab 3 Installation vCenter

Die Lab-Umgebung sollte möglichst vom eigentlichen Heimnetz getrennt werden, sodass hierfür die Konfiguration eines entsprechenden vSwitches, nebst der benötigten Portgruppen auf dem ESX notwendig war. Das eigentliche Routing und Firewalling erfolgt dann mittels pfSense.
Die ursprüngliche Idee, eine lokale Windows Domäne aufzuziehen, habe ich relativ schnell verworfen, da die Hardware des Odroid dem nicht gewaschen scheint. Sicherlich ist der Betrieb einzelner Windows VMs ohne Weiteres möglich, jedoch wollte ich mich erstmal mit der neuen Umgebung vertraut machen. Eine Windows Domäne kann auch später noch folgen.

Die Installation der pfSense verlief ohne Probleme und relativ zügig. Um das Routing aus aus meinem Heimnetzwerk zu ermöglichen, habe ich manuelle Routing-Einträge auf meinem PC hinzugefügt. Anschließend habe ich ein paar grundlegenden Regeln in der Firewall erstellt und getestet.

Der nächste Schritt war die Bereitstellung einer vCenter-Appliance um eine möglichst „realitätsnahe“ Umgebung zu erzeugen. Kaum eine VMware-Umgebung kommt ohne eine solche Appliance aus, da sie eine Vielzahl an Management- und Überwachungsfunktionen mitbringt.
Um diese jedoch bereitstellen zu können benötigt man DNS. Zwar kann man das Ganze auch „irgendwie“ mittels Einträgen in die hosts-Datei hinbiegen, ich halte das aber für Bastelei. Leider sieht man auch in produktiven Umgebungen immer wieder solche „Workarounds“ und wundert sich dann über ein nicht erklärbares Systemverhalten.
Glücklicherweise bietet pfSense einen eigenen DNS-Resolver, welchem man mittels Overwrites individuelle Einträge hinzufügen kann. Die benötigten Einträge für die neue vCenter-Appliance, sowie den ESX-Server waren schnell angelegt. Zusätzlich habe ich gleich noch einen Eintrag für die Firewall erstellt.

Wer noch ein Stück weiter gehen möchte, kann ebenso NTP auf der pfSense aktivieren um einen zentralen Zeitserver für das Netzwerk bereitzustellen. DHCP oder sonstige Dienste habe ich vorerst nicht konfiguriert. Die Adressvergabe in meiner Lab-Umgebung erfolgt komplett mittels statischer IPv4-Adressen.

Die Installation der kleinsten vCenter-Appliance verlief dann auch überwiegend unauffällig….bis auf die Zeit.

Der Odroid ist mit seinem Celeron Prozessor nicht unbedingt leistungsstark und brauch für alles etwas länger. Allein die jetzt laufenden Dienste lasten die CPU schon gut aus. Der Start des vCenters bringt die CPU zum Anschlag. Wenn es dann einmal läuft, ist es einigermaßen performant. Ausnahmsweise ist der Arbeitsspeicher mal nicht das Problem, von den 32GB sind noch gut 26GB frei.