Sophos Firewall: sprawdzanie miejsca i raportów

Jeśli Sophos Firewall ostrzega o małej ilości miejsca na dysku, nie powinieneś od razu usuwać plików ani wyłączać raportów. Najpierw należy ustalić, której partycji dotyczy problem, czy przyczyną są lokalne raporty, dzienniki, kolejki poczty, kwarantanna, pliki pomocnicze czy też zbyt mały wirtualny dysk twardy.

W artykule wyjaśniono, jak sprawdzić stan przechowywania na Sophos Firewall, zarządzać raportami lokalnymi w kontrolowany sposób i wyłączać raportowanie na urządzeniu tylko wtedy, gdy zrozumiałe są konsekwencje. W przypadku długoterminowego przechowywania dzienników często lepszym dodatkiem jest Centralne raportowanie zapory sieciowej, ponieważ nie polega się wyłącznie na danych z raportów lokalnych na urządzeniu.

⚠️ Ważne: usunięcie raportów lub dezaktywacja raportów wbudowanych może bezpowrotnie usunąć raporty lokalne i dane dziennika. Przed podjęciem takich kroków należy sprawdzić, czy wymagane dane są eksportowane, przechowywane centralnie lub nie są już potrzebne do celów wsparcia i audytu.

Kiedy przestrzeń dyskowa staje się krytyczna

Problemy z pamięcią masową nie zawsze pojawiają się od razu. Typowe powiadomienia to:

• E-mail z ostrzeżeniem lub powiadomienie z Centrum sterowania o dużym zużyciu pamięci.
• Raporty ładują się powoli, pozostają puste lub nie pokazują aktualnych danych.
• Lokalne pliki dziennika szybko rosną.
• Usługi raportowe lub bazy danych generują błędy.
• Aktualizacja oprogramowania sprzętowego lub instalacja poprawek zgłasza niewystarczającą ilość wolnej pamięci.
• Wirtualna zapora została wdrożona przy użyciu zbyt małego dysku.
• Ochrona poczty, kwarantanna lub duży ruch w sieci/aplikacjach generują dużo danych lokalnych.

Jeśli w tym samym czasie wystąpią błędy we/wy, nietypowe ponowne uruchomienie lub problemy z bazą danych, należy zwolnić nie tylko miejsce w pamięci. Następnie możesz także sprawdzić kondycję dysku SSD za pośrednictwem SMART oraz odpowiednie usługi i dzienniki.

Przy Reports istnieje ważny próg: domyślnie firewall ostrzega przy 70 procentach użycia odpowiedniej partycji. Od 80 procent generowanie Reports zatrzymuje się. Jeśli reporting zatrzyma się z tego powodu, nie wystarczy zejść tuż poniżej 80 procent; użycie musi ponownie spaść poniżej progu ostrzegawczego, aby Reports były znów generowane niezawodnie.

Przy bardzo małych appliances trzeba dodatkowo sprawdzić, czy lokalne Reports są w ogóle obsługiwane. Sophos wskazuje XGS 87/87w i XGS 88/88w jako modele bez On-Appliance Reporting. W takich środowiskach centralne przechowywanie przez Sophos Central lub Syslog nie jest tylko wygodą, ale elementem projektu.

Co zajmuje miejsce na firewallu

Wiele lokalnych danych operacyjnych znajduje się w obszarze /var. Firewall zapisuje tam między innymi Reports, Event Logs, Troubleshooting Logs i dane kolejnych komponentów. Poszczególne obszary mają własne limity zależnie od modelu appliance i funkcji. Mały firewall w oddziale nie zachowuje się więc jak duża appliance z większą lokalną pojemnością.

Ważne jest rozróżnienie:

• Reports: raporty nie są już poprawnie zapisywane albo trzeba je skrócić lub usunąć. Ryzykiem jest krótsza lokalna historia i brakujące analizy.
• Event Logs: starsze logi są usuwane, nowe zdarzenia mogą być nadal zapisywane. Historyczna analiza staje się przez to krótsza.
• Troubleshooting Logs: starsze skompresowane pliki logów są usuwane. Dla analiz supportowych może przez to zabraknąć ważnego okna czasowego.
• E-mail quarantine: starsze wiadomości z kwarantanny mogą zostać usunięte. Cierpi na tym odtwarzalność procesu i zwalnianie wiadomości.
• Pliki tymczasowe lub ręcznie skopiowane: takie pliki mogą niepotrzebnie blokować miejsce. Przyczyna pozostaje ukryta, jeśli usuwa się tylko raporty.

Wykres użycia dysku w WebAdmin pomaga w pierwszej ocenie. Sygnatury, dane konfiguracyjne, Reports i pamięć tymczasowa są tam pokazane oddzielnie. Nie zastępuje to szczegółowej analizy, ale pokazuje, czy rzucają się w oczy raczej Reports, dane tymczasowe czy inne obszary.

Najważniejszą pułapką jest mieszanie Reports i logów. Retencja Reports w Reports > Show Reports settings > Data management dotyczy Reports. Event Logs dla Log Viewer, Sophos Central i Syslog są natomiast sterowane w System services > Log settings. Jeśli skraca się tylko retencję Reports, lokalne Event Logs nie zmniejszają się automatycznie.

Po upgrades ważny jest jeszcze jeden punkt: od SFOS 21.0 firewall może traktować Reports sprzed i po upgrade w oddzielnych bazach raportów. Podczas analizy dnia upgrade może więc pojawić się wybór między danymi sprzed i po migracji. Jeśli po upgrade nastąpi rollback do starszego firmware, Reports wygenerowane od czasu upgrade mogą zostać utracone. Przed pracami firmware istotne lokalne Reports powinny więc zostać wyeksportowane albo być dostępne centralnie.

Sprawdź miejsce w Device Console

Aby uzyskać szybki przegląd, możesz sprawdzić wykorzystaną pamięć w Konsoli urządzenia. Polecenie pokazuje odpowiednie obszary pamięci Sophos Firewall:

system diagnostics show disk

Konsola urządzenia jest przeznaczona dla poleceń specyficznych dla Sophos. Jeśli trzeba przygotować dostęp przez SSH, pomocne jest Sophos Firewall połączenie przez SSH. Opisuje również, dlaczego SSH powinno być dozwolone tylko z godnych zaufania sieci administracyjnych.

Sprawdź miejsce w Advanced Shell

W Advanced Shell możesz przyjrzeć się bliżej systemom plików. To polecenie pokazuje rozmiar, zajętą ​​pamięć, wolną pamięć i procentowe wykorzystanie:

df -hkm

Jeśli nie jest jasne, czy pełny wynik jest zbyt szeroki, można celowo sprawdzić /var, ponieważ znajduje się tam wiele lokalnych danych operacyjnych:

df -h /var

Polecenie służy wyłącznie do odczytu. Plików w katalogach systemowych nie należy usuwać ręcznie tylko dlatego, że partycja wygląda na zapełnioną. Najpierw należy zawęzić przyczynę.

Jeśli /var rzuca się w oczy, należy najpierw sprawdzić przewidziane obszary Sophos zamiast losowo usuwać katalogi. Do ogólnej oceny szczególnie istotne są Reports, Event Logs i Troubleshooting Logs. Dodatkowo należy sprawdzić, czy Packet Capture, Debug-Logging, pliki supportowe albo ręcznie skopiowane pliki zajmują miejsce.

Do trzech typowych bloków miejsca Sophos podaje te polecenia odczytu w Advanced Shell:

du -kh reportdb_16
du -kh eventlogs
du -kh tslog

Te polecenia służą do oceny. Nie zastępują wspieranego czyszczenia przez WebAdmin, Device Console ani przewidzianych funkcji diagnostycznych.

Ogranicz przyczynę

Pełny dysk może mieć kilka przyczyn. Właściwy następny krok zależy od tego, jakie dane rosną.

• Reports zajmują dużo miejsca: sprawdzić retencję pod Reports > Show Reports settings > Data management, wyeksportować raporty albo użyć Central Reporting.
• Lokalne logi szybko rosną: sprawdzić Log settings, Debug-Logging i dotknięte usługi.
• Troubleshooting Logs szybko rosną: sprawdzić Debug-Logging, aktywną analizę supportową albo powtarzające się błędy usług.
• /var jest wyraźnie pełny: sprawdzić Reports, logi, bazę danych, pliki supportowe albo mail queue.
• Wykres dysku pokazuje dużo danych tymczasowych: sprawdzić działające captures, pliki supportowe albo procesy tymczasowe.
• E-mail quarantine albo mail spool rośnie: sprawdzić Email > Quarantine settings i Email > Mail spool. Wiszące wiadomości należy skontrolować, ponownie dostarczyć w kontrolowany sposób albo usunąć.
• Firewall wirtualny jest zbyt ciasno zwymiarowany: sprawdzić rozmiar dysku i wymagania platformy w hypervisorze.
• Przed firmware upgrade pojawia się ostrzeżenie o miejscu: nie rozpoczynać upgrade na ślepo, tylko najpierw wykonać SFOS 22 Upgrade Check.
• Dotknięty jest HA-Cluster: sprawdzić oba nody oddzielnie, ponieważ lokalne logi i raporty nie muszą być identyczne.

Jeśli występują aktywne błędy, najpierw należy zapisać logi, gdy błąd jest świeży. Artykuł Sophos Firewall Tworzenie kopii zapasowych logów do celów wsparcia i analizy opisuje sposób eksportowania danych dziennika lokalnego.

Jeśli lokalne miejsce zajmują Event Logs, retencja Reports nie jest właściwym narzędziem. W takim przypadku należy sprawdzić w System services > Log settings, które moduły są zapisywane lokalnie, wysyłane do Sophos Central albo przekazywane do Syslog. Log Suppression może pomóc ograniczyć niepotrzebne powtórzenia. Nie powinny jednak zniknąć zdarzenia istotne dla bezpieczeństwa, które później będą potrzebne do Incident Response, supportu albo compliance.

Nie usuwaj ręcznie w systemie plików

Nawet jeśli Advanced Shell pokazuje wolne miejsce i katalogi, nie należy usuwać plików bezpośrednio z /var, /log albo katalogów baz danych. Ręczne usuwanie może uszkodzić raporty, usługi, bazy danych lub analizy supportowe i utrudnić późniejsze ustalenie przyczyny.

Lepszy proces:

• Stan przechowywania dokumentów i partycja, której dotyczy problem.
• Zapisz odpowiednie logi lub CTR, jeśli prawdopodobne jest zgłoszenie się do pomocy technicznej.
• Sprawdź zachowanie raportu poprzez WebAdmin.
• Puść raporty za pośrednictwem zamierzonego punktu konsoli tylko wtedy, gdy jest jasne, że można pominąć dane lokalne.
• Jeśli zużycie nadal rośnie, sprawdź przyczynę: rejestrowanie debugowania, kolejka poczty, kwarantanna, baza danych, dysk wirtualny lub niezwykle duży ruch lokalny.

Jeśli nie jest jasne, które dane zajmują miejsce, nie należy pracować z rm. Bezpieczniej jest zabezpieczyć logi i włączyć support albo Avanet z aktualnym stanem.

Dla Troubleshooting Logs istnieją osobne polecenia Device Console do purgingu. Nie zastępują one analizy przyczyny i powinny być używane dopiero po zabezpieczeniu potrzebnych logów. W uproszczeniu system diagnostics purge-old-logs usuwa starsze skompresowane logi, a system diagnostics purge-all-logs usuwa wszystkie Troubleshooting Logs. Dla pojedynczych subsystemów istnieją warianty szczegółowe. W razie wątpliwości ukierunkowany export w Diagnostics > Tools jest czystszy niż ogólny purge.

Dostosuj przechowywanie raportów w WebAdmin

Jeśli przyczyną są raporty lokalne, należy najpierw sprawdzić okres przechowywania. W wielu środowiskach tradycyjnie sporządzano raporty on-box, choć obecnie faktyczna ocena przeprowadzana jest centralnie.

Ścieżka Sophos dla lokalnej retencji Reports to:

Reports > Show Reports settings > Data management

Tam można dopasować czas przechowywania dla poszczególnych modułów raportów i zapisać przez Apply. Zmiana działa na Reports, nie na Event Logs. Sophos wskazuje też, że zmiany retencji Reports zaczynają obowiązywać dopiero o 00:00.

Przydatne pytania przed dokonaniem zmiany:

• Czy raporty lokalne naprawdę są nadal oceniane?
• Czy istnieje już centralne raportowanie, syslog lub SIEM?
• Jak długo muszą być przechowywane wewnętrznie dane rejestrów i raportów?
• Czy istnieją jakieś wymagania dotyczące zgodności lub wsparcia?
• Czy krótsze przechowywanie lokalne jest wystarczające, gdy aktywna jest pamięć centralna?

Jeżeli w Sophos Central potrzebne są logi i raporty, warto także sprawdzić, jakie typy logów wysyłane są do Centrali w zakładce Usługi systemowe > Ustawienia logów. Aktywację opisano w Aktywuj raportowanie centralnej zapory ogniowej.

Usuwaj raporty w sposób kontrolowany

Jeśli usługi nie działają już poprawnie z powodu zapełnienia pamięci, konieczne może okazać się ręczne czyszczenie raportów. Powinien to być jednak kontrolowany sposób odzyskiwania, a nie normalny proces operacyjny.

Sprawdź wcześniej:

• dostępna jest kopia zapasowa bieżącej konfiguracji
• wymagane raporty wyeksportowane lub dostępne centralnie
• udokumentowane okresy, których dotyczy problem
• Zrozumiały powód zwiększenia pamięci
• Przygotowano okno konserwacji lub przypadek wsparcia, jeśli zapora sieciowa jest już niestabilna

Pierwszą drogą powinien być WebAdmin:

Reports > Show Reports settings > Manual purge

Dzięki temu można usuwać Reports celowo według modułu i okresu. Ten proces może być wolny, ponieważ firewall świadomie wykonuje purge Reports w kontrolowany sposób, aby oszczędzać zasoby systemowe.

Jeśli to nie wystarcza albo firewall jest już w stanie recovery, istnieje punkt konsoli:

5. Device Management > 4. Flush Device Reports

Po usunięciu nie należy po prostu wracać do codziennych czynności. Ważne jest, aby sprawdzić, czy rzeczywiście zwiększa się ilość wolnej pamięci i czy raporty, Log Viewer, raportowanie centralne i powiązane usługi znów działają prawidłowo.

Flush Device Reports usuwa Reports zapisane na firewallu i restartuje firewall. W tym czasie urządzenie jest niedostępne przez sieć przez około dziesięć minut. Dlatego ten krok należy wykonywać w oknie serwisowym albo w udokumentowanym procesie recovery.

Jeśli pełny dysk już wpływa na usługi firewalla, przed usunięciem trzeba wiedzieć, których danych później zabraknie. Lokalne Reports są często użyteczne do change reviews, analizy użytkowników, odtwarzalności security albo pytań supportowych. Kto je usuwa, powinien mieć krótką notatkę z zakresem czasu, powodem i dostępnym źródłem zastępczym, na przykład Central Reporting albo Syslog.

Sprawdź lub dezaktywuj raporty On-Box

Raporty On-Box zapisują raporty lokalnie na zaporze. Jest to praktyczne, ale może powodować zużycie pamięci w przypadku małych urządzeń, dużego ruchu lub długiego przechowywania.

Możesz sprawdzić status w konsoli urządzenia:

show on-box-reports

To polecenie nie odpowiada na to samo pytanie co system diagnostics show disk: show on-box-reports pokazuje, czy lokalne raporty są zasadniczo aktywne, natomiast system diagnostics show disk pokazuje aktualne użycie pamięci przez poszczególne obszary. Do czystej diagnozy zwykle potrzebne są oba spojrzenia.

Jeśli raporty lokalne nie są potrzebne i dostępna jest inna pamięć, możesz dezaktywować raporty wbudowane:

set on-box-reports off

Należy to po prostu uświadomić. Raporty są ważne dla analiz, wsparcia i operacji. W wielu środowiskach produkcyjnych lepiej jest ograniczyć pamięć lokalną i równolegle korzystać z centralnego raportowania, syslog lub SIEM. Jeśli wymagane jest dłuższe przechowywanie centralne, możliwą opcją jest Sophos Central Zaawansowane raportowanie zapory ogniowej.

Ważne: On-Box Reports można włączyć albo wyłączyć tylko całościowo, nie selektywnie per moduł. Jeśli tylko pojedyncze obszary raportów zajmują dużo miejsca, krótsza retencja albo celowe purging jest zwykle lepsze niż całkowite wyłączenie On-Box Reporting.

Jeśli On-Box Reports zostaną wyłączone, potem należy sprawdzić nie tylko miejsce. Zmieniają się też procesy wewnętrzne: lokalne widoki Reports, zaplanowane Reports, analizy bezpieczeństwa i szybkie analizy ad hoc na firewallu mogą zniknąć albo stać się mniej użyteczne. Dlatego ten krok jest decyzją operacyjną, a nie spontanicznym czyszczeniem miejsca.

Klasyfikacja progów ostrzegawczych i alertów

Sophos Firewall może generować alerty w Control Center i Event Logs przy wysokim użyciu /var. Próg ostrzegawczy można sterować w Device Console przez set var-partition-usage watermark. To jednak nie jest naprawa miejsca. Niższy lub wyższy próg zmienia tylko moment pojawienia się ostrzeżenia, a nie przyczynę zużycia miejsca.

