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

<p>Поднял веб-сервер внутри офисной сети. Через неделю кто-то просканировал его снаружи и нашёл дырку в связке с бухгалтерским 1С-сервером в той же подсети. Знакомая история? DMZ на <a class="wpil_keyword_link" href="https://it-apteka.com/tag/mikrotik/" target="_blank" rel="noopener" title="mikrotik" data-wpil-keyword-link="linked" data-wpil-monitor-id="3164">MikroTik</a> решает это ровно так, как должно было быть с самого начала — сервер видно из интернета, но он физически не может достучаться до твоей LAN.</p> <p>Дальше — конкретика. Без введения на 4000 слов. Один VLAN, три firewall-цепочки, проброс портов и <a class="wpil_keyword_link" href="https://it-apteka.com/category/security/" target="_blank" rel="noopener" title="Безопасность" data-wpil-keyword-link="linked" data-wpil-monitor-id="3166">защита</a> от сканирования. Час работы, если руки не трясутся.</p> <h2>1. Диагноз: почему веб-сервер в общей сети — это бомба с фитилём</h2> <p>Поднял сайт или приложение на сервере внутри офиса. Всё работает, все довольны. А потом сервер ломают — через уязвимость в CMS, через дырявый плагин, через что угодно снаружи. И если этот сервер сидит в той же подсети что и рабочие станции бухгалтерии, атакующий получает не один взломанный сайт, а доступ ко всей внутренней <a class="wpil_keyword_link" href="https://it-apteka.com/category/networks/" target="_blank" rel="noopener" title="Сети" data-wpil-keyword-link="linked" data-wpil-monitor-id="3165">сети</a>. DMZ на MikroTik — это способ вынести публичный сервис в отдельный сегмент, где взлом сервера не превращается во взлом компании.</p> <p>Что получишь на выходе: изолированный VLAN для веб-серверов, проброс 80/443 (и любых других портов) снаружи, firewall-правила которые физически не пускают трафик из DMZ в LAN, и базовую защиту от автоматического сканирования портов.</p> <p>Сколько займёт: 40-60 минут, если MikroTik уже настроен и есть доступ к Winbox или SSH. Если начинаешь с нуля — плюс 20 минут на базовую конфигурацию бриджа.</p> <p>Что нужно до старта:</p> <ul> <li>MikroTik с RouterOS v7 (v6 тоже подойдёт, но синтаксис VLAN чуть другой)</li> <li>Минимум 2 свободных Ethernet-порта или один порт под VLAN-транк</li> <li>Внешний IP или проброс через провайдера</li> <li>Понимание своей текущей топологии — где LAN, где WAN, что уже есть в firewall</li> </ul> <p>Основной ключ этой статьи — DMZ на MikroTik — именно про это: не «как вообще устроен DMZ» в теории, а конкретная рабочая конфигурация, которую можно скопировать и адаптировать под себя.</p> <h3>Что будет в статье</h3> <ul> <li>Причины почему без DMZ рано или поздно случается пробой в LAN</li> <li>Пошаговый рецепт: VLAN, dst-nat, firewall filter</li> <li>Проверка что изоляция реально работает</li> <li>Типичные ошибки и их решения</li> <li>Альтернативные подходы — когда DMZ не нужен вообще</li> <li>Профилактика: <a class="wpil_keyword_link" href="https://it-apteka.com/category/monitoring/" target="_blank" rel="noopener" title="Мониторинг" data-wpil-keyword-link="linked" data-wpil-monitor-id="3167">мониторинг</a>, бэкап конфига, автозапуск правил</li> </ul> <h2>2. Причины, почему это ломается без DMZ</h2> <p>Смотри, вот список того, что реально происходит в продакшне, когда веб-сервер сидит в общей подсети с офисом:</p> <ul> <li><strong>Одна подсеть — один уровень доверия.</strong> Firewall на уровне маршрутизатора не различает «это сервер снаружи» и «это ноутбук бухгалтера». Оба в 192.168.1.0/24, оба доверенные по умолчанию.</li> <li><strong>Сканеры находят сервис за минуты.</strong> Shodan и masscan индексируют открытые 80/443 порты по всему интернету постоянно. Твой сервер найдут не потому что кто-то целится именно в тебя, а потому что боты сканируют весь диапазон IPv4.</li> <li><strong>Уязвимость в приложении — это не «если», а «когда».</strong> WordPress, Joomla, самописный PHP — неважно что стоит. Рано или поздно найдётся дыра, через которую получают shell на сервере.</li> <li><strong>Shell на сервере в общей LAN — это shell в твоей сети.</strong> Атакующий с сервера может пинговать внутренние хосты, сканировать SMB, лезть на терминал-серверы. Потому что маршрутизации внутри VLAN никто не мешает.</li> <li><strong>Бэкапы и базы данных живут рядом.</strong> Если файловый сервер и веб-сервер в одной подсети — взлом одного даёт доступ ко второму просто по L2.</li> <li><strong>Логи это подтверждают постоянно.</strong> Открой /log на любом MikroTik с публичным IP и увидишь сотни попыток подключения к SSH и веб-портам за сутки. Это фон, не аномалия.</li> </ul> <p>Ну и запросы у вас — сказала база данных и повисла, когда сервер в общей сети получил shell-инъекцию через форму обратной связи.</p> <h2>3. Рецепт: строим DMZ на MikroTik пошагово</h2> <p>Схема простая: бридж с VLAN-фильтрацией, отдельный VLAN под DMZ, dst-nat на публичный IP, firewall filter с тремя ключевыми правилами.</p> <pre class="mermaid">%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ffffff', 'primaryTextColor': '#1e293b', 'primaryBorderColor': '#94a3b8', 'lineColor': '#64748b', 'fontSize': '15px', 'fontFamily': 'ui-sans-serif, system-ui, sans-serif' }, 'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50} }}%% flowchart TD A["Интернет WAN"] --> B["MikroTik"] B --> C["VLAN 10 LAN офис"] B --> D["VLAN 20 DMZ веб-сервер"] D --> E["Интернет через NAT"] D -.-> C style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d </pre> <p>Пунктирная стрелка D в C — это то, что должно быть заблокировано. Именно ради неё вся статья.</p> <h3>Системные требования</h3> <table> <tbody> <tr> <th>Компонент</th> <th>Минимум</th> <th>Рекомендовано</th> </tr> <tr> <td>RouterOS</td> <td>v7.1 и выше</td> <td>7.23.2 (актуальна на момент публикации)</td> </tr> <tr> <td>Модель устройства</td> <td>Любая с поддержкой VLAN filtering на бридже</td> <td>hEX, CCR, CRS с аппаратным оффлоадом VLAN</td> </tr> <tr> <td>RAM</td> <td>128 МБ</td> <td>256 МБ и выше при большом числе правил</td> </tr> <tr> <td>Порты</td> <td>2 Ethernet</td> <td>3+ (WAN, LAN, DMZ раздельно)</td> </tr> </tbody> </table> <h3>Таблица портов</h3> <table> <tbody> <tr> <th>Порт</th> <th>Протокол</th> <th>Назначение</th> <th>Доступен снаружи?</th> </tr> <tr> <td>80</td> <td>TCP</td> <td>HTTP веб-сервера в DMZ</td> <td>Да, через dst-nat</td> </tr> <tr> <td>443</td> <td>TCP</td> <td>HTTPS веб-сервера в DMZ</td> <td>Да, через dst-nat</td> </tr> <tr> <td>22</td> <td>TCP</td> <td>SSH на сам MikroTik</td> <td>Нет, только с LAN или через port knocking</td> </tr> <tr> <td>8291</td> <td>TCP</td> <td>Winbox</td> <td>Нет, только с LAN</td> </tr> </tbody> </table> <h3>Подготовка</h3> <p>Проверь текущую конфигурацию до того как что-то менять:</p> <pre><code class="language-bash"> /interface bridge print /interface vlan print /ip firewall filter print /ip firewall nat print </code></pre> <p>Результат: увидишь список существующих бриджей, VLAN и правил. Если бридж уже есть и на нём сидит LAN — будем добавлять VLAN поверх него, не ломая существующее.</p> <h3>Шаг 1. Создаём VLAN для DMZ</h3> <p>Заходим на бридж, который уже смотрит в LAN, и добавляем поверх него VLAN-интерфейс с новым ID.</p> <pre><code class="language-bash"> /interface vlan add name=vlan20-dmz vlan-id=20 interface=bridge-lan </code></pre> <p>Результат: появился виртуальный интерфейс vlan20-dmz. Пока без IP и без правил — просто L2-сегмент внутри бриджа.</p> <h3>Шаг 2. Включаем VLAN filtering на бридже</h3> <p>Без этого шага VLAN-теги будут просто гулять по всей сети без изоляции. Вот тут важно не перепутать — именно filtering разделяет трафик по портам.</p> <pre><code class="language-bash"> /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 </code></pre> <p>Результат: ether2 (порт к офисным свитчам) отдаёт VLAN 10 без тега, ether3 (порт к серверу в DMZ) отдаёт VLAN 20 без тега. Сам сервер и офисные машины тегов не видят — для них это просто отдельные физические сети.</p> <h3>Шаг 3. Назначаем IP-адрес DMZ-сегменту</h3> <pre><code class="language-bash"> /ip address add address=192.168.20.1/24 interface=vlan20-dmz </code></pre> <p>Результат: MikroTik теперь имеет адрес шлюза 192.168.20.1 для сети DMZ. Сервер получит 192.168.20.10 (например) со шлюзом 192.168.20.1.</p> <h3>Шаг 4. Настраиваем dst-nat для входящего трафика</h3> <p>Публичный IP на WAN-интерфейсе, а внутри — веб-сервер на 192.168.20.10. Пробрасываем 80 и 443:</p> <pre><code class="language-bash"> /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" </code></pre> <p>Результат: запрос на публичный IP:80 и :443 уходит на сервер в DMZ. Проверяется на следующем шаге.</p> <h3>Шаг 5. Firewall filter — ядро всей изоляции</h3> <p>Вот тут вся суть DMZ на MikroTik. Три правила, которые определяют, кто куда ходит:</p> <pre><code class="language-bash"> /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" </code></pre> <p>Порядок правил критичен. Established/related и invalid идут первыми — это база любого нормального firewall. Дальше разрешаем WAN→DMZ только на 80/443. Потом явно режем DMZ→LAN. Потом разрешаем DMZ→интернет, чтобы сервер мог ставить обновления и слать почту. В конце — default deny, который ловит всё, что не подошло под явные правила.</p> <p>Результат: сервер в DMZ доступен снаружи по 80/443, может выходить в интернет, но не видит вообще ничего в офисной LAN — ни пинга, ни SMB, ни RDP.</p> <h3>Шаг 6. Защита от сканирования</h3> <p>Сканеры долбят порт за портом с одного IP или диапазона. Ограничиваем скорость новых соединений:</p> <pre><code class="language-bash"> /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" </code></pre> <p>Результат: если один IP открывает больше 20 одновременных соединений, он попадает в address-list scanners и режется на час. Обычный посетитель сайта под это не подпадает, а вот массовый сканер — да.</p> <h2>4. Проверка: работает ли изоляция на самом деле</h2> <p>Конфиг написан — не значит что он работает как задумано. Проверяем с трёх сторон.</p> <p>С сервера в DMZ пробуем достучаться до LAN (должно упасть):</p> <pre><code class="language-bash"> ping 192.168.10.5 </code></pre> <p>Результат должен быть 100% packet loss. Если пинг проходит — правило «Block DMZ to LAN» не работает или стоит не в том порядке.</p> <p>Снаружи проверяем доступность веб-сервера:</p> <pre><code class="language-bash"> curl -I https://ваш-домен.ру </code></pre> <p>Результат: HTTP 200 или редирект. Если таймаут — смотри dst-nat и правило WAN→DMZ.</p> <p>На самом MikroTik смотрим счётчики правил — растут ли они на реальном трафике:</p> <pre><code class="language-bash"> /ip firewall filter print stats </code></pre> <p>Результат: у правила «Block DMZ to LAN» счётчик packets должен оставаться на нуле в норме. Если он растёт — кто-то реально пытается пробиться из DMZ в LAN, и это повод для расследования, а не для игнорирования.</p> <p>Проверка логов на предмет попыток сканирования:</p> <pre><code class="language-bash"> /log print where topics~"firewall" /ip firewall address-list print where list=scanners </code></pre> <h2>5. Осложнения: что ломается и как чинить</h2> <p>Всё не так плохо как ты думаешь. Всё намного хуже — но каждая проблема тут решается одной командой.</p> <table> <tbody> <tr> <th>Ошибка</th> <th>Причина</th> <th>Решение</th> </tr> <tr> <td>Сервер недоступен снаружи после настройки</td> <td>dst-nat указывает не на тот интерфейс или IP сервера не совпадает</td> <td>Проверь <code>/ip firewall nat print</code> и IP сервера в DMZ</td> </tr> <tr> <td>Потерял доступ к MikroTik после vlan-filtering=yes</td> <td>Порт управления не назначен в правильный VLAN</td> <td>Сброс через netinstall или подключение по консоли</td> </tr> <tr> <td>Сервер в DMZ не может обновиться</td> <td>Правило DMZ→интернет стоит после default deny</td> <td>Переставь правило accept DMZ→WAN выше блокирующего</td> </tr> <tr> <td>Пинг из DMZ в LAN всё равно проходит</td> <td>Правило forward стоит после accept established/related, который матчит раньше</td> <td>Проверь порядок правил, established должен быть первым, но не единственным accept</td> </tr> </tbody> </table> <pre><code class="language-bash"> /interface bridge port print </code></pre> <p>Если после потери доступа к устройству остался физический доступ — подключайся через консольный порт напрямую, минуя бридж. Это единственный надёжный путь, когда сетевой доступ отрезан собственным же правилом.</p> <h3>Отдельно про SSH и Winbox</h3> <pre><code class="language-bash"> /ip firewall filter add chain=input protocol=tcp dst-port=8291,22 src-address=!192.168.10.0/24 action=drop comment="Restrict management" </code></pre> <h2>6. Альтернативы</h2> <p>DMZ на MikroTik через VLAN — не единственный вариант, и не всегда самый удобный.</p> <ul> <li><strong>Отдельный физический коммутатор под DMZ.</strong> Проще концептуально, дороже по железу. Подходит если у тебя уже валяется свитч и жалко тратить порты роутера.</li> <li><strong>Reverse proxy перед сервером (Nginx или Traefik) на отдельной машине в DMZ.</strong> Добавляет ещё один слой, полезно если серверов несколько и нужен единый вход.</li> <li><strong>Cloudflare Tunnel или аналоги.</strong> Сервер вообще не открывает порты наружу — всё идёт через исходящее соединение к облаку. Удобно для небольших проектов, но добавляет зависимость от третьей стороны.</li> <li><strong>Виртуализация с отдельным гипервизором под DMZ.</strong> Если сервер и так виртуальный — выноси его на отдельный физический хост, а не только в отдельный VLAN.</li> </ul> <p>VLAN на MikroTik выбран как основной сценарий потому что не требует дополнительного железа и работает на том оборудовании, которое уже стоит в большинстве офисов.</p> <h2>7. Профилактика</h2> <p>Настроил — не значит забыл. DMZ без мониторинга это просто красивая схема на бумаге.</p> <ul> <li><strong>Мониторинг счётчиков firewall.</strong> Скрипт раз в час проверяет, не растёт ли packets на правиле «Block DMZ to LAN».</li> <li><strong>Бэкап конфигурации перед любым изменением.</strong> Один забытый export — и придётся вспоминать всё руками в 3 часа ночи.</li> <li><strong>Автозапуск правил через export и import при восстановлении.</strong> Конфиг должен подниматься из файла, а не из головы.</li> <li><strong>Обновление RouterOS по расписанию, не по факту взлома.</strong> Капля никотина убивает лошадь. Одна забытая уязвимость в старой прошивке — весь периметр.</li> <li><strong>Регулярная проверка address-list scanners.</strong> Если список пустой неделями — либо у тебя нет трафика, либо правило перестало работать.</li> </ul> <pre><code class="language-bash"> /system backup save name=router-backup-$(:tostr [/system clock get date]) /export file=router-config-backup </code></pre> <h3>Безопасность — сводный чеклист</h3> <ul> <li>UFW / firewall filter — все правила explicit, default deny в конце</li> <li>Management-доступ (SSH, Winbox) закрыт снаружи полностью</li> <li>SSH hardening на самом сервере в DMZ — ключи вместо паролей, fail2ban на уровне <a class="wpil_keyword_link" href="https://it-apteka.com/category/linux/" target="_blank" rel="noopener" title="Linux" data-wpil-keyword-link="linked" data-wpil-monitor-id="3163">Linux</a>-хоста (не на MikroTik — это уровень сервера, не роутера)</li> <li>Отдельный пользователь БД на сервере с минимальными правами</li> <li>Резервные копии конфигурации роутера и данных сервера раздельно</li> <li>Ограничения по IP на административные интерфейсы</li> </ul> <h3>Резервное копирование</h3> <table> <tbody> <tr> <th>Что бэкапить</th> <th>Как часто</th> <th>Где хранить</th> </tr> <tr> <td>Конфиг MikroTik (.<a class="wpil_keyword_link" href="https://it-apteka.com/category/rezervnoe-kopirovanie/" target="_blank" rel="noopener" title="Резервное копирование" data-wpil-keyword-link="linked" data-wpil-monitor-id="3162">backup</a> и .rsc export)</td> <td>Перед каждым изменением + раз в неделю</td> <td>Отдельный NAS вне DMZ и вне LAN, или облако</td> </tr> <tr> <td>Данные веб-сервера и БД</td> <td>Ежедневно</td> <td>Вне DMZ, желательно вне офиса физически</td> </tr> </tbody> </table> <p>Восстановление конфига:</p> <pre><code class="language-bash"> /system backup load name=router-backup-2026-07-20 </code></pre> <h3>Обновление RouterOS</h3> <p>До обновления проверь список изменений на официальном сайте <a href="https://mikrotik.com/download" target="_blank" rel="noopener">MikroTik Download</a> — иногда меняется поведение firewall между минорными версиями.</p> <pre><code class="language-bash"> /system backup save name=pre-update-backup /system package update check-for-updates /system package update install </code></pre> <p>Если после обновления что-то сломалось — откат через тот же backup файл, загруженный до апдейта.</p> <h2>8. FAQ</h2> <h3>Почему DMZ не работает после настройки?</h3> <p>Чаще всего дело в порядке firewall-правил. RouterOS обрабатывает правила сверху вниз и останавливается на первом совпадении. Если accept established/related стоит слишком широко или default deny стоит не последним — изоляция не сработает как задумано. Проверяй порядок через <code>/ip firewall filter print</code>.</p> <h3>Как проверить что DMZ работает правильно?</h3> <p>Пинг из сервера в DMZ на любой хост в LAN должен стабильно падать в таймаут. Одновременно curl снаружи на публичный IP должен возвращать ответ от веб-сервера. Если оба условия выполняются — изоляция настроена верно.</p> <h3>Что делать если сервер в DMZ не может обновить пакеты?</h3> <p>Проверь правило DMZ→интернет — оно должно стоять выше default deny в цепочке forward. Также убедись что <a class="wpil_keyword_link" href="https://it-apteka.com/tag/dns/" target="_blank" rel="noopener" title="DNS" data-wpil-keyword-link="linked" data-wpil-monitor-id="3168">DNS</a> резолвится с сервера, иначе обновление упадёт даже при открытом firewall.</p> <h3>Чем DMZ отличается от обычного проброса портов?</h3> <p>Простой проброс портов (dst-nat) сам по себе не изолирует сервер от остальной сети — он просто перенаправляет трафик. DMZ добавляет к этому firewall-правила, которые физически запрещают серверу инициировать соединения в сторону LAN. Проброс без DMZ — это открытая дверь в общий дом, DMZ — отдельный флигель с одним входом.</p> <h2>9. Прогноз</h2> <p>Настроил VLAN, прописал dst-nat, закрыл DMZ→LAN тремя строчками firewall filter. Теперь взлом веб-сервера через уязвимость в приложении остаётся проблемой одного сервера, а не входным билетом во всю офисную сеть.</p> <p>Дальше — дело за мониторингом и регулярными обновлениями. Конфиг не гниёт сам по себе, но и не следит сам за собой. Если после настройки что-то не так — пиши в комментарии, разберёмся.</p>

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Интернет WAN"] --> B["MikroTik"]
    B --> C["VLAN 10 LAN офис"]
    B --> D["VLAN 20 DMZ веб-сервер"]
    D --> E["Интернет через NAT"]
    D -.-> C
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style B fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style D fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d

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

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

/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

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

/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 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"

/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"

ping 192.168.10.5

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

/ip firewall filter print stats

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

/interface bridge port print

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

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

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

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