IT-Blog von Sebastian van de Meer

Kategorie: IT-Security (Seite 3 von 14)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Cloudflare Deal: Günstige YubiKeys für 10–11 USD im Oktober 2022

Es gibt aktuell einen EEEECCCHHHTTTT guten Deal um günstig an bis zu 10 YubiKeys 5 NFC und/oder 5C NFC zu kommen.

Man benötigt dafür einen Cloudflare Account, der ist ja schnell geklickt. Dann klickt man ein paar Links und wartet auf eine E-Mail mit seinem Discount Code.

Da die Keys in der Regel etwas um die 50€ Kosten, ist dieses schon eine extreme Ersparnis.

Oh der Link: https://www.reddit.com/r/yubikey/comments/xrcly7/cloudflare_deal_for_1011_keys/

Screenshot der Bestellübersicht für den YubiKey 5 NFC und YubiKey 5C NFC

Fragen? Einfach melden.

DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-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.

Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.

Bilder der Bind 9 TLS Konfiguration

Zu diesem Zeitpunkt bracht BIND 9 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) mit dem nötigen Support.

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

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.

FreeBSD: Unverschlüsseltes ZFS-Dataset nachträglich verschlüsseln

Bild der Bücher FreeBSD Mastery ZFS und FreeBSD Mastery Advanced ZFS

ZFS Encryption lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Die Daten müssen per zfs send | zfs receive in ein neues, verschlüsseltes Dataset geschrieben werden. Typischer Anwendungsfall: Jails, die in eigenen Datasets liegen und nach einem FreeBSD-Upgrade auf 13+ verschlüsselt werden sollen.

Wer die Grundlagen zu ZFS Encryption noch braucht (Dataset anlegen, Passphrase, Mount nach Reboot), findet sie im Beitrag Native ZFS Encryption einrichten.

Ausgangslage

Ein Pool zroot mit dem unverschlüsselten Dataset varta:

zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  12.0G      100M  /zroot/varta

zfs get encryption zroot/varta
NAME         PROPERTY    VALUE   SOURCE
zroot/varta  encryption  off     default

Migration

Bei zfs send | zfs receive kann man kein Passphrase interaktiv eingeben, weil stdin durch die Pipe belegt ist. Deshalb legt man den Schlüssel temporär in einer Datei ab:

echo 'MeinGeheimesPassphrase' > /tmp/keyfile.txt
chmod 600 /tmp/keyfile.txt

Snapshot erstellen und in ein neues verschlüsseltes Dataset senden:

zfs snapshot zroot/varta@migration

zfs send zroot/varta@migration | \
  zfs receive -F \
  -o encryption=on \
  -o keyformat=passphrase \
  -o keylocation=file:///tmp/keyfile.txt \
  zroot/en-varta

Das neue Dataset zroot/en-varta enthält jetzt dieselben Daten, verschlüsselt mit AES-256-GCM:

zfs list zroot/varta zroot/en-varta
NAME             USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta   100M  11.8G      100M  /zroot/en-varta
zroot/varta      100M  11.8G      100M  /zroot/varta

Aufräumen

Die Keyfile-Referenz auf Passphrase-Abfrage umstellen und die temporäre Datei löschen:

zfs set keylocation=prompt zroot/en-varta

zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE   SOURCE
zroot/en-varta  keylocation  prompt  local

rm /tmp/keyfile.txt

Dann das alte Dataset entfernen und das neue umbenennen:

zfs destroy -r zroot/varta
zfs rename zroot/en-varta zroot/varta

Fertig. Das Dataset liegt jetzt verschlüsselt am selben Mountpoint wie vorher:

zfs get encryption,keylocation,keyformat zroot/varta
NAME         PROPERTY     VALUE        SOURCE
zroot/varta  encryption   aes-256-gcm  -
zroot/varta  keylocation  prompt       local
zroot/varta  keyformat    passphrase   -

Hinweise

