Konfiguracja i testowanie Application Control na Sophos Firewall

Application Control rozpoznaje ruch aplikacji, którego nie da się sensownie rozróżnić wyłącznie na podstawie portów. Sophos Firewall może dzięki temu precyzyjnie zezwalać na narzędzia do zdalnego sterowania, aplikacje tunelujące, transmisje strumieniowe czy usługi przechowywania danych w chmurze albo je blokować. Trafienie jest rejestrowane przez powiązaną regułę zapory; Application Filter nie ma własnej akcji Log.

Podstawowy proces jest krótki: w sekcji Applications > Application filter tworzy się filtr, w sekcji Rules and policies > Firewall rules przypisuje się go do faktycznie dopasowanej reguły, a następnie sprawdza Rule ID, aplikację i akcję przy użyciu rzeczywistego klienta. Samo zapisanie Filter Policy nie zmienia ruchu.

Określanie wymagań i celu

Application Control należy do Web Protection Subscription. Stan licencji sprawdza się w sekcji Administration > Licensing. Przed rozpoczęciem konfiguracji należy również ustalić:

• objęte zmianą konto użytkownika lub zakres sieci oraz używane przez nie ścieżki IPv4/IPv6;
• aplikację lub grupę, która ma być najpierw monitorowana albo blokowana;
• regułę zapory, która obecnie obsługuje ten ruch;
• klienta testowego, powtarzalny scenariusz testowy i oczekiwany wynik;
• aktualnie przypisany Application Filter, pozycję reguły oraz istniejące mapowanie NAT jako stan wyjściowy na potrzeby wycofania zmian.

Aktualizacje sygnatur sprawdza się w sekcji Backup & firmware > Pattern updates. Domyślnie są wykonywane automatycznie; w razie potrzeby opcja Update pattern now aktualizuje wszystkie definicje wzorców z wyjątkiem wzorców firmware’u urządzeń AP i RED. W ustaleniu przyczyny problemu pomagają stany Ready to install, Downloading, Success i Failed. Sygnatury aplikacji pozostają dostępne nawet bez aktywnej licencji IPS, natomiast sygnatury IPS wymagają odpowiedniej licencji i włączonego systemu IPS. Sophos dokumentuje wyjątek dla instalacji air gap: sygnatury IPS i aplikacji są aktualizowane również wtedy, gdy ochrona IPS jest wyłączona.

W regule testowej należy włączyć Log firewall traffic. Rejestrowaniem steruje reguła zapory, a nie Application Filter. Jeśli celem jest wyłącznie obserwacja, należy więc użyć filtra zezwalającego i przeanalizować rozpoznany ruch, zanim poszczególne aplikacje zostaną ustawione na Deny.

Jeśli właściwym celem jest priorytetyzacja lub ograniczenie przepustowości, filtr można uzupełnić zgodnie z instrukcją Konfiguracja funkcji Application Traffic Shaping na Sophos Firewall. Trasy SD-WAN oparte na aplikacjach korzystają natomiast z obiektu Application Object; procedurę przedstawiono w artykule Konfiguracja trasy SD-WAN na Sophos Firewall z przełączaniem awaryjnym bramy.

Planowanie i tworzenie filtra aplikacji

W sekcji Applications > Application list można sprawdzić, czy Sophos udostępnia sygnaturę danej aplikacji oraz do jakiej kategorii i poziomu ryzyka jest ona obecnie przypisana. Dla pola Name filtra dostępne są operatory contains, is, is not i does not contain. Obecność aplikacji w katalogu nie dowodzi jeszcze, że zostanie ona rozpoznana we własnej sieci; potwierdzi to dopiero późniejszy test z klienta.

Stała lista pojedynczych aplikacji zapewnia przewidywalne działanie. Kryteria takie jak Risk, Category lub dostępna tylko dla aplikacji chmurowych Classification pozostają natomiast dynamiczne: w przyszłości mogą zacząć do nich pasować nowe lub przeklasyfikowane sygnatury. Takie reguły wymagają wskazania udokumentowanego właściciela oraz przeglądu po zmianach wzorców lub klasyfikacji.

Pełna ścieżka tworzenia polityki i jej reguły wygląda następująco:

Applications > Application filter > Add
Applications > Application filter > Edit policy > Add

1. Za pomocą opcji Add nadać jednoznaczną nazwę, na przykład Block_File_Transfer_Pilot.
2. Wybrać szablon. W przypadku precyzyjnej blokady Allow All jest zrozumiałym punktem wyjścia; nie należy zakładać, że każda nowa pusta polityka automatycznie działa w ten sposób.
3. Zapisać politykę, ponownie ją otworzyć i utworzyć regułę filtra za pomocą opcji Add.
4. Użyć opcji Select Individual Application albo Select All, aby zawęzić dopasowania według Application, Category, Risk, Characteristics, Technology, Classification lub Smart Filter.
5. Ustawić Action na Allow lub Deny.
6. W sekcji Schedule wybrać na przykład All the time albo przypisać odpowiedni harmonogram.
7. Najpierw zapisać regułę filtra, a następnie politykę.

SFOS udostępnia między innymi szablony Allow All, Deny All, Block filter avoidance apps, Block generally unwanted apps, Block high risk (Risk Level 4 and 5) apps, Block peer to peer (P2P) networking apps i Block very high risk (Risk Level 5) apps. Szablon jest punktem wyjścia, a nie gotową konfiguracją standardową. Szczególnie reguły oparte na Risk i Category należy przed szerokim wdrożeniem porównać z aplikacjami potrzebnymi we własnej sieci.

