Firewall MikroTik: правила защиты корпоративной сети

Input, forward, output: куда действительно идёт пакет

• input: запрос к самому MikroTik — WinBox, SSH, DNS роутера, соединение к серверу VPN на нём.
• forward: запрос проходит через MikroTik — сотрудник открывает сайт, гость пытается обратиться к серверу, клиент идёт в другой VLAN.
• output: соединение создаёт сам роутер — запрос к DNS, NTP, журналам или серверу обновлений.

Блокировка в input не ограничивает транзит между VLAN. Правило forward не закрывает WinBox самого роутера. В примере output не фильтруется: ограничение исходящих соединений устройства проектируют отдельно. Официальный Packet Flow помогает определить нужную точку контроля.

Как пользоваться этим руководством

1. Проект: сегменты, адреса, владельцы сервисов и матрица соединений.
2. Каркас: четыре VLAN, собственные цепочки f68-input/f68-forward, отключённые entry-правила.
3. Расширения: только нужные шаблоны серверов, телефонии, VPN и защиты опубликованного сервиса.
4. Ввод в работу: проверка порядка, новый сеанс управления, положительные и отрицательные тесты, сохранение результата.

Не выполняйте главу с включением entry, пока не подготовили необходимые вашей компании расширения. В каталоге дополнительные разрешения создаются disabled=yes: создание правила не равно разрешению трафика. Для включения должны совпасть интерфейсы, IP-план, назначения и порты. Номера строк меняются; для размещения используем уникальные комментарии базового набора.

Сначала матрица доступа, затем команды

Адреса продолжают учебную схему VLAN: 10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24 и 10.10.99.0/24. Принтер — 10.10.30.50. Интерфейсы: vlan10-staff, vlan20-guest, vlan30-devices и vlan99-mgmt. Они должны быть уже правильно созданы; эта статья не настраивает bridge/VLAN tagging. Основа схемы — инструкция по разделению сети на VLAN.

Базовый набор ниже использует четыре уже настроенных VLAN. Далее он расширяется шаблонами для телефонии, серверов, резервного копирования, камер и VPN. Это два уровня одного проекта: сначала понятный каркас, затем необходимые дополнительные направления. Нельзя разрешать «весь LAN во весь LAN» ради одного обмена. Общий доступ сотрудников и гостей в интернет здесь выбран как политика примера, а не как контроль приложений или DLP.

Что такое LAN сотрудников и почему одного VLAN мало

LAN — общее название локальной сети, а не уровень доверия. Ноутбук сотрудника может быть заражён, телефон — устаревшим, а камера — обслуживаться внешним подрядчиком. Совместное подключение этих устройств к одному коммутатору не означает, что им нужен одинаковый доступ.

• Рабочие места: браузер, 1С, доменная инфраструктура и печать по списку. Администрирование серверов пользователю обычно не требуется.
• Гости и BYOD: отдельные SSID/VLAN, выход в интернет и ограничение пропускной способности. Для изоляции клиентов внутри SSID нужны также функции точки доступа.
• Телефония: телефоны обращаются к АТС, DNS/NTP и серверу provisioning; произвольный доступ в серверную сеть им не нужен.
• Серверы: опубликованные пользовательские интерфейсы отдельно от СУБД, гипервизоров и BMC/IPMI.
• Резервное копирование: заданные инициаторы и репозитории; отсутствие общего доступа к хранилищу из пользовательских VLAN.
• Камеры, принтеры, IoT: разделяйте по риску и потокам. Общий VLAN «всё оборудование» годится только для очень простой пилотной схемы.
• Управление: административные рабочие места, jump-host и сетевые устройства; доступ ограничивается источником и ролью.

Для малого офиса достаточно нескольких осмысленных сегментов. При росте важнее управляемость, чем число VLAN: у каждого сегмента должны быть назначение, владелец и понятные разрешения. Между хостами одного VLAN пакет может идти на L2 без IP firewall роутера. Для контроля внутри сегмента нужны host firewall, изоляция портов/клиентов, ACL коммутатора либо дальнейшее разделение.

VLAN задаёт границу широковещательного домена. Маршрутизация соединяет эти границы, а firewall определяет, какие соединения разрешены. Включение vlan-filtering не создаёт автоматически запрет межсетевого доступа. DHCP snooping, защита от подложенного шлюза и контроль access/trunk — отдельные меры на L2.

IP-план: подсети, шлюзы, DHCP и статические адреса

Ниже пример одного офиса. Адреса не являются обязательным стандартом: до выбора проверьте существующие площадки, облако, партнёрские VPN и домашние сети удалённых сотрудников. Совпадающие подсети через VPN не исправляются одним разрешающим правилом.

В таблице .1 означает адрес соответствующей подсети, например 10.10.50.1. Диапазоны резерваций и динамического пула не должны конфликтовать. Сохраните для каждого узла IP, MAC/идентификатор, VLAN, DNS-имя, назначение, ответственного и способ выдачи адреса. DHCP reservation удобна для телефонов и принтеров, но MAC не является надёжным доказательством личности.

• /24 = 255.255.255.0: 256 адресов, обычно 254 адреса хостов; шлюз тоже занимает адрес.
• /26 = 255.255.255.192: 64 адреса, обычно 62 адреса хостов. Подходит меньшему сегменту при согласованном запасе.
• /23 = 255.255.254.0: 512 адресов, обычно 510 адресов хостов. Нужна корректная граница сети, например 10.10.8.0/23.
• Не увеличивайте подсеть до /16 только ради запаса. Учитывайте широковещательный трафик, домен отказа и поддержку.

Сначала создают VLAN, адреса шлюзов, DHCP/relay, маршруты и DNS. Шаблоны firewall ниже не создают эти компоненты. Для телефонов DHCP option, LLDP-MED и VLAN на access-порту согласуют с коммутатором и устройствами; настройка одной АТС этого не заменяет.

Таблица сервисов: разрешаем направление, а не красивый номер порта

«Открыть 443» недостаточно: укажите источник, интерфейс входа, IP назначения, порт назначения, цепочку, состояние, комментарий и владельца разрешения. Исходный порт клиента обычно динамический; не задавайте src-port=443 для обычного браузера.

