Wysyłanie Syslog z Sophos Firewall do SIEM

Dzięki Syslog, Sophos Firewall może wysyłać zdarzenia do zewnętrznego serwera logów, SIEM lub platformy bezpieczeństwa. Jest to szczególnie ważne, gdy logi mają być przechowywane dłużej, przeszukiwane centralnie, korelowane z innymi systemami lub wykorzystywane do audytów i reakcji na incydenty.

Lokalny Log viewer jest przydatny do szybkiej analizy bezpośrednio na firewallu. Central Firewall Reporting jest praktyczne, gdy Sophos Central jest używane jako platforma raportowania. Syslog jest lepszym wyborem, gdy istnieje własne SIEM, SOC, proces zarządzania wykrywaniem lub architektura logów obejmująca wielu producentów.

Który artykuł o logowaniu jest odpowiedni?

Logowanie na Sophos Firewall składa się z kilku poziomów. W zależności od pytania, Syslog nie zawsze jest najlepszym punktem wyjścia:

Dzięki temu analiza pozostaje czysta: Log Viewer odpowiada na bieżące przypadki pakietów lub polityki, lokalne logi pomagają w głębszej diagnostyce modułów, Central Reporting jest wygodne dla analiz Sophos, a Syslog dostarcza zewnętrzną warstwę długoterminową i SIEM.

Kiedy Syslog ma sens

Syslog jest opłacalny nie tylko dla dużych środowisk. Nawet przy kilku firewallach centralny serwer logów może pomóc w dłuższym i niezależnym od urządzenia przechowywaniu zdarzeń.

Typowe przypadki użycia:

• centralne przechowywanie logów przez tygodnie, miesiące lub lata
• korelacja z logami Endpoint, serwerów, tożsamości, proxy, chmury lub przełączników
• przypadki użycia SIEM dla ataków, skanów portów, logowań VPN, zdarzeń WAF lub trafień z Threat Feed
• zewnętrzna analiza przez SOC, MDR lub wewnętrzne zespoły bezpieczeństwa
• śledzenie po aktualizacjach firmware, przełączeniach awaryjnych, przywracaniu lub wymianie sprzętu
• analiza kryminalistyczna, gdy lokalne logi firewalla nie wystarczają

Dla pilnych przypadków rozwiązywania problemów lokalne logi pozostają ważne. Który lokalny plik logów należy do którego modułu firewalla, znajduje się w Rozwiązywanie problemów z Sophos Firewall: Usługi i logi. Jeśli logi mają być zabezpieczone do wsparcia lub analizy zewnętrznej, odpowiedni jest Zabezpieczanie logów Sophos Firewall do wsparcia i analizy.

Syslog, Central Reporting czy lokalne logi?

Trzy sposoby odpowiadają na różne pytania. W praktyce często korzysta się z kilku z nich równolegle.

Syslog nie zastępuje Log Viewer. Uzupełnia go. Log Viewer szybko pokazuje, która reguła lub moduł podjęły decyzję. Syslog zapewnia, że te informacje są później dostępne zewnętrznie.

Wymagania wstępne

Przed konfiguracją należy wyjaśnić następujące kwestie:

• Serwer Syslog lub SIEM jest osiągalny.
• Docelowy adres IP lub FQDN jest stabilny i udokumentowany.
• Port i transport są ustalone, często UDP 514 lub TLS na własnym porcie.
• Firewall może routować i osiągnąć serwer Syslog.
• W systemie docelowym istnieje odpowiedni parser lub przynajmniej magazyn surowych danych.
• Czas przechowywania i wymagania dotyczące ochrony danych są zdefiniowane.
• Jest jasne, jakie typy logów są naprawdę potrzebne.

W przypadku zewnętrznych lub opartych na chmurze celów SIEM należy zwrócić szczególną uwagę na szyfrowanie transportu, źródłowy adres IP, routing, DNS i sprawdzanie certyfikatów.

Wyjaśnienie ochrony danych, przechowywania i odpowiedzialności

