Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Не удается заблокировать DNS-трафик после обновления UniFi OS до версии 4.2.12 с использованием Zone Based Firewall., UniFi Network
 
Привет,

После обновления моего UDM SE до UniFi OS 4.2.12 я больше не могу блокировать DNS-трафик через Zone Based Firewall. Региональное блокирование также не блокирует DNS-трафик к выбранным регионам.

Ранее у меня были рабочие правила, настроенные для блокировки устройств от обхода UDM для DNS-запросов путем блокировки всего DNS-трафика из внутренней зоны во внешнюю зону. Идея заключалась в том, чтобы трафик проходил через UDM через зону шлюза.

В качестве теста:

Я реализовал правило брандмауэра для блокировки всего трафика к 9.9.9.11 из моей внутренней зоны во внешнюю зону. Затем я попытался выполнить nslookup для различных веб-сайтов, и все вернули адреса. Затем я попытался пропинговать и перейти на 9.9.9.11 через веб-браузер, и оба действия не удались.

Я вернулся к старому брандмауэру от Zone Based Firewall из резервной копии от 25 апреля (в день, когда я обновил UniFi Network с v9.0.114 на v9.1.120) и создал правило LAN In для отбрасывания всего трафика к 9.9.9.11. При использовании старой конфигурации брандмауэра запросы nslookup не удавались из-за таймаута связи.

Я просмотрел Insight Flows и заметил, что DNS-трафик не имеет указанной назначенной зоны, в то время как, казалось бы, весь остальной трафик (например, HTTPS) указывает на назначение. Insight Flows также не показывает трафик "Out" через Primary (WAN1), как это делают другие типы трафика. Это кажется проблематичным, поскольку правила ZBF брандмауэра, похоже, требуют как исходную, так и назначенную зону для работы.

   

Я приложил несколько скриншотов выше с Insight Flows и правил ZBF. Лог Flows показывает блок для теста ping, а остальные — для nslookup тестов. Обратите внимание на назначенную зону, указанную для обоих. Я убедился, что DNS-сервер установлен в значение "auto" для сетей и столкнулся с этой проблемой независимо от того, включен ли Encrypted DNS или нет.

Какие идеи могут вызвать это и что я могу сделать, чтобы исправить это?
 
Я тоже вижу ровно то же самое в своей UDW-настройке. У меня включены блокировка рекламы и региональные ограничения. Неважно, какое правило файрвола установлено, мои IoT-устройства связываются с 1.1.1.1 и 8.8.8.8, обходя правила файрвола, даже если я блокирую 53-й порт или IP-адреса. Я пробовал создать правило DNat, чтобы направлять весь трафик 53-го порта на шлюз, но это тоже не помогло. IoT-устройства напрямую выходят на эти IP-адреса через 53-й порт. Я выяснил, что если отключить блокировку рекламы и фильтрацию контента в UDW, файрвол сможет заблокировать доступ к внешним DNS. Но если хоть одно из этих настроек включено, то это не работает. Вам когда-нибудь удалось решить эту проблему?
 
Нашел статью в центре помощи Ubiquiti "UniFi Gateway - Ad Blocking", которая, кажется, подтверждает мой предыдущий пост. Заметьте: клиенты, использующие собственные DNS-серверы, перенаправляются на DNS-сервер UniFi Gateway при включенном Ad Blocking. Полагаю, это реализует мою первоначальную цель — не допустить обход UDM и блокировку рекламы моими клиентами, поэтому моя неспособность блокировать DNS-трафик с помощью правил ZBF сейчас не является проблемой. Спасибо всем за вклад!
 
@travis.vitek Спасибо за обратную связь! У вас случайно не отключено блокирование рекламы UniFi во вкладке "Защита" в настройках безопасности? У меня нет Pi-Hole, я полагаюсь на UniFi для блокировки рекламы, поэтому я включил блокировку рекламы во всех 6 своих сетях.

Как еще один тест, я отключил блокировку рекламы в UniFi, и мои правила ZBF начали работать, а DNS-трафик к 9.9.9.11 был заблокирован. Хотя, как и вы, я не видел этот теперь заблокированный трафик в Flows, мои запросы истекали по времени, как показано на картинке ниже.

Затем я заметил свой нелокальный DNS-трафик в Flows, который не блокировался правилами брандмауэра, теперь тоже показывал выход через Primary (WAN1) и зону назначения External, в отличие от того, когда включена блокировка рекламы.





Я также протестировал настройку Masquerade NAT, когда блокировка рекламы UniFi была отключена, и она успешно работала. После подтверждения того, что это работает, я отключил правило перенаправления DNS NAT и включил обратно блокировку рекламы UniFi.

Затем я выполнил тесты nslookup для googleads.g.doubleclick.net и google-analytics.com, которые я знаю, что блокировка рекламы UniFi блокирует, и заметил, что, хотя запросы к 9.9.9.11 больше не истекали по времени, они возвращали адрес 0.0.0.0, и Flows указывали на то, что эти запросы на самом деле были заблокированы из-за блокировки рекламы.

Я получил захват пакетов с UDM сети Infrastructure, в которой находится мое устройство, и могу видеть трафик туда и обратно к 9.9.9.11, однако, мой захват пакетов на Primary (WAN1) не указывает на то, что трафик идет к 9.9.9.11. Кроме того, захваченные DNS-запросы были только к ui.com, google.com и www.microsoft.com, которые, я полагаю, для встроенных проверок задержки UniFi. Даже несмотря на то, что я также включил Encrypted DNS на UDM, я бы ожидал увидеть какой-то трафик, идущий к IP-адресу 9.9.9.11.

Я не совсем уверен, что из этого следует, но предполагаю, что это означает, что мои DNS-запросы к внешним серверам каким-то образом направляются через UDM в любом случае, поэтому, возможно, это не проблема. Я все еще интересно, почему эта функция ранее работала на UniFi OS v4.1.22 и теперь больше не работает для меня на v4.2.12, однако, основываясь на моих новых тестах, я не уверен, хочу ли я откатываться.
 
Добавил правило "Блокировать всё на 9.9.9.11" и вижу, что оно блокирует DNS-трафик. Поигрался немного, и по какой-то причине заблокированный трафик не отображается в Flows, но факт блокировки есть. Тем не менее, возможно, стоит рассмотреть возможность использования NAT-правил для решения этой проблемы более эффективно. Трафик, предназначенный для любых DNS-серверов, отличных от того, который вам нужен, можно перенаправлять на DNS-сервер по вашему выбору. Такие правила часто используются с PiHole, чтобы предотвратить обход управляемого DNS устройствами/пользователями.
 
Они внесли какие-то сомнительные изменения в сеть Unifi, особенно это касается правил перенаправления портов, которые я и перечислил. Загляните в мой профиль, чтобы почитать – это серьезно ставит под угрозу то, как это используется. Возможно, это еще один из таких выборов.
Страницы: 1
Читают тему (гостей: 1)