Sophos Firewall Threat Feeds: konfiguracja i operacje

Sophos Firewall Threat Feeds od Cybora dostarczają ciągłe Threat Intelligence Feeds, które automatycznie importują Indicators of Compromise (IoCs) do Sophos Firewall. Takie IoCs to na przykład złośliwe adresy IP, domeny malware, phishing URLs albo znane serwery botnet C&C.

Szerszy kontekst hardening opisuje hub Sophos Firewall Hardening: best practices dla bezpiecznej konfiguracji.

Dzięki temu odpada duża część ręcznej pielęgnacji. Zamiast dopisywać pojedyncze adresy IP atakujących albo domeny ręcznie w host objects, firewall rules albo blocklists, firewall pobiera dane automatycznie z kuratorowanego feedu i może blokować pasujący traffic.

Jest to szczególnie cenne, gdy firewall jest widoczny z zewnątrz. Publiczne IP, DNAT rules, publikacje WAF, VPN portals albo dostęp WebAdmin są zwykle bardzo szybko znajdowane przez bots, scanners i automatyczne exploit frameworks. Dobry Threat Feed redukuje taki niepożądany traffic, zanim trafi głębiej do środowiska.

Krótko mówiąc: Threat Feeds są mocne wtedy, gdy traktuje się je jako proces operacyjny. Wybrać feed, poprawnie ustawić indicator type, najpierw przetestować widoczność, potem blokować, regularnie sprawdzać trafienia i czysto obsługiwać False Positives. Samo podpięcie dużej listy nie jest dobrą strategią bezpieczeństwa.

Klasyfikacja

Czym są Threat Feeds

Threat Feeds, czyli feedy zagrożeń, to listy indykatorów kompromitacji. W praktyce są to wskazania znanej złośliwej infrastruktury:

• IP addresses: scanners, botnets, skompromitowane systemy albo Command-and-Control servers.
• Domains: malware, phishing albo C2 domains.
• URLs: konkretne złośliwe ścieżki albo download links.

W zależności od dostawcy takie feedy pochodzą z organizacji security, konsorcjów branżowych, open-source communities, komercyjnej Threat Intelligence, honeypots albo własnych sensorów. W Sophos Firewall v21 funkcja została rozszerzona o third-party feeds, które są podpinane przez Active Threat Response Framework.

Zalety są jasne:

• Proaktywny protection: blokowanie zagrożeń, zanim powstaną szkody.
• Elastyczność: użycie feedów różnych dostawców, dopasowanych do indywidualnych wymagań.
• Automatyzacja: firewall blokuje automatycznie; ręczne interwencje odpadają.
• Odciążenie: niepożądany traffic jest odrzucany wcześniej i nie dociera do wewnętrznych usług.

Nie mieszać modułów Threat Feed

Pod Active threat response znajduje się kilka funkcji obok siebie. Nazwy brzmią podobnie, ale rozwiązują różne zadania.

• Sophos X-Ops Threat Feeds: własne indykatory Sophos dla znanych zagrożeń. W operacjach aktywować funkcję Network Protection i sprawdzać logi.
• MDR Threat Feeds: informacje o zagrożeniach z kontekstu Sophos MDR/XDR. W operacjach połączyć proces MDR/Central z firewall logging.
• Third-Party Threat Feeds: zewnętrzne listy IoC, takie jak Cybora, jako IP, Domain albo URL feed. W operacjach odpowiadać za jakość feedu, akcję, synchronizację i wyjątki.
• NDR Essentials / NDR Active Threat Intelligence: wykrywanie podejrzanych wzorców ruchu zamiast czystej listy IoC. W operacjach analizować detection signals i nie mylić ich z blocklistą.

Ten artykuł dotyczy przede wszystkim Third-Party Threat Feeds. Dla NDR i Active Threat Intelligence pasuje Sophos Firewall NDR i Active Threat Response w operacjach.

Typowe zastosowania

Threat Feeds są interesujące nie tylko dla wychodzącego client traffic. Szczególnie przy publicznie osiągalnych usługach w praktyce bardzo szybko widać automatyczne dostępy.

