Skonfiguruj i przetestuj Sophos Firewall Application Control

Application Control na Sophos Firewall rozpoznaje aplikacje niezależnie od czystego portu. Dzięki temu można na przykład wyraźnie zezwalać, blokować lub rejestrować narzędzia do zdalnego sterowania, aplikacje do tunelowania, przesyłanie strumieniowe, przechowywanie w chmurze, komunikatory lub ryzykowne obejścia przeglądarki.

Praktyczna korzyść pojawia się tylko wtedy, gdy Application Control jest aktywne w prawidłowej regule zapory sieciowej, aplikacja jest faktycznie rozpoznawana i oceniane są logi. Sama zapisana polityka Application Filter niczego nie blokuje.

Krótka odpowiedź

Application Control jest używany w dwóch etapach:

1. Zaplanuj lub utwórz politykę Application Filter w Applications > Application filter.
2. Wybierz odpowiednią regułę zapory sieciowej w obszarze Inne funkcje bezpieczeństwa w obszarze Identyfikuj i kontroluj aplikacje (kontrola aplikacji).

Następnie musisz użyć prawdziwego klienta testowego, aby sprawdzić, czy ruch przebiega zgodnie z tą regułą i czy aplikacja jest poprawnie rozpoznawana w Log Viewer. W przypadku ruchu zaszyfrowanego TLS Inspection może mieć kluczowe znaczenie, ponieważ w przeciwnym razie zapora widzi mniej szczegółów, w zależności od aplikacji.

Kiedy Application Control ma sens

Application Control jest szczególnie przydatny, gdy same porty nie dostarczają wystarczających informacji. Wiele aplikacji wykorzystuje HTTPS, zmieniając cele lub infrastrukturę chmurową. Reguła czystego portu widzi wtedy tylko 443, ale nie sprawdza, czy kryje się za nią dozwolona usługa biznesowa, narzędzie do zdalnej kontroli lub niechciana pamięć w chmurze.

Typowe zastosowania:

• TeamViewer, AnyDesk, blokuj Tora lub narzędzia proxy
• Ogranicz transmisję strumieniową lub media społecznościowe w niektórych sieciach
• Kontroluj przechowywanie w chmurze
• Ogranicz komunikatory i gry w sieciach gościnnych lub szkolnych
• Włącz wykrywanie aplikacji na potrzeby raportowania i analiz
• Przygotuj kształtowanie ruchu dla wykrytych aplikacji

Jeśli nie chodzi o wykrywanie lub blokowanie, ale o ustalanie priorytetów lub ograniczanie przepustowości, odpowiednia jest również opcja Konfiguruj kształtowanie ruchu aplikacji na Sophos Firewall.

Wymagania wstępne

Przed konfiguracją należy sprawdzić następujące punkty:

• odpowiednia licencja z ochroną sieciową lub Application Control
• znana jest reguła zapory, której dotyczy problem
• Log firewall traffic jest aktywny dla reguły testowej
• żądane zastosowanie lub kategoria są technicznie jasne
• Zdefiniowano klienta testowego i cel testowy
• dla aplikacji HTTPS jest jasne, czy należy użyć TLS Inspection
• Podpisy aplikacji i aktualizacje sygnatur działają

Status licencji można sprawdzić pod adresem System > Administration > Licensing. Typowe pakiety zapory sieciowej Sophos z funkcją Web Protection obejmują Application Control. Konkretną logikę licencji należy jeszcze sprawdzić przed produktywnym wdrożeniem, szczególnie w przypadku wygasłych subskrypcji lub licencji testowych.

Plan Application Filter

Dobry Application Filter to nie tylko długa lista bloków. Po pierwsze, powinno być jasne, co ma zostać osiągnięte.

