Tijd voor goede open-source tools zodat je ook met de rapportages zelf aan de slag kunt (zonder te verdwalen in XML bestanden).

Mja leuk de zoveelste die een oplossing zou "kunnen" zijn.
Zeflde probleem als alle andere "oplossingen", je kan nog zoveel zooi meesturen met een mail, als de ontvanger er vervolgens niets mee doet dan is het zinloos. Simpel weg de reden waarom email nog steeds zoveel problemen heeft, als de oplossing echt wereldwijd had kunnen worden doorgevoerd, dan was dat allang gedaan.

Op naar de volgende die denkt dat de hele wereld wel even in een weekendje gaat updaten naar hun systeem, want ja die van hun is natuurlijk zoveel beter dan die 10 gefaalde ervoor...

Leuk zo'n plaatje maar er klopt weinig van.

Onzin. SPF kijkt volstrekt niet naar de afzender in het Message From veld (en ook niet naar de persoon het Envelope From veld dat trouwens ook leeggelaten mag worden door de afzender - maar dat laatste is, toegegeven, wel verdacht).

Indien optimaal anti-spoofing geconfigureerd, voorkomt SPF dat e-mail verzonden kan worden vanaf een IP-adres dat niet expliciet vertrouwd wordt door de zendende organisatie. Maar bijna niemand configureert SPF optimaal omdat dit forwarding enorm bemoeilijkt of onmogelijk maakt (zie ook [1]).

Als iemand knoeit met de inhoud van een e-mail en de DKIM header verwijdert of wijzigt, detecteert DKIM helemaal niks.

DMARC is het enige protocol dat naar de organisatie in Message From kijkt en daamee het krachtigste protocol van allemaal (en dat komt niet erg uit de verf zo). Het kan echter vervalste e-mails niet voorkomen in de volgende gevallen:
1) De mail client van de ontvanger laat uitsluitend de "friendly name" zien van de afzender, zoals "International Card Services" (en niet <afzender@example.com>), of de ontvanger let daar niet op;
2) De mail client laat netjes de kennelijke afzender zien, bijvoorbeeld: International Card Services <no-reply@ics.nl>
maar de ontvanger weet niet dat ics.nl helemaal niets te maken heeft met icscards.nl [2];
3) Een e-mail account of PC van een medewerker is gehacked;
4) Een spammer verkrijgt op een andere manier de mogelijkheid om e-mail te verzenden vanuit de organisatie (zie bijv. [3]);
5) De organisatie staat een derde partij toe om e-mails namens hen te verzenden, en daar gaat iets mis met de beveiliging;
6) De ontvangende mailserver doet er niks mee.

DNSSEC en DANE zijn in de praktijk non-existent en onveilig (zie [4]).
Daarmee wordt STARTTLS gedegradeerd tot opportunistic encryption. Wat wil zeggen dat je geen zekerheid hebt dat verbindingen versleuteld zullen zijn. En bij een versleutelde verbinding is het goed mogelijk dat dit met een MITM is die de mails kan lezen, doorsturen, wijzigen en/of droppen. Bovendien bieden deze protocollen geen enkele beveiliging van e-mails op mailservers zelf.

In de praktijk is het nadeel van al deze protocollen dat, indien niet juist geconfigureerd, IP-adressen wijzigen of certificaten verlopen, je als verzender het risico loopt dat jouw mails als onbetrouwbaar in spamboxes belanden. Naast de discussie over het nut leidt dit ertoe dat deze protocollen niet massaal uitgerold zulen worden en de effectiviteit dus verder beperkt blijft.

[1] https://isc.sans.edu/forums/diary/Phishing+for+Big+Money+Wire+Transfers+is+Still+Alive+and+Well+or+For+Want+of+Good+Punctuation+all+was+Lost/22141/#39059
[2] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
[3] https://www.security.nl/posting/504763/Java_Python+XXE%3A+FTP+en+SMTP+risico's
[4] https://sockpuppet.org/blog/2015/01/15/against-dnssec/