Reguły zależne od czasu wymagają odpowiedniego harmonogramu. Sposób jego tworzenia oraz sprawdzania względem czasu zapory i reguł awaryjnych opisano w artykule Konfiguracja harmonogramów reguł i polityk na Sophos Firewall.

Przykład: blokowanie transferu plików przez przeglądarkę

Oficjalny przykład nie wpływa na inne aplikacje do przesyłania plików i ogranicza wyłącznie transfery realizowane w przeglądarce:

1. Utworzyć politykę Block_File_Transfer_Pilot na podstawie Allow All i ponownie ją otworzyć.
2. Utworzyć regułę za pomocą Add > Select All.
3. Wybrać Category: File Transfer, Characteristics: Transfer files i Technology: Browser Based.
4. Ustawić Action: Deny i Schedule: All the time.
5. Zapisać regułę filtra i politykę.

Taki wybór może również objąć prawidłowe operacje przesyłania danych, współpracy lub tworzenia kopii zapasowych. Klient pilotażowy powinien więc przetestować zarówno transfer przeznaczony do zablokowania, jak i wyraźnie dozwoloną usługę biznesową z tego samego zakresu.

Przypisywanie filtra do właściwej reguły zapory

Application Control działa dopiero po zastosowaniu w regule zapory. Aktualna ścieżka tworzenia nowej reguły wygląda następująco:

Rules and policies > Firewall rules
> IPv4 lub IPv6
> Add firewall rule
> New firewall rule
> Other security features
> Identify and control applications (App control)

W istniejącej regule należy bezpośrednio otworzyć sekcję Other security features i wybrać w niej przygotowany Application Filter. Opcja Log firewall traffic powinna pozostać aktywna w fazie pilotażowej i podczas odbioru konfiguracji.

Reguła musi faktycznie odpowiadać wartościom Source Zone, Source Network, Destination Zone, Destination Network i Services klienta testowego oraz, w razie potrzeby, warunkowi Match known users. Reguły zapory są przetwarzane od góry do dołu, a pierwsze dopasowanie kończy wyszukiwanie. Dlatego częstszą przyczyną problemu niż sam Application Filter jest bardziej ogólna reguła umieszczona wyżej.

W przypadku nowej reguły dostępu do Internetu poprawna musi być również ścieżka NAT. W przykładach Sophos opcja Create linked NAT rule może utworzyć regułę MASQ. W istniejącym środowisku nie należy na wszelki wypadek tworzyć drugiej reguły NAT; zamiast tego trzeba sprawdzić już działającą regułę SNAT/MASQ i zanotować jej NAT Rule ID.

Protokoły IPv4 i IPv6 korzystają z odrębnych ścieżek reguł. Jeśli klient używa obu protokołów, należy przetestować oba albo świadomie ograniczyć pilotaż do jednego z nich. Podstawy działania reguł opisano w artykule Reguły Sophos Firewall — zasady działania i bezpieczna konfiguracja.

Potwierdzanie działania za pomocą Live Connections i Log Viewer

Wiarygodny test odpowiada na trzy odrębne pytania: która reguła obsługuje przepływ, jaką aplikację rozpoznaje SFOS i jaka akcja zostaje wykonana?

1. Zanotować klienta testowego, źródłowy adres IP, użytkownika, godzinę i cel.
2. Opcjonalnie wybrać Reset data transfer count w opcjach reguły pilotażowej, aby ułatwić przypisanie nowych bajtów.
3. Rozpocząć test i sprawdzić nadal otwarte połączenie w sekcji Current activities > Live connections.
4. Porównać widoczne tam Application, Source IP, Username, Interfaces, porty źródłowe i docelowe, Firewall Rule ID oraz NAT Rule ID z zaplanowaną ścieżką.
5. Otworzyć Log viewer w prawym górnym rogu interfejsu WebAdmin i filtrować według źródłowego adresu IP, użytkownika, celu, Rule ID i aplikacji.
6. Wykonać test oczekiwanej blokady oraz dozwolone wywołanie kontrolne z tego samego zakresu.

Odrzucone dopasowanie Application Filter jest widoczne jako Content Filtering > Application > Denied. Dozwolony, rozpoznany ruch znajduje się w dzienniku zapory pod pozycją Firewall > Firewall Rule > Allowed. Na potrzeby odbioru konfiguracji należy udokumentować co najmniej Firewall Rule ID, Application Filter, aplikację, kategorię, ryzyko, akcję, użytkownika, źródło i cel.

Sesje zapory często pojawiają się dopiero przy zdarzeniu Connection Destroy event, gdy SFOS zamknie połączenie. Otwarta sesja przeglądarki lub transmisji strumieniowej może więc być już widoczna w sekcji Live connections, mimo że nie ma jeszcze jej końcowego wpisu w dzienniku zapory. Połączenia SSL/TLS są rejestrowane po zakończeniu uzgadniania oraz przy zamknięciu.

W sekcji Reports > Dashboards > Traffic dashboard > Allowed policies można dodatkowo sprawdzić ilość danych przesłanych przez reguły zezwalające. Raport nie zastępuje jednak konkretnego testu Rule ID i aplikacji. Raporty lokalne nie są dostępne na XGS 87/87w i XGS 88/88w; na tych modelach należy korzystać z kontroli dzienników i połączeń.

