-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Kategorie: Self-Hosting & Infrastruktur (Seite 1 von 10)

SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken das Problem nicht löst

7. Januar 2026 / / 2 Kommentare

Aus gegebenem Anlass möchte ich ein paar Gedanken zu DigitalOcean aufschreiben. Nicht, weil ich glaube, dass DigitalOcean ein grundsätzliches Problem hat oder etwas falsch macht. Sondern weil DigitalOcean in meinen Logs seit Jahren besonders auffällt. Am Ende steht DigitalOcean hier eher sinnbildlich für ein größeres Thema.

Wer Systeme im Internet betreibt, kennt das Spiel. Server werden dauerhaft von außen angefasst. SSH-Ports werden gescannt, Login-Versuche laufen durch, Webseiten bekommen Requests auf bekannte Pfade, WordPress-Logins, XML-RPC, das volle Programm. Das ist kein gezielter Angriff, sondern automatisiertes Dauerrauschen. Bots, Skripte, Scanner, manchmal Security-Tools, manchmal schlicht schlecht konfigurierte Kisten.

Darstellung von automatisierten SSH-Bruteforce-Angriffen und Server-Härtung in Cloud-Umgebungen

Findet so ein Bot irgendwo ein offenes Loch, einen Standard-Login, ein vergessenes Passwort oder eine ungepatchte Schwachstelle, dann geht es weiter. Meistens wird erst einmal weitere Software nachgeladen. Der Host wird Teil eines Botnetzes, scannt selbst weiter, verteilt Spam, nimmt an DDoS-Aktionen teil oder schürft Kryptowährungen. Nichts davon ist neu, nichts davon ist überraschend.

Was mir allerdings seit mindestens vier Jahren auffällt: Ein sehr großer Teil dieser Brute-Force-Versuche, insbesondere auf SSH, kommt bei mir aus Netzen von DigitalOcean. Nicht ein bisschen mehr, sondern konstant irgendwo im Bereich von achtzig bis neunzig Prozent. Über Jahre. Über verschiedene Systeme hinweg.

Der erste Reflex liegt nahe. Wenn so viel aus einem Netz kommt, warum blockt man dann nicht einfach alle Netze dieses Anbieters? Dann ist Ruhe. Und wenn das alle machen würden, müsste der Anbieter ja reagieren. Der Gedanke ist verständlich. Ich hatte ihn selbst. Er ist aber aus meiner Sicht der falsche.

Ein pauschales Blocken ist im Grunde nichts anderes als eine Decke über das eigentliche Problem zu werfen. Das Problem ist damit nicht weg, es ist nur woanders. Die Bots wechseln dann eben zum nächsten Cloud-Provider. Außerdem produziert man sich damit ganz eigene Probleme. DigitalOcean-Netze komplett zu sperren heißt auch, legitimen Traffic auszusperren. APIs, Dienste, Kunden, Monitoring, externe Abhängigkeiten. Je nach Setup schneidet man sich damit schneller ins eigene Fleisch, als einem lieb ist.

Relativ schnell landet man dann bei Reputation-Diensten wie AbuseIPDB. Dort melden Betreiber IPs, von denen Scans, Brute-Force-Versuche oder andere Auffälligkeiten ausgehen. Auch ich melde dort seit Jahren IPs, automatisiert und manuell. Formal funktioniert das gut. IPs bekommen Scores, werden gelistet, tauchen in Datenbanken auf.

Das Problem ist nur: Diese Systeme arbeiten IP-basiert. Und genau das passt schlecht zur Realität moderner Netze. In Cloud-Umgebungen sind IPs kurzlebig. Heute gehört sie einem kompromittierten Host, morgen einem völlig legitimen Kunden. Ein hoher Abuse-Score sagt wenig über den aktuellen Nutzer dieser IP aus. Reputation ist träge, Infrastruktur ist schnell.

Jan  6 22:58:08 honeypot03 sshd-session[61904]: Invalid user sonar from 64.23.228.101 port 38610
Jan  6 22:58:08 honeypot03 sshd-session[61904]: Connection closed by invalid user sonar 64.23.228.101 port 38610 [preauth]
Jan  6 23:02:13 honeypot03 sshd-session[62101]: Invalid user sonar from 64.23.228.101 port 38174
Jan  6 23:02:13 honeypot03 sshd-session[62101]: Connection closed by invalid user sonar 64.23.228.101 port 38174 [preauth]
Jan  6 23:06:12 honeypot03 sshd-session[62175]: Invalid user sonar from 64.23.228.101 port 35952
Jan  6 23:06:12 honeypot03 sshd-session[62175]: Connection closed by invalid user sonar 64.23.228.101 port 35952 [preauth]
Jan  6 23:10:10 honeypot03 sshd-session[62248]: Invalid user steam from 64.23.228.101 port 38236
Jan  6 23:10:10 honeypot03 sshd-session[62248]: Connection closed by invalid user steam 64.23.228.101 port 38236 [preauth]
Jan  6 23:14:17 honeypot03 sshd-session[62335]: Invalid user steam from 64.23.228.101 port 35952
Jan  6 23:14:18 honeypot03 sshd-session[62335]: Connection closed by invalid user steam 64.23.228.101 port 35952 [preauth]
Jan  6 23:18:22 honeypot03 sshd-session[62455]: Invalid user steam from 64.23.228.101 port 50096
Jan  6 23:18:22 honeypot03 sshd-session[62455]: Connection closed by invalid user steam 64.23.228.101 port 50096 [preauth]
Jan  6 23:22:24 honeypot03 sshd-session[62599]: Invalid user sugi from 64.23.228.101 port 53212
Jan  6 23:22:25 honeypot03 sshd-session[62599]: Connection closed by invalid user sugi 64.23.228.101 port 53212 [preauth]
Jan  6 23:26:26 honeypot03 sshd-session[62671]: Invalid user svnuser from 64.23.228.101 port 44820
Jan  6 23:26:26 honeypot03 sshd-session[62671]: Connection closed by invalid user svnuser 64.23.228.101 port 44820 [preauth]
Jan  6 23:30:26 honeypot03 sshd-session[62763]: Invalid user svnuser from 64.23.228.101 port 52156
Jan  6 23:30:27 honeypot03 sshd-session[62763]: Connection closed by invalid user svnuser 64.23.228.101 port 52156 [preauth]
Jan  6 23:34:30 honeypot03 sshd-session[62867]: Invalid user taryn from 64.23.228.101 port 54128
Jan  6 23:34:31 honeypot03 sshd-session[62867]: Connection closed by invalid user taryn 64.23.228.101 port 54128 [preauth]
Jan  6 23:38:41 honeypot03 sshd-session[62939]: Invalid user taryn from 64.23.228.101 port 39894
Jan  6 23:38:42 honeypot03 sshd-session[62939]: Connection closed by invalid user taryn 64.23.228.101 port 39894 [preauth]
Jan  6 23:42:44 honeypot03 sshd-session[63013]: Invalid user taryn from 64.23.228.101 port 57728
Jan  6 23:42:45 honeypot03 sshd-session[63013]: Connection closed by invalid user taryn 64.23.228.101 port 57728 [preauth]
Jan  6 23:46:45 honeypot03 sshd-session[63160]: Invalid user taryn from 64.23.228.101 port 38438
Jan  6 23:46:45 honeypot03 sshd-session[63160]: Connection closed by invalid user taryn 64.23.228.101 port 38438 [preauth]
Jan  6 23:50:49 honeypot03 sshd-session[63252]: Invalid user taryn from 64.23.228.101 port 54070
Jan  6 23:50:49 honeypot03 sshd-session[63252]: Connection closed by invalid user taryn 64.23.228.101 port 54070 [preauth]
Jan  6 23:54:55 honeypot03 sshd-session[63354]: Invalid user terrance from 64.23.228.101 port 57960
Jan  6 23:54:55 honeypot03 sshd-session[63354]: Connection closed by invalid user terrance 64.23.228.101 port 57960 [preauth]
Jan  6 23:59:05 honeypot03 sshd-session[63472]: Invalid user terrance from 64.23.228.101 port 47558
Jan  6 23:59:05 honeypot03 sshd-session[63472]: Connection closed by invalid user terrance 64.23.228.101 port 47558 [preauth]
Jan  7 00:03:11 honeypot03 sshd-session[64731]: Invalid user terrance from 64.23.228.101 port 42938
Jan  7 00:03:11 honeypot03 sshd-session[64731]: Connection closed by invalid user terrance 64.23.228.101 port 42938 [preauth]

Damit erklärt sich auch, warum Provider solche externen Feeds nicht einfach hart umsetzen. Würde man IPs automatisiert abschalten, nur weil sie in einer Datenbank schlecht bewertet sind, träfe man regelmäßig Unbeteiligte. False Positives wären vorprogrammiert. Rechtlich, operativ und wirtschaftlich ist das für Provider kaum tragbar.

Warum also fällt DigitalOcean so stark auf? Das kann ich nicht belegen, nur einordnen. DigitalOcean ist günstig, schnell, einfach. In wenigen Minuten hat man dort eine VM mit öffentlicher IP. Das ist für legitime Nutzer attraktiv, aber eben auch für Leute mit schlechten Absichten. Wenn Infrastruktur billig und niedrigschwellig ist, taucht sie zwangsläufig häufiger in Logs auf. Dazu kommt, dass viele Systeme dort von Menschen betrieben werden, die vielleicht noch nicht so tief im Thema Security stecken. Offene Dienste, schwache Konfigurationen, fehlendes Hardening – all das macht solche Hosts wiederum zu guten Kandidaten für Kompromittierung und Weiterverwendung.

Wichtig dabei: DigitalOcean selbst macht aus meiner Sicht nichts grundlegend falsch. Der Abuse-Prozess funktioniert. Meldungen lassen sich automatisiert einreichen, werden angenommen, werden beantwortet, werden bearbeitet. Ich habe das über Jahre hinweg genutzt, sowohl manuell als auch automatisiert. Das ist sauber umgesetzt.

Was sich dadurch aber nicht ändert, ist die Menge der Versuche. Die wird nicht weniger. Sie bleibt konstant. Einzelne Hosts verschwinden, neue tauchen auf. Abuse-Meldungen – egal ob direkt beim Provider oder über Plattformen wie AbuseIPDB – wirken immer nur lokal und zeitverzögert. Gegen ein strukturelles Phänomen kommen sie nicht an.

Aus Sicht eines Providers ist das auch logisch. Ein paar tausend fehlgeschlagene SSH-Logins sind kein Incident. Kein DDoS, kein Ausfall, kein messbarer Schaden. Das fällt unter Hintergrundrauschen. Niemand bezahlt dafür, dieses Rauschen global zu eliminieren. Und ehrlich gesagt: Das kann auch niemand realistisch leisten.

Die eigentliche Konsequenz daraus ist unbequem, aber klar. Man darf nicht erwarten, dass Provider oder Reputation-Datenbanken einem dieses Problem abnehmen. Scan- und Brute-Force-Traffic gehört heute zum Betrieb eines öffentlich erreichbaren Systems dazu. Die einzige Stelle, an der man sinnvoll ansetzen kann, ist das eigene Setup.

Saubere Konfiguration. Keine Passwort-Logins per SSH. Kein Root-Login. Rate-Limits. Monitoring, das zwischen Rauschen und echten Zustandsänderungen unterscheidet. Fail2Ban als Dämpfer, nicht als Illusion von Sicherheit. Und vor allem: Gelassenheit gegenüber Logs, die voll sind, aber nichts bedeuten.

DigitalOcean ist hier nicht der Feind. AbuseIPDB ist kein Allheilmittel. Beides sind sichtbare Teile eines größeren Bildes. Das eigentliche Thema ist, wie man Systeme so betreibt, dass dieses Hintergrundrauschen irrelevant wird.

