Zbieraj telemetrię sieciową przez Sophos XDR Collector

Dla OPNsense, pfSense, Netskope SSE i NetScaler ADC udokumentowana ścieżka używa Sophos XDR Data Collector. Najpierw wdraża się kolektor, następnie podłącza źródło we właściwym formacie syslog i sprawdza faktyczne dane. Sam ogólny adres syslog nie wystarcza: Sophos musi poprawnie rozpoznawać format i kategorię zdarzeń.

Opisane dane netflow wymagają subskrypcji Sophos Next-Gen SIEM. Netskope i NetScaler dostarczają także inne schematy, które nie wszystkie mają tę samą uwagę licencyjną w dokumentacji. Dla OPNsense i pfSense sprawdzony zakres obejmuje zdarzenia połączeń firewall w netflow. SIEM i podstawy integracji wyjaśniają wybór i licencje.

Przygotować kolektor i zakres źródeł

Kolektor musi być wdrożony dla właściwego tenantu pod Security Operations > Integrations > Data Collectors. Runbook kolektora omawia zasoby, regionalne uplinki, DNS, czas i różnice wobec starej SVA oraz NDR. Nowy XDR Data Collector nie przejmuje automatycznie istniejącego zadania NDR.

Przed zmianą zapisać dotychczasową trasę logów, nowy cel, dozwolone sieci źródłowe i zdarzenia. Dopuścić syslog tylko z tych sieci. Nie zastępować udokumentowanej trasy UDP przez TLS-syslog lub inny format bez sprawdzenia zgodności. UDP nie potwierdza dostarczenia każdego komunikatu; uwzględnić straty w porównaniu źródła i celu.

Dla pilota wybrać zatwierdzone, nieszkodliwe zdarzenie z czasem i dowodem źródłowym. Skonfigurowany receiver lub zielony stan nie dowodzi odbioru wszystkich kategorii ani normalizacji. Komunikację, przepływ i treść odbiera się osobno.

OPNsense: filterlog przez UDP/514

Ścieżka OPNsense przetwarza filterlog dla dozwolonych lub blokowanych połączeń TCP, UDP i ICMP. Wymaga dostępu administracyjnego OPNsense i osiągalnego kolektora.

1. Po wdrożeniu kolektora otworzyć konfigurację Remote Logging w OPNsense. Nawigacja zależy od wersji; poniższe wartości dokumentuje Sophos.
2. Włączyć Enabled i ustawić Transport na UDP(4).
3. W Applications wybrać filter (filterlog). W Levels zaznaczyć info, notice, warn, error, critical, alert i emergency. Facilities zostawić puste.
4. W Hostname wpisać rzeczywiste IP kolektora, a w Port 514. Wyłączyć rfc5424. Udokumentowana Description to FilterLog; nie mylić nazwy z innym formatem.
5. Zapisać i wygenerować przewidziane nieszkodliwe zdarzenie firewall. Reguła źródłowa musi je faktycznie logować. Najpierw potwierdzić czas, adresy i akcję w OPNsense, potem porównać je w Sophos netflow.

Jeśli brakuje rekordu, sprawdzić logowanie źródła, wybór filterlog, UDP/IPv4, IP, port i RFC5424. Nie wyłączać ochrony, aby wymusić testowy flow.

pfSense: Firewall Events w formacie BSD

pfSense dostarcza również filter logi TCP, UDP i ICMP. Udokumentowany format różni się od innych logów pfSense; dowolny wybór remote syslog nie jest zamiennikiem.

1. Otworzyć Log Settings w administracji pfSense.
2. Pod General Logging Options wybrać BSD (RFC 3164, default).
3. W Remote Logging Options włączyć Enable Remote Logging.
4. W Source Address wybrać interfejs lub sieć osiągającą kolektor. IP Protocol ustawić na IPv4.
5. W Remote log servers wpisać rzeczywiste IP, a w Remote Syslog Contents wybrać Firewall Events.
6. Zapisać, wygenerować zatwierdzone i faktycznie zapisane zdarzenie, a potem odnaleźć je w netflow właściwego tenantu. Akcja i połączenie muszą odpowiadać źródłu.

Inny Source Address może zmienić routing i dopasowanie firewall. Przy braku danych sprawdzić najpierw trasę wyjściową interfejsu, potem receiver i BSD. Procedura nie obejmuje automatycznie innych kategorii logów.

