6
DKIM private key exposed?
Hallo,
mein privater Mailserver nutzt schon seit Jahren DKIM und SPF-Einträge im DNS Eintrag. Die DMARC-Richtlinie ist auf p=reject gestellt, sodass alle invaliden Mails abgelehnt werden, wenn dkim oder spf scheitern. Das ganze funktioniert auch wunderbar.
In den letzten Tagen (seit dem 09.05.) bekomme ich öfter DMARC-Reports, diese habe ich gerade analysiert und einen leichten Schrecken bekommen. Die Mails (die nicht von mir stammen) werden laut den Reports zwar rejected, da SPF fehlschlägt, DKIM wird laut manchen Reports validiert, hier mal einen Auszug aus dem Report von google.com:
Die IP ist auch hier sehr häufig aufzufinden: https://www.abuseipdb.com/check/209.85.220.69
DKIM wird aber nicht in allen Reports erfolgreich validiert, nur in denen von amazonses und google. Ich habe auch noch Reports von corp.mail.ru bekommen, dort schlägt die DKIM-Überprüfung fehl. Betroffen sind insgesamt zwei von meinen Maildomains.
Da DKIM laut den Reports teilweise erfolgreich validiert wurde, habe ich jetzt die Befürchtung, dass mein Mailserver oder Masterserver (ISPConfig Multiserver setup) kompromittiert wurden. Deshalb bin ich erstmal jegliche Verbindungslogs durchgegangen, habe die Zugänge der MariaDB etc kontrolliert und zuletzt nochmal rkhunter auf allen Servern durchlaufen lassen. Dabei ist mir aber nichts aufgefallen, es ist auch alles generell ziemlich gut abgesichert (2FA bei phpMyAdmin, RSA Keys für SSH login, Host-Beschränkter Zugang, ...).
Kann es sein, dass manche Server z.B. zuerst den SPF validieren und die DKIM Überprüfung dann gar nicht mehr stattfindet und <dkim>pass</dkim> somit eine Fehlinformation ist?
Danke schonmal für eure Hilfe!
mein privater Mailserver nutzt schon seit Jahren DKIM und SPF-Einträge im DNS Eintrag. Die DMARC-Richtlinie ist auf p=reject gestellt, sodass alle invaliden Mails abgelehnt werden, wenn dkim oder spf scheitern. Das ganze funktioniert auch wunderbar.
In den letzten Tagen (seit dem 09.05.) bekomme ich öfter DMARC-Reports, diese habe ich gerade analysiert und einen leichten Schrecken bekommen. Die Mails (die nicht von mir stammen) werden laut den Reports zwar rejected, da SPF fehlschlägt, DKIM wird laut manchen Reports validiert, hier mal einen Auszug aus dem Report von google.com:
<record>
<row>
<source_ip>209.85.220.69</source_ip>
<count>4</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>meine.tld</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>meine.tld</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>meine.tld</domain>
<result>fail</result>
</spf>
</auth_results>
</record>Die IP ist auch hier sehr häufig aufzufinden: https://www.abuseipdb.com/check/209.85.220.69
DKIM wird aber nicht in allen Reports erfolgreich validiert, nur in denen von amazonses und google. Ich habe auch noch Reports von corp.mail.ru bekommen, dort schlägt die DKIM-Überprüfung fehl. Betroffen sind insgesamt zwei von meinen Maildomains.
Da DKIM laut den Reports teilweise erfolgreich validiert wurde, habe ich jetzt die Befürchtung, dass mein Mailserver oder Masterserver (ISPConfig Multiserver setup) kompromittiert wurden. Deshalb bin ich erstmal jegliche Verbindungslogs durchgegangen, habe die Zugänge der MariaDB etc kontrolliert und zuletzt nochmal rkhunter auf allen Servern durchlaufen lassen. Dabei ist mir aber nichts aufgefallen, es ist auch alles generell ziemlich gut abgesichert (2FA bei phpMyAdmin, RSA Keys für SSH login, Host-Beschränkter Zugang, ...).
Kann es sein, dass manche Server z.B. zuerst den SPF validieren und die DKIM Überprüfung dann gar nicht mehr stattfindet und <dkim>pass</dkim> somit eine Fehlinformation ist?
Danke schonmal für eure Hilfe!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7487175062
Url: https://administrator.de/contentid/7487175062
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Du hast doch die Liste mit den Fehlermeldungen. Was spricht dagegen, einfach von einen Server der nicht auf der SPF-Liste steht eine Testmail zu schicken?
lks
Du hast doch die Liste mit den Fehlermeldungen. Was spricht dagegen, einfach von einen Server der nicht auf der SPF-Liste steht eine Testmail zu schicken?
lks
Zitat von @Lochkartenstanzer:
Moin,
Du hast doch die Liste mit den Fehlermeldungen. Was spricht dagegen, einfach von einen Server der nicht auf der SPF-Liste steht eine Testmail zu schicken?
lks
Moin,
Du hast doch die Liste mit den Fehlermeldungen. Was spricht dagegen, einfach von einen Server der nicht auf der SPF-Liste steht eine Testmail zu schicken?
lks
die Mail würde dann ja natürlich nicht durchkommen. Das funktioniert ja auch alles soweit. Mache mir ja nur Sorgen, dass mein DKIM private Key exposed sein könnte.
Ich habe jetzt aber mal ein paar Spoofmail Webdienste genutzt um an eine Google-Mailadresse eine gespoofte Mail mit meiner privaten Domain als Absender zu schicken, um die DMARC-Reports dann zu vergleichen... ob diese aber überhaupt beim Googleserver bis zu den dkim/spf Checks durchgehen bezweifel ich
Habe auf die schnelle auch keinen korrekt konfigurierten Ersatz-Mailserver hier, mit dem ich das testen könnte.
Natürlich kommt die Mail nicht durch aber Du siehst dann, ob bei dkim pass oder fail steht. Dann weißt du, wenn der empfangende Server pass meldet, obwohl das nicht sein kann oder fail, obwohl er bei der Mail vom unbekannten Pass gesagt hat. Dann wäre derkey tatsächlich geleakt. Damit hast Du indirekt nachgeschaut, ob es am empfangenden Server oder einem leak.luegt.
lks
lks
Ich habe schon manchmal merkwürdige Diskrepanzen in den Reports gesehen.
Teilweise wird das durch ARC oder durch Signaturen für die Envelope-Adresse erzeugt.
Wie sieht denn bei DMARC deine Vorgabe für das Alignment aus? Wenn du erzwingen willst, dass E-Mails keine abweichende Domain zwischen To:-Header und Envelope-Sender haben dürfen, musst du das Alignment auf Strict stellen, standardmäßig wird Relaxed angenommen.
Teilweise wird das durch ARC oder durch Signaturen für die Envelope-Adresse erzeugt.
Wie sieht denn bei DMARC deine Vorgabe für das Alignment aus? Wenn du erzwingen willst, dass E-Mails keine abweichende Domain zwischen To:-Header und Envelope-Sender haben dürfen, musst du das Alignment auf Strict stellen, standardmäßig wird Relaxed angenommen.
1Zitat von @LordGurke:
Ich habe schon manchmal merkwürdige Diskrepanzen in den Reports gesehen.
Teilweise wird das durch ARC oder durch Signaturen für die Envelope-Adresse erzeugt.
Wie sieht denn bei DMARC deine Vorgabe für das Alignment aus? Wenn du erzwingen willst, dass E-Mails keine abweichende Domain zwischen To:-Header und Envelope-Sender haben dürfen, musst du das Alignment auf Strict stellen, standardmäßig wird Relaxed angenommen.
Ich habe schon manchmal merkwürdige Diskrepanzen in den Reports gesehen.
Teilweise wird das durch ARC oder durch Signaturen für die Envelope-Adresse erzeugt.
Wie sieht denn bei DMARC deine Vorgabe für das Alignment aus? Wenn du erzwingen willst, dass E-Mails keine abweichende Domain zwischen To:-Header und Envelope-Sender haben dürfen, musst du das Alignment auf Strict stellen, standardmäßig wird Relaxed angenommen.
das habe ich im DMARC-Record nicht weiter definiert, also relaxed. Wenn ich das richtig verstanden habe, dann bedeutet das relaxed auch nur, dass die Domains (Envelope oder DKIM Domain) auch eine Subdomain der "FROM"-Domain sein darf. Aber DKIM müsste ja ohne den richtigen Key oder einer Subdomain von mir auf jeden Fall fehlschlagen, da die Mail ja nicht ohne meinen privaten Key signiert werden kann, oder?
Zitat von @Lochkartenstanzer:
Natürlich kommt die Mail nicht durch aber Du siehst dann, ob bei dkim pass oder fail steht. Dann weißt du, wenn der empfangende Server pass meldet, obwohl das nicht sein kann oder fail, obwohl er bei der Mail vom unbekannten Pass gesagt hat. Dann wäre derkey tatsächlich geleakt. Damit hast Du indirekt nachgeschaut, ob es am empfangenden Server oder einem leak.luegt.
lks
Natürlich kommt die Mail nicht durch aber Du siehst dann, ob bei dkim pass oder fail steht. Dann weißt du, wenn der empfangende Server pass meldet, obwohl das nicht sein kann oder fail, obwohl er bei der Mail vom unbekannten Pass gesagt hat. Dann wäre derkey tatsächlich geleakt. Damit hast Du indirekt nachgeschaut, ob es am empfangenden Server oder einem leak.luegt.
lks
Ich bezweifel nur, dass die gespooften Mails (von den fragwürdigen Webseiten) überhaupt HELO oder DNSBL von Google überstehen und ich so erst gar keinen Report bekommen werde. Oder kennt ihr nen vertrauenswürdigen Mailservice bei dem ich auch (ohne weitere Anträge) mit ner fremden Domain Mails verschicken kann?
Gerade kam ein neuer Report von Google, das Ergebnis ist ernüchternd:
Also ich denke an drei Möglichkeiten:
Ich würde natürlich jetzt nur ungerne alles neu aufsetzen, besonders da ich sonst weiter nichts verdächtiges bemerkt habe. Um an die DKIM Keys zu kommen, müsste schon sehr weit ins System eingedrungen worden sein, was ich mir bei einem so großflächigen Angriff kaum vorstellen kann. Passwörter sind auch alle verschieden, 32-stellig, kryptisch und in ner lokalen keypass datenbank gesichert, Fehlversuche sind 'ratelimited' durch Fail2Ban, Standardports sind größtenteils ausgetauscht und alle Software ist auf dem neusten Stand. In Verbindungslogs und Fail2Ban logs kann ich auch keine Besonderheiten entdecken (natürlich gibts täglich Angriffe auf sshd, sasl und imap, aber nur wenige und ungezielt). Was denkt ihr dazu?
<record>
<row>
<source_ip>89.187.129.21</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>reject</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>meine.tld</header_from>
</identifiers>
<auth_results>
<spf>
<domain>meine.tld</domain>
<result>fail</result>
</spf>
</auth_results>
</record>Also ich denke an drei Möglichkeiten:
- Es gibt ne Lücke bei der DKIM Validierung (bei den Berichten von abuseipdb sind viele Reports mit validen DKIM geposted), wahrscheinlich ähnlich wie es @LordGurke geschildert hat
- Meine Server wurden kompromittiert und ich muss alles neu aufsetzen
- Fehler bei den DMARC Reports
Ich würde natürlich jetzt nur ungerne alles neu aufsetzen, besonders da ich sonst weiter nichts verdächtiges bemerkt habe. Um an die DKIM Keys zu kommen, müsste schon sehr weit ins System eingedrungen worden sein, was ich mir bei einem so großflächigen Angriff kaum vorstellen kann. Passwörter sind auch alle verschieden, 32-stellig, kryptisch und in ner lokalen keypass datenbank gesichert, Fehlversuche sind 'ratelimited' durch Fail2Ban, Standardports sind größtenteils ausgetauscht und alle Software ist auf dem neusten Stand. In Verbindungslogs und Fail2Ban logs kann ich auch keine Besonderheiten entdecken (natürlich gibts täglich Angriffe auf sshd, sasl und imap, aber nur wenige und ungezielt). Was denkt ihr dazu?
