E-postgodkjenning i EOP

Tips

Visste du at du kan prøve funksjonene i Microsoft 365 Defender for Office 365 Plan 2 gratis? Bruk 90-dagers prøveversjonen av Defender for Office 365 i Microsoft 365 Defender-portalen for prøveversjoner. Finn ut mer om hvem som kan registrere seg og vilkår for prøveversjonen her.

Gjelder for

E-postgodkjenning (også kjent som e-postvalidering) er en gruppe standarder som prøver å stoppe forfalskning (e-postmeldinger fra forfalskede avsendere). I alle Microsoft 365 organisasjoner bruker EOP disse standardene til å bekrefte innkommende e-post:

E-postgodkjenning bekrefter at e-postmeldinger fra en avsender (for eksempel laura@contoso.com) er legitime og kommer fra forventede kilder for det e-postdomenet (for eksempel contoso.com.)

Resten av denne artikkelen forklarer hvordan disse teknologiene fungerer, og hvordan EOP bruker dem til å sjekke innkommende e-post.

Bruke e-postgodkjenning for å forhindre forfalskning

DMARC hindrer forfalskning ved å undersøke Fra-adressen i meldinger. Fra-adressen er avsenderens e-postadresse som brukere ser i e-postklienten. Mål-e-postorganisasjoner kan også bekrefte at e-postdomenet har passert SPF eller DKIM. Domenet er med andre ord godkjent, og derfor er ikke avsenderens e-postadresse forfalsket.

DNS-poster for SPF, DKIM og DMARC (samlet kalt policyer for e-postgodkjenning) er imidlertid valgfrie. Domener med sterke e-postgodkjenningspolicyer som microsoft.com og skype.com er beskyttet mot forfalskning. Men domener med svakere policyer for e-postgodkjenning, eller ingen policy i det hele tatt, er hovedmål for å bli forfalsket.

Per mars 2018 publiserer bare 9 % av domenene til selskaper i Fortune 500 policyer for sterk e-postgodkjenning. De resterende 91% av selskapene kan bli forfalsket av en angriper. Med mindre en annen mekanisme for filtrering av e-post er på stedet, kan e-post fra falske avsendere i disse domenene bli levert til brukere.

DMARC-policyer for Fortune 500-selskaper.

Andelen små og mellomstore bedrifter som publiserer policyer for sterk godkjenning av e-post, er mindre. Og antallet er enda mindre for e-postdomener utenfor Nord-Amerika og Vest-Europa.

Mangel på sterke policyer for godkjenning av e-post er et stort problem. Organisasjoner forstår kanskje ikke hvordan e-postgodkjenning fungerer, men angripere forstår fullt ut, og de drar nytte av det. På grunn av phishing-bekymringer og begrenset innføring av sterke policyer for godkjenning av e-post, bruker Microsoft implisitt e-postgodkjenning til å sjekke innkommende e-post.

Implisitt e-postgodkjenning er en utvidelse av vanlige policyer for e-postgodkjenning. Disse utvidelsene inkluderer: avsenderens omdømme, avsenderlogg, mottakerlogg, atferdsanalyse og andre avanserte teknikker. I mangel av andre signaler fra disse utvidelsene merkes meldinger som sendes fra domener som ikke bruker policyer for e-postgodkjenning, som forfalsker.

Hvis du vil se Microsoft generelle kunngjøringen, kan du se A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365.

Sammensatt godkjenning

Hvis et domene ikke har tradisjonelle SPF-, DKIM- og DMARC-poster, kommuniserer ikke disse postkontrollene nok informasjon om godkjenningsstatus. Derfor har Microsoft utviklet en algoritme for implisitt e-postgodkjenning. Denne algoritmen kombinerer flere signaler til én enkelt verdi som kalles sammensatt godkjenning, eller compauth for kort. Verdien compauth stemples i overskriften Godkjenningsresultater i meldingshodene.

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Disse verdiene forklares i meldingshodet for godkjenningsresultater.

Ved å undersøke meldingshodene kan administratorer eller til og med sluttbrukere bestemme hvordan Microsoft 365 fastslo at avsenderen er forfalsket.

