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

Schlagwort: Microsoft (Seite 1 von 3)

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

EC 521 bits / SHA256withRSA – Elliptic Curve mit openssl für den Apache

Heute möchte ich einmal ein Zertifikat für meinen munin erstellen. Als Test möchte ich einmal ein Zertifikat mit Elliptischen Kurven im Schlüssel probieren. Dieses soll natürlich ebenfalls von StartSSL signiert werden.

Die openssl Befehle sind wie immer nicht weiter besonders….

Schlüssel erstellen:

$ openssl ecparam -out http.key -name secp521r1 -genkey

CSR erstellen:

$ openssl req -new -sha256 -key http.key -nodes -out http.csr

Den Inhalt des CSRs ausgeben und der CA (StartSSL) zum signieren geben, sowie das signierte Zertifikat in die Datei http.crt gießen:

$ cat http.csr 
$ vi http.crt

Alles im PEM-File zusammenführen:

$ cat http.key http.crt > http.pem

Als guten Abschluss noch ein paar Diffie Hellman einwerfen (wenn auch etwas unnötig):

$ openssl gendh 4096 >> http.pem

Fertig ist das Zertifikat! Alles noch wie bekannt in den Apachen werfen und zur Sicherheit einmal Qualys auf die Seite loslassen:

https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com

Damit habe ich also nun ein EC 521 bits / SHA256withRSA Zertifikat. Tja, in meinem Firefox sieht alles aus wie immer. Gut, der Microsoft Rempel schlägt wie so oft hart auf aber ich nutze die Seite eh nie mit dem IE ;-P

Was meint ihr?

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Testtool Liste für schnelle und einfache Tests

Ich bin schon ein paar mal darum gebeten worden, doch bitte eine gesammelte Liste der verschiedenen Testtools zu erstellen.

Hiermit möchte ich dieser Bitte nachkommen.

Bitte beachtet aber, dass diese Tests/Checks in den meisten Fällen grob sind und nur verlässlich mitteilen können, ob etwas klappt oder nicht. Dennoch ist es hier und da eine schnelle und einfache Hilfe für Experimente und/oder um zu prüfen ob eine Änderungen greift!

So long….


Tests für Mail Server

SSL/TLS/TLSA/DANE/DNSSEC/SMTP Tests:
https://de.ssl-tools.net/mailservers/kernel-error.de

SSL/TLS/SMTP/POP/IMAP Tests:
http://www.checktls.com/

DANE SMTP Validator:
https://dane.sys4.de/smtp/kernel-error.de

DMARC TEST:
https://dmarcian.com/dmarc-inspector/kernel-error.de

SPF TEST:
https://dmarcian.com/spf-survey/kernel-error.de

http://www.kitterman.com/spf/validate.html

Mailserver Blacklist check:
http://mxtoolbox.com/blacklists.aspx

https://talosintelligence.com/

http://www.barracudacentral.org/lookups

DKIM / SPF / DMARC E-Mail Testadresse:
check-auth@verifier.port25.com

check-auth2@verifier.port25.com

Microsoft Tests:

https://testconnectivity.microsoft.com


Tests für Web Server

SSL/TLS Test:
https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

https://de.ssl-tools.net/webservers/www.kernel-error.de

SPDY Test:
https://spdycheck.org/#www.kernel-error.de


Tests für DNS Server

DNSserver:
http://www.dnsinspect.com/kernel-error.de

DNSSEC:
http://dnssec-debugger.verisignlabs.com/www.kernel-error.de

http://dnsviz.net/d/kernel-error.de/dnssec/


Tests für Jabber/XMPP Server

Jabber/XMMPP-Security Test:
http://www.xmpp.net/


Tests für Clients

IPv6 Client-Test:
http://test-ipv6.com

Webbrowser Test:
https://www.ssllabs.com/ssltest/viewMyClient.html

OPENGPGKEY RR:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Siehe auch: Hardenize Security Scanner

Fragen? Einfach melden.

HTTP Public Key Pinning – HPKP

