Sprawdzanie dzienników śladu audytu Sophos Firewall

Dzienniki śladu audytu pomagają śledzić zmiany konfiguracji na Sophos Firewall. Jest to ważne, gdy po zmianie nagle reguła działa inaczej, interfejs został zmieniony, brakuje obiektu hosta lub podczas audytu pytane jest, kto i kiedy zmienił ustawienie.

Od Sophos Firewall v22 SFOS zapisuje szczegółowe wpisy w configuration-audit.log. Dzienniki pokazują nie tylko, że coś zostało zmienione, ale także wartości przed i po zmianie. Wraz z SFOS 22.0 MR1 poprawiono możliwość śledzenia zmian przez Sophos Central, ponieważ przy zmianach na pojedynczej zaporze rejestrowana jest tożsamość użytkownika Sophos Central.

Który artykuł o logowaniu jest odpowiedni?

Dzienniki śladu audytu to tylko część rozwiązywania problemów. W zależności od pytania, inny punkt wyjścia może być szybszy:

To rozdzielenie zapobiega błędnym oczekiwaniom. Ślad audytu odpowiada na pytania dotyczące zmian. Do analizy przepływu pakietów, NAT, VPN, Web Protection, IPS lub błędów usług nadal potrzebne są Log Viewer, Packet Capture, Service-Logs, Central Reporting lub Syslog.

Kiedy dzienniki śladu audytu 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:

• Zmieniono, przesunięto lub usunięto regułę zapory.
• Dostosowano hosta IP, hosta FQDN lub obiekt sieciowy.
• Interfejs lub konfiguracja VLAN wygląda inaczej niż udokumentowano.
• Po oknie konserwacyjnym nie jest jasne, która zmiana spowodowała problem.
• MSP lub wewnętrzny zespół musi przypisać zmiany do kilku administratorów.
• Dla zgodności, NIS2, ISO 27001 lub wewnętrznych procesów zmian potrzebny jest dowód.

Do normalnej analizy ruchu inne narzędzia pozostają ważniejsze. Jeśli chcesz sprawdzić, która reguła zezwoliła lub odrzuciła połączenie, odpowiednie jest Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture. Dzienniki audytu uzupełniają tę analizę, gdy podejrzewa się, że przyczyną jest zmiana konfiguracji.

Co rejestruje configuration-audit

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

• Konfiguracja przed zmianą.
• Konfiguracja po zmianie.
• Znacznik czasu.
• Tożsamość administratora.
• Adres IP administratora.
• Używana konsola lub metoda dostępu.

Wpisy są zapisywane w configuration-audit.log i zapisane w formacie XML. Dzięki temu są bardzo szczegółowe, ale nie zawsze łatwe do odczytania. Do szybkiej weryfikacji często wystarczy wyszukiwanie po nazwie obiektu, administratorze, adresie IP lub przedziale czasowym. Do większych analiz może być sensowne przeszukanie pliku zewnętrznie lub zaimportowanie go do narzędzia do analizy dzienników.

Aktualny zakres funkcji

Ślad audytu obejmuje obecnie ważne obiekty konfiguracyjne, w szczególności:

• Hosty IP.
• Reguły zapory.
• Interfejsy sieciowe, w tym fizyczne, wirtualne, bezprzewodowe i Cellular-WAN.
• Od SFOS v22 dodatkowo Hosts and services należą do obsługiwanych obszarów.

Jest to już bardzo pomocne dla wielu analiz zmian, ale nie jest to jeszcze pełny system zarządzania zmianami. Dzienniki śladu audytu nie zastępują dokumentacji zmian, biletów ani zasady czterech oczu.

⚠️ Dzienniki audytu dowodzą, że zmiana została zarejestrowana. Dzienniki nie wyjaśniają jednak automatycznie, czy zmiana była poprawna, zatwierdzona lub w pełni przetestowana.

Sprawdzanie statusu configuration-audit

Konfiguracja odbywa się w Device Console, a nie w Advanced Shell.

Status można sprawdzić za pomocą:

system configuration-audit show

Jeśli funkcja jest aktywna, zapora powinna zgłosić, że Configuration Audit jest włączony. Jeśli nie jest jasne, czy pracujesz w odpowiedniej konsoli, pomocne jest rozróżnienie w Rozwiązywanie problemów z Sophos Firewall: Usługi i dzienniki.

Włączanie lub wyłączanie śladu audytu

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

system configuration-audit enable

Wyłączenie jest technicznie możliwe:

system configuration-audit disable

W środowiskach produkcyjnych logowanie audytu powinno zazwyczaj pozostać aktywne. Jeśli zostanie wyłączone z określonego powodu, powinno to być samodokumentowane i ograniczone czasowo.

⚠️ Logowanie audytu nie powinno być wyłączane jako pierwsza opcja tylko dlatego, że plik jest duży lub trudny do odczytania. Zwłaszcza w przypadku zakłóceń po zmianach te dane często są decydującym dowodem.

Pobieranie configuration-audit.log

Plik nazywa się:

configuration-audit.log

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

Diagnostics > Tools > Troubleshooting logs

Tam można pobrać pojedyncze pliki dziennika lub wygenerować Consolidated troubleshooting report (CTR). Do celowej analizy audytu często bardziej praktyczne jest pobranie pojedynczego pliku audytu niż pełnego CTR.

Jeśli dzienniki mają być zbierane do wsparcia lub analizy zewnętrznej, odpowiednie jest dodatkowo Zabezpieczanie dzienników Sophos Firewall do wsparcia i analizy. Do bezpośrednich analiz w powłoce istotne jest Łączenie się z Sophos Firewall przez SSH.

Analiza śladu audytu

Do czystej analizy należy najpierw zawęzić okres czasu.

Praktyczny przebieg:

1. Określenie czasu problemu lub zmiany.
2. Pobranie configuration-audit.log.
3. Wyszukiwanie po administratorze, nazwie obiektu, nazwie reguły, interfejsie lub adresie IP.
4. Porównanie wartości przed i po zmianie.
5. Porównanie zmiany z biletem, oknem konserwacyjnym lub dokumentacją zmian.
6. W przypadku problemów z ruchem dodatkowo sprawdzenie Log Viewer i Packet Capture.

Dzienniki audytu są szczególnie pomocne przy problemach z regułami. Jeśli reguła nagle przestaje działać, Log Viewer pokazuje tylko aktualny stan. Ślad audytu może pokazać, czy krótko przedtem zmieniono źródło, cel, usługę, funkcję bezpieczeństwa, pozycję reguły lub zawartość obiektu.

Prawidłowe użycie śladu audytu w przypadku wsparcia

W przypadkach wsparcia ślad audytu jest najskuteczniejszy, gdy jest połączony z konkretnym przedziałem czasowym i powtarzalnym symptomem. Pełne configuration-audit.log bez kontekstu jest trudne do oceny. Lepsze jest krótkie protokół zmian, które dostarcza najważniejszych punktów odniesienia.

Jeśli zmiana została wywołana przez Sophos Central, należy dodatkowo sprawdzić Central Task Queue. Kolejka zadań pokazuje, czy Central przetworzył zadanie. Ślad audytu pokazuje następnie, co jest możliwe do śledzenia lokalnie na zaporze.

Zmiany przez Sophos Central

SFOS 22.0 MR1 poprawia możliwość śledzenia zmian konfiguracji przez Sophos Central. Jeśli pojedyncza zapora jest konfigurowana przez Sophos Central, tożsamość użytkownika Sophos Central pojawia się w kontekście audytu. Ta informacja jest dostępna w Log Viewer zapory oraz w dziennikach i raportach Sophos Central.

Jest to ważne dla środowisk z wieloma administratorami lub operacjami MSP. Ogólny dostęp Central nie wystarcza do czystego śledzenia. Powinno być jasne:

• Które osoby mają dostęp do Sophos Central?
• Czy administratorzy pracują na własnych kontach użytkowników zamiast na wspólnych loginach?
• Czy MFA jest aktywne w Sophos Central i na zaporze?
• Czy dzienniki Central są przechowywane wystarczająco długo?
• Czy istnieje proces porównywania zmian z Central z biletami?

Połączenie między zaporą a Central jest opisane w artykule Łączenie Sophos Firewall z Sophos Central. Do dłuższego przechowywania dzienników odpowiednie jest Aktywowanie raportowania zapory Central.

Uwzględnianie klastrów HA

