Przejdz do tresci
Avanet

Bezpieczne wysyłanie Syslog z Sophos Firewall do SIEM

Sophos Firewall

Za pomocą Syslog Sophos Firewall wysyła zdarzenia do zewnętrznego serwera logów, systemu SIEM lub SOC. Aby integracja była rzeczywiście użyteczna, muszą ze sobą współgrać cztery elementy: transport, wybór logów, format i parser. Dlatego ten artykuł zaczyna się bezpośrednio od konfiguracji, a następnie pokazuje, jak wykrywać brakujące lub błędnie interpretowane logi.

Lokalny Log viewer pozostaje ważny do analizy na żywo. Central Firewall Reporting sprawdza się w raportach Sophos Fusion (dawniej Sophos Central); Syslog jest właściwym wyborem do własnej retencji, korelacji danych różnych producentów i detekcji w SIEM.

Konfiguracja serwera Syslog

Najpierw należy ustalić docelowy adres IP lub FQDN, port, oczekiwany format logów i odpowiedni parser. Firewall musi mieć trasę do collectora, a oba systemy działające źródło czasu. SFOS standardowo używa dla Syslog protokołu UDP na porcie 514. Ten formularz nie udostępnia osobnego wyboru transportu: opcja Secure log transmission włącza lub wyłącza transmisję szyfrowaną za pomocą TLS. W oficjalnym przykładzie TLS dla syslog-ng Sophos używa portu 6514; port i nasłuch muszą zawsze odpowiadać konfiguracji własnego collectora.

  1. Otwórz System services > Log settings.
  2. Wybierz Add.
  3. Nadaj jednoznaczną nazwę, na przykład siem-primary.
  4. W polu IP address/domain wpisz collector.
  5. Ustaw Port, Facility, Severity level i Format zgodnie z systemem docelowym.
  6. Dla przygotowanego collectora TLS włącz Secure log transmission.
  7. Zapisz.
  8. W sekcji Log settings włącz żądane typy logów w kolumnie tego serwera Syslog.

SFOS obsługuje do pięciu zewnętrznych serwerów Syslog. Wiele miejsc docelowych ma sens, gdy pełnią różne funkcje, na przykład lokalnego archiwum i collectora MDR. Natomiast bezrefleksyjne wysyłanie wszystkich logów do każdego celu zwiększa wolumen, koszty i ryzyko związane z ochroną danych.

Facility, Severity i Format

  • Facility: Dostępne opcje obejmują DAEMON, KERNEL, USER oraz wartości od LOCAL0 do LOCAL7. Na przykład LOCAL1 i LOCAL2 mogą rozróżniać dwa firewalle. Przypisanie musi być spójne w collectorze i dokumentacji operacyjnej.
  • Severity level: Wybrana wartość jest minimalnym poziomem ważności. Error wysyła również Critical, Alert i Emergency, ale nie zdarzenia Information ani Notice. Debug obejmuje wszystkie poziomy. Ustawienie zbyt wysokiego minimum może ukryć logowania i zwykłe zdarzenia operacyjne.
  • Format: Dostępne są Standard syslog protocol oraz Device standard format (legacy). Decydujące jest to, jakiego formatu oczekuje parser SIEM. Późniejsza zmiana może uszkodzić wyszukiwania, dashboardy i reguły detekcji.

Secure log transmission

W środowisku produkcyjnym TLS jest wskazany dla połączeń przez niezaufane lub współdzielone sieci, ponieważ logi mogą zawierać wewnętrzne adresy, nazwy użytkowników, adresy URL i zdarzenia bezpieczeństwa. Samo zaznaczenie opcji nie wystarcza: collector musi przyjmować TLS na wybranym porcie, a obie strony muszą mieć możliwość weryfikacji certyfikatów.

