-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Hardening (Seite 5 von 5)

DMARC einrichten: Policy, Alignment und Reporting für deine Domain

30. November 2013 / / Keine Kommentare
DMARC-Einrichtung für eine Domain mit SPF, DKIM, Alignment, Policy-Stufen, Reporting und Beispiel-DNS-Record.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.

DMARC-Record aufbauen

DMARC wird als TXT-Record unter _dmarc.domain.de im DNS veröffentlicht. Ein Beispiel:

_dmarc.kernel-error.de.  IN TXT  "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de"

Die einzelnen Parameter:

v=DMARC1Protokollversion (immer DMARC1)
p=quarantinePolicy für die Hauptdomain (siehe unten)
sp=quarantinePolicy für Subdomains (optional, erbt sonst von p)
adkim=sDKIM-Alignment: s = strict, r = relaxed
aspf=sSPF-Alignment: s = strict, r = relaxed
pct=100Prozent der Mails, auf die die Policy angewendet wird
rua=mailto:...Adresse für aggregierte Berichte (täglich, XML)
ruf=mailto:...Adresse für forensische Berichte (pro Vorfall)

Alignment: Wofür DMARC wirklich da ist

SPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den From:-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im From:-Header passt.

Strict (s) bedeutet: Die Domains müssen exakt übereinstimmen. Relaxed (r) erlaubt auch Subdomains (z.B. mail.kernel-error.de passt zu kernel-error.de). Für die meisten Setups ist strict die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.

Policy-Stufen

Der p-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:

p=noneNur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
p=quarantineAls Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
p=rejectAblehnen. Die Mail wird gar nicht erst angenommen.

Der empfohlene Weg: Mit p=none anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf quarantine hochdrehen. Wenn auch das stabil läuft, auf reject gehen. Mit pct kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.

Reporting

Die aggregierten Reports (rua) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.

Die XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.

Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.

Cross-Domain-Reporting

Wer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für kernel-error.com an postmaster@kernel-error.de gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von kernel-error.de:

kernel-error.com._report._dmarc.kernel-error.de.  IN TXT  "v=DMARC1"

Dieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.

DMARC testen

# DMARC-Record abfragen
dig TXT _dmarc.kernel-error.de +short

Einen vollständigen Check inklusive SPF und DKIM bekommt man über mxtoolbox.com oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.

Das Zusammenspiel

DMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.

Unsichere Protokolle und Prüfsummen am Apache2 deaktivieren

9. November 2013 / / Keine Kommentare

Im Grunde könnte es mir ja fast egal sein, welche Protokollversion und/oder Prüfsumme der Client verwendet um mit dem Server zu sprechen. Ist es denn noch nicht. Der Client verbindet sich mit dem Server. Dabei teilt der Client dem Server mit was er kann, der Server tut dieses ebenfalls. Dann einigen sich beide auf ein Protokoll und eine Prüfsumme. Dabei kann der Server wie auch der Client sagen welches ihm denn am liebsten wäre. Wenn sich nun beide für etwas unsicheres entscheiden, gehen die Daten unsicher über die Leitung 🙁

Warum also nicht dem Server sagen er soll nur die „sicheren“ Protokolle anbieten? Dieses lässt sich recht schnell erledigen, indem man in seine Apache 2 Serverkonfiguration folgendes aufnimmt:

SSLProtocol -ALL +SSLv3 +TLSv1  
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT

Die einzelnen Optionen sind so schön benannt, dass man sich nicht mal mehr erklären muss, oder? Denn noch verlinke ich natürlich gerne hier hin: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Nachteile hat das ganze natürlich auch… Ältere Clients oder Systeme welche dummerweise kein passendes Protokoll / Chipher unterstützen, können keine verschlüsselte Verbindung mehr aufbauen. Meine Erfahrung zeigt aber, wenn man den Menschen die Möglichkeit gibt einfach durch die Sache zu kommen, machen sie es auch! Ich meine damit: „Solange es irgendwie funktioniert.“ Kümmert sich kaum jemand um ein Upgrade auch die Entwickler komme nicht aus dem Quark. Natürlich darf man nicht nach der Verabschiedung des neusten Standards die vorherigen fallen lassen…. Nur klar unsichere und seit Jahren überholte, die darf man dann schon mal los lassen (Windows XP *hust*).

