Wyślij bezpiecznie Sophos Firewall Syslog do SIEM

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

Lokalna Przeglądarka logów jest dobra do szybkiej analizy bezpośrednio na zaporze ogniowej. Centralne raportowanie zapory ogniowej jest wygodne, gdy używasz Sophos Central jako platformy raportowania. Syslog jest natomiast lepszym wyborem, jeśli posiadasz własny SIEM, SOC, zarządzany proces wykrywania lub architekturę dzienników różnych producentów.

Który artykuł dotyczący logowania pasuje?

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

• Analizuj na żywo pojedyncze połączenie, Rule ID lub decyzję o sieci/IPS: Sophos Firewall Testowanie reguł za pomocą Log Viewer, testera zasad i Packet Capture
• Przypisz lokalne pliki dziennika i usługi: Sophos Firewall Rozwiązywanie problemów: Services i dzienniki
• Utwórz kopię zapasową dzienników do celów wsparcia lub analizy zewnętrznej: Sophos Firewall Utwórz kopię zapasową dzienników w celu wsparcia i analizy
• Śledź zmiany konfiguracji i działania administratora: Sophos Firewall Sprawdź dzienniki ścieżki audytu
• Korzystaj z raportów opartych na Sophos Central na wielu zaporach ogniowych: Sophos Firewall Aktywuj i obsługuj Centralne raportowanie
• Wysyłaj logi długoterminowe do SIEM, SOC lub serwera logów: Ten artykuł
• Analizuj przepływy ruchu zamiast poszczególnych zdarzeń zapory: Skonfiguruj monitorowanie przepływu w Sophos Firewall
• Sprawdź stan sprzętu i interfejsu poprzez monitorowanie: Sophos Firewall Konfiguracja monitorowania sprzętu SNMP

Dzięki temu ocena jest czysta: Log Viewer odpowiada na bieżący pakiet lub przypadek polisy, lokalne dzienniki pomagają w głębszej diagnostyce modułu, centralne raportowanie jest wygodne w przypadku ocen Sophos, a Syslog zapewnia zewnętrzną warstwę długoterminową i SIEM.

Kiedy Syslog ma sens

Syslog warto stosować nie tylko w dużych środowiskach. Nawet w przypadku kilku zapór sieciowych centralny serwer dzienników może pomóc w przechowywaniu zdarzeń dłużej i niezależnie od urządzenia.

Typowe przypadki użycia:

• Centralne przechowywanie kłód przez tygodnie, miesiące lub lata
• Korelacja z dziennikami punktu końcowego, serwera, tożsamości, proxy, chmury lub przełącznika
• Przypadki użycia SIEM do ataków, skanowania portów, logowania VPN, zdarzeń WAF lub trafień z kanałów zagrożeń
• ocena zewnętrzna przez SOC, MDR lub wewnętrzne zespoły bezpieczeństwa
• Możliwość śledzenia po aktualizacji oprogramowania sprzętowego, przełączeniu awaryjnym, przywróceniu lub wymianie sprzętu
• Kryminalistyka, gdy lokalne dzienniki zapory ogniowej nie są już wystarczające

Lokalne dzienniki pozostają ważne w przypadku pilnych przypadków rozwiązywania problemów. Który lokalny plik dziennika należy do którego modułu zapory sieciowej, można znaleźć w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki. Jeśli chcesz utworzyć kopię zapasową dzienników na potrzeby wsparcia lub analizy zewnętrznej, odpowiedni będzie Sophos Firewall Utwórz kopię zapasową dzienników na potrzeby wsparcia i analizy.

Syslog, Central Reporting czy lokalne logi?

Te trzy ścieżki odpowiadają na różne pytania. W praktyce często korzysta się z kilku z nich równolegle.

• Log viewer: szybka analiza na żywo na firewallu, ale bez długoterminowej architektury centralnej.
• Lokalne pliki logów: szczegółowa analiza przez Advanced Shell lub zgłoszenie do supportu, ale zależna od stanu i pamięci firewalla.
• Central Firewall Reporting: raporty Sophos Central i prosty przegląd wielu firewalli, ale powiązane z Sophos Central, licencją i limitem przechowywania.
• Syslog / SIEM: własna retencja, korelacja, detekcja i audyt. Wymaga to parserów, obsługi, monitoringu i jasnych przypadków użycia.

