Sophos Firewall Sprawdź dzienniki ścieżki audytu

Dzienniki ścieżki audytu pomagają śledzić zmiany konfiguracji w Sophos Firewall. Jest to ważne, jeśli po zmianie reguła nagle ma inne zastosowanie, interfejs został zmieniony, brakuje obiektu hosta lub audyt pyta, kto i kiedy dostosował które ustawienie.

Od Sophos Firewall v22 SFOS pisze szczegółowe wpisy na ten temat w configuration-audit.log. Logi pokazują nie tylko, że coś zostało zmienione, ale także wartości przed i po zmianie. W SFOS 22.0 MR1 poprawiono także możliwość śledzenia zmian poprzez Sophos Central, ponieważ tożsamość użytkownika Sophos Central jest rejestrowana dla poszczególnych zmian zapory ogniowej.

Rozdzielenie jest ważne: dzienniki Log Viewer i Sophos Central pokazują zdarzenia i działania. configuration-audit.log to szczegółowy dowód techniczny wybranych zmian konfiguracji z wartościami przed i po.

Który artykuł dotyczący rejestrowania pasuje?

Dzienniki ścieżki audytu stanowią jedynie część rozwiązywania problemów. W zależności od pytania inny sposób rozpoczęcia jest szybszy:

• Kto zmienił konfigurację? Właśnie temu poświęcony jest ten artykuł.
• Czy Sophos Central przekazał zmianę do zapory? Najpierw sprawdź Sophos Central Firewall Management Task Queue.
• Która reguła zapory sieciowej dopuszcza lub odrzuca ruch? Przetestuj regułę zapory za pomocą Log Viewer, Test zasad i Packet Capture pasuje do tego.
• Który plik dziennika należy do której usługi? Sophos Firewall Rozwiązywanie problemów: Services i logi to lepszy początek.
• Utworzyć kopię zapasową logów do celów wsparcia lub analizy zewnętrznej? Następnie Sophos Firewall Zapisz logi do celów wsparcia i analizy pomoże.
• Porównać lub udokumentować konfiguracje? Do tego nadaje się Sophos Firewall Config Studio.

To oddzielenie zapobiega fałszywym oczekiwaniom. Ścieżka audytu odpowiada na pytania dotyczące zmian. Do przepływu pakietów, NAT, VPN, ochrony sieci, IPS lub błędów serwisowych nadal potrzebujesz Log Viewer, Packet Capture, dzienników usług, Central Reporting lub Syslog.

Kiedy dzienniki kontroli są pomocne

Dzienniki audytu są szczególnie przydatne, gdy pytanie nie brzmi „dlaczego ruch został zablokowany?” ale „kto lub co zmieniło konfigurację?”

Typowe przypadki:

• Reguła zapory została zmieniona, przeniesiona lub usunięta.
• Dostosowano hosta IP, hosta FQDN lub obiekt sieciowy.
• Interfejs lub konfiguracja VLAN wygląda inaczej niż udokumentowano.
• Po okresie konserwacji nie jest jasne, która zmiana spowodowała problem.
• MSP lub zespół wewnętrzny musi przypisać zmiany wielu administratorom.
• Wymagany jest dowód zgodności, NIS2, ISO 27001 lub procesów zmian wewnętrznych.

W przypadku normalnej analizy ruchu ważniejsze pozostają inne narzędzia. Jeśli trzeba sprawdzić, która reguła dopuściła lub odrzuciła połączenie, pasuje test reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture. Audit Logs uzupełniają tę analizę, gdy podejrzewaną przyczyną jest zmiana konfiguracji.

Co loguje configuration-audit

configuration-audit rejestruje zmiany konfiguracji wprowadzone przez administratorów w WebAdmin lub poprzez CLI. Rejestrowane są między innymi:

• Konfiguracja przed zmianami.
• Konfiguracja po zmianie.
• Znacznik czasu.
• Identyfikacja administratora.
• Adres IP administratora.
• użyto konsoli lub metody dostępu.

Wpisy są przechowywane w configuration-audit.log i zapisywane w formacie XML. Dzięki temu są one bardzo szczegółowe, ale nie zawsze przyjemne w czytaniu. Do szybkiej kontroli wizualnej często wystarczy wyszukiwanie według nazwy obiektu, administratora, adresu IP lub okna czasowego. W przypadku większych analiz sensowne może być przeszukanie pliku na zewnątrz lub przesłanie go do narzędzia do analizy logów.

