Przejdz do tresci
Avanet

Konfigurowanie i testowanie skanowania malware w Sophos Firewall

Skanowanie malware w Sophos Firewall sprawdza pliki w ruchu webowym za pomocą zintegrowanych silników antywirusowych. Samo włączenie Web Filtering lub wybranie Web Policy nie wystarcza: odpowiednia reguła zapory musi używać opcji Scan HTTP and decrypted HTTPS, a zaszyfrowany ruch trzeba odszyfrować, aby można było sprawdzić jego zawartość.

Ten artykuł koncentruje się na plikach pobieranych przez HTTP i HTTPS. Kategorie, URL Groups i reguły użytkowników opisano w artykule Web Protection z Web Policies. Nieznane pliki może dodatkowo analizować Zero-Day Protection, natomiast ruch e-mail jest chroniony oddzielnie przez Mail Protection.

Zakres, wymagania i licencje

Klasyczne skanowanie malware zależy od protokołu i reguły. Pobieranie z internetu wymaga Web Protection; sama Base License nie zawiera Web Malware Protection. Zero-Day Protection jest osobną subskrypcją, która uzupełnia, lecz nie zastępuje antywirusa. SMTP, POP3 i IMAP wymagają Email Protection. W Administration > Licensing należy sprawdzić stan i datę wygaśnięcia; moduł musi mieć status Subscribed lub Evaluating. Firewall połączony z internetem automatycznie synchronizuje licencje co 24 godziny. Jeżeli stan wydaje się nieaktualny, opcja Administration > Licensing > Synchronize wymusza odświeżenie.

Przed zmianą trzeba zapisać regułę, Rule ID, pozycję i bieżące opcje; dla HTTPS wybrać DPI Engine lub Web Proxy i potwierdzić zaufanie klienta do Signing CA; sprawdzić Web Exceptions i SSL/TLS Exclusion Rules; przygotować odizolowanego klienta, okno pilota i Log Viewer. W Backup and firmware > Backup and restore należy też utworzyć aktualną kopię oraz osobno zanotować zmieniane wartości, aby rollback nie wymagał pełnego odtworzenia.

FTP i poczta mają osobne ustawienia. Scan FTP for malware włącza się w pasującej regule, a limit znajduje się w Web > General settings > Maximum file scan size for FTP. Dla poczty na końcu reguły wybiera się używane protokoły (IMAP, IMAPS, POP3, POP3S, SMTP i/lub SMTPS); Add ports dodaje brakujące porty standardowe. Polityki MTA/Legacy, kwarantanna i załączniki są w Email, a silnik podstawowy w Email > General settings > Malware protection. Pełną konfigurację opisuje podlinkowany artykuł Mail Protection.

Kontrola typu pliku również nie dowodzi wykrycia wirusa. Web Policy może blokować plik według typu, a polityka poczty może obsłużyć załącznik. Dowodem skanowania jest dopiero skorelowany wpis Malware.

Co musi współdziałać, aby skanowanie było skuteczne

Na wynik składa się kilka warstw:

  • Właściwa reguła zapory musi faktycznie pasować do ruchu klienta.
  • Scan HTTP and decrypted HTTPS włącza skanowanie malware dla tej ścieżki reguły.
  • Web > General settings określa silnik, sposób skanowania, limity rozmiaru i obsługę treści, których nie można przeskanować.
  • Zawartość HTTPS jest sprawdzana tylko wtedy, gdy DPI lub Web Proxy odszyfruje połączenie.
  • Web Exceptions nie mogą nieumyślnie pomijać skanowania malware.
  • Trzeba kontrolować QUIC, ponieważ ruchu QUIC nie można skanować tak jak klasycznego ruchu HTTP i HTTPS.

Web Policy i skanowanie malware wykonują różne zadania. Web Policy decyduje na przykład o kategoriach lub typach plików. Skan antywirusowy sprawdza zawartość pliku pod kątem znanego malware i PUAs. Dlatego w regule zapory skanowanie malware może być aktywne także z ustawieniem Web policy: None. Z kolei wybrana Web Policy nie oznacza automatycznie, że pobierane pliki są sprawdzane pod kątem malware.

Wybór Single lub Dual Engine

