Posts by Snowpaws

Was zeigt die Statistik vom redis? Meine erste Idee wäre dort zu schauen, was drin steht.

Hallo zusammen,

ich betreibe seit Jahren einen eigenen Mailserver mit ein paar Domains, soweit so unspektakulär. Alle paar Monate bekam ich über den DMARC-Report Rückmeldung, daß eine dkim Signatur kaputt war. Die Mails waren von mir, das war klar, aber in keinem Fall konnte ich den Fehler genauer Eingrenzen bis heute. Ich habe über einige Zeit jeder ausgehende Mail vom Relay als bcc zurückschjcken lassen, um zu prüfen, ob das Problem bei mir liegt. Denn ursprünglich war der Ansatz, das Probleme läge bei Microsoft, über Monat trat es nur dort auf obwohl prozentual mehr Ziele auf andere Anbieter verteilen.

Das Problem war, daß SMTP eine maximale Zeilenlänge bei 1000 Zeichen (inkl. crlf) hat und bei Codierung als 8bit / utf-8 diese Zeilenlänge überschritten werden kann. Postfix bricht dann um, am Ziel sieht man nichts, aber die Signatur ist kaputt.

Struktur ist bei mir so:

A - Hauptserver, versendet lokal, signiert, empfängt Mails aus dem Internet
A schickt alles an ein Relay B
B versendet ins Internet, der direkte Versand von A wäre der Fallback.

Die Gegenrichtung geht normalerweise direkt an A, B könnte aber auch Mails empfangen und an A leiten.

Der Grund ist, daß es 1. historisch so gewachsen ist und 2. auch andere Server über B raussenden und die IP-Reputation entsprechend gut ist, keine rbl etc.

Also mir ist klar, wenn B signieren würde, was ich heute mal getestet habe, dann klappt es natürlich, aber ich würde ungerne meine Config umbauen, die so absolut stabil läuft.

Wie machen es andere?

Das Zeilenlimit von Postfix hochzudrehen würde ins Internet nicht klappen, SMTP kennt so tolle Fehlermeldungen aus dem 500er Bereich, wäre also doof. Normal senden auch alle Clients quote-printable mit frühem Umbruch, daher trat der Fehler nur sporadisch auf.

Ich signiere mit rspamd, das ist als Milter in Postfix eingebunden, der übernimmt in Gegenrichtung auch das Spamfiltern.

System ist Debian Trixie, postfix 3.10.x, rspamd 4.1.x, dovecot 2.4.x

Grüße.

Das ist schon korrekt, ich konnte das so auch nachstellen. Das fiese war nur, daß mein Workaround eben auch die exakte Datei /etc/modprobe.d/disable-algif_aead.conf schrieb und somit das Rollback davon auch den Workaround von Ubuntu entfernt hat. Erneutes Patchen führte auch nicht zum Erfolg, die Datei wird nicht erneut angelegt.

Hat einen Moment gebraucht zu erkennen, wieso eben ansible nicht das tat, was ich erwartete. Mir wäre da lieber gewesen, einen anderen namespace für das file zu benutzen, bei Dirty Frag wurde ja auch nur genau der name vom gitrepo genommen, der als Workaround beim Exploitcode benutzt wurde.

Also ja, funktioniert, aber evt. gibt es eben auch außerhalb des Kernel-Patches etwas robustere Lösungen.

Quote from Bruder_Strozzapretus

Ubuntu, darauf basierend Linux Mint hat die Kernel noch nicht gepatcht, aber via kmod das Problem abgefangen bis die Kernel gepatcht sind. Auf meinem LM 21.3:

Code

cat /etc/modprobe.d/disable-algif_aead.conf
# Disable algif_aead module due to CVE-2026-31431 (AKA copy.fail)
# This will likely be re-enabled in a subsequent update once an updated
# kernel has been deployed.
# Blacklisting the module isn't sufficient, we need to do as below:
install algif_aead /bin/false

Moin,

ich bin etwas enttäuscht von Ubuntu, aktuell betreiben wir vorwiegend 24.04.4 LTS in der Umgebung. Für CVE-2026-31431 hatte ich in meiner Testumgebung den Server aktualisiert, meinen manuellen Workaround zurückgerollt und hatte ein verwundbares System. Der scheint wirklich nur einmalig bei apt upgrade das Laden des Kernel-Moduls über /etc/modprobe.d zu unterbinden und wenn man in seinem eigenen Playbook den exakt gleichen Dateinnamen wir Ubuntu benutzt hat man verloren.

Debian hatte die Kernel-Patches vergleichsweise schnell in den Repositories, privat benutze ich nur das.

Ich muß dazu sagen, daß ich in der Firma die Systeme nur sicherheitshalber gepatched habe, die öffentlich erreichbar sind, direkt kommt kein User auf die Shell. Bei einem Freund war es anders, da haben Kunden ggf Shell-Zugriff, der war leicht genervt.

Für CVE-2026-43284 hat Ubuntu noch keinen offiziellen Patch.