Syslog nie zastępuje więc Log Viewera. Uzupełnia go. Log Viewer szybko pokazuje, która reguła lub który moduł podjął decyzję. Syslog zapewnia, że te informacje pozostaną później dostępne poza firewallem.

Wymagania

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

• Serwer Syslog lub SIEM jest osiągalny.
• Docelowy adres IP lub nazwa FQDN jest stabilna i udokumentowana.
• Port i transport są stałe, często UDP 514 lub TLS na własnym porcie.
• Zapora sieciowa może trasować i docierać do serwera Syslog.
• W systemie docelowym istnieje odpowiedni parser lub przynajmniej magazyn surowych danych.
• NTP działa na zaporze sieciowej i platformie docelowej.
• Określono okres przechowywania i wymogi dotyczące ochrony danych.
• Jasne jest, jakie typy dzienników są naprawdę potrzebne.

W przypadku zewnętrznych lub opartych na chmurze miejsc docelowych SIEM należy zwrócić szczególną uwagę na szyfrowanie transportu, źródłowy adres IP, routing, DNS i weryfikację certyfikatu. Niektórzy dostawcy SIEM lub MDR celowo oczekują niezaszyfrowanego Syslog do lokalnego modułu zbierającego lub czujnika, który następnie przekazuje dane. Wtedy niezaszyfrowana trasa powinna być krótka, wewnętrznie podzielona na segmenty i udokumentowana.

Wyjaśnij kwestię ochrony danych, ich przechowywania i odpowiedzialności

Syslog to nie tylko przekierowanie techniczne. Dzienniki zapory mogą zawierać wewnętrzne adresy IP, nazwy użytkowników, systemy docelowe, adresy URL, kategorie, loginy VPN, zdarzenia administracyjne i naruszenia bezpieczeństwa. Dlatego przed połączeniem produktywnym powinno być jasne, kto może zobaczyć te dane i jak długo będą one przechowywane.

Wyjaśnij przed wdrożeniem:

• Przechowywanie: Jak długo muszą być dostępne dzienniki operacyjne, audytowe lub dzienniki reakcji na incydenty?
• Dostęp: Które osoby lub zespoły mogą wyświetlać nieprzetworzone dzienniki, zapytania wyszukiwania i pulpity nawigacyjne?
• Ochrona danych: Czy dzienniki zawierają dane osobowe, identyfikatory użytkowników, źródłowe adresy IP lub adresy URL?
• Możliwość obsługi wielu klientów: Czy lokalizacje, klienci, najemcy lub klastry HA są wyraźnie oddzielone w SIEM?
• Koszt: Czy woluminy dziennika, EPS, pamięć masowa lub zapytania wyszukiwania są rozliczane przez dostawcę SIEM?
• Alarmowanie: Kto reaguje na alarmy i w jakim przedziale czasowym?
• Usunięcie: W jaki sposób usuwane są stare logi po upływie okresu przechowywania?

Nie należy pozostawiać tej odpowiedzialności otwartej, zwłaszcza w przypadku modeli MSP, SOC lub MDR. SIEM bez wyraźnego właściciela generuje dane, ale nie daje wiarygodnych odpowiedzi.

Planuj wdrażanie etapami

W przypadku wydajnych zapór ogniowych mały program pilotażowy jest lepszy niż natychmiastowe wysyłanie wszystkich typów dzienników do wszystkich miejsc docelowych. Pozwala to kontrolować parsery, nazwy pól, szumy i koszty, zanim SIEM zostanie zaplanowany jako niezawodne źródło.

Rozsądny proces:1. Najpierw wybierana jest zapora pilotażowa. 2. Udokumentowano nazwę hosta, źródło czasu, wersję oprogramowania sprzętowego i format dziennika. 3. Miejsce docelowe Syslog jest skonfigurowane z bezpiecznym transportem. 4. Zaczyna się od kilku typów dzienników, na przykład zapory ogniowej, zdarzeń i VPN. 5. Zdefiniowane zdarzenia testowe są generowane i sprawdzane w systemie docelowym. 6. Sprawdzany jest parser, pola, znacznik czasu, strefa czasowa i device_name. 7. Objętość kłód i hałas obserwuje się przez kilka dni. 8. Następnie dodawane są dodatkowe typy dzienników, takie jak IPS, Web, WAF, Aktywna reakcja na zagrożenia lub Kondycja systemu. 9. Dopiero po pomyślnym zakończeniu pilotażu zostanie on wdrożony w innych zaporach sieciowych.

