Безопасность DNS и сети с нулевым доверием

DNS — это решение о доверии, а не просто поиск

Считайте DNS трубопроводом — и будете защищать не тот слой. Резолюция имени в адрес — это момент, когда ваша система выбирает, кому доверять, и классический DNS делает этот выбор по неаутентифицированному UDP открытым текстом. В продакшене доминируют два сценария отказа.

Отравление кэша. Резолвер, кэширующий ответы, можно обманом заставить закэшировать поддельный. Атака Камински 2008 года сделала это особенно жёстким: рассылая поддельные ответы для множества случайных поддоменов, атакующему нужно выиграть лишь одну гонку с легитимным ответом, а поскольку у ранней версии протокола был всего лишь 16-битный идентификатор транзакции (65 536 значений) и известный исходный порт, эту гонку можно было выиграть за секунды на быстром канале. Отравленная запись затем отдаётся всем нижестоящим клиентам, пока не истечёт TTL. Патч — рандомизация исходного порта, добавляющая ~16 бит энтропии, — превратил секундную атаку в статистически непрактичную, но это смягчение, а не исправление: ничто в протоколе так и не аутентифицировало ответ.

Атакующий на пути и привилегия резолвера. Любой между вами и резолвером — вредоносная Wi-Fi-точка, скомпрометированный роутер, враждебный провайдер — может прочитать каждое имя, которое вы ищете (утечка приватности), и переписать ответ (атака на целостность). Ваш резолвер — один из самых привилегированных хостов в стеке: он молча решает, куда пойдёт каждое ваше соединение.

DNSSEC и DoH защищают разные вещи

Их постоянно путают, и эта путаница рождает ложное чувство безопасности. Они решают ортогональные проблемы.

DNSSEC подписывает DNS-записи криптографией с открытым ключом, выстраивая цепочку доверия от корневой зоны до ответа. Он гарантирует целостность и подлинность: запись, которую вы получили, — это запись, опубликованная владельцем зоны, без изменений. Он ничего не шифрует — DNSSEC-запрос и подписанный ответ по-прежнему видны на проводе — и решает отравление кэша в корне, потому что поддельный ответ не пройдёт проверку подписи. Его цена реальна: развёртывание операционно тяжёлое (ротации ключей, разрыв цепочки доверия уводит зону в офлайн), а внедрение годами буксует значительно ниже половины зон, так что полагаться на него от края до края обычно нельзя.

DoH / DoT (DNS over HTTPS / over TLS) оборачивают запрос в шифрованный транспорт. Они гарантируют конфиденциальность и целостность транспорта от наблюдателя на пути: атакующий из кофейни больше не видит и не переписывает ваши запросы. Они не аутентифицируют саму запись — ваш резолвер всё ещё может вернуть отравленный или цензурированный ответ; вы просто перенесли своё доверие на того, кто держит резолвер. То, что DoH туннелирует DNS внутри обычного HTTPS (порт 443), также объясняет его спорность: он обходит сетевой мониторинг DNS, на который опираются корпоративные и родительские фильтры.

Зрелое прочтение: DNSSEC плюс шифрованный транспорт — это полный ответ — подпишите запись, чтобы её нельзя было подделать, зашифруйте запрос, чтобы его нельзя было прочитать или переписать в полёте. Каждое в отдельности оставляет реальную брешь. И ни то ни другое не отвечает на более глубокий вопрос, ради которого этот урок и существует: даже при идеально разрешённом, идеально зашифрованном соединении с правильным хостом — должен ли этот вызывающий вообще иметь к нему доступ? Вот где ломается модель периметра.

Почему периметр умер: нулевое доверие

Классическая модель — это замок: жёсткий сетевой периметр (файрвол, VPN) вокруг мягкой, доверенной внутренней части. Попал внутрь VPN — и ты «в корпоративной сети», что неявно означало доверенный — плоский east-west доступ к внутренним сервисам. У этой модели один катастрофический сценарий отказа: как только атакующий внутри, он владеет всем. Фишинговый ноутбук, скомпрометированная VPN-учётка подрядчика, одно проэксплуатированное краевое устройство — и плоская внутренняя часть превращается в площадку для свободного латерального движения. Вторжение SolarWinds 2020 года — канонический пример: доверенная внутренняя позиция превратила одну точку опоры в цепочке поставок в широкий охват.

Нулевое доверие, закреплённое в NIST SP 800-207, переворачивает допущение: никогда не доверяй, всегда проверяй. Доверенной сети не существует. Расположение запроса — внутри VPN или в Wi-Fi отеля — даёт ноль неявной авторизации. Каждый отдельный запрос к ресурсу аутентифицируется и авторизуется по собственным заслугам, оценивается против идентичности пользователя и устройства, а не IP, с которого пришёл. Доверие никогда не выдаётся по сетевому положению и непрерывно переоценивается, а не раздаётся один раз при входе.

Как нулевое доверие выглядит на практике: BeyondCorp и IAP

BeyondCorp от Google — эталонная реализация, рождённая из атаки Aurora 2009 года, прошедшей прямо сквозь их периметр. Ключевой компонент — identity-aware proxy (IAP): вместо VPN, который высаживает вас в сеть, каждый запрос к внутреннему приложению проходит через прокси, который в каждом запросе проверяет аутентифицированную идентичность пользователя, состояние устройства (управляемое ли оно, пропатченное, здоровое?) и политику авторизации для конкретного ресурса — и затем разрешает или запрещает. Нет сети, в которой можно было бы «находиться». Инженер попадает на внутренний дашборд из кафе ровно так же, как из офиса: через прокси, доказывая, кто он и с какого устройства, каждый раз.

Это схлопывает поверхность атаки так, как VPN никогда не мог. Украденная сессия или фишинговая учётка больше не отдают сеть; они отдают, самое большее, узкий набор ресурсов, на которые авторизована эта пара идентичность-плюс-устройство, перепроверяемый в каждом запросе — а состояние устройства может отозвать доступ в момент, когда машина выпадает из соответствия. Рукопожатие TLS 1.3 (RFC 8446), аутентифицирующее каждое из этих соединений, — криптографический фундамент, на котором стоит нулевое доверие: взаимная идентичность, прямая секретность и более быстрое рукопожатие делают проверку в каждом запросе достаточно дешёвой, чтобы делать её везде.