Короткий ответ

Правильная DMZ 10.0.30.0/24 принимает с WAN 203.0.113.10 только опубликованное (обычно 80/443), инициирует в LAN 10.0.10.0/24 почти ничего. Исключения — список из матрицы (например, web→app 10.0.10.20:8080 — лучше app тоже не в users VLAN). Default: drop DMZ→LAN, drop DMZ→mgmt 10.0.99.0/24. LAN→DMZ — только админские и нужные клиентские. Не бриджуйте DMZ с LAN. Не отключайте фильтр «чтобы CMS увидела БД».

Если «DMZ» — просто второй IP на том же L2, это не DMZ.

Симптомы и как отличить

С web01 10.0.30.10 открывается \\dc01, RDP, PostgreSQL 10.0.10.20, iLO. В filter нет drop saddr 10.0.30.0/24 daddr 10.0.10.0/24. На RouterOS ether DMZ в том же bridge, что LAN.

ПотокНормаПлохо
WAN→DMZ :443allow VIPany port
LAN users→DMZ :443часто allow—
DMZ→LAN :5432только если так задумано и узкоany
DMZ→mgmtdenyWinBox с веб-сервера
DMZ→WAN :80/443updates, APIany tcp

Отличие от лишних портов WAN: здесь east-west после взлома CMS.

Возможные причины

  1. Интерфейс DMZ не создан, «публичный сервер» стоит в LAN с DNAT.
  2. Bridge LAN+DMZ.
  3. Allow DMZ→LAN any «для 1С/SQL».
  4. Policy forward accept.
  5. App и БД разъехались: БД оставили в LAN, web в DMZ, открыли any.
  6. Backup из DMZ в LAN по SMB any.

Диагностика

1. L2/L3

ip -br addr
ip route
sudo nft list ruleset
/ip address print
/interface bridge port print
/ip firewall filter print where src-address=10.0.30.0/24

Один bridge — не DMZ. Нужен отдельный VLAN/ether + адрес 10.0.30.1/24 на FW.

2. С хоста DMZ (ваш web01)

ip -br addr
ping -c 1 10.0.10.10
nc -zv -w 2 10.0.10.10 389
nc -zv -w 2 10.0.99.1 22

Success на AD/SSH mgmt — сломанная DMZ. Не сканируйте всю LAN -p-; проверяйте известные роли из инвентаря.

3. NAT скрывает картину

DNAT WAN→10.0.30.10:443 при сервере в 10.0.10.0/24 — это не DMZ, это проброс в LAN. См. NAT и источник и port forwarding.

4. Conntrack DMZ→LAN

sudo conntrack -L | grep 10.0.30.10 | grep 10.0.10

Список dst-port — кандидаты на allow или на немедленный drop.

Концепция pf: интерфейс OPT1/DMZ, правило «deny DMZ to LAN», pass только enumerated. Default deny.

Решение

Сценарий A. Сначала отделить L2

VLAN 30, SVI 10.0.30.1/24, порт сервера access VLAN 30. Перенос IP web с 10.0.10.x на 10.0.30.10. Обновить DNAT на новый dst. DNS внутренний A-запись. Не оставляйте старый IP в LAN «на всякий».

Сценарий B. Filter RouterOS 7

Established первым. Затем:

/ip firewall filter add chain=forward src-address=10.0.30.10 dst-address=10.0.20.10 \
  protocol=tcp dst-port=8080 action=accept comment="web to app - matrix"
/ip firewall filter add chain=forward src-address=10.0.30.0/24 dst-address=10.0.10.0/24 \
  action=drop comment="DMZ not to users LAN"
/ip firewall filter add chain=forward src-address=10.0.30.0/24 dst-address=10.0.99.0/24 \
  action=drop
/ip firewall filter add chain=forward in-interface-list=WAN dst-address=10.0.30.10 \
  protocol=tcp dst-port=80,443 action=accept

Если app ещё в 10.0.10.20 — точечный allow один порт, план вынести app в 10.0.20.0/24 (серверный VLAN).

Сценарий C. nftables

sudo cp /etc/nftables.conf /root/nftables.conf.bak.dmz
# iif dmz0 oif lan0 ip saddr 10.0.30.10 ip daddr 10.0.20.10 tcp dport 8080 accept
# iif dmz0 oif lan0 counter log prefix "DMZ-LAN-DENY " drop
# iif dmz0 oif mgmt0 drop
sudo nft -c -f /etc/nftables.conf

Log sample на deny — поймаете забытый легитимный поток без открытия any.

Сценарий D. SQL из DMZ

Идеал: БД не в users LAN, не слушает 0.0.0.0 с DMZ any. Web→app, app→db внутри servers. Если временно web→db: один src, один dst, один порт, нет 1433 с всей 10.0.30.0/24.

Сценарий E. Обновления и DNS из DMZ

Egress DMZ: DNS, NTP, 80/443 к update — egress. Не через DC как «прокси в LAN».

Откат: bak-файл, не nft flush. Firewall не stop.

Как проверить, что проблема устранена

С web01:

nc -zv -w 2 10.0.10.10 389; echo ldap_should_fail
nc -zv -w 2 10.0.20.10 8080; echo app_per_matrix
curl -I --connect-timeout 3 https://127.0.0.1/

С LTE: сайт на опубликованном имени жив. Скан своего 203.0.113.10 — только порты матрицы, не 445 LAN.

С LAN users: сайт в DMZ открывается, если так задумано.

Counters DMZ-LAN-DENY растут на ваших негативных тестах, не на 8080.

Если не помогло

  • Старый DNAT всё ещё в LAN-хост — два сервера.
  • IPv6 в LAN с DMZ.
  • Docker на шлюзе бриджует.
  • «DMZ» в облаке без NSG east-west.
  • Мониторинг с DMZ в LAN ICMP — перенесите probe в mgmt.

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

  • Чеклист «новый хост в DMZ»: нет маршрута в LAN default, есть только enumerated.
  • Запрет SMB/RDP из DMZ в политике.
  • Ревизия conntrack DMZ→RFC1918 раз в месяц.
  • CMS в DMZ, бэкапы не SMB на DC.
  • Документ потоков в матрице.

FAQ

Можно ли ping из DMZ в LAN для диагностики?

Лучше нет. Диагностика с mgmt. ICMP allow DMZ→LAN учит «сеть плоская».

WAN→DMZ any, зато DMZ→LAN drop — достаточно?

Нет. Сужайте inbound. Иначе в DMZ войдут по лишнему порту.

Нужен ли отдельный firewall между DMZ и LAN?

Часто один edge с тремя интерфейсами хватает. Главное — не bridge и не any. Второй FW — если политика организации.

FTP в DMZ и active mode в LAN

Не надо. Пассив FTP или лучше не FTP. Не открывайте высокие порты any в LAN.

ADFS/LDAPS из DMZ

Точечный dst DC:636, не 389 unencrypted, не RPC range. Ещё лучше — брокер в servers.