Phishing Mails Filtern

[reox]

ich bekomme seit kurzen immer wieder PayPal Phishing Mails, welche im SPAM Filter nicht anschlagen, da vermutlich zu ähnlich einer echten Nachricht:

Code: Alles auswählen

X-Spam-Flag: NO
X-Spam-Score: 3.765
X-Spam-Level: ***
X-Spam-Status: No, score=3.765 required=5 tests=[BAYES_00=-1.9,
	DKIM_ADSP_DISCARD=1.8, HTML_FONT_LOW_CONTRAST=0.001,
	HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, MISSING_MID=0.497,
	RCVD_IN_BRBL_LASTEXT=1.449, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001,
	URIBL_JP_SURBL=1.25] autolearn=no autolearn_force=no
Received-SPF: softfail (paypal.de: Sender is not authorized by default to use 'service@paypal.de' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=mail.xxx.tld; identity=mailfrom; envelope-from="service@paypal.de"; helo=loft9615.serverprofi24.de; client-ip=85.25.207.7

Ich les eigentlich überall das man SPF nicht zur SPAM Erkennung verwenden soll. Also was bleibt mir übrig um die zu erkennen? Vermutlich über die URL, welche auf die Phising Seite linked, nur gibt es dafür Filterlisten die aktuell sind?
Was mich ja wundert, is dass BAYES sagt -1.9. Sonst wäre die Nachricht ja eh über 5 und würde geblockt. Macht es Sinn DKIM und SPF höher zu bewerten?

Und warum verwenden eigentlich fast alle nur SOFTFAIL? Die einzigen die ich adhoc gefunden hab, welche hardfails verwenden, sind Microsoft...

[Gunah]

wo hast du den gelesen, dass man SPF nicht verwenden sollte?
Das Problem an SPF ist wenn dass es Falsch vom Mail Server Inhaber/Domain falsch verwendet wird.
Nur ist das meist falsch konfiguriert.

den PTR solltest du auch checken, aber der wird auch oft falsch gesetzt.

Wir haben uns auch dazu entschlossen keine unverschlüsselten Inhalte mehr anzunehmen, was die Zahl auch deutlich gesenkt hat.

Was aber deutlich auffällt ist, dass einige Spammer besser Server konfigurieren können, als die nicht Spammer ^^

[reox]

oh danke für den hinweis mit dem PTR... Ich war mir ziemlich sicher das es eingestellt ist, aber reject_unknown_client_hostname war nicht drin...

wegen SPF: Das steht sogar auf Wikipedia, dass SPF keine Maßnahme zum SPAM filtern ist, schon gar nicht wenn der Record explizit nur SOFTFAIL sagt. Steht auch in diversen Stackoverflow Posts und auf Mailinglisten

[r4pt0r]

SPF und DKIM gehört definitiv ins scoring!
Zudem lasse ich mittlerweile pauschal Mails mit Anhängen mit bestimmten Dateiendungen (exe, zip, xlsx, docx....) mit Fehlermeldung blocken. Andere Anhänge ("normale" .doc/.xml z.b.) gehen an nen Account der zum einen separat nochmal gescant (bitdefender) wird und was dann noch übrig bleibt wird mir als täglicher digest gemeldet damit ichs entweder gesammelt purgen oder ggf weiterleiten kann. Das hält sich mit max ca 2-3 legitimen Mails/Woche die übrig bleiben im Rahmen...

Was aber deutlich auffällt ist, dass einige Spammer besser Server konfigurieren können, als die nicht Spammer ^^

Das ist mir nun auch schon mehrfach aufgefallen. Ich musste mittlerweile eine ansehnliche whitelist ansammeln für "große Unternehmen" die schlicht zu blöd sind ihre Mail- oder DNS-Server zu konfigurieren.
Den Vogel abgeschossen haben bisher die "Spezialisten" eines weltweiten Automobilzulieferers - die haben doch tatsächlich einen "localhost" als MX-Record, der sogar nen A-Record auf 127.0.0.1 bekommen hat. Habe darauf vor mittlerweile 6 Wochen hingewiesen, ausser einem Anruf von einem "Admin" aus der "IT-Abteilung" der mir nur sagen konnte, dass diese Domain garnicht für mailvesand vorgesehen ist und ob ich nicht "temporär" nen Whitelist-eintrag anlegen könnte, ist nix passiert. Aber was will man von MCSEs auch erwarten - solange sie sich ohne schwere Verletzungen die Schuhe zubinden können muss man zufrieden sein (Den erneuten Hinweis auf nen uralten IIS der am zweiten eingetragenen MX horcht hab ich mir dann auch erspart...)
Solange solche Amateure für wirklich große Mailsysteme verantwortlich sind wird man wohl Phishing weiterhin auch zeitintensiv manuell und durch reden mit Wänden schulen der User bekämpfen müssen...


Bei SPF ist das Hauptproblem, dass die meisten "großen" mailschleudern das nur mit softfail konfigurieren - was ursprünglich nur für die einführungsphase gedacht war. google, ebay, paypal, amazon usw gehören da leider auch dazu - gerade die bei denen korrekte SPF-Records richtig Sinnvoll wären... Mit solchen fehlinformationen wie auf Wikipedia wird das auch nicht besser mit den SPF-Records

Wenn DNSSEC (nach 10 Jahren...) mal endlich flächendeckender ausgerollt würde, könnte man hierüber das scoring sicher auch nochmal verbessern - vorausgesetzt die "Großen Phishingziele" kümmern sich um korrekte konfiguration...


Ich experimentiere aktuell auch mit shiva und simplen "passiven" SMTP-honeypots (Perl Mail::SMTP::Honeypot), aus deren logs ich muster und/oder listen generiere. Das ganze ist aber völlig experimentell und kommt nicht für blocking an produktivsystemen zum Einsatz. Derzeit matche ich automatisiert nur die reinen hostdaten (kleinere Proben, nicht alles!) gegen "öffentliche" DNS-Blacklisten, um zu sehen wie hoch der Informationsgehalt einzuschätzen ist. Allerdings ist reines DNSBL lange nicht so effektiv wie andere Muster die sich aus solchen Daten rausfiltern lassen. Die Idee mails anzunehmen und an spamassassin zu füttern hab ich recht schnell verworfen - nach ein paar tagen wäre das als will man aus nem Feuerwehrschlauch trinken - das steigt nach ca 3-4 tagen explosionsartig an. Da sind dann die kleinen droplets die ich bei digitalocean dafür nutze einfach zu schwach, und viel Geld kann/will ich dann für so ein kleines testprojekt auch nicht "nebenher" rauswerfen...