Настройка файрвола MikroTik в RouterOS: правила filter, NAT и защита роутера

Firewall в MikroTik RouterOS опирается на connection tracking: роутер хранит состояние каждой сессии и позволяет описывать правила по роли пакета в соединении, а не по каждому пакету отдельно. Практический вывод простой: защита самого роутера живёт в цепочке input, транзитный трафик в forward, трафик от самого устройства в output. Правила читаются сверху вниз, срабатывает первое совпадение, всё, что ниже него, уже не проверяется.

NAT решает другую задачу. Таблица nat переписывает адреса и порты, но не фильтрует пакеты. Проброс порта с внешнего адреса на внутренний сервер без разрешающего правила в filter forward не заработает: после подмены адреса назначения пакет уходит в цепочку forward и там упирается в политику drop.

Ниже разобраны цепочки и таблицы, готовый набор правил filter для дома и офиса, защита от сканирования портов, ограничение ICMP и связка NAT с filter. Отдельный блок посвящён страховке от потери доступа: подключение WinBox по MAC-адресу, Safe Mode и экспорт конфигурации перед правками.

Как работает firewall в MikroTik RouterOS: цепочки и порядок правил

Firewall в RouterOS разбит на таблицы: filter, nat, mangle и raw. Для защиты роутера и проброса портов хватает первых двух. В filter три цепочки: input, forward, output. В nat две рабочие: dstnat и srcnat. Таблицы mangle и raw нужны для пометки пакетов и обхода connection tracking, в базовой настройке они не участвуют.

Цепочки input, forward и output: что и где фильтруется

Номер порта не определяет цепочку, цепочку определяет адрес получателя. WinBox слушает 8291, SSH 22, WebFig 80 и 443, API 8728 и 8729. Правило с этими портами в input закрывает управление роутером, такое же правило в forward закрывает доступ к серверу за роутером.

Синтаксис добавления правила одинаков во всех цепочках таблицы filter:

/ip firewall filter add chain=input action=accept connection-state=established,related comment="accept established"
/ip firewall filter add chain=forward action=accept connection-state=established,related comment="accept established fwd"
/ip firewall filter add chain=input action=drop comment="drop the rest"

Таблица nat устроена иначе. Цепочка dstnat переписывает адрес и порт получателя, цепочка srcnat подменяет отправителя. Правило masquerade для выхода в интернет выглядит так:

/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade comment="masquerade WAN"

Логика похожа на iptables в Linux, где есть цепочки INPUT, FORWARD, OUTPUT и таблица nat с PREROUTING и POSTROUTING. Смысл тот же, названия и синтаксис другие, поэтому механически переносить правила нельзя: разбор соответствий между iptables, nftables и ufw с примерами правил собран в отдельной шпаргалке по маршрутизации и NAT в Linux.

Главное, что стоит запомнить перед первой правкой: NAT и filter работают последовательно, но независимо. Подмена адреса произойдёт, а пакет всё равно отбросят, если в forward нет разрешения. И наоборот: разрешающее правило в forward без правила NAT бесполезно, потому что снаружи некуда прийти.

Порядок обработки правил и действие first match

RouterOS проверяет правила таблицы сверху вниз и останавливается на первом совпадении. Если ни одно правило не совпало, пакет пропускается: встроенной политики deny-by-default нет. Из этого следует, что фильтр становится запрещающим только после явного правила drop с действием по умолчанию.

Практические следствия first match:

• Разрешающие правила идут выше запрещающих. Правило drop all в первой строке разорвёт все соединения, включая вашу сессию WinBox.
• Правило accept connection-state=established,related должно стоять выше любых drop. Если его убрать вниз, часть ответов на уже открытые сессии начнёт отбрасываться и вы увидите «плавающие» обрывы соединений.
• Конкретные правила ставятся выше общих. Разрешение на порт 22 с одного адреса выше, чем разрешение SSH из всей подсети.
• Порядок меняется перетаскиванием строки в WinBox или через номер правила в CLI: /ip firewall filter move 5 destination=2.