W przypadku syslogu lub SIEM nazwy pól zależą od formatu wyjściowego. Format Central Reporting Format używa między innymi pól fw_rule_id, app_filter_policy_id, app_name, app_category, app_risk, app_resolved_by, qualifier i status. W formacie Device Standard Format (Legacy) odpowiadające im pola noszą na przykład nazwy application_filter_policy, application_name, application_category, application_risk i appresolvedby. Pole app_resolved_by lub appresolvedby rozróżnia między innymi wartości Signature, Proxy oraz Synchronized Application Control (EAC).

Techniczne zdarzenia Application Filter i DPI trafiają do pliku ips.log; pliki sig_upgrade.log i sigmigration.log pomagają diagnozować aktualizacje sygnatur. Przypisanie dzienników opisano w artykule Rozwiązywanie problemów z Sophos Firewall: usługi i dzienniki. Packet Capture może potwierdzić adresy IP, porty, interfejs i drogę pakietu, ale nie stanowi dowodu klasyfikacji aplikacji. Połączoną procedurę diagnostyczną przedstawiono w artykule Testowanie reguły Sophos Firewall za pomocą Log Viewer, Policy Test i Packet Capture.

Uwzględnianie HTTPS, QUIC i wyjątków internetowych

SFOS rozpoznaje wiele aplikacji na podstawie sygnatur nawet bez pełnego odszyfrowania. Oparte na adresach URL Micro Apps, takie jak transfer plików w Dropbox lub Gmailu, wymagają jednak dostępu do odszyfrowanego adresu URL w ruchu szyfrowanym. W ścieżce DPI potrzebna jest do tego odpowiednia reguła w sekcji Rules and policies > SSL/TLS inspection rules. Opcja Scan HTTP and decrypted HTTPS włącza skanowanie w poszukiwaniu złośliwego oprogramowania dla już odszyfrowanego HTTPS, ale sama nie włącza odszyfrowywania.

W ścieżce proxy odszyfrowywanie realizuje opcja Decrypt HTTPS during web proxy filtering. Istnienie Web Policy nie dowodzi ani tego, że HTTPS jest odszyfrowywany, ani tego, że ma zastosowanie ta sama reguła DPI. Kontrolowany proces wdrożenia opisano w artykule Prawidłowe wdrażanie inspekcji TLS na Sophos Firewall.

Opcja Block QUIC protocol odrzuca w zakresie reguły zapory wychodzące pakiety UDP kierowane na porty 80 i 443, aby klienci korzystali zamiast tego z możliwej do skontrolowania ścieżki TCP. SFOS domyślnie zaznacza tę opcję po wybraniu Web Policy albo włączeniu Scan HTTP and decrypted HTTPS. Filtr internetowy nie może skanować protokołu QUIC, ale nie oznacza to, że omijane są wszystkie pozostałe mechanizmy kontroli zapory. Test pozytywny i negatywny opisano w artykule Prawidłowe blokowanie QUIC i HTTP/3 na Sophos Firewall.

W razie nieoczekiwanych wyników rozpoznawania należy również sprawdzić Web > Exceptions. Web Exception może pomijać odszyfrowywanie, skanowanie w poszukiwaniu złośliwego oprogramowania i treści oraz kontrole polityk, a zależnie od wybranych ustawień obowiązuje zarówno w ścieżce DPI, jak i proxy. Szeroki wyjątek może więc usunąć oczekiwany kontekst aplikacji.

Wpis Allowed w dzienniku zapory nie zawsze dowodzi, że użytkownik uzyskał dostęp w przypadku ruchu Web Proxy: zapora może najpierw przekazać połączenie do proxy, a Web Filter następnie zarejestrować je jako Blocked. W takich przypadkach dzienniki zapory i sieci Web należy analizować łącznie.

Klasyfikowanie aplikacji chmurowych

W sekcji Applications > Cloud applications SFOS pokazuje tylko ruch dozwolony i wyłącznie aplikacje, dla których zarejestrowano ruch. Widok można filtrować według daty, Classification, Category i liczby przesłanych bajtów; opcja Expand otwiera szczegóły. Brak wpisu nie wyklucza więc zablokowanej próby połączenia.

Nowe aplikacje chmurowe otrzymują początkowo Classification new. Po weryfikacji za pomocą opcji Classify przypisuje się im sanctioned, unsanctioned albo tolerated. Nowa Classification obowiązuje dla nowego ruchu, ale sama niczego nie dopuszcza ani nie blokuje. Oczekiwaną akcję realizuje dopiero Application Filter korzystający z tego kryterium i przypisany do dopasowanej reguły zapory.

Podstawowe dane o użyciu i liczbie bajtów wymagają rejestrowania ruchu przez zaporę. Liczniki wysyłania i pobierania oraz szczegóły typów plików wymagają odszyfrowywania HTTPS; według Sophos Web Policy inna niż None dodatkowo zwiększa dokładność i szczegółowość danych. Niektóre aplikacje używają własnych mechanizmów przesyłania, dlatego poszczególne pola szczegółowe mogą mimo to pozostać puste.

Za pomocą opcji Traffic shaping można przypisać rozpoznanej aplikacji chmurowej przygotowaną politykę przepustowości. To przypisanie nie zastępuje ani Application Filter, ani reguły zapory.

