Was bist du? Diese Frage beantworten viele Betriebssysteme schon, sobald sie jemand nur vorsichtig antippt. Der Rest verrät sich durch kleine, aber feine Unterschiede in den Details ihrer Datenpakete.

Ach wie gut, dass niemand weiß, dass ich Rumpelstielzchen heiß – so oder so ähnlich könnte auch die Aussage vieler Admins klingen, die glauben, dass niemand weiß, welches Betriebssystem sie einsetzen. Dabei sind die Systeme in der Regel sehr auskunftsfreudig. Beispielsweise liefert schon ein einfacher Telnet auf Port 21 (FTP) des Netscape-FTP-Servers einiges (siehe Listing 1): Er verrät nicht nur den Namen, sondern auch die Versionsnummer seines Betriebssystems (SunOS 5.7).

Fragt sich, inwiefern diese Informationen nützlich oder schädlich sein können. Einem Angreifer erleichtern sie jedenfalls das Handwerk, er kann damit gezielt die bekannten Schwachstellen dieses Systems durchprobieren (siehe dazu auch den Artikel zu Penetrations-Tests in diesem Heft). Im Geschäftsbetrieb können sie auch nützlich sein, um eine Firma zu beurteilen, mit der man in Kontakt treten will. So könnten sich beispielsweise die Marketing-Versprechen eines Providers schnell in Luft auflösen, nachdem klar ist, welche Systeme er verwendet.

$ telnet ftp.netscape.com 21
Trying 64.12.168.204...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp26c.newaol.com FTP server (SunOS 5.7) ready.

TCP/IP-Spezialitäten

Es sind aber nicht nur die doch recht offensichtlichen (und leicht zu ändernden) Textmeldungen, die etwas über ihr Host-System verraten. Auch in den Bits und Bytes der IP-Pakete, die ein Rechner verschickt, verbirgt sich Verräterisches.

Die TCP/IP-Protokollstacks sollten sich ja eigentlich alle gleich verhalten, die Protokolle sind schließlich Standards. Kleinere Freiheitsgrade lassen aber genug Spielraum für feine Unterschiede. Diese verborgenen Spuren sind zwar komplizierter auszuwerten als das erwähnte Banner-Grabbing, dafür aber nicht so einfach abschaltbar.

Time to Live

Das Time-to-Live-Feld (TTL, siehe Abbildung 1) des IP-Protokolls etwa ist ein hilfreiches Indiz. Eine TTL von 64 kommt bei Linux oder FreeBSD vor. Der Wert von 32 lässt auf ein Microsoft-System älter als NT 4.0 schließen, darüber sind es dann 128. Das Beispiel in Listing 2 zeigt, wie der TTL-Wert zu ermitteln ist: Ping zeigt als TTL 110 an. Dieser Wert steht in den Paketen, die vom Zielrechner zum eigenen Host zurückkommen. Jeder Router dazwischen verringert die Time to Live um den Wert 1, also ist die Anzahl an Zwischenstationen zu den 110 zu addieren.

Geht man davon aus, dass die Pakete in beiden Richtungen den gleichen Weg nehmen, dann hilft Traceroute weiter: Es zeigt 18 Stationen an, die ursprüngliche TTL war also 128. Dieser Wert spricht laut [6] für Windows ab NT 4.0 oder VMS. Welches davon tatsächlich vorliegt, erklärt der Webserver:

$ telnet www.bundestag.de 80
Connected to www.bundestag.de.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0

Abbildung 1: Das TTL-Feld (Time to Live) des IP-Headers erlaubt einige Rückschlüsse auf den IP-Protokollstack, der das Paket losgeschickt hat.

$ ping www.bundestag.de
PING www.bundestag.de (62.180.61.218): 56 data bytes
64 bytes from 62.180.61.218: icmp_seq=0 ttl=110 time=21.350 ms
64 bytes from 62.180.61.218: icmp_seq=1 ttl=110 time=21.256 ms
64 bytes from 62.180.61.218: icmp_seq=2 ttl=110 time=21.466 ms
--- www.bundestag.de ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 21.256/21.357/21.466 ms

$ traceroute www.bundestag.de
traceroute to www.bundestag.de (62.180.61.218), 30 hops max, 40 byte packets
[...]
 9  pos-2-5-core1.frankfurt.ipcore.viaginterkom.de (195.182.99.109)  8 ms  7 ms  7 ms
10  pos-2-0-core1.koln.ipcore.viaginterkom.de (195.182.99.30)  10 ms  10 ms  10 ms
11  ge-5-0-core2.koln.ipcore.viaginterkom.de (195.182.98.82)  10 ms  10 ms  10 ms
12  pos-2-0-core1.dusseldorf.ipcore.viaginterkom.de (195.182.99.34)  11 ms  11 ms  11 ms
13  pos-6-0-0-core-accs1.bielefeld.ipcore.viaginterkom.de (195.182.99.2)  74 ms  160 ms  49 ms
14  195.182.122.2 (195.182.122.2)  20 ms  20 ms  20 ms
15  s-6-0-1-core-accs2.muenster.ipcore.viaginterkom.de (195.182.99.17)  21 ms  21 ms  21 ms
16  nicos-gw.muenster.ipcore.viaginterkom.de (62.180.46.226)  21 ms  28 ms  21 ms
17  * * *
18  62.180.61.218 (62.180.61.218)  21 ms  21 ms  21 ms