Ach ja, möchte man einen Server testen gibt es mehrere Möglichkeiten. Am einfachsten ist sicher: https://www.ssllabs.com/ssldb/index.html Wer es lieber selbst auf der Konsole machen möchter, der freut sich sicher über sslscan http://sourceforge.net/project/showfiles.php?group_id=204329

 

 

 

Fragen? Einfach melden.

IPv6 ICMP Redirect erklärt: „rt6_redirect: source isn’t a valid nexthop“

24. Oktober 2013 / / Keine Kommentare

Man stolpert irgendwann über diese Meldung im Kernel-Log:

rt6_redirect: source isn't a valid nexthop for redirect target
Illustration eines IPv6-Netzwerks mit Kernel-Logmeldung „rt6_redirect: source isn't a valid nexthop for redirect target“. Ein ICMPv6-Redirect verweist fälschlich von einer Link-Local-Adresse auf eine globale IPv6-Adresse als Next Hop, was vom System abgelehnt wird.

Gerne im Zusammenhang mit IPv6, gerne dann, wenn man glaubt, eigentlich alles richtig gemacht zu haben. Routing stimmt. Neighbors sehen gut aus. Und trotzdem meckert der Kernel.

Die Kurzfassung: Der Linux-Kernel hat ein ICMPv6 Redirect bekommen und lehnt es ab, weil der vorgeschlagene Next Hop aus seiner Sicht kein gültiger First Hop ist.

Worum geht es überhaupt?

ICMPv6 Redirects (Typ 137) sind Teil von Neighbor Discovery. Ein Router sagt damit zu einem Host sinngemäß:

„Für dieses Ziel gibt es einen besseren ersten Hop als mich.“

Wichtig: erster Hop. Nicht irgendein Router irgendwo, sondern ein direkt erreichbarer Nachbar auf dem Link.

Ein Redirect enthält deshalb zwei zentrale Informationen:

  • das Target (Zieladresse, für die das Redirect gilt)
  • den Better Next Hop

Und jetzt kommt der Teil, den viele Implementierungen (und Admins) gerne unterschätzen:
Der Host muss diesem Vorschlag nicht glauben.

Was Linux hier tatsächlich prüft

Linux ist bei Redirects ziemlich streng. Zu Recht. Redirects sind ein beliebtes Einfallstor für Unsinn und Angriffe.

Bevor der Kernel ein Redirect akzeptiert, prüft er u. a.:

  • stammt das Redirect von einem Router, den ich bereits als Router kenne?
  • liegt der vorgeschlagene Next Hop auf demselben Link?
  • ist dieser Next Hop als Neighbor bekannt bzw. grundsätzlich auflösbar?
  • passt das Ganze zur bestehenden Routing-Entscheidung?

Und genau hier schlägt diese Logmeldung zu.

Der Kernel schaut auf den Better Next Hop im Redirect und stellt fest:

„Diese Adresse kann für dieses Ziel kein gültiger Next Hop sein.“

Dann wird das Redirect verworfen. Keine neue Route. Kein Update. Nur diese Meldung.

Der Klassiker: Global statt Link-Local

In der Praxis sieht man das oft in Setups, in denen Router ihre Default-Route oder interne Routen nicht sauber über Link-Local-Adressen aufbauen.

Beispiel (vereinfacht):

default via 2001:db8:1::1 dev eth0

Sieht harmlos aus. Funktioniert auch meistens. Aber:
IPv6 erwartet, dass Router auf einem Link über ihre Link-Local-Adresse angesprochen werden.

Korrekt wäre also eher:

default via fe80::1 dev eth0

Was passiert nun?

