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 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, transport, oczekiwany format logów i odpowiedni parser. Firewall musi mieć trasę do collectora, a oba systemy działające źródło czasu. Zwykle używany jest UDP 514; w przypadku TLS często stosuje się TCP 6514, ale decydująca jest konfiguracja 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: Wartości od LOCAL0 do LOCAL7 mogą rozróżniać firewalle lub grupy lokalizacji. Przypisanie musi być identyczne w collectorze i dokumentacji.
  • 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. W efekcie mogą zniknąć zwłaszcza 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.

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.

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 Central 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.
  • Wireless: Logi punktów dostępowych i SSID nie są dostępne w lokalnym Log Viewer. Należy je celowo wysyłać do Sophos Central 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.

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.

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.

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.

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 skonfigurowany format.
  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.

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.

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.