5 min read

Over Vlaanderen.be, SPF, DMARC en andere acroniemen.

Mijn commentaar bij het HLN artikel over spam van vlaanderen.be. Niet alles, is wat het lijkt.
Over Vlaanderen.be, SPF, DMARC en andere acroniemen.
Photo by Brett Jordan / Unsplash

Ha, het paste zo goed in het hele "Vlaamse overheid spendeert miljardenjoenen aan consultants" verhaaltje dat de pers al enkele weken bezighoudt: HLN.be (I know) kwam met een verhaal waarom een "ethische hacker" aan het woord komt over wat een prutsers de Vlaamse Overheid is als het op mails aankomt in artikel met als titel "Hackers sturen valse 'fiscale fiches' vanuit vlaanderen.be: “Mailen als minister-president van Vlaanderen is fluitje van een cent”.

Een goedgeschreven artikel, dat niet. Het is wel duidelijk komkommertijd en dan worden uitspraken van "ethische hackers" niet meer gefactcheckt. Daarnaast is de insteek van het artikel niet helemaal correct, maar daar kom ik op het einde toe.

SPF

Het artikel raakt enkele heel juiste zaken aan. Er worden heel veel spam of phishing mails gestuurd die doen alsof ze van de Vlaamse overheid komen, ook ik erger me eraan, want hoewel de meeste worden tegengehouden door spamfilters, belanden er toch in mijn inbox.

De belangrijkste reden die het artikel aanhaalt, is de chaos in de SPF records, die wijzen op het feit dat niemand bij de overheid echt overzicht heeft over de gebruikte maildiensten, en er geen kritisch proces is bij het reviewen van de entries.

