Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

'Mailservers Tweede Kamer missen beveiliging tegen e-mailspoofing' - update

De mailservers van de Tweede Kamer missen beveiligingsmaatregelen die e-mailspoofing tegen moeten gaan, waardoor het mogelijk is om uit naam van politici e-mails te versturen. Dat blijkt uit een onderzoek van Follow the Money.

De site werkte samen met een beveiligingsonderzoeker om de mailservers te controleren. Die stelt dat het gebrek van spf het grootste probleem is waardoor derden e-mails uit de naam van politici kunnen versturen. Daarmee wordt een controle uitgevoerd op de domeinen die mails vanaf een mailserver mogen versturen. Doordat onder meer deze maatregel ontbrak, kon Follow the Money mails versturen vanaf het tweedekamer.nl-domein. Dit deed de site onder meer in de naam van Mark Rutte en Geert Wilders. Kamervoorzitter Khadija Arib laat aan de NOS weten dat er op korte termijn maatregelen worden genomen.

Hierdoor ontstaat een beveiligingsrisico, doordat op deze manier bijvoorbeeld overtuigende phishingmails verzonden kunnen worden. Vorig jaar bleek uit een onderzoek van Binnenlands Bestuur dat ook een groot aantal gemeenten niet voldoende maatregelen nemen om hun e-mail te beveiligen. Daarbij werd gekeken naar spf, maar ook maatregelen als dmarc en dkim.

Dkim is een authenticatiemethode waarmee een ontvanger van een e-mail kan nagaan of een bericht van het domein van de verzender inderdaad daarvandaan verzonden mocht worden. Dmarc bouwt voort op deze technieken en kan bijvoorbeeld ingezet worden om te verifiëren of de inhoud van een e-mail is veranderd na het verzenden daarvan. Spf en dkim staan op de zogenaamde 'pas-toe-of-leg-uit'-lijst. Alles wat op deze lijst staat, is verplicht voor overheidsorganisaties bij aanschaf, aankoop, aanbesteding of ontwikkeling van een nieuwe dienst van 50.000 euro of meer.

Update, 11:56: De Tweede Kamer meldt in een bericht dat het versturen van mail uit naam van een Kamerlid niet meer mogelijk is nadat er 'met spoed maatregelen zijn genomen'.

Door Sander van Voorst

Nieuwsredacteur

24-10-2017 • 07:28

123 Linkedin Google+

Submitter: AnonymousWP

Reacties (123)

Wijzig sortering
Wat een overdreven verhaal zeg, een hoop zinloze dramatiek. Beetje paniekvoetbal voor de media.

SPF, DKIM en DMARC zijn geen betrouwbare technieken; ze zijn op z'n best een advies. Niemand die er echt toe doet vaart blind op die informatie want dan gooi je veel te veel mail weg.

Daarbij zijn er ook een hoop situaties waarin SPF/DKIM/DMARC gewoon echt niet werken met bestaande infrastructuur en applicaties. Dat krijg je niet in een nachtje opgelost, dat is jaren werk voor de hele wereld.

Door overhaast een SPF-record op te nemen heeft de Tweede Kamer waarschijnlijk een flink aantal mensen het leven zuur gemaakt terwijl ze er maar een klein beetje extra bescherming voor terugkrijgen.

Begrijp me niet verkeerd, ik ben geen tegenstander van SPF/DKIM/DMARC. Alle beetjes helpen en iets is beter dan niets. Maar verwacht geen wonderen.
Dit systeem gaat trouwens nooit echt goed werken, de aanpak is verkeerd.
Niemand is geinteresseerd in welk stuk ijzer een bepaalde mail heeft verstuurd. Interessant is of het van de persoon Mark Rutte kwam en of die persoon onze minister president is. SPF/DKIM/DMARC zeggen daar helemaal niks over; hooguit zeer indirect ("de beheerder van deze mailserver heeft van zijn baas te horen gekregen dat volgens iemand van HR er is gecontroleerd dat deze account gebruikt wordt door Mark Rutte").

We moeten onze mails van een persoonlijke digitale handtekening gaan voorzien. Dát is wat we echt willen weten. Helaas worden de bestaande technieken (PGP en S/MIME) niet breed genoeg ondersteunt om er op te kunnen vertrouwen, maar tot we dat hebben blijft het huilen met de pet op.

Daar komt nog bij dat ze hun DNS niet hebben beveiligd met DNSSEC, zo kun je niet op die records vertrouwen.

Wat we niet aan de buitenkant kunnen zien is of dat de mailservers van de Tweede Kamer nu ook inkomende mail gaan controleren op deze aspecten.
Wat ook niet vermeld wordt is hoe het nu met gerelateerde domeinen gaat. eerstekamer.nl en parlement.nl laten bijvoorbeeld nog gewoon alles toe. Als rutte@tweedekamer.nl niet werkt dan pak ik wel rutte@eerstekamer.nl of rutte@parlement.nl. Ik durf te wedden dat zelfs in Den Haag niemand dat opvalt of er over nadenkt. Als het al iemand opvalt dan wordt het toch niet gemeld.

Ik stel voor dat we dit experiment over drie maanden herhalen. Ik voorspel dat het verschil met nu maar heel klein gaat zijn en er hooguit een paar kleine aanpassingen nodig zijn om de aanval weer net zo succesvol te maken.

[Reactie gewijzigd door CAPSLOCK2000 op 24 oktober 2017 18:48]

Het lastige blijft dat email nog steeds een van de grotere communicatie kanalen is op het internet.