Держите комментарии у каждого правила: comment="ssh from mgmt". Через месяц без них разобрать 40 строк почти невозможно. Группируйте правила по цепочкам и по смыслу, а не в порядке появления задач.

Отдельная тонкость: соединение, помеченное как fasttrack, обходит часть обработки фильтра, включая счётчики и правила mangle. Правило fasttrack-connection добавляют только для established,related и обязательно ниже защитных правил. Иначе трафик, который вы рассчитывали фильтровать, пройдёт мимо.

Подготовка к настройке firewall MikroTik без потери доступа

Самая частая аварийная ситуация: администратор применяет drop для input через WinBox по IP-адресу, разрешающего правила выше нет, сессия закрывается. Роутер продолжает работать, но попасть в него можно только с консоли или сбросом. Ниже набор действий, который исключает такой сценарий.

WinBox по MAC-адресу и Safe Mode как страховка

WinBox умеет подключаться по MAC-адресу на канальном уровне, без IP. В окне подключения адрес выбирается двойным щелчком в списке обнаруженных устройств, в поле Connect To подставляется MAC. Такой доступ работает внутри одного широковещательного домена, то есть со стороны LAN, а не из интернета.

Для работы MAC-подключения нужны две вещи: обнаружение соседей и MAC-сервер WinBox. В RouterOS 7 доступ регулируется списками интерфейсов:

/tool mac-server mac-winbox print
/ip neighbor discovery-settings print

Если устройство пропало из списка WinBox, проверьте, что интерфейс, к которому вы подключены, входит в разрешённый interface-list, а на нём не отключено обнаружение. Настройки MAC-сервера и обнаружения легко случайно сузить при «защите роутера», и тогда MAC-подключение перестанет быть страховкой.

Safe Mode откатывает изменения автоматически. В WinBox режим включается кнопкой Safe Mode или сочетанием Ctrl+X, в терминале командой /system safe-mode. Пока режим активен, все правки держатся в памяти без записи, и если сессия оборвётся, роутер вернётся к состоянию до входа в Safe Mode. Если всё прошло нормально, изменения фиксируются выходом из режима.

Перед правками сделайте две копии конфигурации:

/export compact file=before-firewall
/system backup save name=before-firewall

Файл .rsc из export compact читается глазами, переносится на другую версию RouterOS и восстанавливается командой import. Файл .backup хранит полный снимок, включая сертификаты и пароли, но привязан к версии. Оба файла скачайте в Files и сохраните вне роутера.

Резервный путь доступа стоит продумать заранее: второй интерфейс в другой подсети, VPN, последовательная консоль или кнопка Reset на корпусе. Ещё один приём для тех, кто правит фильтр удалённо: правило-предохранитель удаляется через планировщик. Если задача не отменена вручную за 5 минут, скрипт отключает защитные правила:

/system scheduler add name=firewall-rollback interval=5m on-event="/ip firewall filter disable [find comment~\"tmp-\"]; /ip service enable winbox"

Создайте такое правило, примените правки, проверьте доступ и удалите планировщик. Такой предохранитель спасает при работе через VPN, когда MAC-подключение недоступно.

Разрешающие правила для управления роутером

Минимальный набор правил input, после которого можно включать запрет по умолчанию:

/ip firewall filter add chain=input action=accept connection-state=established,related comment="established"
/ip firewall filter add chain=input action=accept in-interface-list=LAN comment="allow LAN"
/ip firewall filter add chain=input action=accept protocol=icmp limit=10,20:packet comment="icmp limited"
/ip firewall filter add chain=input action=accept src-address=192.168.88.0/24 protocol=tcp dst-port=8291 comment="winbox from LAN"
/ip firewall filter add chain=input action=accept src-address=192.168.88.0/24 protocol=tcp dst-port=22 comment="ssh from LAN"
/ip firewall filter add chain=input action=drop comment="drop the rest"

