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. Local reporting przechowuje lokalnie logi zdarzeń dla Log Viewer; logi te nie są raportami generowanymi na urządzeniu. Alternatywnie jako miejsce docelowe logów można użyć Sophos Fusion (dawniej 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 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 własnego dostawcy. URL musi zwracać plik tekstowy bezpośrednio. Jeśli endpoint odpowie zamiast tego 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 zgodnie z wymaganiami dostawcy. Przy API key nazwę nagłówka lub parametru wskazaną przez dostawcę i tajną wartość wprowadza się osobno; następnie jako miejsce przesyłania wybiera się Header albo Query parameters. Jeśli dostawca wymaga na przykład nagłówka X-API-Key, jest to nazwa, a nie tajny klucz. Przy Basic authentication należy wprowadzić nazwę użytkownika i hasło. Wartość API key oraz hasło 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 wolną Storage quota. Success potwierdza udane połączenie lub żądanie HTTP GET, ale nie potwierdza ani pełnego przetworzenia listy, ani tego, że oczekiwany ruch jest rzeczywiście wykrywany lub blokowany. Zawartość i działanie trzeba zweryfikować osobno.

Wybór właściwego feedu i akcji

Obsługiwane wskaźniki

Każda konfiguracja feedu przetwarza dokładnie jeden z następujących typów wskaźnikó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. Jeśli plik dostawcy zawiera kilka typów, SFOS uwzględnia tylko wybrany Indicator type. Dla każdego potrzebnego typu należy więc utworzyć osobną konfigurację; pliku mieszanego nie trzeba dzielić wyłącznie z powodu połączenia w nim różnych typów. 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.

Przykład formatu zawierającego wyłącznie adresy IPv4 wygląda następująco:

192.0.2.10
198.51.100.20

Te adresy dokumentacyjne pokazują jedynie format, a nie rzeczywiste zagrożenia ani dostępne cele testowe. W kontrolowanym teście opisanym poniżej używa się zamiast nich pojedynczego adresu IPv4 własnego celu testowego, a nie jego sieci z sufiksem CIDR. W przypadku Cybora korzysta się bezpośrednio z udostępnionych plików feedów.

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 we własnym środowisku, zajmuje jedynie miejsce. Integracja nie ogranicza się do stałej listy dostawców do wyboru: można podłączyć każdy Third-Party Feed, który spełnia opisane wymagania dotyczące pliku. Sophos wymienia na przykład GreyNoise Intelligence, CrowdSec i Q-Feeds jako dostawców; samo wymienienie tych nazw nie zastępuje ani sprawdzenia konkretnego endpointu, ani własnego pilotażu w trybie Monitor.

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 uczenia maszynowego. Przegląd licencjonowania modułów wymienia Xstream Appliance Bundle, a instrukcja konfiguracji — Xstream Protection Bundle. Przed zakupem lub wdrożeniem skorzystaj ze szczegółowego porównania licencji i źródeł dla NDR Essentials i uzyskaj wiążące potwierdzenie uprawnień licencyjnych dla swojej zapory.
• 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 i adresów URL 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.

Za sprawdzanie odpowiada przy tym moduł Web w przypadku Web Proxy albo IPS w przypadku DPI Engine z regułami inspekcji SSL/TLS. Dotyczy to zarówno zaszyfrowanego, jak i odszyfrowanego ruchu HTTPS; to, które IoC można wykryć, nadal zależy od tego, czy widoczna jest tylko domena, czy również ścieżka 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

Sync status: Success potwierdza udane połączenie lub żądanie HTTP GET do External URL, a nie kompletność czy pomyślne przetworzenie wszystkich oczekiwanych wskaźników. Test connection również sprawdza tylko połączenie. 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 jako liczbę aktywnych i wszystkich skonfigurowanych feedów, Total threat indicators jako liczbę wskaźników IPv4, domen i URL oraz Storage quota jako zajętą przestrzeń w ramach limitu zależnego od modelu. Większe urządzenia mają więcej miejsca niż modele desktopowe. Refresh aktualizuje tylko te wyświetlane liczniki. Synchronize now w sekcji Manage natomiast natychmiast pobiera wybrany feed. Poszczególne IoC można otwierać i wyszukiwać przez Threat indicators lub przez liczbę w Total indicators odpowiedniego feedu. Fetching oznacza, że trwa pobieranie; Disabled oznacza, że feed jest wyłączony.

Przy Authentication error należy najpierw sprawdzić nazwę API key, tajną wartość i miejsce przesyłania albo nazwę użytkownika i hasło. Jeśli te dane są prawidłowe, należy również sprawdzić, czy nie doszło do nieudanego uzgadniania TLS: skontrolować certyfikat i łańcuch zaufania serwera feedu, a w razie potrzeby wyjaśnić problem z dostawcą. Nie każdy błąd uwierzytelniania jest błędem TLS. Validate server certificate pozostaje włączone; brak zaufania do CA rozwiązuje się przez dodanie prawidłowego certyfikatu CA, a nie przez wyłączenie weryfikacji.

Przy Connection error należy sprawdzić DNS, dostęp do Internetu, serwer feedu i status HTTP; możliwymi przyczynami są również 404, 500 i 302. SSL/TLS error jest osobnym statusem wskazującym problemy z certyfikatem. Przy Failed należy sprawdzić, czy faktycznie dostarczony plik jest zwykłym plikiem tekstowym, zawiera jeden wskaźnik w każdym wierszu i odpowiednie obsługiwane typy; możliwe są również inne błędy. Po usunięciu problemu należy ponownie uruchomić Test connection i Synchronize now, sprawdzić znacznik czasu i oczekiwany IoC, a dopiero potem powtórzyć kontrolowany test ruchu. Jeśli błąd nadal występuje, należy zapisać status, czas i informacje o feedzie oczyszczone z tajnych danych dla dostawcy lub pomocy technicznej.

Storage full oznacza, że nie ma wystarczająco dużo miejsca na pełną listę. Firewall nadal pobiera feed zgodnie ze skonfigurowanym interwałem odpytywania, 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 i adresów URL 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ść. Najpierw potwierdzić, że pobieranie i ścieżka sprawdzania działają, oraz sprawdzić, czy MDR, NDR lub X-Ops już wykrywają te same IoC. Krótki test bez trafień nie jest powodem do usunięcia feedu. Jeśli po tej weryfikacji feed rzeczywiście okaże się zbędny, przed usunięciem należy udokumentować nazwę, URL, typ wskaźnika, akcję, pozycję, interwał odpytywania oraz bezpieczne miejsce przechowywania danych uwierzytelniających. W Protect > Active threat response > Third-party threat feeds usunąć sprawdzony feed, aby zwolnić miejsce. Następnie sprawdzić Refresh, Storage quota i Active feeds oraz ponownie pobrać przez Synchronize now feed, którego wcześniejsze pobranie nie powiodło się z powodu Storage full. Aby przywrócić usunięty feed, tworzy się go ponownie z udokumentowanymi wartościami, początkowo w trybie Monitor. Tymczasowe wyłączenie na potrzeby rollbacku pozostaje odrębnym działaniem; nie traktuje się go jako potwierdzenia zwolnienia miejsca.

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. W sekcji Host and network exclusions > Add new item należy wybrać istniejące obiekty hostów lub sieci. W sekcji Threat exclusions wprowadza się 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.

Automatyzacja ThirdPartyFeed przez XML

Do automatyzacji tej samej konfiguracji źródła danych interfejs XML używa obiektu ThirdPartyFeed. Konfiguruje on pobieranie i akcję, a nie poszczególne pobrane wskaźniki IoC. Dostęp, jawna operacja zapisu, zależna od wersji struktura żądania i bezpieczna interpretacja odpowiedzi zostały wyjaśnione w sekcji Zabezpieczanie dostępu do API XML. Poniższe nazwy pól i limity dotyczą SFOS 22 i 23; nie są kompletnym żądaniem zapisu. Przed użyciem należy potwierdzić konkretną operację Add/Edit i jej payload w API help zainstalowanej kompilacji. W przypadku niejasnej składni lub sprzeczności między źródłami nie należy wykonywać zapisu, lecz wyjaśnić sprawę z pomocą techniczną.

Przed zmianą należy zidentyfikować istniejące źródło danych w WebAdmin na podstawie jego Name i zachować nazwę, typ wskaźnika, URL, akcję, stan aktywacji, pozycję i interwał odpytywania. Nazwa określa konfigurację źródła danych, a nie dostawcę ani pojedynczy IoC. Ten sam dostawca może mieć kilka odrębnie nazwanych konfiguracji dla IPv4, domen i adresów URL. Na podstawie nazwy obiektu nie należy wywodzić niezweryfikowanej semantyki zmiany nazwy, upsert ani nadpisywania.

• Tożsamość i źródło: Name jest wymagane, dopuszcza najwyżej 63 znaki i wyłącznie litery, cyfry, podkreślenia oraz łączniki. Description jest opcjonalne i ograniczone do 255 znaków. ExternalURL jest wymagane i ograniczone do 1024 znaków; nadal należy używać bezpośrednio dostępnego przez HTTPS źródła danych w formacie zwykłego tekstu, z jednym wskaźnikiem w każdym wierszu.
• Akcja i kolejność: Action wymaga dokładnie block lub monitor, co odpowiada odpowiednio Block lub Monitor w interfejsie użytkownika. monitor rejestruje trafienia bez blokowania na podstawie źródła danych; block rejestruje i blokuje. Nazwy Log only i Log and drop z innych modułów nie są wartościami zastępczymi dla tego pola. Position dopuszcza top lub bottom, co odpowiada Top lub Bottom. W ten sposób wybiera się pozycję w obrębie Third-Party Feeds, a nie ich pierwszeństwo przed MDR, NDR Essentials czy Sophos X-Ops. Listy Block i Monitor pozostają rozdzielone; decydujące jest pierwsze trafienie na każdej liście.
• Typ wskaźnika: IndicatorType wymaga ip, domain lub url, co odpowiada IPv4 address, Domain lub URL. ip nie jest tutaj typem IPv6, sieci ani zakresu. Dla każdego wymaganego typu wskaźnika należy utworzyć osobną konfigurację.
• Uwierzytelnianie: Authorization wymaga noAuthentication, basicAuthentication lub apiKey. Tylko w przypadku Basic Authentication stosuje się Username i Password, każde o długości najwyżej 64 znaków. Tylko w przypadku uwierzytelniania kluczem API stosuje się Key, Value i AddTo: nazwa klucza i tajna wartość są oddzielne i każda z nich jest ograniczona do 64 znaków; miejsce przekazania to dokładnie header lub queryParam, co odpowiada Header lub Query parameters. Decydują wymagania dostawcy, a nie zakładana wartość domyślna. Należy używać wyłącznie pól właściwych dla danej metody; sekrety pobierać z chronionego magazynu sekretów i nie umieszczać ich w plikach XML w repozytorium, adresach URL w zgłoszeniach, historii powłoki, zrzutach ekranu ani logach. Przy parametrach zapytania należy szczególnie zadbać o maskowanie rejestrowanych adresów URL źródła danych.
• Weryfikacja certyfikatu: ValidateServerCertificate jest wymagane; przykład obiektu pokazuje true i false. Aby zapewnić bezpieczne działanie, należy jawnie włączyć weryfikację i wcześniej skonfigurować odpowiednie zaufanie do CA. Błąd TLS lub uwierzytelniania nie uzasadnia wyłączenia weryfikacji.
• Interwał pobierania: PollingInterval jest wymagane i dopuszcza wyłącznie 5m, 15m, 30m, 1h, 6h, 24h, 7d lub 30d. Są to stałe tokeny, a nie dowolnie wybierana liczba minut. Na XGS 87/87w, 88/88w i 107/107w wybór pozostaje ograniczony do 24h, 7d i 30d. Na przykład 1h odpowiada aktualizacji dostawcy co godzinę tylko na modelu obsługującym ten interwał.
• Aktywacja i wartości domyślne: Dla Enabled tabela parametrów podaje 1 i 0, natomiast przykład obiektu — true i false. Jest to nierozstrzygnięta różnica w sposobie przedstawienia, a nie dowód zamienności tych zapisów. Przed próbą zapisu należy ustalić prawidłową formę w zainstalowanej kompilacji. Tabela podaje ponadto monitor, top, ip i noAuthentication jako wartości domyślne odpowiednich pól; informacje te nie są przetestowanymi gwarancjami zachowania w czasie działania. Należy świadomie określić akcję, pozycję, typ i uwierzytelnianie, zamiast polegać na pominiętych wartościach.

Bezpieczna interpretacja odpowiedzi Add/Edit

Dla Add Third-party threat feed i Edit Third-party threat feed udokumentowano następujące powiązania. Wartości Message.* są nierozstrzygniętymi symbolami komunikatów, a nie dosłownymi tekstami błędów ani samodzielną instrukcją działania:

W szczególności 409 / Message.CPResourceConflict dotyczą Add, a 404 / Message.CPRecordNotFound dotyczą Edit. Tych powiązań specyficznych dla obiektu nie należy utożsamiać z ogólnymi kodami XML ani ze statusem transportu HTTP; decydujące są rzeczywista odpowiedź i Status Message Information w danej kompilacji. Po każdej zmianie należy porównać zapisane źródło danych w WebAdmin z wartościami docelowymi i sprawdzić Audit Trail. W przypadku błędu, przekroczenia limitu czasu lub niejasnej odpowiedzi należy najpierw sprawdzić faktycznie zapisany stan, zanim operacja Add lub Edit zostanie wysłana ponownie. Na podstawie symbolu nie należy wywodzić automatycznego ponowienia, zmiany nazwy ani domniemanego sposobu naprawy błędu.

Odpowiednia odpowiedź dotycząca konfiguracji nie dowodzi ani pobrania źródła danych, ani zawartości IoC, ani wpływu na ruch. Następnie nadal należy sprawdzić Test connection, Synchronize now, Last updated, Storage quota, oczekiwany IoC oraz przeprowadzić kontrolowany test ruchu w trybie Monitor. Dopiero po tej weryfikacji należy przełączyć na Block; w przypadku nieoczekiwanych zakłóceń należy przywrócić zachowaną akcję lub w kontrolowany sposób wyłączyć źródło danych zgodnie z powyższym opisem, a nie stosować globalnego Threat Exclusion jako rozwiązania zastępczego.

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.