Veraltet: HPKP (HTTP Public Key Pinning) wurde von allen Browsern entfernt. Chrome hat es 2019 abgeschaltet, Firefox 2020. Der Grund: Zu hohes Risiko, sich mit falschen Pins selbst auszusperren. Für Zertifikatsabsicherung nimmt man heute DANE/TLSA und Certificate Transparency.

Die aktuelle Gültigkeitsprüfung anhand von CAs hat so ihre Lücken. So erscheint jedes Zertifikat als gültig und vertrauenswürdig, sofern es nur von einer CA unterzeichnet wurde, welcher der Client selbst vertraut.

Erschleiche ich mir also ein gültiges Zertifikat für eine Domain oder schiebe es dem Client als vertrauenswürdig unter, wird sich der Benutzer zwar sicher und geschützt fühlen, dennoch ist er es nicht.

Mögliche Beispiele finden sich hier:
– Google deckt erneut Missbrauch im SSL-Zertifizierungssystem auf
– Comodo stellt fälschlicherweise Microsoft-Zertifikat aus

Nun gibt es mehrere Ansätze um diese Situation zu verbessern. TLSA / DANE zusammen mit DNSsec, HSTS (Strict Transport Security) usw… Inzwischen bin ich auf fast alle eingegangen. Es fehlt aber noch ein, wie ich finde, wichtiger Vertreter. HPKP (Public Key Pinning). Daher soll es nun um HPKP gehen.

Public Key Pinning verfolgt einen ähnlichen Ansatz, wie Strict Transport Security, erweitert diesen nur etwas. Strict Transport Security wird als HTTP-Header gesetzt und sorgt dafür, dass ein Client für den Ablauf einer, durch diesen Header, gesetzten Frist nur noch SSL/TLS gesicherte Verbindungen zu dieser Domain benutzen wird. Public Key Pinning sorgt nun zusätzlich dafür, dass der Client nur gewisse Zertifikate über einen bestimmten Zeitraum annimmt.

Sind beide Header gesetzt, baut der Client also nur noch gesicherte Verbindungen auf und akzeptiert nur noch bestimmte Zertifikate, für einen gewissen Zeitraum. Dieses bietet ebenfalls gewisse Lücken, dennoch hebt es die Sicherheit ein ganzes Stück an, denn es wird für einen Angreifer deutlich aufwendiger seine gefälschten Zertifikate ins Rennen zu bringen.

Wie funktioniert es nun genau?
Im HPKP Header übermittelt der Webserver zwei base64 encodete SHA256-Hash Werte von den Public Keys zweier Zertifikate, sowie eine Ablaufzeit (und ggf. noch ein paar Optionen). Zwei Hash Werte aus einem einfachen Grund… Es kann ja passieren, dass man sein Zertifikat tauschen möchte/muss. Wäre hier nur der Hash eines Zertifikates „fest gepinnt“, würden alle Clients den Verbindungsaufbau mit dem neuen Zertifikat verweigern und dieses im schlimmsten Fall bis zum Ablauf der gesetzten Frist (in meinem Beispiel gleich 60 Tage). Aus diesem Grund nimmt man zwei! Das aktive Zertifikat, welches man ggf. direkt von der CA unterschreiben lässt und einsetzte, sowie ein Backup-Zertifikat, welches man vielleicht nur bis zum CSR vorbereitet und an einer anderen Stelle aufbewahrt. Nun könnte man direkt noch ein anderes Verfahren einsetzten oder ein anderes System um dieses Zertifikat zu erzeugen usw. usw… Wir halten also fest, Hash Werte von zwei Zertifikaten, wobei eines selbstverständlich das aktive ist.

Diese Hashwerte lassen sich nun mittels openssl über die keys, csr oder das fertige Zertifikat bauen. Ich nehme dafür gerne direkt die keys, da sich aus diesen alles weitere ergibt. Als Test, auf korrekte Hash Werte, kann man natürlich alle drei Wege nutzen. Dabei sollten sich natürlich immer die gleichen Werte ergeben!

Ich gehe also davon aus, dass bereits zwei Keys erstellt wurden. Damit lassen sich nun wie folgt die Hash Werte erstellen:

$ openssl pkey -in http-active.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME=
$ openssl pkey -in http-backup.key -pubout | grep -v PUBLIC|base64 -d|openssl dgst -sha256 -binary|base64
KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA=

Um die Header setzten zu können muss beim Apache noch das Modul headers geladen werden:

$ a2enmod headers

In der eigentlichen Konfigurationsdatei des jeweiligen hosts/vhosts fehlt nun nur noch folgende Zeile:

Header always set Public-Key-Pins: 'max-age=5184000; pin-sha256="31XofAyJSqWKGO4xhVZFNe5+grAZQ4cvl2tahddU/ME="; pin-sha256="KJV9jpFftvj+TjzaVtnI44aYm8DdjdO00vFZ+YtBjdA="'

Hash Werte natürlich einpassen. und in dem Zuge über HSTS nachdenken!

Zusätzlich können noch ein paar Optionen in diesem Header folgen. So zum Beispiel report-uri=”http://www.example.org/hpkpReportUrl” Hier wird über einen HTTP-Post einige Informationen vom Client im JSON Format übertragen. Also ob es Probleme gab oder nicht… Die dort folgende URL sollte demnach vielleicht nicht SSL/TLS gesichert sein, oder nicht unter der gleichen Domain liegen. Wäre im Fehlerfall ja sonst ebenfalls nicht erreichbar! Ebenfalls lässt sich mittels includeSubdomains; zusätzlich angeben, dass dieses ebenso für alle Subdomains gilt.

Prüfen?
Prüfen kann man alles natürlich wieder per https://www.ssllabs.com/

Viel Spaß und wie immer, bei Fragen; fragen!

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Apache und sichere SSL / TLS Verschlüsselung

Google Browser Chrome wirft SHA1 Zertifikate weg…

Veraltet: SHA-1 in TLS-Zertifikaten ist seit Januar 2017 von allen großen Browsern abgelehnt. Dieser Beitrag ist ein Zeitdokument aus 2014, als Google den Ausstieg ankündigte.

Dass SHA-1 nicht der Brüller ist, wissen wir inzwischen alle. Dass man nicht so lange warten sollte wie bei MD5, bis es nicht nur ein theoretisches, sondern ein echtes Problem gibt, können sich viele denken. Leider bekommt man viele Entscheider nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Softwaremodule müssen getauscht werden, Hardware könnte ersetzt werden müssen. Windows XP wird so zum Beispiel abgehängt.

Googles Ankündigung

Google hat angekündigt, SHA-1 aus Chrome zu entfernen. Nutzt man Zertifikate mit SHA-1-Checksumme, gibt es eine Meldung im Browser: „Diese Seite ist nicht ganz sicher.“ Danach folgt eine deutliche rote Warnung, bis hin zum Punkt, dass solche Zertifikate nicht mehr unterstützt werden. Zeitplan damals: ab ca. 2017. Bei einer durchschnittlichen Gültigkeitsdauer von zwei Jahren für Kaufzertifikate konnte man zum letzten Mal mit gutem Gewissen am 31.12.2014 ein SHA-1-Zertifikat kaufen.

Was mir an Google damals gefiel: Sie haben sanften Druck auf die Entscheider ausgeübt, um mehr Sicherheit ins Internet zu bringen. SHA-1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern. Genau wie RC4 oder MD5. Kein Anwender prüft das von sich aus. Aber wenn die Software anfängt zu meckern, gibt es schnell Bewegung bei den Entscheidern und den „Weiter, weiter, fertigstellen“-Admins. Microsoft und Mozilla hatten sehr ähnliche Pläne.

Die CAs reagieren

Kurz nach der Ankündigung kamen die ersten E-Mails von den großen CAs. Hier die von Symantec:

Wichtiger Servicehinweis

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die
Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1
einzustellen. Das wird voraussichtlich ab Chrome 39 im November 2014
geschehen.

Symantec empfiehlt:
1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer
   Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015
   ablaufen, kostenlos durch Zertifikate mit SHA-2.

Hinweis: Root-Zertifikate mit SHA-1 sind nicht betroffen.

Ihr Support-Team von Symantec Website Security Solutions

Wie es ausgegangen ist

