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)

I am walking …

Ein zusätzlicher Faktor, der die Datei extrem aufbläht, sind die NSEC-Einträge, die ihrerseits ebenfalls signiert werden müssen. Diese Einträge dienen dazu, das Nicht-Vorhandensein von Einträgen zu beweisen. Hierzu werden die Zoneneinträge intern alphanumerisch sortiert. Jeder NSEC-Eintrag gehört zu einem normalen RR und zeigt auf den nachfolgenden normalen RR. Der NSEC-Eintrag von »ns.avc.local« zeigt im Beispiel auf »www.avc.local« , da dieser an nächster Stelle folgt. Der NSEC-RR des letzten Eintrags (hier: »www.avc.local« ) zeigt auf die Zone selbst, also »avc.local« . Damit schließt sich der Kreis. Fragt ein Resolver zum Beispiel nach dem Eintrag »server1.avc.local« , teilt der Server ihm die Nicht-Existenz durch einen NSEC-Eintrag mit, der für »ns.avc.local« als nächstfolgenden Eintrag »www.avc.local« enthält.

Dieses Konzept führt jedoch zu dem Problem, dass ein Angreifer durch geschickte Abfragen der Zone sämtliche Einträge einer Zone systematisch auslesen kann. Dieses sogenannte Zone Walking lässt sich durch NSEC3 unterbinden [2] . Dieser RR führt den Vorgänger- und Nachfolger-Eintrag nicht im Klartext, sondern als Hashwert. Ein direktes Auslesen der Einträge ist somit nicht mehr möglich. Wurden die Zonenschlüssel KSK und ZSK mit dem Algorithmus NSEC3RSASHA1 erstellt, kann die Zone jederzeit mit NSEC3 signiert werden. Hierzu ist die Option »-3 -« notwendig, wobei der Administrator statt des »-« auch ein zwei Bytes langes Salt angeben kann, um die Sicherheit zu erhöhen. Im einfachsten Fall realisiert er die Signatur mit NSEC3 folgendermaßen:

dnssec-signzone -3 - -o avc.local db.avc.local

Der Trust Anchor

Die Konfiguration des Servers ist nur die eine Seite der Medaille. Natürlich müssen die Resolver ebenfalls angepasst werden, um mit DNSSEC richtig umgehen zu können, in diesem Fall also der eigene DNS-Server. Dazu müssen zum einen in der Konfigurationsdatei »named.conf« DNSSEC aktiviert werden, zum anderen ist es notwendig, den Trust Anchor beziehungsweise Secure Entry Point in Form des KSKs einzubinden.

Im einfachsten Fall wird der KSK der Zone »avc.local« selbst genutzt. Hierzu kopiert der Administrator die entsprechende Datei, die den Public Key des KSK enthält, in diesem Beispiel »Kavc.local.+007+41799.key« , auf den Resolver. Hier steht der KSK in einem »trusted-keys« -Statement in der Datei »named.conf« :

trusted-keys {
 avc.local. 257 3 7 "AwEAAdyIn[...]8Uwg=";
};

Das Trusted-Keys-Statement enthält eine Zeile, die bis auf den Passus »IN DNSKEY« der Form eines DNSKEY-RRs entspricht. Darüber hinaus muss der Schlüssel in Anführungszeichen stehen. Nach dem Neustart des Servers kann dieser in seiner Eigenschaft als DNSSEC-fähiger Resolver DNSSEC-Antworten der Zone »avc.local« validieren. In der Realität ist es allerdings sinnvoll, den Public Key des KSK der Root-Zone als Trusted Key einzubinden. Dieser lässt sich inklusive der »trusted-key« -Direktive unter [3] herunterladen, oder über den folgenden Befehl abfragen:

dig +dnssec . dnskey
comments powered by Disqus
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

Ausgabe /2023