Для Active Directory не копируйте одну строку TCP389 как законченную настройку домена. RPC может использовать динамический диапазон, а состав обмена зависит от операций. Сверяйте официальную матрицу Microsoft, открывайте доступ между нужными участниками, а не всем VLAN ко всем портам.

Шаг 1. Проверьте текущую конфигурацию

/system resource print
/system package print
/interface print
/interface list print
/interface list member print
/interface bridge settings print
/ip address print
/ip route print
/ip firewall filter print detail
/ip firewall nat print detail
/ip firewall raw print detail
/ip firewall mangle print detail
/ipv6 settings print
/ipv6 address print
/ipv6 firewall filter print detail

Зафиксируйте, через какой интерфейс реально входит администратор и что считается WAN. При PPPoE WAN обычно логический pppoe-out1, а не нижележащий ether1. При нескольких провайдерах, VPN и VLAN провайдера выбор меняется. Проверяйте фактический маршрут пакета.

• Ищите существующие drop, jump, FastTrack, RAW notrack и правила NAT. Новые цепочки не отменяют их автоматически.
• Проверьте, не идут ли нужные потоки по bridge или hardware offload в обход ожидаемой CPU-обработки.
• Выясните IPv6: его наличие не определяется только настройкой IPv4. Этот каркас не устанавливает IPv6-политику.
• Не сбрасывайте заводской firewall и не делайте reset-configuration ради применения статьи.

Шаг 2. Подготовьте возврат и включите Safe Mode

До изменений сохраните текстовый экспорт и защищённую резервную копию штатными средствами RouterOS. Для текстового экспорта используйте уникальное имя:

/export file=before-firewall-20261108
/file print where name~"before-firewall"

Скачайте копии в защищённое хранилище. Текстовый export не содержит всех секретов, сертификатов и паролей пользователей и не заменяет полный план восстановления. Если нужен бинарный backup, создайте его с генерируемым паролем, сохранённым в менеджере паролей, и проверьте ограничения восстановления для вашей версии/устройства.

1. Подготовьте локальную консоль или независимый согласованный способ управления.
2. В WinBox включите Safe Mode; в терминале используйте Ctrl+X и проверьте признак SAFE.
3. Работайте небольшими партиями. Safe Mode ограничен историей изменений и не заменяет резервную копию.
4. При проверке держите исходный сеанс открытым и создавайте второй новый сеанс с разрешённого адреса.

Потеря соединения в Safe Mode и штатное завершение сеанса — разные события. Не считайте закрытие окна гарантированным откатом. Порядок подтверждения и отмены сверяйте с документацией Configuration Management. Изменения из других сеансов тоже могут попасть в окно Safe Mode.

Шаг 3. Создайте отдельные списки интерфейсов

Имена F68 используются только в этом примере. Сначала убедитесь, что они и цепочки f68-input/f68-forward не заняты. Если заняты — остановитесь и разберите существующий набор; повторный запуск создаст дубли. Замените pppoe-out1 своим реальным WAN.

/interface list
add name=F68-WAN comment="F68 internet interfaces"
add name=F68-LAN comment="F68 routed office VLANs"
add name=F68-MGMT comment="F68 management ingress"
/interface list member
add list=F68-WAN interface=pppoe-out1
add list=F68-LAN interface=vlan10-staff
add list=F68-LAN interface=vlan20-guest
add list=F68-LAN interface=vlan30-devices
add list=F68-LAN interface=vlan99-mgmt
add list=F68-MGMT interface=vlan99-mgmt
/ip firewall address-list
add list=F68-SUBNETS address=10.10.10.0/24 comment="F68 staff"
add list=F68-SUBNETS address=10.10.20.0/24 comment="F68 guests"
add list=F68-SUBNETS address=10.10.30.0/24 comment="F68 devices"
add list=F68-SUBNETS address=10.10.99.0/24 comment="F68 management"

Добавление bridge целиком в доверенный список может дать лишний доступ гостям. Для маршрутизируемых VLAN контролируйте логический L3-интерфейс, который видит firewall. Membership списка сам по себе не изолирует сеть: он используется условиями конкретных правил.

Почему порядок правил важнее их количества

Jump передаёт управление в пользовательскую цепочку. Return возвращает к следующему правилу вызывающей цепочки. В наших цепочках есть завершающий drop, поэтому неподходящий пакет не возвращается в старый разрешающий набор. Семантика цепочек описана MikroTik.

Не добавляйте новые запреты в самый низ после общего accept: они не увидят соответствующий трафик. И не ставьте drop всего в начало перед разрешением управления. Оба случая часто выглядят как «firewall не работает».

Перед расширениями: что значит disabled, place-before и маска /32

Все дополнительные filter-шаблоны ниже добавляются отключёнными и размещаются перед конкретным final drop. Убедитесь, что такой комментарий встречается ровно один раз. Если базовые цепочки ещё не созданы, сначала создайте их из следующих разделов, а к каталогу расширений вернитесь перед активацией.

/ip firewall filter print count-only where comment="F68 IN final drop"
/ip firewall filter print count-only where comment="F68 FW final drop"
/ip firewall filter print detail where comment~"^F68"

Для каждого count-only ожидается 1. Ноль означает, что точки вставки нет; число больше одного — дубли, которые надо разобрать. Команды add не идемпотентны. Повторное выполнение создаёт ещё одно правило, а не обновляет старое.

• src-address=10.250.68.20/32: конкретный адрес VPN-администратора, а не весь пул.
• src-address=10.10.10.0/24: сеть сотрудников, но только вместе с ожидаемым интерфейсом.
• dst-address-list: список назначений; перечень серверов в нём надо вести и пересматривать.
• connection-state=new: начало нового отслеживаемого потока; UDP тоже учитывается connection tracking.
• connection-nat-state=dstnat: факт трансляции назначения, а не доказательство доверия к сервису.
• disabled=yes: строка существует, но не принимает решений. Включать надо выбранные правила после проверки.

В RouterOS правило с отрицанием, например src-address=!10.10.10.0/24, означает «не из этой подсети». Ошибка в одном символе меняет смысл. Перед включением читайте всю строку, а не только Action.

Шаг 4. Подготовьте защиту самого роутера

Следующие команды создают правила в f68-input. Пока jump из input не добавлен и не включён, этот набор не обрабатывает обычные входящие пакеты. Не используйте его как завершённую защиту до активации и проверки.

