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.

Oprócz Custom IP Hosts do grupy mogą należeć także domyślne hosty interfejsów, Cellular WAN i internetu. Członkostwo w grupie jest niezależne od możliwości edycji obiektu hosta: host systemowy, którego nie można edytować bezpośrednio, nie jest więc automatycznie wykluczony z grup. Wykluczone pozostają jednak dynamiczne hosty systemowe VPN Remote Access.

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.

Aby utworzyć małą grupę testową IPv4 z wcześniej utworzonym host_test_web:

  1. Otworzyć Hosts and services > IP host group i wybrać Add.
  2. Jako Name wpisać grp_test_servers; dostosować nazwę do przeznaczenia grupy.
  3. Ustawić IP version na IPv4, zgodnie z istniejącym hostem testowym.
  4. Wybrać host_test_web przez Add new item. Dodatkowi członkowie muszą mieć to samo przeznaczenie i tę samą wersję IP.
  5. Zapisać przyciskiem Save.

Następnie ponownie otworzyć grupę i sprawdzić jej wersję IP oraz członków. Jeśli żądany host nie pojawia się na liście wyboru, najpierw sprawdzić jego wersję IP i typ; nie obchodzić wykluczenia IP list ani hosta systemowego VPN Remote Access za pomocą niepotrzebnie szerokiego obiektu zastępczego.

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

Lista IP hosts pokazuje interfejsy fizyczne, w tym dodatkowe moduły FleXi-Port, oraz samodzielnie utworzone interfejsy wirtualne. W Address details widnieją adres i maska sieci z Network > Interfaces. W przypadku nieoczekiwanej wartości najpierw porównać tę konfigurację interfejsu z wyświetlanymi danymi; automatycznie utrzymywany obiekt hosta nie jest miejscem do zmiany adresu.

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 powstaje po włączeniu Cellular WAN, używa adresu IP interfejsu WWAN i jest utrzymywany dynamicznie.
  • ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW i ##ALL_RW reprezentują dynamiczne hosty Remote Access.
  • ##ALL_SSLVPN_RW zawiera adresy IP przydzielone przez firewall nawiązanym połączeniom zdalnego dostępu SSL VPN z użyciem Sophos Connect. ##ALL_IPSEC_RW zawiera adresy przydzielone odpowiednim połączeniom IPsec. ##ALL_RW łączy adresy przydzielone obu typom połączeń; SFOS dodaje je dynamicznie podczas nawiązywania połączeń.
  • 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 pełni funkcję bramy dla ruchu Sophos Firewall, 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.

W przeciwieństwie do nieedytowalnych hostów systemowych domyślne hosty internetowe można zmieniać i usuwać. Przed taką operacją odświeżyć Object Usage zgodnie z opisem poniżej i sprawdzić zależne reguły oraz trasy SD-WAN. Ten wyjątek dotyczy hostów internetowych, a nie dynamicznych hostów systemowych VPN/WWAN; adresy interfejsów nadal zmienia się w Network > Interfaces.

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.

Przykład: blokowanie przepływu innego niż web na podstawie źródłowego MAC

Ten przykład dla SFOS 22/23 blokuje nowy przepływ IPv4 TCP iPerf3 z bezpośrednio widocznego urządzenia testowego LAN do kontrolowanego serwera testowego WAN. Nie jest to procedura blokowania całego dostępu do internetu: HTTP/HTTPS i Web Exceptions nie są objęte tym testem. Najpierw sprawdzić rzeczywisty źródłowy MAC urządzenia za pomocą Packet Capture na interfejsie wejściowym. Jeśli widoczny jest tylko router nadrzędny, reguła nie jest odpowiednia; sam port LAN przełącznika nie dowodzi widoczności w warstwie 2. Przed zmianą sprawdzić dostępność serwera WAN i portu TCP 5201. Musi tam rzeczywiście działać iPerf3, a nie usługa web.

  1. W Hosts and services > MAC host > Add wpisać mac_test_client jako Name, MAC address jako Type oraz 02:00:00:00:00:10 jako MAC address, a następnie zapisać przyciskiem Save. Nazwa i lokalnie administrowany adres unicast są przykładami; adres zastąpić zweryfikowanym MAC urządzenia.
  2. Otworzyć Rules and policies > Firewall rules, wybrać IPv4 i utworzyć drop_mac_test_wan przez Add firewall rule > New firewall rule. Ustawić Action na Drop i włączyć Log firewall traffic.
  3. Ustawić Source zones na LAN, Source networks and devices na mac_test_client oraz Destination zones na WAN. W Destination networks wybrać IP Host własnego serwera testowego WAN, a w Services svc_iperf3_tcp; tę usługę TCP z Destination Port 5201 utworzyć zgodnie z opisem w następnej sekcji. Ogranicza to cel i testową usługę inną niż web. Any nie jest wymagane w tym przykładzie.
  4. Dla stałej blokady ustawić During scheduled time na All the time, w przeciwnym razie wybrać odpowiedni harmonogram. Umieścić regułę nad regułami, które wcześniej zezwoliłyby na ten sam przepływ, nie wypierając celowych wyjątków o wyższym priorytecie. Top nie jest uniwersalnym wymogiem. Rule group może pozostać None; grupa nie zastępuje poprawnej pozycji. Zapisać przez Save i sprawdzić rzeczywistą kolejność.

