E-mailspoofing is een van de technieken die kwaadwillenden gebruiken om je te overtuigen dat hun spam/phishing-e-mail legitiem is. Kort gezegd, e-mailspoofing wordt door deze kwaadwillenden gebruikt om het te laten lijken alsof hun e-mails afkomstig zijn van vertrouwde bronnen zoals je bank, je favoriete product of je baas.

E-mailprotocollen bestaan al heel lang. Simple Mail Transport Protocol (SMTP), het belangrijkste protocol waarop e-mailcommunicatie is gebaseerd, dateert uit 1981. Het internet is behoorlijk veranderd, maar e-mail helaas niet zo veel. Toen e-mail werd gecreëerd, waren er slechts een fractie van het aantal gebruikers van vandaag. Destijds was er weinig schade aan het versturen van een nep-e-mail. Nu worden e-mails voor bijna alle digitale diensten gebruikt die je kunt bedenken en de technologie heeft langzaam de achterstand ingelopen.

Laten we beginnen met hoe e-mails werken, zodat iedereen op dezelfde pagina zit. Dit is een extreme vereenvoudiging van hoe e-mail werkt, maar het helpt me de mechanismen uit te leggen om dit een veilig proces te maken. Grofweg gezegd, wanneer iemand een e-mail verstuurt, gaat het als volgt:

1. Alice (hi@alice.com) schrijft een e-mail naar Bob (hi@bob.com).
2. Alice verstuurt de e-mail naar haar e-mailserver voor levering.
3. Alice’s e-mailserver lokaliseert Bob’s e-mailserver en verzendt de e-mail.
4. Wanneer Bob verbinding maakt met zijn e-mailserver, vraagt hij om nieuwe berichten en verschijnt er een nieuwe e-mail in Bob’s inbox.

Simpel! Echter, er kan veel misgaan tijdens het verzenden van een e-mail. Laten we erin duiken!

Sender Policy Framework (SPF)

Oh, maar het internet zit vol met verschrikkingen. Stel je voor dat er een kwaadwillende is, laten we hem Chuck noemen, die Bob wil misleiden om zijn Harvest-wachtwoord te sturen.

Dat klopt, gewone SMTP vertelt ons niet of degene die een e-mail verstuurt is wie hij zegt dat hij is.

Om onze e-mails te beschermen tegen dit soort aanvallen, kunnen we Sender Policy Framework (SPF) gebruiken. Wanneer een e-mailserver een nieuwe e-mail ontvangt, vraagt deze het bron-domein of de afzender is toegestaan om e-mails in hun naam te versturen. Dit is wat SPF doet; wanneer Bob’s e-mailserver een e-mail ontvangt die zogenaamd afkomstig is van alice.com, vraagt het eerst aan alice.com of de echte afzender, chuck.com, iets in hun naam kan versturen.

In de afbeelding hierboven zie je dat Bob’s server een DNS-verzoek uitvoert. Deze techniek en alle andere in deze blogpost zijn gebaseerd op dit protocol. Wanneer ik schrijf over Bob’s e-mailserver die alice.com om informatie vraagt, betekent dit gewoon dat er een DNS-verzoek naar alice.com wordt gestuurd op zoek naar specifieke records.

Als alice.com chuck.com niet heeft vermeld als een van zijn toegestane afzenders, dan kan Bob’s e-mailserver de e-mail als spam markeren. Je hoort het goed, het kan dat doen of niet. Bob’s server heeft altijd het laatste woord en er zijn andere controles die moeten worden uitgevoerd voordat een definitieve beslissing wordt genomen.

DomainKeys Identified Mail (DKIM)

E-mails zouden nu veilig moeten zijn, toch? Nou... niet helemaal. We hebben Chuck verhinderd om nep-e-mails vanaf zijn eigen servers te versturen, maar wat zou er gebeuren als hij een manier vond om in-transit e-mails te onderscheppen? Wat als hij in staat was om de inhoud van Alice’s berichten te wijzigen? Vergeet niet, SPF verifieert alleen dat de afzender is toegestaan om e-mails in haar naam te versturen, maar het zegt niets over wat er onderweg naar de ontvanger gebeurt.