Normalne Event Logs nadal są istotne. W Log Viewer widać na przykład logowania, zdarzenia systemowe, zdarzenia połączeń i zdarzenia konfiguracji. Dla obsługiwanych obiektów Audit Trail idzie głębiej, ponieważ pokazuje faktyczną zmianę z wartością przed i po zmianie.

Bieżąca funkcjonalność

Na pierwszym etapie rozbudowy ścieżka audytu obejmuje ważne obiekty konfiguracyjne, w szczególności:

• Hosty IP.
• Reguły zapory sieciowej.
• Interfejsy sieciowe, w tym interfejsy fizyczne, wirtualne, bezprzewodowe i komórkowe WAN.
• Hosts and services lub obiekty, o ile są obsługiwane przez aktualną kompilację SFOS.

Jest to już bardzo pomocne w wielu analizach zmian, ale nie stanowi jeszcze pełnego zarządzania zmianami-System. Nie każda strona konfiguracji automatycznie zapewnia ten sam poziom szczegółowości. Dzienniki ścieżki audytu nie zastępują zatem dokumentacji zmian, biletów ani zasady podwójnej kontroli.

⚠️ Dzienniki audytu potwierdzają, że zarejestrowano zmianę. Jednakże dzienniki nie wyjaśniają automatycznie, czy zmiana była poprawna technicznie, zatwierdzona lub w pełni przetestowana.

Sprawdź status audytu konfiguracji

Konfigurację przeprowadza się w Konsoli urządzenia, a nie w Advanced Shell.

Stan jest sprawdzany za pomocą:

system configuration-audit show

Jeśli funkcja jest aktywna, firewall powinien zgłosić, że Configuration Audit jest włączony. Jeśli nie jest jasne, czy pracuje się we właściwej konsoli, pomaga rozróżnienie opisane w artykule Sophos Firewall Troubleshooting: Services i logi.

Włącz lub wyłącz ścieżkę audytu

Rejestrowanie audytu jest domyślnie włączone. Jeśli zostało dezaktywowane, można je ponownie aktywować w Device Console:

system configuration-audit enable

Dezaktywacja jest technicznie możliwa:

system configuration-audit disable

W środowiskach produkcyjnych rejestrowanie audytu powinno zwykle pozostać aktywne. Jeśli funkcja ta jest wyłączona z konkretnego powodu, powinno to zostać udokumentowane samodzielnie i ograniczone czasowo.

⚠️ Rejestrowanie audytu nie powinno być wyłączane na pierwszym etapie tylko dlatego, że plik wydaje się duży lub trudny do odczytania. Dane te stanowią często kluczowy dowód, zwłaszcza w przypadku zakłóceń wynikających ze zmian.

Pobierz plik konfiguracji-audit.log

Plik nazywa się:

configuration-audit.log

Pobieranie odbywa się za pośrednictwem dzienników rozwiązywania problemów. Ścieżka WebAdmin to:

Diagnostics > Tools > Troubleshooting logs

Tam można pobrać pojedyncze pliki dziennika lub utworzyć Consolidated troubleshooting report (CTR). W przypadku ukierunkowanej analizy audytu indywidualne pobranie pliku audytu jest często bardziej praktyczne niż kompletny CTR.

Jeśli Sophos Support potrzebuje pełnego kontekstu systemu, CTR będzie bardziej sensowny, ponieważ zawiera również status systemu i inne logi.

Jeśli mają być gromadzone logi do celów wsparcia lub analizy zewnętrznej, dodatkowo pasuje Sophos Firewall Zapisz logi do celów wsparcia i analizy. Do bezpośredniej analizy powłoki istotne jest połączenie Sophos Firewall poprzez SSH.

Oceń ścieżkę audytu

Aby uzyskać czystą analizę, należy najpierw zawęzić przedział czasu.

Proces praktyczny:

1. Określ czas wystąpienia problemu lub zmiany.
2. Pobierz configuration-audit.log.
3. Szukaj według administratora, nazwy obiektu, nazwy reguły, interfejsu lub adresu IP.
4. Porównaj wartość przed i po zmianie.
5. Dopasuj zmianę do zgłoszenia, okna konserwacji lub dokumentacji zmiany.
6. W przypadku problemów z ruchem sprawdź także Log Viewer i Packet Capture.