Następnie z urządzenia testowego rozpocząć nową próbę połączenia TCP iPerf3 do tego samego serwera WAN na porcie 5201, nie test UDP ani test w przeglądarce. W Log Viewer Drop i Rule ID tej reguły blokującej muszą odpowiadać przepływowi. Sprawdzić ten sam przepływ inny niż web z drugiego, nieblokowanego urządzenia: nadal powinien trafiać do zamierzonej reguły Allow. W obu testach użyć nowych połączeń, nie istniejących sesji. Jeśli brakuje oczekiwanego dopasowania, sprawdzić źródłowy MAC w Packet Capture, strefy, wersję IP, harmonogram, zakres celu/usługi i wcześniejsze reguły.

Ta kontrola potwierdza tylko testowane przepływy, a nie ogólną blokadę web lub internetu. IPv6, inne strefy docelowe, cele i usługi nie są objęte przykładem i wymagają osobnej konfiguracji oraz testów. Aby wycofać zmianę, wyłączyć tylko nową regułę blokującą i nowym przepływem TCP iPerf3 sprawdzić poprzedni dozwolony stan. Opisane wyżej ryzyko spoofingu i problem tożsamości pozostają.

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.

Dla usługi typu IP w Hosts and services > Services > Add nadać odpowiednią nazwę w Name, ustawić Type na IP, wybrać wymagany numer protokołu i zapisać przyciskiem Save. Chodzi o numer protokołu IP, a nie port docelowy TCP/UDP. Następnie ponownie otworzyć usługę i porównać numer z wymaganiami aplikacji; podczas testu w ściśle ograniczonej regule sprawdzić w Packet Capture rzeczywiście obserwowany protokół. Jeśli brakuje oczekiwanego dopasowania, najpierw sprawdzić protokół i zakres reguły, zamiast przechodzić na Any.

W Hosts and services > Services > Add usługa może zawierać wiele wpisów tego samego wybranego typu. Dla ICMP lub ICMPv6 najpierw wybrać potrzebną parę typu i kodu, dodać kolejne pary przyciskiem Add, a zbędne wpisy usunąć przyciskiem Remove. Następnie sprawdzić wszystkie wpisy i zapisać przez Save. Pozwala to opisać kilka potrzebnych komunikatów ICMP w jednej usłudze bez bezwarunkowego zezwalania na wszystkie typy. Oddzielne usługi TCP/UDP i Service Group z przykładu iPerf3 pozostają czytelną alternatywą, gdy usługi mają być używane ponownie osobno.

Uwaga dotycząca wersji dokumentacji API: W zapisanej tabeli API Sophos „Add Service / Update Service” dla SFOS 22 kolumna Mandatory zawiera No zarówno dla ICMPType, jak i ICMPv6Type; dla SFOS 23 w obu przypadkach widnieje Yes. Są to oznaczenia w dokumentacji API, a nie dowód zmiany GUI ani zachowania podczas działania. Dotyczą pól ICMP/ICMPv6 i nie należy ich rozumieć jako wymogu dodawania obu rodzin protokołów do usług TCP/UDP/IP. Strona nie definiuje reguły warunkowej określającej, kiedy można pominąć te pola; z tych oznaczeń nie wynikają więc konkretne instrukcje dotyczące payloadu ani walidacji.

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.

Wyszukiwanie istniejących obiektów i ich świadome utrzymywanie

Listy w Hosts and services > IP host, IP host group, MAC host, Services i Service group można przeszukiwać według atrybutów poszczególnych obiektów. Przed utworzeniem nowego obiektu szukać nie tylko żądanej nazwy, lecz także wymaganych wartości adresów lub protokołów/portów, o ile mają zastosowanie do danego typu obiektu. Pozwala to znaleźć istniejący już odpowiedni obiekt o innej nazwie. Po zapisaniu ponownie wyszukać obiekt i sprawdzić jego wartości lub członków grupy.

Custom IP Hosts i IP Host Groups można dodawać, edytować i usuwać; własne Service Groups można również edytować, zmieniać ich nazwy, dodawać do nich usługi lub je usuwać. Zawsze najpierw odświeżyć Object Usage. Zmiana grupy wpływa na wszystkie reguły, które jej używają, a nie tylko na aktualnie opracowywany przypadek użycia. Przed zmianą zapisać dotychczasowe wartości i członków, a następnie sprawdzić objęte zmianą połączenia przy użyciu nowych sesji. Jeśli zakres jest nieprawidłowy, wycofać zmianę w sposób kontrolowany i ponownie przetestować. Opisane wyżej ograniczenia dotyczące System Hosts, domyślnych Service Groups i chronionych usług nadal obowiązują.

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.