Архитектура защиты

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

flowchart TB
    Internet[Интернет]
    MT[MikroTik / периметр]
    HAP[HAProxy 192.168.160.117<br/>25 80 443]
    ACL[HAProxy ACL<br/>SNI Host allowlist]
    BE[Бэкенды 192.168.160.0/24]

    Internet --> MT
    MT -->|DNAT публичный IP| HAP
    HAP --> ACL
    ACL --> BE

Два контура

1. Публичный вход (через HAProxy)

Клиент → публичный IP → HAProxy → (проверки) → один бэкенд.

На HAProxy уже есть:

443/TCP: отклонение неизвестного SNI; allowlist для git, sac-web, rds, erp, syno.
80/HTTP: только Host: zabbix.kalinamall.ru + zabbix-allowed.
25/SMTP: passthrough на KSMG без IP-фильтра на frontend.

2. Внутренняя сеть (LAN / VPN)

Трафик мимо HAProxy возможен, если:

есть VPN в 192.168.160.0/24;
бэкенд слушает на LAN без host firewall;
RDP/RDP Gateway по внутренним адресам.

Защита: UFW на бэкендах + политика «сервисный порт только с .117», админ-доступ — отдельные правила.

IP HAProxy (источник для бэкендов)

Имя	IP
haproxy.kalinamall.ru	192.168.160.117

Health-check HAProxy и прокси идут с этого IP. Правила на бэкендах должны разрешать его явно.

Матрица: кто фильтрует что

Угроза	MikroTik	UFW HAProxy	HAProxy cfg	UFW бэкенд	Приложение
Сканирование портов	✓	✓	—	✓	—
Неверный SNI / Host	—	—	✓	—	—
Доступ не из allowlist	—	—	✓	—	✓
Прямой удар в бэкенд	✓	—	—	✓	—
Brute SSH на HAProxy	✓	✓	—	—	fail2ban
DDoS L4	✓	частично	conn limits*	—	—

* Опционально: maxconn, rate-limit на frontend (Enterprise / custom); на 2.8 — sysctl, MikroTik, внешний scrubbing.

Принципы

Default deny на вход (UFW incoming deny, бэкенды — только HAProxy + admin).
Минимум открытых портов с интернета: 25, 80, 443 на одном хосте.
Не дублировать смысл правил без нужды: allowlist в HAProxy для HTTP/SNI; UFW — транспорт и админ.
Сначала dry-run, потом --apply; для SSH — console/IPMI или сессия, которую UFW не оборвёт.
Логи: HAProxy + UFW + fail2ban; алерты на аномалии (Zabbix уже в инфраструктуре).

3.0 KiB Raw Blame History Unescape Escape