SPF skrald

Landfill

Forholdsvis mange firmaer har et domæne med en defekt SPF record.
Den nok hyppigste årsag til SPF record defekter er for mange DNS opslag.

Synderen er for det meste Sender ID standarden.
Sender ID havde nogle alvorlige defekter fra fødsel, og kun nogle Microsoft ildsjæle tog i en periode standarden alvorligt, herefter overgik den hurtigt til en slags vegetativ tilstand.
I slutningen af 2011 begyndte selv Microsoft at anvende SPF.
Endelig i 2015 blev Sender ID standarden erklæret officielt død.

Der er dog stadig masser af firmaer der vil bede dig lave tilføjelser til din SPF record som kun har til formål at understøtte den afdøde Sender ID standard, det bliver desværre i sidste ende tit på bekostning af SPF funktionalitet som ophører med at virke.
Det hele bliver ekstra forvirrende af at disse leverandører omtaler Sender ID understøttelsen som om der var tale om SPF.

I et forsøg på at komme dette problem til livs, kommer her en liste over elementer du kan fjerne fra SPF recorden i roden af dit domæne, idet de ikke har noget med understøttelse af SPF standarden at gøre.

include:emsd1.com
include:trustpilotservice.com
include:mktomail.com
include:agspf.agillic.eu
include:_spf.presscloud.com
include:_spf.anpdm.com
include:send.aweber.com
include:spf.mailjet.com
include:mailmailmail.net
include:bounce.peytz.dk
include:_spf.createsend.com
include:emarsys.net
include:emsmtp.com
include:emarsys.us
include:emsmtp.us
include:musvc.com
include:spf.sendinblue.com

Listen vil blive opdateret efterhånden som jeg falder over mere skrald

Der eksisterer også en del firmaer med denne include i SPF recorden i roden af deres domæne:

include:amazonses.com

Det er det lodret modsatte af hvad Amazon SES angiver i sin SPF vejledning, så den kan også fjernes.

Læsestof:
M3AAWG Best Practices for Managing SPF Records.
SPF Standarden RFC 7208.

 

Transmission af personoplysninger via e-mail

Fra nytår træder Datatilsynets nye regler for transmission af personoplysninger via e-mail sådan rigtig i kraft.
Vejledningen er lidt uklar, der er mange “kan” og “bør” og meget få “skal” og “er”
Alt i alt, er der som databehandler mulighed for at komme galt afsted.

Tænk hvis vi havde fået simple regler i stil med:
SMTP trafik skal foregå over en TLS forbindelse.
Transmission af personoplysninger der omfatter mere end et enkelt individ skal end-to-end krypteres.

Nå, tilbage til den besværlige virkelighed.

Der er også ting i vejledningen som er helt klart beskrevet, det er f.eks altid databehandler (afsenders) ansvar at en e-mail kan sendes sikkert til modtagerens mailserver.

Det er jo klar tale, men hvordan finder man ud af om det overhovedet kan lade sig gøre?

Lad os forestille os jeg vil sende en e-mail over TLS fra dmarc.dk til datatilsynet.dk.

I Holland tager man elementær sikkerhed noget mere alvorligt end vi gør her i Danmark, på https://internet.nl kan man finde en funktion til at teste et domænes e-mail konfiguration.

Her kan du se en rapport for dmarc.dk
Så langt, så godt, min egen e-mail løsning kan godt transmittere e-mail over TLS.
Nu er det så min opgave at sikre mig jeg kan sende sikkert til Datatilsynets mailserver, her kan du se en rapport for datatilsynet.dk
Ja kønt er det jo ikke ligefrem, e-mail sikkerhed har bestemt ikke nogen høj prioritet hos Datatilsynet, men det er dog muligt at levere en e-mail over en TLS forbindelse til dem.

Så er alt vel godt, og jeg kan roligt trykke på Send knappen?
Ja og nej, Datatilsynet har ikke sikret datatilsynet.dk med DNSSEC, så jeg skal kunne  leve med at min e-mail falder i forkerte hænder hvis nogen har overtaget kontrollen over indgående e-mail til @datatilsynet.dk adresser.

Datatilsynet kunne selvfølgelig bare aktivere DNSSEC for datatilsynet.dk, det tager ikke mange minutter, hos en del DNS udbydere kræver det kun et tryk på en knap.
Udfordringerne stopper imidlertid ikke her, Datatilsynets e-mail leverandør anvender heller ikke DNSSEC. Der er ikke tale om noget unikt for netop deres leverandør, heller ikke de helt store e-mail leverandører som G-Suite & Office365 anvender DNSSEC.