Der Router verschickt ein Redirect und trägt als „Better Next Hop“ seine globale Adresse ein (z. B. 2001:db8:1::1).
Der Host bekommt das Redirect, prüft es – und sagt:

„Moment. Dieser Next Hop ist kein gültiger direkt erreichbarer Neighbor für dieses Ziel.“

Und genau dann landet diese Meldung im Log.

Wichtig:
Das Problem ist nicht primär, dass die Adresse global ist.
Das Problem ist, dass der Kernel den vorgeschlagenen Next Hop nicht als legitimen First Hop auf diesem Link akzeptiert.

Link-Local ist der Normalfall. Alles andere muss extrem gut begründet sein – und ist es fast nie.

Ein Blick auf die Nachbartabelle hilft

Wenn man wissen will, warum der Kernel das Redirect ablehnt, lohnt sich ein Blick in die Neighbor-Daten:

ip -6 neigh show

Oder gezielter:

ip -6 route get 2001:db8:dead:beef::1

Wenn der vorgeschlagene Next Hop dort nicht als sinnvoller Neighbor auftaucht, ist die Sache im Prinzip entschieden.
Kein Neighbor → kein gültiger Next Hop → Redirect wird verworfen.

Das Redirect live mitschneiden

Wenn man genau wissen will, ob der Router wirklich ein Redirect schickt und was er als Next Hop vorschlägt, hilft tcpdump. ICMPv6 Typ 137 ist das Redirect:

tcpdump -n -i eth0 'icmp6 and ip6[40] == 137'

Im Paket sieht man den Router als Absender, das Target (Ziel, für das der Hinweis gilt) und den Better Next Hop. Passt der Next Hop nicht zu einem gültigen Neighbor auf dem Link, ist klar warum der Kernel ablehnt.

Ebenfalls nützlich: ob der Host Redirects überhaupt annehmen will.

sysctl net.ipv6.conf.all.accept_redirects
sysctl net.ipv6.conf.eth0.accept_redirects

Default ist 1 auf einem Host, 0 auf einem Router. Zusätzlich greift secure_redirects (Default 1): nur Redirects von bereits bekannten Gateways werden überhaupt akzeptiert.

Default-Route mit Link-Local als Next Hop

Wer die Route selbst setzt (statische Konfiguration ohne RA), sollte Link-Local nehmen. Link-Local ist pro Interface nicht eindeutig, der Eintrag braucht also immer ein dev:

ip -6 route add default via fe80::1 dev eth0