Netskope SSE: Cloud Log Shipper i CEF

Ścieżka ma dwa etapy: Netskope Cloud Log Shipper pobiera dane z API Netskope i przesyła CEF przez syslog do kolektora. Konto Netskope wpisane bezpośrednio w kolektorze nie zastępuje Shippera.

Integracja może dostarczać aktywność web/cloud, malware, alerty bezpieczeństwa/policy i działania administracyjne, m.in. jako http, antivirus, thirdpartyalert, nids i auth. Dodatkowe zdarzenia połączeń/tuneli netflow wymagają SIEM.

1. Wdrożyć zatwierdzony Cloud Log Shipper dla tenantu Netskope. Skonfigurować API i kategorie według odpowiedniej procedury Netskope. Sophos nie podaje uniwersalnego zestawu uprawnień API.
2. Wybrać wyjściowy Plugin: Syslog.
3. W Mapping użyć Syslog Defaults Mapping. Zachować udokumentowaną ścieżkę CEF; własne mapowanie może zmienić normalizację.
4. Ustawić rzeczywiste IP XDR Data Collector jako cel. Transport i receiver muszą odpowiadać zatwierdzonej konfiguracji. Wymóg UDP/514 innych produktów nie określa uniwersalnego portu Netskope.
5. Wybrać właściwe zdarzenie i sprawdzić jego pobranie z API oraz przekazanie przez Shipper. Następnie porównać schemat i wymagane pola w Sophos.

Jeżeli brakuje tylko połączeń, sprawdzić też dobór kategorii i licencję SIEM. Rekord HTTP nie dowodzi zebrania wszystkich kategorii. Problemy pobierania API i przesyłania syslog bada się osobno.

NetScaler ADC: audyt z jednoznacznym czasem

NetScaler ADC, dawniej Citrix ADC, przekazuje syslog web/Application Firewall (http), uwierzytelnianie/sesje VPN (auth) i komendy administracyjne (managementevent). Otwarcie i zamknięcie TCP mapuje do netflow i wymaga SIEM.

1. Po wdrożeniu kolektora otworzyć konfigurację syslog Audit Logging w NetScaler. Dopasować serwer/policy do wersji i zakresu; źródło Sophos nie dokumentuje uniwersalnej komendy CLI.
2. Ustawić IP właściwego kolektora jako cel i sprawdzić zatwierdzoną trasę sieciową.
3. Ustawić datę MM/DD/YYYY. DD/MM/YYYY nie jest obsługiwany do prawidłowego odbioru.
4. Wysyłać czas zdarzeń w UTC. Zmiana późniejszego wyświetlania Sophos nie naprawia źle zinterpretowanego czasu źródłowego.
5. Wykonać zatwierdzoną zmianę administracyjną lub logowanie w zakresie audytu. Porównać dowód, czas, użytkownika i akcję ze schematem Sophos. Netflow wymaga osobnego testu połączenia.

Gdy zdarzenie pozornie zniknęło, najpierw porównać czas źródłowy i okno wyszukiwania. Błędna data lub strefa może umieścić rekord poza zakresem. Następnie sprawdzić audit policy, faktycznie wysłaną kategorię, IP i sieć.

Odbiór i kontrolowane wycofanie

Dla każdego źródła zapisać co najmniej jedno powtarzalne zdarzenie, źródło, tenant, czas odbioru i schemat. Adresy, porty, akcję i użytkownika porównywać, gdy są oczekiwane i obecne. Brak detection lub case nie musi oznaczać braku danych; decyduje rzeczywisty rekord.

Powtórzyć odbiór po zmianie źródła lub formatu. Poprawnie przetworzony wczoraj CEF nie dowodzi poprawności dzisiejszego mapowania. Przy rozbieżnościach czasu sprawdzić zegar źródłowy zamiast wyłączać ochronę.

Aby wycofać zmianę, zatrzymać nowy wpis Remote Logging lub dedykowane wyjście Shippera i sprawdzić poprzednią trasę. Zachować wspólne kolektory, tożsamości API i pozostałe wyjścia. Zasoby wyłącznie dedykowane usunąć po analizie zależności. Usunięcie integracji nie dowodzi usunięcia historii i nie przywraca utraconych zdarzeń.