Dla udokumentowanego przez Sophos bezpiecznego połączenia Syslog obowiązują następujące zasady:

  1. Certyfikat serwera collectora i jego łańcuch certyfikatów muszą być zaufane dla firewalla.
  2. Skonfigurowany FQDN musi pasować do certyfikatu. Bez LINCE SFOS sprawdza Common Name; z LINCE może pasować Common Name lub Subject Alternative Name.
  3. W sekcji Certificates > Certificate authorities pobiera się CA Sophos Default. Collector musi ufać wyodrębnionemu z niej Default.pem, ponieważ Sophos używa tego CA po swojej stronie połączenia.
  4. Dopiero wtedy należy włączyć Secure log transmission z przygotowanym portem TLS.

W oficjalnym przykładzie syslog-ng pliki Default.pem i zewnętrzny CA znajdują się w katalogu CA collectora; peer_verify(required-trusted) wymusza weryfikację certyfikatu. Inne produkty collectorskie mają do tego własne magazyny zaufania. FQDN występujący wyłącznie w SAN nie działa bez LINCE, a wpisany adres IP nie pasuje do certyfikatu zawierającego wyłącznie nazwę DNS.

Przed włączeniem LINCE w tym celu należy sprawdzić granicę certyfikacji, dozwolone algorytmy i restart SSH w trybie LINCE. Tryb nie jest tylko przełącznikiem syslog i nie wolno go włączać bez niezależnego dostępu administracyjnego.

Jeśli chmurowy SIEM nie obsługuje tego mechanizmu bezpośrednio, firewall może wysyłać dane wewnętrznie do lokalnego collectora, który przekazuje je dalej w sposób szyfrowany. Nieszyfrowany odcinek powinien być krótki, segmentowany i udokumentowany.

Określanie typów logów i widoczności

Cel aktywuje się dwuetapowo:

  1. Dana reguła lub funkcja musi wygenerować zdarzenie. W regułach firewall wymaga to opcji Log firewall traffic, a w regułach SSL/TLS Inspection opcji Log connections.
  2. W sekcji System services > Log settings odpowiedni typ logów musi być zaznaczony w kolumnie serwera Syslog.

Jeśli brakuje jednego z tych etapów, collector nie otrzyma zdarzenia. Na potrzeby pilota wystarczy niewielki, świadomie dobrany zestaw:

  • Firewall i Events: zdarzenia reguł, aktywność administratorów i użytkowników oraz zdarzenia uwierzytelniania, VPN, DHCP i DNS.
  • IPS, Content filtering, Web server protection i Zero-day protection: decyzje dotyczące bezpieczeństwa i polityk.
  • Active threat response: trafienia MDR, NDR Essentials, Sophos X-Ops oraz Third-Party Threat Feeds.
  • System health, Wireless, Heartbeat i SD-WAN: dodatkowe informacje o stanie operacyjnym, jeśli te moduły są używane.

Kolejne moduły należy dodawać dopiero wtedy, gdy istnieje cel wyszukiwania, alarmowania lub audytu. Przy analizie zdarzeń DoS warto również sprawdzić konfigurację Spoof i DoS. W przypadku Third-Party Threat Feeds oraz NDR i Active Threat Response oprócz transportu logów potrzebne są konkretne zapytania wyszukujące i alarmy.

Zakres ATR: Włączać rejestrowanie źródeł zdalnych tylko dla kombinacji modułu i ścieżki ruchu, których obsługa jest potwierdzona. Tekst ATR firmy Sophos i macierz ruchu w formacie SVG są sprzeczne w kwestii kierunków dopasowania X-Ops; konflikt pozostaje nierozstrzygnięty. Informacje o MDR, NDR lub feedach innych dostawców nie potwierdzają równoważnej obsługi w X-Ops. Zachować restrykcyjne reguły zapory, DNAT/WAF i Device Access niezależnie od spornego działania feedu. Sporne przypadki wymagają autoryzowanej, kontrolowanej weryfikacji modułu, kierunku dopasowania, logów i rzeczywistego efektu oraz wiarygodnego wyjaśnienia; do tego czasu ochrona nie może zależeć od tego działania. Bezpieczny kontekst opisuje NDR i Active Threat Response.