W sekcji System services > Malware protection ustawia się podstawowy silnik antywirusowy. Sophos Firewall używa silników Sophos i Avira; wybrany Primary Engine skanuje samodzielnie przy opcji Single engine, a przy Dual engine działa jako pierwszy.

Globalny wybór dla ruchu webowego znajduje się tutaj:

Web > General settings > Malware and content scanning
  • Single engine: używa tylko Primary Engine. Wymaga mniej zasobów i zapewnia najlepszą wydajność. Aby korzystać z Zero-Day Protection, Sophos musi być ustawiony jako Primary Engine.
  • Dual engine: najpierw używa Primary Engine, a następnie drugiego silnika. Zwiększa zakres wykrywania, ale wymaga więcej czasu i zasobów.

W zwykłych sieciach klienckich dobrym punktem wyjścia jest Single engine z Sophos jako Primary Engine, jeżeli istotne są przepustowość i opóźnienia. Dual engine pasuje do środowisk, w których maksymalny zakres wykrywania jest ważniejszy, a appliance może obsłużyć dodatkowe obciążenie w rzeczywistych warunkach. Decyzji nie należy podejmować wyłącznie na podstawie danych katalogowych: pilot z typowymi plikami do pobrania, wideokonferencjami i dystrybucją oprogramowania lepiej pokaże faktyczny wpływ.

⚠️ Zmiana Primary Engine lub przejście z Single na Dual działa globalnie na pasujące ścieżki skanowania. Przed zmianą trzeba uwzględnić istniejące polityki webowe, FTP i pocztowe oraz Zero-Day Protection, a także udokumentować sposób wycofania zmiany.

Sterowanie wykrywaniem machine learning przez silnik skanujący

SFOS 22 umożliwia globalne włączenie machine learning, czyli ML, dla silnika skanującego Sophos, a następnie osobno dla grup funkcji. ML wyszukuje podejrzane wzorce, których może jeszcze nie być w bazie sygnatur. Rozszerza to wykrywanie nowych lub szybko rozprzestrzeniających się zagrożeń, ale zwiększa też ryzyko wyników fałszywie dodatnich.

Najpierw należy zapisać bieżący stan poleceniem tylko do odczytu:

show scanengine

Udokumentowane wartości domyślne to globalnie ml_scan on, ml_web_detection off dla Web Proxy i DPI Engine, ml_email_detection on dla Email oraz ml_legacy_detection off dla WAF i FTP Proxy. Gdy globalne ml_scan ma wartość off, nie można skutecznie włączyć ML dla poszczególnych grup funkcji. Przełączniki funkcji określają, czy wykrycie ML może w danej grupie wywołać blokadę.

Pełna składnia CLI wygląda następująco:

set scanengine ml_scan <on|off>
set scanengine ml_web_detection <on|off>
set scanengine ml_email_detection <on|off>
set scanengine ml_legacy_detection <on|off>
set scanengine thread_count <1-128|default>

thread_count obowiązuje dla każdego silnika skanującego. Zakres wynosi od 1 do 128, a default dynamicznie oblicza liczbę na podstawie dostępnych procesorów. Stałej liczby wątków nie należy stosować jako ogólnego tuningu wydajności. Wymaga to powtarzalnego obciążenia skanera, pomiarów CPU i pamięci, testu przepustowości oraz zazwyczaj konkretnego zalecenia wsparcia. Starsza opcja max_buffer_size jest przestarzała i nie należy jej już zmieniać.

⚠️ ML może błędnie blokować prawidłowe pliki lub ruch, a wykrycia ML generują telemetrię dla Sophos Labs. Przed wdrożeniem należy więc wyjaśnić aktywację, prywatność, objęte ścieżki danych i proces obsługi wyników fałszywie dodatnich. Globalne wyłączenie ML na podstawie podejrzenia nie jest lepszym rozwiązaniem niż niezweryfikowany wyjątek.

Pilot rozpoczyna się od dokładnie jednej grupy funkcji i kontrolowanego ruchu klienta lub poczty. Przed zmianą i po niej porównuje się show scanengine, policy, działanie blokady, Log Viewer, wynik aplikacji, CPU i czas skanowania. EICAR potwierdza zwykłe skanowanie malware, ale nie dowodzi wykrycia przez ML nowego wzorca. Wycofanie zmiany przywraca wartości zapisane przez show scanengine, a nie bez sprawdzenia wartości domyślne produktu.