Dzienniki audytu są szczególnie przydatne w przypadku problemów z regułami. Jeśli reguła nagle przestanie obowiązywać, Log Viewer pokaże tylko bieżący stan. Ścieżka audytu może wykazać, czy ostatnio zmieniono źródło, cel, usługę, funkcję bezpieczeństwa, pozycję reguły lub treść obiektu.

Używaj poprawnie ścieżki audytu w sprawach pomocy technicznej

W przypadkach pomocy technicznej ścieżka audytu jest najskuteczniejsza w połączeniu z określonym oknem czasowym i powtarzalnym objawem. Kompletny configuration-audit.log bez kontekstu jest trudny do oceny. Lepszy jest krótki protokół zmian, który zawiera najważniejsze kotwice.

Ważne informacje do analizy:

• Dokładny czas ze strefą czasową: Log Viewer, dzienniki centralne i ścieżka audytu mogą być wyraźnie powiązane.
• Dotknięty obiekt: Szybciej można znaleźć nazwę reguły, obiekt hosta, interfejs, VLAN, usługę lub grupę.
• Oczekiwane zachowanie: Wsparcie sprawdza, czy chodzi o ruch, rejestrację, routing, raportowanie czy centralną synchronizację.
• Rzeczywiste zachowanie: Obraz błędu jest oddzielony od samej zmiany konfiguracji.
• Zaangażowany administrator lub użytkownik centralny: Zmiany można uzgodnić z kontekstem osoby, roli lub najemcy.
• Wartość przed/po: Odpowiedni fragment kodu XML jest rozpoznawany szybciej.
• Zgłoszenie lub okno konserwacji: Zatwierdzone zmiany i zmiany spontaniczne są wyraźniej oddzielone.

Jeśli zmiana została wywołana przez Sophos Central, należy również sprawdzić Centralna kolejka zadań. Kolejka zadań pokazuje, czy Centrala przetworzyła zadanie. Centralne dzienniki audytu pokazują kontekst centralny. Ścieżka audytu pokazuje następnie, co można prześledzić lokalnie na zaporze.

Zmiany poprzez Sophos Central

SFOS 22.0 MR1 poprawia identyfikowalność zmian konfiguracji poprzez Sophos Central. Jeśli pojedyncza zapora sieciowa jest skonfigurowana poprzez Sophos Central, w kontekście audytu pojawia się tożsamość użytkownika Sophos Central. Informacje te są dostępne w Log Viewer zapory ogniowej, a także w dziennikach i raportach Sophos Central.

Dodatkowo Sophos Central ma własny obszar dziennika audytu pod adresem Reports > General logs > Audit Logs. Aktywności centralne można filtrować i eksportować według okresu i wyszukiwanego hasła. Domyślnie widok pokazuje ostatnie 7 dni; Aktywności są istotne przez maksymalnie 90 dni przy użyciu filtrów i eksportu. W przypadku zmian w zaporze sieciowej za pośrednictwem systemu centralnego należy zawsze patrzeć na obie strony: dzienniki audytu centralnego pokazują kontekst centralny, zapora sieciowa pokazuje efekt lokalny i szczegółowe zmiany.

Jest to ważne w środowiskach z wieloma administratorami lub operacjami MSP. Ogólny, centralny dostęp nie jest wystarczający do zapewnienia czystej identyfikowalności. Powinno być jasne:

• Kto ma dostęp do Sophos Central?
• Czy administratorzy pracują na własnych kontach użytkowników zamiast na wspólnych loginach?
• Czy MFA jest aktywny w Sophos Central i na zaporze?
• Czy dzienniki centralne są przechowywane przez wystarczający okres czasu?
• Czy istnieje proces dopasowywania zmian z systemu centralnego do zgłoszeń?

Połączenie pomiędzy zaporą sieciową a centralą opisano w artykule Sophos Firewall połącz z Sophos Central. W celu dłuższego przechowywania dzienników odpowiednia jest opcja Aktywuj raportowanie centralnej zapory.

Uwaga Klaster HA

W środowiskach HA logi audytu są tworzone tylko na aktualnie aktywnym urządzeniu. Podczas analizy po failoverze trzeba więc zwrócić uwagę na zmianę roli.

Ważne pytania:

• Która zapora sieciowa była aktywna w momencie zmiany?
• Czy krótko przed lub po nastąpiło przełączenie awaryjne?
• Czy pliki dziennika z obu urządzeń są istotne?
• Czy zmiana została prawidłowo zsynchronizowana z klastrem?