Jeśli masz wiele zapór sieciowych, nie powinieneś po prostu sprawdzać, czy dane przychodzą. Ważne jest, czy każde zdarzenie jest przypisane do właściwej lokalizacji, urządzenia, węzła HA, klienta czy najemcy.

Pilot powinien obejmować co najmniej jedno normalne zdarzenie operacyjne, jedno zdarzenie związane z bezpieczeństwem i jedno zdarzenie związane z błędem. W przeciwnym razie transport wydaje się zdrowy, ale później ważnych pól brakuje tylko w sytuacjach awaryjnych.

Dodaj serwer Syslog

Konfiguracja odbywa się w interfejsie internetowym Sophos Firewall.

1. Otwórz System services > Log settings.
2. Wybierz Dodaj.
3. Nadaj unikalną nazwę, np. siem-primary lub syslog-soc.
4. Wpisz adres IP/domena serwera Syslog.
5. Ustaw Port zgodnie z systemem docelowym.
6. Wybieraj świadomie Obiekt.
7. Ustaw Poziom ważności.
8. Wybierz Format.
9. Opcjonalnie włącz Secure log transmission, jeśli miejsce docelowe obsługuje TLS.
10. Zapisz.

Sophos Firewall może skonfigurować wiele zewnętrznych serwerów Syslog. Aktualna dokumentacja przewiduje maksymalnie pięć serwerów Syslog. Niemniej jednak nie powinieneś łączyć każdego celu losowo, ale raczej określić cel stojący za każdym celem.

Jeśli masz wiele celów, powinieneś świadomie oddzielić wybór dziennika dla każdego celu. Lokalny serwer dzienników może potrzebować wszystkich dzienników zapory ogniowej i VPN, podczas gdy moduł zbierający MDR oczekuje tylko typów dzienników istotnych dla bezpieczeństwa. Jeśli wszystkie cele na ślepo otrzymają te same dane, wzrosną koszty, ryzyko prywatności i szum parsera.

Ważne ustawienia

Obiekt

Funkcja ta pomaga serwerowi Syslog rozróżniać źródła dzienników lub kategorie. W prostych środowiskach często wystarcza wartość domyślna. W większych środowiskach sensowne może być oddzielenie zapór ogniowych lub grup lokalizacji przy użyciu różnych wartości LOCAL0 do LOCAL7.

Co ważne, reguły, parsery i dokumentacja SIEM korzystają z tej samej logiki. Jeśli zdarzy się, że każda zapora sieciowa korzysta z innego narzędzia, ocena staje się niepotrzebnie trudna.

Poziom ważności

Ważność określa ważność, z jaką wysyłane są dzienniki. Ze względów bezpieczeństwa i rozwiązywania problemów zbyt wysoki próg jest niebezpieczny, ponieważ może przeoczyć ważne informacje lub powiadomienia. Jednakże w przypadku bardzo głośnych środowisk zbyt niski próg może generować niepotrzebną ilość hałasu.

Zwykle ma sens mieć pilota z większym wyborem logów, a potem świadomą redukcję w oparciu o realne trafienia i przypadki użycia SIEM.

Próg należy rozumieć jako minimalną wagę. Jeśli na przykład wybrane jest Error, firewall wysyła także krytyczniejsze komunikaty, takie jak Critical, Alert i Emergency, ale nie zwykłe zdarzenia informacyjne. W wielu przypadkach użycia SIEM właśnie zdarzenia Information i Notice są ważne, bo inaczej mogą brakować logowania VPN, zdarzenia reguł albo stany systemu.

formacie

Zgodnie z aktualną dokumentacją Sophos Firewall oferuje dwa formaty:

• Standardowy protokół syslog
• Standardowy format urządzenia (starszy)