Im Januar 2017 hat Chrome 56 SHA-1-Zertifikate endgültig abgelehnt. Firefox und Edge zogen nach. Heute signiert jede CA mit SHA-256 oder besser. Wer sich für den aktuellen Stand von TLS und Zertifikaten interessiert: Da hat sich seit 2014 einiges getan.

Fragen? Einfach melden.

STOP GELD

Am Wochenende habe ich mal wieder den Al Bundy gegeben. Damit möchte ich sagen, ich habe den Inhalt meiner Geldbörse an meine Familie verteilt. Um heute in der Mittagspause nicht am Hungertuch nagen zu müssen, wollte ich vor der Arbeit noch schnell Geld aus dem Geldautomaten der Sparkasse in der Nähe ziehen.

Leide präsentierte sich die Kiste mit dem unten stehenden Bild (sorry für die schlechte Aufnahme)….

Lustig oder? Na ja, wie man es sieht! Auf dem Automat läuft also klar ein Microsoft Windows. Dieses hat sich auf die Nase gelegt. Fehler gibt es in jeder Software, einfach nur zu lachen und auf das „dumme“ Windows zu zeigen wäre hier wohl zu einfach.

Warum läuft denn auf dem Automat ein Windows? Ich denke zum Teil gutes Lobbying… Dieses wird es nur nicht alleine sein. Ich denke der laufende Support wird ebenfalls ein Thema sein (wie lange hatte so ein Windows XP noch gleich Support?).

Fragen? Einfach melden.

Exchange Online und Office 365: DNS-Einträge für eine BIND-Zone

Bei mir ist die Frage aufgeschlagen, was man in seine BIND-Zone schreiben muss, wenn man Exchange Online, Lync/Skype for Business oder Office 365 nutzen will. Microsoft zeigt einem während der Einrichtung eine Tabelle mit DNS-Einträgen an. Für Webinterface-Hoster kein Problem, für BIND-Admins aber erstmal Übersetzungsarbeit.

Ich liebe es, wenn Microsoft solche Dinge ins Deutsche übersetzt. „Verweist auf die Adresse“ statt „Points to“. „Gültigkeitsdauer“ statt „TTL“. Aber gut.

Hinweis: Lync heißt inzwischen Teams, die SRV-Records für Lync Federation sind aber weiterhin nötig, solange Skype for Business im Tenant aktiv ist.

Was Microsoft verlangt

Für eine Domain (hier kernel-error.com als Beispiel) werden folgende Records benötigt:

# Exchange Online
MX    0  kernel-error-com0i.mail.protection.outlook.com
TXT      "v=spf1 include:spf.protection.outlook.com -all"
CNAME    autodiscover → autodiscover.outlook.com

# Lync / Skype for Business / Teams
SRV      _sip._tls           443  1 100  sipdir.online.lync.com
SRV      _sipfederationtls._tcp 5061 1 100  sipfed.online.lync.com
CNAME    sip → sipdir.online.lync.com
CNAME    lyncdiscover → webdir.online.lync.com

# Office 365 allgemein
TXT      "MS=ms12345678"   (Domain-Verifikation)
CNAME    msoid → clientconfig.microsoftonline-p.net

Das BIND-Zonefile

Und so sieht das dann als BIND-Zone aus:

$ORIGIN .
$TTL 86400
kernel-error.com  IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                      2014010101 ; serial
                      15000      ; refresh
                      1800       ; retry
                      604800     ; expire
                      86400      ; minimum
                  )
                  NS  ns1.kernel-error.de.
                  NS  ns2.kernel-error.org.

$TTL 1H
                  IN TXT "MS=ms12345678"
                  IN TXT "v=spf1 include:spf.protection.outlook.com -all"
                  IN MX  0 kernel-error-com0i.mail.protection.outlook.com.

_sip._tls.kernel-error.com.              IN SRV 1 100 443  sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com. IN SRV 1 100 5061 sipfed.online.lync.com.

$ORIGIN kernel-error.com.
$TTL 1H
autodiscover  IN CNAME autodiscover.outlook.com.
sip           IN CNAME sipdir.online.lync.com.
lyncdiscover  IN CNAME webdir.online.lync.com.
msoid         IN CNAME clientconfig.microsoftonline-p.net.