SPF-records zijn een stukje DNS informatie (de vaste lezers weten dat DNS een van mijn dada's is), die aan andere mailservers aangeven welke mailservers namens een domein verondersteld zijn mail te sturen. De records die op de vlaanderen.be domeinnaam staan, zijn syntactisch correct, maar bevatten bij nader inzicht een hoop rommel, zoals het artikel aanhaalt.

Het artikel is helemaal correct als het aanhaalt dat het grootste probleem bij deze SPF records zit.

Te veel SPF

Alleen maakt het artikel wat shortcuts en is het niet helemaal volledig op een paar andere punten. En mist het de essentie, maar daar kom ik straks op terug.

Zo vallen mij drie zaken op als ik het voor het eerst naar de SPF records kijk. Vooreerst zijn de SPF records enorm uitgebreid. Als ik snel tel, gaat het om 145 netwerk-blokjes, goed voor een klein miljoen (!) afzonderlijke ip-adressen.

Verder zijn er de talloze "RFC 1918" ip-adressen die erin voorkomen. Dit zijn adressen die enkel kunnen voorkomen in "private" netwerken zoals je thuis-net of bedrijfsnetwerken, maar op het internet onbruikbaar zijn. Er is geen enkele geldige reden om deze adressen op te nemen in een SPF record, toch niet in een organisatie die de basis netwerk hygiëne op orde heeft...

Als derde valt op dat de SPF records enkel individuele ip-blokken bevatten, en geen includes naar andere domeinen gebruiken. Let me explain ... Als je nieuwsbrieven verstuurt via een bepaald platform, of een extern-gehoste inschrijf-module gebruikt, sturen die externe diensten mail uit jouw naam. De ip-adressen van de servers die door die derde partij gebruikt worden om mail te sturen, moeten dus opgenomen worden in de SPF records van al hun klanten.

Dit zou willen zeggen dat elke keer zo'n uitbater iets aan hun infrastructuur verandert, ze alle klanten op voorhand zouden moeten melden welke nieuwe ip-adressen in gebruik genomen zullen worden. Omdat dit praktisch niet haalbaar is, kan je "doorverwijzingen" gebruiken bij SPF records. Zo kan je bv zeggen "dit ip hier is mijn bedrijfs-mailserver, maar ik gebruik MailChimp om mails te sturen, dus ga daar even kijken welke servers zij gebruiken om te mailen, en heb een webshop bij Shopify, die ook wel mailtjes in mijn naam mag sturen".

De Vlaamse overheid gebruikt die mogelijkheid compleet niet. Enkel individuele ip-adressen of ip-blokken zijn opgenomen. Er kunnen meerdere redenen zijn om dit te doen, maar tenzij de VO dit 100% geautomatiseerd heeft, werkt dit systeem niet. De gigantische hoeveelheid adressen die in de SPF lijst voorkomen, wijzen voor mij dat aan dit proces heel wat schort.

Oei, geen SPF?

Helaas gaat het artikel op een paar plekken in de mist. Vooreerst haalt het aan dat er Microsoft adressen op de lijst staan, en het de spammers daardoor wel heel makkelijk maakt.

Hoewel de SPF records van de VO inderdaad een gigantische adresblok van Microsoft opneemt en het als spammer allicht niet zo heel moeilijk is een ip-tje daaruit te bemachtigen op een Azure account, is enkel het opnemen van Microsoft adressen op zich niet zo'n probleem. Meer nog: als je organisatie Office365 gebruikt als mailplatform, moet je de SPF records van MS Office365 opnemen. Het is natuurlijk wel een probleem als je meer dan enkel de adressen van de Microsoft mailservers opneemt, maar dat onderscheid maakt het artikel niet.

Daarnaast zou de ethische hacker moeten zien dat de SPF records bij de Vlaamse overheid nog maar recent toegevoegd zijn. Ik heb in elk geval spam-samples van 30 mei 2023 of 5 juni 2023 die aangeven dat er op dat moment gewoon geen SPF record was. Update: een vriendelijke ziel bezorgde me een mail van 10 juni waaruit ik afleid dat er zelfs op 10 juni nog geen SPF records waren.

Update: Wouter Goderis toonde net aan dat de records er maar sinds 8 juni staan.

Het feit dat vlaanderen.be sindsdien SPF records heeft, is dus een reactie, geen oorzaak van de recente spam-golf. De VO zou dus aangemoedigd en gefeliciteerd moeten worden in het artikel. De SPF records zelf is nog gigantisch veel werk aan, maar de stappen zijn wel gezet! Het artikel slaat hier dus volgens mij de bal mis.

Dat neemt uiteraard niet weg dat de journalist ook niet kritisch moet zijn voor de uitspraken voor de uitspraken van de woordvoerder van Vlaanderen Digitaal die in de laatste paragraaf aan het woord komt. Het is op vandaag niet mogelijk om DKIM signing (waarbij aan elke mail een onzichtbare handtekening wordt toegevoegd die gecontroleerd wordt door de ontvangende mailserver) af te dwingen. Hetgeen het dichts in de buurt komt en waar de woordvoerder op alludeert is het DMARC record. Die geeft aan dat de mail waarschijnlijk spam is als of de DKIM header ontbreekt of de zendende mailserver niet in de SPF adressen zit (en daarnaarst is er nog iets technisch over alignment maar dat zou ons te ver brengen).

Met andere woorden: als een mail niet digitaal via DKIM getekend is, maar de mail is wel verzonden door een server in de (veel te) uitgebreide set ip-adressen in het SPF record, dan zal de mail niet noodzakelijk als spam aanzien worden.

In t kort ...

... had het artikel beter de titel "Hackers sturen valse 'fiscale fiches' vanuit vlaanderen.be: Vlaamse Overheid pakt het aan (maar heeft nog een weg te gaan)".

Daarnaast is goed dat SPF records plaatsen en een strikte DMARC policy implementeren helpt. Bijna alle grote mailservers (GMail en Microsoft voorop) hechten een groot belang aan deze systemen. Waar ze vroeger eerder "optioneel" waren, zijn ze vandaag essentieel. Zowel in het reduceren van de hoeveelheid spam in onze mailboxen, maar ook in het omgekeerde. Het is cruciaal dat je deze records correct en juist geïmplementeerd hebt om zeker te zijn dat je mail toekomt in de mailbox van je ontvangers. Daarover schrijf ik later nog wel eens iets ... (insert mysterieus muziekje hier)

Update 21/06/2023: Er blijft spam toekomen met vlaanderen.be afzenders. Het lijkt erop dat mijn suggestie hieronder dat ook de Nameserver setup niet optimaal was, correct blijkt: de nameservers geven heel vaak een SERVFAIL foutbootschap als je de SPF records opvraagt. Overbelast? Rate-limiting ergens? Te weinig redundantie zowiezo.

💡
Dus, lieve Mail/DNS admins bij de VO: doe zo voort, je bent goed bezig. Je moet je SPF netblocks drastisch trimmen, dat weet je waarschijnlijk zelf ook. Oh en je gebruikt nu een service van Mimecast om je DMARC rapportjes te beheren. Je krijgt daar ook de ruf reportjes, die persoonsgegevens bevatten. Check je even met je DPO of alle contractjes OK zijn en Mimecast opgenomen is in je lijst subprocessors? Oh, en over de redundantie van je nameservers moeten we ook nog eens praten, maar dat is voor een andere blogpost :)