Gezien dat dit protocol pas in 2012 aan de wereld voorgesteld is, vind ik het nog meevallen dat zo'n nieuw protocol al door 10% van de bedrijven gebruikt wordt. Uit interesse kijk ik wel eens in het "_dmarc." subdomein van bedrijven en zie dat het toch best wel vaak ingesteld staat. (alleen meestal met een p=none).

Maar naast dit protocol moet je mensen bewust maken dat ze altijd naar de echte afzender moeten kijken en niet naar de "friendly name". Mail programma's zouden niet eens de optie mogen hebben de echte afzendernaam te verstoppen. Of als compromis alleen het echte mailadres weglaten als dit in het eigen adresboek voorkomt. (Thunderbird heeft die optie)

Ik zie net dat GMail zich nog steeds niet aan zijn belofte uit 2015 houd om de policy medio 2016 op reject te zetten. zie: https://www.security.nl/posting/448417/Google+gaat+strenger+DMARC-beleid+voor+Gmail+doorvoeren


En GMail is een van de promotors van dit project. Als ik nu bij gmail en ook bij apple mail kijk, staat die policy nog steeds op none. Yahoo doet het wat dat betreft beter.


Een mailserver die dmarc controleert zal dan wel zijn bevindingen in de header schrijven, maar er verder niets mee doen.

Edit: dmarc.org heeft vorige maand ook een lijst gepubliceerd met de dmarc policy van een paar grote bedrijven: https://dmarc.org/who-is-using-dmarc/

Helemaal mee eens, dit is toch wel 1 van de grootste problemen waardoor de niet phishing bewuste mensen iedereen keer weer in de phishing mails trappen.

Hier nog een mooie dienst welke iedere week gratis kan rapporten over failed/succes delivery icm DMARC.

https://dmarc.postmarkapp.com

Er zijn uiteraard nog wel veel mooiere tools, met realtime dashboards etc, maar de bovenstaande is gratis.

Andere geavanceerde tools waar ik ooit naar heb gekeken zijn:
https://250ok.com
https://dmarcian.com
https://www.agari.com

In Europa hebben we ook nog de variant https://dmarcian-eu.com.
Ik zou wel eens iets willen hebben dat niet in de cloud staat eigenlijk, maar gewoon in Plesk of DirectAdmin ofzo.

Onjuist. Je kunt alleen met de private key van de eigen organisatie tekenen, niet met een willekeurige key, want dan klopt de public key niet meer. De inhoud van het bericht wordt wel degelijk beschermd door DMARC (mits goed geconfigureerd).

Wel juist, want Erik had het over alleen DKIM als protocol. En dan weet je alleen dat de mail onveranderd is sinds het de smtp server van de ondertekenaar verlaten heeft. Kwaadwillenden kunnen de ondertekening gewoon wissen of door een nieuwe DKIM header vervangen, na de mail aangepast te hebben.

Het is pas DMARC wat afdwingt dat er een DKIM ondertekening op naam van het 'from adres' aanwezig moet zijn. Meerdere DKIM ondertekeningen mogen ook, maar de rest wordt door DMARC genegeerd.

De titel van het artikel is 'FTC: Bedrijven moeten DMARC tegen phishing uitrollen'. Onderdeel van DMARC is DKIM. Daarom is het door Erik gestelde pertinent onjuist. Je gaat niet alleen DKIM uitrollen. Overigens blokkeer je met DMARC de mail, de detectie zit al in het DKIM protocol ingebouwd.

Public/private key crypto. De private key tekent, en je checkt met en tegen de public key. DMARC zelf checkt niets, het definieert alleen de policies.

Klopt. Echter ik ben ervan overtuigd geraakt dat al deze trucs phishing onvoldoende helpen voorkomen. Daarbij stoorde ik mij voorral aan het plaatje; als je mensen van het nut van drastische maatregelen probeert te overtuigen, verkoop dan geen popie-jopie onzin.

DKIM is veel ouder dan DMARC en werd destijds (net als het nog veel oudere SPF) gepromoot als de heilige graal. Zonder DMARC is DKIM echter waardeloos zoals ik aantoon in [1]. En, zoals ik in mijn bijdrage hierboven (onder DMARC) laat zien: zelfs met al deze maatregelen door alle mailservers geïmplementeerd wordt phishing niet uitgeroeid, terwijl die suggestie voor de zoveelste keer wordt gewekt.