Prüfen

Die gesetzten Records lassen sich mit dig prüfen:

dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de
dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de
dig +nocmd +noall +answer _sip._tls.kernel-error.com IN SRV @ns1.kernel-error.de
dig +nocmd +noall +answer autodiscover.kernel-error.com IN CNAME @ns1.kernel-error.de

Viel Spaß mit den Microsoft-Online-Produkten. Fragen? Einfach melden.

AOL macht jetzt auch Mailinglisten „kaputt“ / DMARC

Das gefällt mir laughing… Nachdem nun Yahoo die Eier hatte einfach mal ihre DMARC Policy „scharf“ (reject) zu schalten und sich so viel Schimpfe von aller Welt dafür eingesammelt hat und beschuldigt wurde die Mailinglisten „kaputt“ zu machen…. Tja, da zieht AOL nun in gewisser Weise nach: https://web.archive.org/web/20151222062444/http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ AOL hat nämlich gerade ein tierisches Spam-Problem. Also jetzt nicht direkt, eher haben andere das Problem, es betrifft AOL nur in soweit das deren Absenderdomain dafür missbraucht wird. Die Spam E-Mails sehen also so aus als wenn sie von AOL kommen. AOL hat nun also ihre DMARC Policy scharf geschaltet um das Problem damit etwas eindämmen zu können. Ob nun wohl so langsam Google und Microsoft ebenfalls nachziehen? Inzwischen sollten die Admins der Mailinglisten ja schon mal „warm“ gelaufen sein tongue-out

Fragen? Einfach melden.

P-A-N-I-C Millionen E-Mail Kennwörter geknackt!!!

Oh Gott…. Nein was machen wir jetzt bloß?

O-o nun mal im Ernst, mich wundert an der Geschichte eher dass dieses Viele überrascht. Schauen wir uns doch mal die durchschnittlichen Kennwörter der meistern Benutzer an. Die sind nicht wirklich gut und oft haben sie ebenfalls nur ein Kennwort  für alle ihre Dienste. Natürlich haben sie ja per default nichts zu verbergen, also wird auf „Sicherheit“ nicht unbedingt Wert gelegt… Klar geht mir in diesen Fällen immer ein Schmunzeln über die Lippen. Denn man hat ja nichts zu verbergen und ist ja alles nicht SO schlimm. Nur wenn mein E-Mail Passwort von anderen geklaut wurde, ne da muss natürlich was passieren.

Ich lese und höre in den letzten Tagen immer das fiese, böse, Masken und Kapuzen tragende Hacker die E-Mail Accounts gehackt hätten. Viel eher werden wohl verseuchte Rechner die Kennwörter bei der Eingabe oder Übertragung eingesammelt und Kriminellen geschickt haben. Wenn ich mich so bei einigen Kunden umschaue sieht man schnell dass die großen drei Sicherheitslöcher Anwendungsprogramme (Java, Flash, PDF) meist in recht alten Versionen vorliegen. Die Microsoft Produkte selbst bekommen ja meist per WSUS oder direkt von Microsoft ihre Updates. Java, Flash oder der Acrobat Reader kümmern sich „selbst“ darum. Leider muss der Anwender für die Installation der Updates administrative Rechte auf dem Rechner haben. Sonst kann er die Installation kaum durchführen. Gut, es gibt auch hier Lösungen… Welche ich produktiv im Einsatz gesehen habe kann ich an einer Hand abzählen. Daher hängt es mal wieder vom Einsatz der hauseigenen IT ab. Das klappt mal gut, mal weniger gut. Gibt es keine eigene IT, sieht es schnell schlecht aus. Warum muss überhaupt jeder Anwender ins Internet und warum immer mit Flash, Java und PDF?!?!

