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

Schlagwort: SelfHosted (Seite 2 von 7)

Jetzt mit HTTP/3 und QUIC: Schnelleres Surfen leicht gemacht

Von QUIC habt ihr sicher alle schon gehört, seit knapp Mitte 2021 ist dieser neue Standard fertig und in einem recht einfach zu merkendem RFC 9000 beschrieben.

Im Grunde geht es darum, HTTP-Verbindungen schneller zu machen und dabei sogar UDP zum Einsatz zu bringen. Nicht ganz korrekt ist es einfach eine Weiterentwicklung von SPDY.

Um zu testen, ob eine Webseite bereits HTTP/3 also QUIC unterstützt, kann ich euch http3check.net ans Herz legen. Diese gibt, wenn gewünscht, sogar noch ein paar Detailinformationen aus.

Wer sehen möchte, ob sein Browser QUIC „macht“, kann auch nginx.org nutzen. Steht oben „Congratulations! You’re connected over QUIC.“ Dann ist man ein Gewinner.

Die Konfiguration am Nginx ist wie immer sehr einfach und ein sehr gutes Beispiel findet sich direkt von nginx.

Mein Nginx spricht dieses nun ebenfalls, mal sehen ob es Probleme gibt.


Update März 2026: Drei Jahre HTTP/3 im Betrieb

Es sind jetzt gut drei Jahre vergangen und ich kann sagen: Es gab keine Probleme. Kein einziges. HTTP/3 läuft hier seit 2022 auf allen vHosts und ich habe nie einen Fehler gesehen, der auf QUIC zurückzuführen war. Auch in den Logfiles nichts Auffälliges.

Illustration zu HTTP/3 und QUIC: schneller Web-Transport über UDP mit moderner Verschlüsselung und Browser-Support

Was sich geändert hat: Damals war HTTP/3 in Nginx noch experimentell und brauchte einen separaten Build mit dem quiche-Patch oder BoringSSL. Seit Nginx 1.25.0 (Mai 2023) ist HTTP/3 offiziell im Mainline-Branch enthalten und wird mit dem normalen --with-http_v3_module Build-Flag aktiviert. Kein Patch mehr, kein BoringSSL mehr, einfach OpenSSL 3.x und fertig. Mein aktueller Stack: Nginx 1.29.4 mit OpenSSL 3.5.4 auf FreeBSD 15.

Was bringt HTTP/3 in der Praxis?

Der größte Vorteil von QUIC gegenüber TCP ist die Verbindungsaufbauzeit. Bei TCP+TLS braucht ihr mindestens zwei Roundtrips, bevor Daten fließen (TCP Handshake + TLS Handshake). QUIC macht das in einem einzigen Roundtrip. Bei einem Wiederverbindungsversuch sogar in null Roundtrips (0-RTT).

Auf einer Glasfaserleitung mit 5 ms Latenz merkt ihr das kaum. Aber auf einem Smartphone im Zug mit 80 ms Latenz und gelegentlichem Paketverlust macht das einen spürbaren Unterschied. Dazu kommt, dass QUIC auf UDP basiert und damit das Head-of-Line-Blocking Problem von TCP löst: Ein verlorenes Paket blockiert nicht mehr alle Streams, sondern nur den einen betroffenen.

Konfiguration 2026

Die Konfiguration hat sich seit 2022 etwas verändert. Hier mein aktuelles Setup für den Blog-vHost:

server {
    listen [::]:443 ssl;
    listen [::]:443 quic;

    http2 on;

    server_name  www.kernel-error.de;

    # TLS (wird per include eingebunden)
    include tls-default.conf;
    ssl_certificate      /path/to/fullchain.pem;
    ssl_certificate_key  /path/to/privkey.pem;

    # ...
}

Wichtig sind zwei Dinge. Erstens: Der quic Listener läuft auf demselben Port 443 wie der SSL-Listener, nur eben über UDP statt TCP. Zweitens: Die Clients müssen wissen, dass HTTP/3 verfügbar ist. Das passiert über den Alt-Svc Header:

add_header Alt-Svc 'h3=":443"; ma=86400' always;

Dieser Header sagt dem Browser: „Ich spreche auch h3 auf Port 443, merk dir das für 24 Stunden.“ Beim nächsten Besuch nutzt der Browser dann direkt QUIC. Ohne diesen Header bleibt alles bei HTTP/2 über TCP.

