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.

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.

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: Any
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

W przykładzie używany jest DPI Engine. Nazwy i sieci trzeba dostosować do własnego środowiska. Bardziej ogólna reguła znajdująca się nad LAN_USERS_WEB może przejąć ruch wcześniej, dlatego Rule ID i kolejność reguł zawsze należą do testu akceptacyjnego. Podstawy opisano w artykule 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.

Do testu działania można użyć strony SophosTest dla Web Security albo pliku testowego EICAR Anti-Malware. EICAR nie jest prawdziwym malware, ale produkty antywirusowe celowo rozpoznają go jak malware. Prawdziwe złośliwe oprogramowanie nie może trafić do sieci produkcyjnej.

Praktyczna procedura:

  1. Wyznaczyć odizolowanego klienta testowego i oczekiwany Firewall Rule ID.
  2. Zanotować czas, adres IP klienta, 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 dla Sophos Firewall albo pobrać plik testowy EICAR.
  6. Sprawdzić, czy firewall blokuje pobieranie i czy Malware-log pokazuje wykrycie antywirusowe dla tego samego klienta, tego samego Rule ID i tego samego czasu.

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.

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

Szczególny przypadek aktualizacji do SFOS 22.0 GA

Sophos opisuje pod identyfikatorem NC-177529 ś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.

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.