• Blokuj ryzykowne narzędzia do zdalnego sterowania: Blokuj wybrane aplikacje lub kategorie.
• Ogranicz Wi-Fi dla gości: Blokuj niechciane kategorie i pozostaw otwarte dozwolone usługi podstawowe.
• Tylko aplikacja rejestrująca: początkowo używaj Allow do rejestrowania i raportów.
• Unikaj fałszywych alarmów: użyj węższego wyboru aplikacji zamiast szerokiej kategorii.
• Nadaj priorytet aplikacjom o znaczeniu krytycznym: Połącz Application Control z kształtowaniem ruchu.

Tryb monitorowania często ma sens w przypadku sieci produktywnych: najpierw aktywuj Application Control, sprawdź dzienniki i raporty, a następnie specjalnie go zablokuj. W ten sposób możesz sprawdzić, które aplikacje naprawdę istnieją i czy blokada zakłóci legalne procesy.

Jeżeli kryteria są szerokie, należy wziąć pod uwagę przyszłą opiekę. Nowe aplikacje są automatycznie uwzględniane w politykach Application Filter i regułach zapory sieciowej poprzez aktualizacje bazy sygnatur aplikacji. Na przykład, jeśli reguła blokuje wszystkie aplikacje wysokiego ryzyka, nowy podpis wysokiego ryzyka może zostać później zablokowany bez dalszych ręcznych zmian zasad. Jest to pożądane, ale musi być znane w procesie zmian i przeglądu.

Planuj wdrażanie etapami

Application Control nie powinien być uzbrajany dla wszystkich sieci w jednym dużym kroku. Lepiej mieć mały rollout z przejrzystą grupą testową, widocznym rejestrowaniem i określoną decyzją, kiedy obserwacja stanie się blokiem.

Praktyczny proces:

• Inwentarz: Dowiedz się, jakie aplikacje faktycznie występują. W tym celu użyj Application Filter z logowaniem, jeszcze bez szerokiego blokowania.
• Pilot: Sprawdź wybranych użytkowników lub sieć testową. Blokuj pojedyncze ryzykowne aplikacje i ściśle kontroluj Rule ID i logi.
• Produkcja: Zastosuj potwierdzone zasady do sieci docelowej. Aktywuj filtry w regułach produkcyjnych i wyjątki w dokumentach.
• Działanie: Monitoruj działanie i skutki uboczne. Regularnie sprawdzaj raporty Log Viewer, Central Reporting lub Syslog.

Przed uruchomieniem powinno być jasne, które aplikacje muszą pozostać dozwolone. Często obejmują one usługi aktualizacji, zdalne wsparcie, narzędzia do współpracy, przechowywanie w chmurze, telefonię lub aplikacje branżowe. Jeśli te zależności staną się widoczne dopiero po bloku, Application Control szybko zacznie działać jak czynnik zakłócający, a nie funkcję ochronną.

Warto sporządzić krótką listę decyzji do akceptacji: która aplikacja jest zablokowana, jakiej grupy użytkowników to dotyczy, jaki wyjątek jest dozwolony, kto jest właścicielem technicznym i kiedy polityka zostanie ponownie sprawdzona? Ta dokumentacja jest ważniejsza niż idealny pierwszy filtr.

Rozróżnianie Application Filter, Application Object i kształtowanie

Terminy są do siebie zbliżone, ale dotyczą różnych zadań. To oddzielenie pozwala zaoszczędzić wiele problemów:

• Application Filter: określa, które aplikacje są dozwolone, blokowane lub rejestrowane. Typowe dla narzędzi do zdalnego sterowania, przechowywania w chmurze lub trybu obserwacji.
• Application Object: podsumowuje aplikacje jako obiekt. Przydatne w przypadku grup wielokrotnego użytku, gdy ten sam wybór jest używany wielokrotnie.
• Application-based Traffic Shaping: nadaje priorytet lub ogranicza wykryte aplikacje. Typowe dla ustalania priorytetów w aplikacji Teams, ograniczania transmisji strumieniowej lub ograniczania przepustowości Wi-Fi gości.
• Synchronized Application Control: uzupełnia wykrywanie aplikacji danymi z systemów końcowych Sophos za pośrednictwem Security Heartbeat. Jest to szczególnie przydatne w przypadku programów, które w przeciwnym razie zapora rozpoznawałaby jedynie ogólnie lub wcale.

