MikroTik firewall: лучшие практики правил для корпоративного офиса

Я, Семёнов Евгений Сергеевич, директор ITFresh. За свои 15+ лет глубокого погружения в настройку MikroTik, могу сказать, видел я всякое. Иногда поражаешься! Например, сталкиваешься с офисами, где на MikroTik стоит firewall с правилом «allow all» – и что дальше? Внутренние принтеры спокойно "торчат" прямо в интернет, да ещё и с открытым PJL. Представьте себе! Или же другая крайность: сотни правил, добрая половина которых просто дублирует друг друга. Зачем так усложнять? По нашему убеждению, хороший, действительно правильный firewall – это всегда про поиск той самой золотой середины. Это тонкий компромисс между максимальной безопасностью и, конечно же, производительностью системы. Возьмём конкретный пример: нормальный комплект на RB4011 или CCR2004, используемый в дата-центре МТС. Он просто обязан "тянуть" 1 Gbps NAT, без проблем обрабатывать 50+ правил и выдавать как минимум 0,5 Gbps шифрования. И что важно — без просадок! Это, на наш взгляд, абсолютный минимум.

Цепочки firewall: input, forward, output

Когда мы работаем с фаерволом, основное внимание уделяем двум цепочкам: input, которая занимается защитой самого роутера, и forward – это уже про безопасность ваших сетей. А вот output-цепочку трогают гораздо реже. Зачем? Только если вдруг сам роутер начинает генерировать какой-то подозрительный трафик, или если нам позарез нужны специальные маркировки пакетов для последующей балансировки нагрузки.

Универсальный шаблон input

/ip firewall filter
# 1. Принимаем established и related
add chain=input action=accept connection-state=established,related \
  comment="accept est/rel"
# 2. Дропаем invalid
add chain=input action=drop connection-state=invalid comment="drop invalid"
# 3. ICMP с rate-limit
add chain=input protocol=icmp limit=50,50:packet action=accept \
  comment="accept ICMP limited"
# 4. Разрешаем из LAN всё
add chain=input in-interface-list=LAN action=accept comment="accept from LAN"
# 5. Whitelist управления (если нужен удалённый доступ)
add chain=input src-address-list=management action=accept \
  comment="accept management"
# 6. Port knocking / honeypot — переносим Winbox на нестандартный порт
add chain=input dst-port=22,8291 protocol=tcp action=add-src-to-address-list \
  address-list=knock-stage1 address-list-timeout=30s
# 7. Финальный drop
add chain=input action=drop comment="drop rest"

Запомните главное: «state first» — это наше всё. Почему? Всё просто: правило со статусом established/related должно стоять в списке самым первым, быть №1. Если его нет или оно не на первом месте, что происходит? Каждый ответный пакет вынужден пробегать по всему, абсолютно всему списку правил. А это, уж поверьте, катастрофически "убивает" производительность!

Универсальный шаблон forward

# FastTrack для увеличения NAT-производительности
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related \
  comment="fasttrack"
add chain=forward action=accept connection-state=established,related
add chain=forward action=drop connection-state=invalid
# Блок спуфинга
add chain=forward in-interface-list=WAN src-address-type=local action=drop \
  comment="drop spoofing"
# Защита от trashmasquerade
add chain=forward action=drop src-address-list=blacklist
# Разрешение пользовательских сетей наружу
add chain=forward src-address=192.168.10.0/24 out-interface-list=WAN \
  action=accept comment="office out"
# Запрет гостевой сети в корпоративные
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
  action=drop comment="block guest→office"
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.30.0/24 \
  action=drop comment="block guest→infra"
# DNAT для публичного веб-сервиса
add chain=forward dst-address=192.168.30.50 dst-port=443 protocol=tcp \
  action=accept comment="public HTTPS"
# Финальный drop
add chain=forward action=drop comment="drop rest"

Address-list: динамические списки IP

Address-list – это одна из тех фишек MikroTik, что действительно меняют игру. Это крайне мощный инструмент! Вы можете автоматически добавлять IP-адреса в такой список, как только сработает определённое правило. Например, если кто-то пять раз подряд неудачно пытался подключиться по SSH – бац, и его IP уже в "чёрном" списке! А дальше что? В других правилах вы просто проверяете, принадлежит ли адрес этому списку, и принимаете нужное решение. Удобно, правда?

# Каскадная защита от брутфорса SSH
/ip firewall filter
add chain=input protocol=tcp dst-port=22 src-address-list=ssh-banned \
  action=drop comment="drop banned SSH"
add chain=input protocol=tcp dst-port=22 connection-state=new \
  src-address-list=ssh-stage3 \
  action=add-src-to-address-list address-list=ssh-banned \
  address-list-timeout=1d comment="ban SSH"
add chain=input protocol=tcp dst-port=22 connection-state=new \
  src-address-list=ssh-stage2 \
  action=add-src-to-address-list address-list=ssh-stage3 \
  address-list-timeout=1m
add chain=input protocol=tcp dst-port=22 connection-state=new \
  src-address-list=ssh-stage1 \
  action=add-src-to-address-list address-list=ssh-stage2 \
  address-list-timeout=1m
add chain=input protocol=tcp dst-port=22 connection-state=new \
  action=add-src-to-address-list address-list=ssh-stage1 \
  address-list-timeout=1m

У нас есть железное правило: если с одного IP-адреса за минуту происходит четвёртая безуспешная попытка подключения, этот клиент немедленно отправляется в бан. Сразу на целые сутки! Такая простая, но эффективная мера надёжно отсекает до 99% всех автоматических сканеров и ботов, которые пытаются "прощупать" вашу систему.

Raw-цепочка: разгружаем conntrack

Представьте: на ваш WAN-интерфейс постоянно льётся куча мусора – это могут быть сканеры, попытки ботнетов, всё что угодно. В такой ситуации стандартный механизм conntrack занимается совершенно пустой работой, пытаясь отслеживать и обрабатывать весь этот ненужный трафик. Мы используем Raw-таблицу! Она позволяет нам отбросить ("дропнуть") подозрительные пакеты ещё до того, как они вообще попадут в conntrack. Это значительно разгружает роутер.

/ip firewall raw
# Дропаем bogons (невалидные IP)
add chain=prerouting src-address-list=bogons action=drop \
  comment="drop bogons"
# Дропаем спуфинг
add chain=prerouting src-address=192.168.0.0/16 in-interface-list=WAN \
  action=drop comment="drop rfc1918 from WAN"
add chain=prerouting src-address=10.0.0.0/8 in-interface-list=WAN action=drop
add chain=prerouting src-address=172.16.0.0/12 in-interface-list=WAN action=drop

# Список bogons добавляется автоматически из RIPE
/ip firewall address-list
add list=bogons address=0.0.0.0/8
add list=bogons address=127.0.0.0/8
add list=bogons address=169.254.0.0/16
add list=bogons address=224.0.0.0/4
add list=bogons address=240.0.0.0/4

Защита от сканирования портов

/ip firewall filter
# PSD (port scan detector)
add chain=input protocol=tcp psd=21,3s,3,1 \
  action=add-src-to-address-list address-list=port-scanners \
  address-list-timeout=2w comment="detect port scan"
# Nmap NULL/FIN/XMAS
add chain=input protocol=tcp tcp-flags=fin,!syn,!rst,!psh,!ack,!urg \
  action=add-src-to-address-list address-list=port-scanners \
  address-list-timeout=2w
add chain=input src-address-list=port-scanners action=drop \
  comment="drop port scanners"

Кейс: укрепление firewall после взлома

Помните июнь 2025 года? К нам тогда обратилась одна производственная компания из Подмосковья, у них 80 рабочих мест. Ситуация была критическая: на их MikroTik RB3011 взломали пароль администратора! Злоумышленник не просто получил доступ, а умудрился изменить настройки DNS на свой сервер с MITM (Man-in-the-Middle). В итоге? Пользователи компании, сами того не подозревая, попадали на фишинговые страницы. Обнаружили это лишь спустя неделю, когда заметили уж очень странный трафик. Главная причина взлома, как выяснилось при расследовании, была до банального проста и шокирующа: у аккаунта "mikrotik" в Winbox стоял пустой пароль, и порт 8291 был просто открыт в мир. Вот так беспечность может дорого стоить!

За один рабочий день мы:

• Первым делом, что мы сделали? Полностью сбросили ту "кашу" из настроек, которая там была, и перенастроили всё с чистого листа. С нуля.
• Конечно же, сразу же установили нашу проверенную схему каскадного бана для SSH и Winbox. (Да, ту самую, о которой мы говорили чуть выше!).
• Для Winbox мы сменили стандартный порт на 54321 – простое, но эффективное действие. И главное: ограничили доступ к нему, разрешив подключение только из офиса и через корпоративный VPN. Больше никаких открытых дверей!
• Включили raw-цепочку с bogons-списком.
• Мы настроили два DNS-листенера: один на внутреннем адресе (192.168.10.1), второй – на публичном DNS. И тут же, чтобы исключить любые обходы, наглухо заблокировали 53-й порт наружу от всех клиентов. Теперь трафик DNS идёт только через наши контролируемые серверы.
• А чтобы быть всегда в курсе, настроили систему почтовых уведомлений: теперь, как только кто-то пытается войти в Winbox, мы мгновенно получаем алерт на почту, используя связку Netwatch+fetch. Ни одна попытка не останется незамеченной!

Только представьте: за прошедшие полгода наши системы зарегистрировали 14 862 попытки брутфорса по SSH. И что самое важное? Все до единой были заблокированы нашим каскадным методом! Ни одного, подчёркиваю, ни одного успешного входа не произошло. А стоимость таких комплексных работ, включая тщательное расследование инцидента, составила 42 000 рублей. Подумайте, сколько это сэкономило нервов и денег нашим клиентам.

FastTrack и Connection Tracking

FastTrack – это, по сути, такой "скоростной проезд" для уже установленных соединений, он позволяет им обходить основные таблицы firewall. Знаете, насколько это эффективно? Производительность NAT может вырасти в 3–5 раз! Звучит здорово, правда? Но тут есть важный нюанс, такой скрытый камень: FastTrack делает пакеты абсолютно невидимыми для mangle и queue. Это значит, что если вы активно используете маркировку пакетов или занимаетесь шейпированием трафика (shaper), то вам придётся либо полностью отключить FastTrack, либо, как минимум, исключить из него те соединения, которые вы хотите контролировать. Иначе желаемого эффекта не будет.

# Проверить использование conntrack
/ip firewall connection print count-only
/ip firewall connection tracking print

Логирование и мониторинг

# Логируем дропы в отдельную тему
/system logging action
add name=fw-drops target=memory memory-lines=5000
/system logging
add topics=firewall action=fw-drops

# В правилах
add chain=input action=log log-prefix="drop-input" connection-state=new

# Экспорт на syslog-сервер
/system logging action
add name=remote target=remote remote=192.168.10.5 remote-port=514
/system logging add topics=firewall action=remote

FAQ — правила firewall MikroTik

В каком порядке обрабатываются правила?

Сверху вниз до первого совпадения. Established+related всегда №1, final drop — последний.

Чем отличается filter от raw?

Raw работает до connection tracking и дешевле по ресурсам для мусорного трафика.

Стоит ли блокировать по странам?

Geo-blocking помогает, но не заменяет полноценную защиту. VPN и TOR обходят.

Как защититься от брутфорса?

Каскадный бан через address-list с timeout, перенос портов на нестандартные.

Нужен ли DDoS-protection на MikroTik?

Базовая защита встроена, но для серьёзных атак — облачные анти-DDoS сервисы.