Serwer padł ofiarą ransomware w piątek wieczorem. W poniedziałek firma próbuje ustalić, jak intruz się dostał, co zrobił i czy wyciekły dane klientów. Okazuje się, że logi z serwera plików nadpisały się po trzech dniach, firewall w ogóle nie zapisywał zdarzeń poza domyślnym oknem 24 godzin, a nikt nie wie, kto logował się do panelu administracyjnego w tygodniu poprzedzającym atak. Bez tych danych nie da się rzetelnie zbadać incydentu ani sensownie zgłosić go do CSIRT w wymaganym terminie. NIS2 stawia sprawę wprost: masz obowiązek wykrywać incydenty i nimi zarządzać, a bez logów to zwykłe zgadywanie.
Dlaczego logi to fundament, a nie dodatek
Log to zapis zdarzenia z dokładnym czasem, źródłem i kontekstem: kto się zalogował, jaki proces się uruchomił, który adres IP nawiązał połączenie, jaka reguła firewalla zablokowała ruch. Bez tego śladu każda analiza incydentu sprowadza się do domysłów. Jeśli zajmowałeś się już obsługą incydentów w swojej firmie, wiesz, że pierwsze pytanie zespołu reagującego zawsze brzmi: co dokładnie się wydarzyło i kiedy. Odpowiedź leży w logach, nie w domysłach administratora, który „chyba pamięta”, że coś było nie tak.
Drugi powód jest formalny. NIS2 wymaga zgłoszenia poważnego incydentu w ciągu 24 godzin (wczesne ostrzeżenie) i pełnego raportu w ciągu 72 godzin. Napisanie takiego raportu bez logów jest praktycznie niemożliwe: nie podasz zakresu ataku, wektora wejścia ani listy systemów, które mogły zostać naruszone. Urząd czy CSIRT dostanie ogólnik zamiast konkretów, a to źle świadczy o dojrzałości firmy podczas ewentualnej kontroli.
Co właściwie trzeba zbierać
Nie chodzi o to, żeby logować wszystko bezmyślnie, bo wtedy utoniesz w danych i niczego w nich nie znajdziesz. Chodzi o pokrycie kluczowych źródeł, z których realnie korzystasz przy analizie incydentu:
- Serwery: logowania, próby nieudanych logowań, zmiany uprawnień, uruchamiane usługi, zdarzenia systemowe (Windows Event Log, syslog w Linuksie).
- Firewall / UTM: ruch blokowany i przepuszczony na granicy sieci, alerty IPS/IDS, połączenia VPN.
- Active Directory: logowania i wylogowania, tworzenie i modyfikacja kont, zmiany w grupach uprawnień, zwłaszcza dodawanie kogoś do grupy administratorów domeny.
- Aplikacje krytyczne: ERP, CRM, systemy księgowe, bazy danych. To tam najczęściej leżą dane osobowe i finansowe, więc dostęp do nich trzeba śledzić szczególnie uważnie.
- Urządzenia sieciowe: przełączniki, punkty dostępowe Wi-Fi, koncentratory VPN. Atak często zaczyna się od słabo zabezpieczonego urządzenia brzegowego, o którym nikt nie pamięta.
W małej firmie realistycznie nie obsłużysz analizy dziesiątek źródeł ręcznie, dlatego warto od razu myśleć o centralizacji, a nie o przeglądaniu logów na każdym serwerze osobno.
Jak długo trzymać logi
NIS2 nie podaje jednej konkretnej liczby miesięcy retencji, co bywa mylące, bo firmy szukają gotowego przepisu i go nie znajdują. W praktyce chodzi o zasadę: musisz być w stanie odtworzyć przebieg incydentu, także takiego, który został wykryty z opóźnieniem. Atakujący często siedzą w sieci tygodniami, zanim uruchomią finalny etap ataku, więc logi z ostatnich dwóch tygodni często nie wystarczą. W praktyce większość firm, z którymi pracujemy, trzyma logi krytyczne od kilku do kilkunastu miesięcy, w zależności od rodzaju systemu i ryzyka z nim związanego.
Jest tu jednak druga strona medalu. Logi zawierają dane osobowe: adresy IP, loginy, czasem treści zapytań do aplikacji czy nazwy plików z danymi klientów. To oznacza, że retencja logów musi liczyć się z RODO, a nie tylko z wymogami bezpieczeństwa. Jeśli zastanawiasz się, gdzie NIS2 spotyka się z RODO, retencja logów to jeden z najbardziej praktycznych przykładów tego przecięcia: przechowujesz dane tak długo, jak potrzebujesz do celu bezpieczeństwa, ale nie w nieskończoność „na wszelki wypadek”. Warto to udokumentować w polityce retencji, żeby nie było wątpliwości, dlaczego akurat taki okres, a nie inny.
Wazuh jako centralny dziennik zdarzeń
Wazuh to darmowe, open-source’owe narzędzie klasy SIEM, które zbiera logi z agentów zainstalowanych na serwerach i stacjach, a także z urządzeń bez agenta przez syslog (firewalle, przełączniki, część urządzeń sieciowych). Zamiast logować się na dwadzieścia różnych maszyn, masz jeden panel, w którym widzisz zdarzenia z całej infrastruktury w jednej osi czasu. To jest kluczowe przy badaniu incydentu: widzisz, że o 14:32 ktoś zalogował się na serwer plików, o 14:34 ta sama sesja próbowała połączyć się z kontrolerem domeny, a o 14:41 firewall zablokował nietypowe połączenie wychodzące. Bez centralizacji te trzy zdarzenia leżałyby w trzech różnych systemach i nikt by ich nie powiązał.
Równie ważna jak zbieranie logów jest ich ochrona przed manipulacją. Jeśli atakujący przejmie serwer, jedną z pierwszych rzeczy, jakie zrobi, jest wyczyszczenie lub podmiana logów lokalnych, żeby zatrzeć ślady. Dlatego logi trzeba wysyłać na osobny serwer Wazuh niemal w czasie rzeczywistym, tak żeby nawet po utracie kontroli nad zaatakowaną maszyną kopia zdarzeń była bezpieczna gdzie indziej. Wazuh wspiera dodatkowo mechanizmy integralności plików (File Integrity Monitoring), które wykrywają, jeśli ktoś próbuje modyfikować logi na źródłowym systemie. To ma znaczenie nie tylko techniczne, ale i dowodowe: jeśli logi mają posłużyć jako materiał w zgłoszeniu incydentu albo w postępowaniu, muszą być wiarygodne, a wiarygodność wymaga, żeby nikt po fakcie nie mógł ich cicho poprawić.
Koszt, rotacja i kompresja
Logi potrafią rosnąć szybciej, niż się wydaje, zwłaszcza z firewalla generującego setki wpisów na minutę przy ruchu produkcyjnym. Trzymanie wszystkiego bez planu prowadzi albo do przepełnionego dysku, albo do rachunku za przechowywanie, który nikogo nie ucieszy. Sensowne podejście to warstwowanie: świeże logi, na przykład z ostatnich 30-60 dni, trzymasz w formie łatwo przeszukiwalnej, bo to one najczęściej służą do bieżącej analizy. Starsze dane kompresujesz i przenosisz na tańszy nośnik, zachowując je jednak w formie, którą da się odtworzyć, gdy zajdzie potrzeba. Kompresja logów tekstowych potrafi zmniejszyć ich rozmiar nawet dziesięciokrotnie, więc koszt długiej retencji jest dużo niższy, niż wygląda na pierwszy rzut oka. Rotację warto ustawić automatycznie, żeby nikt nie musiał pamiętać o ręcznym czyszczeniu i żeby uniknąć sytuacji, w której dysk się zapełnia w środku weekendu.
Od czego zacząć w małej firmie
- ✅ Zainstaluj agenta Wazuh na serwerach krytycznych: kontroler domeny, serwer plików, serwer aplikacji, w pierwszej kolejności.
- ✅ Podłącz firewall przez syslog: to często pojedyncza zmiana konfiguracji, a daje ogromny przyrost widoczności.
- ✅ Ustal politykę retencji na piśmie: ile miesięcy, dla jakich systemów, kto ma dostęp do logów i po co, zgodnie z zasadami minimalizacji z RODO.
- ✅ Wydziel serwer logów poza zasięgiem zwykłych administratorów: dostęp do zmiany czy usuwania logów powinien mieć wąski krąg osób.
- 🚩 Nie zaczynaj od logowania wszystkiego: to prosta droga do sytuacji, w której nikt nie ma czasu przejrzeć zalewu danych i realnie nikt tego nie robi.
Zanim wdrożysz centralne logowanie, warto sprawdzić, jakie systemy w ogóle generują dane osobowe i jakie ryzyko z nimi wiążesz, co zwykle wychodzi już na etapie analizy ryzyka. To ona pokazuje, które systemy są na tyle krytyczne, żeby objąć je logowaniem w pierwszej kolejności, zamiast rozpraszać się na wszystko naraz.
Co dalej w cyklu
Samo zbieranie logów to dopiero połowa sukcesu, bo tysiące zdarzeń dziennie nikt nie przejrzy ręcznie. W kolejnym wpisie pokażemy, jak w Wazuh zbudować reguły i alerty, czyli jak z zalewu zdarzeń wyłuskać te powiadomienia, na które naprawdę trzeba zareagować.
W Zjawa.IT wdrażamy centralne logowanie i Wazuh pod klucz, dobierając zakres zbierania danych i okres retencji do realnej skali Twojej firmy, a nie do korporacyjnego wzorca, który u Ciebie się nie sprawdzi. Napisz do nas.