Jeg havde mig en god lang snak med Googles support om netop dette. Det er ikke overraskende ikke specielt nemt at få Google til at indrømme deres standard konfiguration ikke er helt sikker, på den anden side er jeg heller ikke specielt nem at slippe af med igen.

Til slut tryllede Google 4 DNSSEC signede MX hosts op af hatten til mig.

mx1.smtp.goog
mx2.smtp.goog
mx3.smtp.goog
mx4.smtp.goog

Anvender du G-Suite kan du udskifte dine eksisterende MX records med ovenstående, for at få bedst mulighed sikkerhed for at din e-mail leveres til dig.

Alt i alt:
Vi skal snart leve med nogle nye strengere regler for e-mail som skal gøre omgangen med personoplysninger mere sikker.
På papiret ser det fint ud, men i realiteten er der tale om et sminket lig.

Lidt læsestof:
DK-Hostmasters statistik over DK domæner med DNSSEC
How-to Geek om DNS Cache poisoning
Wikipedia artikel om DNS Spoofing

DMARC Workshop hos DK-Hostmaster, d. 8. november 2018

Er du nysgerrig, eller skal du igang med at implementere DMARC, og vil gerne have alle de tekniske detaljer helt på plads?
Så bør du tilmelde dig DK-Hostmasters DMARC workshop d. 8 november 2018.
Tim Draegen fra dmarcian.com kommer og underviser.
Det er gratis at deltage.

Er du i tvivl? Så start med at teste om dit domæne er sikkert.

Du finder mere information på DK-Hostmaster tilmeldingssiden

 

 

Hvor der er vilje, er der vej

For et par uger siden lå Netcompany og rodede på min fumle liste, idet de siden de oprettede deres DMARC record i Juni sidste år ikke har haft en funktionel DMARC record.
Nu er der imidlertid sket ting og sager, på et par uger fra de bevæget sig fra 0 til 100, de har nu en fuld DMARC reject policy.
Det er sgu’ godt gået, flot indsats!

Lad os håbe flere konsulenthuse følger det gode eksempel.

 

Finans Danmark

Finans Danmark

Sidste år i marts måned kom Finans Danmark med en opfordring til at tage kampen op med bla. phishing ved hjælp af DMARC.
Med ganske få undtagelser lykkedes det en samlet finansbranche fuldstændig at overhøre denne opfordring.

Finans Danmark har nu valgt at gå foran med et godt eksempel.
finansdanmark.dk domænet er nu topsikret mod misbrug med en DMARC reject politik, og derudover har man også aktiveret DNSSEC for domænet.
Så bliver det ikke bedre!

Finans Danmark er nu at finde på Elite listen

Så mangler vi bare at resten af finansbranchen kommer igang med at sikre sig selv og deres kunder mod falske emails.

“v=DMARC1; p=none;”

Doing it wrong

DMARC standarden blev designet til at være nem og ufarlig at tage i brug.
Man starter ganske simpelt med at overvåge sin email leverance, der er tale om ren overvågning, sikkerhedsmæssigt og leveringsmæssigt gør denne konfiguration ingen forskel.

"v=DMARC1; p=none; rua=mailto:xxx@ag.dmarcian.com;"

Herefter udfører man de nødvendige tilretninger for at ens email opfylder kravene fra DMARC standarden, tilretter SPF records, tilføjer manglende DKIM signaturer osv.
Denne process kan tage alt fra et par timer til flere år at komme igennem. Det er her værd at bemærke det yderst sjældent er tekniske forhindringer der får tingene til at tage tid, det skyldes typisk langsommelige interne procedurer og ansatte med et anstrengt forhold til nytænkning.

Når ens DMARC rapporter viser konfigurationen er helt på plads kan man skifte til en mere restriktiv DMARC politik, den kunne så således ud:

"v=DMARC1; p=quarantine; rua=mailto:xxx@ag.dmarcian.com;"

Bemærk ordet quarantine, oversat til dansk betyder det i en DMARC record at falske emails med dit domæne som afsender skal leveres direkte i spam mappen.

Vil man opnå bedst mulig beskyttelse mod misbrug, kan man efter et stykke tid skifte til den strengeste DMARC politik, det kunne se sådan ud:

"v=DMARC1; p=reject; rua=mailto:xxx@ag.dmarcian.com;"

