DNSSEC für Mailserver richtig einrichten

Abstract

Die Grundlage für DANE over SMTP ist ein DNSSEC-fähiger Resolver. Davon gibt es einige brauchbare, aber es gibt ein paar Stolperfallen zu beachten, damit der Resolver auch wirklich vertrauenswürdige Informationen liefert.

E-Mail ohne DNS ist kaum vorstellbar. Nahezu alle E-Mail-Routing-Entscheidungen basieren auf Informationen, die der Mailserver durch DNS-Abfragen erlangt hat. Umso erstaunlicher ist, dass viele gerade bei der DNS-Abfrage keinen besonderen Wert darauf legen, mit Sicherheit vertrauenswürdige Routing-Informationen zu erhalten. Was ist, wenn ein Angreifer per MITM-Attacke das DNS fälscht und die Daten beim falschen Server abgegeben werden?

Schlimmer finde ich fast nur noch, dass Gott und Welt die 8.8.8.8 von Google als ersten Resolver in die /etc/resolv.conf packen und dem neugierigen Unternehmen mit jeder Abfrage frei Haus Auskunft darüber geben, mit wem man denn so per E-Mail kommuniziert. Abgesehen davon, dass einige DNS-Blacklist-Provider wie z.B. Spamhaus Anfragen von Google DNS blocken...

Note

Sicher liegt das auch an dem Mythos, man dürfe die DNS-root-Server nicht direkt abfragen, um sie vor Überlastung zu schützen. Vier Worte: Es ist ein Mythos.

Die Lösung beider Probleme ist ein lokaler, cachender und DNSSEC-fähiger Resolver.

Lokal
Lokal muss er sein, weil DNSSEC-Abfragen mit Vertrauen zu tun haben. Ein lokaler Resolver ist aufgrund der systeminternen Kommunikation vertrauenswürdiger als einer, mit dem über ein unverschlüsseltes Netzwerk gesprochen wird.
Cachend
Cachend sollte er sein, damit wiederkehrende Abfragen schnell verfügbar sind. Gerade wenn der Mailserver auch DNS-Blacklisten eingebunden hat, um Spammer abzuwehren, steigert ein cachender Resolver die Verarbeitungsgeschwindigkeit bei Clients, die einfach nicht fassen können, dass sie nicht mailen dürfen.
DNSSEC-fähig
DNSSEC-fähig sollte er sein, damit er vertrauenswürdige Routing-Informationen liefern kann, wenn die abzufragende Zone DNSSEC-signiert ist.

Unbound

Unbound ist ein DNS-Resolver. Er kann DNS-Namen auflösen, aber nicht wie ein Autoritativer Nameserver eigene Zonen ausliefern. Nach der Installation auf dem Mailserver startet er je nach Plattform chrooted, bindet sich an 127.0.0.1:53 und wartet dort auf Anfragen:

# lsof -Pni :53
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
unbound 1344 unbound    3u  IPv6   8870      0t0  UDP [::1]:53
unbound 1344 unbound    4u  IPv6   8871      0t0  TCP [::1]:53 (LISTEN)
unbound 1344 unbound    5u  IPv4   8872      0t0  UDP 127.0.0.1:53
unbound 1344 unbound    6u  IPv4   8873      0t0  TCP 127.0.0.1:53 (LISTEN)

Unbound cachet auch Anfragen. Das zeigt sich gut in dem folgenden Beispiel, bei dem die erste Abfrage 27 msec und die Zweite 4 msec benötigt.

$ dig @127.0.0.1 www.heise.de
...
;; Query time: 27 msec

$ dig @127.0.0.1 www.heise.de
...
;; Query time: 4 msec

Fehlt nur noch das Sahnehäubchen und der eigentliche Grund, Unbound zu installieren: Unbound ist DNSSEC-fähig. Aber die Fähigkeit, DNSSEC-signierte Domains zu erkennen und ihre Gültigkeit zu prüfen, ist nicht von Haus aus verfügbar. Sie muss erst eingerichtet und konfiguriert werden.

DNSSEC-Validierung in Unbound aktivieren

Irgendwo fängt Vertrauen immer an. Im Fall einer DNSSEC-signierten Domain beginnt das Vertrauen bei ihrer Top-Level-Domain. Von dort aus wird eine Kette nach unten bis zur Domain, die validiert werden soll, gebildet.

Note

Das Konstrukt ist sicherlich schon von Certification Authorities bekannt. Da traut die Software auch dem root-Zertifikat der CA, und alle anderen von der CA signierten Zertifikate sind in dieser dann entstehenden Kette vertrauenswürdig, eben weil die Software der CA vertraut.

In der Welt von DNSSEC entspricht der Trust Anchor des DNS-root-Servers dem root-Zertifikat einer Certification Authority. Wenn Unbound die DNS-Zone einer DNSSEC-signierten Domain validieren können soll, benötigt es zuerst den Trust Anchor. Von ihm ausgehend, kann Unbound die gesamte Kette aller Domains und Subdomains validieren, bis es bei der Domain angekommen ist, an die der Mailserver senden möchte.