Onzin. Bij beide protocollen is sprake van detectie en potentieel weigeren (of bijv. als spam taggen) van e-mail.

Asymetrische cryptografie is een briljante uitvinding. Helaas kennelijk zo briljant (of gecompliceerd?) dat de meeste gebruikers er niet bij stilstaan van wie de public key is.

Zo is het een epic fail van DKIM dat het niet checkt of de public key van de geclaimde afzender is (nogmaals zie [1] waarin een e-mail, naar verluidt verzonden door een gmail.com gebruiker, dat niet is - ondanks kloppende SPF en DKIM signature - niet gezet door gmail.com). DKIM is pas bruikbaar als DMARC wel checkt dat de DKIM public key toebehoort aan het geclaimde afzenderdomein.

De gefalsificeerde e-mail in [1] is doorgelaten door xs4all omdat, hoewel gmail had gevraagd wel te checken (immers er is een policy gepubliceerd, en nagaan of daaraan voldaan wordt noem ik "checken"), tevens had gevraagd niets (anders dan rapporteren aan gmail) met het resultaat te doen. En, zoals Briolet gisteren schreef, doet gmail dat kennelijk nog steeds niet. Waardoor ook hun DKIM waardeloos is.

[1] https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)

Vaag, dat betekent dat werknemers van het bedrijf wel protected zijn.

_dmarc.google.com descriptive text "v=DMARC1\; p=reject\; rua=mailto:mailauth-reports@google.com"

_dmarc.apple.com descriptive text "v=DMARC1\;p=none\;ruf=mailto:d@ruf.agari.com\;rua=mailto:d@rua.agari.com\;fo=1"

Zonder DMARC is dit inderdaad zo, maar dat maakt DKIM nog niet waardeloos. Je moet dit een beetje 'omdenken': Met DKIM kan je als verzender verantwoordelijkheid nemen voor je e-mail. Je kunt stellen: de verzendende organisatie koppelt zijn reputatie aan de e-mails die worden uitgestuurd. Dankzij DKIM wordt het lastiger voor spammers en phishers om die reputatie te beschadigen. Anders gezegd; als je als verzender zorgt voor een goede reputatie (geen spam, geen phish vanuit jouw domein), dan kun je met behulp van DKIM profiteren van die goede reputatie. Want mails met DKIM zijn gegarandeerd in ongewijzigde vorm zo van jou afkomstig. Deze krijgen een plusje in de slimme e-mail systemen van Google, Microsoft of Yahoo. Zonder DKIM kun je niet profiteren van een goede reputatie, want iedereen kan dergelijke emails gemaakt en/of onderweg veranderd hebben.


Dat zegt natuurlijk meer over de gebruikte mail-client (mijne heeft dit gedrag niet bijvoorbeeld) en de oplettendheid van de ontvanger, dan over deze standaarden.


Prima, dan kunnen we dus heel snel ics.nl als spam-domein kwalificeren!
(zeker als de spammer in kwestie ook SPF/DKIM/DMARC heeft aangezet)

In dit concrete voorbeeld is het nog beter; ics.nl is van de Stichting ICS en die heeft keurig SPF aangezet op zijn domein. Als ze nu ook nog DMARC (en liefst ook DKIM) aanzetten, kan de phisher deze domeinnaam niet eens misbruiken.


Ook voor al deze argumenten geldt: ze diskwalificeren SPF/DMARC/DKIM niet. Ze tonen alleen maar aan dat SPF/DKIM/DMARC bouwstenen zijn die helpen tegen het probleem. Natuurlijk zijn ze niet de zaligmakende totaaloplossing voor al je problemen (want nee, ze beschermen niet tegen het hacken van een PC...)


Dit is niet waar. Bijna de helft van alle .nl domeinnamen heeft DNSSEC-bescherming. Ook aan de validatiekant gebeurt het e.e.a. Zo valideren de resolvers van XS4ALL bijvoorbeeld. Ook Google Public DNS doet dat (8.8.8.8). Het artikel van sockpuppet.org is op een aantal punten onjuist, zeer vooringenomen en betwistbaar en toont nergens overtuigend aan dat DNSSEC onveilig is.

