Przejdz do tresci
Avanet

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

Sophos Firewall

IP hosts i usługi 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 usługą.

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 usługa zwykle opisuje stały Destination Port, natomiast dynamiczny Source Port pozostaje bez zmian.

W przypadku nowej reguły najkrótsza bezpieczna droga prowadzi od najmniejszego odpowiedniego obiektu hosta, przez istniejącą lub własną usługę, do ściśle ograniczonej reguły firewalla. Dopiero później należy zająć się przypadkami szczególnymi, takimi jak System Hosts, MAC Hosts i grupy wielokrotnego użytku. Przed każdą późniejszą zmianą Object Usage wskazuje reguły i zasady zależne od obiektu.

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. Aktualna pomoc SFOS 22 zawiera zdanie „For IP list, use only class B IP addresses.” Ponieważ Sophos nie wyjaśnia tej przestarzałej terminologii klas sieci, nie należy z niej wnioskować, że obsługiwane są dowolne listy IPv4 lub IPv6.

FQDN Host jest lepszym wyborem, gdy adres docelowy się zmienia, a istnieje stabilna nazwa DNS. Rozwiązywanie nazw, symbole wieloznaczne 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 bramy.
  • IP range: range_test_admins od 203.0.113.10 do 203.0.113.20 reprezentuje ciągłą pulę.
  • IP list: w list_test_hosts należy wpisać, rozdzielając je przecinkami, wyłącznie adresy z własnego, zweryfikowanego środowiska. Ze względu na niejasną wzmiankę o klasie B w aktualnej pomocy konkretną listę trzeba utworzyć w używanej kompilacji SFOS i zatwierdzić za pomocą reguły testowej. Lista jest odpowiednia dla kilku stałych pojedynczych adresów, ale nie dla stale zmieniających się wskaźników naruszenia bezpieczeństwa.

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łą.
  • Jeśli zgodnie z projektem operatora i sieci dodatkowy adres musi być lokalnie powiązany z interfejsem fizycznym, należy skonfigurować go jako alias IP na interfejsie fizycznym. Jeżeli pole NAT nie udostępnia odpowiedniego Interface Host, trzeba dodatkowo utworzyć jasno nazwany Custom IP Host z tym adresem. Taka sama nazwa jest jedynie przydatną konwencją, a nie wymogiem technicznym.
  • ##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.

Dla hostów wewnętrznych w podsieci aliasu SFOS musi być bramą domyślną. Jeśli urządzenie nadrzędne używa firewalla jako bramy, potrzebuje adresu IP z każdej objętej konfiguracją podsieci aliasu. Po wymianie firewalla nieaktualne wpisy ARP na urządzeniach nadrzędnych mogą czasowo uniemożliwić dostęp do aliasu IP. Wtedy należy najpierw sprawdzić i odświeżyć ich pamięć podręczną ARP, zamiast niepotrzebnie rozszerzać regułę NAT.

Dla wychodzących internetowych tras SD-WAN Sophos zaleca ponadto wybranie Internet IPv4 group albo zawartych w niej hostów domyślnych jako celu zamiast Any. Dzięki temu trasa pozostaje ograniczona do publicznych celów IPv4 i nie kieruje ruchu wewnętrznego tą samą ścieżką wyłącznie z powodu zbyt szerokiego obiektu docelowego.

Używanie MAC hosts dla bezpośrednio widocznych urządzeń

MAC host opisuje urządzenie w warstwie 2 i może zawierać jeden adres albo listę. Ma sens tylko tam, gdzie firewall widzi rzeczywisty źródłowy adres MAC. Za routerem, VPN-em lub NAT-em zwykle widzi adres MAC następnego skoku, a nie pierwotnego klienta. W regułach routowanych stabilniejszym obiektem jest więc zazwyczaj IP host albo sieć.

W Hosts and services > MAC host > Add należy nadać obiektowi czytelną nazwę i wybrać typ MAC address albo MAC list. Adres można zapisać z dwukropkami, na przykład 00:16:76:49:33:CE, albo z myślnikami, na przykład 00-16-76-49-33-CE; wiele wpisów rozdziela się przecinkami. MAC list obsługuje maksymalnie 1000 adresów MAC.

MAC host nie jest tożsamością urządzenia. Adres MAC można skopiować lub sfałszować, a ponadto może się zmieniać przy stacjach dokujących, maszynach wirtualnych lub prywatnych adresach Wi-Fi. Obiekt nadaje się jako wąskie kryterium dopasowania w kontrolowanym segmencie, ale nie jako jedyna metoda uwierzytelniania ani granica bezpieczeństwa.

Tworzenie usługi z właściwym Destination Port

Przed utworzeniem nowej usługi należy sprawdzić, czy istnieje już odpowiednia usługa standardowa. 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 usługa ograniczała 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, obie usługi 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.

Service Group może łączyć usługi domyślne i Custom Services, a jedna usługa może należeć do kilku grup. Services i Service Groups nie rozróżniają IPv4 od IPv6; wersję IP określają obiekty hostów i kontekst reguły. Domyślnych Service Groups nie można edytować ani usuwać, dlatego dla własnej kombinacji tworzy się nową grupę.

Nie można też edytować ani usuwać predefiniowanych usług ani usług używanych już w Security Policies. Zamiast obchodzić zależność, należy utworzyć potrzebny Custom Service, w kontrolowany sposób zastąpić stary obiekt w zależnych zasadach, a następnie sprawdzić zaktualizowane wskazanie Usage.

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 usługi 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 usługę należy dostosować do rzeczywistej sieci. Ruch odpowiedzi dla dozwolonego połączenia stanowego jest przepuszczany automatycznie. Ta reguła nie zezwala jednak na niezależne nowe połączenia z DMZ do LAN. Sama reguła NAT również nie udziela uprawnienia; nadal potrzebna jest odpowiednia reguła firewalla.

SFOS sprawdza reguły firewalla od góry do dołu i kończy wyszukiwanie po pierwszym dopasowaniu. Nową, szczegółową regułę należy więc umieścić nad regułą szerszą, która w przeciwnym razie jako pierwsza przejęłaby ten sam przepływ. 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. Filtry adresu testowego, portu i reguły pozwalają wyodrębnić właściwy przepływ, a w widoku szczegółowym sprawdzić Rule ID, Source, Destination i Service. Pozwala to odróżnić źle zdefiniowany obiekt od ruchu przetwarzanego przez inną regułę. Jeśli połączenie zostanie przerwane bez zdarzenia Destroy rozpoznanego przez firewall, może zabraknąć końcowego wpisu sesji; lepszą weryfikację zapewniają wtedy Packet Capture i Live Connections.

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 zasadę.
  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 bramy WAN i konfiguracje CLI, trzeba otworzyć osobno we wskazanym miejscu konfiguracji. Licznik równy zero jest wiarygodną podstawą dopiero po ręcznym Refresh.

Bezpieczne zarządzanie obiektami

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 usługa 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ł.

Utrzymywanie małego i przejrzystego zbioru

SFOS obsługuje łącznie do 16 000 hostów wszystkich typów. Jest to limit platformy, a nie cel planistyczny. W codziennej pracy mniejsza i zrozumiała baza obiektów jest cenniejsza niż wiele trudnych do rozróżnienia wpisów. Niepotrzebne obiekty należy zastępować lub usuwać w sposób kontrolowany, dopiero po odświeżeniu i sprawdzeniu ich Usage.