TTL beim Ping: So erkennst du das Betriebssystem
Neulich bin ich über einen kleinen Netzwerk-Trick gestolpert, der mich sofort gepackt hat: Anhand der TTL in einer Ping-Antwort kannst du oft erkennen, welches Betriebssystem auf der Gegenseite läuft. Linux, Windows oder doch ein Router? Ein einziger ping verrät erstaunlich viel über das System, das dir antwortet.
Natürlich musste ich das sofort in meinem eigenen Homelab ausprobieren. Ich zeige dir, was hinter der TTL steckt, welche Startwerte die gängigen Systeme verwenden und warum der Wert unterwegs kleiner wird. Dazu gibt es echte Messwerte aus meinem Netz (anonymisiert) und am Ende auch die Antwort auf die Frage, warum du dich auf diesen Trick nicht blind verlassen solltest.
🔍 Was die TTL eigentlich ist
Jedes IPv4-Paket trägt im Header ein kleines Feld mit dem Namen Time To Live, kurz TTL. Das ist eine Zahl zwischen 0 und 255. Der Absender setzt einen Startwert, und jeder Router auf dem Weg zieht genau 1 davon ab, bevor er das Paket weiterreicht. Erreicht der Wert 0, wirft der Router das Paket weg und schickt dem Absender die ICMP-Meldung Time to live exceeded zurück.
Warum das Ganze? Ohne TTL würde ein Paket bei einer fehlerhaften Route im Kreis laufen, bis das Netz irgendwann schlapp macht. Die TTL ist also eine Art Verfallsdatum. Spannend finde ich übrigens, dass der Name noch aus den Anfängen stammt: Im ursprünglichen IP-Standard RFC 791 war der Wert tatsächlich in Sekunden gedacht. In der Praxis zählt heute aber jeder Router einfach um eins herunter, deshalb sind es faktisch Hops.
Und jetzt kommt der Clou: Der Startwert ist nicht genormt. Jedes Betriebssystem hat seinen eigenen Standardwert. Wenn du also weißt, mit welchem Wert ein Paket gestartet ist, weißt du auch ungefähr, wer es losgeschickt hat.
🧮 Typische TTL-Startwerte nach Betriebssystem
In der Praxis begegnen dir fast immer dieselben drei Werte. Die folgende Tabelle ist mein persönlicher Spickzettel:
| Startwert | Typische Systeme |
|---|---|
| 64 | Linux, Android, macOS und iOS, FreeBSD und OpenBSD (also auch OPNsense und pfSense), die meisten NAS, Switches, Access Points und IoT-Geräte |
| 128 | Windows ab Windows NT, also auch Windows 10, Windows 11 und Windows Server |
| 255 | Viele klassische Router und Netzwerkgeräte (zum Beispiel Cisco IOS), Solaris und AIX |
| 32 | Uralte Windows-Versionen wie Windows 95 und 98. Falls dir das heute noch begegnet, hast du ganz andere Probleme. 😉 |
Die 64 ist übrigens kein Zufall. Sie wurde schon 1994 in RFC 1700 als empfohlener Standardwert festgehalten, und der Linux-Kernel verweist in seiner Dokumentation bis heute genau darauf.
Da ein Paket auf dem Weg durch das Internet selten mehr als 30 Router passiert, gilt eine einfache Faustregel: Runde den TTL-Wert aus der Antwort auf den nächsthöheren Startwert auf. Das ist mit hoher Wahrscheinlichkeit das Betriebssystem. Die Differenz verrät dir dann, wie viele Router zwischen dir und dem Ziel liegen.
- TTL 64: Linux oder ein ähnliches System, direkt in deinem Netz.
- TTL 57: aufgerundet 64, also Linux-artig, mit 7 Routern dazwischen.
- TTL 127: aufgerundet 128, also Windows, ein Router dazwischen.
- TTL 249: aufgerundet 255, vermutlich ein Router oder Netzwerkgerät, 6 Hops entfernt.
🖥️ So liest du die TTL unter Windows und Linux ab
Du brauchst dafür kein spezielles Werkzeug. Der ganz normale ping zeigt die TTL bei jeder Antwort mit an. Unter Windows steht sie am Ende der Zeile in Großbuchstaben:
C:\> ping -n 1 10.0.10.50 Antwort von 10.0.10.50: Bytes=32 Zeit<1ms TTL=64
Unter Linux und macOS heißt das Feld kleingeschrieben ttl=:
$ ping -c 1 10.0.10.20 64 bytes from 10.0.10.20: icmp_seq=1 ttl=128 time=1.27 ms
Im ersten Beispiel antwortet also ein Linux-System, im zweiten ein Windows-Rechner. Beide stehen im selben Netz wie der Absender, deshalb fehlt vom Startwert nichts. Wichtig: Du siehst immer die TTL des Antwortpakets. Es geht also um den Startwert des Systems, das dir antwortet, und um die Router auf dem Rückweg zu dir.
🏠 Praxistest: Mein Homelab im TTL-Check
Genug Theorie! Ich habe von einem Linux-Rechner in meinem Server-Netz aus ein paar Systeme angepingt. Die IP-Adressen habe ich anonymisiert, die TTL-Werte sind aber echt. Damit du die Ergebnisse einordnen kannst, kurz zum Aufbau: Mein Netz ist in mehrere VLANs aufgeteilt, und eine OPNsense-Firewall routet zwischen diesen Netzen. Dahinter hängt noch ein Router zum Provider.
| Ziel | Wo steht es? | TTL | Deutung |
|---|---|---|---|
| Windows Server (Monitoring) | gleiches Netz | 128 | Windows, 0 Hops |
| Home-Assistant-VM | gleiches Netz | 64 | Linux, 0 Hops |
| OPNsense-Firewall | Gateway im Management-VLAN | 64 | FreeBSD, 0 Hops |
| Core-Switch | Management-VLAN | 63 | Embedded-System mit Startwert 64, 1 Hop |
| Proxmox-Host | eigenes VLAN | 63 | Linux, 1 Hop |
| VPS im Rechenzentrum | Internet | 57 | Linux, 7 Hops |
| 1.1.1.1 (Cloudflare) | Internet | 55 | Startwert 64, 9 Hops |
| 8.8.8.8 (Google) | Internet | 115 | Startwert 128? Dazu gleich mehr. |
Auf den ersten Blick ist das schon ziemlich eindeutig. Der Windows Server meldet sich mit 128, alles andere startet bei 64. Interessant wird es aber bei den Werten, die eben nicht glatt sind.
Warum der Switch nur 63 meldet
Der Core-Switch steht in einem anderen VLAN als mein Linux-Rechner. Seine Antwort muss deshalb einmal durch die Firewall, die zwischen den beiden Netzen routet. Die Firewall macht genau das, was ein Router laut Standard machen muss: Sie zieht 1 von der TTL ab. Aus 64 wird 63. Beim Proxmox-Host passiert exakt dasselbe, er hängt ebenfalls in einem eigenen VLAN.
Ein Switch innerhalb desselben Netzes zieht dagegen nichts ab. Er arbeitet auf Layer 2 und schaut sich den IP-Header gar nicht an. Deshalb kommen der Windows Server und die Home-Assistant-VM mit ihrem vollen Startwert bei mir an, obwohl auch dort ein paar Switches dazwischen hängen.
Warum die Firewall trotzdem 64 meldet
Moment, die Firewall steht doch auch im Management-VLAN? Richtig, aber hier antwortet die Firewall selbst. Ihre IP im Management-VLAN ist eine ihrer eigenen Schnittstellen. Das Paket wird also gar nicht weitergeleitet, sondern direkt von ihr beantwortet. Kein Routing, kein Abzug. OPNsense basiert auf FreeBSD, und das startet ebenfalls mit 64.
Die 7 Hops zum VPS nachzählen
Bei meinem VPS kam eine 57 zurück. Aufgerundet ergibt das 64, also ein Linux-System, und 64 minus 57 macht 7 Router. Das wollte ich genauer wissen und habe den Weg mit mtr nachverfolgt:
$ mtr -4 -n -r -c 3 203.0.113.50 HOST: linux-client Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.0.10.1 0.0% 3 0.6 0.7 0.6 0.8 0.1 2.|-- 192.168.178.1 0.0% 3 0.8 0.7 0.6 0.8 0.1 3.|-- 198.51.100.65 0.0% 3 5.8 5.7 5.5 5.9 0.2 4.|-- 198.51.100.210 0.0% 3 10.7 10.7 10.5 11.0 0.3 5.|-- 198.51.100.10 0.0% 3 10.5 10.3 10.2 10.5 0.1 6.|-- 203.0.113.247 0.0% 3 12.7 13.2 12.7 13.6 0.4 7.|-- 203.0.113.21 0.0% 3 13.6 18.8 12.5 30.3 9.9 8.|-- 203.0.113.50 0.0% 3 12.8 13.0 12.8 13.1 0.2
Zeile 8 ist der VPS selbst. Davor liegen genau 7 Router: meine Firewall, der Router zum Provider und fünf Router im Netz der Provider und des Rechenzentrums. Der VPS schickt seine Antwort mit 64 los, jeder dieser Router zieht eins ab, und bei mir kommt 57 an. Die Rechnung geht also auf!
Ein kleiner Haken bleibt: mtr zeigt dir den Hinweg, die TTL in der Antwort hängt aber vom Rückweg ab. Im Internet sind Hin- und Rückweg nicht immer identisch. Wenn die Zahlen mal um ein, zwei Hops abweichen, ist also nicht gleich etwas kaputt. Wie du mtr installierst und die Ausgabe richtig liest, habe ich dir übrigens in einem eigenen Beitrag erklärt:
Den Abzug live beobachten
Du kannst den Mechanismus auch ganz direkt sichtbar machen. Unter Linux legst du mit -t selbst fest, mit welcher TTL dein Ping startet. Mit einer TTL von 1 kommt das Paket genau bis zum ersten Router. Der zieht eins ab, landet bei 0 und meldet sich bei dir:
$ ping -c 1 -t 1 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. From 10.0.10.1 icmp_seq=1 Time to live exceeded --- 1.1.1.1 ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Geantwortet hat meine Firewall, also der erste Router auf dem Weg. Mit -t 2 meldet sich der zweite Router, mit -t 3 der dritte und so weiter. Genau nach diesem Prinzip arbeiten übrigens traceroute und mtr. Unter Windows funktioniert das Gleiche mit ping -i 1 1.1.1.1.
🎭 Warum die TTL auch lügen kann
So schön der Trick ist, er bleibt eine Faustregel. Der Startwert ist schließlich nur eine Einstellung, und Einstellungen kann man ändern. Spätestens bei Google wird das in meiner Tabelle sichtbar: 8.8.8.8 antwortet mit 115. Aufgerundet wäre das 128 und damit Windows. Dass Googles DNS-Infrastruktur auf Windows-Servern läuft, halte ich allerdings für ziemlich unwahrscheinlich. Große Anbieter setzen eigene Werte, und oft antwortet bei solchen Diensten auch gar nicht der eigentliche Server, sondern ein Load Balancer oder Edge-System davor.
Experiment: Linux als Windows tarnen
Wie leicht sich die TTL verbiegen lässt, habe ich auf einer Test-VM ausprobiert. Unter Linux steuert der Kernel-Parameter net.ipv4.ip_default_ttl den Startwert:
$ sysctl net.ipv4.ip_default_ttl net.ipv4.ip_default_ttl = 64 $ sudo sysctl -w net.ipv4.ip_default_ttl=128 net.ipv4.ip_default_ttl = 128
Ein Ping von meinem Windows-Rechner vorher und nachher:
Vorher: Antwort von 10.0.10.92: Bytes=32 Zeit<1ms TTL=64 Nachher: Antwort von 10.0.10.92: Bytes=32 Zeit=1ms TTL=128
Und schon hält jeder, der nur auf die TTL schaut, meine Ubuntu-VM für einen Windows-Rechner. Danach habe ich den Wert natürlich wieder auf 64 zurückgestellt. Die Änderung mit sysctl -w gilt ohnehin nur bis zum nächsten Neustart. Dauerhaft würdest du sie in einer Datei unter /etc/sysctl.d/ eintragen. Einen echten Grund dafür gibt es im Alltag aber nicht, ich würde die Finger davon lassen.
Unter Windows kannst du dir den Startwert übrigens auch anzeigen lassen. Dort heißt er etwas sperrig Standardhoplimit:
C:\> netsh interface ipv4 show global | findstr /i hop Standardhoplimit : 128 Hops
Mit netsh interface ipv4 set global defaultcurhoplimit=64 ließe sich das in einer Admin-Konsole genauso umstellen. Auch hier gilt: schön zu wissen, aber bitte nur zum Ausprobieren.
Weitere Stolperfallen
- Load Balancer, CDNs und Reverse Proxys: Antwortet ein vorgeschaltetes System, siehst du dessen Startwert und nicht den des eigentlichen Servers.
- Firewalls mit Normalisierung: Manche Firewalls setzen die TTL unterwegs auf einen festen Wert, damit von außen nicht erkennbar ist, was dahinter steckt. Mobilfunkanbieter nutzen den Effekt übrigens auch andersherum: Pakete vom Laptop hinter einem Handy-Hotspot kommen mit einer TTL weniger an als die vom Handy selbst. So lässt sich Tethering erkennen.
- Virtualisierung und Container: Ein Docker-Container teilt sich den Kernel mit seinem Host. Ein Container auf einem Linux-Host antwortet deshalb mit 64, egal welches Image darin läuft. Beim Weg über ein Docker-Bridge-Netz kann zudem ein zusätzlicher Hop dazukommen.
- Kein Ping, keine TTL: Blockt eine Firewall ICMP, bekommst du schlicht keine Antwort und damit auch keinen Wert.
🌐 Und bei IPv6? Dort heißt sie Hop Limit
Bei IPv6 gibt es das Feld TTL nicht mehr. Seine Aufgabe übernimmt das Hop Limit, und der Name sagt endlich ehrlich, was gezählt wird. Das Prinzip ist identisch: Jeder Router zieht eins ab, bei 0 ist Schluss. Auch die Startwerte sind dieselben, Linux nutzt standardmäßig 64 und Windows 128. Mit ping -6 funktioniert der Trick also genauso, die Zahl findest du unter Linux wieder hinter ttl=.
🕵️ Betriebssystem genauer erkennen mit nmap
Wenn dir eine Faustregel nicht reicht, kommt OS-Fingerprinting ins Spiel. Werkzeuge wie nmap betrachten nicht nur die TTL, sondern eine ganze Reihe von Merkmalen: die TCP-Fenstergröße, die Reihenfolge der TCP-Optionen, das Verhalten bei ungewöhnlichen Paketen und einiges mehr. Daraus entsteht ein Fingerabdruck, den nmap mit seiner Datenbank vergleicht. Für die Erkennung brauchst du Root-Rechte:
$ sudo nmap -O 10.0.10.20 [...] Device type: general purpose|phone|specialized Running (JUST GUESSING): Microsoft Windows 2016|2012|2022|Phone|7 (97%) Aggressive OS guesses: Microsoft Windows Server 2016 (97%), Microsoft Windows Server 2012 or Windows Server 2012 R2 (91%), Microsoft Windows Server 2022 (91%), [...] No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop
Das ist mein Windows Server von oben, und nmap landet ziemlich nah dran. Statt nur „Windows“ bekommst du hier schon konkrete Versionen mit einer Wahrscheinlichkeit. Ganz unfehlbar ist aber auch nmap nicht: Meine OPNsense-Firewall hat es als FreeBSD 11.2 eingeschätzt, obwohl darunter ein deutlich aktuelleres FreeBSD läuft. Das „JUST GUESSING“ in der Ausgabe ist also durchaus ernst gemeint. 😄
Die Gegenrichtung gibt es auch: p0f arbeitet passiv. Es schickt selbst keine Pakete los, sondern lauscht nur am Netzwerkverkehr und erkennt anhand der gleichen Merkmale, welche Systeme sich gerade bei dir melden.
Ein wichtiger Hinweis noch: Ein Ping ist harmlos, ein Portscan mit OS-Erkennung ist es aus Sicht des Gegenübers nicht unbedingt. Scanne mit nmap bitte nur deine eigenen Systeme oder Netze, für die du ausdrücklich die Erlaubnis hast.
📋 Kurz zusammengefasst
- Jedes Betriebssystem startet mit einem eigenen TTL-Wert: Linux und Co. mit 64, Windows mit 128, viele Router mit 255.
- Jeder Router auf dem Weg zieht 1 ab. Switches im selben Netz tun das nicht.
- Den TTL-Wert der Antwort auf den nächsten Startwert aufrunden, dann hast du das wahrscheinliche Betriebssystem. Die Differenz ist die Anzahl der Hops.
- Die TTL lässt sich mit einer Zeile ändern. Sie ist ein Hinweis, kein Beweis.
- Für eine genauere Einschätzung nutzt du
nmap -O, aber nur bei deinen eigenen Systemen.
📚 Quellen und weiterführende Links
- RFC 791: Internet Protocol, Definition des TTL-Felds (englisch)
- RFC 1700: Assigned Numbers, empfohlene Standard-TTL von 64 (englisch)
- RFC 8200: IPv6 Specification mit dem Hop Limit (englisch)
- Linux-Kernel-Dokumentation: ip_default_ttl und weitere Netzwerkparameter (englisch)
- Nmap Reference Guide: OS Detection (englisch)
- p0f auf GitHub: passives OS-Fingerprinting (englisch)
💡 Mein Fazit
Ich finde es immer wieder faszinierend, wie viel in so einem unscheinbaren Ping steckt. Eine einzige Zahl verrät dir mit etwas Glück, ob ein Linux-Server, ein Windows-Rechner oder ein Router antwortet und wie viele Stationen dazwischen liegen. Für eine schnelle Einschätzung im eigenen Netz ist das ein richtig praktischer Trick.
Gleichzeitig hat mein kleines Experiment gezeigt, wie leicht sich die TTL verbiegen lässt. Nimm sie also als ersten Hinweis und nicht als Beweis. Und jetzt bist du dran: Öffne ein Terminal, ping ein paar Geräte in deinem Netz an und rechne nach. Ich wette, du findest mindestens ein Gerät, bei dem du kurz stutzt!
👥 Techniverse Community
Lust auf Austausch rund um Matrix, Selfhosting und andere smarte IT-Lösungen?
In der Techniverse Community triffst du Gleichgesinnte, kannst Fragen stellen oder einfach nerdigen Talk genießen. 🚀
👉 Jetzt der Gruppe auf Matrix beitreten
~ Direkte Raumadresse: #community:techniverse.net
👉 Für lockere Gespräche abseits der Kernthemen komm in den Talkraum
~ Direkte Raumadresse: #talk:techniverse.net
Ich freue mich, wenn du dabei bist!
