DMZ на MikroTik: изолируем веб-серверы от офиса

Поднял веб-сервер внутри офисной сети. Через неделю кто-то просканировал его снаружи и нашёл дырку в связке с бухгалтерским 1С-сервером в той же подсети. Знакомая история? DMZ на MikroTik решает это ровно так, как должно было быть с самого начала — сервер видно из интернета, но он физически не может достучаться до твоей LAN.

Дальше — конкретика. Без введения на 4000 слов. Один VLAN, три firewall-цепочки, проброс портов и защита от сканирования. Час работы, если руки не трясутся.

1. Диагноз: почему веб-сервер в общей сети — это бомба с фитилём

Поднял сайт или приложение на сервере внутри офиса. Всё работает, все довольны. А потом сервер ломают — через уязвимость в CMS, через дырявый плагин, через что угодно снаружи. И если этот сервер сидит в той же подсети что и рабочие станции бухгалтерии, атакующий получает не один взломанный сайт, а доступ ко всей внутренней сети. DMZ на MikroTik — это способ вынести публичный сервис в отдельный сегмент, где взлом сервера не превращается во взлом компании.

Что получишь на выходе: изолированный VLAN для веб-серверов, проброс 80/443 (и любых других портов) снаружи, firewall-правила которые физически не пускают трафик из DMZ в LAN, и базовую защиту от автоматического сканирования портов.

Сколько займёт: 40-60 минут, если MikroTik уже настроен и есть доступ к Winbox или SSH. Если начинаешь с нуля — плюс 20 минут на базовую конфигурацию бриджа.

Что нужно до старта:

• MikroTik с RouterOS v7 (v6 тоже подойдёт, но синтаксис VLAN чуть другой)
• Минимум 2 свободных Ethernet-порта или один порт под VLAN-транк
• Внешний IP или проброс через провайдера
• Понимание своей текущей топологии — где LAN, где WAN, что уже есть в firewall

Основной ключ этой статьи — DMZ на MikroTik — именно про это: не «как вообще устроен DMZ» в теории, а конкретная рабочая конфигурация, которую можно скопировать и адаптировать под себя.

Что будет в статье

• Причины почему без DMZ рано или поздно случается пробой в LAN
• Пошаговый рецепт: VLAN, dst-nat, firewall filter
• Проверка что изоляция реально работает
• Типичные ошибки и их решения
• Альтернативные подходы — когда DMZ не нужен вообще
• Профилактика: мониторинг, бэкап конфига, автозапуск правил

2. Причины, почему это ломается без DMZ

Смотри, вот список того, что реально происходит в продакшне, когда веб-сервер сидит в общей подсети с офисом:

• Одна подсеть — один уровень доверия. Firewall на уровне маршрутизатора не различает «это сервер снаружи» и «это ноутбук бухгалтера». Оба в 192.168.1.0/24, оба доверенные по умолчанию.
• Сканеры находят сервис за минуты. Shodan и masscan индексируют открытые 80/443 порты по всему интернету постоянно. Твой сервер найдут не потому что кто-то целится именно в тебя, а потому что боты сканируют весь диапазон IPv4.
• Уязвимость в приложении — это не «если», а «когда». WordPress, Joomla, самописный PHP — неважно что стоит. Рано или поздно найдётся дыра, через которую получают shell на сервере.
• Shell на сервере в общей LAN — это shell в твоей сети. Атакующий с сервера может пинговать внутренние хосты, сканировать SMB, лезть на терминал-серверы. Потому что маршрутизации внутри VLAN никто не мешает.
• Бэкапы и базы данных живут рядом. Если файловый сервер и веб-сервер в одной подсети — взлом одного даёт доступ ко второму просто по L2.
• Логи это подтверждают постоянно. Открой /log на любом MikroTik с публичным IP и увидишь сотни попыток подключения к SSH и веб-портам за сутки. Это фон, не аномалия.

Ну и запросы у вас — сказала база данных и повисла, когда сервер в общей сети получил shell-инъекцию через форму обратной связи.

3. Рецепт: строим DMZ на MikroTik пошагово

Схема простая: бридж с VLAN-фильтрацией, отдельный VLAN под DMZ, dst-nat на публичный IP, firewall filter с тремя ключевыми правилами.

Пунктирная стрелка D в C — это то, что должно быть заблокировано. Именно ради неё вся статья.

Системные требования

Таблица портов

Подготовка

Проверь текущую конфигурацию до того как что-то менять:

/interface bridge print
/interface vlan print
/ip firewall filter print
/ip firewall nat print

Результат: увидишь список существующих бриджей, VLAN и правил. Если бридж уже есть и на нём сидит LAN — будем добавлять VLAN поверх него, не ломая существующее.

Шаг 1. Создаём VLAN для DMZ

Заходим на бридж, который уже смотрит в LAN, и добавляем поверх него VLAN-интерфейс с новым ID.

/interface vlan add name=vlan20-dmz vlan-id=20 interface=bridge-lan

