[ DNS ja verkkotunnukset ]

Eteenpäin vahvistettu käänteinen DNS : tarkista molemmat hakusuunnat

Suorita käänteisen DNS-tarkistuksen molemmat puolet ja ilmoita täsmäämät, yhteensopimattomuudet ja hakuvirheet.

EmailAuth -tutkimusryhmä

[Avainkohdat]

  • Vertaa normalisoituja IP-arvoja koko eteenpäin suunnatun osoitejoukon välillä.
  • Pidä aikakatkaisu, poissaolo ja epäsuhta eri tuloksina.
  • DNS yhteensopivuus ei takaa lähettäjän valtuutusta tai turvallisuutta.
Tällä sivulla

Käänteinen haku palauttaa IP-osoitteelle vaaditun isäntänimen. Eteenpäin vahvistettu käänteinen DNS sitten tarkistaa, palautuuko isäntänimi takaisin alkuperäiseen osoitteeseen. Toinen vaihe havaitsee yleisen epäjohdonmukaisuuden, mutta vastaavuus ei vahvista, että lähettäjä on luotettava tai valtuutettu käyttämään viestin Lähettäjä-toimialuetta.

Määrittele vertailu

Viitteet: RFC 1912 §2.1, RFC 3596 §2.1, RFC 4291 §2.2.

Ota havaittu SMTP -lähdeosoite aloitusarvoksi. Tee kysely sen PTR tietueesta. Kysy kullekin palautetulle isäntänimelle sopiva edelleenlähetysosoitetyyppi: A IPv4 -lähdettä varten ja AAAA IPv6 -lähdettä varten. Vertaa osoitearvoja käyttämällä IPv6 :n IP-jäsennintä, jotta vastaavia tekstimuotoja käsitellään samalla tavalla.

Tämän oppaan diagnostiikassa vahvistus tarkoittaa, että ainakin yksi palautetun isäntänimen edelleenlähetysosoitejoukko sisältää alkuperäisen IP-osoitteen. Säilytä isäntäkohtaiset tulokset sekä yhteenveto. Tämä on eksplisiittisesti määritelty diagnostinen sääntö, ei lupaus, että jokainen vastaanotin toteuttaa saman valintakäytännön tai tarkistaa jokaisen PTR tuloksen.

Pidä epäonnistumiset erillään

Viitteet: RFC 1035 §4.1.1, RFC 2181 §10.2.

Ei PTR vastausta, isäntänimi ilman vastaavaa osoitetta, DNS aikakatkaisu ja validointivirhe ovat eri havaintoja. Aikakatkaisu ei voi todistaa tietueen puuttumista. IPv4 A -osuma ei vahvista IPv6 lähdettä. Säilytä vastauskoodit ja ajoitus sen sijaan, että kokoat kaikki tulokset yhdeksi punaiseksi merkiksi.

Älä pysähdy ensimmäiseen isäntänimen palauttamaan osoitteeseen. Isännällä voi olla useita osoitteita, ja alkuperäinen osoite voi olla myöhemmin sarjassa. Kojelauta ei myöskään saa hiljaa hylätä useita PTR nimiä. Taustalla olevia tuloksia tarvitaan selittämään tarkasti, mikä vastaa.

Laske synteettinen testisarja

Tapaus A alkaa klo 192.0.2.25. PTR palaa smtp.example.com; tuo nimi on A setti 192.0.2.24, 192.0.2.25. Odotettu tulos on vahvistettu, koska alkuperäinen osoite on joukon jäsen. Tasa-arvoa koko sarjan kanssa ei vaadita.

Tapaus B käyttää samaa PTR ää, mutta A-sarja sisältää vain 192.0.2.24. Odotettu tulos ei vastaa. Tapaus C saa aikakatkaisun eteenpäinhaussa. Odotettu tulos on ratkaisematon, ei yhteensopivuus. Tapaus D alkaa klo 2001:db8::25 ja kohteen AAAA vastaus on 2001:0db8:0000:0000:0000:0000:0000:0025. Odotettu tulos varmistuu, kun molemmat on normalisoitu IPv6 osoitteiksi.

Toista nämä tapaukset valaisimen tai eristetyillä vyöhykkeillä. Tallenna kussakin tapauksessa lähde-IP, PTR vastaus, välitysvastaus, kyselytyyppi ja laskettu jäsenyystulos. Yksinkertainen toteutus jäsentää jokaisen osoitteen ja arvioi, onko lähde palautetussa joukossa, samalla kun käsitellään DNS virheet ennen kyseistä jäsenyysvaihetta. Nämä odotetut tulokset eivät väitä, että mitään tuotantovastaanotinta olisi testattu.

Korjaa omistajan puoli epäsuhta

Viitteet: RFC 1035 §3.5, RFC 8767 §4.

Jos PTR on väärä, työskentele käänteisalueen operaattorin kanssa. Jos edelleenlähetysosoite on väärä, työskentele isäntänimen valtuutetun DNS operaattorin kanssa. Jos molemmat ovat oikeita auktoriteetin suhteen, mutta eivät ratkaisijan suhteen, tutki välimuistia tai erilaisia ​​näkemyksiä. Säilytä todisteet molempiin suuntiin samanaikaisesti, jotta peräkkäistä muutosta ei diagnosoida väärin jatkuvaksi epäjohdonmukaisuudeksi.