BIND auf FreeBSD: DoT & DoH einrichten mit Views, IP‑Trennung und Testplan für IPv4/IPv6.

3. Januar 2026 / / 3 Kommentare

Wofür braucht man noch gleich DoT oder DoH?

Nun, wenn du eine Internetadresse eingibst, muss dein Gerät zuerst herausfinden, zu welchem Server diese Adresse gehört. Diese Nachfragen heißen DNS. Lange Zeit liefen sie unverschlüsselt durchs Netz, vergleichbar mit einer Postkarte. Jeder, der den Datenverkehr sehen konnte, wusste dadurch sehr genau, welche Webseiten aufgerufen werden, und konnte die Antworten sogar manipulieren.

Beitragsgrafik zu BIND 9.20 auf FreeBSD 15: schematische Trennung von autoritativem DNS und rekursivem Resolver. Links ein Authoritative-DNS-Server mit deaktivierter Rekursion und blockiertem UDP/53, rechts ein Resolver, der ausschließlich DNS over TLS (Port 853) und DNS over HTTPS (Port 443) anbietet. In der Mitte ein Schild mit DoT/DoH-Symbolen, Pfeile zeigen verschlüsselten DNS-Verkehr. Fokus auf Sicherheits- und Rollen-Trennung.

DoT und DoH lösen genau dieses Problem. Beide sorgen dafür, dass diese DNS-Nachfragen verschlüsselt übertragen werden. Bei DNS over TLS, kurz DoT, wird die Anfrage in eine eigene sichere Verbindung gepackt. Außenstehende sehen noch, dass eine DNS-Anfrage stattfindet, aber nicht mehr, welche Webseite gemeint ist. Bei DNS over HTTPS, kurz DoH, wird dieselbe Anfrage zusätzlich im normalen Webseitenverkehr versteckt. Von außen sieht sie aus wie ein ganz gewöhnlicher Zugriff auf eine Website.

Der Zweck von beiden ist also derselbe: Schutz der Privatsphäre und Schutz vor Manipulation. Der Unterschied liegt darin, wie sichtbar diese Nachfragen noch sind. DoT ist transparent und gut kontrollierbar, DoH ist unauffälliger, kann dafür aber lokale Regeln und Schutzmechanismen umgehen.

Mal angenommen, du möchtest eine gewisse Webseite aufrufen. Dann geht der Client los und holt über einen DNS-Server die IP-Adressen vom Server. Dies kann man mitlesen und ggf. verändern. Mitlesen sagt dem Mitlesenden, wo du dich so im Internet herumtreibst. Verändern könnte man als Angriff nutzen, indem man dir einfach eine andere Webseite vorsetzt, während du versuchst, dich in deinen Mailaccount einzuloggen. Beides wird durch DoH und DoT deutlich erschwert.

Dann soll es ja Netzwerke geben, in welchen dir ein bestimmter DNS-Server aufgezwungen wird, weil dieser DNS-Server nach Werbung oder ungewollten Inhalten filtert. Damit dies nun ebenfalls nicht einfach umgangen werden kann, blockt man den Zugriff aus dem Netzwerk einfach auf die Ports, welche sonst für eine DNS-Abfrage benutzt werden (TCP/53, UDP/53, TCP/853). Da kommt nun DoH ins Spiel, denn das läuft auf dem ganz normalen HTTPS-Port TCP/443. Blockt man den, kann keiner mehr auf Webseiten zugreifen (ok, unverschlüsselt, aber hey, das macht doch keiner mehr, oder?).

Die Zeit ging weiter – BIND auch.
Meine älteren Artikel zu DoT/DoH waren für ihren Zeitpunkt korrekt, aber inzwischen hat sich an zwei Stellen richtig was getan:

  1. BIND spricht DoT/DoH nativ (kein Stunnel-/Proxy-Zirkus mehr nötig – außer du willst bewusst terminieren/filtern).
  2. „Authoritative + Public Resolver auf derselben Kiste“ ist ohne klare Trennung schnell ein Sicherheitsproblem (Open-Resolver/Reflection-Missbrauch lässt grüßen).

Darum gibt’s hier das Update:

  • ns1.kernel-error.de: nur autoritativ auf UDP/TCP 53 (Zonen, DNSSEC wie gehabt)
  • dns.kernel-error.de: Public Resolver nur auf DoT 853/TCP und DoH 443/TCP (rekursiv, DNSSEC-validierend)
  • Trennung über zusätzliche IPs + Views. Ergebnis: Authoritative bleibt „stumm rekursiv“, Resolver ist nur über TLS/HTTPS erreichbar.

Zielbild

Uff, ich muss zugeben, diesen Beitrag schon VIEL zu lange als Draft zu haben. Es ist einfach viel zu schreiben, bschreiben und mir fehlte die Zeit. Aber das kennt ihr ja. OK… das Zielbild, was soll es werden?

Was soll am Ende gelten:

  • Port 53 auf Authoritative-IP(s):
    • beantwortet nur meine autoritativen Zonen
    • keine Rekursion → REFUSED bei google.com
  • DoT/DoH auf separaten Resolver-IP(s):
    • rekursiv für „das ganze Internet“
    • DNSSEC-Validation aktiv
    • kein offenes UDP/53 → weniger Angriffsfläche für Reflection/Amplification

Warum das wichtig ist:
Ein „Public Resolver“ ist per Definition attraktiv für Missbrauch. Der Klassiker ist DNS-Amplification über UDP/53. Wenn man Rekursion auf 53 offen hat, ist man sehr schnell Teil fremder Probleme. DoT/DoH sind TCP-basiert – das ist schon mal deutlich unattraktiver für Reflection. (Nicht „unmöglich“, aber praktisch viel weniger lohnend.)

Warum „Views“ – und warum zusätzliche IPs?

1) Views – weil Policy pro Anfrage gelten muss

Wir wollen auf derselben named-Instanz zwei sehr unterschiedliche Rollen:

  • Authoritative: recursion no;
  • Resolver: recursion yes; + Root-Hints/Cache

Das muss pro eingehender Anfrage entschieden werden. Dafür sind Views da.

2) Also: Trennung über Ziel-IP (match-destinations)

Wenn wir DoH/DoT auf andere IPs legen, kann die View anhand der Zieladresse entscheiden:

  • Anfrage geht an 93.177.67.26 / 2a03:4000:38:20e::53 → auth-View
  • Anfrage geht an 37.120.183.220 / 2a03:4000:38:20e::853 → resolver-View

Und genau deshalb brauchen wir:

  • zusätzliche IPs (damit die Rollen sauber getrennt sind)
  • separaten FQDN dns.kernel-error.de (damit Clients überhaupt sinnvoll DoT/DoH nutzen können – und für TLS/SNI/Cert-Match)

Wenn du also grade ein ripe from ausfüllst und angeben musst, warum da eine weitere IPv4 Adresse „verbrannt“ werden soll, hast du nun eine gute Antwort 😀

BIND-Config

Ich beschreibe hier nur die Teile, die für das Rollen-Split relevant sind. Die Zonendateien/Slaves bleiben wie sie sind.

1) /usr/local/etc/namedb/named.conf – Views

Wichtig: Sobald wir view {} nutzen, müssen alle Zonen in Views liegen, sonst bricht named-checkconf ab. Das ist kein „Feature“, das ist BIND. Leicht nervig, vor allem wenn man nun viel in seinem Setup umschreiben muss. Aber ich eigentlich schon mal erwähnt, dass ich auf der Arbeit mal einen, nennen wir es mal View Ersatz, für powerdns gesehen habe? Da hat tatsächlich jemand mit einer Cisco ASA in die DNS Pakete geschaut und je nachdem welche quelle angefragt hat, wurde dann durch die ASA eine neue Adresse in die DNS Pakete geschrieben. Furchtbar! Richtig schlimm. Bis man so etwas findet, wenn man es nicht weiß. DNSsec geht kaputt und aaahhhhhhaaaaaahhhhh. Egal, mein PTBS kickt da grade. Öhm wo waren wir? Genau…

Beispiel:

include "/usr/local/etc/namedb/named.conf.options";

view "auth" {
    match-clients { any; };
    match-destinations { 93.177.67.26; 2a03:4000:38:20e::53; };

    recursion no;
    allow-recursion { none; };
    allow-query-cache { none; };
    allow-query { any; };

    include "/usr/local/etc/namedb/named.conf.default-zones";
    include "/usr/local/etc/namedb/named.conf.master";
    include "/usr/local/etc/namedb/named.conf.slave";
};

view "resolver" {
    match-clients { any; };
    match-destinations { 37.120.183.220; 2a03:4000:38:20e::853; 127.0.0.1; ::1; };

    recursion yes;
    allow-recursion { any; };
    allow-query-cache { any; };
    allow-query { any; };

    zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
};

Warum Root-Hints nur im Resolver-View?
Weil nur dieser View rekursiv arbeiten soll. Ohne Root-Hints ist Rekursion tot; dat wolln wa so!

2) /usr/local/etc/namedb/named.conf.options – Listener-Trennung + DoH/DoT

Der „Aha-Moment“ hier: Wir trennen nicht nur per View, sondern auch per listen-on.
Damit bindet named die Ports wirklich nur auf den gewünschten IPs.

Authoritative (nur 53):

listen-on { 93.177.67.26; 127.0.0.1; };
listen-on-v6 { 2a03:4000:38:20e::53; ::1; };

DoT auf Resolver-IPs (+ Loopback für lokale Tests):

listen-on port 853 tls local-tls { 37.120.183.220; 127.0.0.1; };
listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; ::1; };

DoH auf Resolver-IPs (+ Loopback):
BIND 9.18+ kann DoH nativ, Endpoint typischerweise /dns-query

http doh-local {
    endpoints { "/dns-query"; };
    listener-clients 1000;
    streams-per-connection 256;
};

listen-on port 443 tls local-tls http doh-local { 37.120.183.220; 127.0.0.1; };
listen-on-v6 port 443 tls local-tls http doh-local { 2a03:4000:38:20e::853; ::1; };

TLS-Block (DoT/DoH):

tls local-tls {
    cert-file "/usr/local/etc/nginx/ssl/wild.kernel-error.de/2025/ecp/chain.crt";
    key-file "/usr/local/etc/nginx/ssl/wild.kernel-error.de/2025/ecp/http.key";
    protocols { TLSv1.2; TLSv1.3; };
    ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
    cipher-suites "TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256";
    prefer-server-ciphers yes;
    session-tickets no;
};

„Ich schalte nginx davor – muss BIND TLS können?“
Wenn nginx wirklich TLS terminiert, kann BIND auch ohne TLS dahinter laufen – dann sprichst du intern HTTP/2 cleartext oder HTTP/1.1, je nach Setup. Das habe ich ebenfalls so umgesetzt, es hängt immer etwas davon ab, was man so will und wie groß das Setup wird. Ich lasse es in diesem Beitrag aber mal weg, so läuft alles nur mit bind. Ob BIND dafür „tls none“/HTTP-Listener sauber unterstützt, hängt an der BIND-DoH-Implementierung – hier ist die BIND/ARM-Doku die Wahrheit. bind9.readthedocs.io+1

Testplan – Linux-CLI – bewusst IPv4 und IPv6

Wir wollen natürlich einmal reproduzierbar testen. Also: jede Stufe zweimal. Einmal -4, einmal -6. Also ob es bei IPv4 und bei IPv6 jeweils korrekt ist. Ihr könnt euch nicht vorstellen, wie oft ich fest davon überzeugt bin, es für beide Adressfamilien korrekt konfiguriert zu haben, dann aber noch ein unterschied zwischen v4 und v6 ist. Daher testen wir das.

Voraussetzungen auf Linux

which dig kdig curl openssl

Schritt 1 – DoT-TLS-Handshake prüfen (IPv4/IPv6)

