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
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>
175 lines
6.1 KiB
Markdown
175 lines
6.1 KiB
Markdown
# 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 |
|