Es lässt sich kaum ändern. Vor einiger Zeit hatten wir ja schon mal etwas ähnliches. Wie groß ist dann wohl die Dunkelziffer tongue-out ? Beim letzten mal hat unser BSI nach langem überlegen die Idee eine Webseite zur Verfügung zu stellen auf welcher man seine E-Mail Adresse eingeben kann. Die Webseite war natürlich sofort tot und nicht erreichbar. Wer hätte schon damit rechnen können dass die eingeschüchterten Benutzer es wirklich probieren könnten? *kopfschüttel*

Man hat also seine E-Mail Adresse eingegeben und hat daraufhin die Info bekommen: Wenn deine E-Mail Konto geklaut wurde, dann bekommst du von uns eine GPG signierte E-Mail mit folgendem Betreff (Zufallszeichen). Nur wenn die E-Mail auch diesen Betreff hat ist sie von uns und du hast ein Problem!

Einmal mit Profis…. Nun nehmen wir das mal eben auseinander:

1. der GPG Schlüssel vom BSI ist auf der gleichen Webseite zu saugen und ist so vertrauenswürdig wie „der dicke Mann aus der Sparkassenwerbung“…
2. GPG ist toll nur wie viele der Anwender nutzen es wohl?
3. der Betreff, auf welchen es ankommt, wird bei einer GPG signierten E-Mail NICHT signiert. Er kann also wild geändert werden…
4. die E-Mail welche den Anwender darüber informiert das sein Account ggf. von anderen missbraucht wird, geht also an diesen Account. Der Missbrauchende müsste sie also nur ?löschen?.

Worried face meme reacting to stolen passwords

Welcher Internetausdrucker hat sich dieses bitte überlegt?!?!?

Diese Kritikpunkte sind beim BSI angekommen und man könnte meinen, sie hätten es beim jetzt neuen Fall besser gemacht… Haben sie?

Unimpressed reaction meme about password security

Natürlich nicht!!!

Zusätzlich wird man nun noch von seinem Provider informiert das sein Account „gefressen“ wurde und direkt gezwungen sein Kennwort zu ändern. Klappt natürlich nur bei den großen Providern. Ja OK, die meisten abgefischten Accounts liegen dort… Macht es denn noch nicht wirklich besser, oder?

Jetzt halten einige von den Pressemenschen wieder jedem dritten ihr Mikrofon unter die Nase… Dabei ergeben sich so Ideen wie: Es muss rechtliche Regelungen für so etwas geben. Zwei Wege Authentisierung usw. usw… Ob das wirklich alles so richtig ist?

Was bringt das alles wenn man Windows XP einsetzt, Java und Flash einem Sieb ähneln und die großen Provider dir beim Login erzählen das dein Adblocker die Sicherheit deines Browsers gefährdet? Dann sind wir schon bei E-Mail Made in Germany, richtig? Die Jungs hängen gerade an die große Glocke dass sie es 2014 geschafft haben TLS für ihre Verbindung einzuschalten und für die Anmeldung voraussetzten. 2014… Ich meine 2014… Das ist knapp 20 Jahre als. 2014. Die haben ihren Werbemastschweinen Kunden bis 2014 per Plaintext (also im Klartext) ein Login gestellt. Jeder hat durch bloßes hinschauen die Zugangsdaten abschreiben können. Die kommen dann mit „Sicherheit wiederherstellen“ und E-Mail Made in Germany und jetzt ist alles sicher?

Frustrated rage meme about email credential theft

Ach ich rege mich hier schon wieder auf…

Vielleicht sollte man aufhören seine Kunden auszuquetschen und mit Müll zu füttern. Hm, setzt natürlich voraus das die Kunden es wollen und vor allem mal von ihrem „kostenlos“ Ding wegkommen. Ach, ich höre nun auf, sonst habe ich für heute wieder schlechte Laune!

Siehe auch: E-Mail-Benachrichtigung bei Root-Login

Fragen? Einfach melden.

DMARC und Mailinglisten: Warum Signaturen brechen und wie ARC das löst

Wer eine strenge DMARC-Policy veröffentlicht und gleichzeitig Mailinglisten nutzt, wird früher oder später feststellen: Die eigenen Mails werden auf der Liste zugestellt, aber beim Empfänger abgelehnt. Das liegt nicht an einem Konfigurationsfehler, sondern an der Art wie Mailinglisten funktionieren.