/ip firewall filter
add chain=f68-input action=accept connection-state=established,related comment="F68 IN established related"
add chain=f68-input action=drop connection-state=invalid comment="F68 IN invalid"
add chain=f68-input action=accept in-interface-list=F68-MGMT src-address=10.10.99.0/24 protocol=tcp dst-port=22,8291 comment="F68 IN management"
add chain=f68-input action=accept protocol=icmp comment="F68 IN ICMP"
add chain=f68-input action=accept in-interface-list=F68-LAN src-address-list=F68-SUBNETS protocol=udp dst-port=53 comment="F68 IN DNS UDP"
add chain=f68-input action=accept in-interface-list=F68-LAN src-address-list=F68-SUBNETS protocol=tcp dst-port=53 comment="F68 IN DNS TCP"
add chain=f68-input action=accept in-interface-list=F68-LAN protocol=udp src-port=68 dst-port=67 comment="F68 IN DHCP server"
add chain=f68-input action=drop comment="F68 IN final drop"

В этом варианте MikroTik уже настроен выдавать DHCP и обслуживать DNS четырём локальным сетям. Правила filter не создают эти службы: отдельно проверьте /ip dns print, параметр allow-remote-requests и /ip dhcp-server print detail. Не включайте DNS-рекурсию для клиентов до проверки ограничения доступа; иначе можно получить открытый резолвер. Если эти роли выполняют другие серверы, соответствующие правила уберите из проекта до подключения цепочки. Для DHCP источник может быть 0.0.0.0, поэтому он не ограничен списком обычных адресов подсетей.

• Управление разрешено только с VLAN99 и адресов его подсети. Одного src-address без правильного интерфейса недостаточно.
• ICMP оставлен для диагностики и сетевых сообщений. Это не защита от объёмного DDoS; ограничение типов и частоты требует отдельной проверки PMTU и диагностики.
• Правил для сервера VPN здесь нет. Если администратор входит через него, до активации нужны отдельные разрешения транспорта VPN и трафика управления после расшифровки.
• WAN DHCP-клиент, IPsec, динамическая маршрутизация и другие роли роутера могут требовать дополнительных input-разрешений. Если они есть, этот набор пока неполон.

Состояние untracked специально не разрешено: пример предполагает отсутствие RAW notrack для этих потоков. При асимметричных маршрутах invalid может означать неполную видимость соединения; сначала исправляют архитектуру, а не копируют drop вслепую.

Шаг 5. Подготовьте правила между сетями

Сначала проверяем источник на каждом известном VLAN, затем состояния и точечные разрешения. Подмена адреса из VLAN99 на гостевом интерфейсе не должна давать административные права.

/ip firewall filter
add chain=f68-forward action=drop in-interface=vlan10-staff src-address=!10.10.10.0/24 comment="F68 FW staff source"
add chain=f68-forward action=drop in-interface=vlan20-guest src-address=!10.10.20.0/24 comment="F68 FW guest source"
add chain=f68-forward action=drop in-interface=vlan30-devices src-address=!10.10.30.0/24 comment="F68 FW device source"
add chain=f68-forward action=drop in-interface=vlan99-mgmt src-address=!10.10.99.0/24 comment="F68 FW management source"
add chain=f68-forward action=accept connection-state=established,related comment="F68 FW established related"
add chain=f68-forward action=drop connection-state=invalid comment="F68 FW invalid"
add chain=f68-forward action=accept in-interface=vlan10-staff src-address=10.10.10.0/24 out-interface-list=F68-WAN comment="F68 FW staff internet"
add chain=f68-forward action=accept in-interface=vlan20-guest src-address=10.10.20.0/24 out-interface-list=F68-WAN comment="F68 FW guest internet"
add chain=f68-forward action=accept in-interface=vlan10-staff src-address=10.10.10.0/24 out-interface=vlan30-devices dst-address=10.10.30.50 protocol=tcp dst-port=9100 comment="F68 FW staff printer"
add chain=f68-forward action=accept in-interface-list=F68-MGMT src-address=10.10.99.0/24 out-interface-list=F68-LAN protocol=tcp dst-port=22,443,8291 comment="F68 FW management services"
add chain=f68-forward action=accept in-interface-list=F68-MGMT src-address=10.10.99.0/24 out-interface-list=F68-LAN protocol=icmp comment="F68 FW management ICMP"
add chain=f68-forward action=drop comment="F68 FW final drop"

Принтер должен иметь нужный адрес и слушать TCP9100; для IPP/SMB, обнаружения и другой модели потребуется иной согласованный набор. Это пример точечного разрешения, не универсальная настройка печати.

У устройств VLAN30 нет нового произвольного выхода в интернет. Если камере нужен NTP, регистратор или облако производителя, добавьте конкретное разрешение до final drop, указав источник, назначение, протокол и порт. Если разрешён широкий выход в WAN, внутренние корпоративные сети, достижимые через этот WAN, сами собой не исключаются — учитывайте их в матрице и более ранних запретах.

Ответ на разрешённое соединение проходит по established/related. Это не означает, что устройство может начать любое новое соединение назад. Не открывайте обратное направление целиком ради ответного пакета.

Серверные VLAN: точечные разрешения и проверка источника

Расширенный IP-план не означает, что надо добавить все новые VLAN в F68-LAN: базовые input-правила DNS/DHCP и разрешения управления используют этот список. Для статического серверного VLAN это может дать ненужные службы. В расширениях указываем интерфейсы и назначения явно.

Для каждого нового VLAN добавьте проверку источника до established, затем нужные разрешения до final drop. Пример для уже созданного vlan50-servers:

/ip firewall filter
add chain=f68-forward action=drop in-interface=vlan50-servers src-address=!10.10.50.0/24 disabled=yes place-before=[find where comment="F68 FW established related"] comment="F68 EXT server source"
add chain=f68-forward action=accept in-interface=vlan10-staff src-address=10.10.10.0/24 out-interface=vlan50-servers dst-address=10.10.50.20 protocol=tcp dst-port=443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT staff 1C HTTPS"
add chain=f68-forward action=accept in-interface=vlan99-mgmt src-address=10.10.99.100/32 out-interface=vlan50-servers dst-address=10.10.50.20 protocol=tcp dst-port=22,443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT jump host web server"