Vanuit diverse oogpunten is het kanaal al meerdere malen dood verklaard, maar toch is het er nog steeds.

Het internet ontwikkeld zich, je zult met de tijd mee blijven gaan. Waaronder dus ook het toepassen van authenticatie op meerdere vlakken. Natuurlijk is het geen silver bullet, maar zolang nog niet iedereen aan de slag gaat met SPF, DKIM en DMARC blijft er een markt bestaan voor het misbruik van email.

Je stelt dat het implementeren van deze technieken bijzonder lastig is in bestaande infrastructuren, ik durf te stellen dat het goed mogelijk is mits nauwkeurig uitgevoerd. DMARC is een uitstekend middel in de rapportage modus om SPF en DKIM te implementeren.

Het probleem bij PGP en S/MIME is dat ik het m'n vader echt niet uitgelegd krijg.

Ik begrijp de toegevoegde waarde van de encryptie technieken, maar pak dan eerst de quick wins en ga je daarna focussen op de rest van de beveiliging in de keten.
Exact, het is bizar hoeveel grote organisaties zelfs hun eigen emails niet controleren op afzender omdat het onhandig zou zijn. Voor de medewerker wordt dan zelfs in outlook doodleuk de profielfoto e.d. bij de gespoofte email geplaatst, waardoor het 100% onmogelijk voor de doorsnee gebruiker is om het verschil te zien. Maar dan wel phishingtraining geven "open alleen bestanden/links van mensen die je vertrouwt!". Ja hoe dan? Als je een mail van je manager krijgt ga je ervanuit dat hij/zij het is. Je kunt er op wachten dat dit goed fout gaat zodra er een gerichtte actie wordt opgezet. Gek he, dat "social engineering"/spear phishing zo effectief is zelfs bij grote namen. Dat alles beter kan met PGP is geen reden om het minimale niet te doen.

[Reactie gewijzigd door Reflian op 25 oktober 2017 06:13]

Ik ben het volledig eens met je verhaal. SPF, DKIM en DMARC allemaal leuk, maar leveren meer ellende dan plezier. Er is met geen enkele techniek te verifiëren dat een e-mail van rutte@tweedekamer.nl daadwerkelijk van mark rutte af komt. E-mail is gewoon niet betrouwbaar genoeg als het gaat om belangrijke communicatie.
SPF, DKIM en DMARC zijn technieken om SPAM te ontmoedigen en tegen te gaan. Heeft 0 , 0 te maken met authenticiteit van een verzender... 0

Hiervoor moet je met Certificaten aan de slag gaan.
Dat is niet correct, het is niet alleen tegen spam, maar ook om te voorkomen dat niet geauthenticeerde email servers emails versturen vanuit jouw domein zonder dat deze als spam gemarkeerd zullen worden.

Als alleen de mailservers van de overheid voor hun eigen domein emails mogen versturen heb je in wezen al een manier om tde authenticiteit van de verzender vast te stellen als je gebruik maakt van welke vorm van authenticatie dan ook, hoewel certificaten alsnog geen overbodige luxe zijn uiteraard.
E-mail is gewoon niet betrouwbaar genoeg als het gaat om belangrijke communicatie.
Ah, nu snap ik eindelijk waarom de POTUS Twitter gebruikt ;)
Daar hebben we toch GPG/PGP encryption & signatures voor?
Dat klopt allemaal, maar waar het op neer komt is dat e-mail in de basis gewoon niet meer betrouwbaar is.
Daar kan je dan wel SPF, DKIM en DMARC , Certificaten, PGP encryption op los laten, maar de gemiddelde huis tuin en keuken gebruiker heeft niet de garantie dat hun e-mail provider hier allemaal op controleert. Of ze zien een e-mail certificaat in hun mailsoftware en denken, wat een grappig icoontje. Laten we het maar niet over PGP hebben. Dan kan ik nog steeds als kwaadwillende mailen namens de tweede kamer.
Ja, dat laatste is waar.
Uiteraard biedt SPF maar een zeer beperkt voordeel, maar het is zeer zeker effectief in het bijvoorbeeld voorzien van de grote hoeveelheid gratis email gebruikers van partijen als Google en Microsoft. Het geeft de ontvanger in ieder geval de indicatie dat er iets niet in de haak is met de emails die niet van de juiste machines komen. Dat is iets voor mij als burger dat toch al wel veel waard is. Dat anderen zich nog steeds kunnen voordoen als de (lokale)overheid maar niet zonder op zijn minst een hoger spamscore te krijgen kan mijn inziens al een hele hoop ellende schelen, en met dat aspect denk ik ook dat de (lokale)overheid de plicht heeft dergelijke (technisch vrij simpele) maatregelen toe te passen.

Afhankelijk van de verscheidenheid van bronnen en complexiteit van de omgeving kan het een forse klus zijn enzovoorts. Als jij in een dergelijke rol (overheid) zoveel partijen inhuurt om email namens jou te sturen (of systemen voor je hosten/beheren die dat kunnen) dan moet je mogelijk wel even stilstaan bij het feit dat je ongeacht al dat andere niet in staat bent om zelf te constateren of de email van jouw organisatie komt. Technisch zijn er ook nog wel manieren te vinden om het geheel te centraliseren (met hier en daar mogelijk een forse uitdaging natuurlijk, hoort bij het vak).

Hoe dan ook wat mij persoonlijk betreft klinkt het als incompetentie dat zoiets 'simpels' (SPF) niet is geregeld door/voor een overheidsorgaan, zeker als ze er al langer van weten.