IPv4

openssl s_client \
  -connect 37.120.183.220:853 \
  -servername dns.kernel-error.de \
  -alpn dot

Erwartung:

  • Zertifikat passt auf dns.kernel-error.de (SAN / Wildcard ok)
  • ALPN protocol: dot
  • Verify return code: 0 (ok)

IPv6

openssl s_client \
  -connect '[2a03:4000:38:20e::853]:853' \
  -servername dns.kernel-error.de \
  -alpn dot

Wenn das passt, ist TLS-Transport ok. Also nur die TLS Terminierung für IPv4 und IPv6, da war noch keine DNS Abfrage enthalten.

Schritt 2 – DoT-Query (kdig) – IPv4/IPv6

IPv4

kdig +tls @37.120.183.220 google.com A

Erwartung:

  • status: NOERROR
  • Flags: rd ra (Recursion Desired/Available)
  • eine A-Antwort

IPv6

kdig +tls @[2a03:4000:38:20e::853] google.com A

Gleiche Erwartungshaltung wie bei IPv4.

Schritt 3 – Sicherstellen: kein Resolver auf UDP/TCP 53

Resolver-IPs dürfen auf 53 nicht antworten

dig -4 @37.120.183.220 google.com A
dig -6 @2a03:4000:38:20e::853 google.com A

Erwartung:

  • Timeout / no servers reached
    Genau das wollen wir ja: kein UDP/53 auf den Resolver-IPs.

Authoritative-IPs dürfen nicht rekursiv sein

dig -4 @93.177.67.26 google.com A
dig -6 @2a03:4000:38:20e::53 google.com A

Erwartung:

  • status: REFUSED
  • idealerweise EDE: (recursion disabled)
    Das ist genau die „nicht missbrauchbar als Open-Resolver“-Bremse.

Und unser positiver Check:

dig -4 @93.177.67.26 kernel-error.de A
dig -6 @2a03:4000:38:20e::53 kernel-error.de A

Erwartung:

  • aa gesetzt (authoritative answer)
  • Antwort aus meiner Zone

Schritt 4 – DoH GET (Base64url) – IPv4/IPv6

4.1 Query bauen (DNS-Wireformat → base64url)

Beispiel google.com A:

echo -n -e '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x06google\x03com\x00\x00\x01\x00\x01' \
| base64 -w0 | tr '+/' '-_' | tr -d '='

Das Ergebnis ist mein dns= Parameter (base64url ohne = padding). Das ist DoH-Standard nach RFC 8484.

4.2 DoH GET erzwingen – IPv4

curl -4 --http2 -s \
'https://dns.kernel-error.de/dns-query?dns=<DEIN_DNS_PARAM>' \
| hexdump -C

IPv6

curl -6 --http2 -s \
'https://dns.kernel-error.de/dns-query?dns=<DEIN_DNS_PARAM>' \
| hexdump -C

Erwartung:

  • HTTP/2 200
  • content-type: application/dns-message
  • Im Hexdump siehst du eine valide DNS-Response.

Schritt 5 – DoH POST (application/dns-message) – IPv4/IPv6

Das ist der „richtige“ DoH-Weg für Tools/Clients.

IPv4

printf '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x06google\x03com\x00\x00\x01\x00\x01' \
| curl -4 --http2 -s \
  -H 'content-type: application/dns-message' \
  --data-binary @- \
  https://dns.kernel-error.de/dns-query \
| hexdump -C

IPv6

printf '\x12\x34\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x06google\x03com\x00\x00\x01\x00\x01' \
| curl -6 --http2 -s \
  -H 'content-type: application/dns-message' \
  --data-binary @- \
  https://dns.kernel-error.de/dns-query \
| hexdump -C

Erwartung:

  • DNS-Response im Wireformat
  • keine HTML-Antwort, kein Redirect-Quatsch

Was wir damit jetzt sicher(er) gelöst haben:

  • Kein Open-Resolver auf UDP/53 → massiver Gewinn gegen DNS-Amplification.
  • Authoritative bleibt Authoritative → Zonen-Betrieb unverändert stabil.
  • Resolver nur über DoT/DoH → TCP/TLS-Transport, weniger Missbrauchsfläche.
  • Saubere technische Trennung → Views per Ziel-IP sind simpel, robust, nachvollziehbar.

Und ja: „Public Resolver“ heißt trotzdem Monitoring/Rate-Limiting/Abuse-Handling.
Das Feintuning (RRL, QPS-Limits, minimal-responses, Response-Policy, ggf. ECS-Handling, Logging, Fail2ban-Signale) ist das nächste Kapitel. Wobei, wenn ich grade auf die TLS Parameter schaue, sollte ich da vielleicht noch mal nacharbeiten, hm?

Wenn ihr noch eine kleine liste von erreichbaren Servern sucht: GitHub-curl-wiki

Alles hilft natürlich nicht, wenn man am Ende doch komplett IP- oder Hostnamebasiert geblockt wird. In China ist da nicht viel zu holen und auch hier gibt es immer mal wieder etwas.

Japp… TLS geht besser. Im Beitrag habe ich es oben schon angepasst, es war:

tls local-tls {
    cert-file "/pfad/chain.crt";
    key-file  "/pfad/http.key";
    dhparam-file "/pfad/dhparam.pem";
    protocols { TLSv1.2; TLSv1.3; };
    ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
    prefer-server-ciphers yes;
    session-tickets no;
};
  • dhparam-file ist komplett raus weil, ja weil es nicht benutzt wird ich mach ja kein DHE sondern ECDHE
  • cipher-suites für TLS1.3 waren nicht gesetzt.
  • Dann konnten auch gleich die Cipher aufgeräumt werden.

Hey, da hat es sich doch gelohnt, das mal runter zu schreiben. So habe ich es direkt gefunden und nicht erst, weil mich jemand von euch darauf hinweist (macht das aber bitte immer wenn ich hier Mist schreibe) oder es beim nächsten eigenen Audit auffällt.

Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15 richtig konfigurieren

22. Dezember 2025 / / Keine Kommentare

Mein FreeBSD 15 kommt mit OpenSSH 10.0p2 und OpenSSL 3.5.4.
Beide bringen inzwischen das mit, was man aktuell als quantensichere Kryptografie bezeichnet. Oder genauer gesagt das, was wir Stand heute für ausreichend robust gegen zukünftige Quantenangriffe halten.

Illustration zu quantensicherer Kryptografie mit OpenSSH auf FreeBSD 15. Dargestellt sind ein Quantenchip, kryptografische Symbole, ein Server, ein SSH Schlüssel sowie der FreeBSD Daemon als Sinnbild für post-quantum Key Exchange und sichere Serverkommunikation.

Quantensicher? Nein, das hat nichts mit Füßen zu tun, sondern tatsächlich mit den Quanten aus der Physik. Quantencomputer sind eine grundlegend andere Art von Rechnern. Googles aktueller Quantenchip war in diesem Jahr bei bestimmten Physiksimulationen rund 13.000-mal schneller als der derzeit leistungsstärkste klassische Supercomputer. Der chinesische Quantencomputer Jiuzhang wurde bei speziellen Aufgaben sogar als 100 Billionen Mal schneller eingestuft.

Kurz gesagt: Quantencomputer sind bei bestimmten Berechnungen extrem viel schneller als heutige klassische Rechner. Und genau das ist für Kryptografie ein Problem.

Als Vergleich aus der klassischen Welt: Moderne Grafikkarten haben die Zeit zum Knacken von Passwörtern in den letzten Jahren drastisch verkürzt.

  • Nur Zahlen: Ein 12-stelliges Passwort wird praktisch sofort geknackt.
  • Nur Kleinbuchstaben: wenige Wochen bis Monate.
  • Groß- und Kleinschreibung plus Zahlen: etwa 100 bis 300 Jahre.
  • Zusätzlich Sonderzeichen: 2025 noch als sehr sicher einzustufen mit geschätzten 226 bis 3.000 Jahren.

Quantencomputer nutzen spezielle Algorithmen wie den Grover-Algorithmus, der die effektive Sicherheit symmetrischer Verfahren halbiert. Ein ausreichend leistungsfähiger Quantencomputer könnte damit die benötigte Zeit drastisch reduzieren. Was heute Jahrhunderte dauert, könnte theoretisch auf Tage oder Stunden schrumpfen.

Stand 2025 sind solche Systeme zwar real und in der Forschung extrem leistungsfähig, werden aber noch nicht flächendeckend zum Brechen realer Kryptosysteme eingesetzt.

Heißt das also alles entspannt bleiben? Jein.

Verschlüsselte Datenträger lassen sich kopieren und für später weglegen. Gleiches gilt für aufgezeichneten verschlüsselten Netzwerkverkehr. Heute kommt man nicht an die Daten heran, aber es ist absehbar, dass das in Zukunft möglich sein könnte. Genau hier setzt quantensichere Kryptografie an. Ziel ist es, auch aufgezeichnete Daten dauerhaft vertraulich zu halten.

Ein praktisches Beispiel ist der Schlüsselaustausch mlkem768x25519. Wenn ihr diese Seite nicht gerade über Tor lest, ist die Wahrscheinlichkeit hoch, dass euer Browser bereits eine solche hybride, post-quantum-fähige Verbindung nutzt. Im Firefox lässt sich das einfach prüfen über F12, Network, eine Verbindung anklicken, dann Security und dort die Key Exchange Group. Taucht dort mlkem768x25519 auf, ist die Verbindung entsprechend abgesichert. Richtig, auf dem Screenhot seht ihr auch HTTP/3.

Image of mlkem768+x25519 in firefox.

Für diese Webseite ist das nicht zwingend nötig. Für SSH-Verbindungen zu Servern aber unter Umständen schon eher. Deshalb zeige ich hier, wie man einen OpenSSH-Server entsprechend konfiguriert.

Ich beziehe mich dabei bewusst nur auf die Kryptografie. Ein echtes SSH-Hardening umfasst deutlich mehr, darum geht es hier aber nicht.

Die zentrale Konfigurationsdatei ist wie üblich: /etc/ssh/sshd_config

Stand Ende 2025 kann ich folgende Konfiguration empfehlen:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com

Die Zeilen werden entweder an die bestehende Konfiguration angehängt oder ersetzen vorhandene Einträge. Da wir nicht einfach blind kopieren wollen, hier kurz die Erklärung.

Schlüsselaustausch:
Bevorzugt werden hybride Verfahren wie mlkem768 kombiniert mit x25519 sowie sntrup761 kombiniert mit x25519. Diese verbinden klassische elliptische Kryptografie mit post-quantum-resistenten Algorithmen. Damit ist die Verbindung sowohl gegen heutige Angreifer als auch gegen zukünftige Store-now-decrypt-later-Szenarien abgesichert. Curve25519 dient als bewährter Fallback. Klassische Diffie-Hellman-Gruppen sind nur aus Kompatibilitätsgründen enthalten.

Verschlüsselung:
Es werden ausschließlich moderne Algorithmen eingesetzt. Primär kommen AEAD-Ciphers wie ChaCha20-Poly1305 und AES-GCM zum Einsatz, die Vertraulichkeit und Integrität gleichzeitig liefern und bekannte Schwächen älterer Modi vermeiden. Ältere Verfahren wie CBC sind bewusst ausgeschlossen.

Integrität:
Zum Einsatz kommen ausschließlich SHA-2-basierte MACs im Encrypt-then-MAC-Modus. Dadurch werden klassische Angriffe auf SSH wie Padding-Oracles und bestimmte Timing-Leaks wirksam verhindert.

Serveridentität:
Als Hostkey-Algorithmus wird Ed25519 verwendet. Optional auch mit Zertifikaten oder hardwaregestützten Security Keys. Das bietet hohe kryptografische Sicherheit bei überschaubarem Verwaltungsaufwand.

