Как закрыть порт 53 (DNS) и защитить WinBox на MikroTik RouterOS

Как закрыть порт 53 (DNS) и защитить WinBox на MikroTik RouterOS от доступа из интернета​

При очередной проверке безопасности домашней сети я обнаружил, что на моём внешнем IP-адресе открыт порт 53, используемый DNS-сервером. Поскольку маршрутизатор MikroTik обслуживает локальную сеть и имеет прямое подключение к интернету, я решил разобраться, почему DNS доступен извне и как ограничить доступ к нему без нарушения работы локальных устройств.

Попутно выяснилось, что в конфигурации маршрутизатора отключены некоторые стандартные правила межсетевого экрана, а в системном журнале регулярно фиксируются неудачные попытки подключения к WinBox.

В этом руководстве я покажу, как закрыл внешние подключения к DNS и WinBox, проверил действующие правила Firewall и NAT, а также какие дополнительные проблемы безопасности обнаружил.

Содержание

1. Исходная конфигурация MikroTik​

На момент проверки использовалась следующая конфигурация:

• Операционная система: MikroTik RouterOS 6.49.22.
• Внешний интерфейс (WAN): ether1.
• Основная локальная сеть: 192.168.79.0/24.
• Дополнительная локальная сеть: 192.168.47.0/24.
• DNS-сервер MikroTik: включён.
• Управление маршрутизатором: WinBox, TCP-порт 8291.
• Доступ к интернету организован через NAT.

Маршрутизатор также обслуживает несколько устройств, для которых настроены пробросы портов, включая торрент-клиенты и сервер резервного копирования Proxmox Backup Server.

Поэтому при изменении правил Firewall мне было важно не нарушить работу локальной сети и уже настроенных сервисов.

2. Почему открытый DNS-порт представляет опасность​

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

• UDP/53 — основной протокол для большинства обычных DNS-запросов.
• TCP/53 — используется, в частности, для передачи больших ответов и некоторых других DNS-операций.

Если DNS-сервер маршрутизатора доступен из интернета и разрешает обработку запросов от произвольных клиентов, он может использоваться посторонними.

Основные риски:

• DNS Amplification — участие в DDoS-атаках с усилением трафика при определённых условиях.
• Посторонние DNS-запросы — использование ресурсов маршрутизатора внешними пользователями.
• Повышенная нагрузка — расход процессорного времени, памяти и сетевой пропускной способности.
• Расширение поверхности атаки — доступность дополнительной сетевой службы извне.

Важно: открытый порт 53 сам по себе ещё не означает, что DNS-сервер выполняет рекурсивные запросы для всех клиентов. Однако если такая возможность есть, доступ к серверу необходимо ограничить доверенными сетями.

3. Проверка настроек DNS​

Первым делом я подключился к MikroTik через терминал WinBox и выполнил:


В моём случае основные параметры выглядели следующим образом:


Особое внимание я обратил на параметр:


Он разрешает MikroTik принимать DNS-запросы от сетевых клиентов.

Это нормальная настройка, когда маршрутизатор используется в качестве DNS-сервера или DNS-кеша для устройств локальной сети.

Однако без соответствующих правил Firewall такая служба может оказаться доступной и через WAN-интерфейс.

Почему я не стал отключать allow-remote-requests?

Можно было выполнить:


Но в таком случае MikroTik перестал бы обслуживать DNS-запросы сетевых клиентов, включая устройства локальной сети.

Сам маршрутизатор по-прежнему смог бы использовать настроенные DNS-серверы, но компьютеры и другие устройства, использующие его IP-адрес для разрешения доменных имён, могли бы столкнуться с проблемами.

Поэтому я оставил параметр включённым и решил ограничить входящие подключения средствами Firewall.

4. Проверка существующих правил Firewall​

Для просмотра правил использовал:


В конфигурации обнаружилось уже существующее правило:


Это правило блокировало входящие UDP-запросы на порт 53, поступающие через внешний интерфейс ether1.

То есть UDP/53 уже был защищён соответствующим правилом.

Однако аналогичного правила для TCP/53 не оказалось.

Кроме того, стандартное правило:


было отключено.

Это означало, что в текущей конфигурации не действовал общий запрет на входящие подключения к самому маршрутизатору со стороны интерфейсов, не входящих в список LAN.

Важный нюанс: поскольку первоначальный тест доступности порта не указывал однозначно, по какому протоколу выполнялась проверка, одного результата «порт 53 открыт» было недостаточно для определения причины. Необходимо проверять TCP и UDP отдельно.

5. Закрываем TCP-порт 53​

Поскольку UDP/53 уже блокировался, мне оставалось добавить правило для TCP.

В терминале MikroTik я выполнил:


Команда выполнилась без ошибок.

Разберу основные параметры:

• chain=input — обработка трафика, адресованного самому маршрутизатору.
• action=drop — отбрасывание пакетов без отправки ответа.
• protocol=tcp — блокировка TCP.
• in-interface=ether1 — правило действует для пакетов, приходящих через внешний интерфейс.
• dst-port=53 — порт назначения 53.
• place-before=0 — помещение правила перед первым правилом в соответствующей таблице Firewall.
• comment — комментарий, позволяющий быстро идентифицировать правило.