W przypadku nowych integracji należy najpierw sprawdzić jakiego formatu oczekuje system docelowy lub istniejący parser. Jeśli SIEM ma już parser zapory sieciowej Sophos, jego oczekiwania mają pierwszeństwo. Zmiana formatu po uruchomieniu może złamać dashboardy, zapytania wyszukiwania i reguły wykrywania.

Secure log transmission

Gdy Secure log transmission jest aktywne, logi wysyłane są w postaci zaszyfrowanej na serwer Syslog. Aby to zrobić, system docelowy musi akceptować protokół TLS na skonfigurowanym porcie, dostarczyć odpowiedni certyfikat serwera i używać łańcucha certyfikatów, któremu ufa zapora sieciowa. Przed uruchomieniem powinieneś nie tylko sprawdzić zaporę ogniową, ale także sprawdzić nazwę certyfikatu, łańcuch zaufania, port, analizator składni i proces odnawiania celu Syslog.

UDP może być technicznie wystarczający dla laboratoriów wewnętrznych. Jednak niezaszyfrowany Syslog w niezabezpieczonych sieciach nie jest dobrą podstawą do produktywnych połączeń SIEM lub SOC, ponieważ dane dziennika mogą zawierać wewnętrzne adresy IP, użytkowników, miejsca docelowe, adresy URL lub zdarzenia związane z bezpieczeństwem.

W przypadku TLS ważna jest nazwa celu Syslog. Bez aktywnego trybu zgodności LINCE Sophos Firewall sprawdza Common Name certyfikatu względem domeny serwera Syslog; w tym standardowym przypadku Subject Alternative Name nie zastępuje Common Name. Przy aktywnym LINCE może pasować Common Name albo Subject Alternative Name. Jeśli w firewallu wpisano adres IP, ale certyfikat zawiera tylko nazwę DNS, albo jeśli certyfikat pasuje tylko przez SAN, połączenie może się nie powieść zależnie od trybu. Dla produkcyjnych celów TLS Syslog należy zaplanować stabilny FQDN, pasujący certyfikat serwera i udokumentowany proces odnowienia certyfikatu.

Jednocześnie system docelowy musi naprawdę rozumieć wybraną procedurę. Niektóre integracje SIEM wymagają lokalnego modułu zbierającego i nie obsługują bezpośrednio zapory Secure log transmission. Wtedy często lepszym rozwiązaniem jest: Zapora sieciowa wysyła dane wewnętrznie do modułu zbierającego, moduł zbierający dalej szyfruje do chmury lub platformy SOC. Architekturę tę należy uwzględnić w dokumencie operacyjnym, w przeciwnym razie w późniejszym czasie zostanie błędnie przyjęte założenie, że wszystkie odcinki trasy są szyfrowane.

Wybierz typy dzienników

Po dodaniu serwera Syslog praca nie jest zakończona. W System services > Log settings musisz określić, jakie typy logów mają być wysyłane do tego miejsca docelowego.

Ważne: reguła zapory tworzy istotne logi ruchu tylko wtedy, gdy w regule aktywne jest Log firewall traffic. W przypadku SSL/TLS Inspection w odpowiedniej regule inspekcji musi być także aktywne Log connections. Wybór logów w Log settings określa następnie, czy te logi są wysyłane lokalnie, do Sophos Central czy do serwerów Syslog.

Typowe typy kłód dla SIEM:

• Zapora sieciowa: połączenia dozwolone i odrzucane, dopasowywanie reguł, zdarzenia DoS
• IPS: Ataki wykryte lub zablokowane
• Filtrowanie sieci/treści: Ruch w sieci, kategorie, zdarzenia związane z polityką sieciową
• Inspekcja SSL/TLS: Decyzje i błędy dotyczące kontroli TLS
• Ochrona serwera WWW: Wydarzenia WAF dla opublikowanych usług
• Uwierzytelnianie / Zdarzenia: Zdarzenia administratora, użytkownika i systemu
• VPN: Zdalny dostęp i zdarzenia typu site-to-site VPN
• Aktywna reakcja na zagrożenie: Trafienia z kanałów o zagrożeniach MDR, NDR Essentials, Sophos X-Ops i kanałów o zagrożeniach innych firm
• Kondycja systemu: Procesor, pamięć, użytkownicy, interfejsy i partycje

