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
Ping eines Windows-Hosts, Standard TTL 128Ping eines Linux-Hosts, Standard TTL 64
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.
System
TTL
Windows 95/98/ME
32
Linux/MacOS/FreeBSD
64
Windows 7/8/10
128
Solaris
255
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.
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
einfacher nmap-Aufruf, nur mit IP-Adresse als Parameter
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.
Nachdem ich ein kleines Script angepassst hatte, wollte ich dieses in ein DEB-Paket überführen. Da ich zu diesem Zeitpunkt nur einen Windows 10 PC mit WSL zur Verfügung hatte wollte ich diesen, eigentlich trivialen Job, dort ausführen.
Beim Aufruf des Befehls kam es zu einer Fehlermeldung, die ich so nicht erwartet hatte…
#Befehl zur Erstellung des DEB-Pakets
dpkg-deb --build tolles_script_0.1
dpkg-deb: error: control directory has bad permissions 777 (must be >=0755 and <=0775)
Ist ja kein Problem, schnell die Dateirechte entsprechend angepasst und nochmal versucht…Pustekuchen. Zwar scheint das Ändern der Rechte mittels „chmod“ grundlegend zu funktionieren, jedoch läuft der Befehl weiterhin auf die gleiche Fehlermeldung.
„chmod“ selbst meldet dabei jedoch keine Probleme.
Schnell vermute ich die WSL als Ursache und tatsächlich scheint es dort „Optimierungsbedarf“ zu geben. Auch Microsoft hat das erkannt und hält einen entsprechenden Artikel in der WSL-Dokumentation parat.
Das Verhalten des WSL lässt sich anhand einer Konfigurationsdatei an die Erfordernisse anpassen. Dazu muss die entsprechende Datei erstellt und mit den gewünschten Optionen befüllt werden.
#erstellen der WSL-Konfigdatei
nano /etc/wsl.conf
Der Dateizugriff unter Linux und Windows ist grundsätzlich verschieden, Windows „versteht“ die vom Subsystem gesetzten Optionen nicht und kann diese somit auch nicht abbilden.
Beim überfliegen der Dokumentation fällt einem folgende, standardmäßig deaktivierte Einstellung auf.
Parameter
Beschreibung
Standardwert
metadata
Whether metadata is added to Windows files to support Linux system permissions
disabled
Das klingt genau nach dem was wir suchen. Die Einstellung setzt man anschließend in der Konfigurationsdatei.
Nach der Aktivierung der Option ist es notwendig das Linux-Subsystem einmal komplett neu zustarten. Am schnellsten geht das mittels Neustart des Dienstes mit der Powershell. Achtung: Hierfür sind Administratorrechte notwendig. Sind diese nicht vorhanden, ist auch ein Neustart des PCs möglich!
#Neustart des WSL-Dienstes in Powershell
Get-Service LxssManager | Restart-Service
Anschließend setzen wir die Dateiberechtigungen erneut:
Zuletzt wird der Befehl zur Erstellung des DEB-Paketes neu ausgeführt. Und siehe da, keine Fehlermeldung mehr und ein hoffentlich funktionsfähiges DEB-Paket.
dpkg-deb --build tolles_script_0.1
dpkg-deb: building package 'tolles_script_0.1' in 'tolles_script_0.1.deb'
Als WSL nutze ich übrigens Kali Linux. Ich bin mir aber sicher, dass das Problem auch bei anderen Distributionen auftritt.