Dit is het perfecte scenario om handtekeningen te gebruiken. In de digitale wereld is een handtekening een mechanisme om te waarborgen en te verifiëren dat de inhoud van wat wordt afgeleverd niet is veranderd. Wanneer Alice een e-mail naar Bob verstuurt, zal nu Alice’s e-mailserver een handtekening aan de inhoud van de e-mail toevoegen. Als iemand ook maar één bit van dat bericht verandert, zal Bob het weten. Bovendien is Alice's e-mailserver de enige die weet hoe deze handtekeningen te maken. Niemand anders kan dit doen zonder dat de ontvanger het opmerkt.

Dit is precies wat DomainKeys Identified Mail (DKIM) doet. In de praktijk begint de DKIM-configuratie in Alice’s e-mailserver:

• Er is meestal een manier om "e-mails te authentiseren" die worden verzonden. Dit betekent meestal gewoon het inschakelen van DKIM.
• De e-mailserver vraagt je om enkele cryptische woorden in je DNS te publiceren; dat is de publieke sleutel van je handtekening. In gewone taal maakt de publieke sleutel het mogelijk voor anderen om te verifiëren dat een handtekening die ze hebben ontvangen geldig is en dat het bericht niet is gewijzigd tijdens de verzending. De server houdt de privésleutel zodat alleen zij handtekeningen kan maken.
• Zodra de publieke sleutel is gepubliceerd, zal de e-mailserver beginnen met het verzenden van een handtekening bij elke nieuwe e-mail.

Hoe is de handtekening nuttig? Wanneer Bob’s e-mailserver een e-mail ontvangt met een bijgevoegde handtekening, kan deze verifiëren of de handtekening correct is. Om dat te doen, moet de server de publieke sleutel en de inhoud van de e-mail ophalen. Met alleen die twee dingen kan de server detecteren of er ongewenste wijzigingen zijn aangebracht.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Nu kan Bob er redelijk zeker van zijn dat e-mails afkomstig zijn van een vertrouwde bron en dat ze niet zijn gemanipuleerd, toch? TOCH?... Als het maar zo eenvoudig was... Chuck, ons kwaadwillende personage, kan nog steeds de inhoud van de e-mail wijzigen en gewoon de DKIM-handtekening verwijderen. Wie heeft dat nodig? Het is beter om een neutrale controle te hebben dan een negatieve.

Niet alles is verloren, echter. We hebben gewoon een manier nodig om Bob’s e-mailserver te vertellen welke beveiligingsmaatregelen zijn geconfigureerd en een beleid dat definieert wat te doen als een van deze faalt. Laten we ons laatste acroniem bekijken: Domain-based Message Authentication, Reporting and Conformance (DMARC).

Met DMARC heeft Bob’s e-mailserver een openbaar informatiepunt dat definieert wat te doen met e-mails die het ontvangt. Meer specifiek beschrijft een DMARC-record:

• Of SPF of DKIM worden afgedwongen in de ontvangende e-mail
• Een rapportage-e-mailadres voor monitoringdoeleinden
• Een beleid om te beslissen wat te doen wanneer er een foutieve controle is. Er zijn 3 verschillende beleidsregels:
• Geen beleid - DMARC-controle resultaten worden genegeerd. E-mailservers zullen echter rapporten verzenden voor verdere analyse. Dit wordt vaak gebruikt tijdens het configureren van DMARC om te zien of het werkt zoals verwacht.
• Quarantaine - E-mails die een DMARC-controle niet doorstaan, worden naar de spamfolder van de ontvanger gestuurd.
• Afwijzen - E-mails die een DMARC-controle niet doorstaan, bereiken de ontvanger niet.

DMARC is het laatste stuk in onze toolbox, en het is de enige die specifiek e-mailservers vertelt om niet-conforme e-mails te verwerpen, en onder welke omstandigheden dat gebeurt.

Conclusies

We zijn blij te kunnen zeggen dat Harvest deze technieken gebruikt om onze e-mails te beschermen. Het heeft ons maanden gekost om te leren en gegevens te verzamelen totdat we eindelijk zijn waar we nu zijn. We hebben het anderen echt moeilijk gemaakt om zich als ons voor te doen en de reputatie van Harvest te ondermijnen. Dit is een geweldige prestatie die onze klanten ten goede zal komen.