ADMIN
2021
06
2021-06-01T12:00:00
Storage-Management
PRAXIS
058
Security-Tipp
Sicherheit
Mit DNS Netzwerkdienste absichern
Im Auftrag der Sicherheit
von Dr. Matthias Wübbeling
Veröffentlicht in Ausgabe 06/2021 - PRAXIS
Das Domain Name System, kurz DNS, ist bekannt zur Namensauflösung im Internet. Neben der Zuordnung zu IP-Adressen unterstützt DNS aber auch die Absicherung von Netzwerkkommunikation mit den Servern innerhalb einer Domäne. Der Security-Tipp in diesem Monat zeigt Ihnen die Möglichkeiten, die DNS zur weiteren Absicherung bietet. Dabei stellen wir insbesondere die Einträge von SSH-Fingerabdrücken und der Certificate Authority Authorization vor.

Bereits im Jahr 1983 wurde das Domain Name System (DNS) spezifiziert. Die Funktionsweise von DNS machte die Verwendung einer lokal gepflegten HOSTS-Datei mit Einträgen zur Namensauflösung überflüssig und trug somit maßgeblich zum Erfolg des Internets bei.
Der dezentrale Ansatz zur Auflösung von Domänennamen in IP-Adressen begann, wie bei fast allen Protokollen des Internets, zunächst ohne Fokus auf Sicherheitsaspekte. Gut zehn Jahre später begannen die Arbeiten an den DNS Security Extensions (DNSSEC), die uns heute den Betrieb einer zuverlässigen und kryptografisch abgesicherten DNS-Infrastruktur erlauben.
Neben der sicheren Namensauflösung hat sich DNS als Universalprotokoll für die Absicherung von Netzwerkprotokollen etabliert. Der wohl bekannteste Einsatzzweck ist die sichere E-Mail-Kommunikation mittels Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) und der Kombination dieser beiden in Form von Domain-based Message Authentication, Reporting and Conformance (DMARC).
Bereits im Jahr 1983 wurde das Domain Name System (DNS) spezifiziert. Die Funktionsweise von DNS machte die Verwendung einer lokal gepflegten HOSTS-Datei mit Einträgen zur Namensauflösung überflüssig und trug somit maßgeblich zum Erfolg des Internets bei.
Der dezentrale Ansatz zur Auflösung von Domänennamen in IP-Adressen begann, wie bei fast allen Protokollen des Internets, zunächst ohne Fokus auf Sicherheitsaspekte. Gut zehn Jahre später begannen die Arbeiten an den DNS Security Extensions (DNSSEC), die uns heute den Betrieb einer zuverlässigen und kryptografisch abgesicherten DNS-Infrastruktur erlauben.
Neben der sicheren Namensauflösung hat sich DNS als Universalprotokoll für die Absicherung von Netzwerkprotokollen etabliert. Der wohl bekannteste Einsatzzweck ist die sichere E-Mail-Kommunikation mittels Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) und der Kombination dieser beiden in Form von Domain-based Message Authentication, Reporting and Conformance (DMARC).
SSH-Fingerprints prüfen
Vom ersten Aufbau einer SSH-Verbindung kennen Sie die Anzeige und die Überprüfung des Server-Fingerabdrucks. Obwohl hier aus Sicherheitsgründen eine zuverlässige Prüfung geboten ist, werden angezeigte Fingerprints häufig nur abgenickt. Hier können Sie als verantwortlicher Administrator dank SSH-Fingerprinting zuverlässig (SSHFP) Abhilfe schaffen. Beim Erzeugen der notwendigen DNS-Einträge für Ihren Server erhalten Sie mit dem Kommando
ssh-keygen -r hostname
eine Ausgabe an Hash-Werten. Die beiden Ziffern vor dem Fingerabdruck kodieren den Algorithmus und das genutzte Hash-Verfahren [1]. Dabei stehen die Ziffern 1 bis 4 an vorderer Stelle in aufsteigender Reihenfolge für RSA, DSA, ECDSA und Ed25519. Der Ziffer 5 ist bisher kein Algorithmus zugewiesen und die 6 steht für Ed448. Die Werte 1 und 2 an zweiter Stelle stehen für die Hash-Verfahren SHA-1 und SHA-256.
Die Abfrage der Fingerprints beim Verbindungsaufbau unterstützt OpenSSH beispielsweise seit Version 6.6 und führt den Abgleich automatisch durch, wenn Sie in der Konfigurationsdatei Ihres SSH-Clients, etwa in "~/.ssh/config", die folgende Option aktivieren:
VerifyHostKeyDNS yes
Alternativ können Sie bei jedem Verbindungsaufbau diese Option aktivieren, indem Sie etwa folgenden Befehl zum Verbindungsaufbau verwenden:
ssh -o VerifyHostKeyDNS=yes hostname
Damit gehört die manuelle Überprüfung der Fingerabdrücke beim ersten Verbindungsaufbau mit einem Server – unabhängig davon, wie zuverlässig Sie diese üblicherweise durchführen – der Vergangenheit an. Abfragen können Sie DNS-Einträge des Typs "SSHFP" beispielsweise mit dem folgenden Kommando:
dig hostname sshfp +dnssec +multi
Certificate Authority Authorization
Grundsätzlich kann jede Certificate Authority (CA) für jede Domain ein gültiges Zertifikat ausstellen, sofern Nutzer beziehungsweise deren Programme der CA vertrauen. Nicht immer jedoch überprüfen die CAs die Legitimität von Antragstellern, sodass sich Angreifer ein gültiges Zertifikat für eine Domain erschleichen können, für die sie überhaupt keine Berechtigungen besitzen.
Eine Möglichkeit, hier für mehr Sicherheit zu sorgen, ist die Certificate Authority Authorization (CAA). Über diesen DNS-Record legen Sie fest, welche CA für Ihre Domain Zertifikate ausstellen darf. Letztere sind verpflichtet, auf einen entsprechenden Eintrag hin zu prüfen, sollte ein Antrag auf Zertifikatsausstellung für eine Domain eingehen – und kein Zertifikat auszustellen, falls sie nicht auf der Liste stehen.
Das Verfahren wurde bereits im Jahr 2013 im RFC 6844 spezifiziert [2]. Dennoch ist der Einsatz nicht besonders verbreitet, obwohl spätestens seit der Unterstützung von Wildcard-Zertifikaten häufig nur noch eine CA zum Einsatz kommt und der Aufwand für die Pflege der zugehörigen CAA-Einträge damit überschaubar bleibt. Möchten Sie mehr als eine CA in Ihrem Unternehmen nutzen, legen Sie für jede Domain mehrere CAA-Einträge an. Aufgrund der hierarchischen Struktur von DNS lassen sich für Subdomains andere CAA-Settings verwenden als für die Hauptdomäne. Diese überschreiben dann entsprechend die Einträge der darüberliegenden Ebenen.
Ein CAA-Eintrag besteht aus drei Elementen: einem Bytewert zur Darstellung von Flags, gefolgt von einem Eigenschaftswert, der den Typ des Eintrags spezifiziert, und einer Zeichenkette, die etwa den Domainnamen der Zertifizierungsstelle enthält. Die aktuelle Spezifikation von CAA definiert lediglich einen möglichen Wert als Flag. Der Wert 128 bedeutet "critical" und hat heute noch keine praktische Bedeutung. Zukünftig sollen damit Einträge mit speziellen Eigenschaften markiert werden. Ist eine Markierung gesetzt, dürfen CAs keine Zertifikate ausstellen, wenn sie die angegebene Eigenschaft nicht interpretieren können.
Als Typ für einen CAA-Eintrag können Sie "issue", "issuewild" und "iodef" angeben. Die Werte "issue" und "issuewild" definieren als dritten Wert eine Zeichenkette mit dem Domänennamen der Zertifizierungsstelle. Die beiden Einträge unterscheiden sich dadurch, dass "issue" die Ausstellung eines Zertifikats für eine spezifische Domain und "issuewild" die Ausstellung eines Zertifikats für eine Wildcard-Subdomain kontrolliert. Dabei dürfen bei der Ausstellung von Wildcard-Zertifikaten die Einträge vom Typ "issue" nicht interpretiert werden. Im Gegenzug müssen bei der Ausstellung spezifischer Domainzertifikate die Einträge vom Typ "issuewild" außen vor bleiben.
Ein CAA-Eintrag für Ihre Domain, der lediglich den Einsatz von Let's Encrypt erlaubt, könnte wie folgt aussehen:
domainname.tld <TTL> CAA 0 issue "letsencrypt.org"
Möchten Sie zusätzlich die Ausstellung von Wildcard-Zertifikaten erlauben, fügen Sie einen zweiten Eintrag hinzu:
domainname.tld <TTL> CAA 0 issuewild "letsencrypt.org"
Um etwa das Ausstellen von Wildcard-Zertifikaten ausschließlich durch den Anbieter GlobalSign zu erlauben, ändern Sie den vorigen Eintrag entsprechend ab:
domainname.tld <TTL> CAA 0 issuewild "globalsign.com"
Alternativ können Sie durch die Angabe beider Einträge die Ausstellung von Wildcard-Zertifikaten für die CAs Let's Encrypt und GlobalSign gestatten.
Als dritten Typ unterstützen CAA-Einträge mit "iodef" die Angabe eines Kontakts bei Problemen oder Sicherheitsvorfällen. Hier können Sie etwa Web- oder E-Mail-Adressen angeben, damit Ihre Kommunikationspartner eine Möglichkeit zur Meldung von Vorfällen haben, zum Beispiel wenn diesen ein Zertifikat angeboten wird, das von einer nicht autorisierten Zertifizierungsstelle stammt. Hier sollten Sie eine abuse-Adresse angeben, wie in folgendem Eintrag:
domainname.tld <TTL> CAA 0 iodef "mailto:<abuse@domainname.tld>"
Möchten Sie für Ihre Domain die CAA-Einträge überprüfen, verwenden Sie das folgende Kommando:
dig CAA <domainname.tld>
Als Ergebnis erhalten Sie eine Ausgabe, die Sie über Ihre definierten Domains und Subdomains sowie die zugehörigen Zertifizierungsstellen informiert.
Fazit
Das Domain Name System hat sich seit seiner Einführung und der Entwicklung der DNS Security Extensions als ein zuverlässiges Protokoll für den Austausch sicherheitsrelevanter Informationen etabliert. Der Security-Tipp in diesem Monat hat Ihnen Anwendungsszenarien zum Schutz von SSH-Verbindungen mittels SSHFP-Einträgen und zur Absicherung der Zertifizierung von Domänennamen über CAA-Einträge vorgestellt. Mit wenigen Schritten sorgen Sie so für deutlich mehr Sicherheit.
(dr)