Częste pułapki dotyczące widoczności

  • Log Suppression: SFOS może łączyć identyczne, następujące po sobie zdarzenia firewalla. Dotyczy to Log Viewer, Sophos Fusion i Syslog. Parsery oraz mechanizmy detekcji muszą więc uwzględniać także log_occurrence.
  • Active Threat Response: Remote Source Match dla przychodzącego ruchu DNAT lub WAF nie jest domyślnie aktywny. Bez tego wyboru brakuje odpowiednich trafień źródłowych dla obsługiwanych modułów i ścieżek ruchu. Podczas badania brakujących typów dopasowania również przestrzegać zakresu ATR opisanego powyżej; zaznaczenie opcji nie potwierdza obsługi spornych kierunków X-Ops.
  • Wireless: Logi punktów dostępowych i SSID nie są dostępne w lokalnym Log Viewer. Należy je celowo wysyłać do Sophos Fusion lub Syslog i tam weryfikować.
  • Content filtering i SSL/TLS: Wybrany typ logów nie zastępuje logowania w odpowiedniej regule firewalla lub Inspection Rule.
  • Web Proxy: W przypadku ruchu WWW na portach 80 lub 443 log Firewall może wskazywać Allowed, podczas gdy Web Filter blokuje to samo żądanie. Aby ustalić rzeczywistą decyzję polityki, należy skorelować zdarzenia Firewall i Web Filter.

Sprawdzanie formatu i parsera

Test parsera nie może jedynie potwierdzać, że dociera jakikolwiek tekst. Kluczowe wartości muszą być dostępne jako osobne pola wyszukiwania. Poniższy skrócony, zanonimizowany przykład odpowiada formatowi Standard syslog protocol dla zdarzenia reguły firewalla:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Format legacy wykorzystuje natomiast między innymi device, date, time, timezone, device_id i priority. Pola takie jak status, user_name, nat_rule_id lub log_occurrence zależą dodatkowo od typu logu i zdarzenia. Nie wolno traktować ich jako obowiązkowych dla każdego zdarzenia w formacie standardowym. Podczas pierwszego odbioru skonfiguruj parser tylko z poniższymi polami podstawowymi; dodatkowe pola specyficzne dla typu logu ustawiaj jako wymagane dopiero po potwierdzeniu ich w rzeczywistym zdarzeniu testowym.

W zależności od przypadku użycia podczas odbioru szczególnie ważne są:

  • Tożsamość: device_name, device_model, device_serial_id
  • Klasyfikacja: log_id, log_type, log_component, log_subtype, severity
  • Polityka: fw_rule_id, fw_rule_name, nat_rule_id
  • Połączenie: src_ip, dst_ip, porty, protokół i użytkownik
  • Czas i częstotliwość: timestamp, strefa czasowa i log_occurrence

log_id zawiera typ logu, komponent, podtyp, Severity i Message ID. Dzięki temu reguły detekcji są stabilniejsze niż zwykłe wyszukiwanie pełnotekstowe. Mimo to pola udostępniane przez konkretny moduł trzeba sprawdzić na podstawie rzeczywistego zdarzenia tego typu.

Dwanaście znaków ma stałe pozycje: znaki 1 i 2 tworzą Log Type ID, 3 i 4 Component ID, 5 i 6 Subtype ID, znak 7 Priority ID, a znaki od 8 do 12 Message ID. Wartość 010101600001 odczytuje się zatem jako 01 / 01 / 01 / 6 / 00001. Parser musi zachować zera wiodące i stałą szerokość pól; dodatkowo należy sprawdzać log_type, log_component, log_subtype i severity.

