glippenBestill test

E-postsikkerhet

Slik hindrer dere at noen sender e-post i deres navn

Uten dette kan hvem som helst sende e-post som ser ut som den kommer fra dere. Ikke en adresse som ligner, men deres egen. Det er den vanligste måten en faktura blir betalt til feil konto på.

Tre poster i DNS løser det, og de må settes opp i riktig rekkefølge. SPF sier hvilke servere som får sende. DKIM signerer meldingene. DMARC sier hva mottakeren skal gjøre når noe ikke stemmer, og er den eneste av de tre som faktisk stopper noe.

Regn med et par uker fra dere begynner til dere kan slå på full blokkering. Det meste av tiden går med til å oppdage hvilke systemer som sender e-post i deres navn uten at noen husket det: fakturasystemet, nyhetsbrevet, CRM-et, skjemaet på nettsiden.

6 steg · omtrent 30 minutter · oppdatert · skrevet av Erik Nilsen

Framgangsmåte

  1. Se hva dere har i dag

    Begynn med å lese det som allerede står der. Kommandoen under henter SPF-posten for domenet.

    dig +short TXT example.no | grep spf1

    Riktig svarÉn linje som begynner med "v=spf1". Kommer det ingenting, har dere ingen SPF-post. Kommer det to, er det en feil som må rettes først: mottakeren skal se bort fra begge.

  2. Sett opp SPF, og la den ende på -all

    SPF lister opp hvem som får sende på vegne av domenet. Den viktigste delen er den siste: haleleddet forteller mottakeren hva den skal gjøre med alt som ikke står i listen.

    «~all» betyr softfail, altså «dette ser feil ut, men slipp det gjennom likevel». «-all» betyr hardfail. Nesten alle stopper på softfail og tror de er ferdige. Det er de ikke: en softfail havner som regel i innboksen.

    Start med ~all mens dere kartlegger, og bytt til -all når dere er sikre på at listen er komplett.

    Pass påSPF tillater maksimalt ti DNS-oppslag. Hver include teller, og en include kan inneholde flere. Er dere over grensen, er posten ugyldig og alt faller tilbake til ingen SPF i det hele tatt.

  3. Slå på DKIM hos den som sender for dere

    DKIM signerer hver melding med en nøkkel, slik at mottakeren kan se at innholdet ikke er endret underveis. Nøkkelen slås på hos leverandøren, som Microsoft 365 eller Google Workspace, og de gir dere en post som skal legges i DNS.

    Sjekk etterpå at nøkkelen faktisk ligger der. Selektoren står i oppsettet hos leverandøren.

    dig +short TXT selector1._domainkey.example.no

    Riktig svarEn lang tekst som inneholder "v=DKIM1" og en "p=" med en nøkkel etter. Står det "p=" uten noe etter, er nøkkelen trukket tilbake, og signaturen er verdiløs selv om posten finnes.

  4. Legg til DMARC på p=none først

    DMARC binder de to sammen og sier hva mottakeren skal gjøre. Begynn på p=none, som ikke blokkerer noe. Den samler bare inn rapporter.

    Rapportene er hele poenget med dette steget. De forteller hvilke systemer som sender i deres navn, og det er nesten alltid flere enn noen husket.

    dig +short TXT _dmarc.example.no

    Riktig svarEn linje som begynner med "v=DMARC1;" og inneholder en "rua=mailto:"-adresse som rapportene sendes til.

  5. Les rapportene, så stram inn

    Når rapportene er stille i noen uker, altså når alt som sender for dere består, går dere videre til p=quarantine. Da havner det som ikke består i søppelposten.

    Siste steg er p=reject, som avviser meldingen. Det er her forfalskning faktisk slutter å virke. Ikke hopp rett hit: gjør dere det før kartleggingen er ferdig, forsvinner e-post dere trengte.

    Pass påDMARC krever at SPF eller DKIM stemmer overens med avsenderadressen mottakeren ser. Et system kan bestå SPF på sitt eget domene og likevel feile DMARC på deres. Det er den vanligste årsaken til at noe uventet slutter å komme frem.

  6. Steng domenene som ikke sender e-post

    De fleste virksomheter eier domener som aldri sender e-post: gamle navn, varemerker, skrivefeilvarianter. De er like brukbare for forfalskning som hoveddomenet, og de blir nesten alltid glemt.

    For dem er svaret kortere: en tom MX-post som sier at domenet ikke tar imot e-post, sammen med SPF -all og DMARC p=reject.

Feil

Det som faktisk går galt

Ikke de teoretiske feilene. Disse er de vi finner igjen og igjen.

  • To SPF-poster på samme domene. Mottakeren ser bort fra begge, og dere står igjen uten SPF uten at noe varsler om det.
  • SPF satt opp riktig, DMARC aldri lagt til. SPF alene stopper ingenting: uten DMARC er det opp til mottakeren om den bryr seg.
  • DMARC stående på p=none i to år. Det er et kartleggingssteg, ikke en løsning, og på p=none blokkeres ingenting.
  • En DKIM-post med tom p=. Den ser ut som om DKIM er på plass, og signaturen er ugyldig.
  • Underdomener som er glemt. DMARC på hoveddomenet dekker underdomener bare hvis sp= ikke sier noe annet.

Sjekk

Vil dere se om det virket

Den gratis sjekken leser dette utenfra sammen med resten av det som er synlig, og sier hva som fortsatt står igjen. Ingen innlogging, ingen e-postadresse.

Kjør den gratis sjekkenSe hva en full test dekker

Videre

Neste veiledning