Hvorfor e-postgodkjenning ikke alltid er nok til å stoppe forfalskning

Bruk bare e-postgodkjenningsposter til å avgjøre om en innkommende melding er forfalsket, har følgende begrensninger:

  • Det sendende domenet kan mangle de nødvendige DNS-postene, eller postene er feil konfigurert.

  • Kildedomenet har riktig konfigurert DNS-poster, men dette domenet samsvarer ikke med domenet i Fra-adressen. SPF og DKIM krever ikke at domenet skal brukes i Fra-adressen. Angripere eller legitime tjenester kan registrere et domene, konfigurere SPF og DKIM for domenet og bruke et helt annet domene i Fra-adressen. Meldinger fra avsendere i dette domenet sender SPF og DKIM.

Sammensatt godkjenning kan løse disse begrensningene ved å sende meldinger som ellers ville mislykket e-postgodkjenningskontroller.

For enkelhetshet konsentrerer eksemplene nedenfor seg om resultater av e-postgodkjenning. Andre bakintelligensfaktorer kan identifisere meldinger som sender e-postgodkjenning som forfalsket, eller meldinger som mislykkes med e-postgodkjenning som legitime.

Det fabrikam.com domenet har for eksempel ingen SPF-, DKIM- eller DMARC-poster. Meldinger fra avsendere i det fabrikam.com domenet kan mislykkes med sammensatt godkjenning (vær oppmerksom på compauth verdien og årsaken):

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

Hvis fabrikam.com konfigurerer en SPF uten en DKIM-post, kan meldingen sende sammensatt godkjenning. Domenet som besto SPF-kontroller, er justert etter domenet i Fra-adressen:

Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

Hvis fabrikam.com konfigurerer en DKIM-post uten en SPF-post, kan meldingen sende sammensatt godkjenning. Domenet i DKIM-signaturen er justert med domenet i Fra-adressen:

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

Hvis domenet i SPF eller DKIM-signaturen ikke samsvarer med domenet i Fra-adressen, kan meldingen mislykkes med sammensatt godkjenning:

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Løsninger for legitime avsendere som sender uautorisert e-post

Microsoft 365 holder oversikt over hvem som sender uautorisert e-post til organisasjonen. Hvis tjenesten mener at avsenderen ikke er legitim, vil den merke meldinger fra denne avsenderen som en sammensatt godkjenningsfeil. Hvis du vil unngå denne dommen, kan du bruke anbefalingene i denne delen.

Konfigurere e-postgodkjenning for domener du eier

Du kan bruke denne metoden til å løse forfalskning på tvers av organisasjoner og forfalsking på tvers av domener i tilfeller der du eier eller samhandler med flere leiere. Det bidrar også til å løse forfalskning på tvers av domener der du sender til andre kunder i Microsoft 365 eller tredjeparter som driftes av andre leverandører.

Microsoft gir ikke detaljerte implementeringsretningslinjer for SPF-, DKIM- og DMARC-poster. Det er imidlertid mange opplysninger tilgjengelig på nettet. Det finnes også tredjepartsselskaper som er dedikerte til å hjelpe organisasjonen med å konfigurere poster for godkjenning av e-post.

Du kjenner ikke alle kilder for e-posten din

Mange domener publiserer ikke SPF-poster fordi de ikke kjenner alle e-postkildene for meldinger i domenet. Begynn med å publisere en SPF-post som inneholder alle e-postkildene du kjenner til (spesielt hvor bedriftens trafikk befinner seg), og publiser den nøytrale SPF-policyen ?all. For eksempel,

fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ?all"

Dette eksemplet betyr at e-post fra bedriftens infrastruktur vil sende e-postgodkjenning, men e-post fra ukjente kilder vil falle tilbake til nøytral.

Microsoft 365 behandler innkommende e-post fra bedriftens infrastruktur som godkjent. E-post fra uidentifiserte kilder kan fremdeles være merket som forfalskning hvis den mislykkes implisitt godkjenning. Dette er imidlertid fortsatt en forbedring fra all e-post som merkes som forfalskning av Microsoft 365.