Przypadki szczególne: pamięć masowa online i filmy na Facebooku

Oficjalny przykład dotyczący Dysku Google łączy Application Filter Block_GoogleDrive z Web Policy BlockPersonalStorage. Filtr powstaje na podstawie Allow All, wyszukuje google drive za pomocą Smart Filter i ustawia wybrane aplikacje na Deny oraz All the time. W sekcji Web > Policies dla precyzyjnej reguły dotyczącej pamięci masowej należy wyłączyć All web traffic, wyszukać personal za pomocą opcji Add new item > Web category i ustawić odpowiednie kategorie na Block HTTP oraz Block HTTPS. Obie polityki muszą być przypisane do tej samej, faktycznie dopasowanej reguły zapory. Mechanizm działania polityk wyjaśniono w artykule Konfiguracja Web Protection na Sophos Firewall.

W przykładzie dotyczącym filmów na Facebooku należy za pomocą opcji Select Individual Application wybrać w Application Filter dopasowania dla Facebook videos. Sophos wskazuje obecnie również następujące wartości niestandardowej kategorii: facebook.com/watch, facebook.com/reel, gateway.facebook.com, facebook.com/ajax i facebook.com/stories, a także słowa kluczowe watch, reel, gateway, ajax i videos. Są to zależne od wersji wartości wyjściowe, które należy zweryfikować przed użyciem, ponieważ ogólne słowa kluczowe mogą pasować także do innych ścieżek. Kategoria musi znajdować się w regule Web Policy z akcją blokującą; obecna procedura dotycząca Facebooka nie określa tej akcji tak jednoznacznie jak przykład dotyczący pamięci masowej.

Przykład Sophos korzysta z Web Proxy, odszyfrowuje HTTPS i blokuje QUIC. Klienci muszą w tym celu ufać urzędowi certyfikacji Sophos Firewall. Istniejącego środowiska DPI nie należy przełączać na inny tryb wyłącznie na potrzeby tego szczególnego przypadku. Procedura proxy nie dowodzi równoważnego blokowania filmów Facebooka przez DPI; przed poleganiem na osobnym projekcie DPI zweryfikować go z Sophos Support i w testach klienta. Procedurę tworzenia własnych kategorii przedstawiono w artykule Tworzenie kategorii internetowych na Sophos Firewall, a dystrybucję certyfikatu urzędu certyfikacji w artykule Dystrybucja certyfikatu CA Sophos Firewall do skanowania HTTPS.

Ukierunkowane używanie Synchronized Application Control

Synchronized Application Control uzupełnia rozpoznawanie sieciowe o dane z zarządzanych punktów końcowych Sophos. Oprócz Web Protection Subscription wymaga Security Heartbeat, Network Protection Subscription, konta Sophos Fusion (dawniej Sophos Central) oraz zarządzanego punktu końcowego z licencją testową lub pełną.

Rejestrację przeprowadza się w sekcji:

System > Sophos Central > Sophos Central registration > Register

Po pomyślnej rejestracji SFOS automatycznie włącza Security Heartbeat i Synchronized Application Control. Wyłączenie Security Heartbeat powoduje również wyłączenie Synchronized Application Control, dlatego nie jest to precyzyjna metoda wycofania zmiany dotyczącej pojedynczej aplikacji.

Przy pierwszym użyciu, po rejestracji, należy sprawdzić w Sophos Fusion (dawniej Sophos Central), czy Synchronized Application Control jest włączone, i w razie potrzeby je włączyć. Domena utworzona na zaporze musi być taka sama jak domena wybrana na punkcie końcowym.

W sekcji Applications > Synchronized Application Control można wyszukiwać według nazwy, ścieżki, kategorii lub punktu końcowego oraz rozwinąć wpis, aby wyświetlić wystąpienia. Sophos obsługuje maksymalnie 15'000 aplikacji. Od wersji SFOS 20.0 MR1 system przechowuje tylko pięć najnowszych wystąpień każdej aplikacji na każdym punkcie końcowym.

Podczas migracji do SFOS 21.0 lub nowszej wersji system włącza automatyczne czyszczenie tylko wtedy, gdy Synchronized Application Control (SAC) jest włączone. Domyślny okres przechowywania wynosi dwanaście miesięcy. Jeśli wcześniej skonfigurowano inny okres, zostanie on zachowany. Jeśli SAC jest wyłączone, zarówno SAC, jak i automatyczne czyszczenie pozostają wyłączone. W ramach czyszczenia indywidualnie dodane aplikacje są również usuwane z Application Filter. Podczas migracji do SFOS 20.0 MR1 lub nowszej wersji system usuwa starsze wystąpienia; jeśli automatyczne czyszczenie nie powiedzie się z powodu braku miejsca, Sophos zaleca kontakt z pomocą techniczną.

New oznacza nowe wpisy, Mapped — aplikacje przypisane automatycznie, a Customized — wpisy zmodyfikowane ręcznie. W sekcji Manage > More options dostępne są następujące działania:

• Customize: nadać zrozumiałą nazwę i odpowiednią kategorię, a następnie wybrać Apply;
• Acknowledge: zmienić etykietę z New na Customized bez zmiany nazwy ani kategorii;
• Hide i Show: ukryć wpis lub ponownie go wyświetlić;
• Delete: usunąć aplikację, a jednocześnie usunąć ją z filtrów aplikacji, które jej używają.