Syslog to nie tylko techniczne przekazywanie. Logi firewalla mogą zawierać wewnętrzne adresy IP, nazwy użytkowników, systemy docelowe, URL-e, kategorie, logowania VPN, zdarzenia administracyjne i trafienia bezpieczeństwa. Dlatego przed produkcyjnym połączeniem należy wyjaśnić, kto może zobaczyć te dane i jak długo będą przechowywane.

Przed wdrożeniem należy wyjaśnić:

Zwłaszcza w modelach MSP, SOC lub MDR ta odpowiedzialność nie powinna pozostać otwarta. SIEM bez wyraźnych właścicieli generuje dane, ale nie zapewnia niezawodnej reakcji.

Planowanie wdrożenia w fazach

Dla produkcyjnych firewalli lepszy jest mały pilotaż niż natychmiastowe wysyłanie wszystkich typów logów do wszystkich celów. Pozwala to kontrolować parsery, nazwy pól, szum i koszty, zanim SIEM zostanie zaplanowane jako niezawodne źródło.

Sugerowany przebieg:

1. Najpierw wybiera się firewall pilotażowy.
2. Dokumentuje się nazwę hosta, źródło czasu, wersję firmware i format logów.
3. Konfiguruje się cel Syslog z bezpiecznym transportem.
4. Rozpoczyna się od kilku typów logów, na przykład Firewall, Events i VPN.
5. Generuje się zdefiniowane zdarzenia testowe i sprawdza w systemie docelowym.
6. Waliduje się parser, pola, znaczniki czasu, strefę czasową i device_name.
7. Obserwuje się wolumen logów i szum przez kilka dni.
8. Następnie dodaje się kolejne typy logów, takie jak IPS, Web, WAF, Active threat response lub System health.
9. Dopiero po udanym pilotażu wdraża się na kolejne firewalle.

W przypadku wielu firewalli należy sprawdzić nie tylko, czy dane docierają. Ważne jest, czy każde zdarzenie jest przypisane do właściwej lokalizacji, urządzenia, węzła HA, klienta lub najemcy.

Dodawanie serwera Syslog

Konfiguracja odbywa się w interfejsie webowym Sophos Firewall.

1. Otwórz System services > Log settings.
2. Wybierz Add.
3. Nadaj unikalną nazwę, na przykład siem-primary lub syslog-soc.
4. Wprowadź IP address/domain serwera Syslog.
5. Ustaw Port odpowiednio do systemu docelowego.
6. Świadomie wybierz Facility.
7. Ustal Severity level.
8. Wybierz Format.
9. Opcjonalnie aktywuj Secure log transmission, jeśli cel obsługuje TLS.
10. Zapisz.

Sophos Firewall może skonfigurować kilka zewnętrznych serwerów Syslog. W aktualnej dokumentacji przewidziano do pięciu serwerów Syslog. Mimo to nie należy bezmyślnie łączyć każdego celu, lecz dla każdego celu określić, jaki jest jego cel.

Ważne ustawienia

Facility

Facility pomaga serwerowi Syslog rozróżniać źródła logów lub kategorie. W prostych środowiskach często wystarcza wartość domyślna. W większych środowiskach może być sensowne rozdzielenie firewalli lub grup lokalizacji za pomocą różnych wartości LOCAL0 do LOCAL7.

Ważne jest, aby reguły SIEM, parsery i dokumentacja używały tej samej logiki. Jeśli każda zapora używa przypadkowo innej Facility, analiza staje się niepotrzebnie trudna.

Severity level

Severity określa, od jakiej powagi logi są wysyłane. Dla celów bezpieczeństwa i rozwiązywania problemów zbyt wysoki próg jest niebezpieczny, ponieważ mogą brakować ważne zdarzenia informacyjne lub powiadomienia. Dla bardzo głośnych środowisk zbyt niski próg może generować niepotrzebnie dużo szumu.

Zazwyczaj sensowny jest pilotaż z szerszym wyborem logów, a następnie świadoma redukcja na podstawie rzeczywistych trafień i przypadków użycia SIEM.