W przypadku czystej polityki blokowej lub Allow, Application Filter jest najważniejszym punktem wejścia. Obiekty aplikacji i kształtowanie ruchu stają się interesujące dopiero wtedy, gdy konieczne jest ponowne wykorzystanie wyboru aplikacji lub wymagana jest szczególna kontrola przepustowości.

Synchronized Application Control nie zastępuje czystych reguł zapory. Wymaga Sophos Central, Security Heartbeat i odpowiedniego pokrycia punktów końcowych Sophos. Nowo odkryte aplikacje pojawiają się we własnych kategoriach, takich jak SyncAppCtl discovered i nie należy ich ślepo blokować. Najpierw sprawdź, potem kategoryzuj, a następnie zapisz w Application Filter.

Wykryte aplikacje automatycznie otrzymują etykietę statusu: New dla wciąż nieznanych aplikacji, Mapped dla aplikacji automatycznie przypisanych do kategorii oraz Customized dla wpisów dostosowanych ręcznie. Sophos obsługuje Synchronized Application Control dla maksymalnie 15 000 aplikacji i przechowuje tylko ostatnie pięć wystąpień na aplikację i punkt końcowy, aby oszczędzać miejsce. Ten limit ma szczególne znaczenie, gdy trzeba ustalić w celach dochodzeniowych, jak często dana aplikacja występowała na punkcie końcowym.

Utwórz Application Filter

Ścieżka menu:

Applications > Application filter

W starszych widokach nawigacji ścieżka może być wyświetlana jako Protect > Applications > Application filter.

Procedura:

1. Otwórz Add.
2. Przypisz nazwę opisową, na przykład Block_Remote_Control_Tools.
3. Wybierz istniejącą politykę jako szablon, na przykład politykę Allow-All jako punkt wyjścia dla docelowych reguł blokowania.
4. Zapisz politykę.
5. Otwórz ponownie politykę i dodaj regułę w filtrze.
6. Wybierz aplikację, kategorię, ryzyko, Characteristics, Technology, Classification lub inteligentny filtr.
7. Ustaw akcję, na przykład Deny lub Allow.
8. Ustaw Schedule, jeśli reguła ma obowiązywać tylko tymczasowo.
9. Zapisz regułę, a następnie zapisz politykę.

Uważaj na kategorie. Szeroka kategoria może spełnić więcej zastosowań, niż oczekiwano. W przypadku testów wstępnych pojedyncze aplikacje lub jasno określone grupy są często lepsze niż duży blok zbiorczy.

Istnieją dwa typowe sposoby pracy podczas dodawania reguły. Select All z filtrami jest odpowiednie, jeśli mamy na myśli całą grupę, na przykład kategorię File Transfer, Characteristics Transfer files i Technology Browser Based. Select Individual Application jest lepsze, jeśli ma to mieć wpływ tylko na pojedyncze aplikacje, takie jak AnyDesk, TeamViewer lub konkretną usługę w chmurze. Inteligentny filtr wyszukuje nazwę i opis aplikacji; nie zastępuje ono technicznego badania listy trafień.

Filtr Classification dotyczy tylko aplikacji w chmurze. Jeśli aplikacja w chmurze zostanie później przeklasyfikowana, Sophos Firewall również zaktualizuje reguły na podstawie tego Classification. Takie reguły są wygodne, ale bardziej dynamiczne niż stała lista poszczególnych aplikacji.

Przykład: Blokuj przesyłanie plików w przeglądarce

Dobrym pierwszym przykładem jest blokowanie przesyłania plików za pośrednictwem przeglądarki w sieci gościa lub klienta. Cała kategoria File Transfer nie jest całkowicie blokowana, ale wybór ogranicza się do przesyłania plików za pośrednictwem przeglądarki.

Konfiguracja w Application Filter:

1. Otwórz Applications > Application filter.
2. Utwórz politykę, na przykład Block_File_Transfer.
3. Wybierz odpowiednią politykę Allow jako szablon.
4. Zapisz i otwórz ponownie politykę.
5. Otwórz Add, aby uzyskać nową regułę filtra.
6. Użyj Select All i zawęź wybór za pomocą Category: File Transfer, Characteristics: Transfer files i Technology: Browser Based.
7. Ustaw Action na Deny.
8. Ustaw Schedule na All the time, jeśli nie jest wymagana kontrola czasu.
9. Zapisz regułę filtra, a następnie zapisz politykę.

Ten przykład jest celowo węższy niż ogólny blok wszystkich aplikacji do przesyłania plików. W wielu firmach miałoby to wpływ na legalne usługi w chmurze, aktualizacje, kopie zapasowe i współpracę. Przed produktywnym użyciem filtr w Log Viewer należy przetestować na prawdziwych klientach.

Włącz w regule zapory

Application Control działa tylko wtedy, gdy w regule zapory zostanie wybrany filtr.

Ścieżka menu:

Protect > Rules and policies > Firewall rules

Procedura:

1. Otwórz regułę zapory, przez którą faktycznie przepływa dany ruch.
2. Otwórz sekcję Inne funkcje zabezpieczeń.
3. Wybierz Application Filter dla Identyfikuj i kontroluj aplikacje (kontrola aplikacji).
4. Log firewall traffic aktywuj, przynajmniej w celu przetestowania i akceptacji.
5. Zapisz regułę.
6. Testuj na zdefiniowanym kliencie.

Kolejność reguł jest kluczowa. Jeśli ruch jest już przetwarzany według bardziej ogólnej reguły powyżej, nie osiągnie reguły z Application Control. Wtedy konfiguracja w WebAdmin wygląda poprawnie, ale nie daje żadnego efektu.

Kiedy tworzona jest nowa reguła LAN-WAN, należy osobno rozważyć NAT. Przykłady Sophos często używają Create linked NAT rule z MASQ w celu łatwego dostępu do Internetu. Przy istniejących regułach produkcyjnych nie powinieneś beztrosko tworzyć nowych reguł NAT, ale raczej sprawdzić, która reguła SNAT/MASQ ma już zastosowanie do tego ruchu.

W przypadku zasad kontroli aplikacji opartych na użytkownikach lub grupach reguła zapory musi faktycznie odpowiadać kontekstowi użytkownika. Match known users i działające uwierzytelnianie są wtedy tak samo ważne jak sam Application Filter. Bez kontekstu użytkownika polityka ma zastosowanie tylko do kryteriów sieci, strefy i usług.

W przypadku nowych reguł powinieneś także świadomie wybierać pomiędzy IPv4 i IPv6. Application Control jest aktywowane w odpowiedniej regule zapory sieciowej. Jeśli klient wybierze inną ścieżkę przez IPv6 niż przez IPv4, w przeciwnym razie test wygląda na czysty, chociaż część ruchu omija oczekiwaną regułę.

Podstawy źródła, miejsca docelowego, Services, funkcji bezpieczeństwa i kolejności reguł znajdują się w regułach Sophos Firewall i należy je bezpiecznie skonfigurować.

Świadomie sprawdź porównanie reguł

Przed zapisaniem reguły należy ją przeczytać jak przypadek testowy:

• Source zone i Source network: Klient testowy naprawdę musi przejść przez tę strefę i tę sieć.
• Destination zone i sieć docelowa: Ogólne cele mogą działać, ale są trudniejsze do zrozumienia.
• Services: TCP 80/443 jest często odpowiedni dla ruchu sieciowego; QUIC działa poprzez UDP 443.
• Zasady sieciowe, IPS i TLS Inspection: Na ten sam przepływ może wpływać wiele funkcji zabezpieczeń.
• Log firewall traffic: Bez logowania trudno jest udowodnić efekt Log Viewer.