Når du har kommet i gang med en SPF-tilbakefallspolicy ?allfor , kan du gradvis oppdage og inkludere flere e-postkilder for meldingene dine, og deretter oppdatere SPF-posten med en strengere policy.

Konfigurere tillatte avsendere av uautorisert e-post

Du kan også bruke innsikten om falsk intelligens og leierens tillatelses-/blokkeringsliste til å tillate avsendere å overføre uautoriserte meldinger til organisasjonen.

For eksterne domener er den forfalskede brukeren domenet i Fra-adressen, mens infrastrukturen for sending er én av følgende verdier:

  • KILDE-IP-adressen (delt opp i /24 CIDR-områder)
  • Organisasjonsdomenet for den omvendte DNS-posten (PTR).
  • Et bekreftet DKIM-domene.

Opprette en tillatelsesoppføring for avsender-/mottakerparet

Hvis du vil omgå filtrering av søppelpost, noen deler av filtreringen for phishing, men ikke filtrering av skadelig programvare for bestemte avsendere, kan du se Opprette lister over klarerte avsendere i Microsoft 365.

Be avsenderen om å konfigurere e-postgodkjenning for domener du ikke eier

På grunn av problemet med søppelpost og phishing anbefaler Microsoft e-postgodkjenning for alle e-postorganisasjoner. I stedet for å konfigurere manuelle overstyringer i organisasjonen, kan du be en administrator i avsenderdomenet om å konfigurere postene for e-postgodkjenning.

  • Selv om de ikke har behov for å publisere registreringer for e-postgodkjenning tidligere, bør de gjøre det hvis de sender e-post til Microsoft.

  • Konfigurer SPF til å publisere domenets sendende IP-adresser, og konfigurer DKIM (hvis tilgjengelig) til å signere meldinger digitalt. De bør også vurdere å konfigurere DMARC-poster.

  • Hvis de bruker masseavsendere til å sende e-post på deres vegne, må du kontrollere at domenet i Fra-adressen (hvis det tilhører dem) samsvarer med domenet som passerer SPF eller DMARC.

  • Kontroller at følgende plasseringer (hvis de bruker dem) er inkludert i SPF-posten:

    • Lokale e-postservere.
    • E-post sendt fra en programvare-som-tjeneste (SaaS)-leverandør.
    • E-post sendt fra en skytjeneste (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services osv.).
  • Konfigurer SPF-posten for små domener som driftes av en Internett-adresse, i henhold til instruksjonene fra Internett-leverandøren.

Selv om det kan være vanskelig i begynnelsen å få tilsendt domener for å godkjenne, etter hvert som flere og flere e-postfiltre begynner å søppelpost eller til og med avvise e-posten, vil det føre til at de konfigurerer de riktige postene for å sikre bedre levering. Deltakelsen kan også hjelpe i kampen mot phishing, og de kan redusere muligheten for phishing i organisasjonen eller organisasjonen som de sender e-post til.

Informasjon for infrastrukturleverandører (Internett-leverandører, ESP-er eller skyvertstjenester)

Hvis du er vert for et domenes e-post eller leverer vertsinfrastruktur som kan sende e-post, bør du gjøre følgende:

  • Sørg for at kundene har dokumentasjon som forklarer hvordan kundene skal konfigurere SPF-postene sine

  • Vurder å signere DKIM-signaturer på utgående e-post, selv om kunden ikke eksplisitt konfigurerer det (signer med et standarddomene). Du kan til og med dobbeltsignere e-postmeldingen med DKIM-signaturer (én gang med kundens domene hvis de har konfigurert den, og en gang til med firmaets DKIM-signatur)

Leveransen til Microsoft er ikke garantert selv om du godkjenner e-post med opprinnelse fra plattformen, men i det minste sikrer den at Microsoft ikke søppelpost i e-posten fordi den ikke er godkjent.

Hvis du vil ha mer informasjon om anbefalte fremgangsmåter for tjenesteleverandører, kan du se anbefalte fremgangsmåter for mobilmeldinger i M3AAWG for tjenesteleverandører.

Finn ut hvordan Office 365 bruker SPF og støtter DKIM-validering: