Sophos Firewall ATP: konfiguracja X-Ops Threat Feeds

Dawna funkcja Advanced Threat Protection (ATP) nosi w aktualnych wersjach SFOS nazwę Sophos X-Ops Threat Feeds. Firewall porównuje ruch wychodzący z zarządzaną przez Sophos bazą znanych złośliwych adresów IP, domen i URL. Może dzięki temu na przykład uniemożliwić zainfekowanemu klientowi połączenie ze znanym serwerem Command and Control.

Docelową akcją w środowisku produkcyjnym jest Log and drop. Funkcja jest domyślnie wyłączona, a po jej włączeniu blokuje ruch tylko wtedy, gdy wybrano tę akcję.

Konfiguracja X-Ops Threat Feeds

Przed aktywacją muszą być dostępne licencje Network Protection i Web Protection. Obie funkcje są zawarte w pakietach Standard i Xstream Protection; X-Ops nie wymaga dodatkowej licencji Sophos Central.

Otworzyć System services > Log settings.
W wierszu Active threat response włączyć co najmniej Local reporting. Zależnie od modelu eksploatacji wybrać także docelowy serwer Syslog i Central reporting.
Otworzyć Protect > Active threat response > Sophos X-Ops threat feeds.
Włączyć Sophos X-Ops threat feeds.
W polu Action wybrać Log only dla krótkiego, kontrolowanego pilota albo Log and drop dla ochrony produkcyjnej.
W sekcji Advanced security settings zdecydować między Inspect untrusted content i Inspect all content.
Zapisać przez Apply.
Następnie sprawdzić ustawienie, cele logowania i istniejące wyjątki.

Modele XGS 87/87w i 107/107w nie obsługują lokalnego raportowania. Na tych urządzeniach należy użyć Central Reporting albo serwera Syslog. Kolumna Central reporting pojawia się dopiero po włączeniu Send reports and logs to Sophos Central w sekcji Sophos Central.

Sophos zaleca blokowanie znanych IoC zamiast samego rejestrowania zdarzeń. W nowym lub dotąd niemonitorowanym środowisku Log only może jednak pomóc podczas krótkiej, jasno ograniczonej czasowo fazy obserwacji. Taka faza wymaga osoby odpowiedzialnej oraz daty przełączenia; w przeciwnym razie funkcja może pozostać na stałe bez działania blokującego.

Co chroni X-Ops, a czego nie chroni

X-Ops sprawdza znane złośliwe cele w przekazywanym ruchu wychodzącym. Typowe zdarzenie powstaje, gdy klient lub serwer próbuje połączyć się ze znanym adresem IP, domeną lub URL powiązanym z malware, phishingiem albo C2. Zależnie od wybranej akcji próba jest jedynie rejestrowana lub od razu odrzucana.

X-Ops nie obsługuje natomiast lokalnych ani zdalnych Source Matches. Nie blokuje więc automatycznie znanych adresów IP atakujących, które jako źródło uzyskują dostęp do publikacji DNAT lub WAF, WebAdmin albo VPN Portal. Do tych przypadków lepiej pasują MDR, NDR lub Third-Party Threat Feeds razem z restrykcyjnymi regułami firewall, WAF i Device Access.

IPS, Malware Scanning i Zero-Day Protection również mają inne zadania. X-Ops działa na podstawie wskaźników: cel musi być już znany jako złośliwy IoC. IPS rozpoznaje natomiast znane wzorce ataków w ruchu. Obie funkcje się uzupełniają, ale się nie zastępują.

Warunki potrzebne do wykrywania zdarzeń

Sama aktywacja nie gwarantuje, że firewall zobaczy każdy wskaźnik IP, domenę lub URL. Decyduje o tym informacja widoczna w danej ścieżce sieciowej.

Adresy IP

Aby dopasować docelowy adres IP, ruch wychodzący musi przechodzić przez odpowiednią regułę firewall. Firewall może bezpośrednio porównać adres docelowy z feedem X-Ops; odszyfrowanie TLS nie jest do tego potrzebne.