Правило accept in-interface-list=LAN кажется избыточным, но без него перестанут работать DHCP-запросы клиентов, DNS на роутере и локальный трафик к шлюзу. Если LAN внутри RouterOS разбита на VLAN, каждой из них нужен свой interface-list.

Доступ по IP удобно ограничить и на уровне служб, тогда он не зависит от порядка правил и от того, кто правил фильтр последним:

/ip service set winbox address=192.168.88.0/24
/ip service set ssh address=192.168.88.0/24
/ip service disable telnet,ftp,www,api,api-ssl,www-ssl
/ip ssh set strong-crypto=yes

Открывать WinBox, SSH и WebFig из интернета без необходимости не стоит: это самые атакуемые порты на периметре. Доступ администратора снаружи лучше строить через VPN, а сами веб-интерфейсы сетевых устройств закрывать по правилам, которые разобраны в гайде по защите веб-интерфейсов роутера и серверов.

Типовой набор правил filter для защиты роутера MikroTik

Рабочая последовательность для цепочки input строится по одному принципу: сначала трафик, который точно нужен, затем явный запрет всего остального.

Базовые правила input: established, invalid, ICMP, управление

Действие drop выбирают вместо reject намеренно: reject отвечает ICMP-сообщением или TCP RST, то есть подтверждает существование узла и порта. Для периметра молчаливый drop информативнее для вас и бесполезнее для сканера.

Отдельный вариант, который экономит правила и убирает шум: разрешать из WAN только то, что связано с NAT, и не трогать остальное:

/ip firewall filter add chain=input action=accept connection-state=established,related comment="established"
/ip firewall filter add chain=input action=accept connection-nat-state=dstnat comment="allow dstnat replies"
/ip firewall filter add chain=input action=drop comment="drop all from WAN"

Правила forward: разрешаем только нужное

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

/ip firewall filter add chain=forward action=accept connection-state=established,related comment="established fwd"
/ip firewall filter add chain=forward action=drop connection-state=invalid comment="drop invalid fwd"
/ip firewall filter add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="LAN to WAN"
/ip firewall filter add chain=forward action=accept connection-nat-state=dstnat comment="published services"
/ip firewall filter add chain=forward action=drop comment="drop the rest fwd"

Правило connection-nat-state=dstnat пропускает только тот трафик, который был создан правилом проброса в nat. Это компактнее, чем перечислять каждый сервер отдельно, и не открывает ничего лишнего: пакет без соответствия в dstnat дальше не пройдёт.

Широкие разрешения в forward сводят защиту к нулю. Правило вида accept с protocol=tcp без указания адреса и порта означает, что вся внутренняя сеть доступна из интернета. Если такой трафик виден в счётчиках, его нужно сузить до конкретных адресов и списоков. Пример аккуратного разрешения для файлового сервера с фильтрацией по адресам клиентов разобран в материале про SMB-сервер на MikroTik.

Домашний и офисный роутер: чем отличаются наборы правил

Для домашней сети набор короткий: разрешить established,related, отбросить invalid, ограничить ICMP, разрешить LAN целиком, закрыть управление снаружи, отбросить остальное. Пробросы портов добавляются только под конкретную задачу: игровой сервер, камера, домашний файловый сервер.

Офисный вариант отличается тем, что правила перестают быть личным делом администратора. Каждое правило получает комментарий с датой и задачей, изменения согласуются, а удаление временных разрешений контролируется. В RouterOS 7 у правил есть время последнего совпадения, поэтому «мёртвые» правила можно находить по счётчикам и удалять без риска.

Защита от сканирования портов и ограничение ICMP в MikroTik

Сканер портов отличается от обычного клиента тем, что обращается ко многим портам одного адреса за короткое время. У этого поведения есть измеримые признаки: всплеск новых соединений с одного источника и попытки подключения к закрытым портам. Оба признака ловятся встроенными средствами RouterOS без сторонних решений.

