Signierte Namensauflösung mit DNS

Beglaubigt

Mit DNS-Cache-Poisoning kann ein Webbrowser auf eine manipulierte Website geleitet werden. Die digitale Signatur von DNS-Einträgen soll das verhindern. Dieser Artikel erklärt, wie man DNSSEC im eigenen Netz implementiert. Darüber hinaus stellt er die neuen Möglichkeiten zur Verwaltung signierter Zonen vor, die ISC BIND ab der Version 9.7 bietet.
Mit E-Mail-Diensten muss sich jeder Administrator früher oder später einmal beschäftigen. Das zur CeBIT erscheinende ADMIN 02/2012 gibt dazu Praxis-Tipps und ... (mehr)

Das Domain Name System (DNS) ist eines der zentralen Konzepte des Internets, gleichzeitig aber auch eines der ältesten. Deshalb enthält es keine sicheren Mechanismen, die sicherstellen, dass die Auflösung eines DNS-Namens zur korrekten IP-Adresse führt. Mittels Cache-Poisoning besteht die Möglichkeit, dem auflösenden Client eine falsche IP-Adresse unterzuschieben, was sich für diverse Angriffe ausnutzen lässt. Nicht nur die Kompromittierung von PINs und TANs im Online-Banking, sondern auch der automatische Download von Schadsoftware von manipulierten Webseiten sind Gefahren, die daraus resultieren.

Schutz hiervor bietet DNSSEC. Die "DNS Security Extensions" sollen die Authentizität (Herkunft) und Integrität (Unveränderlichkeit) von DNS-Daten sicherstellen. In der Vergangenheit standen gewichtige Gründe einer flächendeckenden Einführung von DNSSEC entgegen. Insbesondere politische Uneinigkeit hinsichtlich der Signatur der Root-Zone, die höhere Auslastung der DNS-Server durch die kryptografischen Algorithmen und die Gefahr des sogenannten Zone Walking, des systematischen Auslesens der Zoneneinträge, führten zu breiter Skepsis und einer zögerlichen Einführung von DNSSEC.

Die DNS-Rootzone ist seit dem 15. Juli 2010 digital signiert. Labortests des RIPE [1] zeigen, dass die Mehrbelastung der DNS-Server mit signierten Zonen in einem akzeptablen Rahmen bleibt. Das früher oft kritisierte Zone Walking ist mit den NSEC3-Resource Records nun nicht mehr möglich. Der flächendeckenden Einführung von DNSSEC steht also nichts mehr im Weg.

Der Berkley Internet Name Daemon (ISC BIND) ist der mit Abstand am häufigsten eingesetzte DNS-Server im Internet. Mit der Version 9.7 führt BIND das sogenannte "DNSSEC for Humans" ein, um die Verwaltung signierter Zonen noch weiter zu vereinfachen. Damit wird es möglich, Zonen automatisch aktuell zu halten und auch dynamisches DNS mit geringem Verwaltungsaufwand zu betreiben.

Wer vertraut wem?

Ein Zonefile besteht hauptsächlich aus Ressource Records (RRs). Sie enthalten entweder Verwaltungsinformationen (zum Beispiel SOA, Start of Authority), die Auflösung von Namen in IP-Adressen und umgekehrt (A und PTR) oder spezielle Informationen wie Mailserver-Einträge (MX) oder Aliase (CNAME). Die RRs werden auf Anfrage dem Client übermittelt. Jeder RR einer mit DNSSEC gesicherten Zone ist digital signiert, wobei DNSSEC mit asymmetrischen Schlüsselpaaren arbeitet, also mit einem öffentlichen Schlüssel (Public Key) und einem dazugehörigen privaten Schlüssel (Private Key).

Das Prinzip ist das gleiche wie bei X.509-basierten Zertifikats-Infrastrukturen. Es gibt in der Hierarchie immer einen obersten Punkt, ein sogenannter Secure Entry Point (SEP), auch Trust Anchor genannt. Diesem vertraut der Client. Bei Zertifikats-Infrastrukturen ist dies die Root-CA, bei DNSSEC könnte es zum Beispiel die Root-DNS-Zone sein, aber auch jede darunterliegende Domain-Ebene. Über eine sogenannte Chain-of-Trust wird das Vertrauen vererbt. Damit kann ein DNS-Client auch der Antwort eines DNS-Servers vertrauen, der in der Hierarchie weiter unten liegt, ohne dessen Public Key direkt als vertrauenswürdig einzustufen.

Ein Autogramm bitte!

Digitale Signaturen basieren auf asymmetrischer Verschlüsselung, wobei ein solcher Schlüssel immer aus zwei Teilen besteht: dem Public und dem Private Key. Nur der Private Key bleibt geheim, während der Public Key veröffentlicht werden kann. Eine beliebige Zeichenkette, die mit dem einen Schlüsselteil verschlüsselt wurde, kann ausschließlich mit dem dazugehörigen anderen Schlüsselteil wieder entschlüsselt werden. Damit wird eine digitale Unterschrift (sprich: Signatur) möglich.

Vereinfacht gesagt basiert die Signatur auf der Verschlüsselung einer beiden Seiten bekannten Zeichenkette (zum Beispiel dem Namen des Unterzeichnenden, etwa "Eric Amberg") durch seinen Private Key. Der Empfänger benötigt nun den Public Key des Signierenden. Nur der dazu passende Public Key kann die verschlüsselte Zeichenkette wieder richtig entschlüsseln, sodass der Klartext "Eric Amberg" herauskommt. Da der Private Key nur dem Inhaber bekannt sein kann, ist damit die Authentizität sichergestellt – sofern man dem Public Key des Signierenden vertraut. Somit wird dieser im DNS-Client dann auch als "Trusted Key" eingefügt. Ergänzt man dieses Prinzip durch signierte Hashwerte (etwas MD5 oder SHA-1), die für eine definierte Zeichenkette eine Art Fingerabdruck darstellen, kann dadurch zusätzlich die Integrität der Nachricht sichergestellt werden.

comments powered by Disqus

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018