Format

Sophos Firewall oferuje według aktualnej dokumentacji dwa formaty:

• Standard syslog protocol
• Device standard format (legacy)

Dla nowych integracji należy najpierw sprawdzić, jaki format oczekuje system docelowy lub istniejący parser. Jeśli SIEM ma już parser dla Sophos Firewall, jego oczekiwania są decydujące. Zmiana formatu po rozpoczęciu produkcji może złamać pulpity, zapytania i reguły wykrywania.

Secure log transmission

Jeśli Secure log transmission jest aktywne, logi są wysyłane zaszyfrowane do serwera Syslog. W tym celu system docelowy musi akceptować TLS na skonfigurowanym porcie, dostarczać odpowiedni certyfikat serwera i używać łańcucha certyfikatów, któremu ufa firewall. Przed uruchomieniem na żywo należy więc nie tylko zaznaczyć pole w firewallu, ale także sprawdzić nazwę certyfikatu, łańcuch zaufania, port, parser i proces odnawiania celu Syslog.

Dla wewnętrznych laboratoriów technicznie wystarczy UDP. Dla produkcyjnych połączeń SIEM lub SOC niezaszyfrowany Syslog przez niezabezpieczone sieci nie jest jednak dobrą podstawą, ponieważ logi mogą zawierać wewnętrzne adresy IP, użytkowników, cele, URL-e lub zdarzenia bezpieczeństwa.

Przy TLS ważna jest nazwa celu Syslog. Sophos sprawdza w zależności od trybu Common Name lub Subject Alternative Name certyfikatu względem domeny serwera Syslog. Jeśli w firewallu wpisany jest adres IP, ale certyfikat zawiera tylko nazwę DNS, połączenie może się nie udać. Dlatego dla produkcyjnych celów TLS-Syslog należy zaplanować stabilny FQDN, odpowiedni certyfikat serwera i udokumentowane przedłużenie certyfikatu.

Wybór typów logów

Po dodaniu serwera Syslog praca jeszcze się nie kończy. Trzeba w System services > Log settings określić, jakie typy logów będą wysyłane do tego celu.

Ważne: Reguła firewalla generuje sensowne logi ruchu tylko wtedy, gdy w regule jest aktywowane Log firewall traffic. Dla SSL/TLS Inspection również musi być aktywne logowanie w odpowiedniej regule inspekcji. Wybór logów w Log settings określa następnie, dokąd te logi będą wysyłane.

Typowe typy logów dla SIEM:

Jeśli zdarzenia DoS lub Spoof mają być analizowane, należy również sprawdzić techniczne wzmocnienie. Procedura znajduje się w Sprawdzanie ochrony przed spoofingiem i ustawień DoS w Sophos Firewall.

Jeśli Third-Party Threat Feeds, NDR i Active Threat Response lub WAF są używane, SIEM powinno celowo analizować te zdarzenia. Samo wysyłanie logów nie wystarcza. Potrzebne są jasne zapytania, alarmy, odpowiedzialności i dostosowanie do fałszywych alarmów.

Ważne pułapki widoczności

W projektach Syslog wiele luk powstaje nie w transporcie, ale wcześniej: Firewall nie generuje oczekiwanego zdarzenia, typ logu nie jest wysyłany do serwera Syslog lub SIEM błędnie interpretuje pola.

Logowanie reguł i modułów

Reguły firewalla i reguły inspekcji SSL/TLS muszą same generować logi. W System services > Log settings wybiera się następnie, czy te logi będą wysyłane lokalnie, do Sophos Central czy do serwerów Syslog. Jeśli reguła firewalla nie ma Log firewall traffic, serwer Syslog nie może wyświetlić pełnego przebiegu ruchu firewalla.

Dla zdarzeń polityki webowej również istotne jest, czy odpowiednia reguła firewalla generuje logi ruchu. W przeciwnym razie w SIEM można zobaczyć mniej zdarzeń filtrowania treści lub webowych niż oczekiwano.