P.S. Het is al heel vaak gezegd maar de email standaarden zijn er ook simpelweg niet op gebouwd om aan de huidige beveiligingseisen te voldoen, tenzij je bereid bent het belangrijkste aspect (reikwijdte) al dan niet gedeeltelijk of geheel, te laten varen.
Het probleem is dat SPF in deze überhaupt als beveiligingsmaatregel wordt weggezet.
Daar klopt gewoon niets van. Gigantisch hoog clickbait gehalte dit artikel.

ICT'er die verzuimt heeft een SPF record aan te maken moet zich voor zijn hoofd tikken, maar daar is het m.i. ook wel klaar mee.
Vooral de suggestie die nu gewekt wordt door de tweka en geecho'd door tweakers dat mailadressen van tweka leden nu dus niet meer gespooft kunnen worden is gewoon tamelijk objectieve onzin en geeft mensen een verkeerd beeld van hoe mail werkt.

[Reactie gewijzigd door Koffiebarbaar op 25 oktober 2017 12:00]

Wil je meer info over SPF en DKIM dan kan ik je aanbevelen om de volgende blog eens te lezen deze gaat net een stuk verder dan alle andere blogs en geeft beter beeld en bestpractises.

Overigens is dit bij veel grote bedrijven nog steeds een drama inrichting zelfs in de financieele wereld.

http://www.tech-savvy.nl/2017/02/17/antispam-counter-measures-explained-part-1-how-the-sender-policy-framework-really-works

http://www.tech-savvy.nl/2017/03/09/antispam-counter-measures-explained-part-2-advanced-spf-records-best-practice-and-biggest-mistakes

http://www.tech-savvy.nl/2017/04/11/antispam-counter-measures-explained-part-3-dkim/

[Reactie gewijzigd door Scriptkid op 24 oktober 2017 08:48]

Goede blogs

Trouwens, het is zelfs drama bij XS4ALL.NL
Krijg malware binnen op een @xs4all.nl webmail.
Deze malware komt vanuit een mailadres ook met @xs4all.nl
Alleen de mail zelf komt uit onder andere India, Colombia, Indonesië, Ecaudor.
Xs4all doet het wel een beetje apart:
$ dig xs4all.nl txt
...
;; ANSWER SECTION:
xs4all.nl. 10522 IN TXT "v=spf1 include:spf-considered-harmful.xs4all.nl ~all"
We includen een SPF lijst die we als "harmful" consideren (dus waarvan we bang zijn dat ze schade gaan doen).

De contents daarvan:
;; ANSWER SECTION:
spf-considered-harmful.xs4all.nl. 85084 IN TXT "v=spf1 ip4:194.109.24.0/24 ip6:2001:888:0:108::/64 ip6:2001:888:0:125::/64 ?all"
We noemen de ip-blokken van xs4all dus harmful (schadelijk) en daarom includen (vertrouwen) we ze 8)7

Wat eigenlijk veel erger is, is dat in de SPF van xs4all uiteindelijk een softfail "~all" wordt genoemd, wat er meestal voor zorgt dat mail afkomstig van een niet vertrouwde bron op zijn minst wordt 'gemarked' in de vorm van een "spam score".

Echter, SPF-records worden stap voor stap afgelopen en de include die voor de ~all staat bevat reeds een "?all", die hit dus al alles buiten de eerder genoemde ip-blokken als "neutral". Die softfail ~all komt dus nooit aan bod.

Kortom, wat jij beschrijft is dus heel goed mogelijk. Misschien tijd voor xs4all om de stagiair weg te sturen :Y)
De reden dat XS4ALL geen SPF wil forceren is omdat SPF nogal wat problemen veroorzaakt. Namelijk met het forwarden van e-mail. Dus stel, Henk heeft henk@xs4all.nl en die forward dat naar henk.ingrid@ziggo.nl.

Nu krijgt henk@xs4all.nl e-mail van tweedekamer.nl. XS4ALL forward dat naar Ziggo. Spamfilter van Ziggo doet een SPF check en die ziet dat de mail van tweedekamer.nl is afgeleverd door een mailserver van XS4ALL (immers, xs4all forward de mail). IP-adres van XS4ALL staat niet in de SPF whitelist van tweedekamer.nl, dus weigert Ziggo de mail.

Om dit te voorkomen voor klanten van XS4ALL passen ze de softfail toe. In praktijk komt dit er op neer dat er alleen positieve puntenwaardering worden toegewezen wanneer een mail wel SPF valideert, en geen strafpunten krijgt wanneer SPF check faalt.

Dit is ook de reden waarom, op de vraag van @lenwar zo weinig ISPs SPF forceren: Het breekt zo ongelooflijk veel, dat je helpdesk overuren gaat draaien om dat allemaal uit te leggen. Daar komt bij dat het bovendien best technisch complex is om dit aan een leek uit te leggen. En dan speelt inderdaad het probleem van verkeerd geconfigureerde SPF records ook nog mee.

Wat ook relevant is is dat wanneer Afzender X een verkeerd SPF record heeft, waardoor Ontvanger Y de mail weigert het uiteindelijk de ISP van de ontvanger is die de klachten krijgt. Terwijl die geen blaam treft, maar dus wel de helpdesk calls te verwerken krijgt.

Er zijn hier inmiddels wel wat oplossingen voor, zoals SRS (Sender Rewriting Scheme), maar dat wordt nog maar mondjesmaat toegepast.

SPF is gewoon een halfbakken, gare, niet voldoende uitgewerkte oplossing.