Блокировка сканирования через address-list и rate limit

Схема состоит из двух частей: распознать источник и отбросить его трафик. Распознавание работает через matcher psd, который оценивает распределение попыток подключения по портам:

/ip firewall filter add chain=input protocol=tcp psd=21,3s,3,1 action=add-src-to-address-list address-list=port_scanners address-list-timeout=1d comment="detect port scan"
/ip firewall filter add chain=input src-address-list=port_scanners action=drop comment="drop port scanners"
/ip firewall filter add chain=forward src-address-list=port_scanners action=drop comment="drop scanners fwd"

Второй механизм считает новые подключения к служебным портам. Классическая схема с промежуточными списками даёт нарушителю три попытки, после чего адрес уходит в чёрный список на сутки:

/ip firewall filter add chain=input protocol=tcp dst-port=22,8291 src-address-list=ssh_stage3 action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=1d comment="blacklist ssh"
/ip firewall filter add chain=input protocol=tcp dst-port=22,8291 src-address-list=ssh_stage2 action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=1m comment="ssh stage3"
/ip firewall filter add chain=input protocol=tcp dst-port=22,8291 src-address-list=ssh_stage1 action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=1m comment="ssh stage2"
/ip firewall filter add chain=input protocol=tcp dst-port=22,8291 action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=1m comment="ssh stage1"
/ip firewall filter add chain=input src-address-list=ssh_blacklist action=drop comment="drop ssh blacklist"

Пороги подбираются под нагрузку, и здесь легко перестараться. За домашним NAT может сидеть один публичный адрес на десятки устройств: лимит в 20 новых соединений за 10 секунд отбросит и добросовестных пользователей. Начните с мягких значений, наблюдайте счётчики неделю, потом ужесточайте. Готовые конфигурации с более агрессивными порогами и динамическим blacklist собраны в руководстве по защите от DDoS-атак в MikroTik RouterOS.

Список адресов удобен ещё и для обратной задачи: если вы точно знаете источник, свой адрес можно добавить в отдельный whitelist и проверять его первым правилом, выше всех блокировок. Тогда собственный мониторинг не попадёт под rate limit.

Ограничение ICMP без потери диагностики

Полный запрет ICMP выглядит как усиление защиты, а на практике ломает диагностику и path MTU discovery. Сканер портов по ICMP не работает, а вот поиск проблем с потерей пакетов без ping и traceroute превращается в угадывание. Разумный вариант: разрешить с ограничением скорости и отбросить избыток.

/ip firewall filter add chain=input protocol=icmp limit=10,20:packet action=accept comment="icmp limited"
/ip firewall filter add chain=input protocol=icmp action=drop comment="icmp over limit"
/ip firewall filter add chain=input src-address-list=white_list protocol=icmp action=accept comment="icmp from trusted"

Запись limit=10,20:packet читается как 10 пакетов в секунду с всплеском до 20. Правило для доверенных адресов ставится выше ограничения, чтобы мониторинг видел реальную картину потерь, а не последствия собственного rate limit.

Для IPv6 картина отличается: фильтр живёт в отдельной таблице /ipv6 firewall filter, и полностью блокировать ICMPv6 нельзя. Типы 133-136 отвечают за обнаружение соседей и автоконфигурацию адресов, тип 2 нужен для сообщения «пакет слишком большой», типы 128-129 за echo. Если отбросить их, IPv6 перестанет работать у клиентов, причём без внятных сообщений об ошибке.

NAT и проброс портов в MikroTik: связка с filter-правилами

NAT в RouterOS делится на две цепочки: dstnat меняет адрес получателя, srcnat меняет отправителя. Проброс портов делается в dstnat, выход в интернет для внутренних устройств в srcnat. Оба вида правил имеют счётчики пакетов и байт, поэтому проверяются так же, как правила фильтра.

Настройка dst-nat для проброса портов