Sophos Firewall Skonfiguruj wysoką dostępność jest odpowiedni do operacji HA i interpretacji logów.

Walidacja po zmianie

Ścieżka audytu pokazuje, że obiekt został zmieniony. Należy jednak wówczas sprawdzić, czy zmiana przynosi pożądany skutek i nie powoduje żadnych skutków ubocznych. Nie powinieneś poprzestawać na dzienniku audytu, zwłaszcza jeśli chodzi o reguły zapory sieciowej, interfejsy, sieci VPN i obiekty hosta.

Rozsądny proces po krytycznych zmianach:

1. Znajdź zmianę w ścieżce audytu według okna czasowego i nazwy obiektu.
2. Porównaj wartość przed/po z dokumentacją biletu lub zmiany.
3. Sprawdź, której dotyczy reguła zapory sieciowej, reguła NAT, trasa lub interfejs w WebAdmin.
4. Wygeneruj konkretny ruch testowy.
5. Sprawdź Log Viewer, Policy Test i Packet Capture.
6. W przypadku zmian przez Central sprawdź także Task Queue, Central Audit Logs i Firewall Log Viewer.
7. Sprawdź stan roli i synchronizację klastrów HA.

Dzięki temu ścieżka audytu staje się wiarygodnym dowodem, a nie tylko znaleziskiem w dzienniku. Jeśli ścieżka audytu wykazuje zmianę, ale ruch testowy nadal przebiega nieprawidłowo, przyczyną jest często kolejność reguł, NAT, routing, mapowanie użytkowników, funkcja zabezpieczeń lub ścieżka powrotna.

Ograniczenia i typowe pułapki

Dziennik audytu nie jest kopią zapasową

Ścieżka audytu pokazuje zmiany, ale nie zastępuje kopii zapasowej konfiguracji. Przed wprowadzeniem większych zmian nadal wymagany jest pełny plan tworzenia kopii zapasowych i przywracania danych. Zostało to opisane w artykule Sophos Firewall Tworzenie lub przywracanie kopii zapasowej.

W przypadku audytów należy nie tylko zapisać cały plik, ale także udokumentować odpowiednią sekcję zawierającą okno czasowe, nazwę obiektu i numer zgłoszenia. W przeciwnym razie informacje tam będą, ale później będą niepotrzebnie trudne do wykorzystania.

XML jest szczegółowy, ale niezbyt ładny

Plik nadaje się do maszyn i precyzyjnych porównań, ale jest trudny do szybkiego czytania. Jeśli trzeba porównać wiele zmian, bardziej przydatne może być Sophos Firewall Config Studio lub zewnętrzne narzędzie diff/log.

Nie każda analiza należy do ścieżki audytu

Jeśli połączenie nie działa, najpierw sprawdź ruch. Dzienniki audytu są istotne, gdy podejrzewa się zmianę jako przyczynę. W przypadku rozwiązywania problemów na żywo Log Viewer, Policy Test, Packet Capture i Service-Logs są często bardziej bezpośrednie.

Współdzielone konta administratorów osłabiają dowód

Gdy wiele osób korzysta z tego samego konta administratora, ścieżka audytu zawiera mniej informacji. Nazwani administratorzy, role, MFA i czyste użytkownicy centralni są zatem częścią modelu operacyjnego, a nie tylko dodatkiem zapewniającym bezpieczeństwo.

Operacyjna lista kontrolna

• Sprawdź system configuration-audit show.
• Pozostaw włączone rejestrowanie inspekcji.
• Używaj nazwanych kont administratorów zamiast wspólnych loginów.
• Sprawdź MFA pod kątem WebAdmin, VPN Portal i dostępu zdalnego.
• Dokumentuj zmiany za pomocą zgłoszenia lub okna serwisowego.
• Utwórz kopię zapasową przed poważnymi zmianami.
• Szukaj problemów configuration-audit.log według okna czasowego i nazwy obiektu.
• Porównaj wartości przed/po z oczekiwaną zmianą.
• W przypadku problemów z regułą NAT lub VPN dodaj Log Viewer i Packet Capture.
• Weź pod uwagę czas aktywnego węzła i przełączania awaryjnego dla klastrów HA.
• Uzgadniaj zmiany z Central z Sophos Central Audit Logs, Task Queue i Firewall Log Viewer.

Dla MFA na zaporze pasuje MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access. Przy dostępie administracyjnym warto również sprawdzić poprawną konfigurację Device Access.

Często zadawane pytania