Określanie sposobu skanowania

W sekcji Web > General settings oprócz silnika podejmuje się również inne decyzje dotyczące ochrony.

Treści, których nie można przeskanować

Action on malware scan failure określa, co dzieje się z treścią, której nie można w pełni sprawdzić. Może to dotyczyć zaszyfrowanych lub uszkodzonych archiwów oraz zbyt głęboko zagnieżdżonych plików. Sophos Firewall skanuje archiwa do 16 poziomów kompresji.

Block zapewnia silniejszą ochronę, ale może zatrzymywać prawidłowe pliki chronione hasłem lub uszkodzone. Allow podtrzymuje proces biznesowy, ale przepuszcza niesprawdzoną zawartość. W zwykłych sieciach klienckich bezpieczniejszym punktem wyjścia jest Block. Jeśli przestaje działać aplikacja biznesowa, przed złagodzeniem ustawienia globalnego należy najpierw zbadać konkretną ścieżkę pliku.

Rozmiary plików i streaming

Do not scan files larger than określa maksymalny rozmiar skanowania dla HTTP i HTTPS. Większe pliki nie są skanowane. W przypadku plików skompresowanych liczy się rozmiar archiwum, a nie możliwy rozmiar po rozpakowaniu. Dla FTP istnieje osobny limit Maximum file scan size for FTP.

Niski limit nie poprawia automatycznie bezpieczeństwa, lecz może pozwolić na przejście dużych instalatorów lub archiwów bez skanowania. Bardzo wysoka wartość może natomiast zwiększyć czas pobierania i zużycie zasobów. Wartość musi więc odpowiadać sposobowi dystrybucji oprogramowania, rozmiarom pakietów aktualizacji i wydajności appliance.

Scan audio and video files rozszerza skanowanie na treści audio i wideo, ale może zakłócać streaming. Tę opcję należy włączać tylko wtedy, gdy potrzeba ochrony uzasadnia dodatkowe obciążenie i możliwe przerwy.

Obsługa PUAs

Block potentially unwanted applications wykrywa programy, które nie muszą być malware, ale mogą na przykład zawierać adware, niepożądane narzędzia zdalnego dostępu lub ryzykowne zmiany systemowe. Wpis w Authorized PUAs należy dodać dopiero po sprawdzeniu pliku, źródła, przeznaczenia i Owner. Ogólne zezwolenie osłabia ochronę wszystkich pasujących ścieżek skanowania.

Włączanie skanowania malware w regule zapory

Reguła znajduje się tutaj:

Rules and policies > Firewall rules

Dla typowej reguły dostępu klientów do Internetu w sekcji Web filtering sprawdza się następujące elementy:

  1. Source zone i Source networks odpowiadają sieci klientów.
  2. Destination zone ma wartość WAN, a Services obejmują przewidziany ruch webowy.
  3. Log firewall traffic jest włączone.
  4. Scan HTTP and decrypted HTTPS jest włączone.
  5. Block QUIC protocol jest włączone, jeżeli ruch webowy ma przebiegać kontrolowaną ścieżką TCP.
  6. DPI lub Web Proxy wybrano świadomie.
  7. Use Zero-day protection jest dodatkowo włączone tylko wtedy, gdy analizowane mają być nieznane pliki.

Kompaktowy przykład reguły:

Rule name: LAN_USERS_WEB
Source zones: LAN
Source networks and devices: LAN_CLIENTS
Destination zones: WAN
Destination networks: Any
Services: HTTP, HTTPS
Web policy: LAN_STANDARD_WEB
Scan HTTP and decrypted HTTPS: On
Block QUIC protocol: On
Use web proxy instead of DPI engine: Off
Log firewall traffic: On

Przykład używa DPI Engine. LAN_USERS_WEB, LAN_CLIENTS i LAN_STANDARD_WEB należy zastąpić własnymi obiektami. Przy samym skanowaniu Web policy może mieć wartość None. Services należy ograniczyć do potrzebnych protokołów; Any jest tu zbyt szerokie. Wyższa reguła może pasować wcześniej, więc Rule ID i kolejność należą do odbioru. Podstawy opisano w Zrozumienie i bezpieczne tworzenie reguł zapory.

