Prywatne nazwy VPN nie działają? Podejrzana jest ochrona przed rebindingiem DNS

Resolver odrzucający odpowiedzi z przestrzeni prywatnej psuje nazwy wewnętrzne, a nie tunel. Przeczytaj odpowiedź, zawęź wyjątek, zachowaj ochronę gdzie indziej.

W sieci LAN biura nazwa wewnętrzna odpowiada natychmiast. W chwili uruchomienia VPN przestaje działać, aplikacja zgłasza przekroczenie limitu czasu, a sam tunel bez skargi przenosi ruch. Zmienił się resolver i ten resolver ma własne zdanie o adresach prywatnych.

Ochrona przed rebindingiem istnieje, by zatrzymać jeden konkretny trik. Celowo opublikowana prywatna nazwa wygląda wystarczająco podobnie, żeby obrona zadziałała.

Przeczytaj odpowiedź, zanim przeczytasz politykę

Zapytaj nazwę u resolvera, który VPN rzeczywiście rozsyła, a nie tego, którego twój laptop używa w domu. Porównaj odpowiedź z rekordem, którego oczekujesz, i zanotuj, czy odpowiedź jest pusta, odrzucona, czy pełna publicznych adresów, których nikt nie planował.

Objawy nakładają się, więc o diagnozie decyduje kształt odpowiedzi. NXDOMAIN to brakujący rekord, REFUSED to reguła dostępu, publiczny adres dla nazwy wewnętrznej to błąd polityki lub split-DNS, a poprawny prywatny adres, którego klient nie może użyć, to zupełnie inny problem. Odrzucone połączenie ani zatrzymane żądanie samo w sobie niczego nie dowodzi, dlatego pierwszym poleceniem w takich zgłoszeniach powinno być zapytanie, a nie restart. Zapisz odpowiedź, zanim cokolwiek zmienisz.

Co obrona naprawdę zatrzymuje

Rebinding DNS działa przez zmianę tego, na co nazwa się rozwiązuje po tym, jak klient już jej zaufał. Strona ładuje się z nazwy kontrolowanej przez atakującego, odpowiedź przeskakuje na adres prywatny, a przeglądarka zostaje oszukana, by rozmawiać z czymś w sieci lokalnej, z czym nigdy nie zaakceptowałaby bezpośredniego połączenia. Obrona polega na odrzucaniu odpowiedzi wskazujących w przestrzeń prywatną, gdy resolver nigdy nie został poproszony o obsługę prywatnej przestrzeni nazw. Ta asymetria to cały atak.

dnsmasq dokumentuje dokładnie takie zachowanie, wraz z wyjątkami dla domen. W swojej stronie podręcznika opisuje rebind-domain-ok jako sposób nazwania domen, które mogą legalnie zwracać takie adresy. Czytaj to jako sygnał, że zamierzoną poprawką jest ograniczone zezwolenie, a nie globalny przełącznik.

Zawęź wyjątek do przestrzeni nazw

Najpierw napraw przestrzeń nazw, potem wyjątek. Potwierdź, że zawodząca nazwa należy do domeny kontrolowanej przez organizację i że rekord jest celowo utrzymywany. Nieoczekiwany adres, który jedynie przypomina znany zakres LAN, zasługuje na podejrzenie, a nie wyjątek, więc sprawdź właściciela strefy, zanim wpiszesz jakiekolwiek zezwolenie.

# 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

Następnie dodaj najwęższe zezwolenie obejmujące zamierzone nazwy: jedną domenę albo jedną delegowaną subdomenę, w konfiguracji resolvera, o którą pytają klienci VPN. Wyłączenie ochrony dla każdej nazwy na tym resolverze odbiera obronę wszystkim naraz, także nazwom, które nigdy jej nie potrzebowały.

Split DNS należy do tej samej decyzji. Jeśli prywatna przestrzeń nazw ma być odpowiadana tylko na wewnętrznym resolverze, opublikuj ją tam i przestań ją wyciekać do publicznych resolverów, aby wyjątek obejmował jedną ścieżkę, a nie każdą ścieżkę.

Przetestuj ponownie zasób i obronę

Zapytaj ponownie, potem połącz się z usługą i sprawdź, co widzi klient. Poprawna prywatna odpowiedź z działającą sesją oznacza, że wyjątek zadziałał. Poprawna odpowiedź z zatrzymaną sesją oznacza, że kolejnym podejrzanym jest trasa albo tożsamość usługi.

# 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

Przetestuj też nazwę publiczną przez ten sam resolver. Ochrona powinna nadal zachowywać się poprawnie dla nazw spoza wyjątku, a jeśli ten test zawiedzie, zmiana była szersza niż zamierzano. Nie ruszaj walidacji certyfikatów przez cały czas, bo nazwa, która rozwiązuje się poprawnie, wciąż musi pasować do certyfikatu przedstawianego przez usługę.

Zapisz w zgłoszeniu odrzuconą odpowiedź, domenę, resolver i właściciela polityki. To ten zapis zamienia tajemniczą wewnętrzną awarię w zmianę konfiguracji, którą ktoś może przejrzeć.

Powiązane artykuły