Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Problemen met SPF records en forwarding van mail.

15-12-2014, 14:14 door Briolet, 12 reacties
Laatst bijgewerkt: 15-12-2014, 14:15
Een paar week geleden hoorde ik voor het eerst van een SPF record bij mail. Dat was in verband met phishing mails die ogenschijnlijk door bol.com verstuurd waren.

Een SFP record zou dit soort mail beter kunnen blokkeren. Erik van Straten heeft toen ook duidelijk uitgelegd dat er heel makkelijk omheen te werken is door kwaadwillenden. Ik kreeg in die zelfde week ook een mailtje dat op grond van het SFP record tot spam verklaard was. Volledig ten onrechte zoals ik aannam en Erik heeft op 25-11-2014 mijn vermoeden ook bevestigd in dat draadje. https://www.security.nl/posting/409422/Valse+e-mail+Bol_com+verspreidt+ransomware
(mijn dank)

Vandaag kreeg ik weer een mail die ten onrechte als spam aangemerkt was omdat het SPF systeem gewoon niet goed werkt. En niet kan werken bij forwards. In beide gevallen gaat het om geforwarde mail en een hard fail.

toen was het vitens mail:
Briolet$ host -t txt vitens.nl
vitens.nl descriptive text "v=spf1 ip4:217.77.137.88 ip4:194.9.84.128/26 ip4:91.197.72.0/22 ip4:31.24.48.24 ip4:31.24.48.25 ip4:31.24.48.221 ip4:31.24.48.222 ip4:195.121.247.0/24 ip4:213.206.227.145 -all”

Nu was het een mailtje van de stentor:
Briolet$ host -t txt mailservice.wegenernieuwsmedia.nl
mailservice.wegenernieuwsmedia.nl descriptive text "v=spf1 mx a include:spf.emsecure.net -all"

De mail gaat naar Ziggo en die forward het aan mijn provider die het dan weigert omdat hij Ziggo als afzender ziet. 212.54.42.168 is een IP van Ziggo.
Received-Spf: fail (dataweb.nl: domain of destentor@mailservice.wegenernieuwsmedia.nl does not designate 212.54.42.168 as permitted sender)

Nu is mijn vraag: weet iemand hoe groot de kans is dat hard fail berichten gewoon niet aankomen en je dus essentiële mail mist i.p.v. dat ze als spam aangemerkt worden? Heb ik geluk met mijn provider dat hij ze niet weigert? Ik kan bij hun de spam-settings niet aanpassen.
Reacties (12)
15-12-2014, 15:39 door wizzkizz
Waarom de moeilijk omweg via Ziggo? Hoe zit je systeem van email (providers) in elkaar? Pas dan kan ik er iets over zeggen.
15-12-2014, 15:53 door Anoniem
Even heel kort door de bocht, als men op correcte wijze controleerd op een SPF stict (-all) zal het bericht geweigerd worden.

SPF is per definitie kwetsbaar voor forwarding, nu zijn er manieren om dit te omzeilen (Sender Rewriting Scheme) echter wordt dit door de huis-, tuin- en keuken hosters nooit toegepast. ISP's core business is nooit e-mail, verwacht ook niet dat ze SRS zullen implementeren.

Vele partijen, zoals bijv. Google, Microsft en Yahoo, nemen het SPF record mee in hun totale evaluatie en zullen nooit op alleen SPF een beslissing nemen.

Een ideaal scenario:
Indien je forwarding in een eigen mail-flow toepast, doe je er goed aan alleen SPF te checken op je gateway en dit resultaat met behulp van een Authentication-Result header mee te geven aan de rest van de infrastructuur.

Als je voor e-mail SPF, DKIM en DMARC in place hebt kun je best met een SPF ~all policy af, echter zijn er nog te weinig partijen die op DKIM en DMARC controleren.
15-12-2014, 16:00 door Anoniem
Een SPF fail is geen teken van spam. Jaren geleden was het juist een teken van spam als SPF matchte, omdat spammers met een SPF record pluspunten verzamelde.

Een SPF faal zegt alleen dat iets niet klopt. Het zou dus in de meeste gevallen niet moeten worden gebruikt om mail te blokkeren. Wel om te waarschuwen. Helaas zijn mail clients die zo'n check doen dun gezaaid.

Het komt ook redelijk vaak voor dat de berichten niet vervalst zijn, een faal kan dus ook komen door een fout SPF record. Bijvoorbeeld als een mail server IP wordt gewijzigd, maar het SPF record niet. Dat is ook een reden om SPF niet als blokkeringsmechanisme te gebruiken.

Tegenwoordig komt veel phishing (waartegen SPF enige bescherming biedt) niet het domein van een bank of provider gebruikt maar iets anders. Dan valt direct ook de bescherming weg.

Al met al is de bedrijfszekerheid van SPF en DKIM laag.
15-12-2014, 16:22 door Anoniem
De hele gedachte achter SPF is dat uitsluitend diegenen die in het record zijn opgenomen mail kunnen sturen zodat via het SPF record dit gevalideerd kan worden. Ziggo staat niet in dit lijstje, dus zou geen mail van deze partij moeten transparant moeten forwarden. Het SPF record / systeem werkt perfect, maar jij begrijpt de werking niet.

Oplossing kan zijn om Ziggo in het SPF record op te nemen of je forwarding te veranderen.
15-12-2014, 16:23 door Anoniem
Dit is een gevolg van jouw actie om mail door te sturen naar een andere provider zonder de bijbehorende actie om bij
de ontvangende provider te regelen dat SPF niet gechecked wordt of alleen gechecked t/m de reeds aanwezige
Received: regels.

Als je mail forward dan moet je altijd de ontvangende server onder controle hebben. Anders vraag je om ellende.
15-12-2014, 16:34 door Anoniem
lijkt me een probleem tussen ziggo en je isp.

spf betekent alleen dat een mail die verzonden word door een Ip-adres/server, en zich identificeert als blabla.nl, ook in de DNS van blabla.nl geregistreerd staat.
Een forward kan roet in het eten gooien als je ISP niet alles van spamfiltering weet.
15-12-2014, 16:40 door mcb
Even hier gekeken: http://www.subnetonline.com/pages/network-tools/online-smtp-response.php
SMTP Response Output:
Error: Cannot connect to wegenernieuwsmedia.nl
HELO error: .
QUIT error: .

Finished!
SMTP Response Output:
Error: Cannot connect to mailservice.wegenernieuwsmedia.nl
HELO error: .
QUIT error: .

Finished!
Het lijkt er op dat zij geen officiele mailserver hebben en daarom de servers van ziggo als relay gebruiken.

NSLookup: http://www.subnetonline.com/pages/network-tools/online-nslookup.php
Non-authoritative answer:
Name: wegenernieuwsmedia.nl
Address: 195.193.168.148
Non-authoritative answer:
Name: mailservice.wegenernieuwsmedia.nl
Address: 194.213.114.66
Vaag, ip adres 194.213.x.x (http://whois.domaintools.com/194.213.114.66) is van een belgische provider terwijl 195.193.x.x van een nederlandse is.

Kan je de hele header posten? In ieder geval dat deel waarin alle servernamen en ip-adressen in staan.
15-12-2014, 17:52 door Anoniem
Stop met het gebruik van SPF. SPF heeft een elementaire denkfout (waar je nu tegenaan loopt). Geforwarde mail wordt (geheel volgens de specs!) gezien als spam. Eigenlijk kun je bij SPF records alleen '~all' als acceptant opgeven. Iedereen die '-all' doet weet niet wat de implicaties zijn.

DKIM werkt beter. Veel beter, daar zit deze dommiteit niet in. DMARC gebaseerd op DKIM werkt prima.

Jammer genoeg doen grote Nederlandse providers (Ziggo, UPC, KPN) nog niet aan DMARC (en dus aan DKIM).
15-12-2014, 18:32 door Briolet
Door wizzkizz: Waarom de moeilijk omweg via Ziggo?

Het betreft een e-mail account van mijn vader die al over de 80 jaar is en niets met internet wil doen. Dus al zijn mail forward ik gewoon naar mijn privé mailbox.
Een alternatief is allerlei instellingen mijn mail adres te geven of zijn mailbox via pop leeg te halen. Maar dit is typisch een situatie waar forwardings voor bedoeld zijn. En omdat veel meer mail forwarden, vroeg ik me af of je daardoor mail kunt kwijtraken door dit soort SFP checks.

Vanmiddag kreeg ik weer een mailtje dat door een andere reden door de FPS check in de spambox terecht kwam. Dit was geen door mij geforwarde mail.

Received-Spf: pass (fallback.dataweb.nl: domain of xxx@rubin-and-son.com designates 157.56.112.137 as permitted sender) receiver=fallback.dataweb.nl; client_ip=157.56.112.137; envelope-from=xxx@rubin-and-son.com;
Received-Spf: fail (dataweb.nl: domain of xxx@rubin-and-son.com does not designate 87.236.0.138 as permitted sender)

Hier had mijn mail provider blijkbaar een storing en kwam hij rechtstreeks op hun fallbackserver terecht. Daar klopte de SFP check. Vervolgens werd hij een uur later doorgeleid naar de echte server en daar faalde de SFP check weer. Het gebruik van fallbackservers en het daarna forwarden naar de oorspronkelijke server is ook normale praktijk.
15-12-2014, 22:46 door Erik van Straten
15-12-2014, 18:32 door Briolet: Maar dit is typisch een situatie waar forwardings voor bedoeld zijn. En omdat veel meer mail forwarden, vroeg ik me af of je daardoor mail kunt kwijtraken door dit soort SFP checks.
Ja, helaas. Maar dat geldt niet alleen voor SPF, ook andere karakteristieken kunnen e-mails laten "verdwijnen" (soms totaal onterecht, false positives dus). Persoonlijk heb ik mij hier altijd sterk tegen verzet, maar dat was vaak een lastige strijd die ik regelmatig niet heb gewonnen. Economische argumenten (vooral type kortetermijn) winnen het vaak van verstandige principes (met langetermijnvisie).

Uit https://tools.ietf.org/html/rfc5321:
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons

Een MTA (Mail Transfer Agent, oftewel een server die, bijvoorbeeld via poort 25, SMTP connecties aanneemt) heeft twee keuzes als mail wordt aangeboden:

1) In de loop van de transactie besluit de mailserver de mail niet te accepteren, bijvoorbeeld omdat het (mogelijk) om spam gaat (maar het kan ook zijn dat de ontvanger niet meer bestaat of de mailbox vol zit). In dit geval geeft de MTA een foutcode aan de "postbode" die de post komt brengen: neem maar weer mee en zoek het maar uit, dit is niet mijn verantwoordelijkheid.