Domeny

Aby wykrywać domeny, w odpowiedniej regule firewall musi być aktywne Application Classification albo wybrana IPS Policy. Jeśli brakuje obu ustawień, w danej ścieżce ruchu może nie dojść do wymaganej klasyfikacji.

Pełne URL przez HTTPS

URL oprócz domeny zawiera także ścieżkę, na przykład https://example.invalid/download/payload.exe. W zaszyfrowanym ruchu HTTPS bez odszyfrowania firewall widzi przez SNI zazwyczaj tylko domenę, a nie ścieżkę /download/payload.exe.

Sprawdzenie pełnego wskaźnika URL wymaga Web Proxy z włączonym odszyfrowaniem HTTPS albo odpowiedniej reguły SSL/TLS Inspection z akcją Decrypt. TLS Inspection nie należy włączać globalnie i bez kontroli wyłącznie na potrzeby X-Ops: dystrybucja certyfikatów, prywatność, wyjątki, zgodność aplikacji i wydajność wymagają osobnego wdrożenia.

Świadomy wybór zakresu inspekcji

W sekcji Advanced security settings określa się, jak szeroko X-Ops ma sprawdzać ruch:

Inspect untrusted content ogranicza kontrolę do ruchu z niezaufanymi źródłami lub celami. Zużywa mniej zasobów i jest rozsądnym punktem wyjścia, gdy obciążenie i skutki uboczne nie są jeszcze znane.
Inspect all content sprawdza ruch zaufany i niezaufany. Zapewnia szersze pokrycie, lecz może wpływać na wydajność, zwłaszcza w środowiskach o dużym natężeniu ruchu.

Dla szczególnie chronionych sieci klientów, serwerów lub administracji Inspect all content może być właściwym wyborem, jeżeli appliance ma wystarczającą rezerwę. Zmianę należy przeprowadzić w oknie serwisowym. Następnie porównuje się obciążenie CPU, opóźnienia, przepustowość i zgłoszenia helpdesku ze stanem wcześniejszym.

Podczas wdrażania lepiej nie zmieniać wielokrotnie i jednocześnie akcji oraz zakresu inspekcji. Zmiana najpierw widoczności, a później akcji blokującej ułatwia ustalenie, które ustawienie spowodowało problem.

Kontrola działania i logowania

Po zapisaniu nie wystarczy sprawdzić, czy przełącznik jest aktywny. Wiarygodna kontrola operacyjna obejmuje trzy poziomy:

Konfiguracja: X-Ops jest włączony, a wybrana Action i zakres inspekcji zostały zapisane.
Widoczność: reguła firewall, Application Classification lub IPS oraz, dla pełnych URL HTTPS, odszyfrowanie TLS odpowiadają typowi wskaźnika.
Dowód: zdarzenia są widoczne w Log viewer > Active threat response albo w skonfigurowanym celu Central lub Syslog.

Lokalne podsumowanie jest dostępne w Reports > Network & threats > Active threat response. Widżet o tej samej nazwie w Control Center pokazuje status i liczbę zablokowanych zagrożeń; konkretną akcję i szczegóły połączenia sprawdza się w raporcie lub Log Viewer.

Techniczny typ logu Syslog nadal nazywa się ATP, mimo że interfejs używa dziś nazw X-Ops i Active Threat Response. Zależnie od ścieżki przetwarzania log_component może wskazywać Firewall, DNS, IPS lub Web. W analizie szczególnie przydatne są znacznik czasu, akcja, Source, Destination, porty, domena lub URL, Threat Name, Feed Name i Event ID.

W Advanced Shell ips.log jest głównym logiem silnika Active Threat Response. garner.log pomaga analizować przetwarzanie i przekazywanie zdarzeń, zwłaszcza gdy Central Reporting wygląda na niekompletny. Przegląd usług i logów Sophos Firewall wyjaśnia te pliki oraz bezpieczny dostęp SSH.