Optional könnt ihr auch einen HTTPS-DNS-Record (SVCB) setzen, damit der Browser schon beim DNS-Lookup weiß, dass HTTP/3 verfügbar ist:

$ dig +short HTTPS www.kernel-error.de
1 . alpn="h3,h2" ipv4hint=148.251.30.200 ipv6hint=2a01:4f8:262:4716::443

Mit alpn="h3,h2" im HTTPS-Record kann der Browser die QUIC-Verbindung schon beim allerersten Besuch aufbauen, ohne erst auf den Alt-Svc Header warten zu müssen.

Firewall nicht vergessen

Ein Klassiker, der mich 2022 kurz stolpern ließ: QUIC braucht UDP Port 443. Wenn eure Firewall nur TCP 443 durchlässt, sehen die Clients den Alt-Svc Header, versuchen QUIC und laufen ins Timeout. Auf FreeBSD mit pf:

pass in quick on $ext_if proto udp to $jail_nginx port 443

Post-Quantum-Kryptografie inklusive

QUIC verwendet intern TLS 1.3 für die Verschlüsselung. Das heißt: Wenn ihr in eurer Nginx-TLS-Konfiguration X25519MLKEM768 als Key-Exchange-Gruppe konfiguriert habt, gilt das automatisch auch für QUIC-Verbindungen. Kein extra Aufwand. Euer HTTP/3 Traffic ist dann ebenfalls mit hybridem Post-Quantum-Schlüsselaustausch abgesichert.

Browser-Support

2022 war HTTP/3 noch ein Feature für Early Adopter. 2026 ist es Standard. Chrome, Firefox, Safari und Edge unterstützen QUIC seit Jahren. Laut den Logfiles dieses Blogs nutzen inzwischen gut 40% der Besucher HTTP/3. Tendenz steigend, weil immer mehr Mobilgeräte von dem schnelleren Verbindungsaufbau profitieren.

Wer es noch nicht aktiviert hat: Der Aufwand ist minimal, die Vorteile real und das Risiko gleich null. Drei Jahre Betrieb ohne ein einziges Problem sprechen für sich.

Siehe auch: HTTPS RR und SVCB Records — per DNS-Record signalisieren, dass HTTP/3 verfügbar ist. Damit können Clients direkt mit QUIC starten, ohne vorher TCP zu probieren.

Wechsel zur WordPress

Ich nutze Joomla seit 2006, als es aus Mambo hervorging. Die Datenbank und einige Plugins/Teils sind inzwischen also sehr alt und machen bei Versionssprüngen immer mehr Probleme. Den Wechsel vom CMS habe ich dennoch immer von mir weggeschoben, denn es macht viel Arbeit und für eine solch kleine Spielerei lohnt der Aufwand kaum. Da ich es inzwischen eh nur noch für einfache Blogeinträge nutze… Nun ich werde wohl in der nächsten Zeit auf WordPress wechseln. Damit wird es ebenfalls einen neuen RSS Feed geben und sicher wird ebenfalls viel Content verschwinden.

Fragen? Einfach melden.

MikroTik CRS305-1G-4S+IN: Der 10-Gbit-Switch für 130 Euro im Langzeittest

Den MikroTik CRS305-1G-4S+IN habe ich Ende 2020 in meinem Arbeitszimmer in Betrieb genommen. Workstation, Storage, Hauptswitch und Windows-PC hängen seitdem an seinen vier SFP+ Ports. Fünf Jahre später läuft das Teil immer noch ohne Ausfall und ich denke es ist Zeit für ein ehrliches Update.

Damals lag der Preis bei knapp über 100 Euro, aktuell zeigt mir Amazon 131,62 Euro an. Klingt nach Inflation, ist für einen managebaren 4-Port 10-Gbit-Switch trotzdem immer noch ein Witz.

Was bekommt man fürs Geld?

An der Hardware hat sich seit dem Erstkauf nichts geändert: Vier SFP+ Ports mit 10 Gbit/s, dazu ein Gigabit-Port für Out-of-Band-Management. Komplett lüfterlos, das Metallgehäuse dient als Kühlkörper. Stromversorgung wahlweise per Steckernetzteil, über den zweiten Netzteil-Anschluss redundant oder per PoE-In über den Management-Port. Wer es ernst meint mit Hochverfügbarkeit, packt drei verschiedene Quellen drauf.

Auf der Unterseite sind Bohrungen für die Wandmontage. Bei mir hängt der Switch seit Jahren an genau dieser Stelle.

