# 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 |