Bei Jails: Jail vorher stoppen, nach der Migration den Mountpoint anpassen falls nötig (zfs set mountpoint=...), dann neu starten. Bei großen Datasets dauert der zfs send | zfs receive entsprechend lange. Ein Test mit einem kleinen Dataset vorher schadet nicht.

Eine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Fragen? Einfach melden.

Linux Mint mit verschlüsseltem ZFS-Root-Pool installieren

ZFS als Root-Dateisystem unter Linux — will man haben. Verschlüsselung auf der Festplatte — will man auch haben. Die Kombination aus beidem war unter Linux lange ein manueller Kraftakt. Seit Linux Mint 20 bringt der Installer aber fast alles mit. Man muss ihm nur an zwei Stellen unter die Arme greifen.

Linux Mint Boot-Bildschirm: ZFS-Pool-Passwortabfrage nach erfolgreicher Verschluesselung.

Hinweis: Diese Anleitung wurde mit Linux Mint 20.1 geschrieben, funktioniert aber genauso mit Mint 21.x und 22.x — der Installer nutzt das gleiche zsys-setup-Skript.

Pakete im Live-System nachinstallieren

Die gewünschte Linux Mint ISO herunterladen und davon booten. Im Live-System ein Terminal öffnen und die ZFS-Pakete installieren:

sudo aptitude -y install libzfs2linux zfs-initramfs zfsutils-linux zfs-zed

Wer nur ZFS ohne Verschlüsselung will, ist damit schon fertig. Einfach den Installer starten, bei der Festplattenauswahl auf Advanced features… klicken und EXPERIMENTAL: Erase disk and use ZFS wählen. Für Verschlüsselung weiter lesen.

Installer-Skript für Verschlüsselung anpassen

Der Installer fragt kein Passwort für die ZFS-Verschlüsselung ab — das muss man ihm vorher ins Skript schreiben. Im Terminal:

sudo vi /usr/share/ubiquity/zsys-setup

Nach zpool create suchen — es taucht zweimal auf. Beim rpool (nicht beim bpool) zwei Änderungen vornehmen:

1. Vor die zpool create-Zeile des rpool ein echo mit dem gewünschten Passwort setzen:

echo 'EUER-PASSWORT' | zpool create -f \

2. Vor die Zeile -O mountpoint=/ -R "${target}" rpool "${partrpool}" die Encryption-Optionen einfügen:

-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O keyformat=passphrase \

Das fertige Ergebnis sieht dann so aus:

echo 'Kennwort!' | zpool create -f \
        -o ashift=12 \
        -O compression=lz4 \
        -O acltype=posixacl \
        -O xattr=sa \
        -O relatime=on \
        -O normalization=formD \
        -O mountpoint=/ \
        -O canmount=off \
        -O dnodesize=auto \
        -O sync=disabled \
        -O encryption=aes-256-gcm \
        -O keylocation=prompt \
        -O keyformat=passphrase \
        -O mountpoint=/ -R "${target}" rpool "${partrpool}"

Sicherheitshinweis: Das Passwort steht kurzzeitig im Klartext in der Datei und in der Bash-History. Im Live-System ist das unkritisch — nach dem Reboot ins installierte System ist das Live-System weg. Trotzdem nicht das Produktivpasswort in Screenshots posten.

Jetzt den Installer starten, ZFS als Dateisystem wählen — fertig. Funktioniert mit EFI und Legacy-Boot.

Verschlüsselung prüfen

Nach dem ersten Boot ins neue System — Terminal öffnen und prüfen, ob die ZFS-Verschlüsselung aktiv ist und sich durch den Pool bis zu den Benutzerdaten vererbt hat:

$ zpool get feature@encryption bpool rpool
NAME   PROPERTY            VALUE     SOURCE
bpool  feature@encryption  disabled  local
rpool  feature@encryption  active    local