W środowiskach HA, według dokumentacji Sophos, dzienniki audytu są generowane tylko na urządzeniu, które jest obecnie aktywne. Przy analizach po przełączeniu awaryjnym należy więc zwrócić uwagę na zmianę ról.

Ważne pytania:

• Która zapora była aktywna w momencie zmiany?
• Czy krótko przedtem lub potem nastąpiło przełączenie awaryjne?
• Czy dzienniki obu urządzeń są istotne?
• Czy zmiana została poprawnie zsynchronizowana z klastrem?

Do działania HA i interpretacji dzienników odpowiednie jest Konfigurowanie wysokiej dostępności Sophos Firewall.

Walidacja po zmianie

Ślad audytu pokazuje, że obiekt został zmieniony. Następnie należy sprawdzić, czy zmiana przyniosła oczekiwany efekt i nie spowodowała skutków ubocznych. Zwłaszcza w przypadku reguł zapory, interfejsów, VPN i obiektów hosta nie należy poprzestawać na dzienniku audytu.

Sugerowany przebieg po krytycznych zmianach:

1. Znalezienie zmiany w śladzie audytu według przedziału czasowego i nazwy obiektu.
2. Porównanie wartości przed/po z biletem lub dokumentacją zmian.
3. Sprawdzenie dotkniętej reguły zapory, reguły NAT, trasy lub interfejsu w WebAdmin.
4. Wygenerowanie konkretnego ruchu testowego.
5. Sprawdzenie Log Viewer, Policy Test i Packet Capture.
6. W przypadku zmian Central dodatkowo sprawdzenie Task Queue i Central Logs.
7. W przypadku klastrów HA sprawdzenie statusu ról i synchronizacji.

Dzięki temu ślad audytu staje się wiarygodnym dowodem, a nie tylko znaleziskiem w dzienniku. Jeśli ślad audytu pokazuje zmianę, ale ruch testowy nadal działa nieprawidłowo, przyczyna często leży w kolejności reguł, NAT, routingu, przypisaniu użytkownika, funkcji bezpieczeństwa lub powrocie.

Ograniczenia i typowe pułapki

Dziennik audytu nie jest kopią zapasową

Ślad audytu pokazuje zmiany, ale nie zastępuje kopii zapasowej konfiguracji. Przed większymi zmianami nadal potrzebna jest pełna kopia zapasowa i plan przywracania. Jest to opisane w artykule Tworzenie lub przywracanie kopii zapasowej Sophos Firewall.

XML jest szczegółowy, ale nie piękny

Plik jest dobry dla maszyn i dokładnych porównań, ale trudny do szybkiego odczytu. Jeśli trzeba porównać wiele zmian, bardziej sensowne może być użycie Sophos Firewall Config Studio lub zewnętrznego narzędzia do porównywania/dzienników.

Nie każda analiza należy do śladu audytu

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

Wspólne konta administratora osłabiają dowód

Jeśli kilka osób używa tego samego konta administratora, ślad audytu jest mniej wiarygodny. Nazwane konta administratorów, role, MFA i czyste konta użytkowników Central są więc częścią modelu operacyjnego, a nie tylko dodatkiem bezpieczeństwa.

Lista kontrolna operacyjna

• Sprawdzenie system configuration-audit show.
• Pozostawienie włączonego logowania audytu.
• Używanie nazwanych kont administratorów zamiast wspólnych loginów.
• Sprawdzenie MFA dla WebAdmin, VPN Portal i Remote Access.
• Dokumentowanie zmian za pomocą biletu lub okna konserwacyjnego.
• Tworzenie kopii zapasowej przed większymi zmianami.
• Po problemach przeszukiwanie configuration-audit.log według przedziału czasowego i nazwy obiektu.
• Porównanie wartości przed/po z oczekiwaną zmianą.
• W przypadku problemów z regułami, NAT lub VPN uzupełnienie Log Viewer i Packet Capture.
• W przypadku klastrów HA uwzględnienie aktywnego węzła i czasu przełączenia awaryjnego.
• Porównanie zmian Central z dziennikami i raportami Sophos Central.

Do MFA na zaporze odpowiednie jest Aktywowanie MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access. Do zarządzania dostępem należy dodatkowo sprawdzić Prawidłowa konfiguracja Device Access.

FAQ