Аудит firewall MikroTik: практическая методика

Начать с границ аудита, а не с drop-правила

Firewall нельзя оценить по скриншоту вкладки Filter Rules. Результат зависит от топологии, маршрутизации, interface lists, address lists, connection tracking, NAT, FastTrack, raw-таблицы и аппаратного offload. Сначала определяют зоны доверия: WAN, пользовательские VLAN, серверы, управление, гостевая и VPN-сети. Для каждой пары зон записывают разрешённые потоки и владельца исключения.

Отдельно фиксируют модель устройства, архитектуру, версию RouterOS и RouterBOARD firmware. Поведение и доступные свойства отличаются между выпусками RouterOS 6 и 7, поэтому переносить пример из старой статьи без проверки нельзя. Аудит также должен охватывать IPv6: правила IPv4 не фильтруют IPv6-трафик.

Цель первого прохода — понять действующую политику и найти доказуемые риски. Массовая нормализация комментариев или перестановка правил одновременно с аудитом затрудняет сравнение и откат. Изменения выполняют отдельными малыми пакетами после согласования ожидаемого трафика.

• Какие интерфейсы действительно выходят в интернет, включая резервные каналы.
• Откуда разрешено управление WinBox, SSH, API и веб-интерфейсом.
• Какие входящие публикации и межсегментные доступы необходимы.
• Используется ли IPv6, даже если его не настраивали намеренно.
• Какие правила создаются динамически VPN, UPnP или контейнерами.

Снять воспроизводимый снимок конфигурации

До анализа делают текстовый export с hide-sensitive и бинарный backup. Это разные инструменты: export читаем, сравним и пригоден для выборочного восстановления; backup зависит от платформы и версии и предназначен для возврата устройства целиком. Оба файла нужно вынести с маршрутизатора и хранить как секрет, поскольку даже скрытый export раскрывает адреса, имена интерфейсов и архитектуру сети.

Safe Mode снижает риск потерять удалённый доступ при интерактивной настройке, но не заменяет out-of-band канал и проверенный backup. Если сессия оборвётся, изменения Safe Mode откатятся не мгновенно во всех сценариях, а большое число действий может превысить внутренний лимит истории. Для критичного пограничного устройства планируют локальную консоль или резервный путь управления.

Собирают полный вывод правил с detail и stats, а также списки интерфейсов, адресов и сервисов. Счётчики пакетов помогают отличить активное правило от исторического мусора, но нулевой counter не доказывает ненужность: правило может обслуживать редкий аварийный или месячный процесс.

/system resource print
/system package update print
/export hide-sensitive file=before-firewall-audit
/system backup save name=before-firewall-audit
/ip firewall filter print detail stats
/ip firewall nat print detail stats
/ipv6 firewall filter print detail stats

Не публикуйте export в тикете без очистки. Параметр hide-sensitive уменьшает объём секретов, но не делает конфигурацию общедоступной.

Проверить защиту самого маршрутизатора в chain=input

Chain input обрабатывает пакеты, адресованные самому MikroTik. Базовая логика обычно принимает established, related и необходимые ICMP, отбрасывает invalid, затем разрешает управление только из явно доверенных источников и завершает цепочку запретом остального с недоверенных интерфейсов. Конкретный порядок зависит от сервисов маршрутизатора: DHCP, DNS, BGP, IPsec и VPN требуют точечных исключений.

Распространённая ошибка — правило accept для всей LAN, хотя пользовательская сеть не должна администрировать шлюз. Лучше выделить management-подсеть или address list и ограничить сами IP Services. Firewall и /ip service решают разные задачи: фильтр ограничивает сетевой путь, а настройки сервиса уменьшают поверхность прослушивания.

ICMP не следует запрещать целиком. Он нужен для диагностики и Path MTU Discovery; для IPv6 ICMPv6 участвует в работе протокола. Ограничивают нежелательные типы и частоту там, где это обосновано, сохраняя сообщения, необходимые сети.

/ip service print
/ip firewall filter print where chain=input
/ip firewall address-list print
/interface list member print

Разобрать транзитный трафик в chain=forward

Chain forward определяет, что может пройти через маршрутизатор. Проверку ведут по матрице зон, а не по принципу «интернет работает». Established и related обычно принимаются в начале, invalid отбрасывается, затем идут явные разрешения публикаций и межсегментных потоков. В конце должна быть понятная политика запрета, не зависящая от случайного отсутствия маршрута.

Для dst-nat публикаций важно проверить не только NAT, но и соответствующее разрешение forward. Условие connection-nat-state=dstnat позволяет сформировать общий контроль публикаций, однако его место и дополнительные ограничения по WAN, адресу источника и назначению должны соответствовать политике. Открытие порта в NAT без фильтра либо слишком широкое accept dstnat часто оставляет сервис доступным отовсюду.

Проверяют движение между VLAN. Если маршрутизатор является шлюзом сегментов, отсутствие явного запрета может разрешить пользователям обращаться к серверам, камерам или management-сети. Bridge traffic при включённом аппаратном offload способен не попасть в IP firewall; нужно понимать, где именно происходит L3-маршрутизация, а где L2-коммутация.