Po użyciu Customize lub Acknowledge sprawdzona aplikacja jest dodawana do nowego lub istniejącego Application Filter. Następnie filtr ten przypisuje się do faktycznie zastosowanej reguły zapory. Kolejnym krokiem jest uruchomienie powtarzalnego przepływu testowego i sprawdzenie w Log Viewer oczekiwanej Rule ID, nazwy aplikacji oraz akcji. Dopiero po zakończeniu tego pilotażu wykrycie jest przekształcane w produkcyjną regułę Allow lub Deny.

Usunięty wpis pojawi się ponownie, jeśli punkt końcowy ponownie zgłosi aplikację. Przed użyciem opcji Delete należy więc sprawdzić używane filtry, a następnie wykonać nowy przepływ testowy i potwierdzić oczekiwany Rule ID. Osobny proces pilotażowy dla generatywnej sztucznej inteligencji przedstawiono w artykule Rozpoznawanie i kontrolowanie generatywnej AI za pomocą Sophos Firewall.

Pełna kontrola wyboru i konfiguracji przykładowej

Katalog, szablony i konkretne blokady

W katalogu otworzyć Filter obok odpowiedniego pola; poza Name wybrać wartość z listy. Smart Filter przeszukuje nazwy i opisy. Każda istniejąca Application Filter Policy, również niestandardowa, może służyć jako szablon. Przed skopiowaniem sprawdzić jej reguły i harmonogramy.

Kategorie opisują różne zastosowania, a nie automatyczną ocenę bezpieczeństwa:

• File transfer: transfery i wysyłanie plików; Download applications: pobieranie, udostępnianie plików, pamięć masowa i akceleratory; Storage and backup: przechowywanie plików, współpraca i przechowywanie haseł.
• Gaming: gry i konkursy; Streaming media: audio, wideo i transmisje na żywo; Social networking: sieci społecznościowe; E-commerce: aplikacje handlowe.
• Instant messenger: czat; VoIP: telefonia IP; Conferencing: spotkania wirtualne; Web mail: poczta w przeglądarce; Desktop mail: programy pocztowe.
• General internet: między innymi wiadomości, wyszukiwanie, przeglądarki, zakupy i przestrzenie robocze; General business: hosting, współpraca, księgowość i kopie zapasowe; Mobile applications: aplikacje mobilnych systemów operacyjnych; Software update: aktualizacje systemów i aplikacji.
• Infrastructure: na przykład DNS, DHCP, SMTP, MySQL, QUIC i TLS na innych portach; Network services: routing, rozruch, QoS i FTPS; P2P: udostępnianie plików peer-to-peer; Proxy and tunnel: proxy i VPN; Remote access: dostęp i pulpit zdalny; Industrial control system: komunikacja budynkowa, telekontrola i komunikacja procesowa.
• SyncAppCtl discovered: nieznane aplikacje wykryte przez SAC; Sophos applications: aplikacje Sophos przypisane przez SAC; System applications: usługi systemowe przypisane przez SAC, na przykład Windows lub Linux; Generative AI: aplikacje i usługi AI.

Allow All zezwala na wszystkie aplikacje, a Deny All je odrzuca. Block filter avoidance apps blokuje tunele, proxy i aplikacje omijające polityki; Block generally unwanted apps obejmuje między innymi transfer plików, proxy/tunele, aplikacje ryzykowne i P2P. P2P może rozpowszechniać złośliwe oprogramowanie; blokowanie ma sens, o ile nie istnieje zatwierdzona potrzeba biznesowa. Szablony wysokiego ryzyka dotyczą poziomów 4/5 albo tylko 5.

Aby zablokować pojedynczą aplikację, przefiltrować Facebook Games w Select Individual Application > Name, zaznaczyć ją i zapisać z Action: Deny, Schedule: All the time. Ta sama procedura dotyczy WhatsApp, Skype, LinkedIn lub Internet Download Manager. Dla grup użyć Category: Generative AI albo Category: P2P. Przykład UltraVPN używa Category: Proxy and Tunnel i PPTP Protocol; nie gwarantuje to wykrywania każdego tunelu VPN.

Dla Block_High_Risk_Apps, po zapisaniu i ponownym otwarciu, wybrać Add > Select All > Risk, zaznaczyć High i Very High, potwierdzić OK i ustawić Deny oraz All the time. Zapisać regułę i politykę i przypisać ją do reguły zapory Block_High_Risk_Apps_Rule. Po aktualizacjach wzorców uwzględniane są też nowe pasujące sygnatury. Starsze przykłady opisują pustą politykę zezwalającą i sekcję Advanced; w SFOS 22/23 użyć jawnie Allow All i sprawdzić przypisanie w Other security features, zamiast bez weryfikacji przenosić stare szczegóły.

Wspólne ustawienia zapory i sieci Web

