Priebežné testovanie pravidiel firewallu v Zabbixe: čo má — a čo nemá — byť dostupné

Segmentácia siete vyzerá na diagrame skvele: DMZ sa nedostane do VLAN s databázami, kancelárske stanice sa nedostanú k management rozhraniam serverov, zálohy sú dostupné iba zo zálohovacieho servera. Potom prejde rok. Niekto pridá dočasné pravidlo „any-any“, aby odladil problém. Migrácia firewallu prevedie politiky trochu inak. Nová VLAN vznikne skopírovaním starej.

Nikto pravidlá znova netestuje, takže nikto nevie, či segmentácia ešte existuje. Audítori (aj NIS2) sa pritom pýtajú čoraz častejšie práve na toto.

Myšlienka za týmto template je jednoduchá: zapíšte si očakávanú konektivitu a nechajte ju Zabbix testovať neustále — z miest, na ktorých záleží.

Template: custom-zabbix-templates/port-reachability — Zabbix 7.0+, používa štandardného Zabbix agenta.

Dva zoznamy, dva druhy upozornení

Template pripojíte k hostu so Zabbix agentom — serveru v danom segmente siete — a vyplníte dve makrá:

{$TCP_CHECKS}      = srv1:22,web01:443,db01:5432
{$NOT_TCP_CHECKS}  = db01:3306,mgmt-sw01:22,internal:8080

• {$TCP_CHECKS} — porty, ktoré majú byť dostupné z tohto hosta. Ak niektorý prestane odpovedať, dostanete „Port … is unreachable (should be reachable)“. To je prerušená cesta k službe: služba spadla alebo ju odrezala zmena vo firewalle.
• {$NOT_TCP_CHECKS} — porty, ktoré NEMAJÚ byť dostupné z tohto hosta. Ak niektorý začne odpovedať, dostanete „Port … is reachable (should NOT be reachable)“. To je únik zo segmentácie: pravidlo je príliš široké alebo bola služba vystavená tam, kde nemá byť.

Oba triggery majú závažnosť Average. Posledné údaje zobrazujú každú dvojicu s jej očakávaným stavom, takže to funguje aj ako živá dokumentácia toho, čo s čím komunikuje.

Ako to funguje

1. Discovery pravidlo typu Script (JavaScript) rozparsuje obe CSV makrá na dvojice host:port, každú označenú ako reachable alebo not_reachable. Beží každú hodinu ({$TCP_DISCOVERY_INTERVAL}).
2. Pre každú dvojicu sa vytvorí položka net.tcp.port[host,port]. Je to aktívna kontrola agenta: agent na monitorovanom hoste sám skúsi otvoriť TCP spojenie — test teda beží z daného segmentu siete, cez tie isté firewally, cez ktoré by išla skutočná prevádzka. Predvolený interval 5 minút ({$TCP_CHECK_INTERVAL}).
3. LLD overrides zapnú pre každú dvojicu iba zodpovedajúci trigger: „should be reachable“ pre prvý zoznam, „should NOT be reachable“ pre druhý.

Zmeníte makro a pri ďalšom discovery sa kontroly automaticky pridajú alebo odstránia.

Nastavenie

1. Uistite sa, že na hoste beží Zabbix agent so zapnutými aktívnymi kontrolami (ServerActive= smeruje na váš Zabbix server alebo proxy).
2. Importujte template (Data collection → Templates → Import, template_port_reachability.yaml) a pripojte ho k hostu.
3. Nastavte na hoste makrá {$TCP_CHECKS} a/alebo {$NOT_TCP_CHECKS}. Názvy hostov musia byť z agenta preložiteľné; fungujú aj IP adresy.
4. Počkajte na discovery (najviac hodinu) alebo ho spustite ručne: otvorte discovery pravidlo a kliknite na Execute now.

Kam umiestniť sondy

Jeden template, veľa pozorovacích bodov. Praktické rozloženie:

Najcennejšia je časť NEMÁ byť. Premení vašu politiku segmentácie na testy — keď niečie „dočasné“ pravidlo otvorí databázu do DMZ, viete o tom do piatich minút, nie pri ďalšom audite.

Zhrnutie

• Dve makrá: porty, ktoré musia byť dostupné, a porty, ktoré nesmú.
• Kontroly bežia z hosta s agentom, takže testujú skutočnú sieťovú cestu cez vaše firewally.
• Upozornenia na prerušené cesty k službám aj na úniky zo segmentácie.
• Umiestnite malé hosty-sondy do každého dôležitého segmentu a vaša politika firewallu sa bude testovať priebežne.

Navrhujete segmentáciu siete alebo spravujete firewally Fortinet? Ozvite sa nám.