Der Trust Anchor befindet sich in einer Datei, die von einer Website der IANA heruntergeladen werden muss. Diesen Vorgang erledigt das Kommandozeilen-Werkzeug unbound-anchor. Ohne Zusatzoptionen aufgerufen, holt es den Schlüssel und legt ihn unter /etc/unbound/root.key ab.

Sobald der Key auf dem Server ist, muss Unbound konfiguriert werden, ihn zu nutzen. Dazu aktiviert man in /etc/unbound/unbound.conf den Parameter auto-trust-anchor-file und übergibt ihm den Pfad zum root.key:

server:
    # The following line will configure unbound to perform cryptographic
    # DNSSEC validation using the root trust anchor.
    auto-trust-anchor-file: "/etc/unbound/root.key"

Vorausgesetzt Unbound darf die key-Datei lesen, wird Unbound jetzt nach einem Reload DNSSEC-signierte Domains validieren:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
$ dig @127.0.0.1 sys4.de +dnssec

; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 sys4.de +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3744
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sys4.de.           IN  A

;; ANSWER SECTION:
sys4.de.        3600    IN  A   194.126.158.154
sys4.de.        3600    IN  RRSIG   A 8 2 3600 20140529155741 20140522173232 42928 sys4.de. NB5ZBY2324jGQcrxY3cDdZPJNSQ7BMJ1Wdj9dmLaI0jecrDXpDQpbHeK ccewxegn4rcZ1Wt8amT+coqceDGoPJGzLUGJ8J9aKGXwYPShm8Ug/Iot yHY0Wst+2UQhibgeaeCQo+e87+tIPlztVhTaRrW2EqhIareLQ30p0vc2 P8g=

;; AUTHORITY SECTION:
sys4.de.        3600    IN  NS  ns.sys4.de.
sys4.de.        3600    IN  NS  ns.schiffbauer.net.
sys4.de.        3600    IN  NS  ns3.ray.net.
sys4.de.        3600    IN  RRSIG   NS 8 2 3600 20140531060906 20140523173232 42928 sys4.de. JlzFhcYRlqEnMEoBGvQ5Gnqjo2gpAMg0WanyQPd9c0pvrOe9x1tqneuQ lyKU9nD5+uGLVC2PY1VfKTSiSh44Ks3isdJjOOuK5zwKh8OYSWbMyvyt w9zRUKf9gTNTiZ9sa2QKzA2sLG67Y78YMEaT5qaubQznnkz76JLOeij2 5Fk=

;; ADDITIONAL SECTION:
ns.sys4.de.     3600    IN  A   194.126.158.143
ns.sys4.de.     3600    IN  RRSIG   A 8 3 3600 20140528102428 20140520213232 42928 sys4.de. gDnRltEHpBP318H4M1G09KYyIW5nUs5C3xTgzRMLt6LUHHEex7SZj7FS 8n+vWJQslzFdrC0JEBsk8HK3hFHJUljX0huJVYaTnfY+qm3zIgipYWDt c7exkdPqqMQZ86j+GMADNpYthrn9AL6Xm9QRNHuwU8pAiFgHNtIj/8La hEU=

;; Query time: 82 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 24 00:08:07 2014
;; MSG SIZE  rcvd: 640

Der entscheidende Hinweis, dass wir es in dieser DNS-Abfrage mit einer DNSSEC-signierten Domain zu tun haben, ist das ad-Flag in Zeile 8: flags: ... ad; Es besagt, Unbound hat es hier mit einer authenticated domain zu tun. Die Domain ist DNSSEC-signiert, und unbound konnte diese Tatsache ordentlich validieren.

Fehlt nur noch, den neuen Helfer ins tägliche Leben auf dem Server zu integrieren.

Important

Die Liste der Resolver sollte eine lückenlose Kette von DNSSEC-fähigen Resolvern bilden! Wenn nämlich die Validierung fehlschlägt (Angriff, MITM), dann meldet ein DNSSEC validierender Resolver SERVFAIL. Für den Stub-Resolver in der libc sieht das aber wie ein normaler Server-Fehler aus, und der nächste DNS-Resolver-Eintrag wird versucht. Validiert in der dann folgenden Kettenreaktion nur ein Resolver kein DNSSEC, wäre damit die gesamte DNSSEC-Sicherheit ausgehebelt.

Meine /etc/resolv.conf und auch die /var/spool/postfix/etc/resolv.conf sehen z.B. so aus:

search sys4.de
nameserver 127.0.0.1
nameserver 194.126.158.143
nameserver 188.40.110.137

Anschließend einmal Postfix durchstarten, und die Welt ist wieder ein wenig sicherer geworden. ;)

Patrick Koetter, 23. May 2014

   DNSSEC    Unbound    E-Mail    DNS