Przejdz do tresci
Avanet

Prawidłowe używanie IP hosts, Services i grup w Sophos Firewall

Sophos Firewall

IP hosts i Services nadają zrozumiałe nazwy adresom, sieciom i portom. Dzięki temu reguła firewalla od razu pokazuje, które źródło może komunikować się z jakim celem i Service.

Najważniejszy jest właściwy zakres: pojedynczy adres tworzy się jako IP, podsieć jako Network, ciągły zakres adresów jako IP range, a mały zbiór pojedynczych adresów jako IP list. W przypadku TCP i UDP Service zwykle opisuje stały Destination Port, natomiast dynamiczny Source Port pozostaje bez zmian.

Wybór odpowiedniego obiektu hosta

W Hosts and services > IP host dostępne są cztery typy:

  • IP: dokładnie jeden adres IPv4 lub IPv6, na przykład serwer, drukarka albo system administracyjny.
  • Network: cała podsieć z maską, na przykład 198.51.100.0/24.
  • IP range: ciągły zakres, na przykład od 203.0.113.10 do 203.0.113.20.
  • IP list: kilka pojedynczych, nieciągłych adresów. Lista obsługuje maksymalnie 800 adresów IP i nie może być członkiem IP Host Group.

FQDN Host jest lepszym wyborem, gdy adres docelowy się zmienia, a istnieje stabilna nazwa DNS. Rozwiązywanie nazw, wildcardy i ograniczenia opisuje artykuł Prawidłowe używanie FQDN Hosts i Wildcard FQDNs.

Ogólna zasada brzmi: należy użyć najmniejszego stabilnego obiektu, który w pełni opisuje wymagany ruch. Obiekt typu IP obejmuje tylko jeden adres i jest zbyt wąski dla całej podsieci; sieć /24 byłaby z kolei niepotrzebnie szeroka dla jednego serwera.

Tworzenie IP host krok po kroku

Poniższy przykład reprezentuje jeden serwer testowy:

  1. Otworzyć Hosts and services > IP host i wybrać Add.
  2. Jako Name wpisać host_test_web.
  3. Ustawić IP version na IPv4.
  4. Jako Type wybrać IP.
  5. W polu IP address wpisać 192.0.2.10.
  6. Zapisać przyciskiem Save.

Adresy z sieci 192.0.2.0/24, 198.51.100.0/24 i 203.0.113.0/24 są zarezerwowane do przykładów dokumentacyjnych. W konfiguracji produkcyjnej wszystkie nazwy, adresy i rozmiary sieci należy zastąpić wartościami z rzeczywistego środowiska.

Network, range i IP list

Pola zmieniają się zależnie od wybranego typu:

  • Network: net_test_branch z 198.51.100.0 i /24 reprezentuje całą sieć testową. Należy podać adres sieci, a nie adres gatewaya.
  • IP range: range_test_admins od 203.0.113.10 do 203.0.113.20 reprezentuje ciągłą pulę.
  • IP list: list_test_hosts może zawierać na przykład 192.0.2.10,198.51.100.20. Lista jest odpowiednia dla kilku stałych pojedynczych adresów, ale nie dla stale zmieniających się Indicators of Compromise.

Dla dynamicznie utrzymywanych złośliwych adresów IP, domen lub URL właściwą funkcją są Threat Feeds w Sophos Firewall. Ręczna IP list nie jest aktualizowana automatycznie.

IP Host Groups

W Hosts and services > IP host group można grupować hosty o tym samym przeznaczeniu. Grupa może na przykład zawierać wszystkie dozwolone systemy administracyjne, a następnie być używana w wielu regułach.

Obowiązują trzy ważne ograniczenia:

  • Hosty IPv4 i IPv6 nie mogą znajdować się w tej samej IP Host Group.
  • Zwykły host może należeć do kilku grup.
  • Obiektu typu IP list nie można dodać do IP Host Group.

Grupy powinny mieć wspólne znaczenie. Zbiorcza grupa zawierająca serwery, klientów i tymczasowe wyjątki może ograniczyć liczbę kliknięć, ale później utrudnia zrozumienie, dlaczego reguła zezwala na dostęp.

Rozumienie hostów systemowych i interfejsowych

SFOS automatycznie tworzy kilka obiektów hostów. Nie należy odtwarzać ich jako zwykłych Custom Hosts ani zmieniać w niewłaściwym miejscu:

  • Interface Hosts podążają za konfiguracją IP w Network > Interfaces i tam są zmieniane. Artykuł Strefy i interfejsy w Sophos Firewall wyjaśnia związek między portem, strefą i regułą.
  • ##WWAN1 jest dynamicznie utrzymywany dla interfejsu Cellular WAN.
  • ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW i ##ALL_RW reprezentują dynamiczne hosty Remote Access.
  • Innych System Hosts nie można edytować ani usuwać jak własnych obiektów.

Dynamicznych hostów Remote Access nie można dodać do kolejnej IP Host Group. Physical Interface Hosts nie są dostępne w niektórych polach NAT, między innymi Translated source i Translated destination. W takim przypadku może być potrzebny osobny IP host z tym samym adresem. Jego nazwa powinna wyraźnie wskazywać związek z interfejsem, aby obiekt nie wyglądał jak niezależny adres.

Tworzenie Service z właściwym Destination Port

Przed utworzeniem nowego Service należy sprawdzić, czy istnieje już odpowiednia usługa standardowa, taka jak HTTP, HTTPS, DNS lub NTP. Custom Service ma sens, gdy aplikacja wymaga innego portu albo szczególnej kombinacji protokołów.

