Hyvämaineinen verkkotunnus tai jaettu lähetyspalvelu voi tulla osaksi väärinkäyttöä olevaa viestipolkua. Hyödyllinen kysymys ei ole, onko infrastruktuuri yleisesti luotettava. Kyse on siitä, oliko tämä viesti valtuutettu käyttämään todennettua identiteettiä. Todennus ja yritysvaltuutus vastaavat erilaisiin kysymyksiin.
Määritä uudelleen käytettävä auktoriteetti
Vaarana oleva postilaatikko voi lähettää tavanomaista todennettua reittiään. Liian laaja verkkovaltuutus voi sallia tahattoman lähteen. Välittäjä voi allekirjoittaa viestin hyväksyttyään sen riittämättömän spesifisen pääsysäännön mukaisesti. Näillä mekanismeilla on eri omistajat ja keinot. Älä kokoa niitä yhdeksi selittämättömäksi väitteeksi maineen kaappaamisesta.
Alkuperäinen BreakSPF-tutkimus tutkii sallivaa SPF kokoonpanot ja jaettu infrastruktuuri. Sen uhkamalli tekee pääsystä lähdeverkkoon keskeisen ehdon. Se on käyttöönottoraja, ei todiste siitä, että hyökkääjä voi väärentää niitä DKIM -allekirjoitus. BreakSPF-paperi, osa III. Käsittele paperin mittauksia historiallisena tutkimuksena, ei nykyisenä haavoittuvien palvelujen luettelona.
Rakenna tarkka uhkamalli
Kirjoita suojattu toimialue, todennettu tunniste, sallittu lähdejoukko, hyökkääjän ominaisuudet ja vastaanottajan päätös erikseen. Tässä rajoitetussa skenaariossa brand.test valtuuttaa 192.0.2.0/24 SPF :lle. Hyväksytty sovellus käyttää 192.0.2.10 , kun taas hypoteettinen tahaton vuokralainen voi olla peräisin 192.0.2.99 . Molemmat osoitteet ovat julkaistulla alueella. Se, onko tällainen vuokralaisen käyttöoikeus olemassa todellisessa palvelussa, vaatii erillistä näyttöä.
SPF tarkistaa lähteen valtuutuksen arvioidun identiteetin varalta. Se ei tunnista ihmistä jaetun IP:n takana. Jos ohittava SPF identiteetti on myös linjassa tekijän verkkotunnuksen kanssa, polku voi tyydyttää DMARC ilman DKIM. RFC 7208 ja RFC 9989. Onnistunut arviointi voi siis paljastaa, että oikeuksia on myönnetty liikaa, sen sijaan, että vastaanottaja olisi jättänyt huomioimatta hyväksymissääntöä.
Vertaa kolmea kirjallista lupatapausta
Oletetaan näkyvän osoitteesta alerts@brand.test , ei tyhjä POSTIA LÄHETTÄJÄ bounce@brand.test , ei DKIM -allekirjoitusta ja muuten kelvollinen DMARC arviointi. Vertaa hypoteettisia SPF tietueita v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Hyväksytty lähde 192.0.2.10 : sisältyy molempiin verkkoetuliitteisiin; SPF läpäisee ja linjaa brand.testin, joten kuvaava viesti läpäisee DMARC molemmissa tapauksissa.
- Tahaton lähde 192.0.2.99 : sisältyy /24, mutta ei /32; SPF läpäisee vain laajan ennätyksen. Jos DKIM -allekirjoitusta ei ole, määrätty DMARC tulos hyväksytään alle /24 ja epäonnistuu alle /32.
- Ulkopuolinen lähde 198.51.100.10 : ei sisälly kumpikaan etuliite; -all tuotot SPF epäonnistuu kummassakin tapauksessa. Jos DKIM allekirjoitusta ei ole, määrätty DMARC tulos on epäonnistunut molemmissa.
Nämä ovat kirjoitettuja etuliite-jäsenyys ja linjaus vähennykset, ei käynnissä oleva SPF jäsennin, DNS havainto tai BreakSPF:n toisto. Lähteen ohjaus oletetaan, ei esitetä. Ulkoista viestiä tai live-palvelua ei testattu. Paperin protokollien välinen tekniikka on tämän opetusesimerkin ulkopuolella.
Yksittäinen linjattu mekanismi voi täyttää viestin DMARC hyväksymisehdon. Tämä ei tee vain SPF:n käyttöönotosta riittävää: RFC9989 n osa 7.4 vaatii kelvollisen DKIM :n verkkotunnusten julkaisemiseen p=reject, ja osiossa 8 käsitellään täyttä osallistumista. Nämä ovat erillisiä käyttöönottotehtäviä, eivät ylimääräistä viestikohtaista pääsyporttia.
Korjaa vastuun raja
Ennen kuin rajaat todellista SPF tietuetta, inventoi jokainen laillinen lähettäjä ja noudata palveluntarjoajan tukemia määrityksiä. Oma lähde on hyödyllinen vain, jos se on todella yksinomainen ja sitä ylläpidetään. Varmista, että lähetyspalvelu sitoo asiakkaat heidän sallittuihinsa henkilöllisyyksiin; tarkista DKIM määritykset ja poista vanhentuneet oikeudet muutoksenhallinnan avulla.
Valvo reittikohtaisia vikoja muutoksen jälkeen, säilytä palautussuunnitelma ja dokumentoi tuntemattomat lähettäjät. Älä korvaa laajaa tietuetta tämän esimerkin arvatulla IP-luettelolla. Oppitunti on sovittaa valtuutus yhteen todellisen palvelun omistajuuden kanssa, ei kopioida esittely- DNS tä tuotantoon.