Bezpieczna konfiguracja i obsługa Sophos Firewall Threat Feeds

Sophos Firewall Threat Feeds automatycznie importują znane złośliwe adresy IP, domeny i adresy URL jako wskaźniki naruszenia bezpieczeństwa (IoC). Bezpieczne wdrożenie polega na tym, aby najpierw obserwować feed w trybie Monitor, sprawdzić trafienia i skutki uboczne, a dopiero potem przełączyć go na Block.

Ten artykuł dotyczy przede wszystkim Third-Party Threat Feeds, takich jak feedy firmy Cybora. Funkcję wprowadzono w Sophos Firewall v21.

Konfiguracja Threat Feed

Third-Party Threat Feeds wymagają pakietu Xstream Protection Bundle, ale nie dodatkowej licencji Sophos Fusion (dawniej Sophos Central). Firewall musi mieć dostęp do adresu URL feedu przez DNS i HTTPS.

1. Otworzyć System services > Log settings.
2. W sekcji Active threat response włączyć co najmniej jedno obsługiwane miejsce docelowe logów. Dla lokalnego Log Viewer jest to Local reporting. Modele XGS 87/87w i 107/107w nie obsługują lokalnego reportingu; należy w nich użyć Sophos Fusion albo serwera syslog.
3. Aby widzieć trafienia w przychodzącym ruchu DNAT i WAF, włączyć również Remote source match (inbound traffic). Opcja ta jest domyślnie wyłączona.
4. Otworzyć Protect > Active threat response > Third-party threat feeds > Add.
5. Wprowadzić jednoznaczną nazwę i opis, na przykład:
   • Pilotaż: Name cybora-premium-ipv4-monitor, Description Cybora Premium IPv4 - Pilot
   • Sprawdzony feed produkcyjny: Name cybora-premium-ipv4, Description Cybora Feed - Premium
6. Jako Indicator type wybrać IPv4 address, Domain albo URL. Jeśli źródło udostępnia kilka typów, dla każdego tworzy się osobny feed.
7. Na czas wdrożenia ustawić Action na Monitor. Po sprawdzonym okresie obserwacji można przełączyć na Block.
8. W sekcji Position wybrać Top dla feedu pilotażowego, aby jego trafienia nie zasłonił inny feed zewnętrzny. Bottom jest odpowiednie dla feedu o niższym priorytecie, którego nakładanie się z innymi listami jest już znane.
9. W sekcji External URL wprowadzić odpowiedni adres z listy feedów Avanet albo od dostawcy. URL musi zwracać plik tekstowy bezpośrednio. Jeśli endpoint odpowie na przykład kodem HTTP 302, SFOS klasyfikuje to jako Connection error. Plik zawiera jeden wskaźnik w każdym wierszu.
10. W sekcji Authorization wybrać No authentication, API key albo Basic authentication. API key można przesyłać w Header lub w Query parameters; jego wartość oraz hasło Basic Authentication obsługują po maksymalnie 64 znaki. Danych uwierzytelniających nie należy umieszczać w zgłoszeniach ani na zrzutach ekranu.
11. Włączyć Validate server certificate. W przypadku certyfikatu publicznego wystawiająca go CA musi znajdować się w Certificates > Certificate authorities; przy prywatnej CA należy najpierw zaimportować jej certyfikat.
12. Wybrać Polling interval zgodny z częstotliwością aktualizacji dostawcy.
13. Uruchomić Test connection i zapisać przyciskiem Save.

Następnie sprawdzić Sync status, Last updated, liczbę Threat indicators i dostępną Storage quota. Success potwierdza pobranie, ale nie oznacza jeszcze, że oczekiwany ruch jest rzeczywiście wykrywany lub blokowany. Działanie trzeba osobno zweryfikować w Log Viewer.

Wybór właściwego feedu i akcji

Obsługiwane wskaźniki

Feed zawiera dokładnie jeden z następujących typów:

• IPv4 address: skanery, botnety, przejęte systemy lub serwery C2
• Domain: domeny malware, phishingowe lub command-and-control
• URL: konkretne złośliwe ścieżki albo odsyłacze do pobierania

Feed musi być plikiem tekstowym zawierającym jeden wskaźnik w każdym wierszu. Zakresy IP, adresy IPv6, sieci, domeny z wildcard i wyrażenia regularne nie mogą zastępować pojedynczych obsługiwanych IoC w Third-Party Threat Feeds.

SFOS nie narzuca stałej liczby IoC w jednym Third-Party Feed. Użyteczny rozmiar jest ograniczony zależną od modelu wartością Storage quota. Po imporcie należy wspólnie sprawdzić wolną przestrzeń, liczbę Threat indicators i poprawne pobranie feedu.

Duża lista nie jest automatycznie dobrą listą. Pochodzenie, aktualność, częstotliwość aktualizacji, ryzyko false positives i trafienia we własnym środowisku są ważniejsze niż sama liczba wpisów. Feed, który trwale nie przynosi korzyści, zajmuje jedynie miejsce.

Monitor przed Block

Monitor rejestruje trafienia, ale przepuszcza ruch. Pokazuje w ten sposób, których źródeł, miejsc docelowych i usług dotyczyłoby działanie. Block rejestruje i odrzuca pasujący ruch.

Dla nowego feedu zalecana jest następująca kolejność:

1. Umieścić feed u góry listy Third-Party.
2. Rozpocząć od Monitor.
3. Przez reprezentatywny okres sprawdzać trafienia i możliwe false positives.
4. Udokumentować osobę odpowiedzialną i proces obsługi wyjątków.
5. Dopiero potem przełączyć na Block.

Dobrze dobrany feed IPv4 dla silnie wystawionych usług może trafić do produkcji szybciej niż feed domen lub URL. Te ostatnie częściej obejmują współdzieloną infrastrukturę, CDN albo przekierowania, dlatego wymagają szczególnie starannej kontroli.

Przed przełączeniem na Block należy zapisać nazwę feedu, liczbę IoC, pozycję oraz dotychczasowe trafienia. Jeśli zmiana spowoduje nieoczekiwane zakłócenia, trzeba natychmiast ustawić Action tego samego feedu z powrotem na Monitor i ponownie przetestować odpowiedni ruch. Wadliwy lub niekontrolowany feed można tymczasowo wyłączyć. Globalna Threat Exclusion nie jest równoważnym rollbackiem, ponieważ wpływa również na MDR, NDR i Sophos X-Ops.

Kolejność i nazwy

Active Threat Response przetwarza moduły w następującej kolejności: MDR, NDR Essentials, Sophos X-Ops, a następnie Third-Party Threat Feeds. Przy Log and drop trafienie we wcześniejszym module kończy dalsze sprawdzanie. Przy Log only lub Monitor firewall rejestruje natomiast osobne zdarzenia dla MDR, X-Ops i Third-Party Threat Feeds.

W obrębie Third-Party Threat Feeds firewall ocenia listy Block i Monitor oddzielnie, w wyświetlanej kolejności. Rejestruje pierwsze trafienie na każdej liście i blokuje na podstawie pierwszego trafienia na liście Block. Feedy produkcyjne i pilotażowe oraz tymczasowe listy incydentów należy więc jasno nazywać i porządkować:

• cybora-premium-ipv4-block
• cybora-standard-domain-monitor
• incident-2026-06-c2-ipv4

Dobra nazwa wskazuje dostawcę lub cel, typ wskaźnika i akcję. Oszczędza to czas podczas analizy logów i przeglądów.

Rozróżnienie modułów Threat Feed

W sekcji Active threat response znajdują się różne funkcje o odmiennych zadaniach i wymaganiach licencyjnych:

• Sophos X-Ops Threat Feeds: wskaźniki Sophos; wymagają Network Protection, a do egzekwowania również Web Protection. Oba składniki znajdują się w pakiecie Standard lub Xstream albo mogą być licencjonowane osobno.
• MDR Threat Feeds: IoC z Sophos MDR; wymagają Xstream Protection Bundle oraz MDR Essentials lub MDR Complete w Sophos Fusion. Osobny przewodnik opisuje integrację z Sophos Fusion, lokalną akcję, Audit ID, Task Queue i weryfikację incydentu.
• Third-Party Threat Feeds: zewnętrzne listy IPv4, domen lub URL; wymagają Xstream Protection Bundle.
• NDR Essentials: analizuje ruch przy użyciu machine learning i wymaga Xstream Appliance Bundle.
• NDR Active Threat Intelligence: rejestruje wybrane przez Sophos wzorce NDR, wymaga Xstream Protection Bundle i musi być włączone osobno dla każdej reguły firewall przez Scan with NDR Active threat intelligence. Modele XGS 87/87w i 88/88w nie są obsługiwane.

Do korzystania z Synchronized Security i dodatkowego kontekstu endpointa w logach Active Threat Response potrzebna jest także licencja Intercept X w Sophos Fusion. Licencja ta nie jest wymagana dla samego Threat Feed, lecz do wzbogacenia zdarzenia o dane hosta, użytkownika i procesu.

Korzystanie z Synchronized Security jest opcjonalne przy dopasowywaniu Threat Feedów. Jeśli zarządzany Sophos Endpoint po połączeniu ze złośliwym serwerem wyśle czerwony Security Heartbeat, prawidłowo skonfigurowana reguła Heartbeat może zablokować jego ruch; Lateral Movement Protection może dodatkowo odizolować przejęty endpoint od sieci wewnętrznej. Ta reakcja endpointa uzupełnia feed i jego logi, ale nie zastępuje konfiguracji feedu ani reguły firewall.

Dla NDR dostępna jest osobna instrukcja Obsługa Sophos Firewall NDR i Active Threat Response.

Zrozumienie wpływu na ruch

Ruch IPv4, domenowy i URL

Przekazywany ruch IPv4 wymaga reguły firewall, która go przetwarza. Ruch skierowany do systemu, do usług w Administration > Device access, takich jak WebAdmin, VPN Portal i VPN, jest osobno porównywany ze wskaźnikami źródłowych adresów IP i nie przechodzi przez tranzytową regułę firewall.

Zapytania DNS, na które odpowiada sam firewall jako serwer DNS, są porównywane z domenowymi IoC przez moduł DNS. Jeśli klienci używają innego serwera DNS, IPS musi widzieć ruch DNS. Sam feed domen nie dowodzi więc, że rzeczywista ścieżka resolvera jest sprawdzana.

W przypadku przekazywanego ruchu feedy domen wymagają dodatkowo Application Classification albo polityki IPS w regule firewall. Application Classification jest domyślnie włączona, ale mimo to należy ją sprawdzić w ścieżce odpowiedniej reguły.

Przy pełnych adresach URL HTTPS firewall musi również widzieć ścieżkę. W ścieżce Web Proxy w regule firewall w sekcji Web filtering wybiera się Use web proxy instead of DPI engine oraz Decrypt HTTPS during web proxy filtering. W ścieżce DPI opcja Use web proxy instead of DPI engine pozostaje wyłączona, a dodatkowo dodaje się odpowiednią regułę inspekcji SSL/TLS z ustawieniem Action: Decrypt. Bez deszyfrowania firewall widzi przez SNI tylko domenę, a nie pełną ścieżkę URL.

DNAT i WAF od SFOS 22

Od SFOS 22 firewall może porównywać źródłowy adres IP przychodzącego, przekazywanego ruchu dla DNAT i WAF z MDR, NDR i Third-Party Threat Feeds. Pozwala to wykrywać znane skanery i botnety, zanim dotrą do opublikowanych usług.

Aby te trafienia pojawiały się w logu Active Threat Response, w System services > Log settings > Active threat response musi być włączona opcja Remote source match (inbound traffic). Domyślnie jest wyłączona. Bez tego ustawienia blokowanie może działać, a oczekiwane zdarzenia DNAT lub WAF mogą nie pojawić się w Log Viewer.

Typowe zastosowania

Threat Feeds pomagają nie tylko w ochronie wychodzącego ruchu klientów. Publicznie dostępne usługi są często automatycznie skanowane już wkrótce po ich udostępnieniu.

• DNAT do serwerów wewnętrznych: Feed IPv4 może blokować znane złośliwe źródła, zanim dotrą do opublikowanego serwera.
• Usługi publikowane przez WAF: Dane reputacyjne uzupełniają reguły WAF w ochronie przed ruchem botów, skanami pod kątem CVE, sondowaniem systemów CMS i credential stuffingiem.
• VPN Portal, User Portal i WebAdmin: Usługi te należy najpierw zabezpieczyć za pomocą MFA, sieci źródłowych oraz Device Access i Local Service ACL. Threat Feeds dodatkowo ograniczają ruch ze znanych źródeł ataków.
• Wychodzący ruch klientów: Feedy domen i URL mogą blokować znane cele związane z malware, phishingiem i C2.
• Intensywnie skanowane adresy WAN: Dobry feed IPv4 ogranicza automatyczny szum oraz odciąża firewall i logi.

Threat Feeds uzupełniają podstawowy hardening, ale go nie zastępują. Opublikowane usługi nadal wymagają restrykcyjnych reguł DNAT lub WAF, otwarcia tylko niezbędnych portów, odpowiednich ograniczeń źródłowych lub geograficznych, IPS albo WAF oraz włączonego logowania. Feed nie usprawiedliwia szerokich reguł Any. Cały proces opisuje Sophos Firewall Hardening Hub.

Kontrola synchronizacji i działania

Osobny test pobierania feedu i wpływu na ruch

Udane połączenie i Sync status: Success dowodzą tylko, że firewall mógł pobrać i wczytać listę. Pełna weryfikacja obejmuje trzy poziomy:

1. Pobieranie: Test connection, Sync status, Last updated i Storage quota są wiarygodne.
2. Zawartość: oczekiwany IoC jest widoczny w Threat indicators.
3. Działanie: kontrolowany ruch testowy generuje trafienie w Log viewer > Active threat response albo w skonfigurowanym miejscu docelowym Sophos Fusion lub syslog. Zależnie od dopasowania można prześledzić nazwę feedu, Log/Drop, kierunek dopasowania, źródło i miejsce docelowe lub URL, protokół oraz porty.

Do powtarzalnego testu można użyć krótkiego własnego feedu pilotażowego na kontrolowanym serwerze HTTPS. Zawiera on adres IPv4 również kontrolowanego celu testowego. Feed pozostaje w trybie Monitor, klient laboratoryjny łączy się z celem testowym, a administrator sprawdza wpis w logu. Do testów nie należy otwierać aktywnych celów malware ani obcych systemów.

Synchronizacja i Storage Quota

W codziennej eksploatacji ważne są następujące wartości w przeglądzie feedów:

• Success, Fetching albo Disabled w Sync status
• oczekiwany znacznik czasu w Last updated
• wiarygodna liczba Threat indicators
• wystarczająca wolna Storage quota
• udana ręczna aktualizacja przez Synchronize now

Summary pokazuje Active feeds, Total threat indicators i Storage quota. Refresh aktualizuje tylko te wyświetlane liczniki. Synchronize now natomiast natychmiast pobiera wybrany feed. Poszczególne IoC można otwierać i wyszukiwać przez Threat indicators lub przez liczbę wskaźników odpowiedniego feedu.

Przy Authentication error należy sprawdzić API key lub dane uwierzytelniające, a przy Connection error — DNS, dostęp do Internetu, status HTTP i serwer feedu. SSL/TLS error wskazuje na certyfikat lub łańcuch certyfikatów, natomiast Failed często oznacza nieprawidłowy format feedu albo niepoprawne wskaźniki.

Jeśli przestrzeń jest pełna, firewall nadal pobiera feed zgodnie ze skonfigurowanym interwałem, ale aktualizuje zapisaną listę IoC dopiero po zwolnieniu miejsca. Zamiast dodawać kolejne listy należy więc sprawdzić zakres, jakość i priorytet feedów. Na urządzeniach XGS 87/87w, 88/88w i 107/107w dla Third-Party Threat Feeds dostępne są tylko interwały odpytywania 24h, 7d i 30d. Częściej aktualizowany feed dostawcy nie znosi tego ograniczenia urządzenia.

Gdy nie pojawiają się trafienia

Zalecana kolejność kontroli:

1. Feed aktywny, Sync status: Success i oczekiwany IoC w Threat indicators
2. wykrycie o wyższym priorytecie przez MDR, NDR lub X-Ops dla tego samego IoC
3. logging Active Threat Response i, dla DNAT/WAF, Remote source match
4. odpowiednia reguła firewall i jej logging
5. dla domen Application Classification albo polityka IPS
6. dla URL Web Proxy lub DPI oraz SSL/TLS Inspection
7. Threat Exclusions, Web Exclusions i SSL/TLS Exclusion Lists

Aby prześledzić dozwolony IoC domeny lub URL do odpowiedzialnej reguły, należy otworzyć Log viewer > Web filter, wyszukać IoC w Category lub bezpośrednio domenę i otworzyć widok szczegółowy. Zawiera on Firewall Rule ID oraz Web policy wybraną w tej regule. Jeżeli akcja pasującej polityki to Allow, trzeba sprawdzić kolejność reguł i polityki. Zamierzona blokada wykorzystuje wąsko zdefiniowaną URL Group w blokującej Web Policy, przypisanej do reguły LAN-to-WAN o wyższym priorytecie. Następnie należy powtórzyć ten sam test ruchu.

Dla ścieżki DPI należy również otworzyć Log viewer > SSL/TLS inspection, wyszukać URL w Server name oraz sprawdzić Action i SSL/TLS rule. IoC typu URL wymaga Decrypt. Jeżeli trafienie pokazuje Don't decrypt, Rule ID wskazuje wyjątek lub regułę omijającą deszyfrowanie. Dopiero po takim przypisaniu należy dodać wąsko zdefiniowaną URL Group do reguły Decrypt o wyższym priorytecie. Wdrażanie TLS Inspection krok po kroku opisuje kontrolowany proces.

Jeżeli feed przez reprezentatywny okres obserwacji nie generuje istotnych trafień, należy ponownie ocenić jego użyteczność.

Obsługa false positives

Przy nieprawidłowym zablokowaniu należy najpierw otworzyć wpis w logu i udokumentować nazwę feedu, Log/Drop, kierunek dopasowania, źródło i miejsce docelowe lub URL, protokół oraz porty. Następnie potwierdzić, że ruch jest prawidłowy, zgłosić dany wskaźnik dostawcy feedu i utworzyć tylko możliwie wąski wyjątek z uzasadnieniem, osobą odpowiedzialną i datą przeglądu.

Szeroki wyjątek dla całych sieci nie jest właściwym rozwiązaniem. Przy trafieniach domen lub URL udział mogą mieć także TLS Inspection, Web Policy, DNS Protection albo inna funkcja ochronna.

Kontrolowany wyjątek tworzy się w Protect > Active threat response > Add threat exclusions. Host and network exclusions wykorzystuje istniejące obiekty hostów lub sieci. W sekcji Threat exclusions należy wprowadzić pojedynczy adres IP, domenę lub URL; jeden wpis może zawierać maksymalnie 128 znaków. Po wybraniu Add i Apply trzeba powtórzyć ten sam test ruchu i potwierdzić w Log Viewer, że przestała pojawiać się tylko oczekiwana detekcja.

⚠️ Threat Exclusion dotyczy wszystkich modułów Active Threat Response, a nie tylko feedu, który spowodował false positive. Przed wybraniem Apply należy ocenić wpływ na MDR, NDR, Sophos X-Ops i Third-Party Threat Feeds. Trzeba udokumentować wpis, przyczynę, właściciela i datę przeglądu oraz usunąć wyjątek, gdy nie jest już potrzebny.

Backup i restore

Backup firewalla zawiera konfigurację Third-Party Threat Feeds, ale nie pobrane listy. Po restore firewall natychmiast ponownie pobiera źródła i stosuje skonfigurowaną akcję. DNS, dostęp do Internetu, walidacja certyfikatów i dane uwierzytelniające muszą więc działać bezpośrednio po odtworzeniu.

Konfiguracji Threat Feed nie można osobno importować ani eksportować; jest to natomiast możliwe dla Threat Exclusions. Po restore należy ponownie sprawdzić pobieranie feedu, liczbę IoC i wpływ na ruch.

Cybora Threat Feeds dla Sophos Firewall

Cybora dostarcza feedy IPv4, domen i URL jako pliki tekstowe przez HTTPS, z jednym wskaźnikiem w każdym wierszu. Zgodnie z publicznym opisem produktu łączy źródła OSINT i społecznościowe, komercyjny Threat Intelligence, honeypoty, sensory oraz sygnały z firewalli. Format pasuje więc bezpośrednio do interfejsu zewnętrznego SFOS, ale jego wartość we własnej sieci nadal trzeba potwierdzić w pilotażu z ustawieniem Monitor.

Cybora służy tu jako konkretny przykład dostawcy. Do każdego innego dostawcy należy stosować te same kryteria techniczne: odpowiednie typy wskaźników, plik dostępny bezpośrednio, aktualne dane, akceptowalne false positives, trafienia możliwe do prześledzenia i dostępny proces korekty.

Porównanie planów

Free (Basic) zawiera tylko wskaźniki IPv4 i jest aktualizowany co 24 godziny, dzięki czemu pozwala sprawdzić dostarczanie danych i zgodność z SFOS przed zakupem. Standard dostarcza IPv4 oraz mniejszy zestaw domen co sześć godzin. Premium dostarcza IPv4, domeny i URL co godzinę, a Ultimate te same typy wskaźników co 15 minut. Na XGS 87/87w, 88/88w i 107/107w najkrótszy interwał odpytywania dostępny w SFOS nadal wynosi jednak 24h, niezależnie od planu dostawcy.

Oprócz liczby wpisów i ceny liczą się aktualność, obsługiwane typy wskaźników, jakość źródeł, częstotliwość aktualizacji, ryzyko false positives i możliwość prześledzenia zdarzeń w Log Viewer. Właściwy feed to taki, który zapewnia istotne trafienia przy akceptowalnych skutkach ubocznych we własnym środowisku.

Avanet Firewall Network

Część feedu Premium pochodzi z rozproszonej sieci firewalli. Taka perspektywa pomaga rozpoznawać wzorce ataków, które są niemal niewidoczne na pojedynczym firewallu.

W rozproszonych atakach brute force każdy bot wykonuje tylko kilka nieudanych prób logowania i często pozostaje poniżej lokalnego progu. Połączenie zanonimizowanych sygnałów ujawnia adresy IP, które celowo atakują infrastrukturę w wielu systemach. W ten sposób powstaje stale aktualizowany Threat Intelligence Feed do automatycznej ochrony.