RouterOS, jetzt in Version 7

Auf dem Gerät läuft echtes RouterOS, kein abgespecktes SwitchOS-Light. Vor ein paar Jahren bin ich von Version 6 auf 7 umgestiegen, der Sprung lief schmerzfreier als befürchtet. Container-Support, eine neue Routing-Engine, in-kernel WireGuard, ROSE-storage. Für den CRS305 in reiner Switch-Funktion ist das meiste davon Overkill, aber der gleiche Software-Stack läuft auf allen MikroTik-Geräten und das einmal gelernte Wissen ist übertragbar.

Wer den Switch wirklich nur als Switch braucht und das volle Routing-Featureset nicht will, kann alternativ SwOS einspielen. Ich bleibe bei RouterOS, weil ich VLANs, VRRP und gelegentlich mal eine kleine Bridge mit eigenen Regeln nutze.

Härtung: das was 2021 noch keiner gesagt hat

In den letzten Jahren ist MikroTik mehrfach unangenehm aufgefallen. Botnetze auf nicht aktualisierten RouterOS-Geräten (Mēris, TrickBot, VPNFilter), mehrere Webfig-Authentifizierungs-Bypässe, dazu der Klassiker: Default-User „admin“ ohne Passwort. Wer so ein Gerät ohne Härtung ans Internet hängt oder auch nur ohne Trennung ins LAN, hat sich selbst beschenkt.

Mein Standardvorgehen direkt nach dem Auspacken sieht ungefähr so aus:

/user add name=adminneu group=full password=...
/user remove admin
/ip service disable telnet,ftp,www,api,api-ssl
/ip service set winbox address=192.168.X.0/24
/ip service set ssh address=192.168.X.0/24
/system clock set time-zone-name=Europe/Berlin
/system ntp client set enabled=yes servers=pool.ntp.org
/system package update check-for-updates
/system routerboard upgrade

Webfig und API mögen bequem sein, ich brauche beides nicht. Telnet und FTP haben auf einem Gerät von 2026 nichts mehr verloren. Wer trotzdem das Webinterface nutzen will, sollte zumindest auf HTTPS umstellen und die Zugriffe auf das Management-Subnetz beschränken.

Auto-Update gibt es bei MikroTik leider noch immer nicht out-of-the-box. Ich habe mir einen kleinen Cron-Job gebaut, der einmal im Monat anpingt ob ein Update da ist. Manuell einspielen muss ich es dann selbst, weil mir bei einem zentralen Netzwerkgerät ein automatisches Reboot mitten in der Nacht zu heikel ist.

SFP+ Module und DAC-Kabel

MikroTik ist da angenehm tolerant: vendor-locked Module von Cisco, Juniper oder HPE fliegen in der Regel ohne Murren rein. In meinen vier Ports stecken aktuell zwei FS.com-Module mit LWL, ein generisches Kupfer-DAC zur Workstation und ein 10GBASE-T-Adapter ans Storage. Alles funktioniert, kein Kabel oder Modul zickt.

Vorsicht bei 10GBASE-T-Adaptern: die werden warm. Sehr warm. Bei zwei oder mehr Stück im engen Gehäuse kann der Switch im Sommer am thermischen Limit kratzen. Wer kann, sollte LWL oder DAC bevorzugen, das ist effizienter und kühler. DACs sparen außerdem die Modul-Kosten und bringen Latenzen, die mit aktiven Modulen schlicht nicht zu erreichen sind.

Stromverbrauch

Bei mir liegt der Verbrauch im Mittel zwischen 8 und 12 Watt, je nach Bestückung. Mit zwei 10GBASE-T-Adaptern kann es Richtung 14 bis 16 Watt gehen. Für einen 24/7 laufenden Switch ist das vertretbar, in Zeiten von Stromrechnungen die jedes Jahr neue Höchststände erreichen sollte man es zumindest wissen.

Markt 2026: Alternativen

