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

Kategorie: IT-Security (Seite 4 von 15)

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

WSUS-Bereinigung: Timeouts beheben und Speicherplatz freigeben

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.

SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen​

Wenn man mit einem System im Internet steht fummelt immer irgendein script kiddie oder bot an den Diensten herum. Oft ist hier eine IP Adresse aus China dabei. Dann probieren sie ein paar default logins und wandern weiter zur nächsten IP Adresse. Die Bots geben dem Ganzen in der Regel schon nicht mehr als drei Versuche, weil sie dann eh von irgendeinem Sicherheitssystem geblockt werden. Da es noch viele andere bots hinter anderen IP Adressen gibt, übermittelt der bot nur seinen Stand der Versuche an das Hirn des Botnetzes und der nächste, nicht geblockte bot, kommt und probiert es weiter…

Alles „kalter Kaffee“… In den letzten Wochen fallen mir zwei kleine Veränderungen auf.

old SSH Bot

Einmal kommen diese IP Adressen noch immer stark aus China… ABER sehr oft ebenfalls von DigitalOcean (USA). Zudem fallen mir die anderen Cloudprovider auf (Google, Microsoft, AWS…). Das verschiebt sich aktuell wohl etwas. Normalerweise kommt ganz viel aus China, dann ganz viel von verschiedenen dynamischen Endkundenanschlüssen auf der Erde. Jetzt kommt ganz viel aus China, dann unglaublich nahe daran Digitalocean, direkt gefolgt von der google-cloud und microsoft-cloud. Erst jetzt kommen die Endkundenanschlüsse und mischen sich mit Adressen aus der AWS-Cloud. Scheinbar haben die Amazonjungs irgendetwas „besser“ gemacht, um ihre Kunden davor zu schützen sich etwas „einzufangen“?!?

Zweitens scheint da ein Botnetz mit recht alter ssh Implementierung unterwegs zu sein. Oder es sucht halt speziell alte SSH-Server? Auf IoT Geräte mit alter Firmware tippe ich weniger, denn von diesen kommt ebenfalls etwas von Cloudanbietern. Bei denen unterstelle ich einfach mal, keine alten IoT Geräte im Einsatz zu haben, die infiziert sind. Naja… Oder es wird halt nach genau solchen Geräten gesucht. Warum alt? Weil ich so etwas in den Logs finde:

Apr  8 10:35:58 YOURMOM sshd[43201]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:35:58 YOURMOM sshd[43201]: Did not receive identification string from 1.2.3.4 port 34244
Apr  8 10:36:22 YOURMOM sshd[43202]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:22 YOURMOM sshd[43202]: Unable to negotiate with 1.2.3.4 port 36160: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]
Apr  8 10:36:42 YOURMOM sshd[43204]: reverse mapping checking getaddrinfo for 4.3.2.1.serverdedicati.mum.your [1.2.3.4] failed.
Apr  8 10:36:42 YOURMOM sshd[43204]: Unable to negotiate with 1.2.3.4 port 39556: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

Wie ist das bei euch?

Siehe auch: SSH-Server absichern mit MFA, SSH-Bruteforce, DigitalOcean und AbuseIPDB – warum Blocken das Problem nicht löst, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi

Fragen? Einfach melden.

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.

internet.nl verschärft die TLS-Anforderungen für Mailserver

E-Mail Test der Niederlande für die E-Mail Domain kernel-error.de
Die Domain kernel-error.de ist in der Hall of Fame der niederländischen IT Security Tests.

Der niederländische internet.nl Mailserver-Test hat die Anforderungen verschärft. Die neuen Guidelines orientieren sich an den aktuellen niederländischen IT-Sicherheitsrichtlinien und ziehen die Messlatte deutlich an.

Was sich geändert hat

TLS 1.0 und 1.1 geben jetzt Abzug. Vorher wurden sie toleriert, jetzt gibt es eine explizite Warnung. Schwache Diffie-Hellman-Parameter und weitere veraltete Cipher sind herausgefallen. Alles um TLS 1.3 den Weg zu ebnen.

Die Hall of Fame hat eine neue Sektion für Champions bekommen: Domains die sowohl beim Webserver als auch beim Mailserver 100 Prozent erreichen.

Warum das relevant ist

internet.nl ist kein akademisches Testtool. Die Ergebnisse fließen in die Bewertung niederländischer Behörden und Dienstleister ein. Wenn dort die Standards steigen, zieht das langfristig auch die Anforderungen an internationale Kommunikationspartner nach oben. Wer mit niederländischen Behörden oder Unternehmen per E-Mail kommuniziert, sollte seinen Score im Auge behalten.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Shodan wertet security.txt aus.

Screenshot der shodan Webseite für die Auswertung der security.txt

Zufällig habe ich gesehen, dass die Suchmaschine Shodan bereits die security.txt auswertet und als Security Contact auflistet. Genau so habe ich mir das vorgestellt. https://www.shodan.io/host/148.251.40.23

Zur security.txt habe hier hier schon was geschrieben: Draft zu Security Policies

Dann steht ab jetzt der Security Contact zumindest schon mal direkt über den offenen CVEs, hm?

Siehe auch: security.txt dieses Blogs

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.

Draft zu Security Policies

Es gibt seit einiger Zeit einen Draft zu Security Policies. Schaut mal hier: https://tools.ietf.org/html/draft-foudil-securitytxt-07 über diesen Weg kann man für seine Domain eine Security Policie veröffentlichen. Dieses inkl. Kontaktdaten einer „Dankeschön“ Seite usw…

Die Idee ist es eine einheitliche Möglichkeit zu schaffen um freundlichen Findern von Sicherheitslücken/Problemen eine einfache und „sichere“ Anlaufstelle zu geben. Wer schon mal ein Löchlein gefunden hat, kennt das Problem. Man sucht eine Kontaktmöglichkeit, scheitert an der Human Firewall oder am technischen Verständnis von seinem Gegenüber. Gibt es es bug bounty oder wird der Informierte ~nervös~?!? Ist die Webseite vielleicht schon kompromitiert und der Hinweis wandert direkt an den Bösewicht? usw. usw. usw…

Diese Probleme soll dieser RFC möglichst einfach erschlagen. Es gibt ein textfile mit dem Namen security.txt unter der jeweiligen Domain im Pfad .well-known, diese ist nach Möglichkeit noch gpg cleartext signiert und beinhaltet alle nötigen Informationen.

Als kleine Beispiel: https://www.kernel-error.de/.well-known/security.txt

Es gibt sogar noch ein kleines Tool zum kreieren des Textfiles: https://securitytxt.org/

Da ich selbst sehr oft vor dem Problem stehe eine saubere Kontaktadresse zu finden, begrüße ich diesen RFC natürlich sehr!

Viel Spaß!

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