Forfalskning av avsenderadresser i e-post får stadig større utbredelse og skaper voldsomme problemer. Det er en velkjent teknikk som benyttes av spammere og nettfiskere for å få mottakere til å tro at meldingene kommer fra en pålitelig kilde. Det fører til at folk lures til å oppgi konfidensielle opplysninger som påloggingsinformasjon og forretningshemmeligheter. Samtidig stoler mange brukere ikke lenger på gyldige oppfordringer som eksempelvis å endre passord. Som mottiltak har e-postindustrien utviklet tre autentiseringsprotokoller for e-post som samlet sikrer at avsender er hva vedkommende utgir seg for å være. Disse er:
- Sender Policy Framework (SPF) eller rammeverk for avsenderpolicy
- DomainKeys Identified Mail (DKIM) eller e-post identifisert ved domenenøkler
- Domain-based Message Authentication, Reporting and Conformance (DMARC) eller domene-basert meldingsautentisering, rapportering og overensstemmelse
Her viser vi deg hvordan du setter opp de tre protokollene i Office 365, og hvordan du kan logge bruken av avsenderdomenene dine. Logging er særlig nyttig om applikasjoner eller tredjeparter sender på vegne av dine domener. Men først er det på sin plass med noe bakgrunn.
Sender Policy Framework (SPF)
Rammeverket for avsenderpolicy er en metode for å erklære og verifisere hvem som kan sende e-post fra et gitt domene. Mottakende e-postsystem sjekker om avsendende vert har lov til å sende e-post fra avsenderdomenet. Denne informasjonen lagres i en TXT-post i DNS-sonen. Det kan til en viss grad forhindre forfalskede avsenderadresser og bidra til at virksomhetens rykte og merkevare ikke lider skade.
DomainKeys Identified Mail (DKIM)
E-post identifisert ved domenenøkler foretar autentiseringen ved hjelp av asymmetriske kryptografiske nøkler. Avsendende vert signerer meldingshodet med sin private nøkkel. Mottakeren verifiserer signaturen og identifiserer om feltene er intakte. Den offentlige nøkkelen publiseres i DNS TXT-poster. Den digitale signaturen reduserer i høy grad faren for at meldingene dine blir behandlet som søppelpost.
Hvorfor tre autentiseringsprotokoller?
Dette har til dels historiske årsaker og skyldes svakheter ved SPF og DKIM. Sender Policy Framework – eller Sender Permitted From (avsender tillat fra), som var det opprinnelige navnet – var først ute og baserer seg på IP-adresser som tillatte avsendere. IP-adresser kan forfalskes. De mister sin gyldighet ved videresending av e-post. Et tredje problem er at e-post forvirrende nok har to avsenderadresser:
- En skjult MailFrom- eller konvolutt-adresse som angir faktisk avsender og hvor returmeldinger skal leveres.
- En From-adresse som identifiserer forfatteren. Vanlige svar går til denne e-postadressen. Det er denne adressen mottaker ser i e-postklienten sin.
Ovenfor vises hvordan en typisk phishing-e-post opererer. Det tydeliggjør også sammenhengen mellom MailFrom og From. Meldingen til venstre sendes fra sikkerhet@phishingcrooks.biz og utgir seg for å komme fra sikkerhet@sildeviga.no. Oppfordringen er naturligvis at du skal klikke på en falsk kobling og oppgi påloggingsopplysninger. SPF-kontrollen foretas mot det reelle avsenderdomenet, som her er phishingcrooks.biz. Dette domenet kan godt være registrert med en gyldig SPF. Da godtas det i SPF-kontrollen, men den vil feile på DMARC, der C’en står for Conformance (overenstemmelse). DMARC krever at det skal være samsvar mellom MailFrom og From – mer nøyaktig «på linje med» (alignment), noe som blant annet åpner for å godta subdomener. DKIM, som opererer med offentlige og private nøkler, skaper ingen problemer ved videresending. Men med DKIM kontrolleres vanligvis også bare MailFrom, som kan være helt legitim i en ellers illegitim melding.
Implisitt autentisering av e-post
Endelig angir verken SPF eller DKIM hva som skal skje med en melding som feiler på kontrollen. Her har det imidlertid etablert seg en praksis blant operatører og leverandører av e-posttjenester. En vanlig rutine er å sette dem i 14-dagers karantene for så å slette dem. Microsoft har gått ett skritt videre og foretar en eksplisitt og implisitt autentisering av all innkommende e-post.
Her ser vi analysen av en melding som Office 365 ikke godtar. Den ender opp i søppelpostmappen.
Meldingen er sendt fra Google, men med et egendefinert domene som verken har publisert en SPF- eller DKIM-post. Dermed feiler den på den implisitte autentiseringen. Legg for øvrig merke til at Microsoft anser det som fullstendig usannsynlig at det her dreier seg om et forsøk på phishing – Phishing Confidence Level = 0.
Innledende og standard domener i Office 365
Når du oppretter en ny leier (tenant) i Office 365, lages det et innledende subdomene under domenet onmicrosoft.com, som Microsoft styrer. Her er dette ayla.onmicrosoft.com. Så sant du bare benytter dette i din e-postadresse, behøver du ikke bry deg om verken SPF eller DKIM. Det er allerede satt opp for deg. Men høyst sannsynlig bruker du ditt eget registrerte domenenavn. La oss derfor gå videre med sildeviga.no for å illustrere gangen.
Oppsett av SPF-posten
Klikker du på ditt domene i Microsoft 365 administrasjonssenter (velg Oppsett, Domener), ser du de nødvendige DNS-innstillingene for Exchange Online. DNS-postene må settes til følgende verdier for at Office 365-tjenestene skal kunne kjøre problemfritt.
SPF-posten blir dermed sånn: «v=spf1 include:spf.protection.outlook.com -all». Det skal leses som: Bare godta Office 365 som legitim avsender, avvis alle andre, markert ved minus all. Meldinger sendt på vegne av ditt domene fra andre verter, vil feile på SPF-kontrollen. Vær oppmerksom på at SPF-posten ofte inneholder flere referanser, som til for eksempel tredjeparter som sender fra ditt domenet.
Oppsett av DKIM-postene
Figuren viser konfigurasjonen av Office 365-leieren med sildegiva.no som standard domene og ayla.onmicrosoft.com som innledende domene.
Om du klikker på ditt innledende domene, skal du som et minimum se de to velgerne (selector1 og selector2) for ditt innledende domene. Disse to TXT-postene har Microsoft satt opp for deg. Dét du nå må gjøre er å henvise til disse for ditt registrerte domene i DNS.
Syntaksen for DKIM
I eksempelet ovenfor må disse to DNS-oppføringene opprettes. Det er såkalte CNAME-poster
“selector1-sildeviga-no._domainkey.ayla.onmicrosoft.com” (Innhold) skal henvise til “selector1._domainkey.sildeviga.no” (CNAME)
“selector2-sildeviga-no._domainkey.ayla.onmicrosoft.com” (Innhold) skal henvise til “selector2._domainkey.sildeviga.no” (CNAME)
I redigeringskonsollet for DNS hos Uniweb er oppføringene satt opp som ovenfor. Dét du må gjøre, er å erstatte sildeviga-no/sildeviga.no med ditt registrerte domene og ayla med ditt innledende domene hos Microsoft. Om du har flere domener, gjentar du prosessen for dem.
Kontroll av DKIM-postene
Du kan kontrollere oppsettet ved hjelp av PowerShell. Strings inneholder den offentlige nøkkelen som mottakende vert laster ned for å bekrefte signaturen av meldingshodet. Microsoft opererer med to nøkler som endres og roteres én gang i uken.
Du kan også verifisere DKIM-oppføringene på MX Toolbox.
Aktivere DKIM i Office 365
Nå må du aktivere DKIM. Gå inn i Microsoft 365 administrasjonssenter. Klikk på Compliance (Sikkerhet og samsvar) under Administrasjonssentre. Utvid Trusselhåndtering og velg Policy. Klikk på DKIM:
Velg ditt eller dine domene(r) og klikk på Aktiver. Om DKIM ikke er satt opp riktig i DNS, vil du få en feilmelding.
Opprette DMARC-oppføringen
DMARC forutsetter at SPF og DKIM er på plass. Du kan naturligvis opprette posten direkte i DNS, men vår anbefaling er at du gjør dette via dmarcian, et nederlandsk selskap som har spesialisert seg på DMARC. En av de ansatte der sto bak utvikling av SPF, en annen var medutvikler av DMARC. Fordelen med å bruke dmarcian er rapportene du får. Du abonnerer på en tjeneste som er gratis for alle de første to ukene. Det kan holde for mange for å få en oversikt over sendte meldinger.
Gå til hjemmesiden for dmarcian: https://dmarcian.com. Klikk på Sign Up Free. Velg området for Europa, Afrika og Russland og klikk nok en gang på Sign Up Free. Fyll ut e-postadressen din. Angi et passord på minst åtte tegn. Velg en kontotype. Her velges Basic. De to andre er Plus og Enterprise. Oppgi navnet på virksomheten din og domene ditt. Du kan senere legge til flere. Klikk på Register. Du får tilsendt en e-post. Du logger deg inn på nettsiden din. Der får du oppgitt et forslag til oppføringene du skal legge inn i DNS-sonen din.
Konfigurasjon av DMARC
Til å begynne med ønsker du ikke å sette meldinger i karantene eller avvise dem. Med p=none er du bare ute etter rapportering. Rua angir at rapporteringen skal foregå via dmarcian.
Målet er naturligvis å avvise 100 prosent av meldingene som feiler i DMARC-kontrollen (p=reject; pct=100). Vær for øvrig oppmerksom på at Office 365 alltid bare setter denne type meldinger i karantene.
Eksempel på rapportering
Her vises en rapport over alle som sender på vegne av et domene. Her er det satt opp DKIM for Office 365, men det er flere som sender på vegne av domenet som bare har riktig SPF-konfigurasjon. Du kan klikke deg videre for å få nærmere informasjon. Fordelen med disse rapporten er at du får en fullstendig oversikt over alle som bruker domenet ditt som avsender. Det kan være webservere, applikasjoner og tredjeparter som MailChimp og HubSpot. Først når du har innlemmet alle disse i dine SPF- og DKIM-oppføringer, bør du sette opp DMARC med policyen avvis eller sett i karantene.
Konklusjon
Du er ved veis ende om du har fulgt alle anbefalinger her, dvs. du følger fortsatt med på rapportene og legger grunnlaget for å angi at alle som forsøker å forfalske dine avsenderadresser, skal slettes. Dermed har du sikret deg mot at nettfiskere kan bruke dine e-postdomener til å sende meldinger inn til deg. Alle som får meldinger fra deg, kan stole på at du er avsenderen. Sånn bidrar du til at e-post generelt blir en tryggere kommunikasjonskanal igjen. Du slipper også ulykkelige brukere som ved en misforståelse har latt seg lure av en phishing-e-post.