Jeśli oceniane ma być DoS lub fałszywe zdarzenia, należy również przetestować samo wzmocnienie techniczne. Proces odbywa się w Sophos Firewall Sprawdź ustawienia Spoof Protection i DoS.

Jeśli używane są Źródła zagrożeń stron trzecich, NDR i Active Threat Response lub WAF, SIEM powinien szczegółowo ocenić te zdarzenia. Samo przesłanie logów nie wystarczy. Wymaga jasnych zapytań wyszukiwania, alarmów, odpowiedzialności i strojenia pod kątem fałszywych alarmów.

Świadomie sprawdzić pola parsera

Zdarzenia Syslog Sophos zawierają różne pola zależnie od typu logu. Dla parserów i dashboardów szczególnie istotne są log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name oraz znaczniki czasu.

log_id to więcej niż przypadkowa liczba. ID składa się z typu logu, komponentu, podtypu, wagi i Message ID. To pomaga, gdy SIEM ma budować stabilne reguły detekcji, dashboardy lub normalizacje, a nie tylko przeszukiwać wolny tekst.

Przy odbiorze nie wystarczy więc sprawdzić, czy przychodzą surowe dane. Decydujące jest to, czy pola naprawdę trafiają do SIEM jako osobne pola. Jeśli fw_rule_id albo nat_rule_id zostają tylko w surowym tekście, późniejsze wyszukiwania i alarmy często działają gorzej niż oczekiwano.

Zanonimizowane zdarzenie firewall w formacie raw może wyglądać na przykład tak:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

Przykład nie zastępuje oficjalnej referencji pól. Pokazuje jednak, które informacje podczas testu parsera powinny być widoczne jako osobne pola.

Typowy zestaw startowy dla pilota SIEM

Dla pilota mała, przemyślana seria startowa jest lepsza niż pełna aktywacja bez oceny.

• Zacznij: Zapora sieciowa, zdarzenia, VPN. Sprawdź poziom szumów, zdarzenia reguł, widoczność administratora i VPN
• Bezpieczeństwo: IPS, Sieć, Ochrona serwera WWW, Aktywna reakcja na zagrożenia. Zweryfikuj przypadki użycia zabezpieczeń i pola analizatora
• Operacja: Kondycja systemu, DHCP, DNS, uwierzytelnianie. Dodaj kontekst operacyjny i tożsamościowy
• Dostrajanie: dodatkowe moduły według potrzeb. aktywuj tylko wtedy, gdy istnieje cel wyszukiwania, alarmowania lub audytu

Po każdej fazie należy sprawdzić, czy SIEM poprawnie rozpoznaje pola i czy rzeczywiście ktoś korzysta z nowych zdarzeń. Niesprawdzone typy dzienników nie stanowią wartości dodanej, a jedynie dodatkowy wolumen.

Ważne pułapki widoczności

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

Rejestrowanie reguł i modułów

Reguły zapory sieciowej i reguły inspekcji SSL/TLS muszą same generować logowanie. W System services > Log settings możesz wybrać, czy logi te mają być wysyłane lokalnie, w Sophos Central, czy na serwer Syslog. Jeśli reguła zapory nie zawiera opcji Logowanie ruchu zapory, serwer Syslog nie może wyświetlić pełnej historii ruchu zapory.

W przypadku zdarzeń związanych z zasadami sieciowymi istotne jest również to, czy powiązana reguła zapory sieciowej generuje rejestrowanie ruchu. W przeciwnym razie w urządzeniu SIEM może pojawić się mniej zdarzeń filtrowania sieci lub treści, niż oczekiwano.

Blokowanie logów

Sophos Firewall może ukryć kilka identycznych kolejnych wpisów dziennika. Oszczędza to pamięć i przetwarzanie, ale może być mylące w przypadkach użycia SIEM, gdy należy ocenić wartości zliczania, częstotliwość lub zachowanie serii. Funkcja działa na serwerach Log Viewer, Sophos Central i zewnętrznych serwerach Syslog.

Dlatego przed produktywnym wdrożeniem SIEM należy określić:

• Które zdarzenia zapory sieciowej można zablokować?
• Jakich reguł wykrywania wymaga każde indywidualne połączenie?
• Czy SIEM działa z wartościami zliczonymi, czy tylko z pojedynczymi zdarzeniami?
• W jaki sposób udokumentowano, że tłumienie logów jest aktywne?

Active Threat Response

Dzienniki aktywnej reakcji na zagrożenia są szczególnie przydatne w przypadku korzystania z kanałów zagrożeń, oprogramowania NDR Essentials lub źródeł zewnętrznych. Sophos rozróżnia różne typy dopasowań, na przykład trafienia docelowe dla ruchu wychodzącego i trafienia źródłowe dla ruchu przychodzącego.

Ważne: Zdalne dopasowanie źródła dla ruchu przychodzącego nie jest aktywowane automatycznie. Jeśli ruch WAF lub DNAT ma być monitorowany pod kątem źródeł zagrożeń, należy świadomie sprawdzić tę widoczność. W przeciwnym razie nadchodzące trafienia, których często oczekuje SOC, będą brakować.

Dzienniki sieci bezprzewodowej

Dzienniki sieci bezprzewodowej nie są automatycznie widoczne w lokalnym urządzeniu Log Viewer. Dzienniki punktów dostępu i identyfikatorów SSID należy przesyłać konkretnie do Sophos Central lub Syslog i oddzielnie sprawdzać w systemie docelowym, czy zdarzenia bezprzewodowe są istotne dla operacji, wsparcia lub zgodności.

Środowiska z wieloma zaporami sieciowymi

W środowiskach z wieloma zaporami ogniowymi każde zdarzenie musi być jednoznacznie przypisane do urządzenia. W tym przypadku istotne są nazwa hosta, numer seryjny, model i inne pola. W zależności od typu logu w zdarzeniach Syslog mogą pojawić się pola takie jak device_name, device_model i device_serial_id. SIEM powinien nie tylko przechowywać te pola, ale także umożliwiać ich wykorzystanie w filtrach, pulpitach nawigacyjnych i alarmach.

Praktyczne zalecenia:

• Ustaw czysto nazwę hosta zapory ogniowej.
• Weź pod uwagę lokalizację lub rolę w nazwie hosta.
• Zdefiniuj jednolity obiekt lub strategię znakowania.
• W SIEM sprawdź, czy zdarzenia mogą być filtrowane przez zaporę sieciową, lokalizację i klaster.
• Wyraźne rozróżnienie pomiędzy klastrami HA i samodzielnymi zaporami ogniowymi.

To przypisanie jest szczególnie ważne po wymianie lub przywróceniu sprzętu. W przeciwnym razie zdarzenia w SIEM wyglądają jak nowe lub zduplikowane systemy.

W przypadku klastrów HA należy również przetestować wygląd zdarzeń po przełączeniu awaryjnym. Liczy się to, czy operacje i SOC nadal rozpoznają tę samą lokalizację, czy też w SIEM nagle pojawi się inna nazwa hosta, numer seryjny lub nowy zasób.

Konfiguracja testowa

Po zapisaniu należy świadomie przetestować połączenie. Sam zielony system docelowy nie gwarantuje, że dotrą właściwe kłody z właściwymi polami.

Punkty testowe:

1. Otwórz System services > Log settings na zaporze sieciowej.
2. Upewnij się, że serwer Syslog jest widoczny.
3. Aby uzyskać bezpieczny typ dziennika, aktywuj Syslog w ramach testu.
4. Wywołaj określoną akcję, np. zarejestrowaną regułę zapory sieciowej lub test dostępu.
5. Sprawdź w systemie docelowym, czy zdarzenie nadeszło.
6. Sprawdź pola takie jak czas, nazwa hosta, device_name, źródło, miejsce docelowe, Rule ID, akcja i typ dziennika.
7. Sprawdź znacznik czasu i strefę czasową w SIEM.
8. Dla zdarzeń firewall sprawdzić, czy fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status i log_occurrence są osobno wyszukiwalne.

Do testowania reguł przydatna jest opcja Testuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture. Jeśli w ogóle nie wystąpią żadne zdarzenia, przyczyną często nie jest transport Syslog, ale raczej dezaktywacja rejestrowania z reguły lub niewłaściwy typ dziennika.