Ordet reject medfører at falske emails nu helt afvises hvor de forsøges afleveret.

Alt i alt er DMARC i forhold til så mange andre ting ganske enkelt at implementere, der er jo ikke rigtig noget der kan gå galt…. troede jeg …

Inden man går igang bør man lige bruge en times tid på at sætte sig ind i det helt grundlæggende vedrørende DMARC, ring til en ven, hyr en professionel eller se nogle af de mange DMARC instruktions videoer på Youtube.
Den del er der desværre nogle firmaer som springer let og elegant henover.
Her på det seneste har jeg set en del DMARC records med følgende indhold:

"v=DMARC1; p=none;"

På dansk står der noget i stil med: “Hej emailservere i hele verden, jeg er igang med at implementere DMARC, så nu må i gerne generere rapporter når i ser email som skal forestille at komme fra mit domæne, når rapporterne er færdige kan i bare smide dem væk, jeg vil ikke have dem”

Sådan en konfiguration er selvsagt noget komplet meningsløst fumleri.
Det er ikke sådan at konfigurationen rent teknisk gør skade, den gør hverken fra eller til, i praksis kunne man ligeså godt slette en DMARC record med det indhold.
Men måske sender man et lidt uheldigt signal til de kriminelle?
Her er tale om et firma som sjusker med sikkerheden, er email sikkerhed den eneste form for sikkerhed der sjuskes med, eller sker det også på andre områder?

Fumle listen kan du se eksempler denne slags DMARC implementeringer.

Når dårlig sikkerhed bliver synlig


Postnord/Postdanmark har gennem tiden lagt navn til ganske mange phishing emails.

Nu kommer vi så til det komiske, billedet herover viser ikke en falsk email, den er skam ganske ægte og afsendt af Postnord.

Forklaringen er at Postnord kører den helt usikre stil, ingen DMARC, ingen DKIM signatur, kun en SPF record, og i dette tilfælde har de afsendt email fra en mailserver som ikke er dækket af SPF recorden.

Alt i alt, vil de fleste kriminelle være istand til at sende Postnord email som performer bedre end den ægte vare.

mac.com, me.com og icloud.com

De Apple ejede email domæner mac.com, me.com og icloud.com har nu en DMARC quarantine politik.
Du kan derfor ikke længere anvende din Internet udbyders SMTP server til at afsende den slags email, men skal i stedet for anvende Apples SMTP servere.
Her finder du Apples SMTP indstillinger
Bruger du en email adresse på et af de ovennævnte domæner f.eks. som afsender adresse hos MailChimp eller en anden email service provider, skal du skifte til et andet domæne.

SPF record tips

SPF record tips & tricks

SPF standarden beskriver den simpleste form for email authentication der eksisterer.
SPF har været i brug siden ca. år 2005.
Enhver domæneejer bør kende til og anvende SPF, sådan lidt i stil med alle der færdes i trafikken skal kende færdselsloven og overholde den.
Men, hvor det i trafikken er forbudt ved lov at udsætte sig selv eller andre for fare, så forholder det sig helt anderledes på Internettet, her er der nærmest ingen regler for hvor usikkert  man kan slippe afsted med at opføre sig.

Mange domæner anvender ikke SPF.
Andre har problemer med implementeringen, og ender med  en konfiguration som ikke virker.

Jeg har kigget på rigtig mange SPF records gennem årene, og i forhold til de defekte SPF records, er der en sær form for system i rodet, det er de samme fejl man ser igen og igen.

Copy/Paste

Det er meningen der skal tænkes lidt over hvad man fylder i sin SPF record, en del vælger en Google søgning istedet, finder en ældgammel artikel om SPF records og kopierer noget derfra.
SPF records som starter med “v=spf1 a mx ptr” er der for det meste ikke tænkt meget over, de kan typisk godt tåle en kritisk gennemgang.
F.eks bør man ikke anvende ptr udtrykket i en SPF record.

Copy/Paste fra Microsoft Word

Lad være med at kopiere fra Word/Excel direkte ind i et DNS webinterface, det kan give nogle besynderlige resultater.
F.eks:

v=spf1 ip4:194.255.119.0/26 ip4:213.150.59.247/32 include:spf.comendosystems.com\226\128\147all

som nok i stedet for skulle have været:

v=spf1 ip4:194.255.119.0/26 ip4:213.150.59.247/32 include:spf.comendosystems.com -all

Kilde: Folketingets domæne ft.dk 14/7/2018

MX udtryk + G-Suite/Office365