Таким образом, правило было размещено в начале списка, перед существующими разрешающими правилами.

Важно: если подключение к интернету осуществляется через PPPoE, VLAN или другой логический интерфейс, вместо ether1 необходимо указать фактический входящий WAN-интерфейс. В моей конфигурации внешним интерфейсом являлся именно ether1.

6. Как закрыть UDP/53, если правила ещё нет​

На моём маршрутизаторе соответствующее правило уже существовало, поэтому повторно добавлять его не потребовалось.

Но для других конфигураций приведу команду:


В итоге для защиты DNS должны действовать два правила:


Оба правила ограничивают обращения к DNS-службе маршрутизатора через ether1.

При этом локальные DNS-запросы, поступающие через другие интерфейсы, продолжают обрабатываться в соответствии с остальными правилами Firewall.

7. Ошибка bad command name add​

Во время первоначальной настройки я столкнулся с ошибкой:


Она возникла после попытки выполнить команду:


Причина заключалась в том, что команда add была вызвана из корневого меню RouterOS.

В терминале MikroTik команды можно выполнять двумя способами.

Первый способ — перейти в нужный раздел:


Второй способ — использовать полный путь:


Я предпочитаю второй вариант, поскольку он не зависит от текущего раздела терминала и удобен при копировании команд.

8. Обнаружение попыток подбора пароля WinBox​

Пока я работал с настройками DNS, в терминале стали появляться сообщения о неудачных попытках авторизации:


Подобные сообщения повторялись регулярно.

Это означало, что неизвестные внешние клиенты предпринимали попытки авторизации в WinBox под учётной записью admin.

При проверке настроек служб я выполнил:


Оказалось, что службы Telnet, FTP, SSH, WebFig и API были отключены, но WinBox продолжал работать на стандартном порту 8291.

Само по себе использование WinBox не является проблемой. Опасность возникает тогда, когда к интерфейсу управления можно подключаться из недоверенных сетей.

Поэтому я решил дополнительно заблокировать подключения к WinBox через WAN.

9. Закрываем WinBox TCP/8291 со стороны интернета​

Я добавил следующее правило:


Правило блокирует входящие TCP-подключения к порту 8291 через ether1.

При этом доступ к WinBox из локальной сети сохраняется, если он разрешён остальной конфигурацией.

Внимание!

Если вы управляете маршрутизатором удалённо через интернет, применение такого правила может немедленно прервать подключение.

Перед изменением правил удалённого доступа необходимо убедиться, что имеется альтернативный способ управления маршрутизатором.

Для защиты от случайной потери доступа рекомендую использовать Safe Mode в WinBox. В терминале он включается сочетанием Ctrl+X или клавишей F4. При аварийном разрыве сеанса изменения, выполненные в Safe Mode, могут быть автоматически отменены.

10. Дополнительное ограничение доступа к WinBox​

Одного правила Firewall достаточно для блокировки указанного TCP-порта на внешнем интерфейсе, однако можно дополнительно ограничить список IP-адресов, с которых разрешено управление.

Например, если доступ к WinBox требуется только из основной локальной сети 192.168.79.0/24, можно выполнить:


После этого служба WinBox будет принимать авторизацию только от клиентов из указанной подсети.

Важно: команду следует использовать только в том случае, если администратор действительно подключается из этой подсети. В противном случае можно заблокировать собственный доступ.

Ограничение address на уровне службы является дополнительным механизмом безопасности и не заменяет правила Firewall.

11. Проверяем правила NAT​

После настройки блокировки я решил убедиться, что порт 53 не перенаправляется на какое-либо устройство локальной сети.

Для этого выполнил:


В моём случае присутствовали правила для следующих сервисов:

• Proxmox Backup Server — TCP.
• Торрент-клиенты — TCP/UDP.
• UPnP — динамическое перенаправление TCP/UDP.
• Masquerade — трансляция исходящих подключений локальных устройств.

Действующих правил перенаправления TCP/53 или UDP/53 обнаружено не было.

Здесь важно понимать разницу между цепочками Firewall:

• input — пакеты, направленные непосредственно маршрутизатору.
• forward — пакеты, проходящие через маршрутизатор к другим устройствам.
• output — пакеты, созданные самим маршрутизатором.

Если бы порт 53 перенаправлялся средствами dst-nat на отдельный DNS-сервер в локальной сети, правила chain=input не обеспечили бы его защиту.

В таком случае необходимо было бы анализировать правила chain=forward и NAT.

12. Проверяем добавленные правила и счётчики​

После внесения изменений я использовал:


Эта команда позволяет посмотреть правила входящего трафика, включая их состояние, интерфейсы и применяемые действия.

Для просмотра статистики:


В выводе можно отслеживать:

• BYTES — количество байт, обработанных правилом.
• PACKETS — количество пакетов, совпавших с условиями правила.

При поступлении трафика, соответствующего условиям блокировки, счётчики должны увеличиваться.

В ходе диагностики я также попробовал команду:


Она вернула пустой результат.

Однако отсутствие строк в таком выводе само по себе не означает отсутствия правил Firewall. Поэтому для дальнейшей диагностики я использовал полный вывод с помощью print detail и print stats.

13. Проверка портов снаружи​

После настройки Firewall необходимо проверить доступность сервисов непосредственно из интернета.

Проверять лучше с другой сети или удалённого Linux-сервера, а не с устройства внутри LAN.

Проверка TCP/53:


Проверка UDP/53:


Проверка WinBox:


При использовании action=drop TCP-порт обычно определяется как filtered.

Для UDP результат может отображаться как open|filtered, поскольку сканер не всегда способен отличить фильтрацию UDP от отсутствия ответа работающей службы.

Дополнительно можно выполнить DNS-запросы:


И отдельно с использованием TCP:


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

После внесения правил я убедился, что команды добавления отработали без ошибок и что в действующих NAT-правилах нет проброса DNS. Однако результаты отдельного внешнего сканирования после изменений у меня на момент подготовки руководства отсутствовали, поэтому окончательную проверку доступности портов я выделяю как обязательный этап.

14. Дополнительные проблемы в конфигурации Firewall​

Помимо доступности DNS и WinBox, я обнаружил ещё два момента, заслуживающих внимания.

Отключено стандартное правило блокировки доступа с WAN​

В конфигурации присутствовало отключённое правило:


Это правило служит для ограничения входящего доступа к самому MikroTik со стороны интерфейсов, не относящихся к доверенной локальной сети.

В моей конфигурации оно было отключено.

В результате отдельные службы маршрутизатора потенциально могли быть доступны из интернета, если не существовало других запрещающих правил.

Для полноценной защиты в дальнейшем необходимо проверить всю цепочку input, определить разрешённые источники доступа и настроить запрет остальных нежелательных входящих соединений.

При этом нельзя бездумно включать стандартное правило: в некоторых конфигурациях маршрутизатору требуются входящие пакеты для VPN, DHCP и других сетевых функций.

Включён UPnP​

В таблице NAT я обнаружил динамические правила UPnP, созданные для торрент-клиента.

Например:


Аналогичное правило присутствовало для UDP.

UPnP позволяет программам автоматически создавать пробросы портов на маршрутизаторе.

Это удобно для торрент-клиентов и некоторых сетевых приложений, но увеличивает риски, поскольку приложения локальной сети могут открывать входящие соединения без ручного создания каждого правила.

Если UPnP не нужен, его можно отключить:


В моей конфигурации UPnP использовался торрент-клиентом, поэтому вопрос его отключения я оставил для отдельной проверки.

15. Что получилось в результате​

После анализа конфигурации я выполнил два основных изменения:

• Добавил блокировку TCP/53 на интерфейсе ether1.
• Добавил блокировку TCP/8291 для защиты WinBox от внешних подключений.

Существующая блокировка UDP/53 осталась без изменений.

При этом:

• DNS-сервер MikroTik остался включённым.
• Локальные DNS-запросы не были заблокированы новыми правилами для WAN.
• Пробросы портов для PBS и торрент-клиентов не изменялись.
• Конфигурация NAT осталась прежней.
• Были выявлены дополнительные риски, связанные с отключёнными правилами Firewall и использованием UPnP.

16. Полный набор команд​

Для удобства собрал команды, необходимые при аналогичной настройке.

Проверка DNS:


Проверка интерфейсов WAN и LAN:


Проверка существующих правил:


Блокировка UDP/53, если соответствующего правила ещё нет:


Блокировка TCP/53:


Блокировка внешнего WinBox:


Проверка результата:


Примечание: приведённые команды относятся к конфигурации, где внешним интерфейсом является ether1. Перед применением необходимо проверить собственную схему подключения и убедиться, что аналогичные правила ещё не существуют.

Заключение​

В результате этой проверки я убедился, что даже при наличии первоначально настроенного Firewall отдельные сетевые службы маршрутизатора могут оставаться доступными извне.

Особенно показательной оказалась ситуация с DNS: UDP/53 уже блокировался, но соответствующего правила для TCP/53 не существовало.

Не менее важным оказалось обнаружение попыток входа в WinBox. Если бы я ограничился только портом 53, доступ к административной службе маршрутизатора через WAN остался бы возможен на уровне существующей конфигурации.

Главный вывод, который я сделал: безопасность MikroTik необходимо проверять комплексно, а не ориентироваться исключительно на результаты сканирования отдельных портов.

Правильная конфигурация должна обеспечивать:

• Запрет нежелательных входящих подключений из интернета.
• Доступ к управлению только из доверенных сетей.
• Разрешение исключительно необходимых сервисов.
• Контроль правил NAT и UPnP.
• Регулярную проверку журналов авторизации.
• Проверку доступности портов с внешнего узла после изменения конфигурации.

Именно такой подход позволяет сократить поверхность атаки, не нарушая работу локальных устройств и серверов.

Официальная документация​

• MikroTik — DNS
• MikroTik — Firewall Filter
• MikroTik — IP Services
• MikroTik — Securing Your Router