Eigenlijk alle anti-spam anti-phishing oplossingen op e-mail zijn gare implementaties. Eigenlijk moet gewoon het hele e-mail systeem op de schop. Er moet een nieuw systeem komen in plaats van allerlei "extensies" en "toevoegingen" op SMTP, wat goed werkte in 1960, maar nu niet meer voldoet.
Om dit te voorkomen voor klanten van XS4ALL passen ze de softfail toe.
Nee, dat doen ze dus niet. De "?all" (neutral) uit de include komt namelijk voor de ~all. Dus alles fietst gewoon vrolijk door met een Neutral result.

SRS is inderdaad een oplossing. Xs4all profileert zich nog steeds als de beste ISP (vooral premium). Ik zou dus een betere policy verwachten.

Over de naam van de include list, als dat zo is als jij beschrijft, beetje amateuristisch. Doe dan niets of zoek een betere oplossing.
dan moeten ze dus -include:domain gebruiken

dam wordt alles in de include gedropt
We includen een SPF lijst die we als "harmful" consideren (dus waarvan we bang zijn dat ze schade gaan doen).
Je legt het verkeerd uit.
Ze beschouwen SPF als schadelijk, niet de genoemde IP-blokken.
Steeds vaker is het noodzakelijk om een SPF-record te hebben. Allerlei organisaties eisen dat min of meer; typisch zonder zelf echt te snappen wat ze vragen of waarom.
Daarom moet je wel een SPF-record hebben, dus hebben ze maar een record opgenomen waarin staat dat hun ip-adressen als 'neutraal' moeten worden behandeld.

Die die softfail nooit aan bod komt is precies wat ze willen. Die is omdat er ook bedrijven die gaan proberen je SPF record te controleren en dan zeuren omdat het record te open is. Ik denk dat dit dus een weloverwogen constructie is om dat soort controles te omzeilen.

Ik durf dat wel te zeggen omdat ik voor mijn eigen werkgever in exact dezelfde situatie zit. We moeten praktisch gezien wel een SPF-record hebben, maar tegelijkertijd is onze organisatie er nog lang niet klaar voor. We hebben heel veel externe partners die namens ons mailen. Die situatie is nu eenmaal zo en kan niet snel worden veranderd vanwege een hoop complexe belangen. Er wordt wel aan gewerkt maar het gaat waarschijnlijk nog jaren duren. Tot die tijd moeten wij het ook doen met een SPF-record dat er alleen maar voor de show is.

[Reactie gewijzigd door CAPSLOCK2000 op 24 oktober 2017 19:02]

I stand corrected, goede uitleg!

Als je er wat dieper over nadenkt kan je weinig andere kanten op dan deze. Dat verklaart dan ook meteen die gare dns-naam bij de include.
Geef die 'externe partijen' een account op je server?
Dat doe ik, waar mogelijk, maar niet alle leveranciers kunnen/willen daar mee overweg. Helaas ken ik niet eens alle externe partijen. De organisatie waar ik voor werk bestaat uit heel veel min of meer zelfstandige delen. 20 jaar lang heeft iedereen vrij z'n mailings besteld bij de goedkoopste aanbieder van het moment. Zodra er iets verandert voelt iedereen zich aangetast in z'n zelfstandigheid (dat is zowel een voor- als een nadeel voor deze organisatie). Verandering is wel mogelijk maar snel gaat het niet.
Jullie zijn daar niet de enige in. De situaties waarin het schier onmogelijk wordt om het e.a. allemaal op orde te houden en voor gebruikers begrijpbaar is domweg niet te doen. Vooral omdat email clients niet lekker mee willen werken. Stel, je stuurt een mail vanaf een volledig uitgeruste mailserver die ook spf/dkim en dmarc netjes heeft ingesteld (voorbeeld outlook.com) met als het from field: MAIL FROM: "mrutte@tweedekamer.nl" <volledige.infectie@outlook.com> dan zal de ontvanger in z'n van veld toch echt denken dat eene mrutte@tweedekamer.nl hem/haar een mail gestuurd heeft.

Geen spf/dkim of dmarc die daar wat tegen doet.
Nee... xs4all ziet 'SPF' an sich als harmfull.... het is gewoon commentaar op 't systeem. De blokken zijn van xs4all zelf, en dus worden ze vertrouwd, maar xs4all doet blijkbaar liever niet mee aan SPF


Edit: typo

[Reactie gewijzigd door markjanssen op 24 oktober 2017 14:41]

Heel logies dat xs4all het zo doet. Xs4all heeft genoeg klanten die geen internet afnemen maar wel mail (klanten die in het buitenland wonen). Die moeten soms verplicht mailen met de SMTP-server van hun provider. Zelf heb ik dat gehad toen ik studeerde.
Dus zij willen zeker geen hard-film. Maar eigenlijk ook geen soft.

Mijn bijbaantje in die tijd mailde altijd mijn rooster. En ineens hielt dat op. Zij kregen een SFP-hard faill. Na wat zoeken had bleek de server van de roostermaker (externe leverancier) niet in de SFP te zitten.
Ga je hoofdkantoor in de VS maar eens uitleggen dat we een aanpassing in de sfp nodig hebben.
Yep ik draai zelf ook eigen mailservers en heb SPF, DKIM en DMARC en een reverse DNS record. Dat laatste ontbreekt zelfs bij de meeste bedrijven waar ik kom. De kennis is er gewoon niet, er wordt een mailtje gestuurd die komt aan, hey het werkt en voor de rest wordt nergens meer naar gekeken.
Ik heb zelf al redelijk lang SPF, DKIM en DMARC geconfigureerd voor mijn privédomeinen. Een aantal jaar geleden (waarschijnlijk door m'n eigen domme schuld) is m'n adresboek in een één of ander spammers-systeem gekomen, en worden er dus vanuit allerlei botnets e-mails vanuit mijn e-mail adres en naam naar mijn contactpersonen gestuurd.

Het viel me toen op hoe weinig domeinen de SPF en DKIM adviezen/verzoeken aanhouden. Zelfs bij m'n werkgever (erg vervelend als je collega's voor de 100ste keer lachend zeggen dat ze weer is een e-mail van 'mij' ontvangen hebben :-) ) lieten ze ze gewoon door. In de headers die de mail server toevoegde van de ontvangen mail zag je ook doodleuk dat het SPF-record niet klopte, maar ze lieten hem gewoon door.