• DNAT na wewnętrzne serwery: port forwards są szybko skanowane. IPv4 feed może blokować znane złe źródła, zanim dotrą do wewnętrznego serwera.
• Publikacje WAF: web servers często widzą bot traffic, CVE scans, CMS probes i credential stuffing. Threat Feeds uzupełniają WAF rules o reputację.
• VPN Portal, User Portal i WebAdmin: portale powinny być najpierw chronione przez Device Access, MFA i source networks. Threat Feeds dodatkowo redukują znane źródła atakujących.
• Wychodzący client traffic: domain i URL feeds mogą blokować znane cele malware, phishing albo C2.
• Mocno skanowane WAN addresses: jeśli publiczny IP stale widzi bot traffic, dobry IPv4 feed może odczuwalnie odciążyć firewall i logi.

Od SFOS 22 Threat Feeds są szczególnie interesujące dla przychodzącego, forwardowanego trafficu, takiego jak DNAT i WAF. Firewall może dzięki temu rozpoznawać znane złe źródła także przed opublikowanymi usługami. Przy starszych instalacjach albo mieszanych wersjach należy świadomie sprawdzić ten punkt, zanim założy się taki sam poziom ochrony.

Threat Feeds nie zastępują jednak czystej publikacji. Jeśli usługa jest osiągalna przez DNAT albo WAF, nadal należy otwierać tylko potrzebne ports, ograniczać source networks albo kraje, aktywować IPS/WAF rules i sprawdzać logi. Threat Feeds są dodatkowym elementem ochrony, a nie przepustką dla szerokich reguł Any.

Wymagania i licencja

Aby używać Third-Party Threat Feeds na Sophos Firewall, potrzebny jest Xstream Protection Bundle. Dla tego modułu nie są potrzebne dodatkowe licencje Sophos Central. Inne moduły Threat Feed mają własne wymagania: Sophos X-Ops Threat Feeds wymaga Network Protection, MDR Threat Feeds wymaga dodatkowo Sophos MDR Essentials albo MDR Complete w Sophos Central, a NDR Essentials wymaga Xstream Appliance Bundle.

Przed rolloutem należy dodatkowo sprawdzić:

• Firewall działa na wersji SFOS z obsługą Third-Party Threat Feed.
• Firewall może osiągnąć feed URL przez DNS i HTTPS.
• Dla każdego feedu używany jest jasny Indicator type, na przykład IPv4 address, Domain albo URL.
• Feed jest plikiem tekstowym z jednym wskaźnikiem w każdej linii.
• Zakresy IP, adresy IPv6, adresy sieciowe, wildcard domains i wyrażenia regularne nie są właściwym formatem dla Third-Party Threat Feeds.
• Logging dla Active Threat Response jest aktywny.
• Jest jasne, czy feed ma być najpierw tylko obserwowany, czy od razu blokować.

Praktyczna rekomendacja: nowe feedy wprowadzać najpierw kontrolowanie. Jeśli firewall pozwala, zacząć od fazy obserwacji, sprawdzić trafienia w Log Viewer i dopiero potem przełączyć na blokowanie. Dzięki temu wcześnie widać, czy dotknięte byłyby legalne systemy.

URL feeds i TLS Inspection

IP i Domain feeds są zwykle proste do zrozumienia. URL feeds są bardziej wymagające, bo firewall musi widzieć właściwą ścieżkę URL. Przy HTTPS traffic nie zawsze jest to możliwe bez odpowiedniego odszyfrowania.

Jeśli URL feeds mają być używane produkcyjnie, trzeba sprawdzić, czy Web Proxy, DPI Engine i TLS Inspection pasują do środowiska. Bez czystej widoczności HTTPS traffic URL feed może być mniej skuteczny, niż się oczekuje.

Planowanie przed rolloutem

Monitor czy Block?

Threat Feed może, zależnie od wersji SFOS i konfiguracji, monitorować albo blokować. Dla produkcyjnego bezpieczeństwa blokowanie jest często celem, ale nie każdy feed powinien od razu ślepo trafić w tryb Block.

• Monitor: pokazać trafienia bez bezpośredniego blokowania trafficu. Sprawdzić przy tym wolumen logów, dotknięte źródła/cele i nieoczekiwane trafienia.
• Block: aktywnie zatrzymywać znane złośliwe indykatory. Przygotować proces False Positive, alerting i wyjątki.
• Review: sprawdzić skuteczność i skutki uboczne. Ocenić jakość feedu, stare trafienia, support cases i ryzyko biznesowe.