Tłumienie logów

Sophos Firewall może tłumić wiele takich samych kolejnych wpisów logów. Oszczędza to pamięć i przetwarzanie, ale może wprowadzać zamieszanie w przypadkach użycia SIEM, gdy mają być analizowane wartości liczbowe, częstotliwość lub zachowanie w przypadku burstów. Funkcja działa na Log Viewer, Sophos Central i zewnętrzne serwery Syslog.

Przed produkcyjnym wdrożeniem SIEM należy więc ustalić:

• Jakie zdarzenia firewalla mogą być tłumione?
• Jakie reguły wykrywania potrzebują każdej pojedynczej sesji?
• Czy w SIEM pracuje się z wartościami liczbowymi czy tylko z pojedynczymi zdarzeniami?
• Jak dokumentować, że tłumienie logów jest aktywne?

Active Threat Response

Logi Active Threat Response są szczególnie przydatne, gdy używane są Threat Feeds, NDR Essentials lub zewnętrzne feedy. Sophos rozróżnia różne typy dopasowań, na przykład trafienia docelowe przy wychodzącym ruchu i trafienia źródłowe przy ruchu przychodzącym.

Ważne: Dopasowanie źródła zdalnego dla ruchu przychodzącego nie jest automatycznie aktywne. Jeśli ruch WAF lub DNAT ma być monitorowany pod kątem Threat Feeds, należy świadomie sprawdzić tę widoczność. W przeciwnym razie mogą brakować dokładnie te trafienia przychodzące, których SOC często oczekuje.

Logi bezprzewodowe

Logi bezprzewodowe nie są automatycznie widoczne w lokalnym Log Viewer. Logi punktów dostępowych i SSID powinny być celowo wysyłane do Sophos Central lub Syslog i sprawdzane osobno w systemie docelowym, jeśli zdarzenia bezprzewodowe są istotne dla operacji, wsparcia lub zgodności.

Środowiska z wieloma firewallami

W środowiskach z wieloma firewallami każde zdarzenie musi być jednoznacznie przypisane do urządzenia. W tym celu istotne są nazwa hosta, numer seryjny, model i inne pola. Przewodnik SFOS Syslog opisuje między innymi pola takie jak device_name, device_model i device_serial_id.

Praktyczne zalecenia:

• Ustaw poprawnie nazwę hosta firewalla.
• Uwzględnij lokalizację lub rolę w nazwie hosta.
• Zdefiniuj jednolitą strategię Facility lub tagowania.
• Sprawdź w SIEM, czy zdarzenia można filtrować według firewalla, lokalizacji i klastra.
• Wyraźnie rozróżniaj klastry HA i firewalle samodzielne.

Zwłaszcza po wymianie sprzętu lub przywróceniu ta alokacja jest ważna. W przeciwnym razie zdarzenia w SIEM wyglądają jak nowe lub podwójne systemy.

Testowanie konfiguracji

Po zapisaniu należy świadomie przetestować połączenie. Sam zielony system docelowy nie dowodzi jeszcze, że właściwe logi z właściwymi polami docierają.

Punkty testowe:

1. Na firewallu otwórz System services > Log settings.
2. Upewnij się, że serwer Syslog jest widoczny.
3. Dla bezpiecznego typu logu testowo aktywuj Syslog.
4. Wywołaj zdefiniowaną akcję, na przykład zalogowaną regułę firewalla lub testowy dostęp.
5. Sprawdź w systemie docelowym, czy zdarzenie dociera.
6. Sprawdź pola takie jak czas, nazwa hosta, device_name, źródło, cel, ID reguły, akcja i typ logu.
7. Skontroluj znaczniki czasu i strefę czasową w SIEM.

Dla testów reguł pomocne jest Testowanie reguł firewalla za pomocą Log Viewer, Policy Test i Packet Capture. Jeśli nie powstają żadne zdarzenia, przyczyna często nie leży w transporcie Syslog, ale w wyłączonym logowaniu w regule lub w niewłaściwym typie logu.