$ zfs get encryption rpool/USERDATA/test_9d9i92
NAME                        PROPERTY    VALUE        SOURCE
rpool/USERDATA/test_9d9i92  encryption  aes-256-gcm  -

feature@encryption: active beim rpool und aes-256-gcm auf den Benutzerdaten — alles korrekt. Der bpool (Boot-Pool) bleibt unverschlüsselt — GRUB muss den Kernel lesen können, bevor das Passwort eingegeben wird.

Wer seine SSDs im ZFS-Pool auch gleich mit TRIM versorgen will — das ist in einem separaten Beitrag beschrieben.


Bilder von der Installation zum Durchklicken:

Siehe auch: ZFS Encryption

Fragen? Einfach melden.

Windows Server RRAS: L2TP/IPsec-VPN mit sicheren Cipher Suites

RRAS Routing und RAS Icon.

Wenn ich schon bei Microsoft-Themen bin: Warum nicht gleich noch RRAS (Routing und RAS) mit einem L2TP/IPsec-VPN absichern? Im Standard verbinden sich die Clients nämlich mit SHA-1, 3DES und DH Group 2 (modp1024, also 1024 Bit). SHA-1 ist grenzwertig, 3DES muss nicht sein und modp1024 will man definitiv nicht mehr.

Hinweis: Ursprünglich für Windows Server 2012 R2 geschrieben (inzwischen End of Life). Die Konfiguration über die Windows-Firewall funktioniert auf neueren Versionen identisch.

Wo man die Einstellung findet (Spoiler: nicht bei RRAS)

Ich habe einige Zeit gesucht. Man würde erwarten, dass die IPsec-Cipher irgendwo in der Nähe von Routing und RAS konfiguriert werden. Falsch gedacht. Die Einstellung steckt in der Windows-Firewall mit erweiterter Sicherheit. Irgendeinen Grund wird es haben, das dort zu verstecken. Ich hätte dort nie gesucht.

Der Klickpfad: Windows Firewall → Rechtsklick auf „Windows-Firewall mit erweiterter Sicherheit“ → Eigenschaften → IPsec-Einstellungen → IPsec-Standardeinstellungen → „Anpassen“ → Schlüsselaustausch.

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Sicherheitsmethoden zu konfigurieren.

Hier kann man die Sicherheitsmethoden und Datenschutzeinstellungen anpassen. Windows Firewall als Ort für VPN-Cipher-Konfiguration. Kopfschütteln.

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Datenschutzeinstellungen zu konfigurieren.

UDP Encapsulation hinter NAT

Steht der RRAS hinter einem NAT, muss man noch UDP Encapsulation per Registry aktivieren. Dafür habe ich ein Registry-File:

Registry-File für IPsec UDP Encapsulation

Nach allen Änderungen den Server neu starten. Microsoft halt.

Prüfen ob es geklappt hat

Auf einem Windows-Client per PowerShell (mit erweiterten Rechten) prüfen, welche Cipher die VPN-Verbindung tatsächlich nutzt:

Get-NetIPsecMainModeSA | Select-Object -First 1
Screenshot des Kommandos Get-NetIPsecMainModeSA inkl Konsolenausgabe.

Relevant sind CipherAlgorithm, HashAlgorithm und GroupId. Im Standard steht da 3DES, SHA-1 und DH Group 2 (1024 Bit). Nach den Änderungen:

Encryption:                AES256
Authentication/Integrity:  SHA-1
Key Size:                  DH Group 20 (384-bit ECC)

Immer noch SHA-1 für die Integrity, aber AES-256 und ECC sind ein großer Sprung. Über Gruppenrichtlinien ließe sich das Ganze auch zentral ausrollen, aber das ist nochmal ein eigenes Thema. Vor allem die Reihenfolge korrekt vorzugeben ist dort unerwartet fummelig.

Wer auch die TLS-Cipher für Exchange/OWA härten will: SSL Labs A+ mit Exchange. Fragen? Einfach melden.