HTTPS: prawidłowe uzupełnienie DPI lub Web Proxy

Scan HTTP and decrypted HTTPS nie odszyfrowuje samodzielnie HTTPS. Opcja skanuje tylko niezaszyfrowany ruch HTTP oraz zawartość HTTPS, którą wcześniej odszyfrowała inna część konfiguracji.

DPI Engine

W przypadku DPI Engine odszyfrowywanie odbywa się tutaj:

Rules and policies > SSL/TLS inspection rules

Odpowiednia SSL/TLS inspection rule musi pasować do klienta testowego i celu oraz używać Action: Decrypt. Klienci muszą ufać używanemu Signing CA. Planowanie, pilot i wyjątki opisano w artykule Stopniowe wdrażanie TLS Inspection, a dystrybucję certyfikatu w artykule Instalowanie certyfikatu CA do HTTPS Scanning.

Web Proxy

Dla ścieżki proxy w regule zapory włącza się Use web proxy instead of DPI engine, a dla HTTPS dodatkowo Decrypt HTTPS during web proxy filtering. Następnie w sekcji Web > General settings proxy może skanować w dwóch trybach:

  • Batch: najpierw pobiera cały plik na firewall i przekazuje go dopiero po skanowaniu. Zapewnia to dokładniejszą kontrolę, ale może zauważalnie opóźnić pobieranie.
  • Real-time: przekazuje części pobieranego pliku, ale kończy transfer dopiero po uznaniu treści za bezpieczną.

DPI Engine zawsze działa w trybie Real-time. Nie należy przełączać między Proxy i DPI tylko z powodu pojedynczego błędu, ponieważ różnią się zakresem funkcji, portami, logami i zachowaniem użytkownika.

Wybór między DPI Real-time, skanowaniem proxy Batch lub Real-time oraz bezpieczną zmianę pilotażową opisano w Prawidłowy wybór DPI Engine lub Web Proxy.

Kontrolowanie wyjątków i QUIC

Web Exception może pominąć Malware and content scanning. W takim przypadku dla pasującego ruchu automatycznie pomijana jest również analiza Zero-Day. Wyjątki powinny więc mieć wąski zakres hosta lub URL, jasno określonego Owner i datę przeglądu.

QUIC, czyli HTTP/3, zwykle używa UDP 443. Sophos Firewall nie może skanować tego ruchu tak jak klasycznego ruchu webowego. Block QUIC protocol blokuje w odpowiedniej regule zapory wychodzący ruch UDP na portach 80 i 443, aby zgodne klienty przełączyły się na TCP i HTTPS. Szczegóły i testy opisano w artykule Prawidłowe blokowanie QUIC i HTTP/3.

Sprawdzanie działania za pomocą bezpiecznego testu

Zielony Policy Test lub zaznaczone pole nie dowodzą jeszcze, że zawartość jest sprawdzana. Test musi zostać przeprowadzony z klienta znajdującego się za odpowiednią regułą zapory; pobieranie bezpośrednio z firewalla sprawdza inną ścieżkę ruchu.

Aby sprawdzić ścieżkę webową Sophos Firewall, należy użyć konkretnie działania Anti-virus EICAR test na stronie SophosTest dla Web Security. Aby sprawdzić transport standaryzowanego pliku niezależnie od tej witryny, należy zamiast tego użyć jednego wariantu pliku testowego EICAR Anti-Malware. EICAR nie jest prawdziwym malware, ale antywirusy celowo je wykrywają. Nie wolno wprowadzać prawdziwego malware do sieci produkcyjnej ani otwierać lub uruchamiać pliku testowego.

