Windows Server RRAS bietet standardmaessig L2TP/IPsec mit SHA-1, 3DES und DH Group 2 (modp1024) an. 1024 Bit Diffie-Hellman ist 2026 nicht mehr akzeptabel. Per PowerShell laesst sich die IPsec-Suite auf AES-256, SHA-256 und ECDH P-384 umstellen, plus kompatible Windows-Clients.
ZFS-Snapshots des Notebook-Pools auf eine USB-Platte schieben, die komplett mit geli verschluesselt ist. geli-Init mit AES-XTS-256, ZFS-Pool auf dem entschluesselten Geraet, ein knapper Backup-Workflow per zfs send und der Schluessel-Aufbewahrungs-Hinweis am Schluss.
SSH-Host-Keys nicht mehr per Trust-on-First-Use pruefen, sondern aus dem DNS lesen: SSHFP-Records nach RFC 4255 erzeugen, in die Zone eintragen, VerifyHostKeyDNS aktivieren. Plus die DNSSEC-Pflichtkomponente und was zu beachten ist bei alten OpenSSH-Versionen.
GPG-Schluessel direkt als OPENPGPKEY-Record im DNS hinterlegen, ohne Keyserver-Abhaengigkeit oder Web-of-Trust. RFC 7929 erklaert, die SHA-256-Hash-Variante des Local-Part, ein Generator fuer den Record und warum DNSSEC die Voraussetzung ist. Plus Hinweis zur Recordgroesse.
Wer eine kleinere IP-Range als /24 hat (typisch beim Reseller mit /28 oder /29), kann keine eigene PTR-Zone betreiben. RFC 2317 loest das per CNAME-Delegation im /24 des Providers. Praxis-Walkthrough mit BIND-Zonenfiles auf beiden Seiten und der Standard-Stolperstein bei der Sub-Range-Notation.
Postfix-MTA mit DANE absichern: TLSA-Records nach RFC 7672, smtp_tls_security_level=dane, die "3 1 1"-Selector-Variante als langlebige Wahl, der DNSSEC-Stack als Grundvoraussetzung und Tools fuer die Pruefung. Plus eine Kurz-Erklaerung zu Untrusted vs Verified im Postfix-Log.
Ein SPF-Record legt im DNS fest, welche Server fuer eine Domain Mail verschicken duerfen. Die Mechanismen include/a/mx/ip4/ip6/all, die Qualifier +-~? und der 10-Lookup-Limit-Stolperstein in einem Praxis-Aufschrieb. Warum Hardfail (-all) meist die richtige Wahl ist.
DMARC baut auf SPF und DKIM auf und schliesst die zwei Luecken die beide einzeln offen lassen: Der Absender bestimmt was mit unzustellbaren Mails passieren soll, Reports landen taeglich im Postfach. Policy-Stufen none/quarantine/reject erklaert, plus typischer rua-Reporting-Setup.
BitLocker fragt nach jedem Linux/Windows-Dual-Boot-Wechsel nach dem Recovery Key, weil das TPM die Bootkette-Aenderung erkennt. Fix: TPM als Schluesselschutz raus, Passwort rein. Gruppenrichtlinie, manage-bde, und schon gehoert das Drama der Vergangenheit an.
Native ZFS-Encryption auf FreeBSD 13 mit AES-256-GCM eingerichtet und getestet. Passphrase-Handling, Mount/Unmount. Limitierung: Verschlüsselung lässt sich nicht nachträglich aktivieren. Ansonsten unkompliziert und zuverlässig.
TLSA- und DANE-Records manuell pruefen mit OpenSSL, dig und hash-slinger. Fingerprint-Berechnung fuer Selector 0/1 und Matching-Type 0/1/2 durchgespielt. Nuetzlich wenn ein TLSA-Record nicht validiert und man wissen will warum.
Cipher Suites wie TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 sehen kryptisch aus, folgen aber einem klaren Schema: Key Exchange, Certificate Verification, Bulk Encryption und Hashing. Grundlagen fuer TLS 1.2 und 1.3.
Fuenfzehn Tage Nginx-Logs mit $ssl_curve. Wer spricht schon X25519MLKEM768, wer haengt noch auf klassischem X25519 oder sogar TLS 1.2? Ein Blick auf Browser, AI-Crawler, Suchmaschinen, Fediverse, RSS-Reader und ein paar ueberraschende Ausreisser.
"Vulnerability Reports" zur wp-cron.php sind ein Klassiker unter den Scam-Mails. Kurze Einordnung: ist das ein P1-Bug? Nein. Was wirklich hilft, sind Rate Limiting in nginx oder die lokale Ausfuehrung per Cronjob.
DANE und TLSA-Records ermoeglichen TLS-Zertifikat-Schutz via DNSSEC, nicht ueber CA-Zertifikatsketten. Praktische OpenSSL-Befehle zum Hash erzeugen, dig zum Pruefen. Bei mir im Einsatz, funktioniert elegant.
WSUS laeuft nie dauerhaft ohne Pflege. PowerShell und SQL gegen Timeouts, Platten-Fresser und haengende Serverbereinigung. Treiberupdates raus, abgelehnte Updates loeschen, SUSDB shrinken, IIS-Pool tunen und zuletzt die Indexe neu aufbauen.
Zwei-Faktor-Authentifizierung auf FreeBSD SSH: Google Authenticator PAM-Modul, Challenge-Response in sshd_config, Benutzer-Setup mit QR-Code und Backup-Codes. Erhöht die Sicherheit merklich, unkompliziert einzurichten.
MTA-STS (RFC 8461) zwingt Mailserver zu verschluesselter Uebertragung. Konfiguration: DNS TXT-Record, Policy-Hosting, optionale TLS-Reports. Start im testing-Modus, dann auf enforce schalten. Pragmatischer als DANE.
BIOS-Updates unter Linux waren lange eine Qual. fwupd ändert das: ein Framework, ein LVFS-Repo, ein Kommando. BIOS/UEFI, NVMe, Thunderbolt, Intel ME — über 1.000 Geräte unterstützt. Beispiel auf dem ThinkPad X1 Carbon mit Capsule Updates.
Siehe auch: Post-Quantum TLS für E-Mail — Postfix und Dovecot mit X25519MLKEM768 auf FreeBSD 15, Post-Quantum TLS für Nginx — X25519MLKEM768 auf FreeBSD 15 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…
Ein Vulnerability Report kam rein: angeblich Terrapin (CVE-2023-48795) auf meinem SSH-Server. Stellte sich raus: fremder Server per CNAME aliased, JavaScript-Typ im Template vergessen. Trotzdem ein guter Anlass zu security.txt und Umgang mit solchen Hinweisen.
ZFS Encryption nachtraeglich aktivieren geht nicht. Datasets muessen per zfs send|receive in ein neues verschluesseltes Ziel kopiert werden. Anleitung mit Stolperfallen, inkrementeller Migration und encrypted Offsite-Backup via zfs send -w.
TLS 1.3 in Postfix und Dovecot: keine Sonderbehandlung notwendig, sobald OpenSSL 3.x mitspielt. Sauber konfiguriert wird vor allem der TLS-1.2-Fallback und das Zusammenspiel aus DANE, MTA-STS und TLS-RPT. Post-Quantum ist die nächste Stufe.
kernel-error.de als Tor Hidden Service: Nginx-vHost auf der Loopback-Adresse, Cache-Isolation zum Clearnet, Onion-Location-Header, warum kein TLS-Zertifikat nötig ist und was sich noch härten lässt. Der ursprüngliche Kurzbeitrag komplett überarbeitet.
rt6_redirect: source isn't a valid nexthop for redirect target im Kernel-Log — kein Bug, sondern ein abgelehntes ICMPv6-Redirect. Typischerweise durch globale statt Link-Local-Next-Hops. Diagnose, Fix und wann Abschalten die pragmatische Loesung ist.