Аналогичную проверку источника подготовьте для vlan40-voice, vlan60-backup и vlan70-cameras с их подсетями. Это защита от подмены между известными интерфейсами; она не решает все атаки внутри одного VLAN и требует пересмотра при DHCP relay, туннелях и необычной маршрутизации.

Веб-узлу 1С не нужен универсальный доступ во все серверы. Разрешите соединения к кластеру по фактической конфигурации, а от кластера к СУБД — отдельно. В RouterOS forward не увидит обмен двух серверов внутри одного серверного VLAN; ограничивайте его host firewall или отдельными сегментами.

DNS, DHCP и время: типовые причины «интернет есть, а ничего не работает»

Если сотрудники используют доменный DNS .10, запросы должны идти к нему, а не обязательно к роутеру. У гостевой сети может быть другой резолвер. Ответ DNS по TCP нужен не только редким исключениям; не ограничивайтесь UDP53.

/ip firewall filter
add chain=f68-forward action=accept in-interface=vlan10-staff src-address=10.10.10.0/24 out-interface=vlan50-servers dst-address=10.10.50.10 protocol=udp dst-port=53 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT staff DNS UDP"
add chain=f68-forward action=accept in-interface=vlan10-staff src-address=10.10.10.0/24 out-interface=vlan50-servers dst-address=10.10.50.10 protocol=tcp dst-port=53 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT staff DNS TCP"
add chain=f68-forward action=accept in-interface=vlan40-voice src-address=10.10.40.0/24 out-interface=vlan50-servers dst-address=10.10.50.40 protocol=udp dst-port=123 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT voice NTP"

При переносе DNS с роутера на сервер согласуйте DHCP options и input-разрешения. Для телефонии добавьте DNS к выбранному резолверу отдельными аналогичными правилами. DHCP server и DHCP relay — разные роли: шаблон input UDP68→67 из базовой схемы не является полной настройкой relay.

Разрешение внешнего интернета в базовом примере позволяет и обращения к сторонним DNS. Запрет обычного UDP/TCP53 сам по себе не контролирует весь DNS: есть DoH/DoT и приложения со встроенными резолверами. Корпоративную политику DNS подкрепляют настройками клиентов и подходящими средствами контроля.

IP-телефония: SIP отдельно, голос отдельно

Типичная схема: телефоны VLAN40 регистрируются на АТС 10.10.50.30, АТС работает с оператором. В учебном примере разрешён UDP SIP5060 и RTP10000–20000. Это условные параметры: сначала прочитайте transport и rtp.conf вашей АТС. TLS5061 шифрует сигнализацию, но не делает media автоматически SRTP.

/ip firewall filter
add chain=f68-forward action=accept in-interface=vlan40-voice src-address=10.10.40.0/24 out-interface=vlan50-servers dst-address=10.10.50.30 protocol=udp dst-port=5060 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT phones SIP to PBX"
add chain=f68-forward action=accept in-interface=vlan40-voice src-address=10.10.40.0/24 out-interface=vlan50-servers dst-address=10.10.50.30 protocol=udp dst-port=10000-20000 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT phones RTP to PBX"

Если АТС первой отправляет media в порт телефона, этот новый поток может не подходить под ответ уже существующего соединения. Нужен отдельный обратный шаблон: источник только АТС, назначение только voice-подсеть, UDP destination range — фактический диапазон телефонов. Не копируйте диапазон RTP АТС на телефоны автоматически. При direct media телефоны могут обмениваться голосом напрямую, а правила к АТС не контролируют этот путь.

• Регистрация есть, звука нет: проверьте SDP, внешний media-адрес, RTP/RTCP, NAT и направление потока.
• Односторонний звук: смотрите оба media-направления и адрес назначения, а не открывайте весь UDP.
• Сброс вызова: проверьте SIP-транспорт, NAT timeout, keepalive, re-INVITE и журнал АТС.
• Provisioning: разрешите только нужный сервер и протокол. Конфигурации телефонов могут содержать секреты.
• Качество: измеряйте потери, jitter и задержку. Очереди и DSCP помогают при конкуренции, но не исправляют обрыв или неверный NAT.

У оператора запросите отдельно адреса сигнализации и media, порты и резервные узлы. Для входящего транка используйте allowlist по согласованным сетям; не публикуйте SIP всему интернету. Параметры внешних адресов и NAT разбираются в документации Asterisk.

Проверьте /ip firewall service-port print detail where name="sip". SIP helper/ALG может влиять на NAT; отключение /ip firewall service-port set [find where name="sip"] disabled=yes — осознанный тест по требованиям АТС, а не обязательная команда для всех. Сохраните предыдущее значение, проверяйте новые вызовы и исключите зависимость от helper. Service ports не являются списком пользовательских пробросов.

VPN: отдельно внешний транспорт, отдельно права внутри туннеля

Работающий handshake не означает, что VPN-пользователь должен видеть всю компанию. Не добавляйте всех peers в доверенный LAN. В примере wg-office уже настроен: peer сотрудника 10.250.68.10/32 получает только HTTPS 1С; peer администратора 10.250.68.20/32 — отдельное разрешение управления.

/ip firewall filter
add chain=f68-input action=accept in-interface-list=F68-WAN protocol=udp dst-port=13231 disabled=yes place-before=[find where comment="F68 IN final drop"] comment="F68 EXT WireGuard transport"
add chain=f68-input action=accept in-interface=wg-office src-address=10.250.68.20/32 protocol=tcp dst-port=22,8291 disabled=yes place-before=[find where comment="F68 IN final drop"] comment="F68 EXT VPN admin router"
add chain=f68-forward action=accept in-interface=wg-office src-address=10.250.68.10/32 out-interface=vlan50-servers dst-address=10.10.50.20 protocol=tcp dst-port=443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT VPN employee 1C"
add chain=f68-forward action=accept in-interface=wg-office src-address=10.250.68.20/32 out-interface=vlan99-mgmt dst-address=10.10.99.100 protocol=tcp dst-port=22,443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT VPN admin jump host"

13231 — выбранный listen-port примера, а не обязательный порт WireGuard. Для статических площадок дополнительно ограничивайте внешний source IP. На общем WG-интерфейсе allowed-address каждого peer должен ограничивать его адрес/подсети без пересечений: иначе firewall-роль по VPN-IP недостаточна. Маршруты, обратный путь и разрешённые адреса клиента также проверяются отдельно. Документация WireGuard RouterOS различает транспорт и трафик туннеля.

