Частните имена през VPN не работят? Заподозрян е DNS rebinding

В офисната локална мрежа вътрешното име отговаря мигновено. Щом VPN се вдигне, то спира да работи, приложението съобщава за изтичане на времето, а самият тунел прекарва трафик без оплакване. Промени се resolver-ът и този resolver има мнение за частните адреси.

Защитата от rebinding съществува, за да спре един конкретен трик. Умишлено публикувано частно име изглежда достатъчно подобно и защитата се задейства.

Прочетете отговора, преди да четете политиката

Питайте името към resolver-а, който VPN-ът наистина подава, а не към този, който лаптопът ви използва вкъщи. Сравнете отговора със записа, който очаквате, и отбележете дали отговорът е празен, отказан или пълен с публични адреси, които никой не е планирал.

Симптомите се припокриват, затова формата на отговора решава диагнозата. NXDOMAIN е липсващ запис, REFUSED е правило за достъп, публичен адрес за вътрешно име е грешка в политиката или в разделения DNS, а правилен частен адрес, който клиентът не може да използва, е съвсем друг проблем. Отказаната връзка или застиналата заявка не доказват нищо само по себе си, затова първата команда в който и да е от тези тикети трябва да е справка, а не рестарт. Запишете отговора, преди да промените нещо.

Какво всъщност спира защитата

DNS rebinding работи, като променя към какво се разрешава дадено име, след като клиентът вече му е повярвал. Страница се зарежда от име, контролирано от нападателя, отговорът се обръща към частен адрес и браузърът е подмамен да говори с нещо в локалната мрежа, към което никога не би приел директна връзка. Защитата е да се отхвърлят отговори, сочещи към частното пространство, когато resolver-ът никога не е бил молен да обслужва частно пространство от имена. Цялата атака е точно тази асиметрия.

dnsmasq документира точно това поведение, заедно с изключения за отделни домейни. Неговата страница с ръководство описва rebind-domain-ok като начин да се именуват домейни, които законно могат да връщат такива адреси. Четете го като сигнал, че предвиденото решение е ограничено разрешение, а не глобален превключвател.

Ограничете изключението до пространството от имена

Първо оправете пространството от имена, после изключението. Потвърдете, че проблемното име принадлежи на домейн, който организацията контролира, и че записът се поддържа умишлено. Неочакван адрес, който само наподобява познат диапазон от локалната мрежа, заслужава подозрение, а не изключение, затова проверете собственика на зоната, преди да напишете каквото и да е разрешение.

# 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

След това добавете най-тясното разрешение, което покрива предвидените имена: един домейн или един делегиран поддомейн в конфигурацията на resolver-а, който клиентите на VPN питат. Изключването на защитата за всяко име на този resolver премахва защитата за всички наведнъж, включително за имената, които никога не са се нуждаели от нея.

Разделеният DNS е част от същото решение. Ако частното пространство от имена трябва да се обслужва само от вътрешния resolver, публикувайте го там и спрете изтичането му към публични resolver-и, така че изключението да покрива един път вместо всеки път.

Тествайте отново ресурса и защитата

Питайте отново, после се свържете с услугата и вижте какво вижда клиентът. Правилен частен отговор с работеща сесия означава, че изключението е сработило. Правилен отговор със застинала сесия означава, че следващият заподозрян е маршрутът или идентичността на услугата.

# 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

Тествайте и публично име през същия resolver. Защитата трябва да продължава да работи за имена извън изключението и ако тази проверка се провали, промяната е била по-широка от предвиденото. Пазете проверката на сертификата непокътната през цялото време, защото име, което се разрешава правилно, все още трябва да съвпада със сертификата, който услугата представя.

Запишете в тикета отказания отговор, домейна, resolver-а и кой отговаря за политиката. Този запис е това, което превръща мистериозно вътрешно прекъсване в промяна на конфигурацията, която някой може да прегледа.