Przy mocno eksponowanych usługach dobrze kuratorowany IPv4 feed może od razu mocno ograniczyć szum. Przy Domain albo URL feeds należy być ostrożniejszym, bo legalne usługi częściej działają przez współdzieloną infrastrukturę, CDNs albo redirects.

Kolejność i pozycja feedów

Przy dodawaniu Third-Party Feed można ustawić Feed Position. Brzmi to banalnie, ale pomaga w operacjach: krytyczne, dobrze kuratorowane feedy powinny mieć jednoznaczne nazwy i kolejność. Test feeds, feedy tymczasowe albo źródła z wyższym ryzykiem False Positive nie powinny być ukryte między feedami produkcyjnymi.

Praktyczna konwencja nazw:

• Produkcyjny IPv4 block feed: cybora-premium-ipv4-block
• Domain feed w trybie Monitor: cybora-standard-domain-monitor
• Tymczasowy incident feed: incident-2026-06-c2-ipv4

Dobra nazwa pokazuje dostawcę, plan albo cel, indicator type i akcję. Oszczędza to czas w Log Viewer i przy późniejszych reviews.

Synchronizacja i Storage Quota

Sophos Firewall pokazuje przy Third-Party Threat Feeds aktywne feedy, łączną liczbę Threat Indicators, Storage Quota i status synchronizacji. Tych wartości nie należy ignorować po konfiguracji.

Ważne kontrole:

• Sync status: Success, Fetching albo Disabled można szybko sklasyfikować. Przy Authentication error, Connection error, Storage full, SSL/TLS error albo Failed należy celowo sprawdzić przyczynę i feed.
• Last updated: znacznik czasu pasuje do oczekiwanego polling interval.
• Storage quota: firewall ma jeszcze dość miejsca na załadowane IoCs.
• Threat indicators: liczba mniej więcej pasuje do oczekiwań dostawcy.
• Synchronize now: ręczna synchronizacja działa, gdy zmiana nie powinna czekać na kolejny polling interval.

Jeśli Storage Quota jest pełna, winny nie musi być automatycznie dostawca feedu. Małe appliances mają mniej zapasu niż większe modele. Firewall nadal pobiera IoCs w skonfigurowanym interwale i aktualizuje listę, gdy miejsce znów będzie dostępne. Mimo to lepiej sprawdzić zakres feedów, indicator types i priorytet, zamiast podpinać coraz więcej list.

Na mniejszych modelach XGS ograniczony może być również polling interval. Według Sophos modele XGS 87/87w, 88/88w i 107/107w obsługują dla Third-Party Threat Feeds tylko 24h, 7d i 30d jako opcje Polling interval. Jeśli kupiony feed aktualizuje się częściej, tę różnicę platformy trzeba uwzględnić w oczekiwaniach dotyczących aktualności i efektu blokowania.

Od Free do Ultimate Threat Feed - by Cybora

Niezawodne i aktualne informacje o zagrożeniach są kluczowe. Avanet stawia dlatego na kuratorowane plany Threat Feed od Cybora, przygotowane specjalnie do użycia na Sophos Firewalls.

Feedy są zestawiane z różnych źródeł, aby zapewnić możliwie szeroką i wiarygodną detekcję zagrożeń. Obejmują community i OSINT data, komercyjnie kupowane informacje, wyniki z honeypots oraz zanonimizowane attack, error i anomaly logs z realnie obsługiwanych środowisk Sophos Firewall.

Free (Basic) nadaje się dla home users, PoC i testów kompatybilności. Standard uzupełnia IPv4 feed o ważne malware i phishing domains. Premium rozszerza pokrycie o domains i URLs z hourly updates. Ultimate jest przeznaczony dla critical infrastructure i high-risk perimeter z 15-minute updates.

Sophos Firewall Threat Feeds pozwalają wcześniej odfiltrowywać znaną złośliwą infrastrukturę. Zależnie od środowiska darmowy plan Basic wystarcza do testów, a Standard, Premium i Ultimate są przeznaczone do wymagań produkcyjnych z rosnącym pokryciem i aktualnością.