Если понадобится DNS через VPN, добавьте точечное разрешение к выбранному DNS и передайте его клиенту. Split tunnel не направляет весь интернет через офис; full tunnel требует дополнительных маршрутов, разрешений WAN и NAT. Исходный каркас этих прав VPN-клиентам не выдаёт.

OpenVPN: внешний listener может быть TCP или UDP в поддерживаемой конфигурации RouterOS; порт/транспорт берут из фактической настройки. Правило input открывает только транспорт, а forward ограничивает выданные адреса и нужные ресурсы. Для динамических PPP-интерфейсов заранее проектируют стабильный признак: профиль, interface-list и адреса. Не используйте постоянно меняющееся имя сеанса как единственную основу правил.

Site-to-site IPsec: policy, FastTrack и исключение из NAT

Для policy-based IPsec обычно нужны IKE UDP500/4500 и, где используется, ESP (IP protocol 50). ESP — не TCP/UDP-порт50. L2TP1701 нельзя открывать всему WAN под видом защиты IPsec. Подсети удалённого офиса и селекторы policy должны быть известны заранее.

Фрагменты для удалённой подсети 10.20.50.0/24 показывают принцип; они отключены и не создают сам IPsec-туннель:

/ip firewall filter
add chain=f68-forward action=accept ipsec-policy=in,ipsec src-address=10.20.50.0/24 dst-address=10.10.50.20 protocol=tcp dst-port=443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT IPsec remote 1C"
add chain=f68-forward action=accept ipsec-policy=out,ipsec src-address=10.10.50.20 dst-address=10.20.50.0/24 protocol=tcp dst-port=443 disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT IPsec local initiated HTTPS"

Второе правило разрешает новое исходящее соединение веб-узла к HTTPS удалённой подсети, если это нужно матрице; для простого ответа на первое соединение оно не требуется. Не включайте его только ради симметрии строк. Внешние IKE/ESP-разрешения ограничьте peer-адресами и нужным WAN до input drop.

Перед masquerade может понадобиться srcnat action=accept для трафика, попадающего под нужную outbound IPsec policy, с точными источником и назначением. Убедитесь в порядке NAT и отсутствии более раннего общего srcnat. IPsec-потоки исключают из несовместимого FastTrack до ускорения; добавление accept после уже сработавшего FastTrack не исправляет путь. Проверяйте policy counters, installed SA, маршруты и новый прикладной сеанс. Примеры IPsec сверяют с выбранным типом туннеля.

Копии и камеры: не открываем всё из-за одного устройства

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

• Укажите, кто начинает соединение: агент → backup server либо backup server → узел; это зависит от продукта.
• Разрешите только нужные адреса/порты. SMB445 нужен не каждой системе копирования и не каждому участнику.
• Управление репозиторием — с jump-host, отдельные учётные записи и журналирование.
• Отдельно проверьте restore: рабочая схема копирования не гарантирует обратный транспорт.
• Копия вне площадки и защита от удаления решают другие задачи; один backup VLAN не делает копии неизменяемыми.

Камеры VLAN70 обычно общаются с NVR, DNS/NTP и, по решению владельца, строго определённым облаком. RTSP часто использует TCP554 для управления, а media может идти по UDP или interleaved TCP — уточните модель. ONVIF discovery и широковещательное обнаружение не обязаны проходить между VLAN, даже если разрешён порт веб-интерфейса.

Если телефоны и компьютеры подключены через один аппарат, проверьте voice VLAN, тегирование, LLDP-MED и защиту порта. Firewall не исправит порт коммутатора, который пропускает неожиданные VLAN от пользовательского устройства.

NAT и firewall решают разные задачи

Masquerade меняет исходный адрес при выходе в интернет. Он не задаёт правила доступа между VLAN и не заменяет final drop. До добавления проверьте существующий srcnat. Для нового стенда с динамическим WAN можно подготовить отключённый пример:

/ip firewall nat print detail
/ip firewall nat add chain=srcnat action=masquerade src-address-list=F68-SUBNETS out-interface-list=F68-WAN disabled=yes comment="F68 optional internet NAT"

Не включайте его, если нужный NAT уже есть. Для статического адреса может использоваться src-nat, для IPsec нужны исключения; их порядок важен. Выбор зависит от подключения, не от предпочтения одного слова.

Проброс порта — две проверки: dstnat направляет запрос, forward разрешает конкретный сервис после трансляции. В нашем наборе нет разрешения входящих новых подключений с WAN, поэтому один новый dstnat не опубликует сервис. Это намеренная политика.

Изменение NAT не обязано изменить уже отслеживаемое соединение. Проверяйте новый поток; очистка всей таблицы соединений ради одного теста прервёт чужие сеансы. Документация NAT объясняет связь с connection tracking.

Публикация HTTPS: dstnat и forward проверяем вместе

Допустим, по решению владельца нужно дать партнёру доступ к веб-узлу 1С .20. Сначала проверьте внешний адрес и возможность входящих соединений: за CGNAT один проброс на вашем MikroTik не создаст доступ из интернета. При обычном удалённом доступе сотрудников предпочтительнее ранее согласованный VPN.

В шаблоне 203.0.113.10 — условный внешний IP, 198.51.100.0/24 — условная сеть партнёра. Оба диапазона документационные. Замените их своими данными, не включайте такой пример как есть:

/ip firewall address-list
add list=F68-partner-public address=198.51.100.0/24 comment="F68 EXT replace with partner network"
/ip firewall nat
add chain=dstnat in-interface-list=F68-WAN dst-address=203.0.113.10 src-address-list=F68-partner-public protocol=tcp dst-port=443 action=dst-nat to-addresses=10.10.50.20 to-ports=443 disabled=yes comment="F68 EXT partner 1C dstnat"
/ip firewall filter
add chain=f68-forward in-interface-list=F68-WAN src-address-list=F68-partner-public out-interface=vlan50-servers dst-address=10.10.50.20 protocol=tcp dst-port=443 connection-nat-state=dstnat action=accept disabled=yes place-before=[find where comment="F68 FW final drop"] comment="F68 EXT partner 1C HTTPS"

