Betriebssysteme an ihrem Fingerabdruck im Netz erkennen
Erkennungs-Dienst
von Viola Bräuer
Erschienen im Linux-Magazin
2002/03
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.
Listing 1: FTP-Banner
|
$ 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.
|
Listing 2: Ping und Traceroute
|
$ 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
|
| Whitepaper |
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|