Wichtig: Das funktioniert nur, wenn Server und Client diese Algorithmen auch unterstützen. Wer bereits mit SSH-Keys arbeitet, sollte prüfen, dass es sich um Ed25519-Keys handelt. Andernfalls sperrt man sich im Zweifel selbst aus.

Auf dem Server lässt sich die aktive Konfiguration prüfen mit:

sshd -T | grep -Ei 'kexalgorithms|ciphers|macs|hostkeyalgorithms'

Auf dem Client geht es am einfachsten mit:

ssh -Q kex
ssh -Q cipher
ssh -Q mac
ssh -Q key

So sieht man schnell, welche Algorithmen tatsächlich verfügbar sind.

Zur externen Überprüfung der SSH-Konfiguration kann ich außerdem das Tool ssh-audit empfehlen. Aufruf einfach per:

ssh-audit hostname oder IP -p PORT

Das liefert eine brauchbare Einschätzung der aktiven Kryptografie und möglicher Schwachstellen. Oh, wenn ihr schon dabei seit, vergesst nicht:

Hinweis zur Einordnung der Quantensicherheit:
Die hier gezeigte Konfiguration verbessert ausschließlich den Schlüsselaustausch (Key Exchange) durch hybride post-quantum-fähige Verfahren. Hostkeys und Signaturen in OpenSSH basieren weiterhin auf klassischen Algorithmen (z. B. Ed25519 oder ECDSA); standardisierte post-quantum-Signaturalgorithmen sind in OpenSSH aktuell noch nicht implementiert. Es existieren zwar experimentelle Forks (z. B. aus dem Open-Quantum-Safe-Projekt), diese gelten jedoch ausdrücklich nicht als produktionsreif und sind nicht Bestandteil des OpenSSH-Mainlines. Die hier gezeigte Konfiguration ist daher als pragmatischer Übergangsschritt zu verstehen, um „store-now-decrypt-later“-Risiken beim Schlüsselaustausch bereits heute zu reduzieren, ohne auf instabile oder nicht standardisierte Komponenten zu setzen.
Weiterführende Informationen zum aktuellen Stand der post-quantum-Unterstützung in OpenSSH finden sich in der offiziellen Dokumentation: https://www.openssh.com/pq.html

Viel Spaß beim Nachbauen. Und wie immer: bei Fragen, fragen.

GPT in Rspamd aktivieren: so nutze ich das LLM-Signal im Score

30. September 2025 / / 4 Kommentare

Setup: FreeBSD 14.3, Rspamd 3.12.1, Postfix + Dovecot. Ich lasse bei kniffligen Mails zusätzlich ein LLM draufschauen. Wichtig: GPT ist bei mir nur ein weiterer Sensor im ganz normalen Rspamd-Scoring — keine Allzweckwaffe und kein „hartes Urteil“.

Voraussetzungen

  • Rspamd inkl. GPT-Plugin (ab ~3.12.x im Paket; konfiguriert wird in local.d/gpt.conf).
  • API-Zugang (OpenAI-kompatibel oder eigener Endpunkt).
  • Grundverständnis zu Rspamd-Metrics/Actions (Reject/Add-Header/Greylist).

OpenAI API Key erstellen: Melde dich auf der Developer-Plattform an, öffne die Seite API Keys und klicke auf Create new secret key. Lege bei Bedarf Berechtigungen fest oder arbeite mit projektbasierten Keys. Kopiere den Key einmalig und bewahre ihn sicher (root-only) auf – bitte nicht teilen. Nutzung/Kosten siehst du im Usage-Dashboard.

Mein gpt.conf

Ich halte die Konfiguration bewusst nüchtern — genug, um robuste Labels zu bekommen, aber ohne Schnickschnack:

# local.d/gpt.conf (Auszug)
enabled = true;
type = "openai";
model = "gpt-4o-mini";
api_key = "GEHEIMER-KEY";

model_parameters {
  gpt-4o-mini {
    max_tokens = 160;
    temperature = 0.0;
  }
}

timeout = 10s;
allow_ham = true;
allow_passthrough = false;
json = false;
reason_header = "X-GPT-Reason";

input = "text";
min_words = 1;
max_size = 256k;

symbols_to_except {
  RCVD_IN_DNSWL_MED = -0.1;
  RCVD_IN_DNSWL_HI  = -0.1;
  DWL_DNSWL_MED     = -0.1;
  WHITELIST_RECP_ADDR = -0.1;
  GREYLIST = 0; GREYLIST_CHECK = 0; GREYLIST_SAVE = 0;
  RCPT_IN_SPAMTRAP = 0; SPAMTRAP = 0; SPAMTRAP_ADDR = 0;
  RCVD_VIA_SMTP_AUTH = 0; LOCAL_CLIENT = 0; FROM_LOCAL = 0;
}

Was bedeutet das?!

  • model = gpt-4o-mini: flott & günstig, deterministisch per temperature = 0.0.
  • allow_ham = true: GPT darf „HAM“ melden (kleines, positives Signal).
  • allow_passthrough = false: Bei Fehlern (Timeout/API down) keine stillen Freifahrten.
  • reason_header = "X-GPT-Reason": Kurzbegründung landet im Header (s.u. Datenschutz).
  • symbols_to_except: Offensichtliche interne Fälle werden neutralisiert, damit GPT nicht in klaren Situationen wirkt.
  • Limits: min_words = 1, max_size = 256k, timeout = 10s.

Metric/Scoring: drei GPT-Symbole

symbols {
  GPT_SPAM       { weight = 9.0;  group = "gpt"; description = "GPT: classified as SPAM"; }
  GPT_SUSPICIOUS { weight = 4.5;  group = "gpt"; description = "GPT: classified as SUSPICIOUS"; }
  GPT_HAM        { weight = -0.5; group = "gpt"; one_shot = true; description = "GPT: classified as HAM"; }
}

GPT wirkt wie ein starker, aber nicht absoluter Faktor.
– SPAM (9.0): kräftiger Zuschlag.
– SUSPICIOUS (4.5): sanfter Schubs Richtung Greylist/Review.
– HAM (-0.5): kleine Entlastung, einmalig pro Mail.

Warum diese Gewichte?
Die Zahlen habe ich bewusst so gewählt, dass das GPT-Signal stark, aber nie absolut ist. Rspamd summiert Scores, GPT ist also nur ein Faktor:

  • GPT_SPAM = 9.0: genug, um bei Kombination mit klassischen Checks (Bayes, RBL, DMARC) die Add-Header-Schwelle sicher zu reißen, aber unterhalb von reject allein.
  • GPT_SUSPICIOUS = 4.5: halber Wert, schiebt Grauzonen in Richtung Greylist/Review, ohne sofortige Eskalation.
  • GPT_HAM = -0.5: nur eine kleine Entlastung (one_shot). So verhindert man, dass GPT-HAM mehrere Punkte abzieht und Spams „rettet“.

Wie wird die GPT-Gewichtung berechnet?
In den Logs/WebUI taucht das oft so auf: GPT_SPAM(2.10)[0.85]. Das bedeutet:

  • [0.85] = Rohwert von GPT, z. B. 85 % Wahrscheinlichkeit für Spam.
  • weight aus der Metric (z. B. 9.0 für GPT_SPAM).
  • Grundformel: Rohwert × weight → ergibt den Beitrag zum Gesamtscore.
  • Hinweis: Je nach Rspamd-Version kann der im Header gezeigte Wert zusätzlich skaliert sein (z. B. falls das Modell nur ein „softes“ Signal liefert). Deshalb sieht man in der Praxis häufig 2–8 Punkte statt des Maximalgewichts.

Actions/Schwellen

actions {
  greylist = 4;
  add_header = 6;
  reject = 15;
}

SUSPICIOUS (4.5) kippt oft in Greylist. SPAM (9.0) bringt fast immer Add-Header, Reject nur zusammen mit weiteren harten Befunden. Klassische Checks (SPF/DKIM/DMARC, RBL, Bayes) bleiben führend, GPT ergänzt nur.

Tuning
Zu bissig? Gewicht etwas senken.
Zu lasch? Gewicht erhöhen.
Zu optimistisch bei HAM? Gewicht kleiner machen oder 0 setzen.
Header mit X-GPT-Reason liefert Nachvollziehbarkeit, kann bei Bedarf wieder entfernt werden.

Praxis
– Symbole erscheinen im WebUI und Logfiles.
– X-GPT-Reason erklärt im Header die Bewertung.
– Latenz/Kosten: gpt-4o-mini mit 160 Tokens und 10 s Timeout ist performant und günstig.

Jetzt schauen wir uns mal die Mailheader eines echten Beispiels an und wie GPT dort gegriffen hat:

X-Spamd-Result: default: False [8.59 / 15.00];
        VIOLATED_DIRECT_SPF(3.50)[];
        GPT_SPAM(2.10)[0.85];
        MISSING_MIMEOLE(2.00)[];
        CTYPE_MIXED_BOGUS(1.00)[];
        MID_RHS_NOT_FQDN(0.50)[];
        DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[];
        MIME_HTML_ONLY(0.20)[];
        R_DKIM_ALLOW(-0.20)[thejewelbox.dd:s=1759374209.thejewelbox];
        ...

Erklärung:

  • X-Spamd-Result: [8.59 / 15.00] – Gesamtscore 8.59, Reject-Schwelle bei 15. Hier also kein Reject, sondern nur Add-Header.
  • GPT_SPAM(2.10)[0.85] – GPT meldet Spam mit 85 % Sicherheit ([0.85]). Daraus errechnet Rspamd den Beitrag ((…)), der in den Gesamtscore einfließt.
  • Die klassischen Checks wie VIOLATED_DIRECT_SPF(3.50) oder MISSING_MIMEOLE(2.00) haben ebenfalls beigetragen – GPT ist also nur ein Faktor im Gesamtbild.

Zusätzlich schreibt das GPT-Modul auf Wunsch auch eine kurze Begründung in den Mailheader:

X-GPT-Reason: This email is likely spam due to the urgency created around an unpaid invoice and the mismatch between the sender's domain and the company name.

Erklärung:

  • X-GPT-Reason – eigener Header, den du in gpt.conf mit reason_header = "X-GPT-Reason" aktivierst.
  • Der Text stammt direkt aus dem Modell und begründet die Einstufung (hier: Dringlichkeit „unpaid invoice“ + Domain/Company-Mismatch).
  • Nützlich für Analyse/Transparenz; kann auf MTA/MDA-Ebene wieder entfernt werden, wenn du ihn nicht bis zum Postfach durchreichen willst.

Ein Hinweis zum Datenschutz (gesamt)
Mit GPT-Integration gehen Mailinhalte an einen externen Dienst (z. B. OpenAI). Das kann datenschutzrechtlich relevant sein. Wer sensible oder personenbezogene Daten verarbeitet, sollte vorher prüfen, ob die Nutzung zulässig ist – oder alternativ ein selbst gehostetes, OpenAI-kompatibles Modell nutzen (z. B. Ollama). Den Reason-Header kannst du, falls nötig, serverseitig wieder entfernen.

S/MIME-Zertifikat per DNS veröffentlichen – SMIMEA

14. März 2025 / / Ein Kommentar
smimea S/MIME Blog Image

Mal wieder soweit: Mein aktuelles S/MIME-Zertifikat zum Signieren von E-Mails läuft aus. Also habe ich mir ein neues besorgt. Da GlobalSign keine Class-2-Zertifikate mehr für Privatpersonen anbietet, musste ich die CA wechseln. Durch Zufall bin ich auf SSLplus gestoßen – die haben echt gute Angebote für alle möglichen Zertifikate. Aber darum soll es in diesem Beitrag nicht gehen.

Wie immer will ich mein Zertifikat öffentlich zugänglich machen, sonst müsste jeder erst eine von mir signierte E-Mail erhalten, bevor er mein Zertifikat hat. Erst dann könnten Absender mir verschlüsselte E-Mails schicken.