Cybora pasuje szczególnie wtedy, gdy potrzebny jest konkretny, kupowany feed dla Sophos Firewall i organizacja nie chce samodzielnie zbierać, formatować, sprawdzać i utrzymywać wielu list OSINT. Praktyczna wartość leży nie w największej liście, ale w kuratorowanych indykatorach, jasnych planach feedów i ścieżce operacyjnej pasującej do funkcji Third-Party Threat Feed w Sophos Firewall.

Porównanie Threat Feeds

Przy porównaniu nie należy patrzeć tylko na liczbę wpisów. Ogromna lista nie jest automatycznie lepsza, jeśli generuje dużo False Positives albo jest źle utrzymywana. Decydujące jest, aby feed był aktualny, kuratorowany i dobrze używalny przez firewall.

Ważne kryteria:

• aktualność danych
• obsługiwane indicator types
• jakość i kuratorowanie źródeł
• update interval
• ryzyko False Positive
• odtwarzalność w Log Viewer
• sensowny proces wyjątków

Avanet Firewall Network

Częścią Premium Feed są dane z rozproszonej sieci firewalli. Ten widok jest szczególnie interesujący przy wzorcach ataków, które na pojedynczym firewallu prawie nie rzucają się w oczy.

Wiele narzędzi bez problemu rozpoznaje brute-force attacks z pojedynczych IP addresses, ale zawodzi przy rozproszonych atakach przez botnets. W takich przypadkach każdy host kontrolowany przez atakującego wykonuje tylko kilka nieudanych prób logowania z niską częstotliwością i omija w ten sposób wykrycie oraz blokadę.

Niektóre botnets obejmują setki tysięcy zainfekowanych hostów, dzięki czemu cybercriminals mogą prowadzić masowe brute-force attacks bez blokady.

Z takich wzorców powstaje stale aktualizowany Threat Intelligence Feed z IPs, które stały się podejrzane na wielu systemach. Przez połączenie i ciągłe zasilanie tych danych do Threat Intelligence Feed identyfikowane są IP addresses, które celowo atakują infrastrukturę, i są automatycznie odpierane.

Czego Threat Feeds nie zastępują

Threat Feeds są mocne, ale nie zastępują czystych podstaw firewalla.

Nie zastępują:

• restrykcyjnych firewall rules
• MFA dla VPN, portals i admin access
• Device Access i Local Service ACL, jak opisano w Zabezpieczanie dostępu do Sophos Firewall
• IPS, WAF, Web Protection i TLS Inspection
• patch management i Hotfixes
• logging, reporting i regularnej kontroli

Jeśli na przykład web server jest publikowany przez DNAT, firewall rule nadal powinna mieć możliwie wąskie źródła, konkretne services i aktywny logging. Threat Feed blokuje znane złe źródła, ale nieznani albo nowi atakujący nadal mogą dotrzeć.

Konfiguracja Sophos Firewall Threat Feed

Integracja Cybora Threat Feeds jest prosta i zajmuje kilka minut. Wszystkie feedy są w pełni kompatybilne z funkcją Third-Party Threat Feed w Sophos Firewall i można je dodać przez web interface firewalla:

1. Otworzyć menu: Protect > Active threat response > Third-party threat feeds > Add
2. Wpisać dane podstawowe
   • Name: cybora-premium-ipv4
   • Description: Cybora Feed - Premium
3. Ustawić indicator type
   • Indicator type: IPv4 address, Domain albo URL
   • Utworzyć oddzielny feed dla każdego indicator type, jeśli to samo źródło oferuje IPs, domains i URLs.
4. Wybrać akcję
   • Dla produkcyjnego blokowania: Block.
   • Dla ostrożnego startu: wybrać Monitor albo akcję obserwującą, jeśli jest dostępna i sensowna.
5. Wprowadzić Feed URL
   • W polu External URL wkleić właściwy adres z listy feedów Avanet.
   • URL musi zwracać plik tekstowy z jednym wskaźnikiem w każdej linii.
6. Ustawić polling interval
   • Polling interval: wybrać zgodnie z zakupionym feedem.
   • Krótszy czas nie pomaga, jeśli sam feed jest aktualizowany tylko w dłuższym interwale.
7. Authentifizierung konfigurieren (jeśli potrzebne)
   • Zależnie od feedu bez authentication albo z dostarczonymi credentials.