2021 war der CRS305 in seiner Preisklasse fast konkurrenzlos. 2026 sieht das anders aus. Ein paar Optionen, die ich heute mit auf die Liste setzen würde:

  • MikroTik CRS309-1G-8S+IN: Doppelte Portzahl, gleicher Aufbau, etwa 250 bis 300 Euro. Wenn vier Ports knapp werden, der logische Schritt nach oben.
  • MikroTik CRS310-1G-5S-4S+IN: Mischmasch aus 1G/2.5G und 4× SFP+, brauchbar wenn das eigene Netz nicht komplett auf 10G migriert ist.
  • TP-Link TL-SX3008F: 8× SFP+ JetStream-Smart-Switch, kein RouterOS aber gepflegtes Webinterface, etwa 250 Euro. Für reines Switchen oft entspannter als RouterOS.
  • QNAP QSW-M408S: 4× SFP+ plus 4× 1G, simples Web-UI, knapp 280 Euro. Gut für Leute, die kein RouterOS lernen wollen.
  • Ubiquiti USW-Aggregation: 8× SFP+ mit Web-Controller, etwa 280 Euro. Wer schon im UniFi-Ökosystem unterwegs ist, will sowieso nichts anderes.

Für den absoluten Einstieg in 10G zuhause, mit kleinem Budget und der Bereitschaft sich kurz mit RouterOS zu beschäftigen, ist der CRS305 weiterhin der beste Deal. Wer mehr Ports braucht oder das Routing-Featureset gar nicht erst anfassen will, sollte einen der oben genannten in die engere Wahl nehmen.

Fazit nach 5 Jahren

Das Gerät ist seit 2021 ohne einen einzigen Ausfall durchgelaufen, hat zwei Wohnungswechsel und mehrere RouterOS-Major-Updates überlebt. Bei aktuell 131,62 Euro auf Amazon oder direkt von MikroTik bleibt es eine klare Empfehlung. Mit der Einschränkung, dass man die paar Minuten in Härtung investieren sollte, sonst wird aus dem schönen kleinen Switch schnell ein Botnet-Knoten.

Ich mache ja eher selten Werbung für ein Produkt, aber dieser Switch hat sich nach fünf Jahren als die beste Empfehlung herausgestellt, die ich in dieser Preisklasse jemals geben konnte.

Siehe auch: IPv6 Prefix Delegation: FritzBox und MikroTik und Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt.

Fragen? Einfach melden.

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

Rspamd hat ein Webinterface. Da kann man E-Mails reinkopieren und als Spam oder Ham markieren. Klingt erstmal praktisch. Ist es aber nicht. Niemand kopiert ernsthaft den Quellcode jeder fehlklassifizierten Mail in ein Webformular. Das macht man einmal zum Testen und dann nie wieder.

Automatisches Spam-Training mit Rspamd über Dovecot IMAPSieve – Mail wird zwischen Inbox und Junk verschoben

Was man eigentlich will: Wenn ein Benutzer eine Mail in den Junk-Ordner verschiebt, soll rspamd das automatisch als Spam lernen. Und wenn eine Mail aus dem Junk-Ordner rausgeholt wird, soll rspamd sie als Ham lernen. Kein Webinterface, kein manueller Eingriff. Der Benutzer sortiert einfach seine Mails — und rspamd lernt mit.

Genau das geht mit Dovecot und IMAPSieve. Hier beschreibe ich, wie ich das bei mir eingerichtet habe. Die Konfiguration läuft seit Mai 2020 unverändert — über sechs Jahre, ohne eine einzige Anpassung. Das darf man ruhig als stabil bezeichnen.

Was passiert da eigentlich

Der Datenfluss ist simpel:

  • Benutzer verschiebt eine Mail in den Ordner „Junk“
  • Dovecot erkennt die Verschiebung per IMAPSieve
  • IMAPSieve startet ein Sieve-Script
  • Das Sieve-Script ruft ein Shell-Script auf
  • Das Shell-Script übergibt die Mail per rspamc an rspamd
  • Rspamd lernt die Mail als Spam (Bayes-Klassifikator)

In die andere Richtung genauso: Mail raus aus Junk, Dovecot erkennt es, rspamd lernt Ham. Egal ob der Benutzer über Thunderbird, Roundcube, ein Smartphone oder was auch immer sortiert — solange es IMAP ist, greift das.

Voraussetzungen

  • Dovecot mit Sieve-Support (dovecot-pigeonhole unter FreeBSD, dovecot-sieve unter Debian/Ubuntu)
  • Rspamd mit laufendem Controller-Worker
  • rspamc CLI-Tool (kommt mit rspamd mit)

Mein Setup läuft auf FreeBSD. Die Pfade beginnen daher mit /usr/local/. Unter Linux ist es /etc/dovecot/ statt /usr/local/etc/dovecot/ und /usr/lib/dovecot/ statt /usr/local/libexec/dovecot/. Ansonsten ist alles identisch.