Po wprowadzeniu Application Control pierwsza reguła powinna być nieco węższa i łatwa do zmierzenia. Ogromna zasada LAN do WAN z wieloma wyjątkami jest znacznie trudniejsza do zaakceptowania.

TLS Inspection i wykrywanie

Application Control rozpoznaje niektóre aplikacje nawet bez pełnego TLS Inspection. W przypadku wielu nowoczesnych usług HTTPS i usług w chmurze zapora sieciowa widzi tylko ograniczone informacje, takie jak adres IP, SNI, dane certyfikatu, nazwa hosta lub metadane połączenia bez deszyfrowania.

Nie zawsze to wystarcza do niezawodnego wykrywania. Jeśli aplikacja nie zostanie rozpoznana poprzez HTTPS zgodnie z oczekiwaniami, powinieneś sprawdzić:

• czy ruch przechodzący przez prawidłową regułę zapory sieciowej?
• czy Application Control jest aktywne w tej regule?
• czy aplikacja jest powszechnie rozpoznawana przez Sophos?
• czy TLS Inspection jest konieczne i uzasadnione w przypadku tego ruchu?
• czy istnieje QUIC lub HTTP/3, który utrudnia kontrolę?
• Czy zasady sieciowe IPS lub DNS Protection również mają zastosowanie?

TLS Inspection należy wprowadzać stopniowo i z wyjątkami. Odpowiednia procedura jest w Sophos Firewall wprowadzenie TLS Inspection poprawnie. Dla QUIC i HTTP/3 pasuje Sophos Firewall QUIC i HTTP/3 blokuje się poprawnie.

Różnica jest szczególnie widoczna w aplikacjach chmurowych: podstawowe bajty i dane dotyczące użytkowania wymagają przede wszystkim aktywowanego rejestrowania zapory ogniowej. Jednak bardziej szczegółowe informacje o przesyłaniu/pobieraniu i typie pliku można wiarygodnie zobaczyć tylko wtedy, gdy HTTPS zostanie odszyfrowany. Niektóre aplikacje przesyłają pliki przy użyciu własnych mechanizmów; wówczas pola szczegółów mogą pozostać puste lub wydawać się niekompletne, mimo że ruch jest dostępny.

W przypadku raportowania aplikacji w chmurze zalecana jest zatem triada: aktywuj Log firewall traffic, odszyfruj HTTPS, jeśli jest to uzasadnione organizacyjnie i technicznie, oraz użyj polityki sieciowej, która nie jest po prostu None. Dzięki temu dane sterujące aplikacją są znacznie bardziej przydatne w operacjach.

Efekt testu

Po aktywacji nie czekaj tylko na opinie użytkowników. Czysty test pozwala zaoszczędzić dużo czasu.

Proces praktyczny:

1. Ustaw klienta testowego i źródłowy adres IP.
2. Celowo uruchom aplikację lub wywołaj cel.
3. Filtruj według źródłowego adresu IP, miejsca docelowego, usługi i aplikacji w Przeglądarce dzienników.
4. Sprawdź, który Firewall Rule ID został trafiony.
5. Sprawdź, czy Application Control rozpoznaje aplikację.
6. Zanotuj identyfikator aplikacji, kategorię, akcję i Application Filter.
7. Podczas blokowania sprawdź, czy blokowanie jest pożądane z technicznego punktu widzenia.
8. Jeśli wykrycie jest niejasne, Packet Capture, dzienniki usług i rejestrowanie centralne dodają pola Syslog.

Zdarzenia kontroli aplikacji pojawiają się w Log Viewer jako zdarzenia filtrowania aplikacji lub treści. Firewall Rule ID, użytkownik, aplikacja, kategoria, ryzyko, działanie, źródło i cel są szczególnie istotne dla akceptacji. W przypadku oceny Syslog lub SIEM należy również zaznaczyć pola takie jak fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status i appresolvedby. To drugie pomaga sklasyfikować, czy aplikacja została rozpoznana poprzez podpis, logikę proxy czy Synchronized Application Control.