NAT-правило видит внешний IP, forward — уже внутреннее назначение. Оба правила и allowlist должны соответствовать одной задаче. Не используйте общее accept connection-nat-state=dstnat как разрешение любых будущих пробросов. Снаружи проверьте правильный сертификат, приложение и отказ источнику вне разрешённой сети.

Для внутренних клиентов удобнее split DNS: то же DNS-имя возвращает внутренний адрес, сертификат остаётся выданным на имя. Hairpin NAT нужен не всегда; если он необходим, ограничьте источник/назначение и учитывайте обратный маршрут. Массовый masquerade всего LAN ради hairpin мешает видеть реальные источники.

Обновление, аутентификация и журналирование веб-приложения остаются обязательными. Доступ по HTTPS — не основание публиковать RDP, SQL, WinBox или интерфейс гипервизора наружу.

Гостевой интернет, внутренние адреса за WAN и служебные исключения

Базовый accept out-interface-list=F68-WAN разрешает гостю всё, что маршрутизируется через этот WAN. Если там есть частная сеть провайдера или корпоративная площадка, слово WAN не делает её публичным интернетом. Раньше соответствующего internet-accept нужны точечные исключения или запреты.

Например, список частных назначений и отключённый запрет для гостей. Он не применяется автоматически; вначале проверьте DNS/NTP провайдера, VPN и легальные частные назначения:

/ip firewall address-list
add list=F68-private-v4 address=10.0.0.0/8 comment="F68 EXT RFC1918"
add list=F68-private-v4 address=172.16.0.0/12 comment="F68 EXT RFC1918"
add list=F68-private-v4 address=192.168.0.0/16 comment="F68 EXT RFC1918"
/ip firewall filter
add chain=f68-forward in-interface=vlan20-guest src-address=10.10.20.0/24 out-interface-list=F68-WAN dst-address-list=F68-private-v4 action=drop disabled=yes place-before=[find where comment="F68 FW guest internet"] comment="F68 EXT guest private destinations via WAN"

Это пример для RFC1918, а не полный актуальный список специальных/непубличных адресов. Не объявляйте весь диапазон 172.0.0.0/8 частным: RFC1918 здесь только 172.16.0.0/12. Фильтрация источников на WAN также зависит от провайдера: DHCP, VPN и частные служебные адреса могут быть легальными.

При WAN через DHCP нужен доступ самого роутера к соответствующему обмену. Для такой архитектуры, а не для исходного PPPoE-примера, подготовьте input-шаблон:

/ip firewall filter
add chain=f68-input in-interface-list=F68-WAN protocol=udp src-port=67 dst-port=68 action=accept disabled=yes place-before=[find where comment="F68 IN final drop"] comment="F68 EXT WAN DHCP client"

Проверьте фактический сервер, интерфейс и правила RAW. Для маршрутизаторов с OSPF/BGP, VRRP, IPsec и мониторингом добавляются собственные строго ограниченные служебные разрешения. Порт BGP179 не нужен обычному офисному шлюзу без BGP; OSPF — IP-протокол89, а не TCP-порт89.

Шаг 6. Подключите проверенные цепочки поэтапно

До этого шага проверьте весь набор, VPN/служебные исключения и возврат. Добавьте два отключённых перехода:

/ip firewall filter
add chain=input action=jump jump-target=f68-input disabled=yes comment="F68 entry input"
add chain=forward action=jump jump-target=f68-forward disabled=yes comment="F68 entry forward"
print detail where comment~"^F68"

1. В WinBox откройте IP → Firewall → Filter Rules. Найдите два entry-правила по точному комментарию.
2. Пока они отключены, переместите их перед прежними обрабатывающими правилами соответствующей цепочки. Учитывайте dynamic-правила и FastTrack: простой перенос вверх не отменяет уже ускоренные соединения.
3. В Safe Mode включите только F68 entry input. Проверьте новый сеанс управления с VLAN99 и отказ с гостевого VLAN; старый открытый сеанс может проходить по established.
4. После проверки input включите F68 entry forward и повторите матрицу доступа новыми соединениями.
5. Если для стенда нужен подготовленный NAT, включайте только его точное правило после проверки отсутствия дубля.
6. Проверьте журналы, нагрузку и рабочие сценарии, затем осознанно завершите Safe Mode с сохранением результата.

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

Учётные записи: новый администратор, затем отключение admin

Смена известного имени полезна для снижения простого перебора, но основная защита — ограниченный сетевой доступ, стойкий уникальный пароль, персональные аккаунты и актуальная RouterOS. Не ограничивайтесь переименованием admin при прежнем слабом пароле.

1. В защищённом административном подключении откройте System → Users и создайте персональную запись, например netops.ann. Имя условное; используйте понятное корпоративное правило именования.
2. Сгенерируйте уникальный пароль в менеджере паролей, сохраните запись с устройством и владельцем; не копируйте пароль из статьи. Вводите через форму, чтобы он не оказался в истории терминала/скрипте.
3. Назначьте только нужные полномочия. Полный доступ оставляют ответственным администраторам и контролируемой аварийной записи, а не подрядчику на время диагностики.
4. Откройте новое подключение под новой записью с разрешённого административного адреса. Проверьте требуемые действия и независимый способ восстановления.
5. Только после этого отключите стандартного admin. На первом этапе отключение обратимее удаления.
6. Проверьте журнал входов, действующие сеансы и учёт аварийного доступа. Для каждого подрядчика — собственная запись и срок отзыва.

/user print detail
/user group print detail
/user active print
# Только после проверки нового администратора и возврата:
/user disable [find where name="admin"]

Это инструкция, а не выполненная смена доступа. Для мониторинга создают отдельную минимальную группу: встроенное имя read не гарантирует отсутствия чувствительных полномочий. Поддержку ограничений, SSH-ключей и политику конкретной версии проверяйте в руководстве User. Публичный SSH-ключ можно хранить открыто, приватный ключ и экспорт VPN — нельзя.

IP Services, MAC-доступ, discovery и нестандартные порты

Сначала проверьте перечень сервисов и зависимости. Дальше пример ограничивает существующий WinBox подсетью управления и конкретным /32 VPN-администратора из IP-плана. Если адреса вашей схемы другие, замените их до применения; наличие /32 в IP Services не создаёт VPN.

