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 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 Central 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 External URL wprowadzić odpowiedni adres z listy feedów Avanet albo od własnego dostawcy. Plik musi zawierać jeden wskaźnik w każdym wierszu.
9. W razie potrzeby skonfigurować API key albo Basic Authentication. Danych uwierzytelniających nie należy umieszczać w zgłoszeniach ani na zrzutach ekranu.
10. 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.
11. Wybrać Polling interval zgodny z częstotliwością aktualizacji dostawcy.
12. 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.

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.

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 Central. Osobny przewodnik opisuje integrację Central, 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.

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.

W przypadku przekazywanego ruchu feedy domen wymagają dodatkowo Application Classification albo polityki IPS w regule firewall.

Przy pełnych adresach URL HTTPS firewall musi również widzieć ścieżkę. Wymaga to Web Proxy z deszyfrowaniem HTTPS albo DPI z odpowiednią regułą inspekcji SSL/TLS. 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 Central 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

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, zamiast dodawać kolejne listy należy 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

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.

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 udostępnia wyselekcjonowane feedy, dzięki czemu administratorzy nie muszą samodzielnie zbierać, normalizować i stale sprawdzać wielu list OSINT. Dane pochodzą między innymi ze źródeł społecznościowych i OSINT, komercyjnego Threat Intelligence, honeypotów oraz zanonimizowanych logów ataków i anomalii z zarządzanych środowisk Sophos Firewall.

Zespół Avanet przetestował kilku dostawców Threat Feed w rzeczywistych środowiskach firewall. Naszym zdaniem Cybora oferuje obecnie najlepszy stosunek jakości do ceny dla Sophos Firewall. Ocenialiśmy jakość feedów, zakres danych, częstotliwość aktualizacji i koszty. Również taki feed należy najpierw sprawdzić we własnym środowisku pilotażowym w trybie Monitor.

Porównanie planów

Free (Basic) nadaje się dla użytkowników domowych, do proof of concept i testów zgodności. Standard uzupełnia feed IPv4 o domeny malware i phishingowe. Premium rozszerza ochronę o domeny i URL z aktualizacjami co godzinę. Ultimate, aktualizowany co 15 minut, jest przeznaczony dla infrastruktury krytycznej i perymetrów wysokiego ryzyka.

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.