Application Control często używa ips.log w ścieżce technicznej. Przypisanie logów opisano w artykule Sophos Firewall Troubleshooting: Services i logi. W rozróżnieniu Log Viewer i Packet Capture pomaga testowanie reguł Sophos Firewall za pomocą Log Viewer, Policy Test i Packet Capture.

Przełącz z oglądania na blokowanie

Przejście z czystego wykrywania na blokowanie powinno odbywać się świadomie. W wielu środowiskach lepiej jest najpierw użyć Application Control jako narzędzia do obserwacji i raportowania. Następnie blokowane są tylko aplikacje, których ryzyko, baza użytkowników i zależność biznesowa są zrozumiałe.

Przed zablokowaniem powinieneś sprawdzić:

• Którzy użytkownicy, sieci lub urządzenia faktycznie korzystają z aplikacji?
• Którą regułę zapory sieciowej i Rule ID widzisz w Log Viewer?
• Czy aplikacja jest wiarygodnie rozpoznawana, czy tylko jako kategoria ogólna?
• Czy istnieją uzasadnione zastosowania biznesowe, przypadki wsparcia lub narzędzia dostawcy?
• Should the application be blocked everywhere or only on guest, school, client or server networks?
• Kto zatwierdza wyjątek i kiedy jest on ponownie rozpatrywany?

Krótki proces jest praktycznie czysty: najpierw zbierz dane dziennika, następnie zablokuj pojedyncze aplikacje lub małe grupy, a następnie zatwierdź za pomocą klienta testowego i Log Viewer. Jeśli blok wydaje się zbyt szeroki, nie powinieneś dezaktywować całego Application Filter, ale raczej dostosować konkretnie odpowiednią aplikację, kategorię lub pozycję reguły.

Jeśli Application Control nie działa

W przypadku problemów nie należy natychmiast dezaktywować całego filtra. Najpierw sprawdź, gdzie pęka odpływ.

• Brak wpisu w dzienniku dla połączenia testowego: Brak dziennika lub ruch nie dociera do reguły zapory. Check Rule ID, source zone and Packet Capture.
• Log Viewer pokazuje inny Rule ID: Bardziej ogólna zasada jest powyżej. Popraw kolejność reguł i kryteria dopasowania.
• Aplikacja pozostaje unknown lub ogólna: Wykrywanie nie jest wystarczające bez dodatkowego kontekstu. TLS Inspection, QUIC i sprawdź podpisy aplikacji.
• Blok uderza w zbyt wiele usług: Kategoria lub inteligentny filtr jest zbyt szeroki. Korzystaj z pojedynczych aplikacji lub małych grup.
• Po Pattern Update nagle blokowane jest więcej ruchu: Szeroka reguła oparta na Risk, Category lub Classification obejmuje nowe sygnatury. Sprawdź kryteria reguły i proces zmian.
• Brak szczegółów aplikacji w chmurze: Bez deszyfrowania HTTPS lub bez zasad sieciowych szczegóły dotyczące wysyłania, pobierania i typów plików są ograniczone. Sprawdź raporty aplikacji w chmurze i stan TLS.
• Blokada działa tylko w przypadku niektórych klientów: Sprawdź inną regułę, strefę, grupę użytkowników lub ścieżkę przeglądarki. Porównaj klienta testowego, użytkownika i ścieżkę sieciową.
• IPv6 zachowuje się inaczej niż IPv4: Oddzielna reguła IPv6, możliwa inna ścieżka DNS lub inna ścieżka przeglądarki. Świadomie przetestuj oba protokoły lub uwzględnij w regulaminie IPv6.

Najważniejszym punktem kontrolnym jest Rule ID. Jeśli oczekiwana reguła nie jest spełniona, zasadą kontroli aplikacji prawie nigdy nie jest główna przyczyna.

Należy czysto postępować z fałszywymi alarmami

Jeśli Application Control blokuje prawidłowy ruch, nie należy natychmiast wyłączać całego filtra.