/ip service print detail
/ip service set [find where name="winbox"] address=10.10.99.0/24
/tool mac-server set allowed-interface-list=F68-MGMT
/tool mac-server mac-winbox set allowed-interface-list=F68-MGMT
/ip neighbor discovery-settings set discover-interface-list=F68-MGMT

Эти команды меняют доступ независимо от entry-правил firewall. Их возврат планируют отдельно. Не отключайте MAC-доступ до проверки IP-управления и консоли. Если MAC Telnet вообще не нужен, после проверки можно закрыть его полностью штатным способом.

• Отключайте ненужные Telnet, FTP, HTTP/WebFig, API и API-SSL только после инвентаризации: API может использовать автоматизация.
• Для используемого WebFig выбирайте защищённое подключение с доверенным сертификатом и ограниченными источниками.
• Проверьте UPnP/NAT-PMP, proxy, SOCKS, bandwidth-test server, RoMON и облачные функции удалённого доступа. Нужны ли они бизнесу, кто имеет доступ?
• Не путайте IP Services с /ip firewall service-port: во втором меню находятся helpers, а не сервисы управления устройством.
• Если сменили 8291 или 22 на другой порт, синхронно исправьте input и документацию. Смена порта уменьшает шум сканирования, но не заменяет VPN, права и обновления.

Ограничение address в IP Services не создаёт маршрут и не разрешает firewall. Для IPv6 разрешённые префиксы управления и правила проверяют отдельно. Не выдавайте 0.0.0.0/0 ради временной диагностики.

Что проверять в WinBox, чтобы видеть результат

• Filter Rules: Chain, Action, In/Out Interface, Src/Dst Address, Protocol, Dst Port и порядок строк.
• Advanced: Connection State и другие дополнительные условия; пустое поле не означает автоматически нужное ограничение.
• Action: jump-target для entry, accept/drop для правил решения, комментарий для поиска.
• Statistics: пакеты и байты конкретного правила во время нового тестового соединения.
• Connections: адреса, состояние, NAT и признак FastTrack нужного потока.
• IPv6 → Firewall: отдельная политика, которую не видно на вкладке IPv4.

Нулевой счётчик — повод проверить цепочку, порядок, интерфейс, аппаратный путь и реальное наличие трафика. Он не доказывает автоматически ошибку правила. Рост final drop показывает блокировки, но не доказывает, что блокируются только нежелательные соединения. Здесь приведены ориентиры интерфейса, а не вымышленные скриншоты настроенного стенда.

FastTrack, hardware offload и невидимые для правил пакеты

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

• FastTrack может обходить firewall/mangle и часть очередей; учитывайте IPsec, policy routing и учёт.
• Ранее ускоренное соединение может сохранять такой режим до завершения или timeout. Отключение правила не гарантирует немедленную перепроверку всех его пакетов.
• Для теста создайте новый поток с новым соединением; при необходимости завершайте только согласованный конкретный сеанс.
• Torch/sniffer могут менять условия ускорения. Ситуация «при включённом Torch работает» — диагностический признак, а не исправление.
• L2 switching в одном VLAN и L3 hardware offload — отдельные пути. Проверяйте поддержку и настройки конкретного устройства.

Connection tracking и FastTrack описаны в официальном руководстве. Обещать скорость только по числу портов нельзя: проверяют модель, размер пакета, набор правил и фактическую нагрузку.

IPv6: отдельная политика, а не галочка рядом с IPv4

Команды выше относятся только к /ip firewall. Если клиенты имеют IPv6, успешный запрет IPv4 не подтверждает изоляцию: возможен другой маршрут. До production нужна самостоятельная политика в /ipv6 firewall либо подтверждённое отсутствие IPv6 в согласованной архитектуре.

1. Зафиксируйте адреса, полученные префиксы, RA/ND, маршруты и делегирование провайдера.
2. Для input определите административный IPv6-источник и интерфейс, нужные ICMPv6 и DHCPv6-клиент/relay.
3. Для forward повторите матрицу направлений IPv6 и явный запрет прочего; IPv4 address-list здесь неприменим.
4. Не блокируйте весь ICMPv6: он нужен не только ping, но и базовому функционированию IPv6, включая сообщения об MTU.
5. Проверьте разрешения и запреты с клиента по IPv6, а не только командой ping на роутере.

/ipv6 address print detail
/ipv6 route print detail
/ipv6 nd print detail
/ipv6 dhcp-client print detail
/ipv6 firewall filter print stats

Для DHCPv6 нельзя механически копировать единственный ожидаемый link-local адрес источника: при relay он может отличаться. IPv6 NAT не является заменой фильтрации. Официальная страница Filter содержит отдельные примеры IPv6; их адаптируют под реального провайдера и топологию.

Защита управления: не только IP firewall

Management лучше держать в отдельном VLAN с доступом через согласованный административный маршрут. Но VLAN99 сам по себе не делает каждого его клиента доверенным. Нужны персональные учётные записи, минимальные права и контроль доступа к портам.

/ip service print detail
/tool mac-server print
/tool mac-server mac-winbox print
/ip neighbor discovery-settings print
/user print
/system logging print

• Ограничьте IP Services разрешёнными адресами управления и отключите ненужные сервисы после проверки зависимостей.
• Проверьте MAC WinBox/MAC Telnet и обнаружение соседей: это отдельный уровень, он не закрывается одним IPv4 input drop.
• Удалённое управление организуйте через VPN, а не публичный WinBox. Для VPN добавляют отдельные точечные правила и проверяют отзыв доступа подрядчика.
• Пароли генерируйте и храните в менеджере; используйте персональные аккаунты и ключи по принятой политике.
• Обновляйте RouterOS с проверкой релизных замечаний и планом возврата.

Процедуры ограничения управления есть в Securing your router; сообщения об уязвимостях — в разделе безопасности MikroTik. Не выполняйте массовое отключение сервисов в единственном удалённом сеансе.

Шаг 7. Проверьте счётчики, журнал и новые соединения

/ip firewall filter print stats where comment~"^F68"
/ip firewall connection print detail
/log print where topics~"firewall"
/tool profile

Для ограниченной диагностики можно временно добавить перед final drop правило action=log с узкими адресами/портом и лимитом частоты. Log не заменяет drop: после записи пакет должен дойти до правила решения. Не включайте log=yes для каждого пакета массовой атаки: нагрузка и объём журнала могут стать новой проблемой.