8. Przetestować połączenie i zapisać
   • Uruchomić Test connection.
   • Następnie zapisać przez Save.

Po zapisaniu nie należy od razu przechodzić do następnego tematu. Najpierw sprawdzić, czy feed się synchronizuje, czy widoczna jest oczekiwana liczba IoCs i czy Log Viewer pokazuje trafienia z feed name, action, source i destination w sposób odtwarzalny.

Kontrola w operacjach

Po konfiguracji nie należy po prostu zakładać, że wszystko pasuje. Ważne jest, aby trafienia były widoczne i możliwe do wyjaśnienia.

1. Sprawdzić System services > Log settings i aktywować Active-Threat-Response-Logging.
2. W Log viewer filtrować po Active threat response.
3. Sprawdzić, który feed trafił.
4. Skontrolować source, destination, service i dotkniętą firewall rule.
5. Przy False Positives nie ustawiać szerokiego wyjątku, tylko sprawdzić i udokumentować konkretny indykator.

Szczególnie przy DNAT, WAF i VPN portals po aktywacji często bardzo szybko widać, ile niepożądanego trafficu pochodzi ze znanych złych źródeł. Dlatego Threat Feeds szczególnie dobrze nadają się jako dodatkowy element ochrony dla eksponowanych usług.

Jeśli feed nie pokazuje trafień

Brak trafień nie oznacza automatycznie słabego feedu. Inny komponent Active Threat Response może wcześniej rozpoznać ten sam IoC, właściwy traffic może nie przechodzić przez odpowiednią regułę firewall albo firewall może nie widzieć wystarczającego kontekstu dla domen i URL.

Przydatne kontrole:

1. Otworzyć Threat indicators i wyszukać znany testowy indicator.
2. Sprawdzić, czy feed jest aktywny i czy Sync status pokazuje Success.
3. Przy Authentication error sprawdzić dane dostępowe albo API key.
4. Przy Connection error sprawdzić DNS, dostęp do internetu, status HTTP i serwer feedu.
5. Przy SSL/TLS error sprawdzić certyfikat CA i łańcuch certyfikatów serwera feedu.
6. Przy Failed sprawdzić format feedu, otwarcie pliku w przeglądarce i nieprawidłowe indicators.
7. Sprawdzić regułę firewall i Log Viewer dla oczekiwanego trafficu.
8. Przy domain feeds sprawdzić Application Classification albo IPS policy.
9. Przy URL feeds sprawdzić Web Proxy, DPI i regułę SSL/TLS inspection.
10. Skontrolować Threat Exclusions, Web Exclusions i SSL/TLS Exclusion Lists.
11. Jeśli po fazie obserwacji nie ma istotnych trafień, ponownie ocenić zakres albo pozycję feedu.

Obsługa False Positives

False Positives są możliwe przy każdej dynamicznej blockliście. Decydujące jest, jak czysto się z nimi postępuje.

Praktyczny proces:

1. Otworzyć dotknięty wpis w Log Viewer.
2. Zanotować feed name, indicator type, action, Source, Destination i Service.
3. Sprawdzić, czy traffic jest oczekiwany i legalny.
4. Sprawdzić albo zgłosić indykator u dostawcy feedu.
5. Ustawić wyjątek tylko tak wąsko, jak to możliwe.
6. Udokumentować ticket, powód i review date.

Szeroki wyjątek dla całych sieci tylko dlatego, że użytkownik “nie może otworzyć strony”, nie jest dobrym rozwiązaniem. Przy URL albo Domain hits należy dodatkowo sprawdzić, czy uczestniczy TLS Inspection, Web Policy, DNS Protection albo inna funkcja security.

Lista kontrolna operacji

• Udokumentowano feed name, dostawcę, plan i ownera.
• Indicator type jest jednoznacznie ustawiony per feed.
• Akcja Monitor albo Block została wybrana świadomie.
• Polling interval pasuje do feedu.
• Certificate check i authentication zostały przetestowane.
• Sprawdzono synchronization status i Storage Quota.
• Active-Threat-Response-Logs są widoczne.
• Zdefiniowano proces False Positive z review date.
• Scenariusze DNAT, WAF i VPN oceniono według wersji SFOS.
• Zaplanowano alerts albo reports dla powtarzających się trafień.

FAQ