Июньские патчи для Windows Server сломали VPN- и RDP-подключения

Июньские патчи для Windows Server сломали VPN- и RDP-подключения

Июньские патчи для Windows Server сломали VPN- и RDP-подключения

Обновления Microsoft, выпущенные в этом месяце для систем Windows Server, принесли с собой несколько неприятных багов, в числе которых проблемы с VPN- и RDP-подключениями. Баги затрагивают серверы, на которых включена служба Routing and Remote Access Service (RRAS).

Служба RRAS в Windows обеспечивает дополнительные возможности TCP-подключений и маршрутизации: удалённый доступ, site-to-site и т. п.

Неделю назад Microsoft в рамках очередного вторника патчей выпустила обновления KB5014746 (Windows Server 2019 2012 R2), KB5014692 (Windows Server 2019), KB5014699 (Windows Server 20H2) и KB5014678 (Windows Server 2022).

После установки этих апдейтов системные администраторы, работающие с Windows, обратили внимание на странности в поведении операционной системы. Например, серверы зависали на несколько минут, как только клиент подключался к RRAS-серверу по SSTP. Лечился этот баг только деинсталляцией вышеупомянутых обновлений.

После 14 июня также появились жалобы (123456) на потерю RDP- и VPN-подключений к серверам, на которых активирована RRAS. На форуме BleepingComputer один из администраторов писал, что у него не получается установить стандартную RDP-сессию.

Ещё один сисадмин на Reddit отмечал, что устранить проблемы можно только удалив июньские обновления. Однако стоит учитывать, что в этом месяце разработчики устранили уязвимость CVE-2022-30152 в Windows Network Address Translation (NAT), приводящую к DoS, поэтому откат открывает устройства для потенциальных атак.

ТСПУ начали перенаправлять DNS-запросы к Google и Cloudflare на НСДИ

С вечера 26 августа открытые DNS-запросы к серверам Google и Cloudflare начали перехватываться на российских технических средствах противодействия угрозам (ТСПУ). При обычном UDP-запросе к этим серверам для доменов YouTube и RuTracker возвращался ответ NXDOMAIN, будто таких адресов вообще не существует. Однако запрос по TCP успешно доходил до сервера и получал настоящие IP-адреса.

Об этом сообщил пользователь Хабра angry_agent, изучивший поведение адресов 8.8.8.8 и 1.1.1.1.

Анализ трафика показал ещё более интересную картину. Когда автор отправил DNS-запрос с малым значением TTL, в ответе ICMP TTL Exceeded обнаружился адрес 195.208.5.1, принадлежащий Национальной системе доменных имён (НСДИ), хотя исходный пакет предназначался для 8.8.8.8.

С произвольными UDP-пакетами такой подмены не происходило, система реагировала именно на DNS-трафик.

По версии исследователя, ТСПУ распознаёт открытый DNS-запрос и выполняет направленный DNAT: незаметно меняет адрес назначения и отправляет пакет на сервер НСДИ. Тот уже решает, какой ответ вернуть пользователю. При этом для оператора связи запрос выглядит направленным не к Google, а сразу к НСДИ.

Механизм оказался неидеальным. При быстрой отправке нескольких одинаковых запросов первый получал NXDOMAIN, а следующие всё-таки добирались до Google и возвращали реальные адреса. Кроме того, перенаправление срабатывало не для всех DNS-серверов.

Официального подтверждения такого механизма пока нет, выводы основаны на эксперименте одного пользователя. Напомним, вчера мы писали, что ользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare.

RSS: Новости на портале Anti-Malware.ru