Uit frustratie (De 'grappige reacties' van m'n collega's werden een beetje vermoeiend) en nieuwsgierigheid was ik is gaan doorvragen bij de afdeling die het mail platform beheerd. Toen bleek dat het hun bevinding was dat er dusdanig veel SPF-records verkeerd staan, en daardoor veel legitieme mails mislopen, (en dat is natuurlijk erg vervelend als je zo e-mails van klanten/overheden mist), dat er was besloten er niet hard op te filteren.

Het valt me overigens wel op dat het steeds beter gaat met de checks, en *even afkloppen* het lijkt er op dat de spammers m'n adres niet meer goed genoeg vinden (ik ontvang ook al een tijdje geen DMARC-reports meer van tig mail servers :-) )

Edit:
De moraal van mijn verhaal is dus ook eigenlijk, dat die SPF en DKIM dingen natuurlijk erg leuk zijn, maar als de ontvangende kant ze niet honoreert, dan heb je er nog steeds niet zo veel aan. Het zou bijvoorbeeld een leuke actie zijn als 'Europa' zich met dit soort dingen gaat bemoeien, en het verplicht stelt dat alle overheden en bedrijven hard filteren op SPF en/of DKIM records. Dan is het probleem van foutief ingestelde domeinen volgens mij in no-time opgelost. (of dat bijvoorbeeld een Google, Yahoo!, Microsoft en Apple het samen in eens doen, dat heeft ook wel impact)

[Reactie gewijzigd door lenwar op 24 oktober 2017 12:09]

Ze hebben vannacht nog even snel een SPF -all geplaatst op het domein :+

*EDIT: Dan moet de configuratie wel zo zijn ingesteld dat tweedekamer.nl als envelope sender (return path) domein gebruikt wordt. Want alleen dat domein wordt op SPF gecontroleerd. Ik kan dan alsnog een email spoofen met een willekeurig (niet direct zichtbaar) domein wat SPF valide is en tweedekamer.nl gebruiken als header From. Willen ze dit friendly from domein beschermen, dan DMARC gebruiken.

[Reactie gewijzigd door Aurora op 24 oktober 2017 08:03]

-all zorgt dat de ontvanger nog steeds alle mail accepteert .....
edit:
sorry, net wakker ..
is trouwens beter dan het zo'n 20 jaar geleden was. toen was tweedekamer.nl nog een open relay.

[Reactie gewijzigd door PetervdM op 24 oktober 2017 08:30]

Dat is ?all ;) Een -all zal enkel en alleen de IP's mogen toestaan die in het SPF opgegeven zijn.
Een -all betekent letterlijk: min alles. Dus komt het erop neer dat er helemaal geen mail wordt verstuurd.

https://www.digitalocean....mprove-e-mail-reliability

Ze hebben vanmorgen alleen hun eigen mx-records toegevoegd:

"v=spf1 mx -all"

Dus enkel hun mx-records (dus hun eigen mailservers) zijn nu servers die mail versturen met domein tweedekamer.nl. Jammer dat zoiets vrij lang moest duren. SPF mag dan wel halfbakken zijn, het is een van de weinige dingen die je kan doen. Alles open zetten is ook weer zoiets onhandigs. En als de ontvangende kant netjes kan checken of de verstuurde mail correct is, is het imho gewoon heel simpel: laat je mailscanner de geblokkeerde items gewoon in quarantaine zetten en ontvang dagelijks een overzichtje met geblokkeerde items. Dan komt hij aan waar het hoort: spam, want er klopt iets niet. Dan is het bij de meesten bekend dat je bij de afzender moet zijn: je bericht wordt gezien als spam, jij moet het fixen. Of je whitelist het gewoon en negeert alles, de struisvogeloptie. Maar dat soort volk dunt vanzelf uit :+
Dude..
Een -all betekent letterlijk: min alles. Dus komt het erop neer dat er helemaal geen mail wordt verstuurd.
En dan ..
Dus enkel hun mx-records (dus hun eigen mailservers) zijn nu servers die mail versturen
Wat klopt hier niet :+
Oke, het was eind van de dag :p Lees maar die pagina, dat is makkelijker.
Staat hetzelfde wat ik eerder vermeldde ;) Maar thanks!
Oh ik dacht dat je mijn post misschien verwarrend vond? Care to elaborate?
Sure thing! Een -all policy zegt in principe laat niets door behalve hetgene wat in het record staat aangegeven. In dit geval dus het MX record, zoals jij daarna ook aangaf.

