nordabiz/docs/plans/2026-02-16-dmz-security-layer-design.md
Maciej Pienczyn 110d971dca
Some checks are pending
NordaBiz Tests / Unit & Integration Tests (push) Waiting to run
NordaBiz Tests / E2E Tests (Playwright) (push) Blocked by required conditions
NordaBiz Tests / Smoke Tests (Production) (push) Blocked by required conditions
NordaBiz Tests / Send Failure Notification (push) Blocked by required conditions
feat: migrate prod docs to OVH VPS + UTC→Warsaw timezone in all templates
Production moved from on-prem VM 249 (10.22.68.249) to OVH VPS
(57.128.200.27, inpi-vps-waw01). Updated ALL documentation, slash
commands, memory files, architecture docs, and deploy procedures.

Added |local_time Jinja filter (UTC→Europe/Warsaw) and converted
155 .strftime() calls across 71 templates so timestamps display
in Polish timezone regardless of server timezone.

Also includes: created_by_id tracking, abort import fix, ICS
calendar fix for missing end times, Pros Poland data cleanup.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-06 13:41:53 +02:00

6.1 KiB

DMZ Security Layer — OPNsense Bridge + CrowdSec

Data: 2026-02-16 Status: Zatwierdzony — do realizacji w przyszłej sesji (roadmap) Autor: Maciej Pienczyn + Claude

Problem

FortiGate-500D (R11-FORTI-01) jest po End of Support Life (EOSL: 2023-05-08), FortiOS 6.4 EOS: 2024-09-30. Wszystkie subskrypcje FortiGuard wygasły — brak aktualizacji IPS, AV, WebFilter. Serwery INPI (NPM, NordaBiz i inne) są narażone na ataki bez aktualnych sygnatur bezpieczeństwa.

Decyzja

Wdrożenie OPNsense VM w trybie transparent bridge + CrowdSec jako warstwa bezpieczeństwa DMZ. FortiGate pozostaje jako router NAT/VPN, ale ruch do serwerów przechodzi przez dodatkową inspekcję.

Architektura

Topologia sieci (po wdrożeniu)

Internet → FortiGate (NAT/VPN) → [OPNsense Bridge VM 155] → Serwery INPI
                                   ↑                          ↑
                              Suricata IPS              CrowdSec agents
                              CrowdSec bouncer          (NPM, NordaBiz)

OPNsense VM 155 — Specyfikacja

Parametr Wartość
VM ID 155
IP Management 10.22.68.155
Node r11-pve-03 (10.22.68.123)
vCPU 4
RAM 4 GB
Disk 32 GB (local-lvm)
OS OPNsense 24.7
Rola Transparent bridge + IPS

Interfejsy sieciowe (3 NIC)

NIC Bridge Proxmox Rola IP
vtnet0 vmbr0 Bridge IN (od FortiGate) Brak (bridge)
vtnet1 vmbr1 (nowy) Bridge OUT (do serwerów) Brak (bridge)
vtnet2 vmbr0 Management 10.22.68.155/24

Bridge pair: vtnet0 + vtnet1 tworzą transparentny most. Ruch przechodzi bez zmiany adresów IP.

Suricata IPS

  • Rulesets: ET Open (Emerging Threats) — darmowe, aktualizowane codziennie
  • Tryb startowy: IDS (tylko alerty, bez blokowania) — przez 1 tydzień
  • Tryb docelowy: IPS (inline blocking) — po walidacji false positives
  • Kategorie reguł: exploit, malware, trojan, web-server, sql-injection, web-attack
  • Interfejs inspekcji: Bridge interface (vtnet0/vtnet1)

CrowdSec — Rozproszone agenty

Agent na NPM (VM 119, 10.22.68.250)

  • Parser: nginx logs
  • Scenariusze: HTTP brute-force, path traversal, scanner detection, bad user agents
  • Instalacja: Docker sidecar obok NPM

Agent na NordaBiz (VM 249, 57.128.200.27)

  • Parser: Flask/Gunicorn access logs
  • Scenariusze: Login brute-force, honeypot triggers, rate limit abuse
  • Instalacja: Pakiet systemowy

Bouncer na OPNsense (VM 155)

  • Typ: OPNsense CrowdSec plugin (os-crowdsec)
  • Funkcja: Blokuje IP z community blocklist + lokalnych decyzji
  • Aktualizacja: Co 30 sekund z CrowdSec LAPI