Moduł Syslog Events nie jest tym samym co configuration-audit.log. Wartości przed zmianą i po niej są tam dostępne tylko dla obsługiwanych kluczowych obiektów, takich jak reguły firewalla, interfejsy i hosty IP, a nie dla każdej zmiany konfiguracji. Zakres i analizę opisano w artykule o logach Audit Trail.

Wiele firewalli i HA

W środowisku z wieloma urządzeniami każde zdarzenie musi być jednoznacznie przypisane do firewalla, lokalizacji, klienta i klastra HA. Dlatego należy udokumentować nazwę hosta, numer seryjny, model oraz Facility i umożliwić ich filtrowanie w SIEM. Od wersji SFOS 22.0 pole device_name identyfikuje nazwę hosta firewalla, który wygenerował log. Po aktualizacji należy sprawdzić, czy parser przetwarza to pole, zamiast nadal używać wyłącznie device_serial_id lub nagłówka Syslog jako klucza zasobu.

Po przełączeniu awaryjnym HA, odtworzeniu lub wymianie sprzętu trzeba sprawdzić, czy zdarzenia nadal są przypisane do istniejącego zasobu, czy pojawiają się jako nowy lub zduplikowany system. To samo dotyczy zmiany nazwy hosta lub formatu Syslog.

Testowanie integracji przy użyciu rzeczywistych zdarzeń

Zielony status collectora nie potwierdza ani prawidłowego wyboru logów, ani działania parsera. Procedura odbioru:

  1. Udokumentuj pilotażowy firewall i stan początkowy: nazwę serwera, cel, port, TLS, Facility, Severity, Format oraz wszystkie typy logów włączone w kolumnie tego serwera.
  2. Najpierw wysyłaj do celu Firewall i Events.
  3. Wywołaj regułę testową z włączonym logowaniem oraz zdefiniowanymi Source, Destination i Service.
  4. W SIEM sprawdź urządzenie, czas, typ logu, akcję, Rule ID, Source i Destination.
  5. Wygeneruj zdefiniowany Drop oraz zalogowanie i wylogowanie VPN.
  6. Przetestuj co najmniej jedno zdarzenie bezpieczeństwa z IPS, Content filtering lub Active threat response, jeśli dany moduł jest używany produkcyjnie.
  7. Następnie stopniowo włączaj kolejne typy logów i obserwuj wolumen oraz wynik parsera.

Podczas testowania reguł pomaga instrukcja dotycząca Log Viewer, Policy Test i Packet Capture. Ważny jest również test negatywny: oczekiwane połączenie zostaje celowo zablokowane i musi pojawić się jako Drop z właściwą regułą.

W projektach HA lub migracji odbiór powinien obejmować test przełączenia awaryjnego, odtworzenia lub wymiany sprzętu. SOC musi potem nadal rozpoznawać, które urządzenie i która lokalizacja wygenerowały zdarzenie.

Wycofanie zmiany bez przerwy w danych

Nie należy jednocześnie zmieniać formatu, minimalnego poziomu ważności i wyboru logów. Jeśli jedno z pięciu miejsc na serwery jest wolne, na potrzeby migracji parsera lub collectora należy dodać drugi cel i początkowo korzystać z obu równolegle. Pozwala to porównać dane surowe, wypełnione pola, znaczniki czasu i wolumen bez ingerowania w działający cel.

Dopiero po zakończeniu odbioru należy wyłączyć typy logów w kolumnie starego celu. Wpis serwera trzeba zachować przez uzgodniony okres obserwacji. Jeśli brakuje zdarzeń, parsowanie nie działa lub wolumen jest nieoczekiwany, należy ponownie włączyć tam dokładnie wcześniej udokumentowane typy logów i wycofać ich wybór dla nowego celu. Jeśli nie ma wolnego miejsca na serwer, przed każdą pojedynczą zmianą trzeba zapisać bieżące wartości i w razie niepowodzenia przywrócić je w całości; nie należy jednocześnie usuwać wpisu ani zmieniać parsera.