Praktyczna procedura:

  1. Wyznaczyć odizolowanego klienta testowego i oczekiwany Firewall Rule ID. Tymczasowy wyjątek Allow nie jest potrzebny. Jeżeli najpierw zareaguje ochrona Endpoint, nie należy jej wyłączać; wynik należy uznać za niejednoznaczny dla firewalla.
  2. Zanotować czas, adres IP klienta, wybrany testowy URL i oczekiwaną ścieżkę skanowania.
  3. W Log Viewer otworzyć moduły Firewall, SSL/TLS inspection, Web filter i Malware.
  4. Dla HTTPS sprawdzić, czy połączenie jest rzeczywiście przetwarzane z użyciem Decrypt.
  5. W SophosTest wykonać Anti-virus EICAR test albo pobrać dokładnie jeden wariant EICAR. Firewall powinien przerwać transfer przed zakończeniem pobierania.
  6. Sprawdzić, czy Malware-log pokazuje wykrycie antywirusowe dla tego samego klienta, tego samego Rule ID, tego samego URL i tego samego czasu.
  7. Zamknąć stronę testową i usunąć częściowe lub testowe pliki oraz artefakty pamięci podręcznej przeglądarki zgodnie z procedurą Endpoint; nie przywracać ani nie uruchamiać obiektu z kwarantanny. Wycofać tymczasowe ustawienia testowe i zwykłym pobraniem potwierdzić, że dostęp do sieci nadal działa.

Sama block page nie wystarcza. Dostęp mogła również zablokować Web Policy, reguła typu pliku, produkt Endpoint lub kategoria strony testowej. Decydujący jest skorelowany wpis Malware z firewalla. W Syslog wykrycie malware w ruchu webowym pojawia się z log_type="Anti-Virus"; zależnie od protokołu komponenty mają wartość HTTP lub HTTPS, a Subtype dla wykrycia to Virus.

Jeżeli Log Viewer nie pokazuje, czy lokalna usługa antywirusowa działa, podczas kontrolowanego testu można dodatkowo obserwować log usługi w Advanced Shell:

tail -f /log/avd.log

Wyświetlanie kończy się za pomocą Ctrl+C. avd.log pomaga przy błędach usługi i silnika, ale nie zastępuje danych polityki i połączenia w Log Viewer. Brak nowych wpisów również nie dowodzi, że skanowanie jest nieaktywne. Przypisanie logów opisano w artykule Usługi i logi Sophos Firewall.

Precyzyjne diagnozowanie typowych błędów

  • Web Policy aktywna, ale brak skanowania malware: w regule zapory, która faktycznie obsługuje ruch, nie włączono Scan HTTP and decrypted HTTPS.
  • Test HTTP działa, a test HTTPS nie: SSL/TLS inspection rule nie pasuje, nie używa Decrypt albo Web Proxy nie odszyfrowuje HTTPS.
  • Przeglądarka używa innej ścieżki: QUIC jest dozwolony albo wcześniej pasuje inna reguła zapory.
  • Plik nie jest sprawdzany mimo prawidłowej reguły: Web Exception pomija Malware and content scanning albo plik przekracza skonfigurowany limit rozmiaru.
  • EICAR jest blokowany, ale nie przez firewall: wcześniej zareagowała ochrona Endpoint, reguła typu pliku lub kategoria webowa. Sprawdzić Rule ID i Malware-log firewalla.
  • Prawidłowe archiwa są blokowane: sprawdzić Action on malware scan failure, szyfrowanie, uszkodzenie i zagnieżdżenie. Nie przełączać od razu globalnie na Allow.
  • Dual Engine spowalnia pobieranie: porównać obciążenie appliance, rozmiary plików, równoległość i tryb Proxy/DPI z Single Engine w kontrolowanym pilocie.
  • Zero-Day Protection niczego nie pokazuje: oddzielnie sprawdzić klasyczne skanowanie malware, odszyfrowywanie HTTPS, typ pliku, wyjątki i Use Zero-day protection.
  • Brak opcji lub nie można jej zapisać: sprawdzić stan i wygaśnięcie licencji w Administration > Licensing, a następnie zsynchronizować licencje; nie omijać tego szerszą regułą Allow.
  • Plik FTP nie jest skanowany: sprawdzić Rule ID, Scan FTP for malware, Service i Maximum file scan size for FTP. Opcja HTTP/HTTPS nie włącza FTP.
  • Załącznik pocztowy nie jest wykrywany: ustalić ścieżkę MTA, Legacy SMTP lub POP/IMAP, a potem skorelować protokoły, porty, politykę, Single/Dual Antivirus, wyjątki i logi Mail lub Malware.