Testaa lopuksi todellinen SMTP -reitti ja säilytä kaikki vastaanottimen vastaukset. Eteenpäinvahvistus on DNS tietojen johdonmukaisuusominaisuus. Hyökkääjät voivat käyttää yhteensopivia eteenpäin- ja taaksepäintietueita, ja laillisen palveluntarjoajan kokoonpano voi silti olla rikki. Käytä löytöä todennus- ja väärinkäytösten rinnalla, ei niiden sijasta.

Pidä todisteiden laajuus selkeänä

Neljä synteettistä tapausta voidaan tarkistaa pelkällä osoitejäsenyydellä ja normalisoinnilla: vahvistettu, epäsuhta, ratkaisematon ja vahvistettu. Paikallinen laskenta ei suorita PTR tai eteenpäinhakuja, käytä vastaanotinta tai mittaa mainetta.

[ Takeaway ]

Vertaa normalisoituja IP-arvoja koko eteenpäin suunnatun osoitejoukon välillä. Pidä aikakatkaisu, poissaolo ja epäsuhta eri tuloksina. DNS yhteensopivuus ei takaa lähettäjän valtuutusta tai turvallisuutta.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Laske osoitejäsenyys huolellisesti

Täysi palautettu osoitejoukko ja normalisoidut IP-arvot määrittävät ilmoitetun diagnoosituloksen.

Seuraavat vaiheet

  1. Arvioi kaikki palautetut osoitteet.
  2. Normalisoi IP-arvot ennen vertailua.
  3. Pidä virheet erillään ristiriitaisuuksista.

CISO / SecOps

Vältä maineeseen liittyviä johtopäätöksiä

Johdonmukaiset eteenpäin- ja taaksepäintiedot voivat olla olemassa myös väärinkäyttöön tarkoitetulle infrastruktuurille.

Seuraavat vaiheet

  1. Käsittele vahvistusta rajoitetun johdonmukaisuuden signaalina.
  2. Tarkista todisteet molemmista hakusuunnista.
  3. Tarkista todennus itsenäisesti.

Perustaja / ei-tekninen

Selvitä omistajuus molemmin puolin

Käänteinen ja eteenpäin suuntautuva epäsuhta voi vaatia koordinointia kahden palvelun omistajan välillä.

Seuraavat vaiheet

  1. Määritä molemmat DNS omistajat ratkaisemattomiin tapauksiin.
  2. Vaadi selkeä tulosmääritelmä.
  3. Vältä yhteen tarkastukseen perustuvia turvallisuusväitteitä.

[ UKK ]

Usein kysytyt kysymykset

Onko pelkkä PTR eteenpäinvahvistus?

Ei. Sinun on selvitettävä palautettu isäntänimi ja verrattava osoitteita.

RFC 1912 §2.1

Pitääkö välitysvastauksessa olla vain yksi osoite?

Ei. Alkuperäisen lähteen on oltava läsnä tämän diagnoosin mukaisessa osoitejoukossa.

Entä jos ensimmäinen palautettu osoite eroaa?

Tarkista koko sarja; vastausjärjestys ei ole todiste virheestä.

Tarkoittaako aikakatkaisu, että isäntänimi ei täsmää?

Se tarkoittaa, että tarkistus on ratkaisematon. Älä korvaa puuttuvaa näyttöä yhteensopimattomuudella.

Voiko A-tulos vahvistaa IPv6 lähteen?

Ei. Käytä asianmukaisia ​​AAAA-osoitteita kyseiselle IPv6 lähteelle.

RFC 3596 §2.1

Ovatko eri tavalla pakatut IPv6 merkkijonot aina erilaisia?

Ei. Jäsennä ja normalisoi ne ennen vertailua.

RFC 4291 §2.2

Todistaako vahvistus, että lähettäjä on turvassa?

Ei. Se määrittää DNS yhteensopivuuden, ei hyväntahtoisen tarkoituksen tai verkkotunnuksen valtuutuksen.

Kuka korjaa epäsuhta?

PTR operaattori tai lähtöalueen operaattori sen mukaan, mikä tietue on väärä.

[ Lähteet ]

Lähteet

  1. RFC 1035

    Osat §3.5 · §4.1.1

  2. RFC 1912

    Osat §2.1

  3. RFC 2181

    Osat §10.2

  4. RFC 3596

    Osat §2.1

  5. RFC 8767

    Osat §4

  6. RFC 4291

    Osat §2.2

[ Sanasto ]

Sanasto

Vahvistus eteenpäin
Tässä oppaassa ainakin yhdellä PTR kohteella on relevantti välitysosoitejoukko, joka sisältää alkuperäisen lähde-IP:n. Tämä on määritelty diagnoosi, ei yleinen vastaanottimen sääntö.
Normalisoitu IP-arvo
Jäsennetty osoitearvo, joka käsittelee vastaavia IPv6 tekstimuotoja samana osoitteena.

RFC 4291 §2.2

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta