Sprawdzanie zmian konfiguracji Sophos Firewall w Audit Trail

Od SFOS 22 funkcja Configuration Audit pozwala ustalić, kto i kiedy zmienił obsługiwaną konfigurację oraz jakie były wartości przed i po zmianie. To właściwy punkt wyjścia, gdy po zmianie reguła zapory, obiekt hosta lub interfejs wygląda inaczej niż oczekiwano.

Najszybszy sposób postępowania: sprawdzić status w Device Console, pobrać configuration-audit.log lub przeszukać go w Advanced Shell, porównać zmianę z ticketem i przedziałem czasu, a następnie osobno przetestować jej działanie.

⚠️ Audit Trail pokazuje zarejestrowaną zmianę. Nie dowodzi automatycznie, że została ona zatwierdzona, była merytorycznie poprawna lub pomyślnie przetestowana, i nie zastępuje kopii zapasowej ani dokumentacji zmian.

Sprawdzanie Configuration Audit w czterech krokach

1. Sprawdzenie statusu w Device Console

Configuration Audit jest domyślnie włączony. Polecenia wykonuje się w Device Console, a nie w Advanced Shell.

system configuration-audit show

Jeśli funkcja jest wyłączona:

system configuration-audit enable

Wyłączenie jest technicznie możliwe, ale w środowisku produkcyjnym powinno mieć uzasadnienie i ograniczony czas:

system configuration-audit disable

⚠️ Nie należy wyłączać Audit Logging tylko dlatego, że plik jest duży lub trudny do odczytania. Po awarii wpisy te mogą stanowić kluczowy dowód wprowadzonych zmian.

2. Pobranie pliku logu w WebAdmin

Plik nazywa się configuration-audit.log. W WebAdmin znajduje się pod ścieżką:

Diagnostics > Tools > Troubleshooting logs

Do ukierunkowanej analizy należy wybrać i pobrać pojedynczy plik. Consolidated troubleshooting report (CTR) jest przydatny, gdy Sophos Support potrzebuje również stanu systemu i innych logów; niektóre logi podsystemów usług w CTR mogą jednak podlegać skonfigurowanemu limitowi wierszy.

3. Przeszukanie pliku w Advanced Shell

Po zalogowaniu przez SSH wybrać 5. Device Management, a następnie 3. Advanced Shell. Nazwę obiektu można wyszukać na przykład tak:

grep -i 'LAN_to_WAN' /log/configuration-audit.log

LAN_to_WAN należy zastąpić rzeczywistą nazwą reguły, hosta lub interfejsu. Nowe wpisy można śledzić na żywo:

tail -f /log/configuration-audit.log

Podgląd na żywo kończy się skrótem Ctrl+C. Do spokojnego przeglądania stronami służy less /log/configuration-audit.log. Dane XML mogą być długie; do zgłoszenia pomocy technicznej należy zabezpieczyć tylko istotny fragment wraz ze znacznikiem czasu.

4. Osobne sprawdzenie zmiany i jej działania

Audit Trail odpowiada najpierw na pytanie: Co zmieniono? Następnie test funkcjonalny musi potwierdzić oczekiwany rezultat. Przy problemach z ruchem należy dodatkowo użyć Log Viewer, Policy Test i Packet Capture. Procedurę opisuje artykuł Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.

Co rejestruje configuration-audit

configuration-audit.log zapisuje obsługiwane zmiany wprowadzone w WebAdmin i CLI w formacie XML. Wpis może zawierać:

• konfigurację przed i po zmianie,
• znacznik czasu,
• tożsamość administratora i źródłowy adres IP,
• używaną konsolę lub metodę dostępu.

Obecny zakres obejmuje w szczególności reguły zapory, IP Hosts lub Hosts and services oraz interfejsy sieciowe. W przypadku interfejsów Sophos wymienia interfejsy fizyczne, wirtualne, bezprzewodowe i Cellular WAN. Nie każda strona konfiguracji oferuje taki sam poziom szczegółowości; dla NAT, routingu, VPN i innych funkcji nie można zakładać kompletnego zakresu Audit Trail.

Description lub ticket wyjaśnia, dlaczego obiekt powinien istnieć. Audit Trail pokazuje, co faktycznie zmieniono w obsługiwanym obiekcie. Pełny dowód wymaga obu informacji.

Czego Audit Trail nie zastępuje

• Analizy ruchu: Dla dozwolonych lub odrzuconych połączeń nadal kluczowe są Log Viewer i Packet Capture.
• Kopii zapasowej i wycofania zmiany: Przed większymi zmianami nadal potrzebne są aktualna kopia zapasowa i droga powrotu.
• Pełnego Change Management: Zatwierdzenie, odpowiedzialność, test i odbiór należą do ticketu lub protokołu okna serwisowego.
• Porównania konfiguracji: Sophos Firewall Config Studio porównuje pełne eksporty konfiguracji, ale nie odczytuje configuration-audit.log.

Wiarygodna analiza zmiany

Znalezienie i udokumentowanie zmiany

Skuteczna procedura:

1. Ustalić czas problemu lub zmiany wraz ze strefą czasową.
2. Określić obiekt, na przykład nazwę reguły, host, interfejs lub VLAN.
3. Przeszukać configuration-audit.log według nazwy obiektu, administratora, adresu IP lub przedziału czasu.
4. Porównać starą i nową wartość.
5. Porównać zmianę z ticketem, oknem serwisowym i odpowiedzialnym administratorem.
6. Zabezpieczyć istotny fragment XML wraz z przedziałem czasu i nazwą obiektu.

W regule zapory mogły zmienić się na przykład źródło, cel, usługa, pozycja reguły lub włączone funkcje ochrony. Konkretną zmianę trzeba odczytać z wpisu; lista nie gwarantuje identycznego przedstawienia każdego pola w każdym buildzie.

Dla Sophos Support szczególnie przydatne są:

• dokładny czas ze strefą czasową,
• obiekt i oczekiwany stan,
• rzeczywisty objaw,
• administrator lub użytkownik Central,
• istotna wartość przed i po zmianie,
• numer ticketu i wykonany test funkcjonalny.

Pełny plik XML może zawierać wewnętrzne adresy IP, nazwy obiektów i dane administratorów. Eksport należy przechowywać z kontrolą dostępu i przed przekazaniem sprawdzić pod kątem zbędnych danych klienta. Więcej informacji zawiera artykuł Zabezpieczanie logów Sophos Firewall dla pomocy technicznej i analizy.

Testowanie działania technicznego

Po zmianie reguły, hosta lub interfejsu nie należy poprzestawać na znalezieniu wpisu:

1. Sprawdzić bieżącą konfigurację w WebAdmin.
2. Wygenerować zdefiniowany ruch testowy.
3. Sprawdzić Rule ID, NAT, trasę i drogę powrotną właściwym narzędziem.
4. W HA dodatkowo sprawdzić role i synchronizację.
5. Udokumentować wynik i ewentualne odchylenia w zmianie.

Przy zmianach NAT, routingu lub VPN configuration-audit.log może pokazać tylko obsługiwane obiekty uczestniczące. Samą funkcję trzeba zweryfikować w jej bieżącej konfiguracji, logach zdarzeń i usług oraz, w razie potrzeby, w Packet Capture.

Klasyfikowanie zmian z Sophos Central

Od SFOS 22.0 MR1 przy zmianach na pojedynczej zaporze przez Sophos Central rejestrowana jest tożsamość użytkownika Central. Sophos potwierdza jej dostępność w Firewall Log Viewer oraz w Sophos Central Logs and Reports. Nie oznacza to automatycznie, że tożsamość Central zawsze znajduje się w configuration-audit.log.

Central Audit Logs znajdują się pod ścieżką:

Reports > General logs > Audit Logs

Widok domyślnie pokazuje 7 dni i może wyświetlić aktywność z maksymalnie 90 dni. Wyszukiwanie jest ukierunkowane na IP address i Modified by. Przy eksporcie obowiązuje:

• CSV/PDF of current view: uwzględnia aktualnie ustawione filtry.
• CSV/PDF of past 90 days: eksportuje ostatnie 90 dni; filtr wyszukiwania obowiązuje, ale wybrany zakres dat nie.

Dla dłuższych okresów dowodowych eksport trzeba regularnie tworzyć i bezpiecznie archiwizować. Central Firewall Reporting nie wydłuża 90-dniowego limitu ogólnych Central Audit Logs.

Kiedy pomaga Task Queue

Task Queue nie jest ogólnym dowodem każdej zmiany z Central. Właściwa ścieżka zależy od typu zadania:

• Bezpośrednio otwarta pojedyncza zapora: sprawdzić Central Audit Logs i Firewall Log Viewer, a dla obsługiwanych obiektów dodatkowo configuration-audit.log.
• Polityka grupy zapór: sprawdzić stan w Sophos Central Firewall Management Task Queue. Jeśli polityka grupowa nie dociera lokalnie, dodatkowo przeanalizować fwcm-updaterd.log.
• MDR Settings lub MDR IOCs z Firewall Configuration API: użyć Firewall Task Queue i w razie potrzeby fwcm-api-executor.log.

Imienne konta użytkowników Central umożliwiają wiarygodne przypisanie działań. Odpowiednie role i MFA chronią dostęp administracyjny. Role opisuje artykuł Role administracyjne Sophos Central dla Firewall Management.

HA i przechowywanie danych

Sophos dokumentuje, że Audit Logs są generowane tylko wtedy, gdy urządzenie ma stan Active. Ocena zależy od trybu HA:

• W Active-Passive zazwyczaj istotne jest urządzenie aktywne w chwili zmiany.
• W Active-Active także Auxiliary Appliance może być aktywne i mieć istotne logi lokalne.
• Po failoverze potrzebne przedziały czasu mogą znajdować się na różnych urządzeniach.

Logi i raporty nie są synchronizowane między węzłami HA. Dla pełnej analizy trzeba udokumentować tryb HA, zmianę ról i przedział czasu oraz osobno pobrać Troubleshooting Logs z właściwych urządzeń. Zarządzanie konfiguracją klastra i synchronizację opisuje artykuł Konfigurowanie High Availability w Sophos Firewall.

Także lokalnie nie ma udokumentowanego stałego okresu przechowywania configuration-audit.log wynoszącego 7, 30 lub 90 dni. Troubleshooting Logs rotują zależnie od komponentu, modelu i przydzielonej przestrzeni; stare rotacje mogą zostać skompresowane, a później usunięte. Dane wymagane do audytu lub zgodności należy zatem odpowiednio wcześnie eksportować.

Lista kontrolna eksploatacji

• Regularnie sprawdzać system configuration-audit show i pozostawić Audit Logging włączony.
• Używać osobistych kont administratorów, odpowiednich ról i MFA dla dostępu administracyjnego. Pełny cykl życia opisuje artykuł Bezpieczna konfiguracja administratorów i profili Sophos Firewall.
• Dokumentować zmiany wraz z ticketem, czasem, obiektem i oczekiwanym testem.
• Przed większymi zmianami przygotować kopię zapasową i plan wycofania.
• Przeszukiwać configuration-audit.log według czasu, obiektu i administratora.
• Porównywać wartości przed i po zmianie z zatwierdzonym zakresem.
• Weryfikować działanie techniczne za pomocą Log Viewer i rzeczywistego ruchu testowego.
• W Central używać Audit Logs, Log Viewer lub właściwej kolejki zależnie od zadania.
• W HA uwzględniać właściwe węzły i czas failoveru.
• Eksportować wymagane dane audytowe przed ich rotacją.

FAQ