WSUS-Bereinigung: Timeouts beheben und Speicherplatz freigeben

WSUS Windows Server Update Service Icon

Pfffff… Einen dauerhaft richtig gut laufenden WSUS Server habe ich tatsächlich noch nie gesehen. Irgendwann werden die Dinger langsam, dann gibt es Timeouts, die Serverbereinigung läuft nicht mehr durch und die Platten laufen voll. WSUS ist kein Dienst, den man einmal konfiguriert und dann läuft er. WSUS möchte dauerhaft Aufmerksamkeit. Was mir dabei so aufgefallen ist, möchte ich hier teilen.

Keine Treiberupdates über WSUS

Screenshot der WSUS-Oberfläche: Produkte und Klassifizierungen konfigurieren.

Nie Treiberupdates über WSUS verteilen. Hier explodiert der Platzverbrauch. Falls aktiviert: Über Optionen → Produkte und Klassifizierungen → Klassifizierungen den Haken bei „Treiber“ entfernen. Dann unter Updates → Alle Updates die Dropdown-Menüs auf „Genehmigung: Genehmigt“ und „Status: Alle“ setzen, nach Klassifizierung sortieren und alle Treiberupdates ablehnen.

Abgelehnte Updates löschen

Abgelehnte Updates belegen weiterhin Plattenplatz, bis sie aktiv gelöscht werden. Dieses PowerShell-Script räumt sie weg — es läuft eine Weile, schafft aber viel Platz:

Screenshot der PowerShell ISE mit WSUS-Bereinigungsscript.
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$wsus.GetUpdates() | Where {$_.IsDeclined -eq $true} | ForEach-Object {
    $wsus.DeleteUpdate($_.Id.UpdateId.ToString())
    Write-Host $_.Title removed
}

Serverbereinigung automatisieren

Der „Assistent für die Serverbereinigung“ löscht überflüssige Updates — abgelehnte, ersetzte und nicht mehr benötigte. Man sollte ihn regelmäßig laufen lassen, aber er lässt sich nicht direkt automatisieren. Dafür braucht man ein PowerShell-Script, das man per Aufgabenplanung täglich ausführt:

# 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