Das Problem

DKIM signiert nicht nur den Body einer E-Mail, sondern auch bestimmte Header wie den Betreff. Mailinglisten-Manager wie Mailman verändern die Mail aber auf dem Weg zum Empfänger. Sie hängen einen Identifier an den Betreff ([liste-name]), fügen einen Footer mit Abmelde-Link an den Body an und setzen eigene Header. Jede dieser Änderungen bricht die DKIM-Signatur.

SPF schlägt ebenfalls fehl, weil die Mail jetzt vom Listserver kommt und nicht mehr vom Mailserver des ursprünglichen Absenders. Die IP des Listservers steht nicht im SPF-Record der Absender-Domain.

DMARC prüft ob mindestens DKIM oder SPF bestehen und das Alignment stimmt. Beides schlägt fehl. Bei einer Policy von p=reject wird die Mail vom empfangenden Server abgelehnt. Der Absender bekommt einen Bounce, der Empfänger sieht die Mail nie.

Workarounds der Listenbetreiber

Mailinglisten-Manager haben verschiedene Strategien entwickelt um das Problem zu umgehen:

From-RewritingDer Absender wird auf die Listenadresse umgeschrieben. DMARC-Alignment passt dann zur Listendomain. Nachteil: Man sieht nicht mehr wer die Mail geschrieben hat.
Subject-Tag weglassenKein [liste] im Betreff. Schont die DKIM-Signatur, aber der Betreff allein reicht nicht, die Signatur kann trotzdem brechen wenn der Body verändert wird.
Footer weglassenKein Abmelde-Link im Body. Schont DKIM, aber Listenbetreiber brauchen den Footer oft aus rechtlichen Gründen.
DKIM re-signingDie Liste signiert die Mail neu mit ihrer eigenen Domain. Funktioniert, aber die originale Signatur des Absenders geht verloren.

Keiner dieser Workarounds ist sauber. Entweder geht Information verloren oder die Authentizität leidet.

ARC: Die eigentliche Lösung

Authenticated Received Chain (RFC 8617) wurde genau für dieses Problem entwickelt. Die Idee: Jeder Zwischenserver (wie ein Listserver) speichert die Authentifizierungsergebnisse der eingehenden Mail in einem ARC-Header und signiert diesen. Der empfangende Server kann dann die Kette zurückverfolgen und sehen, dass die Mail beim Eintritt in die Liste noch gültig war.

Drei Header bilden die Kette:

ARC-Authentication-Results: i=1; lists.example.org;
  dkim=pass header.d=kernel-error.de;
  spf=pass smtp.mailfrom=kernel-error@kernel-error.com;
  dmarc=pass header.from=kernel-error.de

ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; ...
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.org; cv=none; ...

ARC-Authentication-Results enthält die Ergebnisse zum Zeitpunkt der Annahme. ARC-Message-Signature signiert die Nachricht in ihrem aktuellen Zustand. ARC-Seal signiert die gesamte ARC-Kette und verhindert Manipulation.

Der empfangende Mailserver prüft die ARC-Kette. Wenn er dem Listserver vertraut und die Kette gültig ist, kann er die Mail trotz gebrochener DKIM-Signatur zustellen. Gmail, Microsoft und Yahoo werten ARC bereits aus. rspamd unterstützt ARC-Validierung und ARC-Signing von Haus aus.

In der Praxis

Mailman 3 unterstützt ARC-Signing. Bei Mailman 2 lässt sich ARC über einen vorgeschalteten Milter nachrüsten. Wer rspamd als Milter einsetzt, kann ARC dort aktivieren und braucht keinen separaten Dienst.

Die Empfehlung für Listenbetreiber: ARC-Signing aktivieren und den Betreff nicht verändern (statt [liste] den List-Id-Header nutzen, den alle modernen Mailclients auswerten können). Für Absender mit p=reject: ARC reduziert das Problem erheblich, löst es aber nur wenn die Gegenseite ARC auch prüft. In der Übergangsphase hilft es, bekannte Listserver per DMARC-Whitelist von der Policy auszunehmen.

Fragen? Einfach melden.

« Ältere Beiträge

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