Eksploatacja, retencja i awarie

Integracja Syslog wymaga właściciela, zdefiniowanej retencji i reakcji na alarmy. Trzeba też ustalić, kto ocenia fałszywe alarmy i dostosowuje reguły detekcji. Logi firewalla mogą zawierać dane osobowe, wewnętrzne adresy, nazwy użytkowników, adresy URL i aktywność VPN. Dlatego przed szerokim wdrożeniem należy określić uprawnienia dostępu, terminy usuwania, rozdzielenie tenantów i koszty SIEM.

Monitoring musi wykrywać nie tylko ataki, lecz także brak danych:

  • monitoruj oczekiwaną minimalną aktywność każdego firewalla;
  • osobno sprawdzaj aktualność ważnych typów logów, takich jak Firewall, Events, IPS lub Active threat response;
  • monitoruj puste lub nagle zmienione wartości kluczowych pól parsera;
  • alarmuj o wygasaniu certyfikatów i stanie collectora;
  • po aktualizacjach firmware, parsera i certyfikatów ponownie generuj zdarzenia testowe.

Sam monitoring również trzeba przetestować: jeśli oczekiwany typ logu lub firewall celowo przestanie wysyłać dane, zdefiniowany alarm braku danych musi się uruchomić.

Surowe dane bez sparsowanych pól również oznaczają awarię. Aktualizacja parsera może pozostawić transport sprawny, podczas gdy dashboardy i reguły detekcji przestają znajdować trafienia.

Syslog nie zastępuje ani lokalnych logów usług, ani archiwum diagnostycznego dla supportu. Do rekordów NetFlow v5 z celowo logowanych reguł firewall pasuje NetFlow, a do próbek z interfejsów i wzorców ruchu sFlow. Stan sprzętu i interfejsów można dodatkowo monitorować za pomocą SNMP.

Precyzyjne zawężanie przyczyn błędów

Nie docierają żadne logi: Sprawdź cel, port, transport, routing i firewall po drugiej stronie. Następnie sprawdź, czy żądany typ logu jest aktywny w kolumnie Syslog. Jeśli collector znajduje się za VPN lub w sieci zarządzającej, uwzględnij również trasę, politykę SD-WAN i Source NAT.

Brakuje tylko określonych zdarzeń: Najpierw sprawdź logowanie w odpowiedniej regule firewalla lub Inspection Rule, a następnie typ logu w sekcji Log settings. W przypadku ATR sprawdź dodatkowo wymagany typ dopasowania.

Najpierw ustalić, czy moduł i ścieżka ruchu są obsługiwane. Przestrzegać zakresu ATR opisanego powyżej: brak logów nie rozstrzyga konfliktu X-Ops, a sporne kierunki nie uzasadniają po prostu włączania kolejnych typów dopasowania.

Surowe logi docierają, ale brakuje pól: Porównaj skonfigurowany format, wersję parsera i wersję firmware. W jednym profilu parsera nie wolno oczekiwać jednocześnie pól formatu standardowego i legacy.

TLS nie nawiązuje połączenia: Sprawdź port TLS i usługę serwera, następnie łańcuch certyfikatów, FQDN, Common Name, SAN i tryb LINCE. Collector musi dodatkowo ufać CA Sophos Default.pem. Po zmianie certyfikatu sprawdź oba magazyny zaufania i proces odnawiania.

Znaczniki czasu są nieprawidłowe: Sprawdź NTP na firewallu i collectorze, strefę czasową SIEM oraz normalizację parsera. Nieprawidłowy czas uniemożliwia niezawodną korelację z logami endpointów, serwerów i tożsamości.

Zbyt wiele logów lub zbyt dużo szumu: Nie wyłączaj wszystkiego zbiorczo. Najpierw przeanalizuj nieużywane typy logów, niepotrzebnie hałaśliwe reguły, przypadki użycia SIEM i log_occurrence, a następnie celowo ogranicz wybór.