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.

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.

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; trzeba w nim zastosować odpowiednią SSL/TLS Inspection Rule. 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.

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 danych Synchronized Application Control i domyślnie ustawia okres dwunastu miesięcy. Jeśli wcześniej skonfigurowano inny okres, zostanie on zachowany. 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.

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. Precyzyjnie wyłączyć wymaganą aplikację, 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