Rozsądna kolejność:

1. Dokument, którego dotyczy problem, i wpis w dzienniku.
2. Sprawdź, która reguła zapory sieciowej i które Application Filter są zaangażowane.
3. Sprawdź aplikację, kategorię i działanie w filtrze.
4. Sprawdź, czy aplikacja jest rozpoznawana inaczej przez TLS Inspection.
5. Ustaw wyjątek tak wąsko, jak to możliwe: aplikacja, sieć źródłowa, grupa użytkowników lub cel.
6. Właściciel dokumentu i data przeglądu wyjątku.

Wyjątek dla Any lub szerokiej kategorii często szybko rozwiązuje bieżący przypadek, ale trwale osłabia kontrolę. Mały, zrozumiały wyjątek z jasnego powodu jest lepszy.

Typowe błędy

• Application Filter utworzony, ale nie wybrany w regule: Brak wpływu na ruch. Włącz filtry w prawdziwej regule zapory sieciowej.
• Ruch przechodzi przez inną regułę: Filtr nigdy nie został osiągnięty. Sprawdź Rule ID w Log Viewer.
• Zablokowano zbyt obszerną kategorię: Może to mieć wpływ na legalne usługi w chmurze lub usługi biznesowe. Korzystaj z pojedynczych aplikacji lub węższych grup.
• Niezrozumiano filtrów dynamicznych: Ryzyko Category lub Classification może uzyskać nowe trafienia dzięki sygnaturom i aktualizacjom aplikacji w chmurze. Sprawdzaj regularnie.
• HTTPS wykrywanie zawyżone: Aplikacja nie została wykryta niezawodnie. Sprawdź zachowanie TLS Inspection i QUIC.
• Brak logowania: Efekt pozostaje niewidoczny. Włącz rejestrowanie reguł na potrzeby testowania i obsługi.
• Wyjątek zbyt szeroki: Funkcja ochronna została praktycznie wyeliminowana. Ustaw wyjątek wąsko i z datą przeglądu.

Kontrola działania

Application Control należy regularnie sprawdzać. Aplikacje się zmieniają, usługi w chmurze korzystają z nowych punktów końcowych, użytkownicy korzystają z nowych narzędzi, a podpisy są aktualizowane.

Powinieneś udokumentować:

• Cel filtra aplikacji
• dotyczy reguł zapory sieciowej
• zablokowane lub dozwolone aplikacje
• znane wyjątki
• właściciel techniczny
• Data przeglądu
• ostatnia istotna zmiana

Jeśli Application Control jest używane w krytycznych aplikacjach biznesowych, sieciach szkolnych lub w wymaganiach zgodności, należy również sprawdzić Central Reporting, Syslog lub SIEM. Do oceny centralnej odpowiednia jest opcja Aktywuj raportowanie centralnej zapory ogniowej lub Sophos Firewall Skonfiguruj Syslog i SIEM.

Lista kontrolna

• Sprawdzono stan licencji.
• Wyraźnie zidentyfikowano regułę zapory, której dotyczy problem.
• Application Filter stworzony w jasnym celu.
• Udokumentowano szablon, filtry dynamiczne i kryteria reguł.
• Wybrano filtr w prawidłowej regule zapory.
• Aktywne rejestrowanie reguł.
• Zdefiniowano klienta testowego i aplikację testową.
• Log Viewer sprawdzone na Rule ID i Application Control.
• Rzeczywiste użycie, właściciel i zasada wyjątku wyjaśniona przed zablokowaniem.
• Sprawdzono ścieżkę IPv4 i IPv6, jeśli obie są aktywne w sieci.
• TLS Inspection i QUIC oceniane, gdy wykrycie HTTPS jest niejasne.
• Sprawdzono raportowanie aplikacji w chmurze za pomocą deszyfrowania HTTPS i, jeśli to konieczne, zasad sieciowych.
• Dokładnie udokumentowane wyjątki.
• Ustawiono datę przeglądu.

Często zadawane pytania