Mein rspamd läuft in einer eigenen Jail und lauscht auf 127.0.0.3:11334. Wer rspamd lokal auf dem gleichen System hat, nimmt stattdessen 127.0.0.1:11334 oder den Unix-Socket.

Dovecot konfigurieren

Zuerst muss das Sieve-Plugin für IMAP aktiviert werden.

20-imap.conf:

protocol imap {
  mail_plugins = $mail_plugins sieve
}

Dann die IMAPSieve-Konfiguration. Hier wird festgelegt, welche Ordner-Aktionen welches Sieve-Script auslösen.

90-plugin.conf:

plugin {
  sieve_plugins = sieve_imapsieve sieve_extprograms

  # Wenn eine Mail in den Junk-Ordner kopiert oder dort ein Flag geaendert wird
  imapsieve_mailbox1_name = Junk
  imapsieve_mailbox1_causes = COPY FLAG
  imapsieve_mailbox1_before = file:/usr/local/etc/dovecot/sieve/report-spam.sieve

  # Wenn eine Mail AUS dem Junk-Ordner woanders hin verschoben wird
  imapsieve_mailbox2_name = *
  imapsieve_mailbox2_from = Junk
  imapsieve_mailbox2_causes = COPY
  imapsieve_mailbox2_before = file:/usr/local/etc/dovecot/sieve/report-ham.sieve

  sieve_pipe_bin_dir = /usr/local/libexec/dovecot

  sieve_global_extensions = +vnd.dovecot.pipe
}

Zwei Trigger: Einer für „Mail landet im Junk“ (→ Spam lernen), einer für „Mail verlässt Junk“ (→ Ham lernen). COPY deckt Verschieben ab, FLAG fängt den Fall ab, dass ein Mail-Client den Junk-Status per Flag statt per Verschieben setzt.

Sieve-Scripts

Jetzt die beiden Sieve-Scripts, die von IMAPSieve aufgerufen werden.

report-spam.sieve — wird ausgelöst, wenn eine Mail im Junk-Ordner landet:

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

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

# Beantworteten oder weitergeleiteten Spam ebenfalls lernen
elsif anyof (allof (hasflag "\\Answered",
                    environment :contains "imap.changedflags" "\\Answered"),
             allof (hasflag "$Forwarded",
                    environment :contains "imap.changedflags" "$Forwarded")) {
    pipe :copy "sa-learn-spam.sh";
}

Der erste Block fängt das normale Verschieben ab. Der zweite Block ist für einen Sonderfall: Wenn jemand auf eine Mail im Junk-Ordner antwortet oder sie weiterleitet, ändert sich das Flag — und auch das sollte als Spam gelernt werden.

report-ham.sieve — wird ausgelöst, wenn eine Mail den Junk-Ordner verlässt:

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

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

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

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

Hier passiert etwas Wichtiges: Bevor die Mail als Ham gelernt wird, prüfen wir wohin sie verschoben wurde. Wenn sie im Papierkorb landet, war das vermutlich kein „Das ist kein Spam“ sondern ein „Ich lösche den Spam“. Deshalb: stop; für Trash und die Trainingsordner. Nur wenn die Mail in einen echten Ordner verschoben wird, ist es ein Ham-Signal.

Beide Scripts müssen kompiliert werden:

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

Shell-Scripts für rspamc

Die Sieve-Scripts rufen Shell-Scripts auf, die die Mail per rspamc an rspamd übergeben. Simpel — jeweils ein Einzeiler.

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

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

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

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

Die Dateinamen sa-learn-* kommen historisch von SpamAssassin. Verwirrend, wenn man rspamd nutzt. Man könnte sie auch rspamd-learn-spam.sh nennen — funktional ist es egal. Ich habe sie so gelassen, weil man funktionierende Dinge nicht anfasst.

Beide ausführbar machen:

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

Wer rspamd lokal laufen hat, ersetzt 127.0.0.3 durch 127.0.0.1 oder nutzt den Unix-Socket (-h /var/run/rspamd/rspamd.sock). Unter Linux liegen die Scripts in /usr/lib/dovecot/ statt /usr/local/libexec/dovecot/. Der Pfad in sieve_pipe_bin_dir muss natürlich dazu passen.

Wichtig: Damit rspamc ohne Passwort trainieren darf, muss die IP im rspamd Controller-Worker als vertrauenswürdig eingetragen sein. In /usr/local/etc/rspamd/local.d/worker-controller.inc (FreeBSD) bzw. /etc/rspamd/local.d/worker-controller.inc (Linux):