• Сопоставить каждое accept-правило с записью в матрице доступов.
• Проверить source и destination, protocol, ports, interfaces и address lists.
• Найти широкие правила, перекрывающие более точные запреты ниже.
• Проверить публикации с каждого WAN и hairpin NAT отдельно.
• Убедиться, что гостевая сеть не достигает внутренних и management-сегментов.

Учесть FastTrack, raw и порядок обработки пакета

FastTrack ускоряет established/related соединения, обходя часть стандартной обработки. Это полезно для производительности, но влияет на очереди, IPsec, учёт и наблюдаемость. Нельзя объявлять правило неработающим только потому, что его counters не растут после установления соединения: последующие пакеты могли уйти в fasttrack. Для диагностики временное отключение делают в согласованное окно и оценивают нагрузку CPU.

Raw-таблица применяется до connection tracking и может отбрасывать мусор дешевле, но ошибочное правило там труднее диагностировать по состояниям соединений. Mangle изменяет маркировку и маршрутизацию, из-за чего одинаковые на вид пакеты могут идти по разным каналам. Аудит фильтра без raw и mangle неполон на устройстве с policy routing или несколькими провайдерами.

Порядок правил критичен: обработка прекращается на первом подходящем terminal action. Недостижимые правила ниже широкого accept или drop создают ложное чувство защиты. Встроенный print stats и контролируемый тест с конкретного источника дают больше информации, чем визуальное чтение списка.

/ip firewall raw print detail stats
/ip firewall mangle print detail stats
/ip firewall filter print detail stats where action=fasttrack-connection
/tool sniffer quick interface=<интерфейс> ip-address=<тестовый_IP>
/tool torch interface=<интерфейс>

Torch и packet sniffer способны заметно нагрузить слабое устройство и показать чувствительные данные. Ограничивайте интерфейс, адрес, длительность и объём захвата.

Проверить NAT, сервисы и обходные пути

В srcnat ищут чрезмерно широкие masquerade, которые скрывают межсегментный трафик и затрудняют контроль. Masquerade подходит для динамического внешнего адреса, но для статического адреса src-nat предсказуемее. Изменение NAT может разорвать существующие соединения; после правок тестируют новые сессии, а очистку connection tracking выполняют только осознанно.

UPnP, cloud DDNS, MAC WinBox, MAC Telnet, Neighbor Discovery и bandwidth server могут создать путь, неочевидный при просмотре IP filter. Ненужные сервисы отключают, нужные ограничивают интерфейсами. Доступ по MAC особенно важен: IP firewall его не фильтрует, поэтому управление на недоверенном L2-сегменте нужно закрывать в настройках MAC server.

Проверяют автоматические механизмы и скрипты. Scheduler или provisioning может вернуть удалённое правило; VPN-пакет — создать динамический интерфейс; контейнер — слушать опубликованный порт. Для каждого исключения должен быть понятен источник конфигурации.

/ip firewall nat print detail stats
/ip upnp print
/ip cloud print
/tool mac-server print
/tool mac-server mac-winbox print
/system scheduler print detail

Не забыть отдельный firewall IPv6

RouterOS имеет отдельные /ipv6 firewall filter и address-list. Копия IPv4-правил механически не подходит: в IPv6 нет привычной необходимости в NAT, а Neighbor Discovery и ICMPv6 обязательны для нормальной работы. Если провайдер выдаёт prefix delegation, клиенты могут получить глобальные адреса даже при отсутствии запланированной публикации.

Если IPv6 используется, строят такую же матрицу зон, ограничивают input и forward, сохраняют необходимые ICMPv6 и проверяют выдачу адресов и DNS. Если IPv6 не используется, решение об отключении принимают явно и проверяют после обновлений и смены провайдера. Пустая IPv6-таблица при активной адресации — не нейтральное состояние.

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

• Проверить /ipv6 address, route, nd и dhcp-client.
• Проверить input и forward как отдельные цепочки.
• Не блокировать обязательные сообщения ICMPv6.
• Проверить доступность сервисов по глобальным адресам извне.

Внести исправления и доказать результат

Исправления начинают с наблюдаемого правила: добавляют его выше текущего разрешения с action=log или ограниченным accept для тестового источника, проверяют counters и только затем активируют запрет. Постоянное логирование каждого dropped packet на интернет-границе быстро забивает журнал и процессор. Используют отдельный log-prefix и rate limit либо краткое диагностическое окно.

Удалять старые правила сразу не нужно. Их отключают, добавляют комментарий с датой и причиной, наблюдают полный бизнес-цикл, а затем удаляют отдельным изменением. После каждого пакета сохраняют export и diff. Проверки выполняют с разрешённых и запрещённых источников: положительный тест без отрицательного не доказывает изоляцию.

Итог аудита содержит не просто перечень правил, а найденный поток, риск, подтверждение counters или packet capture, предлагаемое минимальное изменение и способ проверки. Пароли и полные конфигурации в отчёт не включают. Для критичных исключений назначают срок повторного просмотра.

1. Сохранить export и обеспечить резервный доступ.
2. Добавить одно точное правило в Safe Mode.
3. Проверить разрешённый сценарий и ожидаемый counter.
4. Проверить отказ с недоверенного источника.
5. Наблюдать CPU, logs и существующие соединения.
6. Зафиксировать diff и только потом перейти к следующему изменению.