Unser Server hier dient im Nebenjob als Zeitserver für pool.ntp.org. Das ist eine Sammlung von zur Zeit 1300 Rechnern, die sich um eine besonders genaue Uhrzeit kümmern und jedem anderen Rechnern erlauben, sich übers Internet per NTP-Protokoll mit ihnen zu synchronisieren.
Entstanden ist der Pool, als die Nachfrage nach NTP-Servern im Netz stark anstieg und jeder der Clients sich einen der wenigen NTP-Server bei Unis, Wetterdiensten und anderen Atomuhrenbetreibern ausgesucht hat. Das hat dann dazu geführt, dass die Betreiber damit gedroht haben, ihre Dienste einzustellen, weil sie den Traffic nicht bezahlen wollten. So wurde ein Pool von Rechnern gegründet, der sich mit diesen primären Zeitquellen synchronisiert und das Gros der Zeitanfragen beantworten sollte. Ich denke, das ist mehr ein symbolischer Akt. Ein Poolserver bedient zwar ein paar Tausend Clients, aber vermutlich nutzen immer noch Hunderttausende die primären Server z.B. der Physikalisch-Technischen Bundesanstalt oder des amerikanischen Instituts für Normen.
Zeitserver zu spielen wäre eigentlich keine grosse Sache. Ins wirkliche Leben übertragen wäre das in etwa so, dass man sich ein Schild "Zeitserver" umhängt, darauf achtet, seine Armbanduhr stets genau zu stellen und während man einkauft oder zur Arbeit fährt, können einen die Leute nach der Uhrzeit fragen und ihre eigene Uhr stellen. Im Internet heisst das, dass man 5-10GByte pro Monat übrig hat und ein paar Tausend Verbindungen gleichzeitig bedienen kann. Die einzelne Verbindung benötigt ein paar Hundert Bytes an Traffic.
Dummerweise hat man dann doch damit Ärger, weil die Leute ihre Firewalls nicht bedienen können. Das führt so weit, dass man Briefe vom Provider bekommt, weil die Antworten des Zeitservers als Angriff auf den Anfragenden gedeutet werden. Das ist mir zwar noch nicht passiert, aber anlässlich eines
Berichts darüber hab ich mal genauer geschaut, wie meine Clients so reagieren:
Beliebt ist z.B. dieses Spiel:
Client->Server: NTP: Frage
Server->Client: NTP: Antwort
Client->Server: ICMP: Client nicht erreichbar
Übertragen aufs richtige Leben: Einer fragt mich nach der Uhrzeit, ich sag sie ihm und er hört einfach weg.
Oder dieses:
Client->Server: NTP: Frage
Server->Client: NTP: Antwort
Client->Server: ICMP: unreachable - admin prohibited filter
Also in etwa: Einer fragt mich nach der Uhrzeit, ich sag sie ihm und er schreit "Belästigen Sie mich nicht!!!". Anscheinend eben noch um die Variante erweitert, dass ein paar dieser Kandidaten zur Polizei laufen und den Zeitserver anzeigen.
Ganz neu ist auch diese Variante, anscheinend liefert T-Online derart gestaltete Firewalls aus:
Client->Server: NTP: Frage
Server->Client: NTP: Antwort
Client->Server: ICMP: redirect 217.229.x.y to host 192.168.46.21
Einer fragt mich nach der Uhrzeit, ich sag sie ihm und er sagt "Ach erzähl das doch der Parkuhr da drüben, die sagts mir dann weiter". Dummerweise steht da nichtmal eine Parkuhr die für mich erreichbar wäre.
Die Clients kommen so natürlich niemals an meine Zeitauskunft ran. Einige reagieren dann damit, dass sie einfach die Frequenz der Anfragen erhöhen, um irgendwann doch durchzukommen. Der gleiche Typ, der mich an die Parkuhr verweist, kommt dann also alle paar Sekunden angerannt und will die Uhrzeit wissen... Gegenmassnahmen laufen deshalb oft ins Leere. Ignorieren hilft nicht viel, den eingehenden Traffic, die Anfragen, hat man trotzdem. Die Leute anzuschreiben hat bisher nicht viel gebracht, ich glaube, meine Mails in dieser Sache landen irgendwo im Spamfilter.
Dabei wäre es eigentlich ganz einfach, seine Firewall passend zu konfigurieren:
- NTP verwendet das UDP-Protokoll, nicht TCP. Das ist das gleiche Protokoll, das z.B. auch für Nameserver verwendet wird. Dort müsstest Du Port 123 freischalten.
- UDP ist verbindungslos, es gibt keinen definierten Datenstrom im Sinne von "Das ist das erste Paket der Verbindung, das hier die Antwort des Servers darauf und jetzt kommt ein Paket mit der Empfangsbestätigung vom Client...". Entweder Deine Firewall hat trotzdem irgendwas "verbindungsorientiertes" eingebaut ("Ein Server, der auf Port 123 von hier aus angesprochen wird, wird für 30 Sekunden auch eingehend freigeschaltet") oder Du musst eben alles was auf Port 123 ankommt reinlassen.
- Falls Deine Firewall NAT macht, muss sie sowas wie oben erwähnt eingebaut haben. Sie muss ja die Antwort dem richtigen internen Client zuordnen können. Übliche DSL-Router machen NAT, man erkennt das daran, dass man intern andere IP-Adressen hat (192.168... z.B.) als die nach Aussen sichtbare dynamisch zugewiesene.
- "pool.ntp.org" ist nicht genau eine IP-Adresse, sondern eben ein Pool. Es hilft nichts, diesen "Host" in der Firewall freizuschalten. Die würde sonst beim Booten diesen Hostnamen in eine IP-Adresse umwandeln und diese in ihre Regeln eintragen. Ein anfragender Client bekommt aber Stunden später eine andere Adresse als Zeitserver zugewiesen. Die wäre dann in Deiner Firewall gesperrt. Dieses Problem hast Du übrigens auch bei Windows-Clients, die "time.windows.com" als Server verwenden, auch das ist eigentlich ein Pool.
- Falls Du Deine Clients nicht im Griff hast, weil die Studenten in Deinem Wohnheim nicht auf ihren Admin hören, gib halt 123/udp ganz frei. Falls Du das nicht möchtest, sperr ihnen den Port ausgehend. Dann bekommen sie auch keine Zeitinformation, gehen aber da draussen niemandem auf die Nerven.
- Falls Du Snort einsetzt, um verdächtigen Netzwerkverkehr zu überwachen und Meldungen über NTP-Pakete mit Überlänge bekommst, ist das noch nicht zwingend ein Angriff. Normale Zeitansagen sind tatsächlich kleiner als 128Byte, in der Regel 48Byte. Neben der normalen Zeitsynchronisation kann ich aber auch weitere Statusinformationen eines Servers einholen (z.B. kann man mit "ntpq -pn servername" rausbekommen, wo sich der Server selbst seine Zeit holt). Die Antworten auf solche Anfragen sind dann längere Pakete. Solltest Du also im Snort auf "EXPLOIT ntpdx overflow attempts" hingewiesen werden, schau doch mal mit tcpdump oder etherreal nach, ob einer Deiner Clients gerade dabei ist, ntp-Server nach Statusinformationen abzufragen.
- pool.ntp.org liefert Zeit per NTP (RFC 985 oder dessen Nachfolger 1305 und 2030) aus. Es gibt weitere Protokolle (z.B. RFC-868-Time-Protokoll oder RFC-867-Daytime), aber es ist Glücksache, ob ein Poolserver diese Protokolle unterstützt. Es gibt eigentlich auch keinen Grund die zu nehmen, diese Protokolle haben Nachteile gegenüber NTP (Nur eine Sekunde Auflösung bei RFC868, zusätzlich kein definiertes Format der Antwort bei RFC867). Bei meinem Server funktioniert das zwar bis auf weiteres, aber eigentlich nur aus Gründen der Tradition. Die pfiffige Idee, sich die Zeit über HTTP-Anfragen zu besorgen ist lustig und sehr firewallverträglich, wird aber ebenfalls von Poolservern nicht unterstützt.
Falls Du viele Clients hast, bau einen eigenen NTP-Server, der sich mit dem Pool synchronisiert und sag Deinen Leuten, sie sollen den verwenden. Das bringt auch Deinen Kunden Vorteile. ein NTP-Server hat seine Zeit immer auf 2-50ms genau. Der grösste Unsicherheitsfaktor bei der Synchronisation ist die Laufzeit der Pakete übers Internet. Ein eigener Server im Keller mit 1ms Laufzeit wäre ideal.
Schön wäre es, wenn Du den Server dann noch in den Pool eintragen könntest. Einen Server aufzusetzen ist nicht viel Arbeit, 10GByte/Monat solltest allerdings entbehren können, Du brauchst eine feste IP-Adresse dafür und virtuelle Server eignen sich in der Regel nicht. vServer haben nämlich meistens keinen Zugriff auf die echte Hardwareuhr. Dabei lernt man auch ungemein viel über Netzwerkprotokolle, lustige ICMP-Antworten und verkorkste Firewalls.
Als Bonus bekommt man auch noch eine schöne Statistik über seine eigene Uhr geliefert. Diese Erfassung der Genauigkeit der Poolserver dient auch dazu, falsch gehende Uhren rauszuwerfen. Falls Deine Uhr also mal nicht stimmt, bekommst Du eine Mail, die Dich darauf hinweist und Dein Server wird vorübergehend aus dem Pool geworfen, bis die Zeit wieder passt.
PS: Wer mehr über NTP erfahren will, findet bestimmt bei "Heise: Zeit-Abgleich" genug Lektüre...