Przykłady transferu plików i pamięci masowej używają reguły zapory Accept z LAN do WAN, Log firewall traffic, Rule group: None, During scheduled time: All the time i Rule position: Top. Sieci źródłowe, docelowe i usługi mają wartość Any; przykład wysokiego ryzyka używa nawet Any dla obu stref. Te szerokie wartości nie są zaleceniem dla pilotażu: ograniczyć źródło do klienta testowego, dostosować strefy i usługi do rzeczywistej ścieżki i świadomie umieścić regułę nad tą, która inaczej zostałaby dopasowana. Bez Match known users reguła dotyczy pasującego ruchu sieciowego niezależnie od użytkownika; po włączeniu tej opcji wybrać na przykład Marketing dla pamięci masowej albo Open Group dla transferu plików w User or groups > Add new item. Zastąpić te nazwy własną zatwierdzoną grupą; dziennik testowy musi pokazać poprawne przypisanie użytkownika.

W razie potrzeby Create linked NAT rule tworzy regułę z Translated source (SNAT): MASQ; w przykładzie również znajduje się ona na Top. Najpierw zapisać regułę NAT, potem regułę zapory. W istniejącej sieci nadal decyduje wcześniej sprawdzone mapowanie NAT.

Dla pamięci masowej włączyć regułę Web w Status po ustawieniu Block HTTP/Block HTTPS i zapisać. W ścieżce proxy dodatkowo blokować QUIC, włączyć Scan HTTP and decrypted HTTPS i Decrypt HTTPS during web proxy filtering oraz rozprowadzić CA przed testem.

Dla Facebooka zapisać kategorię niestandardową w Web > Categories > Add z Classification: Unproductive oraz podanymi wcześniej wartościami Domain i Keyword. W Web > Policies > Add policy > Add rule usunąć All web traffic z Activities, wybrać kategorię przez Add new item > Web category, użyć Apply selected items, sprawdzić akcje blokowania HTTP/HTTPS i stan aktywny, a następnie Save i, jeśli dotyczy, Skip this step. Zapisać wszystkie dopasowania Facebook videos w Application Filter z Deny i All the time. Pełny przykład proxy włącza dodatkowo Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, Scan FTP for malware, Decrypt HTTPS during web proxy filtering i Block QUIC protocol. Skanowanie FTP jest dodatkową ochroną, nie dowodem blokowania wideo. Podobna nazwa opcji sama nie dowodzi, że ścieżka DPI została przetestowana jako równoważna; jeśli blokada nie działa, zastosować opisany wcześniej proces diagnostyczny i eskalację do pomocy technicznej.

Kończenie operacji chmurowych i SAC

Po Classify potwierdzić Apply; po Traffic shaping wybrać istniejącą politykę i Save. Można na przykład sprawdzić aplikacje społecznościowe unsanctioned z określonego okresu lub ograniczyć strumieniowanie wideo.

Nieznane aplikacje SAC trafiają początkowo do SyncAppCtl discovered; znane są kategoryzowane automatycznie. Zawęzić zakres wyszukiwania, na przykład do System applications. Po Hide wpisy są widoczne tylko w Hidden applications; przywrócić je przez Show. Customize pozostaje dostępne również później i ustawia etykietę na Customized.

Clean up application database wymaga rejestracji w Sophos Fusion/Sophos Central. Po codziennym sprawdzeniu SFOS usuwa stare aplikacje partiami po 100 co pięć minut, w tym wpisy dodane indywidualnie do polityk. Sprawdzić ich użycie przed zmianą okresu; skrócenie go nie jest pozbawionym ryzyka rozwiązaniem problemów z miejscem. Bez ważnej Web Protection Subscription SAC można skonfigurować, ale nie używać.

Automatyzacja Application Control za pomocą XML API

Dokumentacja referencyjna XML dla SFOS 22/23 opisuje różne obiekty o podobnie brzmiących nazwach. Klasyfikacja chmurowa nie jest ani regułą filtrowania, ani globalnym przełącznikiem Device Console. Przed wywołaniem zapisującym należy zabezpieczyć istniejący stan i korzystające z niego polityki. Dostęp, interpretację odpowiedzi i bezpieczne ponawianie operacji opisano w artykule Zabezpieczanie dostępu do Sophos Firewall XML API. Poniższe struktury objaśniają udokumentowany kontrakt, a nie żądanie przetestowane na zaporze.

Pojedyncze i zbiorcze przypisania klasyfikacji chmurowych

ApplicationClassificationAssignment aktualizuje dokładnie jedno przypisanie: dwa wymagane pola Application i Classification są ciągami znaków. Przykład w dokumentacji referencyjnej podaje Facebook Website i New. Nie jest to pełny katalog dozwolonych klasyfikacji; wartości z UI i wielkość liter nie stają się automatycznie wartościami wyliczeniowymi API.

ApplicationClassificationBatchAssignment używa natomiast ClassAssignmentList z powtarzającymi się obiektami ClassAssignment. W każdym obiekcie znajdują się pola zapisane małymi literami: app i class, a nie Application i Classification. Udokumentowana struktura wygląda na przykład tak:

<ApplicationClassificationBatchAssignment>
  <ClassAssignmentList>
    <ClassAssignment>
      <app>iCloud</app>
      <class>New</class>
    </ClassAssignment>
    <ClassAssignment>
      <app>iPlay Website</app>
      <class>New</class>
    </ClassAssignment>
  </ClassAssignmentList>
</ApplicationClassificationBatchAssignment>