Znaczące zdarzenia testowe

Dobry test akceptacyjny tworzy nie byle jaki dziennik, ale dokładnie te zdarzenia, które będą później wyszukiwane.

• Zalogowana reguła testowa umożliwia połączenie: Źródło, miejsce docelowe, usługa, działanie, Rule ID i zapora sieciowa wyraźnie widoczne
• Zdefiniowana zasada upuszczania trafień: Pojawia się zdarzenie upuszczenia z właściwym kierunkiem i czasem
• VPN użytkownik łączy się i rozłącza: Wykryto użytkownika, typ tunelu, czas i zaporę
• Polityka internetowa lub wydarzenie testowe IPS: Typ dziennika, kategoria lub podpis są poprawnie rozpoznawane przez parser
• Test ATR lub źródła zagrożeń, jeśli jest dostępny: Trafienie pojawia się w oczekiwanym przypadku użycia i nie generuje fałszywego alarmu
• HA test przełączania awaryjnego lub przywracania, jeśli jest planowany: Zdarzenia pozostają w sposób identyfikowalny przypisane do lokalizacji, klastra i urządzenia. W przypadku produktywnych reguł SIEM należy również udokumentować negatywny wynik testu: Co się stanie, jeśli oczekiwane zdarzenie nie nastąpi? Dopiero wtedy okaże się później, czy analizator składni, moduł zbierający lub typ dziennika uległ cichej awarii.

Operacje i monitorowanie

Połączenie Syslog nie jest jednorazowym haczykiem. Działanie należy monitorować i regularnie sprawdzać.

Przynajmniej te punkty powinny zostać udokumentowane:

• Kto jest właścicielem platformy dziennika?
• Które zapory sieciowe wysyłają logi?
• Jakie typy dzienników są wysyłane?
• Jaki okres przechowywania ma zastosowanie?
• Jakie parsery, dashboardy i alarmy są do niego dołączone?
• Po czym rozpoznajesz, że dzienniki już nie docierają?
• W jaki sposób sprawdzane są zmiany formatu po aktualizacji oprogramowania sprzętowego?
• W jaki sposób monitorowane są wygaśnięcia certyfikatów, aktualizacje modułów zbierających i zmiany w parserze?
• Kto ocenia fałszywe alarmy i dostosowuje zasady SIEM?

Po aktualizacji oprogramowania sprzętowego należy przeprowadzać losowe kontrole, aby sprawdzić, czy ważne zdarzenia są nadal poprawnie analizowane. Jest to szczególnie prawdziwe w przypadku produktywnych reguł SIEM, które opierają się na określonych nazwach pól, typach lub formatach dzienników.

Wykrywanie cichej awarii logowania

Dla eksploatacji powinien istnieć prosty wskaźnik awarii:

• Na firewall: zdefiniować oczekiwaną minimalną liczbę zdarzeń w danym okresie, na przykład zdarzeń Firewall lub System.
• Na ważny typ logu: sprawdzać, czy Firewall, VPN, Web, IPS lub Active threat response nadal regularnie dostarczają zdarzenia.
• Na parser: monitorować, czy centralne pola, takie jak device_name, Source, Destination, Action i Rule ID, nadal są wypełniane.
• Na collector: rozpoznawać, czy lokalny collector nie przyjmuje już danych albo ich nie przekazuje.
• Po zmianach: traktować aktualizację firmware, aktualizację parsera, zmianę certyfikatu, restore firewalla i failover HA jako powód do ponownego testu akceptacyjnego.

Dobra eksploatacja SIEM alarmuje więc nie tylko przy podejrzanych zdarzeniach, ale także przy brakujących zdarzeniach. Jeśli produkcyjny firewall nagle przestaje dostarczać logi, samo w sobie jest to zdarzenie operacyjne.

Rozwiązywanie problemów

Do SIEM nie docierają żadne dzienniki

Najpierw sprawdź adres IP, port, routing i reguły zapory sieciowej pomiędzy Sophos Firewall a serwerem Syslog. Następnie sprawdź, czy dla serwera Syslog pod System services > Log settings aktywowano prawidłowy typ dziennika.