De rest van je verhaal ben ik volledig met je eens!
Met alleen -all wordt er volgens mij aangegeven door dat record dat er geen mail verstuurd wordt namens dat domein. Mx -all betekent alles blokkeren behalve de eigen mx-records. Wat jij bedoelt is denk ik gewoon de a record maar dat is vaak de webserver en niet de mailserver. Mocht dit fout zijn verneem ik graag een bron want dan moet ik op mijn domein wat veranderen en ben ik benieuwd hoe het daadwerkelijk zit.
Oei, denk dat jij een iets ander beeld hebt wat SPF werkelijk doet. Tell you what, ben nu steeds op mijn mobiel aan het tikken. Ik breng mijn kinderen straks naar bed, even wat avondeten en dan schuif ik achter mijn computer. Ik stuur je dan wel een DM.
Wel hulde dat ze voor de verandering eens snel hebben gereageerd.
wrong again,

Ook met -all kan gewoon alle mail aankomen,

Letop :

SPF, DKIM en DMARC zijn alleen een advies , De ontvanger bepaald nog steeds wat hij er mee doet.

en ? en ~ zijn conflicterend voor DMARC. Zowiezo zijn SPF en DMARC 2 standaarden waarvan de best practice elkaar tegen spreken in de RFC.

DMARC is een leuke techniek het slaat alleen net de plak mis en het had zoveel beter kunnnen zijn als de DMARC groep zich nu eens echt had gefocust op het problem ipv de zoveelste standard die net de plank mis slaat.
Ik zei niet dat mail niet aankomt :) Ik zei dat een -all IP's mogen toestaan. Daarom heet deze parameter een SPF policy. Het hangt nog altijd af van de remote host wat deze met de email doet. En of de remote host überhaupt SPF/DKIM/DMARC controleert. Tegenwoordig wordt SPF echter vrijwel door iedere fatsoenlijke mailserver gecheckt.

In mijn werkveld zie ik dat de meeste (zo wat alle) remotes host de SPF policy honoreren.

Een ~all is niet conflicterend voor DMARC. Sterker nog, wij (deliverability club) raden altijd aan om een ~all te gebruiken, vooral in combinatie met DMARC. DMARC is slechts een aanvulling en een verbetering waar SPF en DKIM apart van elkaar falen.

Je moet niet vergeten, mail moet wel blijven aankomen bij de recipient. Als je je blind focust op blokkade, blokkade, blokkade, dan zal de legitieme recipient af en toe ook niets ontvangen.
@PetervdM Eigenlijk betekent dat -all: sta alle adressen uit het domein toe, en blokkeer alles wat niet uit het domein komt.
Ik neem aan dat je bedoelt: "verwerp alles wat niet expliciet in dit spf-record gedefinieerd is". Domein heeft in deze context niet veel betekenis.
20 jaar geleden was het domein nog helemaal dicht. registratiedatum was 1998-09-17 :D zeker weten dat je wakker bent?
ja, nu wel, dank je.
laat het dan 19 jaar geleden zijn, of misschien 18, een collega heeft toen eens zo'n stunt uitgehaald, mail versturen namens tweedekamer en een paar andere instanties. is toen niks mee gedaan.
In overheidsland is het instellen van een SPF filter in een nacht tijd een snelheidsrecord. Exact ditzelfde probleem is 9 maanden geleden aangekaart bij de Dienst ICT Uitvoering(DICTU, dé overheidsclub waarvan je verwacht zijn ict-gerelateerde zaakjes op orde te hebben), het heeft ongeveer 6 maanden geduurd voordat er een SPF filter verscheen.

Het lullige aan het ontbreken van dit soort filters is niet dat je e-mails kan sturen vanaf markrutte@tweedekamer.nl, maar dat je hun email infrastructuur onklaar kan maken. Iedereen kent wel de berichten die je terug krijgt wanneer je een email hebt verstuurd naar een emailadres dat niet bestaat. Er zijn onwijs veel servers met een flinke capaciteit waarbij je dit voor elke verzonden email terug krijgt. Een van de klanten van het bedrijf waar ik werk had ooit ook geen SPF filters ingesteld waardoor je ook e-mails kon versturen vanaf dit adres (zeg: markrutte@tweedekamer.nl). Met dit e-mailadres kon je emails versturen naar een niet bestaand adres waarvan je wist dat de emails aankwamen bij een server die je een reply ging sturen. Deze reply werd echter niet naar jou verstuurd, maar naar de afzender (markrutte@tweedekamer.nl). Deze klant kreeg in korte tijd zelfs zoveel mails over zich heen dat hun ironport er door is gesmolten.
Ditto voor de brakke configuratie van hun mailinglist servers bij asp4all.
Ik heb het ooit ook aangekaart bij ABN Amro, die zouden het doorgeven... Uiteindelijk toen niets gebeurd. Juist dat soort bedrijven en instanties dienen gewoon zeer stenge SPF, DKIM en DMARC records te hebben. Geen idee of ze het ondertussen wel gedaan hebben.
Het zijn dé bedrijven in wiens naam phishing mails verstuurd worden, en hoewel het een kleine verbetering is ís het een verbetering als ze gezonde restricties toepassen.
Het gros van de grote banken zijn sinds 2010 bezig met de implementatie van DMARC, waarbij ING de eerste was die het af had.

In 2018 gaan we naar schatting in Nederland naar 90-95% DMARC dekking op de consumenten mailboxen, dan hebben vermoedelijk KPN en Ziggo (Liberty Global) inkomende DMARC validatie aan staan. We zitten op dit moment op pak hem beet 80% omdat het gros van de consumenten een mailbox heeft bij Google of Microsoft.

De zakelijke markt blijft achter, dit terwijl er in de filter infrastructuur wel ondersteuning is voor DMARC (denk aan Cisco Ironports). Alle cloud oplossingen, bijvoorbeeld Microsoft Office 365 en Google G-Suite (Google Apps) bieden dit al.
vziw deed gmail al tijden aan dmarc validatie.