Результат: появился виртуальный интерфейс vlan20-dmz. Пока без IP и без правил — просто L2-сегмент внутри бриджа.

Шаг 2. Включаем VLAN filtering на бридже

Без этого шага VLAN-теги будут просто гулять по всей сети без изоляции. Вот тут важно не перепутать — именно filtering разделяет трафик по портам.

/interface bridge set bridge-lan vlan-filtering=yes
/interface bridge vlan add bridge=bridge-lan vlan-ids=20 tagged=bridge-lan untagged=ether3
/interface bridge vlan add bridge=bridge-lan vlan-ids=10 tagged=bridge-lan untagged=ether2

Результат: ether2 (порт к офисным свитчам) отдаёт VLAN 10 без тега, ether3 (порт к серверу в DMZ) отдаёт VLAN 20 без тега. Сам сервер и офисные машины тегов не видят — для них это просто отдельные физические сети.

Шаг 3. Назначаем IP-адрес DMZ-сегменту

/ip address add address=192.168.20.1/24 interface=vlan20-dmz

Результат: MikroTik теперь имеет адрес шлюза 192.168.20.1 для сети DMZ. Сервер получит 192.168.20.10 (например) со шлюзом 192.168.20.1.

Шаг 4. Настраиваем dst-nat для входящего трафика

Публичный IP на WAN-интерфейсе, а внутри — веб-сервер на 192.168.20.10. Пробрасываем 80 и 443:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=80 in-interface=ether1-wan action=dst-nat to-addresses=192.168.20.10 to-ports=80 comment="DMZ HTTP"
/ip firewall nat add chain=dstnat protocol=tcp dst-port=443 in-interface=ether1-wan action=dst-nat to-addresses=192.168.20.10 to-ports=443 comment="DMZ HTTPS"

Результат: запрос на публичный IP:80 и :443 уходит на сервер в DMZ. Проверяется на следующем шаге.

Шаг 5. Firewall filter — ядро всей изоляции

Вот тут вся суть DMZ на MikroTik. Три правила, которые определяют, кто куда ходит:

/ip firewall filter add chain=forward connection-state=established,related action=accept comment="Allow established"
/ip firewall filter add chain=forward connection-state=invalid action=drop comment="Drop invalid"
/ip firewall filter add chain=forward in-interface=ether1-wan out-interface=vlan20-dmz protocol=tcp dst-port=80,443 action=accept comment="WAN to DMZ web"
/ip firewall filter add chain=forward in-interface=vlan20-dmz out-interface=bridge-lan action=drop comment="Block DMZ to LAN"
/ip firewall filter add chain=forward in-interface=vlan20-dmz out-interface=ether1-wan action=accept comment="Allow DMZ to internet"
/ip firewall filter add chain=forward action=drop comment="Default deny"

Порядок правил критичен. Established/related и invalid идут первыми — это база любого нормального firewall. Дальше разрешаем WAN→DMZ только на 80/443. Потом явно режем DMZ→LAN. Потом разрешаем DMZ→интернет, чтобы сервер мог ставить обновления и слать почту. В конце — default deny, который ловит всё, что не подошло под явные правила.

Результат: сервер в DMZ доступен снаружи по 80/443, может выходить в интернет, но не видит вообще ничего в офисной LAN — ни пинга, ни SMB, ни RDP.

Шаг 6. Защита от сканирования

Сканеры долбят порт за портом с одного IP или диапазона. Ограничиваем скорость новых соединений:

/ip firewall filter add chain=forward protocol=tcp dst-port=80,443 connection-state=new in-interface=ether1-wan dst-address=192.168.20.10 action=jump jump-target=port-scan-check comment="Check port scan"

/ip firewall filter add chain=port-scan-check protocol=tcp connection-limit=20,32 action=add-src-to-address-list address-list=scanners address-list-timeout=1h comment="Mark scanners"
/ip firewall filter add chain=port-scan-check src-address-list=scanners action=drop comment="Drop scanners"
/ip firewall filter add chain=port-scan-check action=accept comment="Accept rest"

Результат: если один IP открывает больше 20 одновременных соединений, он попадает в address-list scanners и режется на час. Обычный посетитель сайта под это не подпадает, а вот массовый сканер — да.

4. Проверка: работает ли изоляция на самом деле

Конфиг написан — не значит что он работает как задумано. Проверяем с трёх сторон.

С сервера в DMZ пробуем достучаться до LAN (должно упасть):

ping 192.168.10.5

Результат должен быть 100% packet loss. Если пинг проходит — правило «Block DMZ to LAN» не работает или стоит не в том порядке.

Снаружи проверяем доступность веб-сервера:

curl -I https://ваш-домен.ру

Результат: HTTP 200 или редирект. Если таймаут — смотри dst-nat и правило WAN→DMZ.

На самом MikroTik смотрим счётчики правил — растут ли они на реальном трафике:

/ip firewall filter print stats

Результат: у правила «Block DMZ to LAN» счётчик packets должен оставаться на нуле в норме. Если он растёт — кто-то реально пытается пробиться из DMZ в LAN, и это повод для расследования, а не для игнорирования.