# Status-Mail versenden
$MailBody = Get-Content $Logfile | Out-String
Send-MailMessage -SmtpServer "smtp.example.de" `
    -From "wsus@example.de" -To "admin@example.de" `
    -Subject "${env:COMPUTERNAME} Bereinigung $DateFormat" `
    -Body $MailBody -Encoding Unicode

IIS-Einstellungen bei Timeouts

Wenn die WSUS-Konsole oder Bereinigung mit Timeouts abbricht, hilft es oft, dem WsusPool im IIS mehr Ressourcen zu geben:

IIS-Manager → Anwendungspools → WsusPool → Erweiterte Einstellungen

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

Danach den IIS neu starten — oder besser gleich den ganzen Server, es ist ja ein Windows.

SUSDB-Datenbank warten

Screenshot der Database Properties SUSDB: Compatibility Level auf SQL Server 2012 setzen.

Mit dem SQL Server Management Studio zur Windows Internal Database verbinden: \\.\pipe\MICROSOFT##WID\tsql\query

Compatibility Level anheben: Databases → SUSDB → Properties → Options → Compatibility level: SQL Server 2012 (110)

Screenshot SUSDB Shrink Database Dialog.

Datenbank verkleinern: Databases → SUSDB → Tasks → Shrink → Database

Synchronisierungshistorie aufräumen:

Screenshot SQL Server Management Studio mit Bereinigungsquery für WSUS-Synchronisierungen.
USE SUSDB
GO
DELETE FROM tbEventInstance
WHERE EventNamespaceID = '2'
  AND EVENTID IN ('381', '382', '384', '386', '387', '389')

Wenn die Bereinigung hängen bleibt

Manchmal bleibt die Serverbereinigung an einem bestimmten Update hängen. Dann hilft es, das erste Update in der „zu löschen“-Liste von Hand zu entfernen:

USE SUSDB
GO
-- Erste Update-ID ermitteln
exec spGetObsoleteUpdatesToCleanup
-- ID notieren und löschen
exec spDeleteUpdate @localUpdateID=HIER_UPDATE_ID

Wenn auch das nicht reicht, kann man alle obsoleten Updates in einer Schleife löschen — das läuft lange, räumt aber zuverlässig auf:

USE SUSDB
DECLARE @var1 INT, @curitem INT, @totaltodelete INT
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
    RAISERROR('%d/%d: Deleting %d', 0, 1, @curitem, @totaltodelete, @var1) WITH NOWAIT
    EXEC spDeleteUpdate @localUpdateID=@var1
    SET @curitem = @curitem + 1
    FETCH NEXT FROM WC INTO @var1
END
CLOSE WC
DEALLOCATE WC
DROP TABLE #results

Abschließend die Indexe der SUSDB neu aufbauen — das beschleunigt danach alles spürbar. Microsoft hatte dafür ein Script in der TechNet Gallery veröffentlicht. Die Gallery ist inzwischen offline, aber das Script findet sich als WsusDBMaintenance.sql in diversen Microsoft-Docs-Artikeln. Im Kern macht es nichts anderes als fragmentierte Indexe zu erkennen und per ALTER INDEX REBUILD oder REORGANIZE zu reparieren, gefolgt von sp_updatestats.

Meist hilft eine Kombination aus mehreren dieser Maßnahmen. Bisher hat mir immer irgendetwas davon geholfen — auch wenn ich dafür einige Zeit in Suchmaschinen verschwenden musste. Fragen? Einfach melden.

Siehe auch: Windows Server Backup mit Nagios

Windows Server mit Exchange: SSL Labs A+ erreichen

Qualis A+ Icon.

Ich hatte hier einen Windows Server 2012 R2 mit Exchange 2016 stehen. Out of the Box sprach das Ding TLS 1.0, SSLv3 und RC4. Da gehen einem die Haare hoch. Kann man so ein System auf ein A+ bei Qualys SSL Labs bekommen und es funktioniert danach noch? Kleiner Spoiler: Ja, geht.

Ich muss zugeben, Microsoft-Produkte strengen mich in dieser Hinsicht immer an. Die haben ihre Daseinsberechtigung, keine Frage. Aber TLS-Hardening unter Windows fühlt sich an wie Zahnmedizin mit Handschuhen aus Pappe.

Hinweis: Windows Server 2012 R2 und Exchange 2016 sind inzwischen End of Life. Der Ansatz (Registry-Änderungen für TLS, HSTS im IIS) funktioniert auf Windows Server 2016/2019/2022 aber genauso.

HSTS im IIS setzen

Für ein A+ braucht man neben sauberen Ciphern und Protokollen auch HTTP Strict Transport Security (HSTS). Das ist im Grunde nur ein HTTP-Response-Header. Im IIS-Manager konfiguriert man ihn ganz oben auf Server-Ebene, damit er überall vererbt wird:

IIS-Manager → HTTP-Antwortheader → Hinzufügen:

Screenshot der Internetinformationsdienste (IIS)-Manager.
Name:  strict-transport-security
Wert:  max-age=31536000; includeSubdomains

TLS-Protokolle und Cipher härten

Jetzt der eigentlich spannende Teil. Man muss eine ganze Reihe von Registry-Änderungen vornehmen: MD5 und RC4 deaktivieren, SSLv3, TLS 1.0 und TLS 1.1 abschalten, TLS 1.2 aktivieren, schwache Cipher raus und eine sinnvolle Cipher-Reihenfolge vorgeben. Ich habe dafür ein Registry-File vorbereitet. Herunterladen, ausführen, Server neu starten (Microsoft halt).

Download: Registry-File Download

Ergebnis

Qualis A+ Wertung.
Qualis Wertung mit Blick auf Cipher Suites und Protocols.

A+ steht. Ich hätte gerne noch schönere Cipher gehabt, aber mehr war mit diesem Setup nicht drin. Immerhin: Kein RC4, kein 3DES, kein TLS unter 1.2. Und Exchange funktioniert danach noch, was bei Microsoft-Produkten ja nie selbstverständlich ist.

Wer auch die VPN-Cipher auf dem Windows Server härten will, findet die Anleitung im Beitrag RRAS mit sicheren Cipher Suites. Fragen? Einfach melden.

Bash-Skript: Automatisiertes Erstellen von Abuse-E-Mails

Das Problem

Wer ein System mit öffentlicher IP betreibt, kennt das: Kaum ist der Server online, hämmern Bots und Script Kiddies auf SSH, Postfix und alles, was nach Dienst aussieht. Fail2Ban sperrt die Adressen, meldet sie an AbuseIPDB und verteilt die Sperren auf die anderen Kisten. So weit, so automatisch.

Screenshot der Konsolenausgabe vom Abuse Script.

Aber was ist mit dem Hoster oder ISP hinter der IP? Meistens steckt ein kompromittierter Root-Server oder VPS dahinter. Vielleicht weiß der Admin noch gar nichts davon. Im whois zur IP findet sich eine abuse-mailbox, an die man sich wenden kann.

➜  ~ whois 8.8.8.8|grep -i abuse
OrgAbuseEmail:  ipaddressing@level3.com
OrgAbuseEmail:  network-abuse@google.com

Ehrlich gesagt: Der Großteil dieser Abuse-Mails landet beim Empfänger in /dev/null. Rückmeldungen bekommt man fast nie, und oft hat es schlicht keinen Effekt. Hin und wieder hilft es aber jemandem. Deshalb schiebe ich ab und zu einen Abuse an, will dabei aber so wenig Arbeit wie moeglich reinstecken.

Abuse melden: Was gehört rein?

Damit der Empfänger etwas mit der Meldung anfangen kann, sollte sie folgende Informationen enthalten:

  • Die IP-Adresse des eigenen Systems.
  • Die IP-Adresse, von der die Angriffe kommen.
  • Ein paar Zeilen aus dem Logfile, die das Problem zeigen.
  • Die Zeitzone des eigenen Systems, damit die Zeitangaben im Log nutzbar sind.
  • Eine kurze Beschreibung des Problems.
  • Die Erlaubnis, die Kontaktdaten an den Kunden weiterzugeben.

Das Script

Da mich Fail2Ban direkt mit dem whois zur IP informiert, brauche ich nur noch etwas, das die restlichen Informationen einsammelt und die Mail generiert. Dafür habe ich folgendes Bash-Script geschrieben. Man übergibt die IP und die Abuse-Adresse, das Script validiert beides, sammelt die passenden Zeilen aus dem auth.log, baut die Mail zusammen und schickt sie nach einer Sichtkontrolle ab.

#!/usr/local/bin/bash

if [ "$1" == "-h" ] ; then
    printf "You can add abuse ip and mail on start or interactive by request."
    printf "Usage 1: abusemail.sh 1.2.3.4 example@example.org"
    printf "Usage 2: abusemail.sh"
    exit 0
fi

myip="1.2.3.4"
bcc="my@mail.com"


function validateMail()
 {
         local mail=$1
         local stat=1
         if [[ "$mail" =~ ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$ ]]; then
                stat=0
        fi
        return $stat
}

function validateIP()
 {
         local ip=$1
         local stat=1
         if [[ $ip =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]]; then
                OIFS=$IFS
                IFS='.'
                ip=($ip)
                IFS=$OIFS
                [[ ${ip[0]} -le 255 && ${ip[1]} -le 255 \
                && ${ip[2]} -le 255 && ${ip[3]} -le 255 ]]
                stat=$?
        fi
        return $stat
}
clear
printf "\x1b[31;1;4mCreate und send abuse e-mail!\x1b[0m\n\n"
printf "Enter IP Address"

if [ "$1" == "" ] ; then
    read ip
else
    ip=$1
fi

validateIP $ip

if [[ $? -ne 0 ]];then
  printf "Invalid IP Address ($ip)"
  exit 1
else
  printf "$ip ==> \x1b[32;1;4mOK\x1b[0m\n\n"
fi
printf "\n"
printf "Enter Abuse E-Mail Address"

if [ "$1" == "" ] ; then
    read mail
else
    mail=$2
fi

validateMail $mail

if [[ $? -ne 0 ]];then
  printf "Invalid Abuse E-Mail Address ($mail)"
  exit 1
else
  printf "$mail  ==> \x1b[32;1;4mOK\x1b[0m"
fi

printf "Dear abuse team,\n\nI got some SSH connections from one of your IPv4 addresses. It seems to\nbe a bot or something....\n\nYes, you can forward this E-Mail with contact informations to your \ncustomer to solve this case, if necessary.\n\nMy timezone: Europe/Berlin\nMy IPv4: $myip\nYour IPv4: $ip\n\nSome log snippets:\n" > /tmp/abusemail
grep $ip /var/log/auth.log >> /tmp/abusemail
printf "\nBest regards\nSebastian van de Meer\n" >> /tmp/abusemail


printf "\n\n\n\x1b[31;1;4mCheck e-mail before sending!\x1b[0m\n\n"
printf "\x1b[32;1;4mRecipient:\x1b[0m $mail\n\n"
printf "\x1b[32;1;4mSubject:\x1b[0m Abuse against: $ip - Brute Force\n\n"
cat /tmp/abusemail
printf "\n\n"

while true
do
 printf "\x1b[33;1;4mSend Abuse Mail? [Y/n]\x1b[0m\n"
 read -r input

 case $input in
     [yY][eE][sS]|[yY])
 cat /tmp/abusemail | /usr/local/bin/mailx -s "Abuse against: $ip - Brute Force" -r "My Name " -b $bcc $mail
 printf "Abuse Mail is on it's way..."
 break
 ;;
     [nN][oO]|[nN])
 printf "Abuse Mail aborted"
 break
        ;;
     *)
 printf "Invalid input..."
 ;;
 esac
done

Das Script ist alt, stumpf und einfach. Es tut genau das, was es soll: Arbeit abnehmen bei einer Aufgabe, die sich meistens sowieso nicht lohnt. Wer das Thema automatisierter weitertreiben will, kann sich mal SSH-Bruteforce und AbuseIPDB anschauen. Dort geht es darum, wie Fail2Ban und AbuseIPDB zusammenspielen.

Fazit

Abuse-Mails sind undankbar. Die meisten verpuffen, manche helfen. Wer trotzdem ab und zu eine rausschicken will, ohne jedes Mal alles von Hand zusammenzusuchen, hat mit so einem Script zumindest den Aufwand minimiert.

Fragen? Einfach melden.

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

Verschlüsselung-cipher

Wer sich mit TLS beschäftigt, stolpert früher oder später über Zeichenketten wie TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 oder TLS_AES_256_GCM_SHA384. Was da genau drinsteht, ist auf den ersten Blick nicht offensichtlich. Dabei folgt die Benennung einem klaren Schema.

Die Bestandteile einer Cipher Suite

Jede Cipher Suite beschreibt vier Dinge:

  • Key Exchange — wie sich Client und Server auf einen gemeinsamen Sitzungsschlüssel einigen.
  • Certificate Verification — wie das Serverzertifikat geprüft wird (Signaturverfahren).
  • Bulk Encryption — die symmetrische Verschlüsselung der eigentlichen Daten.
  • Hashing — die Prüfsummen, die Integrität und Authentizität sicherstellen.

TLS 1.2 vs. TLS 1.3

In TLS 1.2 stehen alle vier Bestandteile im Namen der Cipher Suite. Nehmen wir TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 auseinander:

  • TLS — das Protokoll (Transport Layer Security)
  • ECDHE — Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral)
  • ECDSA — Certificate Verification (Elliptic Curve Digital Signature Algorithm)
  • AES_256_GCM — Bulk Encryption (AES mit 256 Bit im Galois/Counter Mode)
  • SHA384 — Hashing (SHA-2 mit 384 Bit)

TLS 1.3 hat das Namensschema verkürzt. Key Exchange und Certificate Verification sind nicht mehr Teil des Cipher-Suite-Namens, weil sie separat verhandelt werden. Darum sieht TLS_AES_256_GCM_SHA384 so kompakt aus: nur Protokoll, Verschlüsselung und Hash.

Key Exchange

Der Schlüsselaustausch legt fest, wie Client und Server einen temporären Sitzungsschlüssel aushandeln. Man will hier Ephemeral-Verfahren, also temporäre Schlüssel. Warum? Selbst wenn jemand den Traffic mitschneidet und später an den privaten Schlüssel des Servers kommt, kann er die aufgezeichneten Verbindungen nicht entschlüsseln. Der Sitzungsschlüssel existiert nur für die Dauer der Verbindung. Das nennt sich Perfect Forward Secrecy.

DHE (Diffie-Hellman Ephemeral) funktioniert, sollte aber mindestens 2048 Bit nutzen. Besser ist ECDHE (Elliptic Curve DHE), weil es bei gleicher Sicherheit deutlich kleiner und schneller ist. Idealerweise bietet der Server nur ECDHE an. Alles ohne das E am Ende (also statisches DH) hat kein Forward Secrecy und gehört abgeschaltet.

In Zukunft kommt hier noch Post-Quantum dazu. Mit X25519MLKEM768 lassen sich hybride Verfahren nutzen, die auch gegen Quantencomputer absichern. Wer das auf Nginx einrichten will, findet bei mir eine Anleitung: Post-Quantum TLS.

Certificate Verification

Verschlüsselung allein hilft nicht, wenn man mit dem falschen Server spricht. Das Serverzertifikat beweist die Identität. Es wird von einer CA signiert, kann per DANE/TLSA im DNSSEC-geschützten DNS verankert sein und sollte nicht trivial fälschbar sein.

RSA-Zertifikate sollten mindestens 2048 Bit haben, besser 4096 Bit. Allerdings werden RSA-Schlüssel mit steigender Sicherheit immer größer und langsamer. ECDSA-Zertifikate lösen das elegant: Ein ECDSA-Schlüssel mit 256 Bit bietet vergleichbare Sicherheit wie RSA mit 3072 Bit, ist aber deutlich kleiner und schneller zu verifizieren. Als Kurve sollte es mindestens secp256r1 (P-256) sein. secp384r1 geht auch, bringt aber aktuell keinen praktischen Vorteil.

Bulk Encryption

Das ist die eigentliche Datenverschlüsselung. Brauchbare Kombinationen sind:

  • AES-128-GCM oder AES-256-GCM — Standard, schnell, hardware-beschleunigt auf den meisten CPUs
  • ChaCha20-Poly1305 — gute Alternative, besonders auf Geräten ohne AES-NI

AES mit CBC ist noch akzeptabel, aber GCM ist vorzuziehen. Von 3DES sollte man die Finger lassen. Wenn irgendwo RC4 oder DES auftaucht: abschalten.

Hashing

Der Hash sichert die Integrität der übertragenen Daten. Minimum ist SHA-256, ein guter Mittelweg ist SHA-384. SHA-1 sollte man nicht mehr einsetzen. Taucht MD5 auf, stimmt etwas grundlegend nicht.

Fragen, Korrekturen oder Ergänzungen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