Dozwolony zakres wynosi od 50 do 75 procent, standardowo 70 procent. Reporting zatrzymuje się przy 80 procentach i ten stop nie jest właściwą granicą operacyjną, lecz już stanem błędu. Wyższy próg ostrzegawczy nie czyni firewalla stabilniejszym, lecz skraca czas reakcji.

Dla operacji zwykle sensowniejsze jest:

• aktywować powiadomienia e-mail albo SNMP dla ostrzeżeń o miejscu,
• nie odkładać ostrzeżeń o miejscu do kolejnego okna serwisowego,
• przy powtarzających się ostrzeżeniach dopasować retencję, Debug-Logging i lokalne użycie raportów,
• świadomie sprawdzać wolne miejsce przed firmware upgrades.

Jeśli użycie wyraźnie rośnie albo Reports już się zatrzymują, najpierw trzeba zwolnić miejsce i wyjaśnić przyczynę. Zmieniony próg ostrzeżeń nie może służyć do ukrywania realnego problemu pojemności.

Zwróć uwagę na wirtualne zapory ogniowe

W przypadku wirtualnych Sophos Firewall przyczyna nie zawsze leży w raportach lub dziennikach. Czasami urządzenie wirtualne zostało wdrożone ze zbyt małą ilością dysku lub rozrastało się przez kilka lat bez ponownej oceny wymagań platformy.

W środowiskach wirtualnych należy także sprawdzić:

• Rozmiar dysku wirtualnego.
• Wolne miejsce w magazynie danych.
• Migawki, zadania tworzenia kopii zapasowych i opóźnienia przechowywania.
• Monitorowanie hypervisora.
• Czy wersja zapory określa dodatkowe wymagania dotyczące pamięci.
• Czy wirtualny dysk można rozszerzyć online, czy czystszy jest reimage z restore.

Jeśli dysk jest zdecydowanie za mały, usunięcie raportów przyniesie jedynie krótkotrwałą ulgę. Należy wówczas odpowiednio dostosować platformę wirtualną i zabezpieczyć ją kopią zapasową, oknem konserwacji i planem przywracania.

Przed SFOS 22 ten punkt jest szczególnie ważny: jeśli firewall pokazuje ostrzeżenie o miejscu albo upgrade blocker dotyczący wirtualnego dysku, najpierw należy przejść SFOS 22 Upgrade Check. Tam podlinkowane są oficjalne wskazówki Sophos dotyczące wirtualnego dysku. Rozszerzenie należy zaplanować w oknie serwisowym z backupem, sprawdzonym storage hypervisora i późniejszą walidacją partycji.

Przy hardware appliances normalną drogą nie jest natomiast rozszerzenie dysku. Tam należy sprawdzić zużycie miejsca, Reports, logi, kwarantannę i stan SSD oraz przy podejrzeniu hardware przygotować support albo proces RMA.

Lista kontrolna

Sprawdź natychmiast

• Udokumentowano komunikat ostrzegawczy, czas i zaporę, której dotyczy problem.
• system diagnostics show disk wykonane w Device Console.
• df -hkm sprawdzone w Advanced Shell.
• Zanotowano rzucającą się w oczy partycję.
• Sprawdzono Disk-Usage-Graph w WebAdmin do ogólnej klasyfikacji.
• Raporty, dzienniki, kolejka poczty, kwarantanna i dysk wirtualny zostały ocenione jako możliwe przyczyny.
• Packet Capture i Debug-Logging sprawdzono jako krótkoterminowe źródła zużycia miejsca.

Przed usunięciem lub dezaktywacją

• Kopia zapasowa wymaganych raportów i dzienników.
• Sprawdzono centralne raportowanie, syslog lub inną centralną pamięć masową.
• Dostępna jest ścieżka tworzenia kopii zapasowych i odzyskiwania.
• Okno konserwacji zdefiniowane, gdy ma to wpływ na usługi produkcyjne.
• W HA oba węzły sprawdzane oddzielnie.
• Zakres czasu i powód czyszczenia raportów udokumentowane.

Po czyszczeniu

• Ponownie sprawdzono wolną pamięć.
• Raporty i Log Viewer przetestowane.
• Central Reporting lub Syslog sprawdzone pod kątem aktualnych danych.
• Udokumentowana przyczyna wzrostu pamięci.
• Dostosowano okres przechowywania, ustawienia dziennika i proces przeglądu.
• Sprawdzono powiadomienia dla przyszłych ostrzeżeń o miejscu.

Często zadawane pytania