To, która reguła zapory i polityka faktycznie obowiązuje, można ustalić za pomocą Log Viewer, Policy Tester i Packet Capture.

Wycofanie zmian z zachowaniem stanu

Rollback przywraca tylko wartości zmienione w pilocie, w odwrotnej kolejności: regułę SSL/TLS i pozycję, regułę firewall z Rule ID i pozycją, Proxy/DPI, opcje skanowania i QUIC, globalny Single/Dual Engine oraz wartości show scanengine. Nie należy usuwać reguły ani globalnie wyłączać skanowania z powodu jednego nieudanego pobrania.

Po zapisaniu zwykły reprezentatywny plik musi działać, a odizolowany EICAR musi dokładnie odtworzyć wcześniejsze zachowanie. Inna Rule ID, deszyfrowanie lub akcja logu oznacza niepełny rollback. Pełny backup jest drogą awaryjną dla szerszej błędnej konfiguracji.

Szczególny przypadek aktualizacji do SFOS 22.0 GA

Pod identyfikatorem NC-177529 udokumentowano ściśle ograniczony błąd aktualizacji dla SFOS 22.0 GA Respin Build 411. Podczas tej aktualizacji mogą tymczasowo pojawić się komunikaty takie jak Malware Unscannable, często dla www.msftconnecttest.com. W tym momencie nowy silnik skanowania Sophos nie jest jeszcze dostępny, jeżeli tylko ten silnik skonfigurowano jako Single Engine. W Legacy Web Proxy pojawiają się wtedy block pages, a przy DPI Engine wczytywanie stron może zostać przerwane; zakłócenie może potrwać około minuty dłużej. Przed aktualizacją trzeba też sprawdzić bieżące wydanie Maintenance Release i obsługiwane ścieżki; podlinkowany niżej artykuł obejmuje tę kontrolę zależną od wersji.

Jeżeli aktualizacja jest wykonywana konkretnie do tej wersji GA, przed aktualizacją należy w Web > General settings przełączyć Single engine na Dual engine, a po zakończeniu aktualizacji wrócić do używanej wcześniej Single engine. Ten środek tymczasowy nie jest ogólnym zaleceniem dla MR1, MR2 ani późniejszych wydań. Całą ścieżkę aktualizacji i pozostałe blokady opisano w artykule Kontrola przed aktualizacją do SFOS 22.

FAQ

Czy Web Policy wystarczy do skanowania malware?

Nie. Web Policy kontroluje kategorie webowe i inne decyzje polityki. Aby wykonać skan antywirusowy, w regule zapory, która faktycznie obsługuje ruch, trzeba dodatkowo włączyć Scan HTTP and decrypted HTTPS.

Czy należy używać Single czy Dual Engine?

Single Engine z Sophos jako Primary Engine zapewnia lepszą wydajność i obsługuje Zero-Day Protection. Dual Engine zwiększa zakres wykrywania, ale wymaga więcej zasobów. Właściwy wybór zależy od potrzeb ochrony, appliance i zmierzonego obciążenia.

Dlaczego plik testowy HTTPS nie jest wykrywany?

Często połączenie nie jest odszyfrowywane, Exception pomija skanowanie, QUIC lub inna reguła zapory zmienia ścieżkę albo pobierany plik przekracza limit skanowania. SSL/TLS inspection log, Rule ID i Malware-log trzeba sprawdzać razem.

Czy należy zezwalać na treści, których nie można przeskanować?

Block jest bezpieczniejszym punktem wyjścia dla zwykłych sieci klienckich. Jeśli zakłócony zostaje prawidłowy proces, należy zbadać konkretną ścieżkę pliku i obsłużyć ją możliwie wąsko, zamiast globalnie zezwalać na niesprawdzone treści.

Czy skanowanie malware przez firewall zastępuje ochronę Endpoint?

Nie. Firewall widzi tylko ruch przechodzący przez jego ścieżkę skanowania i nie może w pełni sprawdzić zaszyfrowanych lub wykluczonych treści. Ochrona Endpoint, EDR lub MDR nadal jest potrzebna do monitorowania plików, procesów i zachowania na urządzeniu.