Operacja i monitorowanie

Połączenie Syslog nie jest jednorazowym zadaniem. Operacja musi być monitorowana i regularnie sprawdzana.

Przynajmniej te punkty powinny być udokumentowane:

• Kto jest właścicielem platformy logów?
• Które firewalle wysyłają logi?
• Jakie typy logów są wysyłane?
• Jaki okres przechowywania obowiązuje?
• Jakie parsery, pulpity i alarmy są z tym związane?
• Jak rozpoznać, że logi przestają docierać?
• Jak sprawdzać zmiany formatu po aktualizacjach firmware?
• Kto ocenia fałszywe alarmy i dostosowuje reguły SIEM?

Po aktualizacjach firmware należy losowo sprawdzać, czy ważne zdarzenia są nadal poprawnie parsowane. Dotyczy to szczególnie produkcyjnych reguł SIEM, które polegają na określonych nazwach pól, typach logów lub formatach.

Rozwiązywanie problemów

Żadne logi nie docierają do SIEM

Najpierw sprawdź adres IP, port, routing i reguły firewalla między Sophos Firewall a serwerem Syslog. Następnie sprawdź, czy w System services > Log settings jest aktywowany właściwy typ logu dla serwera Syslog.

Brakuje tylko określonych zdarzeń

Wtedy często nie jest aktywne logowanie modułu lub reguły. W przypadku reguł firewalla musi być ustawione Log firewall traffic. W przypadku zdarzeń webowych lub SSL/TLS musi dodatkowo generować logi odpowiednia polityka lub reguła inspekcji.

Logi docierają, ale są źle parsowane

Sprawdź format, wersję parsera i wersję firmware. Jeśli zmieniono między Standard syslog protocol a Device standard format (legacy), parser SIEM musi do tego pasować.

TLS-Syslog nie łączy się

Sprawdź FQDN, certyfikat, Common Name, Subject Alternative Name, łańcuch certyfikatów i port. Jeśli firewall oczekuje nazwy DNS, a serwer Syslog jest wpisany tylko przez adres IP, sprawdzanie certyfikatu może się nie powieść. Dodatkowo sprawdź, czy system docelowy rzeczywiście akceptuje TLS na skonfigurowanym porcie.

Znaczniki czasu są nieprawidłowe

Sprawdź NTP na firewallu, strefę czasową w SIEM i logikę parsera. Nieprawidłowe czasy sprawiają, że korelacja z logami Endpoint, serwerów lub tożsamości jest niewiarygodna.

Zbyt wiele logów lub zbyt dużo szumu

Nie wyłączaj wszystkiego od razu. Najpierw sprawdź, jakie typy logów są naprawdę potrzebne, które reguły logują zbyt dużo i czy tłumienie logów jest sensowne. Następnie celowo redukuj.

Lista kontrolna

• Serwer Syslog lub SIEM jest osiągalny.
• Transport, port i szyfrowanie są ustalone.
• Format pasuje do parsera SIEM.
• Strategia Facility jest udokumentowana.
• Odpowiednie typy logów są aktywowane w System services > Log settings.
• Ważne reguły firewalla mają aktywne Log firewall traffic.
• Reguły inspekcji SSL/TLS generują w razie potrzeby własne logi.
• Tłumienie logów jest świadomie ocenione i udokumentowane.
• Typy dopasowań Active Threat Response pasują do przypadków użycia SIEM.
• Ochrona danych, dostęp i okres przechowywania są wyjaśnione.
• Firewall pilotażowy, zdarzenia testowe i parser SIEM zostały zweryfikowane.
• Zdarzenia testowe docierają do systemu docelowego.
• Pola takie jak nazwa hosta, device_name, źródło, cel, akcja i ID reguły są poprawnie rozpoznawane.
• Znaczniki czasu i strefa czasowa są prawidłowe.
• Monitorowanie wykrywa, gdy logi przestają docierać.
• Po aktualizacjach firmware sprawdzana jest funkcja parsera.

FAQ