Dafür gibt es ein experimentelles RFC 8162, das beschreibt, wie sich ein solches Zertifikat in einer DNSSEC-geschützten Zone veröffentlichen lässt. Natürlich gibt es im Internet wieder zig verschiedene Anleitungen und Wege, um das zu realisieren. Aber nichts wirklich Zuverlässiges, was ich finden konnte. Den DNS-Record für meine Bind9-Zone wieder manuell zu erstellen, hatte ich jedenfalls keine Lust.

Also habe ich zwei kleine Python3-Skripte geschrieben:

smimea_generate_record.py – Erstellt einen kopierbaren RR für die DNS-Zone. Kann interaktiv genutzt werden: Fragt nach E-Mail-Adresse und PEM-Zertifikat. Oder direkt mit Parametern aufgerufen werden. Prüft, ob E-Mail-Adresse und Zertifikat zusammenpassen, und gibt den fertigen Record aus.

./smimea_generate_record.py
Enter the email address: kernel-error@kernel-error.com
Enter the path to the PEM certificate: mail.pem
✅ Email 'kernel-error@kernel-error.com' matches the certificate!

🔹 **Generated BIND9 DNS Record:**

70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com. 3600 IN SMIMEA 3 0 0 (
   30820714308204FCA003020102021073C13C478DA7B114B871F00737F1B0FB30
   0D06092A864886F70D01010B0500304E310B300906035504061302504C312130
   1F060355040A0C1841737365636F20446174612053797374656D7320532E412E
   311C301A06035504030C1343657274756D20534D494D4520525341204341301E
   170D3235303331333133343135355A170D3237303331333133343135345A3078
   3114301206035504040C0B76616E206465204D65657231123010060355042A0C
   0953656261737469616E311E301C06035504030C1553656261737469616E2076
   616E206465204D656572312C302A06092A864886F70D010901161D6B65726E65
   6C2D6572726F72406B65726E656C2D6572726F722E636F6D30820222300D0609
   2A864886F70D01010105000382020F003082020A0282020100D0A90BC53ABA04
   08543FE600F0F71C17BE7EB4A8996A8EF5E9122AAC8E7F39D627186617C4D6CA
   734E1A9E6302F8076065EA93D762542D2C12BFF32D5D4942B9A8AA84E2E63CE9
   B843C1665C014A6572A42E376ED0629694FCC942FE53D76052A40CDAB1257A1D
   501D9C65DE18F27C5490A24181498A202E56F4DC0FDCBFE94766F96EBF47C872
   3744ABD69DC684417106DF3D4F12FD52A13B786490366DBF6CB5A843621CD686
   B06D072FD7D486BD0AC706021D137A365718DCD8709D55B64428F8DB56B268BD
   BED463A25231B40566C041A48958BE1767E27E21881D2109935C02F27EA306B6
   4997683EEFDF8685F4F090AB09692F232CD34AC7FF2296768CED62C68C37B4C3
   DD9F04EC9F5C9BB9F712A5032AC2F83D68DA756E4F2886A6F65889CFAEA0C15E
   3624EA3D9E3EFF91D68606F7B7B1B7120035AD4F71369E6D79977B4B2CC3575A
   C51CAF419E795B78822DD36B6D0B0E4622BCE55F7B27FCB52FDCD6A4FBD33EF0
   9F897CADA2E793D1509DE54773B3FBE9091CEA2E27A41CBA38A08BBBE1B15BF5
   6EB35B21D66F5B1B1CC6FDD6362AA88A4010F3D2732F071A841BC765D6F74C3B
   430D036A327918D08156BA2882D78113DD15633599319F4BD5D4F12E1F0102BA
   33766ADF09DC58323246D20BAC815BE5B8822C260EFBB07ADBAB98FA42F31650
   FEFAE5D679D4AD29992F199D59F38D54988D77B61E740CBF470203010001A382
   01C2308201BE300C0603551D130101FF0402300030410603551D1F043A303830
   36A034A0328630687474703A2F2F63736D696D6572736163612E63726C2E6365
   7274756D2E706C2F63736D696D6572736163612E63726C30818306082B060105
   0507010104773075302E06082B060105050730018622687474703A2F2F63736D
   696D6572736163612E6F6373702D63657274756D2E636F6D304306082B060105
   050730028637687474703A2F2F63736D696D6572736163612E7265706F736974
   6F72792E63657274756D2E706C2F63736D696D6572736163612E636572301F06
   03551D2304183016801466FBC30FBEF4BFE09CC9AB4DDE4719BDC0CAA668301D
   0603551D0E041604148D8C102E11D87004F7DDB4E04FF01781888A32A0304C06
   03551D20044530433009060767810C010504023036060B2A84680186F6770264
   01013027302506082B06010505070201161968747470733A2F2F7777772E6365
   7274756D2E706C2F435053301D0603551D250416301406082B06010505070304
   06082B06010505070302300E0603551D0F0101FF0404030204F030280603551D
   110421301F811D6B65726E656C2D6572726F72406B65726E656C2D6572726F72
   2E636F6D300D06092A864886F70D01010B0500038202010070724799F05CF4C8
   21854F43BD950BB608B989046349214F9D0EEC79F73A59DBF4063608FE5A7A7F
   A50CD46A15486018EB9C334418084D8F97FE32EA21CCBAFE902BF6472DB6CA60
   D79EBE09919AFA0652D92CB13B506400BAF4774F3263967A49548A6F723ADCBB
   715AF79705099E5EC84E283DAFA3465908F4148C2B153C41D051C94295D4F042
   54217D1C8E48DF59D92ECBCB4A872EC728A954DAF7B661DE8037F7F103393612
   14163901ACFE98F3D597A67DBE87A8EE1FEC33DB71712F4907E0F3B1171E9176
   158189AC8229B26B369C0FE2BBD5964CA2ABFC7D955485056102844E84E8F79E
   0F30BF41D5F42B3C4F4CCA9BF9334D5728518473A0E61A3AFC88F59034F27154
   6B5D806D86F1E8BC6B54B4E05F80C44835DCC2C534E419F63BBFDB305C1733B4
   2DD2CC5795876F004F18C2E4D64B2C9FC6939590BE32501B6A6CEDB19B5FBF47
   887C76E14C99A36D46E99B5C76782E4E345ECB37E8886303C84849ADC8BDE1AF
   4E3A8096AEE407A40699D5C000ADCD16A4805DDF8FB208FFB902EF14031CFFBE
   3C0DC03588EBF15557B3B1029B2CD196064BC0DEE1F11D12391825B86CB34A6F
   BEBBAD43B0FE0EA43301F93D0B26ACED182B1E27063AE578C003D4D4498132B8
   D980532754CFFBD9E6D8917615B62AE08295FC46391AA0FD9815FDD822D95E9B
   7573CA35477D59B98DE4852065F58FB60E0E620D3E2F5CAD
   )

smimea_lookup.py – Fragt den SMIMEA-Record im DNS ab, lädt das Zertifikat herunter und prüft es mit OpenSSL auf Gültigkeit. Funktioniert interaktiv oder mit übergebenen Werten.

./smimea_lookup.py 
Enter the email address: kernel-error@kernel-error.com

Querying DNS for SMIMEA record:
  70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com

Certificate saved as smimea_cert.der
Certificate successfully retrieved and verified:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            73:c1:3c:47:8d:a7:b1:14:b8:71:f0:07:37:f1:b0:fb
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = PL, O = Asseco Data Systems S.A., CN = Certum SMIME RSA CA
        Validity
            Not Before: Mar 13 13:41:55 2025 GMT
            Not After : Mar 13 13:41:54 2027 GMT
        Subject: SN = van de Meer, GN = Sebastian, CN = Sebastian van de Meer, emailAddress = kernel-error@kernel-error.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:d0:a9:0b:c5:3a:ba:04:08:54:3f:e6:00:f0:f7:
                    1c:17:be:7e:b4:a8:99:6a:8e:f5:e9:12:2a:ac:8e:
                    7f:39:d6:27:18:66:17:c4:d6:ca:73:4e:1a:9e:63:
                    02:f8:07:60:65:ea:93:d7:62:54:2d:2c:12:bf:f3:
                    2d:5d:49:42:b9:a8:aa:84:e2:e6:3c:e9:b8:43:c1:
                    66:5c:01:4a:65:72:a4:2e:37:6e:d0:62:96:94:fc:
                    c9:42:fe:53:d7:60:52:a4:0c:da:b1:25:7a:1d:50:
                    1d:9c:65:de:18:f2:7c:54:90:a2:41:81:49:8a:20:
                    2e:56:f4:dc:0f:dc:bf:e9:47:66:f9:6e:bf:47:c8:
                    72:37:44:ab:d6:9d:c6:84:41:71:06:df:3d:4f:12:
                    fd:52:a1:3b:78:64:90:36:6d:bf:6c:b5:a8:43:62:
                    1c:d6:86:b0:6d:07:2f:d7:d4:86:bd:0a:c7:06:02:
                    1d:13:7a:36:57:18:dc:d8:70:9d:55:b6:44:28:f8:
                    db:56:b2:68:bd:be:d4:63:a2:52:31:b4:05:66:c0:
                    41:a4:89:58:be:17:67:e2:7e:21:88:1d:21:09:93:
                    5c:02:f2:7e:a3:06:b6:49:97:68:3e:ef:df:86:85:
                    f4:f0:90:ab:09:69:2f:23:2c:d3:4a:c7:ff:22:96:
                    76:8c:ed:62:c6:8c:37:b4:c3:dd:9f:04:ec:9f:5c:
                    9b:b9:f7:12:a5:03:2a:c2:f8:3d:68:da:75:6e:4f:
                    28:86:a6:f6:58:89:cf:ae:a0:c1:5e:36:24:ea:3d:
                    9e:3e:ff:91:d6:86:06:f7:b7:b1:b7:12:00:35:ad:
                    4f:71:36:9e:6d:79:97:7b:4b:2c:c3:57:5a:c5:1c:
                    af:41:9e:79:5b:78:82:2d:d3:6b:6d:0b:0e:46:22:
                    bc:e5:5f:7b:27:fc:b5:2f:dc:d6:a4:fb:d3:3e:f0:
                    9f:89:7c:ad:a2:e7:93:d1:50:9d:e5:47:73:b3:fb:
                    e9:09:1c:ea:2e:27:a4:1c:ba:38:a0:8b:bb:e1:b1:
                    5b:f5:6e:b3:5b:21:d6:6f:5b:1b:1c:c6:fd:d6:36:
                    2a:a8:8a:40:10:f3:d2:73:2f:07:1a:84:1b:c7:65:
                    d6:f7:4c:3b:43:0d:03:6a:32:79:18:d0:81:56:ba:
                    28:82:d7:81:13:dd:15:63:35:99:31:9f:4b:d5:d4:
                    f1:2e:1f:01:02:ba:33:76:6a:df:09:dc:58:32:32:
                    46:d2:0b:ac:81:5b:e5:b8:82:2c:26:0e:fb:b0:7a:
                    db:ab:98:fa:42:f3:16:50:fe:fa:e5:d6:79:d4:ad:
                    29:99:2f:19:9d:59:f3:8d:54:98:8d:77:b6:1e:74:
                    0c:bf:47
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 CRL Distribution Points: 
                Full Name:
                  URI:http://csmimersaca.crl.certum.pl/csmimersaca.crl
            Authority Information Access: 
                OCSP - URI:http://csmimersaca.ocsp-certum.com
                CA Issuers - URI:http://csmimersaca.repository.certum.pl/csmimersaca.cer
            X509v3 Authority Key Identifier: 
                66:FB:C3:0F:BE:F4:BF:E0:9C:C9:AB:4D:DE:47:19:BD:C0:CA:A6:68
            X509v3 Subject Key Identifier: 
                8D:8C:10:2E:11:D8:70:04:F7:DD:B4:E0:4F:F0:17:81:88:8A:32:A0
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.5.4.2
                Policy: 1.2.616.1.113527.2.100.1.1
                  CPS: https://www.certum.pl/CPS
            X509v3 Extended Key Usage: 
                E-mail Protection, TLS Web Client Authentication
            X509v3 Key Usage: critical
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Subject Alternative Name: 
                email:kernel-error@kernel-error.com
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        70:72:47:99:f0:5c:f4:c8:21:85:4f:43:bd:95:0b:b6:08:b9:
        89:04:63:49:21:4f:9d:0e:ec:79:f7:3a:59:db:f4:06:36:08:
        fe:5a:7a:7f:a5:0c:d4:6a:15:48:60:18:eb:9c:33:44:18:08:
        4d:8f:97:fe:32:ea:21:cc:ba:fe:90:2b:f6:47:2d:b6:ca:60:
        d7:9e:be:09:91:9a:fa:06:52:d9:2c:b1:3b:50:64:00:ba:f4:
        77:4f:32:63:96:7a:49:54:8a:6f:72:3a:dc:bb:71:5a:f7:97:
        05:09:9e:5e:c8:4e:28:3d:af:a3:46:59:08:f4:14:8c:2b:15:
        3c:41:d0:51:c9:42:95:d4:f0:42:54:21:7d:1c:8e:48:df:59:
        d9:2e:cb:cb:4a:87:2e:c7:28:a9:54:da:f7:b6:61:de:80:37:
        f7:f1:03:39:36:12:14:16:39:01:ac:fe:98:f3:d5:97:a6:7d:
        be:87:a8:ee:1f:ec:33:db:71:71:2f:49:07:e0:f3:b1:17:1e:
        91:76:15:81:89:ac:82:29:b2:6b:36:9c:0f:e2:bb:d5:96:4c:
        a2:ab:fc:7d:95:54:85:05:61:02:84:4e:84:e8:f7:9e:0f:30:
        bf:41:d5:f4:2b:3c:4f:4c:ca:9b:f9:33:4d:57:28:51:84:73:
        a0:e6:1a:3a:fc:88:f5:90:34:f2:71:54:6b:5d:80:6d:86:f1:
        e8:bc:6b:54:b4:e0:5f:80:c4:48:35:dc:c2:c5:34:e4:19:f6:
        3b:bf:db:30:5c:17:33:b4:2d:d2:cc:57:95:87:6f:00:4f:18:
        c2:e4:d6:4b:2c:9f:c6:93:95:90:be:32:50:1b:6a:6c:ed:b1:
        9b:5f:bf:47:88:7c:76:e1:4c:99:a3:6d:46:e9:9b:5c:76:78:
        2e:4e:34:5e:cb:37:e8:88:63:03:c8:48:49:ad:c8:bd:e1:af:
        4e:3a:80:96:ae:e4:07:a4:06:99:d5:c0:00:ad:cd:16:a4:80:
        5d:df:8f:b2:08:ff:b9:02:ef:14:03:1c:ff:be:3c:0d:c0:35:
        88:eb:f1:55:57:b3:b1:02:9b:2c:d1:96:06:4b:c0:de:e1:f1:
        1d:12:39:18:25:b8:6c:b3:4a:6f:be:bb:ad:43:b0:fe:0e:a4:
        33:01:f9:3d:0b:26:ac:ed:18:2b:1e:27:06:3a:e5:78:c0:03:
        d4:d4:49:81:32:b8:d9:80:53:27:54:cf:fb:d9:e6:d8:91:76:
        15:b6:2a:e0:82:95:fc:46:39:1a:a0:fd:98:15:fd:d8:22:d9:
        5e:9b:75:73:ca:35:47:7d:59:b9:8d:e4:85:20:65:f5:8f:b6:
        0e:0e:62:0d:3e:2f:5c:ad

