Dokumentowanie reguł Sophos Firewall

Reguły firewalla szybko stają się nieczytelne. Na początku każda reguła jest logiczna: serwer potrzebuje dostępu do Internetu, usługa jest publikowana, VPN wymaga dostępu albo aplikacja potrzebuje określonych portów. Po kilku miesiącach często nikt już nie pamięta, dlaczego reguła istnieje, kto ją zamówił i czy nadal jest potrzebna.

Najprostszym środkiem zaradczym nie jest duża CMDB, lecz czysty opis bezpośrednio w regule Sophos Firewall. Już kilka spójnych informacji pomaga przy troubleshootingu, audytach, porządkowaniu i przekazywaniu obowiązków.

Podstawowym artykułem dotyczącym budowy reguły jest Zrozumienie i poprawna konfiguracja reguł Sophos Firewall. Po zapisaniu reguły przydatny jest artykuł Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Dlaczego Dokumentacja Reguł Jest Ważna

Reguła firewalla to nie tylko techniczne zezwolenie. To decyzja operacyjna: kto może dokąd uzyskać dostęp, przez jaką usługę, z jakim ryzykiem i z jakiego powodu.

Bez dokumentacji pojawiają się typowe problemy:

• Stare reguły pozostają aktywne, bo nikt nie zna ich celu.
• Reguły testowe nigdy nie są usuwane.
• Audyty zajmują niepotrzebnie dużo czasu.
• Incydenty trwają dłużej, bo owner aplikacji jest niejasny.
• Zmiany są wykonywane bezpośrednio na firewallu, ale nie są udokumentowane.
• Reguły nie są czyszczone z obawy przed skutkami ubocznymi.

Dobry opis nie rozwiązuje wszystkich tych problemów, ale wyraźnie zmniejsza tarcie w codziennej pracy.

Gdzie Wpisać Opis

Pole Description znajduje się bezpośrednio w regule firewall. Regułę otwiera się w:

Rules and policies > Firewall rules

Następnie należy edytować odpowiednią regułę i uzupełnić pole opisu.

Pole jest ograniczone. Nie powinno więc zastępować pełnej dokumentacji technicznej, ale ma pokazywać najważniejsze informacje operacyjne bezpośrednio na firewallu. Szczegóły mogą pozostać w tickecie, wiki, change request lub folderze projektu.

Co Powinno Znaleźć Się W Opisie Reguły

Source, Destination, Services, NAT i Security Features są już widoczne w regule. Opis nie powinien więc wszystkiego powtarzać, ale wyjaśniać to, czego później nie będzie już widać na pierwszy rzut oka.

Przydatne informacje:

• Cel: Dlaczego reguła istnieje?
• Aplikacja / usługa: Która aplikacja lub proces potrzebuje reguły?
• Owner: Kto jest odpowiedzialny?
• Ticket / change: Gdzie udokumentowano zmianę?
• Autor / edytor: Kto utworzył lub zmienił regułę?
• Data: Kiedy regułę utworzono lub ostatnio sprawdzono?
• Review: Kiedy reguła ma zostać sprawdzona lub usunięta?
• Szczególna uwaga: Świadomy wyjątek, odstępstwo lub ryzyko.

Nie każda reguła wymaga wszystkich pól. Dla standardowej reguły klienckiej często wystarczy mniej. DNAT, VPN, management, dostęp partnerów lub tymczasowe wyjątki powinny być opisane dokładniej.

Łączenie Nazwy I Description

Nazwa reguły powinna być krótka i uporządkowana. Description wyjaśnia kontekst. Nie istnieje jeden idealny schemat dla każdej firmy. Ważne jest, aby administrator, przeglądając bazę reguł, mógł mniej więcej zrozumieć, co reguła robi, bez otwierania każdej z nich.

W praktyce dobrze sprawdzają się trzy podejścia:

• Źródło, cel, usługa: VLAN12_WAN_HTTPS. Dobra standardowa metoda dla reguł klienckich, serwerowych i VPN.
• Aplikacja, źródło, cel: ERP_VPNUSERS_SRVERP_HTTPS. Przydatne, gdy aplikacja jest ważniejsza niż segment sieci.
• Typ reguły jako prefiks: DNAT_WAN_SRVWEB01_HTTPS. Pomocne przy DNAT, regułach Drop, tymczasowych i specjalnych.