Ik heb een tijdje zelf een stricte dmarc op mijn domein gehad, was geen succes daar ik ook op mailinglists post. Ik meen mij te herinneren dat google ook bounces gaf. En ik weet vrij zeker dat ik dmarc raporten krijg van ze.
Die bounces zijn hopelijk verleden tijd zodra ARC gemeengoed wordt, tot die tijd maar een losse dmarc op mijn domein ;)
Abnamro is verschrikkelijk. Die sturen je adresboek (en wat nog meer?) naar omtrdc.net terwijl je met je edentifier bent ingelogd.
De tweede kamer heeft een eigen ICT club.

De overheid zijn allemaal eigen politieke partijen, met eigen belangen. Zie het als eigen bedrijfjes met eigen financiële middelen. Veel zal bring your own device zijn.
De eigen partijen hebben eigen middelen, pas wanneer iemand van een partij in de tweede kamer komt, moet zijn partij ICT aan de ICT van de tweede kamer geknoopt worden.

Denk ook maar niet dat de leden van de tweede kamer heel erg welwillend zijn en open staan voor een andere manier van werken als dat veiliger is. Ze voelen zich belangrijk en ICT is slechts een middel dat ze op hun eigen manier gebruiken.
Ze hebben inderdaad alleen een SPF geplaatst op tweedekamer.nl maar niet op parlement.nl. Deze lijkt wel de host te zijn aangezien hun MX record hier ook naar verwijst.

[Reactie gewijzigd door HKLM_ op 24 oktober 2017 09:15]

SPF stel je dan ook in op het emaildomein, niet op het domein van de verzendende mailserver.
Maar wordt het domein @parlement.nl dan niet gebruikt?
Voor het parlement.nl domein is geen spf record aanwezig:

parlement.nl text =

"Staten-Generaal, Dutch Parliament"

Kan best dat men zowel een @tweedekamer.nl als @parlement.nl stmp adres heeft. En dan is het probleem dus nog steeds niet helemaal opgelost als ik gewoon markrutte@parlement.nl kan spoofen. :)
Als je wilt opzoeken of je gemeente voldoende heeft gedaan aan DMARC, DKIM, SPF en DNSSEC dan kun je dit op de volgende website opzoeken:
https://www.phishingscore...vernment--Govt-Owned/MS0y

Er zijn meer van dit soort websites om je mail domein te bekijken maar deze vind ik zelf erg makkelijk en overzichtelijk. Je kunt per land en per sector zoeken.
Mocht je nog een (je eigen) maildomein missen dan kun je deze hier ook eenvoudig toevoegen.
Opvallend dat voor DMARC geen groen schildje verschijnt als de betreffende gemeente geen DMARCIAN adres in zijn DMARC record heeft opgenomen.

In hoeverre is deze lijst / test écht representatief?
Met betrekking tot de Phishing Scorecard, het proces aan de achterkant doet een crawl van alle domeinnamen die op enige lijst staan.

Aangezien dit proces om de x-tijd loopt kan het zo zijn dan sommige records nog bijgewerkt moeten worden en daarom geen status heeft.

Het is absoluut niet gekoppeld hebben aan het hebben van een dmarcian account!

Verder bestaat er een verschil tussen DMARC p=none en DMARC p=reject, reject resulteert in een schildje en p=none een Work in Progress. Bestaat er echt geen DMARC record dan heb je een rood kruis.

Gemeenten die zaken doen met dmarcian worden wel naar p=reject geholpen, samen met het inrichten van SPF en DKIM op alle mailstromen. Dit om te kunnen voldoen aan de Pas-toe-of-leg-uit lijst van het Forum Standaardisatie.
Of als je een suggestie hebt voor een thema lijst, laat me dat dan even weten ;)

De laatste lijsten richten zich op dit moment op onderwijs (Hogescholen, Universiteiten, Voortgezet Onderwijs).

We proberen voornamelijk de email standaarden die op de Pas-toe-of-leg-uit lijst van het Forum Standaardisatie staan te visualiseren.
https://www.forumstandaar...verplicht-pas-toe-leg-uit
Hmm, echt wel heel slechte zaak dit.

Ik werk in een ziekenhuis als exchange beheerder en daar hebben we al een tijdje DKIM/DMARC om allerlei ellende tegen te gaan.

Had toch wel gehoopt dat DE OVERHEID hier als eerste mee zou beginnen...

Dat zijn dan de mensen die je land moeten regeren...
Dat zie je verkeerd. Gelukkig zijn het niet de mensen die ons land regeren die ook de mailserver moeten installeren. Natuurlijk kun je zeggen dat de politiek verantwoordelijk is, maar die mensen worden iedere 4 jaar opnieuw gekozen. De fout ligt bij de beheerder van de mailserver. Die schiet hier volkomen tekort en zou daarom ook op het matje moeten worden geroepen.
Verwacht op IT-vlak niet al te veel van de overheid, anders zal je vaak teleurgesteld zijn. Ik ben blij dat mijn gemeente al DNSsec en SPF gebruikt. Indrukwekkend.
Vreemd, want dit zou toch betekenen dat veel mail geweigerd wordt die vanaf dat domein wordt gestuurd door het ontbreken van een SPF record. Een beetje spam filter controleerd hier dan op. Zodra dat wordt opgevangen, gaan gebruikers klagen dat mails niet aankomen of in de spam terecht komen. Dit moet binnen een week opvallen.
Voor zover ik de RFC hierover begrijp hoort het niet aanwezig zijn van een SPF record niet te leiden tot het weigeren van de email. In de praktijk zie ik wel dat Gmail en Hotmail de email direct in de spammap zetten. Maar daar krijg je geen bericht van terug, dus tenzij de ontvanger aan de bel trekt weet je daar niet van.
Complete afwezigheid van SPF-records draagt over het algemeen niet veel bij aan een spam-score. In ieder geval bij spamassassin (standaard instellingen), een veelgebruikt open source spam filter.
Buiten dit heeft de mailserver ook een B rating op ssllabs.com omdat hun Cipher Suites niet helemaal op orde zijn.

"This server supports weak Diffie-Hellman (DH) key exchange parameters"

Echt serieus je zou verwachten dat iedereen dat ondertussen wel op orde heeft..

[Reactie gewijzigd door HKLM_ op 24 oktober 2017 08:04]

en ook : https://www.htbridge.com/ssl/?id=CPtHfgCn
Gewoon te triest..

The server's Diffie-Hellman parameter is too small.
Non-compliant with NIST, HIPAA and PCI DSS
The server supports protocols that have known weaknesses and are considered unsafe.
Non-compliant with NIST, HIPAA and PCI DSS
The server supports cipher suites that are not approved by PCI DSS requirements, NIST guidelines and HIPAA guidance.
Non-compliant with NIST, HIPAA and PCI DSS
The server is vulnerable to POODLE over SSL.

Nu zegt dit ook niet alles, maar goed is anders en dit is gewoon slecht.
Ziet er uit als een standard 2008R2 (2012?) windows server waar mogelijk wel netjes de patches op gezet zijn, maar niet de moeite is genomen om ssl 2/3 uit te zetten en tls1.2 aan.

mogelijk even IISCrypto van Nartac software (free download) runnen op de server en de best practices toepassen. Die zet de goede registry settings voor de Schannel services.

[Reactie gewijzigd door Frost_Azimov op 24 oktober 2017 14:31]

Grappig, want SSLLabs test alleen webservers...
Als ik naar https://webmail.parlement.nl ga kom ik uit op hun webmail met certificaat. Als ik vervolgens naar https://webmail2.parlement.nl ga kom ik op de webmail pagina uit zonder certificaat.

Ze hebben dus twee exchange servers zo te zien, zou de tweede webmail niet ook een certificaat moeten hebben en tevens moeten redirecten naar https://webmail.parlement.nl

Misschien heb ik het mis hoor, maar mijn dubbele exchange server kennis is beperkt.
Misschien heb ik het mis hoor
Ja de pagina's waarna jij linkt is geen webmail van Exchange. Het lijken mij F5 Big-Ip inlog pagina's.
Zolang ministers en Tweede Kamer leden ook doodleuk e-mails laten doorsturen naar privé e-mailadressen, omdat men te lui is of het te moeilijk vind om een tweede mailbox in te stellen op [insert favoriet mobiel apparaat hier] zou ik mij nog allerminst zorgen maken om het gemis van DMARC, DKIM en SPF. Diensten zoals GMail hebben standaard - naar mijn weten - dat namelijk ook niet ingesteld staan en wie weet wie men mailt vanuit het privé mailadres met zakelijke stukken.

Het instellen zou natuurlijk top zijn, zeker voor de mensen die wél uitsluitend het emailadres van de Tweede Kamer gebruiken om zakelijk te mailen, al lost het - helaas - het probleem niet 100% op, dat is mijn punt meer.

[Reactie gewijzigd door CH4OS op 24 oktober 2017 09:42]

Google doet op de gmail.com wel aan DKIM signing, dat ze vervolgens de DMARC policy nog niet naar p=reject hebben gezet heeft een andere reden.

Authentication-Results: mx.google.com;
dkim=pass header.i=@gmail.com header.s=20161025 header.b=hI1VS5qM;
spf=pass (google.com: domain of xxxxxxxxxxxx@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=xxxxxxxxxxx@gmail.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:sender:from:date:message-id:subject:to;
bh=26GEMKxgQetRZNc4BA6u89h84CcETYHGAXFxoWch4XE=;
b=hI1VS5qMWZc1tiXrR+p7s81dMDwgrECU4AF1abMM3Vgff8TJy6aJRQODbcJnX0GBYs
yj6knp/UK4+iWZqkCL72aFJPcQcccGQHzVXN2jxUHeFy7/1PmNetDaF/zEu77p7hCFVg
gQnKN7lCL2rg018iNU3HdL0ZDYUVgjInrkjpLOZ5UHCDhx37yD7I8K702gIDFpPh9rHn
0pyvMayaZIh7SEQ9u/YhLXo5gC5j3a/LwTno5ym3U7EHsg5KfjcU20n6LzZuBEpiD8qi
cRPHoFJ/6H7LlwaYoJMX5DIJ9WzE/tOw3EFzruvn2yVKYEsYiGEFN/3ZxPrrmvNucv85
sxsQ==


https://www.dmarcian-eu.com/dmarc-inspector/gmail.com

[edit]
Outlook.com doet ook DKIM signing
Authentication-Results: mx.google.com;
dkim=pass header.i=@outlook.com header.s=selector1 header.b=V2Q2zw99;
spf=pass (google.com: domain of xxxxxxxxxxxx@outlook.com designates 40.92.72.15 as permitted sender) smtp.mailfrom=xxxxxxxxxx@outlook.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=outlook.com

[Reactie gewijzigd door orbit_ph op 24 oktober 2017 11:30]

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True