Jeśli serwer Syslog jest dostępny poprzez tunel VPN lub oddzielną sieć zarządzającą, sprawdź także trasę, politykę SD-WAN, źródłowy NAT i zaporę licznika. Z punktu widzenia Sophos Firewall Syslog to normalny ruch wychodzący; musi faktycznie dotrzeć do kolektora.

Brakuje tylko niektórych wydarzeń

Wtedy moduł lub logowanie reguł często nie jest aktywne. W przypadku reguł zapory sieciowej należy ustawić Logowanie ruchu zapory. W przypadku zdarzeń internetowych lub SSL/TLS należy również wygenerować odpowiednią politykę lub regułę inspekcji.

Dzienniki docierają, ale są nieprawidłowo analizowane

Sprawdź format, wersję parsera i wersję oprogramowania sprzętowego. W przypadku przełączania pomiędzy Standardowym protokołem syslog i Standardowym formatem urządzenia (starszy), parser SIEM musi go pasować.

TLS-Syslog nie łączy się

Sprawdź FQDN, certyfikat, Common Name, Subject Alternative Name, tryb LINCE, łańcuch certyfikatów i port. W większości środowisk bez LINCE Common Name musi pasować do skonfigurowanej domeny; nazwa pasująca tylko w SAN nie wystarcza. Jeśli firewall oczekuje nazwy DNS, ale serwer Syslog wpisano tylko przez adres IP, sprawdzenie certyfikatu również może się nie powieść. Dodatkowo sprawdź, czy system docelowy rzeczywiście akceptuje TLS na skonfigurowanym porcie.

Jeśli dostawca SIEM nie obsługuje bezpośrednio Secure log transmission, nie należy próbować ratować parsera losowymi formatami. Lepiej mieć obsługiwany lokalny kolektor, inny projekt transportu lub jasną decyzję, która trasa wewnętrzna pozostanie niezaszyfrowana.

Sygnatury czasowe są nieprawidłowe

Sprawdź NTP na zaporze, strefę czasową w SIEM i logikę parsera. Nieprawidłowe czasy powodują, że korelacja z punktem końcowym, serwerem lub dziennikami tożsamości jest niewiarygodna.

Za dużo kłód lub za dużo hałasu

Nie dezaktywuj wszystkiego od razu. Najpierw sprawdź, które typy dzienników są naprawdę potrzebne, które reguły rejestrują niepotrzebne i czy pomijanie dzienników ma sens. Następnie zmniejsz konkretnie.

Lista kontrolna

• Serwer Syslog lub SIEM jest osiągalny.
• Naprawiono transport, port i szyfrowanie.
• W przypadku TLS: sprawdzana jest nazwa FQDN, certyfikat, łańcuch zaufania i odnowienie.
• Format odpowiada parserowi SIEM.
• Strategia obiektu jest udokumentowana.
• Odpowiednie typy logów są aktywowane pod System services > Log settings.
• Ważne reguły zapory sieciowej mają aktywną funkcję Logowanie ruchu zapory.
• Reguły inspekcji SSL/TLS generują w razie potrzeby własne logi.
• Usuwanie kłód jest świadomie oceniane i dokumentowane.
• Typy dopasowania odpowiedzi na aktywne zagrożenia odpowiadają przypadkom użycia SIEM.
• Wyjaśniono ochronę danych, okres dostępu i okres ich przechowywania.
• Zapora ogniowa pilota, zdarzenia testowe i parser SIEM zostały sprawdzone.
• Zdarzenia testowe docierają do systemu docelowego.
• Pola takie jak nazwa hosta, device_name, źródło, miejsce docelowe, akcja i Rule ID są rozpoznawane poprawnie.
• Ważne pola parsera, takie jak log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity i status, są osobno wyszukiwalne.
• Scenariusz przywracania lub wymiany sprzętu HA jest zawarty w modelu mapowania SIEM, jeśli jest to wymagane.
• Znacznik czasu i strefa czasowa są prawidłowe.
• Monitorowanie wykrywa, kiedy nie napływają już żadne dzienniki.
• Funkcja parsera jest sprawdzana po aktualizacji oprogramowania sprzętowego.

Często zadawane pytania