DANE in combinatie met STARTTLS tussen mailserver's (MTA) neemt ook gestaag toe.


Geldt dat niet voor alles in het leven?

Wat ik verder mis is hoe het dan wel zou moeten volgens jou? Ik lees veel kritiek, maar geen alternatieven. Alles zo laten als het was lijkt me nauwelijks een optie. Het is ook niet zo vreemd dat grote mailers massaal aan de DMARC/SPF en DKIM zijn gegaan. Dat doen ze niet zonder reden.

Het vervelende is dat de grote email providers in Nederland (nog) niet meedoen. Ziggo heeft nog geen aansluiting gezocht, KPN wel, maar heeft het nog niet geïmplementeerd.

"non-existent"? Niet als je naar de gebruikscijfers kijkt. Hoewel nog niet overal toegepast, is het gebruik aanzienlijk en bovendien groeit het sterk:
- "State of DNSSEC Deployment 2016": https://www.internetsociety.org/doc/state-dnssec-deployment-2016
- 'DANE for SMTP' statistieken met o.a. XS4ALL, TransIP en Bhosted: https://mail.sys4.de/pipermail/dane-users/2017-February/000374.html

"onveilig"? Daar denken verschillende gerenommeerde partijen toch echt heel anders over:
- "For DNSSEC": https://www.easydns.com/blog/2015/08/06/for-dnssec/
- "Is DNSSEC worth the effort?": https://www.iis.se/english/blog/is-dnssec-worth-the-effort/
- "Sichere E-Mail-Dienste: Erstes Zertifikat nach Technischer Richtlinie des BSI an Posteo": https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2016/Sichere_EMail_Dienste_07122016.html

Kortom: Laten we vooral (verder) aan de slag gaan met DNSSEC en DANE, net als veel andere partijen wereldwijd al doen. Het zijn bouwblokken die de veiligheid van internet naar een hoger niveau tillen. En nee, ze zijn inderdaad niet volmaakt en geen panacee voor alles. Maar dat geldt voor meer standaarden zoals bijvoorbeeld PKI (zie Diginotar) en HSTS (zie o.a. problematiek van Trust on First Use).

Over belang van DANE zie presentatie "Why DANE?" door Geoff Huston (APNIC):
- Slides: https://www.nanog.org/sites/default/files/2017-02-08-why-dane.pdf
- Video: https://youtu.be/09fNjMur1Gs

Als één van de makers van de hierboven afgebeelde infographic SPF-DKIM-DMARC-STARTTLS-DANE wil ik graag reageren op de discussie. De opmerkingen en kritiek over het plaatje, en met name de teksten zijn grotendeels terecht. Bedenk daarbij dat we dit plaatje in de eerste plaats hebben gemaakt voor een bestuurlijk publiek zonder technische achtergrond. Daarbij stond voorop dat het plaatje duidelijk moet maken welk probleem elke standaard aanpakt, de technische volledigheid en correctheid van de teksten was voor dit publiek van ondergeschikt belang. We vonden het best moeilijk om teksten te bedenken die (a) uitleggen waar de standaard goed voor is; (b) technisch min of meer uitleggen wat de standaard doet en (c) niet meer dan één of twee regels lang zijn.
We gaan het commentaar in deze discussie meenemen en proberen een accuratere versie van de infographic te maken. Als jullie concrete tekstvoorstellen hebben, zijn die zeker welkom. Han Zuidweg - Bureau Forum Standaardisatie

Beste Han, zoekend naar iets anders vond ik deze thread en las nu voor het eerst jouw bijdrage (enkele dagen na een redactie-artikel zijn er zelden relavante bijdragen, ik kijk dan ook lang niet altijd terug - jammer dat ik deze gemist heb).

Wetende dat de kans klein is dat je dit nu nog leest: ik denk graag mee en ben best bereid daar wat vrije tijd voor op te offeren. Als je op het forum een nieuwe thread over dit thema begint, haak ik daar wel op in en kunnen we contactgegevens uitwisselen.

Met vriendelijke groet,
Erik van Straten