En sikkerhetsgateway kan vises som kilden sett av en rapporterende mottaker fordi den videresendte meldingen. Utseendet bekrefter ikke at den opprettet meldingen, eier avsenderapplikasjonen eller forårsaket en autentiseringsfeil. Undersøk ruten og punktet der meldingsinnholdet endret seg før du gjør en endring i DNS eller gateway-policy.
Etabler gateway-rollen
Referanser: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10.
Tegn den tiltenkte ruten fra søknad til endelig mottakssystem. Skille utgående relé, inngående gateway og videresendingsformidler. Registrer hvilken organisasjon som kontrollerer hvert hopp og hvilket hopp rapporteringsmottakeren faktisk så. Et kjent gateway-vertsnavn er bare en infrastruktur ledetråd inntil ruten er bekreftet.
Bevar kilde-IP, reporter, intervall, antall, forfatterdomene, konvoluttidentitet, DKIM domener og rapportert justering resultater. Sammenlign disse med autoriserte gateway-logger og pålitelige mottakerbevis. Begrens tilgangen til råmeldinger fordi de kan inneholde personlig eller konfidensielt innhold.
Finn signeringsgrensen
Referanser: RFC 6376 §3.4, RFC 6376 §3.7.
RFC 6376 definerer hvordan DKIM dekker utvalgte overskrifter og kanonisert hovedinnhold. En gateway som endrer dekket materiale etter signering kan ugyldiggjøre signaturen. Ikke alle endringer gjør det nødvendigvis: de signerte feltene, kanonisering og nøyaktig transformasjonssak.
Få trygge representantmeldinger fra rett før og etter den mistenkte transformasjonen når den er autorisert. Ta vare på de originale bytene og sammenlign bekreftelsesresultater, utvalgte overskrifter og kanoniserte hovedinndata. Ikke sammenlign skjermbilder eller omlagret tekst som om de beholder den signerte meldingen nøyaktig. Fastslå om signering skjedde før eller etter innsetting av bunntekst, omskriving av emne eller annen behandling.
Vurder SPF separat
Referanser: RFC 7208 §4.1, RFC 9989 §4.4, RFC 9989 §5.3.5.
En nedstrøms mottaker vurderer koblingskilden mot den relevante SPF identitet. Et relé kan derfor endre SPF situasjonen selv når DKIM overlever. Raw SPF suksess tilfredsstiller ikke DMARC hvis den autentiserte identiteten ikke er relatert til forfatterdomenet i henhold til gjeldende justeringsregel.
DMARC kan passere gjennom enten en passerende justert SPF eller DKIM bane. Unngå å behandle en mislykket signatur som bevis på generell DMARC feil uten å sjekke den andre mekanismen. På samme måte må du ikke behandle gatewayens egen urelaterte signatur som automatisk justert for den opprinnelige forfatteren.
Arbeid gjennom en kontrollert sammenligning
Hypotetisk scenario, ikke en utført test i denne anmeldelsen: en applikasjon signerer for example.com , så legger en utgående gateway til en ansvarsfraskrivelse. Anta at den mottakende testpostboksen viser en body-hash-feil for den signaturen. SPF passerer for et urelatert tjenestekonvoluttdomene. Uten annen justert overføringsmekanisme, mislykkes dette eksemplet DMARC .
Undersøkelsen vil måtte sammenligne beholdte før- og etterprøver og bekrefte at den dekkede kroppen endret seg ved inngangsporten. En foreslått reparasjon er å plassere autorisert justert signering etter den tiltenkte transformasjonen, ved å bruke en støttet design. Det er en kandidatløsning, ikke en påstand om at hver gateway tilbyr funksjonen eller at det alltid er trygt å flytte en signer.
Bekreft den valgte reparasjonen
Få de ansvarlige eierne til å godkjenne design og sikkerhetsimplikasjoner. Test selve ruten med representativt innhold, inkludert maler som utløser omskriving. Bekreft justert autentisering på en ekstern mottaker og verifiser forretningsflyten. Hold sikkerhetsskanning effektiv; ikke deaktiver kontrollene tilfeldig for å få en testbestått.
Lukk hendelsen med den bekreftede ruten, nøyaktig transformasjon, plassering av signering, beholdt testbevis og tilbakestillingskriterier. Hvis før-og-etter-beviset ikke er tilgjengelig, hold den mistenkte årsaken foreløpig og skaff deg en kontrollert reproduksjon. En gatewayetikett alene kan ikke rettferdiggjøre en konklusjon eller en bred SPF autorisasjon.