Nazwy są przykładami z dokumentacji referencyjnej i należy je zastąpić faktycznie istniejącymi aplikacjami. Tabela parametrów opisuje ClassAssignmentList jako opcjonalną tablicę obiektów z wieloma wartościami. Nie wynika z tego ani sensowność pustej operacji zbiorczej, ani gwarancja atomowego przetwarzania, wycofania zmian czy statusu dla każdego wpisu. Po zmianie należy osobno odczytać każde żądane przypisanie, a działanie filtra Classification sprawdzać dopiero na nowym ruchu. Dla operacji zbiorczej dokumentacja referencyjna podaje 200 z Operation Successful. i 500 z Operation Fail.; dla pojedynczej operacji podaje 200 i 500 z nierozwiniętymi symbolami odpowiednio Message.AppClassificationUpdateSuccess i Message.AppClassificationUpdateFail.

Polityka filtrowania: szablon lub własne reguły

W ApplicationFilterPolicy pierwszeństwo ma Template: jeśli zostanie przekazany, zgodnie z udokumentowanym kontraktem DefaultAction i RuleList są ignorowane. Żądanie zawierające szablon i własną regułę Deny nie stanowi zatem niezawodnego połączenia obu wariantów. Bez szablonu dokumentacja referencyjna opisuje DefaultAction z wartościami Allow lub Deny oraz RuleList/Rule dla własnych reguł. Podana jednocześnie maksymalna długość jednego znaku jest sprzeczna z tymi słowami; nie należy na tej podstawie wyprowadzać skróconej wartości jednoznakowej. Przykład XML zawiera AllowAll, podczas gdy UI wyświetla Allow All. Nie należy bez weryfikacji przyjmować tekstu z UI jako tokenu API.

W obrębie Rule znajdują się SelectAllRule, kontenery wyboru oraz Action i Schedule. Kontenery to CategoryList/Category, RiskList/Risk, CharacteristicsList/Characteristics, TechnologyList/Technology, ClassificationList/Classification i ApplicationList/Application. SelectAllRule używa w przykładzie Enable/Disable; jest to przełącznik, a nie wartość listy dla kategorii. Pierwszych pięć list pokazuje SelectALL, natomiast lista aplikacji — SelectAll. Komentarze w przykładzie wskazują, że wybór wszystkich elementów powoduje ignorowanie pozostałych wpisów na tej samej liście. Nie należy normalizować pisowni ani wyprowadzać z niej nieudokumentowanego pierwszeństwa między różnymi kryteriami. Tabela parametrów wymienia dodatkowo Search jako ciąg wyszukiwania; nie należy go mylić z SmartFilter obiektu Application Object.

Nazwa polityki jest wymagana, dopuszcza UTF-8, ale nie przecinki, i może mieć najwyżej 60 znaków; Description dopuszcza najwyżej 1000 znaków. MicroAppSupport wymienia True i False, ale nie dowodzi, że odszyfrowywanie HTTPS jest włączone. Tabela wymienia Action i Schedule jako tablice, których duplikaty nie są ignorowane, podczas gdy przykład XML pokazuje je dla każdej reguły. Nie należy zatem samodzielnie usuwać duplikatów z list ani zmieniać ich kolejności. Po zapisaniu należy odczytać akcję domyślną, kolejność, wybór i Schedule; dopiero przypisanie do odpowiedniej reguły zapory i test na kliencie potwierdzają żądaną blokadę.

Rozróżnianie QoS kategorii i obiektów SD-WAN

ApplicationFilterCategory identyfikuje istniejącą kategorię za pomocą wymaganego Name; tej nazwy kategorii nie można zmienić. Wymagane QoSPolicy na poziomie kategorii należy odróżnić od ApplicationSettings/Application/QoSPolicy: to ostatnie należy do aplikacji, której Name znajduje się w odpowiednim podobiekcie. Przykład pokazuje dodatkowo BandwidthUsageType z Individual/Shared. Uwidacznia to kontekst współdzielenia przepustowości, ale nie dowodzi istnienia pełnej reguły pierwszeństwa między przypisaniem do kategorii a przypisaniem do aplikacji. Przed zmianą należy sprawdzić istniejące przypisania QoS oraz żądane wykorzystanie wspólne lub indywidualne; procedurę operacyjną opisano w artykule Application Traffic Shaping.

ApplicationObject udostępnia wybór aplikacji dla tras SD-WAN opartych na aplikacjach, a nie ApplicationFilterPolicy z regułami Allow/Deny. Jego wymagane pola to Name i SelectAllRule (Enable lub Disable); nazwa dopuszcza UTF-8, nie dopuszcza przecinków i może mieć najwyżej 80 znaków. Przykład XML używa tych samych sześciu kontenerów wyboru co powyżej oraz dodatkowo SmartFilter jako ciągu wyszukiwania. Również tutaj pokazuje SelectALL dla kryteriów i SelectAll dla aplikacji. Widoczny wybór aplikacji nie stanowi tożsamości nazwanego obiektu: przy aktualizacji należy odczytać właściwy obiekt; w przypadku Delete ta strona Add/Edit nie stanowi potwierdzenia kontraktu dotyczącego tożsamości.

Dla Application object add i Application object edit dokumentacja referencyjna przypisuje te same kody:

Te symbole nie są pełnymi komunikatami błędów, a kody nie są automatycznie równoważne kodom statusu HTTP. Należy zapisywać łącznie operację, kod i rzeczywistą odpowiedź. Przed ponowieniem należy odczytać faktycznie zapisaną nazwę obiektu i wybór; niejasny błąd nie może prowadzić do utworzenia drugiego obiektu ani obiektu o szerszym zakresie. Dla Policy-Edit dokumentacja referencyjna podaje ponadto 502 z Message.AFPRecordExists obok 200/Message.AFPUpdateSuccess i 500/Message.AFPUpdateFail. Również tutaj znaczenie nierozwiniętego tekstu komunikatu pozostaje nieokreślone; kod powodzenia nie zastępuje ani kontroli stanu, ani testu ruchu.

Diagnozowanie problemów według objawów

• Brak oczekiwanego Rule ID: sprawdzić kolejność reguł, Source/Destination, Service, dopasowanie użytkownika oraz ścieżkę IPv4/IPv6. Dopóki przepływ trafia do innej reguły, przyczyną nie jest Application Filter.
• Brak końcowego wpisu w dzienniku zapory: najpierw znaleźć otwartą sesję w sekcji Current activities > Live connections i zakończyć ją w kontrolowany sposób. Sprawdzić rejestrowanie oraz zakres czasu filtra w Log Viewer.
• Aplikacja pozostaje unknown lub jest rozpoznawana ogólnie: sprawdzić stan wzorców, Application list, odszyfrowywanie HTTPS, QUIC oraz Web Exceptions. Packet Capture służy wyłącznie do potwierdzania ścieżki sieciowej.
• Blokada obejmuje zbyt wiele usług: zawęzić regułę opartą na Risk, Category, Classification lub Smart Filter do pojedynczych aplikacji albo mniejszej grupy. Następnie powtórzyć test blokady i wywołanie kontrolne.
• Po aktualizacji wzorców blokowanych jest więcej aplikacji: sprawdzić, która nowa sygnatura spełnia kryterium dynamiczne. Utworzyć wąski wyjątek dla wymaganej aplikacji, zamiast wyłączać cały filtr.
• Log Viewer pokazuje Allowed w dzienniku zapory, ale przeglądarka wyświetla stronę blokady: jeśli ruch jest obsługiwany przez proxy, sprawdzić również dziennik sieci Web.
• Brak szczegółów aplikacji chmurowej: osobno sprawdzić rejestrowanie ruchu przez zaporę, odszyfrowywanie HTTPS oraz Web Policy. Nie każdy mechanizm przesyłania udostępnia wszystkie pola szczegółowe.
• Filmy na Facebooku pozostają dostępne mimo kompletnej konfiguracji: sprawdzić Rule ID, Application Filter, Web Policy, aktualne wpisy kategorii, QUIC, odszyfrowywanie, zaufanie klienta do CA i Web Exceptions. Jeśli wynik testu jest powtarzalny, Sophos wskazuje pomoc techniczną jako kolejny poziom eskalacji.

Wycofywanie zmian i eksploatacja

Przed rozpoczęciem pilotażu należy udokumentować Application Filter, Web Policy, stan i pozycję reguły, mapowanie NAT, ścieżkę TLS oraz wyjątki. Zmiany wycofuje się w następującej kolejności:

1. Wyłączyć osobną regułę pilotażową albo ponownie wybrać poprzedni Application Filter lub None w istniejącej regule.
2. Przywrócić udokumentowaną pozycję reguły oraz tylko to mapowanie NAT, które jednoznacznie należało do konfiguracji pilotażowej.
3. Przy użyciu klienta kontrolnego sprawdzić, czy nowe połączenia trafiają do poprzedniego Rule ID i działają zgodnie z oczekiwaniami.
4. Dopiero potem usunąć zbędne filtry lub obiekty pilotażowe. Współdzielonych filtrów, reguł NAT ani wpisów Synchronized Application Control nie należy usuwać bez wcześniejszej weryfikacji.

Podczas eksploatacji należy dokumentować przeznaczenie, przypisane reguły zapory, kryteria dynamiczne, dozwolone wyjątki, właściciela, ostatnią zmianę i datę przeglądu. Do scentralizowanej analizy przydatne są artykuły Włączanie Central Firewall Reporting oraz Konfiguracja syslogu i SIEM na Sophos Firewall.

Zmiana globalnej klasyfikacji tylko według zaleceń Sophos Support

Application Filter reguły zapory nie jest tym samym co globalna Application Classification w Device Console. Sophos ostrzega przed zmianą tych przełączników bez polecenia pomocy technicznej. Najpierw należy jedynie odczytać stan:

system application_classification show
system application_classification microapp-discovery show

Globalna klasyfikacja jest domyślnie ustawiona na on, a microapp-discovery na off. Jeśli Sophos Support zaleci zmianę, należy udokumentować stan początkowy i numer zgłoszenia. Dostępne przełączniki to:

system application_classification on
system application_classification off
system application_classification microapp-discovery on
system application_classification microapp-discovery off

Włączenie microapp-discovery powoduje ponowne uruchomienie usług i przerwę w ruchu. Po autoryzowanej zmianie należy sprawdzić wyniki obu poleceń show, rzeczywisty przepływ aplikacji i dzienniki. Wycofanie zmiany polega na dokładnym przywróceniu stanu początkowego: wcześniejszą wartość on ustawia się za pomocą on, a wcześniejszą wartość off za pomocą off, po czym ponownie sprawdza się stan poleceniem show. W przypadku domenowych wskaźników IoC globalna klasyfikacja wpływa również na kontekst funkcji Third-Party Threat Feeds.

Często zadawane pytania