Проверка логов на предмет попыток сканирования:

/log print where topics~"firewall"
/ip firewall address-list print where list=scanners

5. Осложнения: что ломается и как чинить

Всё не так плохо как ты думаешь. Всё намного хуже — но каждая проблема тут решается одной командой.

/interface bridge port print

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

Отдельно про SSH и Winbox

/ip firewall filter add chain=input protocol=tcp dst-port=8291,22 src-address=!192.168.10.0/24 action=drop comment="Restrict management"

6. Альтернативы

DMZ на MikroTik через VLAN — не единственный вариант, и не всегда самый удобный.

• Отдельный физический коммутатор под DMZ. Проще концептуально, дороже по железу. Подходит если у тебя уже валяется свитч и жалко тратить порты роутера.
• Reverse proxy перед сервером (Nginx или Traefik) на отдельной машине в DMZ. Добавляет ещё один слой, полезно если серверов несколько и нужен единый вход.
• Cloudflare Tunnel или аналоги. Сервер вообще не открывает порты наружу — всё идёт через исходящее соединение к облаку. Удобно для небольших проектов, но добавляет зависимость от третьей стороны.
• Виртуализация с отдельным гипервизором под DMZ. Если сервер и так виртуальный — выноси его на отдельный физический хост, а не только в отдельный VLAN.

VLAN на MikroTik выбран как основной сценарий потому что не требует дополнительного железа и работает на том оборудовании, которое уже стоит в большинстве офисов.

7. Профилактика

Настроил — не значит забыл. DMZ без мониторинга это просто красивая схема на бумаге.

• Мониторинг счётчиков firewall. Скрипт раз в час проверяет, не растёт ли packets на правиле «Block DMZ to LAN».
• Бэкап конфигурации перед любым изменением. Один забытый export — и придётся вспоминать всё руками в 3 часа ночи.
• Автозапуск правил через export и import при восстановлении. Конфиг должен подниматься из файла, а не из головы.
• Обновление RouterOS по расписанию, не по факту взлома. Капля никотина убивает лошадь. Одна забытая уязвимость в старой прошивке — весь периметр.
• Регулярная проверка address-list scanners. Если список пустой неделями — либо у тебя нет трафика, либо правило перестало работать.

/system backup save name=router-backup-$(:tostr [/system clock get date])
/export file=router-config-backup

Безопасность — сводный чеклист

• UFW / firewall filter — все правила explicit, default deny в конце
• Management-доступ (SSH, Winbox) закрыт снаружи полностью
• SSH hardening на самом сервере в DMZ — ключи вместо паролей, fail2ban на уровне Linux-хоста (не на MikroTik — это уровень сервера, не роутера)
• Отдельный пользователь БД на сервере с минимальными правами
• Резервные копии конфигурации роутера и данных сервера раздельно
• Ограничения по IP на административные интерфейсы

Резервное копирование

Восстановление конфига:

/system backup load name=router-backup-2026-07-20

Обновление RouterOS

До обновления проверь список изменений на официальном сайте MikroTik Download — иногда меняется поведение firewall между минорными версиями.

/system backup save name=pre-update-backup
/system package update check-for-updates
/system package update install

Если после обновления что-то сломалось — откат через тот же backup файл, загруженный до апдейта.

8. FAQ

Почему DMZ не работает после настройки?

Чаще всего дело в порядке firewall-правил. RouterOS обрабатывает правила сверху вниз и останавливается на первом совпадении. Если accept established/related стоит слишком широко или default deny стоит не последним — изоляция не сработает как задумано. Проверяй порядок через /ip firewall filter print.

Как проверить что DMZ работает правильно?

Пинг из сервера в DMZ на любой хост в LAN должен стабильно падать в таймаут. Одновременно curl снаружи на публичный IP должен возвращать ответ от веб-сервера. Если оба условия выполняются — изоляция настроена верно.

Что делать если сервер в DMZ не может обновить пакеты?

Проверь правило DMZ→интернет — оно должно стоять выше default deny в цепочке forward. Также убедись что DNS резолвится с сервера, иначе обновление упадёт даже при открытом firewall.

Чем DMZ отличается от обычного проброса портов?

Простой проброс портов (dst-nat) сам по себе не изолирует сервер от остальной сети — он просто перенаправляет трафик. DMZ добавляет к этому firewall-правила, которые физически запрещают серверу инициировать соединения в сторону LAN. Проброс без DMZ — это открытая дверь в общий дом, DMZ — отдельный флигель с одним входом.

9. Прогноз

Настроил VLAN, прописал dst-nat, закрыл DMZ→LAN тремя строчками firewall filter. Теперь взлом веб-сервера через уязвимость в приложении остаётся проблемой одного сервера, а не входным билетом во всю офисную сеть.

Дальше — дело за мониторингом и регулярными обновлениями. Конфиг не гниёт сам по себе, но и не следит сам за собой. Если после настройки что-то не так — пиши в комментарии, разберёмся.