Public DENIC mailinglist

[Stefan Paletta <sp-denic-public-l AT WRonline.de>]

Liebes Denic, Daniel,

Daniel Roesen wrote/schrieb/scribsit:
> Bin ich der einzige, der fassungslos ist, wie mit der Sicherheit
> der de ccTLD umgegangen wird?
 
Ganz und gar nicht.

Eine Anmerkung darf ich machen bevor es jemand bemaengelt: ich bin
mir bewusst, dass die Daten zu version.bind ab BIND8 leicht
konfigurierbar sind. Auch Daniel weiss das, er weiss aber auch dass
die wenigsten Administratoren diese Daten faelschen.

> (ich weiss, dass dns3/dns4 nicht an de. beteiligt sind).

Aber natuerlich ist dns3.denic.de das.
Angenommen ein full-service resolver hat im cache (dieses Beispiel
ist vereinfacht, aendert aber nichts an der grundsaetzlichen
Funktionsweise):

 de.            NS      dns.denic.de.
 denic.de.      NS      dns3.denic.de.
 dns3.denic.de. A       194.246.96.25

Nun soll er folgende Frage beantworten:
 meine.db24.de. A

Er wird beginnen, dns3.denic.de zu fragen nach:
 dns.denic.de.  A

Nun hat ein Anfgreifer durch die fehlerhafte Version BIND auf
dns3.denic.de diesen unter seine Kontrolle gebracht. Er faelscht
die Antwort und antwortet mit einer IP Adresse unter seiner Kontrolle.
Diesen vermeindlichen dns.denic.de wird der resolver nun fragen nach:
 meine.db24.de.         A

Der Rechner des Angreifers antwortet mit einer IP Adresse unter seiner
Kontrolle. Dort hat der Angreifer einen Webserver laufen der so
aussieht wie der Ihnen vertraute. Sie melden sich mit Passwort an.
Der Angreifer stiehlt Ihr Geld.

Es kommt noch viel herber:
; <<>> DiG 2.2 <<>> @beer.pilsnet.sunet.se version.bind CHAOS TXT +norec 
VERSION.BIND.   0       TXT     "4.9.6-REL"

beer.pilsnet.sunet.se ist NS fuer sunet.se und sunic.sunet.se ist NS
fuer de. Damit kontrolliert ein Nameserver mit einer seit mindestens
1998 obsoleten Software, in einer auch noch veralteten Version mit
bekannten Sicherheitsluecken alle Ihre de-Domains.
Schaut man sich die vertrauten Nameserver fuer die de-Zone an, stellt
man fest dass durch die nicht-.denic.de Server eine ganze Menge z.T.
mehrfach indirekt vertrauter Rechner (viel .edu und .au, aber auch
US-Backbones) hinzugezogen werden. 
Ich bin mir bewusst dass das Denic dem mit der Umstellung auf das
shared secondary system Rechnung traegt und damit die Sicherheit und
Zuverlaessigkeit der de-Zone erhoeht. Dies begruesse ich
ausdruecklich. Es ist jedoch nicht geschafft, solange SUNIC.SUNET.SE,
DNS.NIC.XLINK.NET und AUTH03.NS.DE.UU.NET noch secondaries fuer die
de-Zone sind.

Doch nicht die fremden Server sind es, die mir mehr Sorgen machen.

Wann wird das Denic auf ihren Nameservern Software einsetzen, die
nicht RFC-widrige Antworten liefert? Die Antwort auf z.B.
; <<>> DiG 2.2 <<>> @dns.denic.de ns.wronline.de A +norec 
verletzt die Anforderungen von RFC2181, Abschitt 5.5. 

Wann wird das Denic auf ihren Nameservern nicht mehr Software
einsetzen, von der sich selbst der Hersteller wegen ihrer Fehler und
Geschichte voller Sicherheitskatastrophen distanziert?

Wann wird das Denic auf ihren Nameservern Software einsetzen, die
einen reload von Daten relevanter Groesse innerhalb von Sekunden
(wieviele Stunden dauert ein kompletter reload der de-Zone jetzt?)
durchfuehren kann und zur Verteilung nicht das langsame Zonen-
transferprotokoll einsetzt? Diese Software ist verfuegbar!
Wenn man auch ueber den Sinn mehrfacher Updates der Nameserver
pro Tag streiten kann (ich bin mir bewusst dass alleine schon
die Generierung der Daten ein laengerer Prozess ist), wuerden es
die Kunden nicht begruessen? Wuerden nicht alle begruessen wenn dies
moeglich gewesen waere bei den in der Vergangenheit erlebten Fehlern
in der de-Zone? (Nungut, da das Denic fuer den Normalsterblichen
am Wochenende nicht arbeitet und man die Zone "sowieso" erst am Montag
neu erstellt, ist die Moeglichkeit einer schnellen Fehlerbehebung
wenig relevant in dem Fall dass z.B. einige Delegationen fuer ein
Wochenende schlicht in der de-Zone fehlten und Kunden dadurch Schaden
entstand.)

Stefan

-- 
 junior guru                                                  SMP@IRC