Beide Skripte findet ihr auf GitHub, damit ihr sie nutzen oder verbessern könnt.

Warum habe ich geschrieben, dass ich nichts Zuverlässiges finden konnte? Nun, oft stoße ich auf Anleitungen, die noch auf TYPE53 basieren. Das ist nötig, wenn Bind9 den eigentlichen RR-Type noch nicht kennt – also ein klares Zeichen dafür, dass es sich um eine sehr frühe Implementierung handelt.

Ein weiteres häufiges Problem: Der Hash des Local-Parts wird einfach weggelassen. Stattdessen erfolgen die Abfragen direkt auf _smimecert., was aber falsch ist. Ohne den SHA256-Hash des Local-Parts gibt es keine eindeutige Zuordnung zur jeweiligen E-Mail-Adresse.

Warum ist der SMIMEA-DNS-Record so aufgebaut? Ganz einfach:

Der erste Teil, also , sorgt dafür, dass nicht einfach jeder direkt aus der DNS-Zone die E-Mail-Adressen auslesen kann. Statt die E-Mail-Adresse im Klartext zu speichern, wird stattdessen nur der SHA256-Hash des Local-Parts (also der Teil vor dem @) genutzt. Das bedeutet: Wer die genaue E-Mail-Adresse kennt, kann den passenden DNS-Eintrag finden – aber jemand, der einfach nur blind durch die Zone scannt, sieht nur Hashes und kann damit nichts anfangen.

Der _smimecert-Prefix zeigt an, dass es sich um einen SMIMEA-Record handelt, ähnlich wie es bei ._tcp. für SRV-Records oder _acme-challenge. für Let’s Encrypt-Zertifikate der Fall ist.

Und schließlich kommt die Domain, zu der die E-Mail-Adresse gehört.

Zusammen ergibt das einen sicheren, einfach abfragbaren und nicht direkt durchsuchbaren DNS-Eintrag für dein S/MIME-Zertifikat.

Möchte man die Abfrage manuell mit dig für die E-Mail-Adresse „kernel-error@kernel-error.com“ durchführen, muss man zuerst den Local-Part der E-Mail-Adresse (kernel-error) mit SHA256 hashen. Laut RFC 8162, Abschnitt 3.1 wird der SHA-256-Hash auf die ersten 28 Bytes (56 Hex-Zeichen) gekürzt, um die DNS-Label-Längenbeschränkung von 63 Zeichen pro Label (RFC 1035, Abschnitt 2.3.4) einzuhalten.

echo -n "kernel-error" | sha256sum | awk '{print $1}' | cut -c1-56
70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0

Anschließend kann man die dig-Abfrage korrekt zusammensetzen:

dig +dnssec +short 70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com. SMIMEA
3 0 0 30820714308204FCA003020102021073C13C478DA7B114B871F00737 F1B0FB300D06092A864886F70D01010B0500304E310B300906035504 061302504C3121301F060355040A0C1841737365636F204461746120 53797374656D7320532E412E311C301A06035504030C134365727475 6D20534D494D4520525341204341301E170D32353033313331333431 35355A170D3237303331333133343135345A30783114301206035504 040C0B76616E206465204D65657231123010060355042A0C09536562 61737469616E311E301C06035504030C1553656261737469616E2076 616E206465204D656572312C302A06092A864886F70D010901161D6B 65726E656C2D6572726F72406B65726E656C2D6572726F722E636F6D 30820222300D06092A864886F70D01010105000382020F003082020A 0282020100D0A90BC53ABA0408543FE600F0F71C17BE7EB4A8996A8E F5E9122AAC8E7F39D627186617C4D6CA734E1A9E6302F8076065EA93 D762542D2C12BFF32D5D4942B9A8AA84E2E63CE9B843C1665C014A65 72A42E376ED0629694FCC942FE53D76052A40CDAB1257A1D501D9C65 DE18F27C5490A24181498A202E56F4DC0FDCBFE94766F96EBF47C872 3744ABD69DC684417106DF3D4F12FD52A13B786490366DBF6CB5A843 621CD686B06D072FD7D486BD0AC706021D137A365718DCD8709D55B6 4428F8DB56B268BDBED463A25231B40566C041A48958BE1767E27E21 881D2109935C02F27EA306B64997683EEFDF8685F4F090AB09692F23 2CD34AC7FF2296768CED62C68C37B4C3DD9F04EC9F5C9BB9F712A503 2AC2F83D68DA756E4F2886A6F65889CFAEA0C15E3624EA3D9E3EFF91 D68606F7B7B1B7120035AD4F71369E6D79977B4B2CC3575AC51CAF41 9E795B78822DD36B6D0B0E4622BCE55F7B27FCB52FDCD6A4FBD33EF0 9F897CADA2E793D1509DE54773B3FBE9091CEA2E27A41CBA38A08BBB E1B15BF56EB35B21D66F5B1B1CC6FDD6362AA88A4010F3D2732F071A 841BC765D6F74C3B430D036A327918D08156BA2882D78113DD156335 99319F4BD5D4F12E1F0102BA33766ADF09DC58323246D20BAC815BE5 B8822C260EFBB07ADBAB98FA42F31650FEFAE5D679D4AD29992F199D 59F38D54988D77B61E740CBF470203010001A38201C2308201BE300C 0603551D130101FF0402300030410603551D1F043A30383036A034A0 328630687474703A2F2F63736D696D6572736163612E63726C2E6365 7274756D2E706C2F63736D696D6572736163612E63726C3081830608 2B0601050507010104773075302E06082B0601050507300186226874 74703A2F2F63736D696D6572736163612E6F6373702D63657274756D 2E636F6D304306082B060105050730028637687474703A2F2F63736D 696D6572736163612E7265706F7369746F72792E63657274756D2E70 6C2F63736D696D6572736163612E636572301F0603551D2304183016 801466FBC30FBEF4BFE09CC9AB4DDE4719BDC0CAA668301D0603551D 0E041604148D8C102E11D87004F7DDB4E04FF01781888A32A0304C06 03551D20044530433009060767810C010504023036060B2A84680186 F677026401013027302506082B06010505070201161968747470733A 2F2F7777772E63657274756D2E706C2F435053301D0603551D250416 301406082B0601050507030406082B06010505070302300E0603551D 0F0101FF0404030204F030280603551D110421301F811D6B65726E65 6C2D6572726F72406B65726E656C2D6572726F722E636F6D300D0609 2A864886F70D01010B0500038202010070724799F05CF4C821854F43 BD950BB608B989046349214F9D0EEC79F73A59DBF4063608FE5A7A7F A50CD46A15486018EB9C334418084D8F97FE32EA21CCBAFE902BF647 2DB6CA60D79EBE09919AFA0652D92CB13B506400BAF4774F3263967A 49548A6F723ADCBB715AF79705099E5EC84E283DAFA3465908F4148C 2B153C41D051C94295D4F04254217D1C8E48DF59D92ECBCB4A872EC7 28A954DAF7B661DE8037F7F10339361214163901ACFE98F3D597A67D BE87A8EE1FEC33DB71712F4907E0F3B1171E9176158189AC8229B26B 369C0FE2BBD5964CA2ABFC7D955485056102844E84E8F79E0F30BF41 D5F42B3C4F4CCA9BF9334D5728518473A0E61A3AFC88F59034F27154 6B5D806D86F1E8BC6B54B4E05F80C44835DCC2C534E419F63BBFDB30 5C1733B42DD2CC5795876F004F18C2E4D64B2C9FC6939590BE32501B 6A6CEDB19B5FBF47887C76E14C99A36D46E99B5C76782E4E345ECB37 E8886303C84849ADC8BDE1AF4E3A8096AEE407A40699D5C000ADCD16 A4805DDF8FB208FFB902EF14031CFFBE3C0DC03588EBF15557B3B102 9B2CD196064BC0DEE1F11D12391825B86CB34A6FBEBBAD43B0FE0EA4 3301F93D0B26ACED182B1E27063AE578C003D4D4498132B8D9805327 54CFFBD9E6D8917615B62AE08295FC46391AA0FD9815FDD822D95E9B 7573CA35477D59B98DE4852065F58FB60E0E620D3E2F5CAD