1. Сотрудник открывает сайт: новое соединение и счётчик staff internet.
2. Сотрудник обращается к согласованному принтеру: правило staff printer и фактическая печать.
3. Гость пробует управление роутером и новый TCP-сеанс к принтеру: ожидаем отказ, интернет при этом работает.
4. Администратор создаёт новый сеанс из VLAN99: ожидаем вход. Старый established-сеанс не подходит как единственное подтверждение.
5. Устройство VLAN30 инициирует несогласованное внешнее соединение: ожидаем отказ.
6. Повторяем важные тесты по IPv6, если он используется.

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

DoS/DDoS: что защищаем и где проходит граница роутера

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

• Сам роутер: закрытые службы, доступ управления из доверенных источников, отсутствие открытого DNS/proxy, контроль CPU/памяти и новых соединений.
• Сервис за роутером: публикация только нужного назначения, allowlist где возможно, ограничения приложения/reverse proxy и наблюдение.
• Канал: измерение bps/pps и потерь, связь с провайдером, готовая схема очистки/резервирования. Второй интернет не является автоматической DDoS-защитой.

Для TCP-служб самого роутера RouterOS поддерживает SYN cookies; после проверки версии и задачи администратор может включить:

/ip settings print
# После оценки совместимости и сохранения исходного значения:
/ip settings set tcp-syncookies=yes

Это не SYN-proxy перед каждым внутренним сервером и не защита UDP. Проверяйте влияние на службы. Официальное описание DDoS protection отдельно рассматривает обнаружение всплеска новых соединений, RAW и SYN cookies.

Не назначайте универсальную цифру «32 новых соединения в секунду» всем клиентам. Один NAT-адрес может представлять большую компанию, браузер — открывать параллельные соединения, а резервное копирование — давать легальный всплеск. Порог определяют по профилю сервиса, наблюдению и допустимым ложным срабатываниям.

RAW и списки блокировки: ранняя фильтрация без ложных обещаний

RAW prerouting обрабатывает пакет до connection tracking и до dstnat. Он полезен для точечно подтверждённого нежелательного источника, но ошибочное правило может отбросить и управление до filter. Сначала наблюдение и узкая область, затем ограниченный срок и возврат.

Шаблон ниже отключён. 198.51.100.23 — документационный адрес, его заменяют подтверждённым источником. Само наличие этой строки не доказывает атаку.

/ip firewall address-list
add list=F68-confirmed-block address=198.51.100.23 timeout=30m comment="F68 EXT reviewed source example"
/ip firewall raw
add chain=prerouting action=drop in-interface-list=F68-WAN src-address-list=F68-confirmed-block disabled=yes comment="F68 EXT temporary WAN source block"

Шаблон блокирует все входящие IPv4-пакеты отмеченного источника на выбранных WAN, включая его легальные соединения. Уточните влияние на подрядчика, SIP-оператора, VPN, CDN и других клиентов за одним NAT. Для одного сервиса ограничьте также правильное назначение/протокол, соблюдая стадию NAT.

Важная тонкость dstnat: detector в forward видит внутренний адрес сервера, RAW — ещё публичный адрес назначения. Копирование списка «жертв» из forward в RAW без учёта трансляции может вообще не сопоставиться с атакуемым пробросом. Для фильтра после dstnat используют внутреннее назначение; для RAW нужна отдельная привязка к внешнему адресу. Не смешивайте эти представления.

Два независимых списка attackers и targets задают все сочетания источников и назначений из списков, а не точную таблицу пар. Это может расширить блокировку. Логика dst-limit, время жизни записей и место jump требуют проверки, а не механического импорта «анти-DDoS скрипта».

/ip firewall address-list print detail where list="F68-confirmed-block"
/ip firewall raw print stats where comment~"^F68"
/ip firewall filter print stats where comment~"^F68"
/ip firewall connection tracking print
/tool profile

Нужны мониторинг pps/bps, CPU, connection table, потерь и доступности сервиса. Не логируйте каждый пакет flood и не используйте тяжёлые Layer7-регулярные выражения как универсальную защиту HTTPS. Поддельный source IP и распределённые источники ограничивают пользу простого чёрного списка.

Прикладная приёмка: проверяем бизнес-сценарии, а не только ping

1. Бухгалтер: получает адрес и DNS, входит в 1С по HTTPS, открывает отчёт; не может войти в WinBox и интерфейс репозитория.
2. Гость: открывает интернет, не создаёт новое соединение к принтеру, серверу или management. Проверка повторена с IPv6 при его наличии.
3. Телефон: регистрируется, проходит входящий/исходящий вызов, удержание и перевод, есть звук в обе стороны; после простоя вызов тоже проходит.
4. VPN-сотрудник: имеет только согласованный ресурс; peer-администратор — отдельный вход через jump-host. Отключённый peer теряет новый доступ.
5. Камера: пишет на NVR и синхронизирует время; произвольный выход в интернет и пользовательский VLAN закрыт по матрице.
6. Копии: выполняются backup и тест восстановления; обычный сотрудник не получает административный доступ к хранилищу.
7. Сетевой администратор: новый персональный вход работает; admin отключён после проверки; MAC-доступ и discovery соответствуют проекту.
8. Защита под нагрузкой: согласованная стендовая проверка не нарушает легальные соединения; связь с провайдером и порядок отмены блокировок записаны.

Это шаблоны испытаний, не описание выполненных нами внедрений. Для каждой проверки фиксируют источник, назначение, новое соединение, IPv4/IPv6, время и результат. Выгрузка счётчиков дополняет проверку приложения, но не заменяет её.

Чего этот firewall не обещает бизнесу

• Не расшифровывает и не анализирует автоматически всё содержимое HTTPS как DLP.
• Не заменяет защиту рабочих станций, почты, резервные копии и права пользователей.
• Не спасает канал, который уже забит объёмной DDoS-атакой: нужна работа с провайдером или внешней фильтрацией.
• Не разделяет устройства внутри одного L2-сегмента, если их трафик не проходит через нужную точку контроля.
• Не превращает правила по портам в полноценный контроль современных приложений.

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

Матрица доступа и протокол проверки

Настройка сети и сопровождение инфраструктуры

Частые вопросы