Często używamy wzorca SOURCE_DESTINATION_PORT, ponieważ pozostaje techniczny i czytelny również po miesiącach. Akcja nie musi koniecznie znajdować się w nazwie, ponieważ Sophos Firewall i tak pokazuje w regule Accept, Drop lub Reject.

Typowe przykłady:

• VLAN12_WAN_HTTPS
• VLAN20_WAN_DNS
• VLANGUEST_WAN_WEB
• SRVEXC01_WAN_SMTP
• WSTONY01_SRVFILE_SMB
• VPNUSERS_SRVERP_HTTPS
• ADMINNET_FIREWALL_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• DNAT_WAN_SRVDMS01_TCP5555
• DROP_VLANIOT_INTERNAL_ANY

W zależności od środowiska schemat można lekko rozszerzyć:

• ZONE_SOURCE_DESTINATION_PORT, na przykład LAN_VLAN12_WAN_HTTPS
• APP_SOURCE_DESTINATION_PORT, na przykład ERP_VPNUSERS_SRVERP_HTTPS
• CHANGE_SOURCE_DESTINATION_PORT, na przykład CHG1842_VPNUSERS_SRVERP_HTTPS

W małych środowiskach często wystarczy prosty wzorzec. W większych środowiskach z wieloma VLANs, VPNs, sieciami serwerowymi i regułami DNAT spójny standard ma znacznie większą wartość. Prefiksy takie jak DNAT, DROP lub TEMP są sensowne, jeśli pomagają szybko skanować reguły albo wskazują specjalny typ reguły.

Lepiej unikać bardzo ogólnych nazw, ponieważ później nic z nich nie wynika:

• Rule1
• Test
• Allow
• Internet
• Temp

Kompaktowy Przykład

Przykład reguły produkcyjnej:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

Jeśli miejsca jest mało, opis może być krótszy. Cel, owner i ticket powinny jednak pozostać rozpoznawalne:

ERP VPN access, Owner Finance, CHG-1842, Review 2026-12

Dla reguły tymczasowej szczególnie jasna powinna być data wygaśnięcia:

Temp vendor access do migracji, Owner IT, CHG-1910, remove after 2026-07-31

Czego Nie Wpisywać W Description

W polu Description nie powinny znajdować się:

• hasła,
• klucze API,
• dane osobowe bez uzasadnienia,
• poufne dane klientów,
• pełne instrukcje dostępu dla osób trzecich,
• długie zewnętrzne URL bez wewnętrznego kontekstu.

Jeśli zaangażowani są zewnętrzni dostawcy, zwykle wystarczy wewnętrzna osoba kontaktowa, ticket lub odniesienie do dokumentacji. Wrażliwe szczegóły powinny znajdować się w odpowiednim systemie ticketowym, dokumentacyjnym lub menedżerze haseł, a nie w regule firewalla.

Review I Porządkowanie

Opis reguły to tylko pierwszy krok. Kluczowe jest regularne sprawdzanie reguł.

Praktyczna procedura:

1. Oznaczyć reguły bez Description.
2. Sprawdzić reguły z Test, Temp, Allow any lub niejasną nazwą.
3. Przeanalizować Usage Counter i Log Viewer.
4. Znaleźć ownera lub ticket.
5. Niepotrzebne reguły wyłączyć, obserwować i później usunąć.
6. Udokumentować zmianę.

Przy każdym porządkowaniu Log firewall traffic powinien być włączony dla istotnych reguł, aby Log Viewer pokazywał, czy reguła jest jeszcze używana. Do testów po zmianach przydaje się Testowanie reguły Sophos Firewall za pomocą Log Viewer i Packet Capture.

Minimalny Standard Dla Nowych Reguł

Nowe reguły Sophos Firewall powinny mieć co najmniej:

• czytelną nazwę,
• jasne Source i Destination zamiast zbędnego Any,
• logging włączony dla ważnych reguł,
• Description z celem, ownerem i ticketem,
• datę review dla reguł tymczasowych lub ryzykownych,
• brak sekretów w polu opisu,
• test po zapisaniu.

Dla publikowanych serwerów istotny jest również artykuł Publikowanie serwera przez DNAT na Sophos Firewall. Podstawy NAT opisuje Zrozumienie NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

FAQ