Was bedeutet das?
3 → Gibt an, dass es sich um einen S/MIMEA-Record handelt. Die Zahl steht für den sogenannten „Usage“-Wert, also wie das Zertifikat genutzt wird. In diesem Fall bedeutet 3, dass es für eine End-Entity-Zertifizierung gedacht ist, also für die tatsächliche E-Mail-Verschlüsselung und Signatur.

0 → Der „Selector“-Wert. Hier steht 0, was bedeutet, dass der gesamte Public Key aus dem Zertifikat gespeichert wird. Alternativ könnte 1 stehen, dann wäre nur der „Subject Public Key Info“-Teil enthalten.

0 → Gibt an, welche Hash-Funktion verwendet wird. Ist es 1, steht es für SHA-256 steht. Alternativ könnte 2 für SHA-512 verwendet werden oder, wie in unserem Fall 0, was für das komplette Zertifikat steht.

Hexwerte → Das ist der eigentliche Zertifikatsinhalt, also der öffentliche Schlüssel in hexadezimaler Darstellung.

Möchte man den kompletten DNS-Record einmal manuell auf der Konsole prüfen, geht das wie folgt:

dig +short 70e1c7d87e825b3aba45e2a478025ea0d91d298038436abde5a4c2d0._smimecert.kernel-error.com SMIMEA | sed 's/^3 0 0 //' | tr -d '[:space:]' > dns_cert.hex

Damit holen wir uns den SMIMEA-Eintrag, entfernen die vorderen 3 0 0, da diese nur die Nutzungsparameter angeben, und speichern den reinen HEX-Wert in eine Datei.

xxd -r -p dns_cert.hex dns_cert.der

Hier wandeln wir den HEX-String in eine binäre DER-Datei um.

openssl x509 -inform DER -in dns_cert.der -text -noout

So kann man sich das Zertifikat im lesbaren Format anzeigen lassen.

Und nun?

SMIMEA ist leider noch immer nicht besonders weit verbreitet. Das liegt sicherlich daran, dass das RFC noch immer experimental ist, aber auch daran, dass es auf weiteren Techniken aufbaut, die ebenfalls eher selten genutzt werden. So braucht man SMIMEA nur, wenn man überhaupt selbst ein S/MIME-Zertifikat zur Signatur und Verschlüsselung von E-Mails verwendet. Zusätzlich muss die Domain per DNSSEC geschützt sein – was noch weniger verbreitet ist – und dann muss auch noch der zusätzliche Mehrwert von SMIMEA verstanden werden.

Denn SMIMEA verteilt nicht nur die Zertifikate, sondern macht einen direkt initial verschlüsselt erreichbar. Wenn man der Empfänger einer solchen signierten Nachricht ist, kann man das Zertifikat zudem gegen eine vertrauenswürdige DNS-Zone halten und sich so vergewissern, dass es wirklich die Signatur des Absenders ist – ähnlich wie bei TLSA/DANE.

Ihr kennt das doch mit der Sicherheit im Internet: Sie ist nur relevant, wenn man damit Geld verdienen kann oder wenn man Opfer geworden ist. Die Implementierung von SMIMEA ist also aktuell sehr überschaubar. Es gibt Milter für beispielsweise Postfix oder Plugins für Thunderbird, aber vor allem im Enterprise-Umfeld ist mir momentan keine funktionierende Lösung bekannt.

Pffff… Eigentlich wollte ich doch nur schnell schreiben, dass ich da zwei Python-Skripte zusammengebastelt habe – und am Ende ist es doch wieder so ein riesiges Ding geworden. 😅

Aber ich denke, vor allem der Teil mit dem gekürzten Hash des Local-Parts der E-Mail-Adresse ist wichtig zu erklären. Das ist echt eine verrückte Konstruktion. Klar, das hat seinen Sinn, aber zumindest ich bin damals genau an diesem Punkt hängen geblieben.

Naja, jetzt könnt ihr die Skripte nutzen und euch den ganzen Fummel selbst auf der CLI anschauen, testen und vor allem auch verstehen.

Viel Spaß! 😃

B.t.w.: Das einzig korrekt funktionierende online Tool, was ich finden konnte ist: https://www.co.tt/smimea.cgi

Alle anderen sind nicht erreichbar, halten sich nicht ans RFC oder ich war zu blöde, sie zu bedienen.

Kernel-Error jetzt auch im Tor-Netz: meine .onion-Adresse

30. Juli 2024 / / Keine Kommentare

Kurzfassung: www.kernel-error.de ist jetzt zusätzlich als Tor Hidden Service erreichbar.
Meine .onion-Adresse: jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion

Damit gibt’s die Seite auch dann stabil und datensparsam, wenn Clearnet gerade zickt – oder wenn ihr grundsätzlich über Tor unterwegs seid.

Warum?

  • Datenschutz: weniger Metadaten, keine Exit-Node–Mitleser auf dem letzten Hop.
  • Integrität: über Onion-Routing direkt zu mir, kein „Dazwischenfunken“ per CDN/Proxy.
  • Erreichbarkeit: Mirror unabhängig vom Clearnet-DNS.

Wie verifizieren?

  • Auf https://www.kernel-error.de sende ich den Header Onion-Location, der auf die .onion-Version zeigt.
  • Zusätzlich gibt’s in meinem DNS einen TXT-Record der Form:
dig in txt www.kernel-error.de +short
"onion=jjyvff6eh3kp7ydfkamm27cldhsee2cl6wzfa5lfjyrfyribgeaesgqd.onion"
  • So lässt sich die Zugehörigkeit Clearnet ↔︎ Onion nachvollziehen.

Hinweise

  • Die Onion-Variante läuft ohne HTTPS – das ist bei .onion normal, Ende-zu-Ende-Schutz liefert Tor selbst.
  • Feature-Gleichstand: Seiten, Feeds und Sitemaps sind identisch erreichbar. Falls euch irgendwo ein Asset noch auf www.kernel-error.de verweist, kurzer Hinweis genügt.

Have fun & stay safe. 🧅

WordPress wp-cron.php: Ist die angebliche Sicherheitslücke real?

13. Juni 2024 / / Ein Kommentar
Picture of an hacker checken for wordpress vulnerability

In letzter Zeit begegnen mir immer wieder sogenannte „Vulnerability Report Scams“. Klar, mit Angst und Unwissenheit kann man Geld verdienen – also wird es auch jemand tun. Besonders fällt mir das im Zusammenhang mit der wp-cron.php auf.

Ich habe häufig Reports gesehen, die in etwa so aussehen:

Critical Vulnerability Report- {Critical BUG #P1} - https://www.example.com/ - vulnerable to attack via wp-cron.php

Hello  Security team,

I am a Security Engineer, Cyber Security Researcher, Bug Bounty Hunter  & Ethical Hacker. While testing your domain https://www.example.com/ I have found some important vulnerabilities in your site. 

Vulnerability Name:   https://www.example.com/  -  vulnerable to DoS attack via wp-cron.php

Vulnerable Domain:  https://www.example.com/wp-cron.php

Description: 

The WordPress application is vulnerable to a Denial of Service (DoS) attack via the wp-cron.php script. This script is used by WordPress to perform scheduled tasks, such as publishing scheduled posts, checking for updates, and running plugins.
An attacker can exploit this vulnerability by sending a large number of requests to the wp-cron.php script, causing it to consume excessive resources and overload the server. This can lead to the application becoming unresponsive or crashing, potentially causing data loss and downtime.

I found this vulnerability at https://www.example.com/wp-cron.php endpoint.


Steps to Reproduce: reference- https://hackerone.com/reports/1888723
 
navigate to: https://www.example.com/wp-cron.php
intercept the request through the burp suite
right click on the request and send it to the repeater
Now send a request, and you will see the response as  200 OK

---

this can be also done by the curl command given below

curl -I "https://www.example.com/wp-cron.php"



POC: Attached 

Impact:

If successful, this misconfigured wp-cron.php file can cause lots of damage to the site, such as:

Potential Denial of Service (DoS) attacks, resulting in unavailability of the application.
Server overload and increased resource usage, leading to slow response times or application crashes.
Potential data loss and downtime of the site.
Hackers can exploit the misconfiguration to execute malicious tasks, leading to security breaches.

Exploitation: 
Exploitation can be done through a GitHub tool called doser.go https://github.com/Quitten/doser.go
I did not do that as this can impact your website.
Get the doser.py script at https://github.com/Quitten/doser.py
Use this command to run the script: python3 doser.py -t 999 -g 'https://www.example.com/wp-cron.php'
Go after https://www.example.com/ 1000 requests of the doser.py script.
The site returns code 502.

Suggested Mitigation/Remediation Actions:

To mitigate this vulnerability, it is recommended to disable the default WordPress wp-cron.php script and set up a server-side cron job instead. Here are the steps to disable the default wp-cron.php script and set up a server-side cron job:
Access your website's root directory via FTP or cPanel File Manager.
Locate the wp-config.php file and open it for editing.
Add the following line of code to the file, just before the line that says "That's all, stop editing! Happy publishing.":

1define('DISABLE_WP_CRON', true);

Save the changes to the wp-config.php file.
Set up a server-side cron job to run the wp-cron.php script at the desired interval. This can be done using the server's control panel or by editing the server's crontab file.
References:

For more information about this vulnerability, please refer to the following resources:

https://hackerone.com/reports/1888723

https://medium.com/@mayank_prajapati/what-is-wp-cron-php-0dd4c31b0fee


Cron


Fix Them 

-----

I have protected your company and saved it from a big loss so give me some appreciation Bounty  Reward.

I am sharing my PayPal ID with you.  

Paypal ID:  woop woop


Current  Market  Value Minimum  Bounty  Reward for Critical BUG  P1 Type.    

The bug I reported is part of type P1


 
Vulnerability severity	Bug bounty reward amount (in USD)
P1 (Critical)	$2500
P2 (High)	$1500
P3 (Medium)	$1000
P4 (Low)	$500


Please feel free to let me know if you have any other questions or need further information. 

I am happy to secure it.


I hope this will be fixed soon. Feel free to let me know if you have any other questions.

Thanks & Regards

Ist das nun ein echtes Problem oder nicht?

Nun… Ja und Nein. In der Nachricht wird korrekt beschrieben, was die wp-cron.php tut und warum sie wichtig ist. Auch die Tatsache, dass sie extern unendlich oft aufgerufen werden kann und dadurch potenziell eine Überlastung auslösen könnte, ist nicht falsch. Selbst der Tipp, auf eine lokale Crontab-Version umzusteigen, ist nicht verkehrt. Allerdings muss man das Ganze in den richtigen Kontext setzen: wp-cron.php ist standardmäßig in WordPress aktiviert und wird für geplante Aufgaben genutzt. Die geplanten Aufgaben werden in der Datenbank abgelegt, gibt es etwas zutun und die wp-cron.php wird aufgerufen, dann wird auch gearbeitet, gibt es nichts zutun, dann gibt es auch keine Arbeit. Die Empfehlung, sie zu deaktivieren und durch einen serverseitigen Cron-Job zu ersetzen, ist eher eine Performance-Optimierung als eine echte Sicherheitsmaßnahme.

Es handelt sich hierbei nicht um einen Zero-Day-Exploit und es gibt keine direkte Gefahr eines Datenabflusses. Falls es wirklich zu Performance-Problemen kommt, gibt es einfache Gegenmaßnahmen. Sollte tatsächlich jemand versuchen, die wp-cron.php gezielt anzugreifen, hilft ein simples Rate Limiting – entweder über die Firewall oder direkt mit mod_security (Apache) bzw. limit_req (nginx).

Ein Beispiel für nginx:

limit_req_zone $binary_remote_addr zone=cronlimit:10m rate=1r/s;

server {
    location = /wp-cron.php {
        limit_req zone=cronlimit burst=3 nodelay;
        limit_req_status 429;
    }
}

Das begrenzt die Anfragen auf 1 Anfrage pro Sekunde, mit maximal 3 Anfragen in kurzer Zeit.

Sollte man wp-cron.php einfach deaktivieren?

Nicht unbedingt. Klar, im Fall eines Angriffs kann das als erste Maßnahme helfen. Besser ist es aber, wp-cron.php lokal auszuführen und den Zugriff darauf über den Webserver auf bestimmte IP-Adressen zu beschränken – zum Beispiel die lokale des Webservers. Anschließend kann man einen Cronjob anlegen, der alle 15 Minuten ausgeführt wird:

*/15 * * * * wget -q -O - https://www.example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Zugriff per nginx einschränken:

location ~* ^/wp-cron.php$ {
    allow 1.2.3.4;  # Ersetze mit deiner IP
    deny all;
}

Fazit:

Das ist ganz sicher kein P1-Bug. Und wenn der Report direkt eine Preistabelle mitliefert, ist das schon ein ziemlich eindeutiges Zeichen für einen Scam.

Zusammengefasst:

  • Ja, wp-cron.php könnte unter bestimmten Umständen zu Problemen führen.
  • Nein, es ist kein echter Sicherheits-Bug.
  • Wer weiß, was er tut, hat bereits die richtigen Maßnahmen getroffen.

Also: Keine Panik. Stattdessen lieber kurz die eigene Konfiguration prüfen und gut ist.

Wer auf das nginx Rate Limit setzt und dieses einfach testen möchte, kann das folgende Bash-Script nutzen: rate_limit_test.sh

08-03-2025 kleines Update. Das script ist zu github gewechselt.

FreeBSD SSH-Server absichern: MFA mit Google Authenticator einrichten​

29. März 2024 / / Keine Kommentare

Dass man eigentlich keinen reinen Kennwort-Login für seine Anmeldung an einem SSH-Server haben möchte, ist sicherlich bei fast allen angekommen. Kennwörter lassen sich einfacher mittels eines Brute-Force-Angriffes herausfinden. Ebenso gehen diese auch mal verloren. SSH-Keys werden die meisten ebenfalls bereits aufseiten des Clients mit einem zweiten Faktor geschützt haben. Dies kann ein MFA-Token sein oder einfach eine Passphrase.

Hin und wieder lässt es sich aber nicht vermeiden, dass man seinen Login nur mit einer einfachen Kombination aus Benutzername und Kennwort sichert. Um dieses dennoch etwas aufzuwerten, lässt sich dieses ebenfalls mit MFA ausstatten. In diesem kurzen Beispiel geht es dabei um einen SSH-Server auf einem FreeBSD-System, welches nach der Authentifizierung mittels Benutzername/Kennwort noch nach einem Auth-Code vom Google Authenticator fragt.

Clientseitig ist eigentlich nichts weiter zu beachten. Auf Serverseite muss das Paket pam_google_authenticator installiert werden:

pkg install pam_google_authenticator

Ist die Installation abgeschlossen, müssen wir nun unsere PAM-Konfiguration für den SSHD-Password-Login erweitern. Oh, ja… Auf demselben Weg lässt sich dieses ebenfalls für den normalen Login an der Konsole, für su, ftp usw. einbinden. Selbstverständlich ebenfalls für den Login per SSH-Keys. Wir bleiben aber hier nun beim Login mit User/Pass. Meine /etc/pam.d/sshd sieht damit wie folgt aus:

#
#
# PAM configuration for the "sshd" service
#

# auth
#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
auth		required	pam_unix.so		no_warn try_first_pass
auth            required        /usr/local/lib/pam_google_authenticator.so

# account
account		required	pam_nologin.so
#account	required	pam_krb5.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
#session	optional	pam_ssh.so		want_agent
session		required	pam_permit.so

# password
#password	sufficient	pam_krb5.so		no_warn try_first_pass
password	required	pam_unix.so		no_warn try_first_pass

Ebenfalls muss die folgende Option in der /etc/ssh/sshd_config aktiviert sein:

ChallengeResponseAuthentication yes

Das war es auch schon fast. Wenn man nun auf seinem Smartphone noch schnell den Google Authenticator installiert, können wir schon damit beginnen, den zweiten Faktor zu erstellen. Dafür einfach mit dem gewünschten Nutzer in dessen Home-Verzeichnis: „cd ~“ den google-authenticator aufrufen und den Anweisungen folgen:

Dieses nur noch mit der Authenticator-App am Smartphone scannen, den Code einmal eingeben und schon wird man bei jedem Kennwort-Login nach seinem aktuellen Code gefragt.

Oh, sehr ähnlich ist die Einrichtung unter Linux 🙂

DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server​

18. März 2022 / / 7 Kommentare

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.

Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.

Bilder der Bind 9 TLS Konfiguration

Zu diesem Zeitpunkt bracht BIND 9 die Unterstützung für DoH und DoT noch nicht selbst mit. Daher waren zu diesem Zeitpunkt noch Umwege über stunnel oder nginx zusammen mit doh-proxy nötig.

Zum Glück kommt die letzte stable Version 9.18.0 (26. Januar 2022) mit dem nötigen Support.

named now supports securing DNS traffic using Transport Layer Security (TLS). TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH).

Warum möchte man noch gleich DoH oder DoT benutzen? Ganz einfach… Über diese Techniken werden DNS Abfragen verschlüsselt übertragen. Dieses ist ein weiterer Schutz davor manipulierte Antworten zu bekommen und selbstverständlich, damit die eigenen DNS Abfragen erst überhaupt nicht mitgelesen werden. Denn wenn von einem Gerät im Netzwerk die DNS Abfrage zu z.B.: www.tagesschau.de kommt, könnte man davon bereits Dinge ableiten.

Wie die meisten Bind Konfigurationen ist dieses ebenfalls straightforward. Ab Version 9.18 bringt Bind alles Nötige mit. Da wir nun TLS mit dem Bind sprechen möchten, benötigen wir natürlich ein gültiges Zertifikat, wie z.B. beim nginx für seine Webseite.

Ebenfalls sollte man ein paar frische Diffie-Hellmann Parameter generieren:

openssl dhparam -out dhparam.pem 4096

Die eigentliche bind Konfiguration kann in der named.conf.options geschehen:

options {
        [...]
        listen-on port 853 tls local-tls { 37.120.183.220; };
        listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; };
        listen-on port 443 tls local-tls http default { 37.120.183.220;  };
        listen-on-v6 port 443 tls local-tls http default { 2a03:4000:38:20e::853; };
        [...]
        allow-recursion-on { 127.0.0.0/8; ::1/128; 2a03:4000:38:20e::853; 37.120.183.220; };
        [...]
};

Da der bind auf weiteren Ports lauschen soll erweitert man diese für IPv4 und IPv6. Der Default Port für DoH ist dabei 443 und der default Port für DoT ist 853, beides TCP.

listen-on sowie listen-on-v6 sind wohl selbsterklärend.
port ist der TCP Port und erklärt sich ebenfalls.
tls sagt dem Bind das wir tls sprechen möchten.
local-tls verweißt auf den gleichnamigen tls Block über welchen man seine TLS Konfiguration vornimmt.
http ist für DoH.
default gibt den eigentlichen endpoint für die DoH Abfragen an, im default ist es /dns-query

Da der Server unsere DNS Abfragen erledigen soll, müssen wir ihm dieses noch per allow-recursion-on auf den jeweiligen Adressen erlauben.

Als nächstes wird die eigentliche TLS Terminierung konfiguriert (das lässt sich ebenfalls auslagern, wenn gewünscht). Dafür wird der folgende Block, außerhalb der Options Blocks, ergänzt:

tls local-tls {
    cert-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/chain.crt";
    key-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/http.key";
    dhparam-file "/usr/local/etc/ssl/dhparam.pem";
    protocols { TLSv1.2; TLSv1.3; };
    ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
    prefer-server-ciphers yes;
    session-tickets no;
};

local-tls ist dabei der name des Blocks. Auf diesen verweisen wir oben.
cert-file ist der Pfad zum Zertifikat. Ich habe dort nicht nur das Zertifikat, sondern die gesamte Chain, also mit Intermediate und Root.
key-file ist der Pfad zum Key des Zertifikates.
dhparam-file ist der Pfad zu den Diffie-Hellman Parametern.
protocols definiert die zu verwendenden TLS Protokolle. In diesem Beispiel TLS1.2 sowie TLS1.3.
ciphers definiert die zu verwendenden cipher. Es soll ja „sicher“ bleiben.
prefer-server-ciphers übermittelt dem Client die Information, in welcher Reihenfolge protokoll/cipher Kombinationen probiert werden sollen um einen Match zu finden. Erst das vermeintlich sicherste und dann immer „schlechter“.
session-tickets regelt ob eine Wiederaufnahme von TLS Sessions erlaubt ist oder nicht. Da ich forward secrecy nutzen möchte, ist es deaktiviert.

Damit ist die Konfiguration schon abgeschlossen (Firewall ggf. nicht vergessen!). Also testen….

Ein einfaches Tool dafür ist dog, oder natürlich dig aus den bind-tools aber Version 9.18. Für bind gibt es dann die Optionen +https oder auch +tls

dig +https @dns.kernel-error.de www.kernel-error.de A
dig +tls @dns.kernel-error.de www.kernel-error.de A

Der gleiche Test mit dog, sieht wie folgt aus:

dog www.kernel-error.de --tls "@dns.kernel-error.de"
A www.kernel-error.de. 6h00m00s   148.251.40.23
dog www.kernel-error.de --https "@https://dns.kernel-error.de/dns-query"
A www.kernel-error.de. 6h00m00s   148.251.40.23

Das war es auch schon! Viele Spaß mit einem „besseren“ DNS und wenn es noch Fragen gibt, einfach fragen 🙂

Dead-Link-Checker für die Konsole: Effektive Tools im Überblick

14. Februar 2022 / / Keine Kommentare

Tote Links auf einer Webseite zu suchen, kann aufwendig sein. Es gibt viele Angebote im Internet, diese sind aber meist auf eine gewisse Anzahl Seiten beschränkt und ab dann kostenpflichtig.

Ich mag Tools, die einen Job gut können und dieses möglichst einfach erledigen. Daher habe ich für diesen Fall den LinkChecker für die CLI.

404 ERROR mit totem gehäkelten Link von Selder.

Das Tool ist schnell per pip installiert:

pip3 install linkchecker

Die Bedienung ist nicht viel komplizierter:

linkchecker https://www.kernel-error.de

Ohne weitere Angaben läuft das Tool mit 10 threads los, dieses lässt sich über die Option -t erweitern:

linkchecker -t 200 https://www.kernel-error.de

Nun läuft das Tool über die komplette Webseite und prüft alle Links, ist einer kaputt, meldet das Tool dieses. Dabei bekommt man direkt die Informationen, was verlinkt wurde, was der eigentliche Link ist und auf welcher seiner Seiten sich dieses befindet. So lässt sich ohne große Mühe und Arbeit nach toten Links suchen und diese im Anschluss beheben.

URL        `www.kernel-error.de'
Parent URL https://www.kernel-error.de/en/lala/seite, line 746, col 17
Real URL   https://www.kernel-error.de/en/lala/zeugen
Check time 67.089 seconds
Result     Error: 404 Not Found

Viel Spaß!

Link zur Dead Link Bild Quelle: https://www.deviantart.com/amiamalilium/art/It-looks-like-you-found-a-dead-link-365756737

« Ältere Beiträge

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