Poniższy przykład tworzy usługę TCP dla iPerf3:

  1. Otworzyć Hosts and services > Services i wybrać Add.
  2. Jako Name wpisać svc_iperf3_tcp.
  3. Ustawić Type na TCP/UDP, a Protocol na TCP.
  4. Pozostawić domyślny Source Port 1:65535 bez zmian.
  5. Jako Destination Port wpisać 5201.
  6. Zapisać przyciskiem Save.

Klient zwykle wybiera Source Port dynamicznie. Gdyby Service ograniczał go również do 5201, zwykłe połączenie przestałoby pasować. Stały port serwera należy więc podać jako Destination Port. Wąski Source Port jest poprawny tylko wtedy, gdy protokół wymaga go wprost, a rzeczywisty ruch potwierdza takie zachowanie.

Dla testu UDP w iPerf3 tworzy się również svc_iperf3_udp z protokołem UDP i Destination Port 5201. Ponieważ iPerf3 nadal używa połączenia sterującego TCP podczas testu UDP, oba Services należy połączyć:

  1. Otworzyć Hosts and services > Service group i wybrać Add.
  2. Jako Name wpisać grp_iperf3.
  3. Wybrać svc_iperf3_tcp i svc_iperf3_udp.
  4. Zapisać przyciskiem Save.

Pełną procedurę pomiaru opisuje artykuł Test szybkości iPerf3 przez Sophos Firewall.

IP, ICMP i ICMPv6

Oprócz TCP i UDP Custom Service może opisywać numer protokołu IP albo typy i kody ICMP/ICMPv6. Te typy są przeznaczone dla protokołów, które nie używają portów TCP ani UDP. Wartości powinny pochodzić z dokumentacji technicznej aplikacji, a nie być zgadywane po pojedynczym nieudanym teście.

Używanie obiektów w regule firewalla

Sam obiekt hosta lub Service nie zezwala na ruch. Zaczyna działać dopiero jako kryterium dopasowania w regule. Wąski przykład może wyglądać następująco:

  • Source zones: LAN
  • Source networks and devices: net_test_branch
  • Destination zones: DMZ
  • Destination networks: host_test_web
  • Services: HTTPS
  • Log firewall traffic: włączone

Strefy, adresy i Service należy dostosować do rzeczywistej sieci. Ruch odpowiedzi dla dozwolonego połączenia stateful jest przepuszczany automatycznie. Ta reguła nie zezwala jednak na niezależne nowe połączenia z DMZ do LAN. Artykuł Rozumienie i bezpieczna konfiguracja reguł Sophos Firewall wyjaśnia kolejność, funkcje ochronne i testowanie.

Po zapisaniu należy sprawdzić rzeczywistą próbę połączenia w Log Viewer. Powinny być widoczne oczekiwane Rule ID, Source IP, Destination IP i Destination Port. Pozwala to odróżnić źle zdefiniowany obiekt od ruchu przetwarzanego przez inną regułę.

Aktualizacja Object Usage przed zmianami

Obiekt może być używany w regułach firewalla i NAT, VPN, trasach SD-WAN lub innych konfiguracjach. Przed zmianą albo usunięciem trzeba więc najpierw sprawdzić jego zależności.

Kolumna Usage na liście obiektów pokazuje znaną liczbę odwołań. Licznik jest automatycznie aktualizowany tylko raz dziennie. Przed zmianą:

  1. Wybrać Refresh obok Usage.
  2. Otworzyć zaktualizowany licznik danego obiektu.
  3. Rozwinąć kategorie i sprawdzić każdą zależną regułę lub Policy.
  4. Dopiero wtedy zdecydować, czy obiekt można zmienić, zastąpić lub usunąć.

Nie każdą zależność można edytować bezpośrednio z widoku Usage. Niektóre, w tym WAN gateways i konfiguracje CLI, trzeba otworzyć osobno we wskazanym miejscu konfiguracji. Licznik równy zero jest wiarygodną podstawą dopiero po ręcznym Refresh.

Unikanie typowych błędów

  • Host zamiast Network: Pojedynczy adres IP nie obejmuje automatycznie powiązanej podsieci.
  • Błędny adres sieci lub maska: W obiekcie Network adres sieci i prefiks muszą odpowiadać rzeczywistej segmentacji.
  • Ograniczony Source Port: W zwykłych połączeniach klient-serwer pozostaje 1:65535; ograniczany jest Destination Port.
  • Zbyt szerokie Any: Precyzyjny obiekt hosta traci wartość bezpieczeństwa, jeśli źródło lub Service pozostają niepotrzebnie szerokie.
  • Duplikat obiektu systemowego: SFOS utrzymuje hosty interfejsowe i Remote Access, dlatego nie należy ich kopiować bez konkretnego powodu.
  • IP list jako Threat Feed: IP list pozostaje statyczna i nie zastępuje automatycznie aktualizowanych wskaźników zagrożeń.
  • Nieodświeżone zależności: Przed edycją lub usunięciem obiektu zawsze należy wybrać Refresh w Object Usage.

Opisowe prefiksy, takie jak host_, net_, range_, svc_ i grp_, nie są wymaganiem technicznym, ale ułatwiają wyszukiwanie i przegląd. Ważniejsze od konkretnego schematu jest konsekwentne stosowanie nazw, celów i zakresów w całym zestawie reguł.

SFOS obsługuje łącznie do 16 000 hostów wszystkich typów. W codziennej pracy mniejsza i zrozumiała baza obiektów nadal jest cenniejsza niż wiele prawie identycznych wpisów. Nieużywane obiekty należy usuwać w sposób kontrolowany po odświeżeniu i sprawdzeniu ich Usage.