Anvender du G-Suite eller Office365 til email, skal du have “include:_spf.google.com” eller “include:spf.protection.outlook.com” i din SPF record, et “mx” udtryk er fuldkommen overflødigt og bidrager kun til at øge antallet af DNS opslag som kræves for at evaluere din SPF record.
Der er en grænse på max 10, så det er en dårlig ide med overflødige udtryk.

Blind tillid til email service providers

Email service providers (3. parter) lever af at sende email, så det ville være naturligt at tro de har fuldkommen styr på samtlige email standarder incl. SPF.
De har de imidlertid ikke, faktisk kan jeg kun komme i tanke om en enkelt email service provider som formår at beskrive SPF rigtigt i sin dokumentation.
Hovedparten af alle email service providers kan ikke kende forskel på SenderId og SPF, og det til trods der er en ganske væsentlig forskel på hvordan de virker.
Som udgangspunkt, kan du regne med at email service providers beder dig lave ændringer i din SPF record som ikke har noget med SPF at gøre. Og ja, jeg ved det lyder helt skørt, men det bliver det ikke mindre rigtigt af.
Her kan du læse mere om SenderId vs. SPF.

Manglende oprydning

Indtil 2012 kunne man med rette være lidt bange for at rydde op/slette noget i en SPF record, man arbejdede lidt i blinde og kunne nemt komme til at slette noget som stadig var i brug.
Sørger man for at implementere DMARC har man ikke den slags problemer, så fortæller ens DMARC rapporter helt tydeligt hvad der er i brug.

Parkerede domæner

Mange firmaer ejer en stor samling domæner. Det kan dreje sig om lookalike domæner, produktnavne, gamle produktnavne, fremtidige produktnavne osv.
Ved at have domænerne registreret, men intaktive, beskytter man sig f.eks mod typosquatting.
De fleste firmaer glemmer desværre at beskytte domænerne mod email misbrug.
For et lookalike domænes vedkommende betyder det man nærmest giver de kriminelle en hjælpende hånd når de beslutter sig for at rette et phishing angreb mod firmaets kunder.
Her kan du læse om hvordan du beskytter et parkeret domæne

Mere end en SPF record

SPF standarden dikterer at man kun have en SPF record pr. domæne/subdomæne, så når man ønsker at tilføje noget, skal det tilføjes til den allerede eksisterende SPF record.

Test dine ændringer

Der findes masser af gratis værktøjer som på sekunder kan fortælle dig om du har lavet fatale fejl i din SPF record.
Personligt anvender jeg altid Dmarcians SPF Survey

Spørg hvis du er i tvivl

Internettet er, ud over at være arbejdsplads for kriminelle, distributionskanal for fakenews plus en masse andet skidt, også stedet hvor du kan finde flinke og hjælpsomme mennesker som gerne giver en hånd når du sidder og bøvler med et teknisk problem.

Læsestof om SPF:

Hjælper du kriminelle?

Donating to crime

Nej, du hjælper nok ikke de kriminelle med fuldt overlæg, men dårlig email sikkerhed kombineret med et par andre uhensigtsmæssigheder, kan gøre at du alligevel hjælper dem, eller ihvertfald gør deres arbejde betydeligt nemmere.

DMARC
Har du ikke implementeret DMARC på dit domæne, gør du det ekstremt nemt for kriminelle at sende forfalskede og særdeles vellignende emails med dit eget domæne som afsender.
En SPF record er i forhold til phishing værdiløs.
Din lokale ekspert som hårdnakket påstår en SPF record er løsningen på falske emails, ja ham må du bede om at læse SPF standarden lidt mere grundigt, der er noget helt grundlæggende han har misforstået.

Referencer
Er du et af de firmaer som skilter med dine B2B kunder og samarbejdspartere på din hjemmeside, har du givet de kriminelle endnu en hjælpende hånd. Med den information ved de også hvem de kan rette et spear phishing angreb imod.

Medarbejderoversigt
Er du derudover også et af de firmaer som har en medarbejderoversigt liggende på din hjemmeside, med titler, navne og emailadresser, så ved de kriminelle også præcis hvilken falsk identitet de skal antage.

Alt i alt er det ikke så svært utilsigtet nærmest at opfordre til kriminalitet. Der er ikke rigtig nogen lov som forbyder ovenstående scenarie, men er du glad for, eller måske ligefrem afhængig af dine kunder, vil jeg anbefale ikke at udsætte dem for fare som i sidste ende vil pege tilbage på dig.