Persistenz hängt vom System ab. systemd-networkd in /etc/systemd/network/*.network unter [Route] Gateway=fe80::1, netplan in /etc/netplan/*.yaml, die klassische /etc/network/interfaces kennt post-up ip -6 route .... Wichtig: das Interface muss im Eintrag stehen.

Mit Link-Local als Next Hop verschwindet die rt6_redirect-Meldung in der Regel. Der Kernel hat einen gültigen First Hop als Neighbor, und ein Redirect desselben Routers passt dann sauber ins Modell.

Oder: Redirects abschalten

Auf Servern in kontrollierten Hosting-Umgebungen (Hetzner, Netcup, Cloud-VPCs) ist das Routing sauber vorgegeben, und der Provider-Router hat keinen besseren Next Hop anzubieten. Dann sind ICMPv6-Redirects nur Rauschen im Log:

sysctl -w net.ipv6.conf.all.accept_redirects=0
sysctl -w net.ipv6.conf.default.accept_redirects=0

Persistent in /etc/sysctl.d/99-ipv6.conf. Nachteil: kennt der Router tatsächlich einen legitimen besseren Weg, bleibt der Host trotzdem bei seiner existierenden Route. Im Rechenzentrum mit einer einzigen Default-Route ist das genau richtig, in einem verzweigten Firmennetz mit mehreren Uplinks eher nicht.

Warum das kein Bug ist

Die Meldung klingt erstmal nach kaputtem Routing. Ist es aber meistens nicht.

Im Gegenteil:
Der Kernel verhält sich exakt so, wie es das Protokoll vorsieht. Redirects sind Hinweise, keine Befehle. Und Linux nimmt diese Hinweise nur an, wenn sie sauber in das bestehende Neighbor- und Routing-Modell passen.

Das schützt unter anderem vor:

  • falschen Router-Konfigurationen
  • kaputten RA-Setups
  • Bridge-/VM-Konstrukten mit „kreativem“ IPv6
  • trivialen Redirect-Spoofing-Angriffen

Update 2026: was heute anders ist

In modernen Setups begegnet einem die Meldung seltener. Nicht weil das Protokoll sich geändert hätte, sondern weil die Umgebung drumherum sauberer geworden ist:

  • Enterprise-Switches mit RA Guard und ND Inspection filtern unerwünschte RAs und Redirects bereits auf Layer 2 heraus. Cisco, Juniper und andere haben das seit Jahren im Portfolio.
  • Cloud-Umgebungen (AWS VPC, Hetzner Cloud, Azure) liefern ein sauber vorgegebenes Default-Gateway aus, in der Regel ein Link-Local-Hop. Redirects tauchen praktisch nie auf.
  • Home-Router (FritzBox, Unifi, OpenWrt) machen es per Default richtig.
  • SEND/CGA (RFC 3971) hätte kryptografisch signierte Neighbor Discovery gebracht und Redirect-Spoofing strukturell verhindert. Die Adoption ist praktisch bei null geblieben. Tot.

Übrig bleibt die Meldung heute fast nur in selbstgebauten VM- und Container-Setups, in denen Host- und Gast-Routing nicht sauber zusammenpassen, oder wenn in statischer Konfiguration aus Gewohnheit eine globale Adresse als Next Hop gesetzt wird.

Fazit

Die Meldung

rt6_redirect: source isn't a valid nexthop for redirect target

bedeutet nicht „IPv6 kaputt“.
Sie bedeutet: Ein Router hat ein Redirect geschickt, das aus Sicht des Hosts keinen gültigen Next Hop beschreibt.

In der Praxis ist das fast immer ein Hinweis auf:

  • Default- oder interne Routen ohne Link-Local-Next-Hop (siehe auch IPv6 ULA und Adresspriorisierung)
  • Router, die globale Adressen in Redirects verwenden
  • Setups, in denen Neighbor Discovery und Routing nicht sauber zusammenpassen

Oder anders gesagt:
Der Kernel ist hier nicht pingelig. Er ist vorsichtig. Und das ist gut so.

Siehe auch: IPv6 Grundlagen. Zum Nachlesen: RFC 4861 §8 (Redirect-Handling bei Hosts) und RFC 6980 (fragmentiertes Neighbor Discovery ist verboten — ein harter Security-Fix für ND-Spoofing).

Fragen? Einfach melden.

DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern

10. August 2013 / / Keine Kommentare

Meine Domain ist per DNSSEC gesichert, der Webserver bietet TLS an. Mit DANE (DNS-based Authentication of Named Entities) lässt sich beides verbinden: Die Checksumme des TLS-Zertifikats wird als TLSA-Record im DNS veröffentlicht — DNSSEC schützt diesen Record vor Manipulation.

Warum DANE?

Das klassische CA-System hat ein grundsätzliches Problem: Jede der hunderten Certificate Authorities kann ein Zertifikat für jede Domain ausstellen. Wird eine CA kompromittiert oder handelt fahrlässig, können gefälschte Zertifikate im Umlauf sein — der Browser merkt nichts. DANE löst das, indem der Domaininhaber selbst festlegt, welches Zertifikat gültig ist. Der Hash steht im DNS, DNSSEC garantiert die Integrität. Keine CA kann das unterlaufen.

Unterstützt ein Client DANE, prüft er beim TLS-Handshake, ob der TLSA-Record zum angebotenen Zertifikat passt. Das funktioniert auch mit selbstsignierten Zertifikaten — solange der Hash stimmt und DNSSEC aktiv ist, wird dem Zertifikat vertraut. Die Spezifikation steht in RFC 6698.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des Public Keys (SPKI) aus dem Zertifikat. Mit OpenSSL erzeugt:

openssl x509 -in server.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein. Für den Webserver (Port 443):

_443._tcp.www.kernel-error.de. 3600 IN TLSA 3 1 1 a321...f7

Die drei Zahlen 3 1 1 bedeuten:

  • 3 — DANE-EE (End Entity): Das Zertifikat wird direkt geprüft, kein CA-Vertrauen nötig
  • 1 — SPKI (Subject Public Key Info): Nur der Public Key wird gehasht, nicht das ganze Zertifikat. Vorteil: Bei Erneuerung mit demselben Key bleibt der TLSA-Record gültig
  • 1 — SHA-256 als Hash-Algorithmus

Der TTL von 3600 Sekunden ist bewusst kurz gewählt — bei einem Zertifikatswechsel mit neuem Key soll der alte Record schnell ablaufen.

Prüfen

Mit dig lässt sich der TLSA-Record abfragen:

dig TLSA _443._tcp.www.kernel-error.de +short
3 1 1 a321...f7

Ob der Record auch zum tatsächlich ausgelieferten Zertifikat passt, prüft man mit OpenSSL — Hash vom Server-Zertifikat erzeugen und mit dem DNS-Record vergleichen:

echo | openssl s_client -connect www.kernel-error.de:443 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Stimmen die Hashes überein, ist alles korrekt. Komfortabler geht es mit posttls-finger (Teil von Postfix) — das Tool prüft TLSA-Record und Zertifikat in einem Schritt.

DANE für E-Mail

DANE funktioniert nicht nur für Webserver. Für E-Mail ist es sogar wichtiger — SMTP hat kein Vertrauensmodell wie Browser, opportunistisches TLS kann trivial per Downgrade-Angriff ausgehebelt werden. Mit DANE und TLSA-Records auf Port 25 wird die Verschlüsselung kryptographisch verifizierbar. Wie man das mit Postfix einrichtet, steht im Beitrag Postfix mit DANE und DNSSEC absichern. Zur Visualisierung des DANE-Anteils im Mailverkehr habe ich damals Mailgraph um DANE-Graphen erweitert.

Siehe auch: DNSSEC einrichten

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

25. September 2012 / / Keine Kommentare

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

SSH Host Keys per SSHFP im DNS veröffentlichen

27. Mai 2012 / / Keine Kommentare
SSH-Host-Key-Prüfung per SSHFP im DNS mit DNSSEC-validiertem Fingerprint, OpenSSH-Client, Server-Host-Key und Schutz vor Man-in-the-Middle-Angriffen.

OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.

Client konfigurieren

Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:

VerifyHostKeyDNS yes

Oder nur für die aktuelle Sitzung:

ssh -o "VerifyHostKeyDNS=yes" server.example.de

SSHFP-Records erzeugen

Am einfachsten direkt auf dem Server mit ssh-keygen, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:

ssh-keygen -r server.example.de.

Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):

server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...
server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...
server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...
server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...

Aufbau des SSHFP-Records

Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:

hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]

Algorithmus:

  • 1, RSA
  • 3, ECDSA
  • 4, Ed25519 (empfohlen, ab OpenSSH 6.7)

DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.

Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.

Prüfen

Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:

dig +short server.example.de SSHFP
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3...
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
4 2 D4E5F6A7B8C9...

Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein, sonst ist die Antwort nicht vertrauenswürdig:

dig +dnssec server.example.de SSHFP | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

Verbindungsaufbau mit SSHFP

Ohne SSHFP-Records im DNS meldet OpenSSH:

DNS lookup error: data does not exist
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Mit SSHFP-Records und DNSSEC:

debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure, der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.

Strenge Prüfung erzwingen

Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:

Host *
    VerifyHostKeyDNS yes
    StrictHostKeyChecking yes

Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.

Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