Nie ma powszechnie udokumentowanego, nieszkodliwego wskaźnika testowego X-Ops. Nie należy więc celowo otwierać prawdziwej domeny malware ani łączyć się ze znanym złośliwym adresem IP. Jeśli potrzebny jest powtarzalny test, najbezpieczniejszą metodą jest własny Third-Party Pilot Feed z kontrolowanym celem testowym. W X-Ops sprawdza się konfigurację i widoczność; faktyczne działanie blokowania potwierdzi następne rzeczywiste, dokładnie przeanalizowane zdarzenie.

Analiza alarmu X-Ops

Zablokowany IoC jest istotnym sygnałem, ale nie stanowi jeszcze pełnej analizy incydentu. Z adresem docelowym mogło połączyć się malware, link phishingowy, przejęte rozszerzenie przeglądarki albo legalna usługa sklasyfikowana błędnie.

Przydatna kolejność działań:

Zabezpieczyć znacznik czasu, firewall lub węzeł HA, akcję i pełne szczegóły logu.
Zapisać Source IP, Destination IP, domenę lub URL, porty, protokół, Threat Name i Feed Name.
Skorelować logi firewall, DNS, IPS i Web z tego samego przedziału czasu.
Zidentyfikować klienta wewnętrznego przez DHCP Lease, przypisanie użytkownika lub dane endpointu.
Na danym systemie sprawdzić powiązany proces, historię przeglądarki, pobranie i inne zdarzenia bezpieczeństwa.
Po potwierdzeniu kompromitacji odizolować system i obsłużyć go zgodnie z wewnętrznym runbookiem Incident Response.
Dopiero po analizie zdecydować o czyszczeniu, dodatkowej blokadzie lub bardzo wąskim wyjątku.

W przypadku Synchronized Security na obsługiwanych endpointach Windows mogą pojawić się także użytkownik procesu, Endpoint ID i ścieżka wykonania. Na macOS te informacje o procesie nie są dostępne; Source IP pozostaje tam szczególnie ważny dla identyfikacji.

Znany fałszywy alarm HA `NC-170292`

W systemie HA z SFOS 21.5.1 MR1 Build 261 problem NC-170292 może wygenerować w Sophos Central fałszywy alarm Advanced threat detected z Raw Logs. Jednocześnie może nadejść wiadomość e-mail z firewalla bez przydatnych szczegółów.

To ograniczenie nie dotyczy ogólnie innych buildów ani firewalli standalone. Alarm należy więc najpierw zabezpieczyć i przeanalizować zgodnie z powyższym opisem. Jeśli system dokładnie odpowiada wersji objętej problemem i brakuje wiarygodnych szczegółów zdarzenia, Sophos wskazuje restart usługi Garner jako tymczasowe obejście. Ponieważ Known Issues List nie podaje konkretnego polecenia CLI dla tego błędu, restart należy wykonywać wyłącznie zgodnie z zatwierdzoną procedurą wsparcia lub utrzymania. Przy powtarzających się alarmach do zgłoszenia Sophos Support należy dołączyć status HA, firmware build, znacznik czasu i garner.log.

Wyjątki dopiero po potwierdzonej analizie

W Protect > Active threat response > Add threat exclusions można dodać Host and network exclusions oraz Threat exclusions dla adresów IP, domen lub URL. Taki wyjątek nie dotyczy wyłącznie X-Ops, lecz wszystkich modułów Active Threat Response. Szybko dodany wyjątek może więc jednocześnie osłabić ochronę MDR, NDR lub Third-Party Threat Feeds.

Po potwierdzeniu false positive należy wykluczyć tylko najmniejszy niezbędny wskaźnik. Wyjątek powinien mieć uzasadnienie, numer ticketu, osobę odpowiedzialną i datę przeglądu. Prewencyjne wykluczanie całych sieci klienckich lub szerokich zakresów domen usuwa widoczny alarm, ale także dużą część ochrony.

Po zmianie ponownie sprawdza się ten sam proces biznesowy i w Log Viewer potwierdza, że znika tylko zamierzone zdarzenie. Pozostałe zdarzenia X-Ops muszą być nadal rejestrowane albo blokowane.