Задача: внешний порт 8080 должен попадать на веб-сервер 192.168.1.10 порт 80. В WinBox правило создаётся в IP, Firewall, NAT, вкладка General и Action. В CLI это одна строка:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=8080 in-interface-list=WAN action=dst-nat to-addresses=192.168.1.10 to-ports=80 comment="web 8080 to 10:80"

Разбор полей:

• chain=dstnat - цепочка для переписывания получателя.
• protocol и dst-port - что именно пробрасываем. Udp тоже поддерживается, для игр и VoIP он нужен.
• in-interface-list=WAN - ограничение по входному интерфейсу. При динамическом адресе от провайдера это надёжнее, чем привязка к конкретному IP. Если адрес статический, можно указать dst-address, тогда правило не сработает при смене адреса.
• action=dst-nat с to-addresses и to-ports - куда перенаправлять внутри сети.

Правило без in-interface или dst-address сработает и для трафика из локальной сети, что даёт неожиданные эффекты. Проверяйте проброс с внешней стороны: с мобильного интернета или через внешний узел, а не с ноутбука внутри той же подсети. Пошаговый разбор проброса в другой платформе с примерами DNAT, masquerade и работы conntrack приведён в руководстве по пробросу портов через DNAT в nftables: логика та же, меняется синтаксис.

Порты управления пробрасывать не стоит. Правило для 8291 или 22 в dstnat открывает WinBox и SSH всему интернету, а сканеры находят такие порты за минуты. Если доступ снаружи нужен, стройте его через VPN или ограничивайте источник списком адресов.

Masquerade и src-nat для доступа в интернет

Masquerade подставляет адрес выходного интерфейса в поле отправителя. Это частный случай src-nat, удобный при динамическом адресе от провайдера:

/ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade comment="internet access"

При статическом внешнем адресе выгоднее классический src-nat: правило не пересчитывает адрес на каждый пакет и чуть меньше нагружает CPU.

/ip firewall nat add chain=srcnat out-interface=ether1 action=src-nat to-addresses=203.0.113.5 comment="static srcnat"

Два частых промаха с srcnat. Первый: правило без out-interface меняет адреса и для трафика между внутренними подсетями, из-за чего в логах появляются странные адреса источников. Второй: masquerade считают заменой фильтра и не добавляют правила в forward, после чего вся внутренняя сеть либо открыта, либо закрыта целиком.

Разрешающее правило forward для проброшенного порта

Ситуация, с которой начинается большинство обращений «проброс не работает»: правило dst-nat создано, счётчик пакетов растёт, а соединение не устанавливается. Причина в цепочке forward, где стоит политика drop. Пакет после подмены адреса обязан пройти forward, и разрешение нужно именно там.

/ip firewall filter add chain=forward action=accept connection-nat-state=dstnat comment="allow dstnat"

Правило ставится выше общего drop. Альтернатива для параноидального подхода: разрешать конкретные пары адрес-порт, например chain=forward protocol=tcp dst-address=192.168.1.10 dst-port=80 action=accept. Такой вариант точнее, но требует отдельной строки на каждый сервис.

Отдельный сценарий: внутренние клиенты должны открывать сервис по внешнему адресу. Тогда одного dst-nat мало, нужен hairpin NAT, иначе ответы сервера уйдут напрямую клиенту с внутреннего адреса и соединение оборвётся:

/ip firewall nat add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.1.10 protocol=tcp dst-port=80 action=masquerade comment="hairpin NAT"

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

Проверка и отладка правил firewall MikroTik

Отладка в RouterOS строится на счётчиках: каждое правило показывает, сколько пакетов и байт через него прошло. Если счётчик не растёт, правило не совпадает с трафиком, и искать ошибку нужно в условиях или в позиции строки.

Счётчики, логи и Torch для диагностики

