Yksityiset VPN-nimet eivät toimi? Epäiltynä DNS-rebind-suojaus

Toimiston lähiverkossa sisäinen nimi vastaa heti. Heti kun VPN on päällä, se lakkaa toimimasta, sovellus ilmoittaa aikakatkaisusta ja tunneli itse välittää liikennettä valittamatta. Muuttunut asia on resolver, ja tuolla resolverilla on mielipide yksityisistä osoitteista.

Rebind-suojaus on olemassa yhtä tiettyä temppua varten. Tahallisesti julkaistu yksityinen nimi näyttää tarpeeksi samanlaiselta, ja puolustus laukeaa.

Lue vastaus ennen kuin luet käytäntöä

Kysy nimeä resolverilta, jonka VPN todella työntää, älä siltä, jota kannettavasi käyttää kotona. Vertaa vastausta odottamaasi tietueeseen ja pane merkille, onko vastaus tyhjä, hylätty vai täynnä julkisia osoitteita, joita kukaan ei suunnitellut.

Oireet menevät päällekkäin, joten vastauksen muoto ratkaisee diagnoosin. NXDOMAIN on puuttuva tietue, REFUSED on käyttösääntö, julkinen osoite sisäiselle nimelle on käytännön tai jaetun DNS:n virhe, ja oikea yksityinen osoite, jota asiakasohjelma ei voi käyttää, on täysin eri ongelma. Hylätty yhteys tai jumiutunut pyyntö ei todista itsessään mitään, minkä vuoksi ensimmäisen komennon missä tahansa näistä tiketeistä pitäisi olla haku eikä uudelleenkäynnistys. Kirjoita vastaus muistiin ennen kuin muutat mitään.

Mitä puolustus oikeasti pysäyttää

DNS-rebind toimii muuttamalla sitä, mihin nimi ratkeaa sen jälkeen, kun asiakasohjelma on jo luottanut siihen. Sivu latautuu hyökkääjän hallitsemasta nimestä, vastaus kääntyy yksityiseen osoitteeseen ja selain huijataan puhumaan jotain lähiverkossa olevalle, jonka kanssa se ei olisi koskaan hyväksynyt suoraa yhteyttä. Puolustus on hylätä vastaukset, jotka osoittavat yksityiseen avaruuteen, kun resolveria ei ole koskaan pyydetty tarjoamaan yksityistä nimiavaruutta. Koko hyökkäys on juuri tuo epäsymmetria.

dnsmasq dokumentoi juuri tuon käyttäytymisen, sekä toimialuekohtaiset poikkeukset. Sen käsikirjasivu kuvaa rebind-domain-ok:n tapana nimetä toimialueita, jotka voivat laillisesti palauttaa tällaisia osoitteita. Lue se merkkinä siitä, että aiottu korjaus on rajattu lupa, ei yleinen kytkin.

Rajaa poikkeus nimiavaruuteen

Korjaa ensin nimiavaruus, sitten poikkeus. Varmista, että epäonnistuva nimi kuuluu toimialueeseen, jota organisaatio hallitsee, ja että tietuetta ylläpidetään tarkoituksella. Odottamaton osoite, joka vain muistuttaa tuttua lähiverkon aluetta, ansaitsee epäilyksen eikä poikkeusta, joten tarkista vyöhykkeen omistaja ennen minkään luvan kirjoittamista.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

Lisää sitten kapein lupa, joka kattaa aiotut nimet: yksi toimialue tai yksi delegoitu alitoimialue sen resolverin kokoonpanossa, jolta VPN-asiakkaat kysyvät. Suojauksen poistaminen käytöstä jokaiselta kyseisen resolverin nimeltä poistaa puolustuksen kaikilta kerralla, myös niiltä nimiltä, jotka eivät sitä koskaan tarvinneet.

Jaettu DNS kuuluu samaan päätökseen. Jos yksityiseen nimiavaruuteen pitäisi vastata vain sisäiseltä resolverilta, julkaise se siellä ja lopeta sen vuotaminen julkisille reservereille, jotta poikkeus kattaa yhden polun kaikkien polkujen sijaan.

Testaa resurssi ja puolustus uudelleen

Kysy uudelleen, yhdistä sitten palveluun ja katso, mitä asiakasohjelma näkee. Oikea yksityinen vastaus ja toimiva istunto tarkoittavat, että poikkeus osui. Oikea vastaus ja jumiutunut istunto tarkoittavat, että seuraava epäilty on reitti tai palvelun identiteetti.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

Testaa myös julkinen nimi saman resolverin kautta. Suojauksen pitäisi toimia edelleen poikkeuksen ulkopuolisille nimille, ja jos tarkistus epäonnistuu, muutos oli laajempi kuin oli tarkoitus. Pidä varmenteen validointi koskemattomana koko ajan, koska oikein ratkeavan nimen on edelleen vastattava varmenteen, jonka palvelu esittää.

Kirjaa tikettiin hylätty vastaus, toimialue, resolver ja kuka käytännön omistaa. Juuri tuo kirjaus muuttaa salaperäisen sisäisen katkoksen kokoonpanomuutokseksi, jonka joku voi tarkistaa.