Przepływ ruchu (szczegółowy)

1. Klient → FortiGate port9 (WAN, 85.237.177.83)
2. FortiGate DNAT → IP serwera (np. 10.22.68.250 dla NPM)
3. FortiGate → vtnet0 (OPNsense bridge IN)
4. OPNsense: Suricata inspekcja + CrowdSec bouncer check
   - Jeśli zablokowany → DROP (silent)
   - Jeśli OK → forward
5. vtnet1 (bridge OUT) → serwer docelowy
6. Odpowiedź: serwer → vtnet1 → Suricata → vtnet0 → FortiGate → klient

Integracja z infrastrukturą INPI

System Akcja Skill
Proxmox Utworzenie VM 155 na r11-pve-03 proxmox-manager
phpIPAM Rezerwacja 10.22.68.155 ipam-manager
Technitium DNS Rekord A: opnsense.inpi.local → 10.22.68.155 dns-technitium-manager
FortiGate Weryfikacja routingu po bridge insertion fortigate-manager

Plan wdrożenia (6 faz)

Faza 1: CrowdSec na istniejących serwerach (bez przestoju)

  • Instalacja CrowdSec agent + bouncer na NPM (VM 119)
  • Instalacja CrowdSec agent na NordaBiz (VM 249)
  • Konfiguracja parserów i scenariuszy
  • Rejestracja w CrowdSec Console (community blocklist)

Faza 2: Przygotowanie infrastruktury

  • Rezerwacja IP 10.22.68.155 w phpIPAM
  • Rekord DNS opnsense.inpi.local
  • Utworzenie vmbr1 na r11-pve-03 (nowy bridge Proxmox)
  • Utworzenie VM 155 z 3 NIC

Faza 3: Konfiguracja OPNsense

  • Instalacja OPNsense 24.7 z ISO
  • Konfiguracja interfejsu management (vtnet2 → 10.22.68.155)
  • Konfiguracja bridge (vtnet0 + vtnet1)
  • Instalacja pluginu os-crowdsec
  • Instalacja i konfiguracja Suricata (tryb IDS)
  • Załadowanie ET Open rulesets

Faza 4: Wstawienie bridge'a (okno serwisowe ~5 min downtime)

  • Backup konfiguracji FortiGate
  • Przełączenie kabli/VLAN:
    • FortiGate → vtnet0 (IN)
    • vtnet1 (OUT) → switch serwerowy
  • Weryfikacja łączności przez bridge
  • Test: curl -I https://nordabiznes.pl/health

Faza 5: Obserwacja (1 tydzień)

  • Suricata w trybie IDS — alerty bez blokowania
  • Analiza false positives
  • Tuning reguł (suppress, threshold)
  • CrowdSec zbiera dane z community

Faza 6: Aktywacja IPS

  • Przełączenie Suricata: IDS → IPS (inline blocking)
  • Włączenie CrowdSec bouncera na OPNsense
  • Monitoring przez 48h
  • Dokumentacja końcowa

Rollback

W każdym momencie:

  1. Wyłączenie VM 155 (OPNsense)
  2. Przełączenie kabli/VLAN z powrotem: FortiGate → switch serwerowy (bezpośrednio)
  3. Łączność wraca natychmiast (FortiGate dalej routuje normalnie)

Czas rollback: < 2 minuty (fizyczne przepięcie lub zmiana VLAN w Proxmox)

Zasoby r11-pve-03

Zasób Dostępne Wymagane Po wdrożeniu
vCPU 80 cores 4 76 wolnych
RAM 503.7 GB 4 GB 499.7 GB wolnych
Disk 320 GB free 32 GB 288 GB wolnych

Wpływ na klaster: minimalny (~5% jednego node'a).

Koszty

Pozycja Koszt
OPNsense $0 (open source)
Suricata + ET Open $0 (open source)
CrowdSec Community $0 (open source)
VM na istniejącym Proxmox $0
Razem $0

Ryzyka i mitigacja

Ryzyko Prawdopodobieństwo Mitigacja
False positives blokują ruch Średnie Start w IDS mode, 1 tydzień obserwacji
Awaria OPNsense VM Niskie Proxmox HA, szybki rollback (2 min)
Latencja przez bridge Minimalne Bridge = L2 forwarding, < 1ms overhead
Utrata sesji przy bridge insertion Pewne Okno serwisowe poza godzinami pracy