В WinBox откройте IP, Firewall, Filter и включите колонки Packets и Bytes: они показывают попадания по каждому правилу. Сброс счётчиков делается правой кнопкой и Reset Counters, это удобно сразу после правок: вы видите только новый трафик.

Логирование включается флагом log у правила. Полезно добавлять префикс, чтобы отделить свои записи от остальных:

/ip firewall filter set [find comment="drop the rest"] log=yes log-prefix="FW-DROP:"
/log print where message~"FW-DROP:"

Действие log не прерывает обработку: пакет логируется и передаётся следующему правилу. Логирование всех отброшенных пакетов во время флуда загружает CPU и забивает диск, поэтому включайте его временно, на время разбора инцидента.

Для наблюдения за трафиком в реальном времени используйте Torch: он показывает активные потоки по интерфейсу с адресами и портами.

/tool torch interface=ether1 port=any
/tool sniffer quick interface=ether1

Sniffer показывает пакеты на интерфейсе, включая те, которые фильтр затем отбросит, поэтому он помогает отделить проблему маршрутизации от проблемы фильтрации. Torch работает на уровне соединений и лучше подходит для вопроса «кто сейчас грузит канал».

Если разбор логов занимает часы, выгрузку можно ускорить: часть администраторов отдаёт текстовые логи модели через API-агрегатор вроде AiTunnel, который даёт доступ к нескольким десяткам моделей через один интерфейс и оплату в рублях. Это вопрос удобства, а не обязательный шаг: счётчики и фильтры по message закрывают большинство задач.

Типичные ошибки при настройке firewall MikroTik

Проверку удобно вести по чек-листу: доступ к управлению есть, интернет с внутренних устройств работает, пробросы открываются снаружи, лишних слушающих портов на роутере нет. Команда /ip firewall filter print stats покажет счётчики всех правил разом, а /ip service print - какие службы управления включены.

Если нужен отдельный стенд для обкатки правил, разверните Cloud Hosted Router: CHR ставится на виртуальную машину, не требует железа и позволяет проверить конфигурацию до переноса на рабочий роутер. Подходящий вариант аренды виртуальных машин с почасовой оплатой и готовыми образами предлагает Timeweb Cloud. Один тестовый инстанс экономит вечер отладки на боевом устройстве.

Чек-лист безопасной настройки firewall MikroTik

1. Сделайте /export compact и /system backup, скачайте оба файла с роутера.
2. Подключитесь через WinBox по MAC-адресу на время правок и включите Safe Mode (Ctrl+X).
3. Проверьте, что MAC-server и обнаружение соседей разрешены на вашем интерфейсе.
4. Добавьте первым правилом accept connection-state=established,related в input.
5. Разрешите управление только с доверенных адресов или через VPN, добавьте правило для LAN.
6. Настройте ICMP с limit и отдельное разрешение для доверенных адресов и мониторинга.
7. Включите drop для input, предварительно убедившись, что DHCP и DNS для LAN не отвалились.
8. Настройте цепочку forward: established,related, drop invalid, LAN в WAN.
9. Создайте правила dstnat для пробросов и добавьте accept connection-nat-state=dstnat выше общего drop.
10. Настройте srcnat или masquerade для выхода в интернет и проверьте hairpin NAT, если сервис нужен изнутри по внешнему адресу.
11. Добавьте защиту от сканирования: psd-правило, address-list и drop для чёрного списка.
12. Проверьте счётчики правил, включите логирование на время тестов, затем выключите его.
13. Сохраните конфигурацию и запишите комментарии к каждому правилу: дата, задача, автор.

Инструкция проверена на RouterOS 7.x. Набор цепочек, действий и матчеров, включая connection-state, connection-nat-state, limit и psd, в ветке 6.4x тот же, но часть настроек служб и MAC-сервера задаётся через интерфейсы, а не через interface-list. Перед применением сверьте синтаксис с версией вашего устройства командой /system resource print и сохраните экспорт конфигурации: правки в firewall откатываются в одну команду только тогда, когда есть копия.