2) De MTA accepteert de mail onvoorwaardelijk. Daarmee neemt de MTA de verantwoordelijkheid over van voornoemde postbode, en mag, volgens de regels van Internet, die mail niet stilletjes laten verdwijnen. En dit is waar de schoen gaat wringen...

Methode 1 wordt als beste optie gezien (zie bijv. http://www.dontbouncespam.org/), maar kent wel enkele nadelen: ten eerste kunnen spammers, met trial and error (brute force), vaststellen wat geldige email adressen zijn, en wat niet. Een ander nadeel is dat die "front end" server kennis moet hebben van alle achterliggende mailboxen: bestaat het ontvangeradres nog, past de mail er nog bij in de mailbox, wellicht heeft de ontvanger een of andere "handige" antispam challenge geconfigurerd etc. Bij grotere mail providers vind je deze aanpak niet zo vaak.

Bij methode 2 kan het zijn dat, na het accepteren van een e-mail, die e-mail alsnog niet afgeleverd kan worden c.q. een of ander systeem (of malwarescanner) ontdekt dat het om een ongewenste e-mail gaat. Omdat e-mail niet "zoek mag raken" moet er een NDR (Non Delivery Report) naar de schijnbare afzender worden gestuurd. Het grote probleem hierbij is dat veel spammers er een gewoonte van maken om afzenderadressen te vervalsen (het gaat hierbij om het Envelope-From adres AKA "Return-Path", niet om het From: veld in de mail zelf).

Indien een willekeurige mailserver, ergens ter wereld, methode 2 gebruikt, en spammers jouw e-mail adres als afzenderadres (envelope-from) gebruiken in miljoenen spams die ze naar die mailserver sturen, dan kan SPF helpen verhinderen dat jouw mailbox volloopt met NDR's.

Feitelijk gaat SPF in tegen de eerdergenoemde regel dat mail niet mag zoekraken. Dat brengt het hele model aan het wankelen. De aanleiding hiervan is simpel: de ontwerpers van het SMTP protocol hebben geen rekening gehouden met afzenders die de boel belazeren. Als er een eenvoudige oplossing voor dit probleem had bestaan, was die er al lang geweest (hoed je voor snake oil verkopers).

De feitelijke oorzaak ligt dieper: ontvangers en verzenders kunnen heel verschillend denken over het nut van een specifieke e-mail. Omdat verzenders niet opdraaien voor de kosten van de opslag van mail zodra de mailserver van de ontvanger deze heeft geaccepteerd, en verzenders via botnets voor belachtelijk weinig geld kunnen spammen, hebben verzenders een winstgevende business.

"Fix": we lossen het spamprobleem op met (snake oil) spamfilters (http://www.paulgraham.com/spam.html en maatregelen zoals SPF (https://web.archive.org/web/20030808185855/http://spf.pobox.com/ eerste bullet: "cuts spam")!

Yeah right. We hebben steeds strengere en nieuwe maatregelen nodig, want spammers zijn ook niet gek: die experimenteren net zo lang tot hun junk er weer enigszins doorheen sijpelt. En het wordt steeds moeilijker om zelf een mail zodanig te schrijven dat je zeker weet dat deze de inbox van de bedoelde ontvanger haalt. Vooral als je echt een erectieprobleem hebt, op zoek bent naar een partner, of zoals ik regelmatig doe: mensen/beheerders waarschuw dat hun account/server is gehacked (klik rechtsboven in http://rfcignorant.org/lookup/gmail.com op "show").

Uiteindelijke gevolg: enorme hoeveelheden e-mail die wordt verzonden waarvan minstens 99% in spamfilters eindigt, met de bijbehorende verspilling van resources, en niet te vergeten, energie. Zoekrakende legitieme mails en voortdurend enorme aantallen nieuwe zombie PC's. Dit betalen we met z'n allen.

SPF is een onderdeeltje van deze kansloze en, schijnbaar eeuwigdurende, symptoombestrijding - die we, als een soort "collateral damage", lijken te blijven accepteren. Ik kan het niet hardmaken, maar vermoed dat niet alleen spammers hier bakken geld aan verdienen. Anders werd dit probleem wel met meer doorzettingsvermogen aangepakt.

Sorry voor de -off-topic- rant, het gevoel kwam weer even boven; ik kon het niet laten ;)

Mogelijke oplossingen voor jouw probleem: onderzoek of rewrite van de envelope-from header mogelijk is, of kijk of je mails voor jouw vader als bijlage i.p.v. forwards naar jouw account kunt doorzetten. Lukt dat niet dan wordt het toch poppen of zo (in bijv. Thunderbird kun je eenvoudige meerdere POP3/IMAP mailservers configureren).
22-12-2014, 20:19 door Anoniem
Briolet$ host -t txt vitens.nl
Briolet$ host -t txt mailservice.wegenernieuwsmedia.nl
FYI: naast een TXT RR is er ook een SPF RR is in het DNS.
Het beste is om beide te hebben, met identieke inhoud.

Jaren geleden was het juist een teken van spam als SPF matchte, omdat spammers met een SPF record pluspunten verzamelde.
Welk jaar is mij dat ontgaan? Dusdanig dat een spamassassin daar strafpunten op gaf?
Daarnaast, als ik regelmatig spam met DKIM krijg, wat maakt dat DKIM voor dit aspect dan zoveel beter? (behalve dat het minder ondersteund wordt op MTA filters)
Dat je geen mail kan versturen vanaf een IP anders dan strict opgegeven is geen "stommiteit", maar precies waar het voor bedoeld was.

Iedereen die '-all' doet weet niet wat de implicaties zijn.
Oh? Werkelijk iedereen, inclusief mijzelf?
Er zijn nog talloze Mutt gebruikers. Daarnaast nog meer webmail gebruikers. Van beiden is het remote IP nooit in beeld (en is er ook geen rewriting nodig - dus kan men zeer bewust en probleemloos bewust voor een super-strict SPF record kiezen).
23-12-2014, 11:45 door Anoniem
Door Erik van Straten: RFC5321 / dontbouncespam.org / NDR
Precies. Dus mijn MTA geeft pas een 250 als op dat punt alle mogelijk tests gedaan zijn.
En; belangrijk: geeft voor elke mogelijke error een duidelijke reden.
Als een outlook die beschrijving vervangt voor onbekende codes, dan heb ik mijn best genoeg gedaan.

Feitelijk gaat SPF in tegen de eerdergenoemde regel dat mail niet mag zoekraken.
Ik spreek jou vrijwel nooit tegen, maar nu toch echt wel: ik doe mijn SPF validatie nog tijdens de dialoog.
Wellicht spreek ik over eSMTP, en jij over aSMTP.

Uiteindelijke gevolg: enorme hoeveelheden e-mail die wordt verzonden waarvan minstens 99% in spamfilters eindigt, met de bijbehorende verspilling van resources, en niet te vergeten, energie. Zoekrakende legitieme mails en voortdurend enorme aantallen nieuwe zombie PC's. Dit betalen we met z'n allen.
Waarmee je aangeeft dat SPF dus z'n werk doet.
En als iedereen de sociale dicipline zou hebben om een strict SPF zou hebben zou die 99% meer richting 0,nogwat% kunnen.

SPF is een onderdeeltje van deze kansloze en, schijnbaar eeuwigdurende, symptoombestrijding
Omdat dat makkelijk en directer in eigen hand te nemen valt.

vermoed dat niet alleen spammers hier bakken geld aan verdienen. Anders werd dit probleem wel met meer doorzettingsvermogen aangepakt.
Wereldwijd alle beheerders van geheel danwel half open relays bij te scholen is lastiger (en vooral kostbaarder) dan symptoombestrijding.

Sorry voor de -off-topic- rant, het gevoel kwam weer even boven; ik kon het niet laten ;)
Allerminst off-topic. En onderbouwd altijd welkom.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.