Fenstergrößen

Pakete kommen dank unterschiedlicher Routing-Wege nicht zwangsläufig in derselben Reihenfolge an, in der sie losgeschickt wurden. Sie können unterwegs auch ganz verloren gehen. Das TCP-Protokoll enthält für diese Fälle Schutzmechanismen (beispielsweise Paketwiederholung, Byte-Zählung und Timer). In diesem Zusammenhang spielt auch das 16 Bit breite Feld »Window Size« (Abbildung 2) eine wichtige Rolle: Es zeigt, wie viele Bytes der Sender auf die Reise schicken darf, bevor er eine Empfangsbestätigung erhält.

Auch bei diesem Wert sind die Betriebssysteme eigen. Zum Beispiel AIX mit dem einmaligen Wert von 0x3F25, womit sich AIX eindeutig identifizieren lässt. Der angeblich völlig neu geschriebene TCP-Stack für Microsofts Windows 2000 benutzt den Wert 0x402E. Den teilt sich der Stack interessanterweise mit Open- und FreeBSD.

Abbildung 2: In den Feldern des TCP-Headers verbergen sich viele Indizien, mit deren Hilfe sich das benutzte Betriebssystem ermitteln lässt.

Sequenznummern raten

Auch das Verhalten über die Zeit ist bei TCP interessant. Beim Drei-Wege-Handshake zum Aufbau einer TCP-Verbindung legen die beiden Kommunikationspartner ihre Initial Sequence Number (ISN) fest, bei der sie dann mit dem Zählen der gesendeten Bytes beginnen. Als Schutz vor IP-Spoofing [4] sollte der Rechner die ISN bei jeder Verbindung zufällig wählen: Sendet ein Angreifer Pakete mit gefälschter Absender-IP, dann wird er in der Regel die Antworten des Opfers nicht sehen. Er kennt somit auch dessen ISN nicht. Ohne die korrekte Sequence Number nimmt der Server aber die gefälschten Pakete nicht an und es kommt zu keiner Verbindung.

Wie zufällig die ISN tatsächlich ist, darin unterscheiden sich die verschiedenen Betriebssysteme und deren Versionen erheblich. So addiert ein Berkeley-Unix zeitabhängig einen festen Wert für jede neue ISN. Nach dem Beobachten einiger legitimer Verbindungen lässt sich mit hoher Wahrscheinlichkeit die nächste ISN vorhersagen und damit IP-Spoofing erfolgreich betreiben – zugleich sagt die Art des Zufallsgenerators einiges über den TCP-Stack, in dem er steckt.

Auch mit gezielten Testanfragen lassen sich Hinweise auf das Gegenüber ermitteln: Die Antworten unterscheiden sich je nach System und verstoßen auch mal gegen die geltenden RFCs.

Da wäre zum Beispiel die FIN-Probe: Der Ermittler schickt ein Paket mit gesetztem FIN-Flag, das normalerweise dazu dient, eine Verbindung zu beenden. Das konstruierte Paket gehört aber zu keiner Verbindung. Nach RFC 793 wäre die korrekte Reaktion, nicht zu antworten, auch wenn der Port geöffnet ist. Da hier offenbar jeder Hersteller eigene Wege geht, antworten Windows, BSDi, CISCO, HP/UX und IRIX stattdessen mit einem Reset.

Keine Bannerwerbung

Ungewöhnlich verhalten kann sich aber auch der Systemadministrator, etwa indem er den Begrüßungstext seines FTP-Servers ändert und kein oder ein falsches Betriebssystem angibt.

Viele der Tests können einzelne Betriebssysteme nur ausschließen, so bedeutet etwa Window Size ungleich 0x3F25, dass hier etwas anderes vorliegt als AIX. Erst die Kombination verschiedener Tests erhöht die Wahrscheinlichkeit, auf das richtige System zu tippen. Viele Tests zusammen können dann sogar zwischen einzelnen Versionen eines Systems unterscheiden. Die Kombination vieler einzelner Testergebnisse ergibt dann den Fingerabdruck des Rechners. Durch seine Sammlung vieler Host-Fingerprints ist »nmap -O« beispielsweise in der Lage, sauber zwischen Solaris 2.4, Solaris 2.5 bis 2.51 und Solaris 2.6 zu unterscheiden.

Fazit

Das Ausschalten allzu redseliger Begrüßungstexte kann in manchen Fällen sinnvoll sein, auch wenn sich der Admin damit eventuell selbst verwirrt. Ausgefeilte Scanner wie Nmap lassen sich davon zwar nicht beeindrucken, einfachere Exemplare und sogar einige kommerzielle Scanner verlassen sich aber nur auf die Banner und scheitern damit bereits an dieser einfachen Hürde.

Neben den Beispielen aus diesem Artikel gibt es noch eine Menge weiterer Indizien, durch die sich Betriebssysteme verraten können. Für tieferes Versinken in die Materie seien Fyodors Ausführungen [1] zu seinem Nmap empfohlen. (fjl)