secure_ip = "127.0.0.0/8";
secure_ip = "::1";

Ohne das schlägt rspamc learn_spam mit einem Authentifizierungsfehler fehl. Bei Jail-Setups wie meinem muss die Jail-IP (127.0.0.3) in der Liste stehen.

Testen

Dovecot neu laden:

service dovecot reload

Dann eine beliebige Mail in den Junk-Ordner verschieben und im rspamd-Log nachschauen:

rspamd_controller_learn_fin_task: <127.0.0.3> learned message as spam: MESSAGE-ID

Mail wieder raus aus Junk in den Posteingang:

rspamd_controller_learn_fin_task: <127.0.0.3> learned message as ham: MESSAGE-ID

Wenn das im Log steht, funktioniert alles. Kein Neustart nötig, kein Cache-Flush, kein Warten.

Wie viel Training braucht rspamd

Rspamd nutzt einen Bayes-Klassifikator. Der braucht eine Mindestmenge an gelernten Nachrichten, bevor er aktiv wird. Die Standardeinstellung ist 200 — also mindestens 200 Spam-Mails und 200 Ham-Mails. Vorher ignoriert rspamd die Bayes-Ergebnisse komplett.

Das klingt nach viel, geht aber schneller als man denkt. Wer ein paar Dutzend Benutzer auf dem Server hat, kommt da in wenigen Wochen hin. Und danach wird rspamd mit jeder sortierten Mail ein bisschen besser.

Den aktuellen Stand kann man jederzeit prüfen:

rspamc stat

Unter Statfile sieht man wie viele Nachrichten rspamd bereits gelernt hat.

Rspamd trainiert standardmäßig einen globalen Bayes-Klassifikator — alle Benutzer lernen in denselben Pool. Wer das pro Benutzer trennen will, setzt in der classifier-bayes.conf:

per_user = true;

Für die meisten Setups mit einer Handvoll Domains ist der globale Pool sinnvoller — mehr Trainingsdaten, schneller gute Ergebnisse.

Hinweise

Die Konfiguration ist stabil — Dovecot-Updates, rspamd-Updates, FreeBSD-Upgrades, alles durchgelaufen ohne Anpassung.

Wer rspamd danach noch eine Stufe weiter bringen will: Ich habe einen eigenen Beitrag geschrieben, wie man GPT-basierte Spam-Erkennung in rspamd integriert. Das läuft zusätzlich zum Bayes-Klassifikator und fängt die Mails ab, die durch das statistische Netz rutschen.

Siehe auch: Postfix und AMaViS: content_filter oder smtpd_proxy_filter?, DMARC-Prüfung in Postfix: OpenDMARC und rspamd im Vergleich

Fragen? Schreib mir über die Kontaktseite.

Von RSA zu ECDSA: Zertifikate für Nginx und Postfix umstellen

ECDSA-Zertifikate (Elliptic Curve Digital Signature Algorithm) bieten bei 256 Bit das gleiche Sicherheitsniveau wie RSA mit 3072 Bit. Die Schlüssel sind deutlich kleiner, der TLS-Handshake ist schneller und die Signaturen kürzer. Für Webserver ist die Umstellung trivial. Bei Mailservern gibt es eine Besonderheit: Nicht alle sendenden Server können ECDSA. Postfix löst das elegant mit Dual-Zertifikaten.

ECDSA-Schlüssel erstellen

# EC-Schlüssel mit P-256 erzeugen
openssl ecparam -genkey -name prime256v1 | openssl ec -out ec-server.key

# CSR erstellen (für CA-signierte Zertifikate)
openssl req -new -key ec-server.key -out ec-server.csr

# Oder gleich ein selbstsigniertes Zertifikat (z.B. für Tests)
openssl req -new -x509 -key ec-server.key -out ec-server.pem -days 365

P-256 (prime256v1) ist die gängige Kurve. Let’s Encrypt, DigiCert und andere CAs signieren ECDSA-CSRs problemlos. Bei Let’s Encrypt/certbot: certbot certonly --key-type ecdsa.

Nginx

Beim Webserver einfach den neuen Schlüssel und das Zertifikat hinterlegen. An der Cipher-Konfiguration muss nichts geändert werden, solange ECDSA-Ciphers enthalten sind:

ssl_certificate     /path/to/ec-server.pem;
ssl_certificate_key /path/to/ec-server.key;
ssl_ciphers         TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;

Alle modernen Browser unterstützen ECDSA seit Jahren. Probleme gibt es nur noch mit sehr alten Clients (Android 2.x, IE 6). Wer die nicht bedienen muss, kann RSA komplett aus der Cipher-Liste streichen.

Postfix: Dual-Zertifikate

Bei E-Mail sieht es anders aus. Manche Mailserver (ältere Exchange-Installationen, schlecht gewartete Systeme) können kein ECDSA. Postfix bietet dafür eine saubere Lösung: Man hinterlegt sowohl ein EC-Zertifikat als auch ein RSA-Zertifikat. Der Server bietet dem Client beide an, der Client wählt das passende.

# ECDSA (bevorzugt)
smtpd_tls_eckey_file = /usr/local/etc/postfix/ec-postfix.key
smtpd_tls_eccert_file = /usr/local/etc/postfix/ec-postfix.pem

# RSA (Fallback)
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem

Die Cipher-Reihenfolge entscheidet, was bevorzugt wird. ECDSA-Ciphers sollten vor den RSA-Ciphers stehen. Mit tls_preempt_cipherlist = yes bestimmt der Server die Reihenfolge:

tls_preempt_cipherlist = yes
tls_high_cipherlist = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

Die TLS-1.3-Ciphers (TLS_AES_*) stehen ganz vorn. Danach kommen ECDHE-ECDSA für TLS 1.2 mit EC-Zertifikat, dann ECDHE-RSA als Fallback für Clients die kein ECDSA können. Alle Ciphers haben Perfect Forward Secrecy durch ECDHE.

Dovecot

Dovecot unterstützt seit Version 2.3.15 ebenfalls mehrere Zertifikate. In 10-ssl.conf:

ssl_cert = </path/to/ec-dovecot.pem
ssl_key = </path/to/ec-dovecot.key
ssl_alt_cert = </path/to/rsa-dovecot.pem
ssl_alt_key = </path/to/rsa-dovecot.key

Verifizieren

Im Postfix-Log erkennt man am Cipher, welches Zertifikat verwendet wurde:

# ECDSA-Verbindung
TLS connection established: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

# RSA-Fallback (TLS 1.2)
TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384

Mit openssl s_client lässt sich gezielt prüfen:

# ECDSA-Zertifikat anfordern
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep "Server public key\|Cipher"

# Ergebnis: Server public key is 256 bit (EC)

Wer den nächsten Schritt gehen will: Mit Post-Quantum-Schlüsselaustausch (X25519MLKEM768) lässt sich zusätzlich der Key Exchange gegen Quantencomputer absichern. Das Zertifikat bleibt dabei ECDSA, nur der Schlüsselaustausch wird hybrid. Und natürlich gehört zu jedem Zertifikat ein DANE/TLSA-Record im DNS. Fragen? Einfach melden.

Automatische E-Mail-Archivierung mit cleanup-maildir und Dovecot

IMAP-Postfächer wachsen mit der Zeit. Irgendwann hat man tausende Mails im Posteingang und in Sent, die Suche wird langsam und die Übersicht geht verloren. cleanup-maildir ist ein Python-Script das Mails nach Alter automatisch in Archiv-Ordner sortiert. Es läuft als Cronjob und arbeitet direkt auf dem Maildir-Verzeichnis.

Installation

# FreeBSD
pkg install cleanup-maildir

# Debian/Ubuntu
pip install cleanup-maildir

Grundlegender Aufruf

Alle Mails die älter als 365 Tage sind aus der Inbox ins Archiv verschieben:

# Inbox archivieren
sudo -u vmail cleanup-maildir --age=365 \
  --archive-folder='Archive.Inbox' \
  --maildir-root='/var/mail/vhosts/example.com/user' \
  archive ''

# Gesendete archivieren
sudo -u vmail cleanup-maildir --age=365 \
  --archive-folder='Archive.Sent' \
  --maildir-root='/var/mail/vhosts/example.com/user' \
  archive 'Sent/'

--age=365 fasst nur Mails an die älter als ein Jahr sind. --archive-folder gibt den Zielordner im IMAP-Postfach an. archive ist der Modus (alternativ delete). Der leere String '' steht für die Inbox, 'Sent/' für die gesendeten Mails.

Das Script legt automatisch Unterordner nach Jahr und Monat an. Die Struktur im Postfach sieht dann so aus:

Archive/
├── Inbox/
│   ├── 2024-01/
│   ├── 2024-02/
│   └── ...
└── Sent/
    ├── 2024-01/
    ├── 2024-02/
    └── ...

Cronjob

Als Cronjob einmal pro Nacht laufen lassen. Wichtig ist dass der Cronjob als der Benutzer läuft der Zugriff auf die Maildir-Verzeichnisse hat:

# /etc/crontab
30 3 * * * vmail cleanup-maildir --age=365 --archive-folder='Archive.Inbox' --maildir-root='/var/mail/vhosts/example.com/user' archive ''

Mehrere Postfächer mit LDAP

Bei mehreren Postfächern will man nicht für jeden Benutzer einen eigenen Cronjob-Eintrag pflegen. Ein Wrapper-Script kann die Benutzer, Maildir-Pfade und die Option ob archiviert werden soll aus dem LDAP holen. Das LDAP-Attribut (z.B. autoarchive=1) steuert pro Benutzer ob die Archivierung aktiv ist. So lässt sich die Archivierung zentral verwalten ohne auf jedem Mailserver Cronjobs anzupassen.

Python 3.11+ und kaputte Header

Ab Python 3.11 nutzt cleanup-maildir den strikten RFC-Header-Parser aus email.policy.default. Das führt zu einem Problem: Mails mit fehlerhaften Headern (z.B. Microsoft Exchange Message-IDs wie <[b378dfc5...]@microsoft.com>) lassen das Script mit einem IndexError abstürzen. Alle Mails nach der fehlerhaften werden nicht mehr verarbeitet.

Den Fix dafür habe ich als Pull Request eingereicht. Ein _safe_header()-Wrapper fängt Parse-Fehler ab und überspringt kaputte Header, statt das ganze Script abzubrechen. Bei mir hat das Script vorher bei Mail #8 aufgehört, danach liefen alle 2.986 Mails sauber durch.

Siehe auch: Dovecot Quota einrichten

Fragen? Einfach melden.

DoH (DNS over HTTPS) mit BIND auf eigenem Server

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

Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet.  DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.

Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…

DoH DNS over HTTPS Firefox

Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?

Siehe auch: DoT mit Stunnel und BIND9

Fragen? Einfach melden.

Postfix: Verschleierung nur für SASL-Benutzer einrichten

Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…

Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.

Man erstellt in der master.cf vom Postfix einen neuen Service:

anonym unix n       -       -       -       0       cleanup
  -o header_checks=pcre:/usr/local/etc/postfix/header_cleanup

Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:

submission inet n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym
[...]
smtps     inet  n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym

Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

Fragen? Einfach melden.

Matrix Server Synapse: Erste Stable-Version 1 erschienen

Es hat einige Zeit gedauert aber gestern ist Synapse in Version 1.0.0 erschienen.

https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation
https://matrix.org/blog/2019/06/11/synapse-1-0-0-released
https://github.com/matrix-org/synapse/releases/tag/v1.0.0

Eine ganz wichtige Änderung der Version ist, dass Zertifikate anderer Server ab jetzt gültig sein müssen.

Wer seinen Server mittels pip auf den letzten Stand bringen möchte:

$ pip install --upgrade matrix-synapse

„Meldet“ euch doch mal wenn es klappt 🙂

Fragen? Einfach melden.

Postfix: Client-Initiated Renegotiation sicher deaktivieren

client-initiated renegotiation beim SMTPD Server kann für DDoS Angriffe ausgenutzt werden. Die einzelnen TLS/SSL Optionen lassen sich über die recht gleichnamige Option im Postfix ein und ausschalten. Gibt es noch keinen mappenden Namen kann die jeweilige Option auch ein/ausgeschaltet werden mit dem jeweiligen Hexwert. Genau Infos findet man hier: http://www.postfix.org/postconf.5.html#tls_ssl_options

If the value of the parameter is a hexadecimal long integer starting with "0x", the options corresponding to the bits specified in its value are enabled (see openssl/ssl.h and SSL_CTX_set_options(3))

Für ein Postfix  3.3 und einem OpenSSL ab Version 1.1.1 ist der passende Hexwert 0x40000000.

Die Option setzt man wie so oft in der main.cf:

root@smtp:/ # postconf  tls_ssl_options
tls_ssl_options = 0x40000000

Ab Postfix >=3.4 gibt es: NO_RENEGOTIATION

Fragen? Dann fragen.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