Realne problemy, które rozwiązuje monitorowanie logów
Monitorowanie logów i alerty bezpieczeństwa nie są celem samym w sobie. Mają pomóc odpowiedzieć na konkretne pytania: kto, kiedy, do czego się dobrał, co się zepsuło i jak daleko zaszedł atakujący. Bez logów te odpowiedzi są wyłącznie domysłami.
Najczęstsze kategorie problemów, przy których logi ratują sytuację:
Ataki i próby włamań – logi logowania (SSH, RDP, VPN, aplikacje webowe), logi firewalli, WAF, serwerów WWW. Dzięki nim widzisz:
skąd przychodzi atak (IP, kraj, AS),
które konta są atakowane (np. konto serwisowe bez MFA),
czy próby zakończyły się sukcesem, czy to tylko „bruteforce w próżni”.
Awarie i błędy konfiguracji – logi usług (systemd, Event Log), aplikacji (np. logi exceptionów), baz danych. Bez nich diagnoza sprowadza się do restartów i zgadywania.
Nadużycia uprawnień i błędy ludzkie – logi zmian konfiguracji, eskalacji uprawnień, dostępu do wrażliwych danych (np. logi baz danych, systemów plików, systemów CRM/ERP).
Przy incydencie bezpieczeństwa kluczowe pytanie brzmi zwykle: czy atakujący miał dostęp do danych X? Jeśli nie zbierasz logów dostępu i zmian, uczciwa odpowiedź brzmi: „nie wiadomo”. To z kolei podbija ryzyko, zakres notyfikacji i koszt obsługi incydentu.
Logi „dla administratora” kontra logi „dla bezpieczeństwa”
Te dwa światy często są mylone, a oczekiwania wobec logów stają się nierealne. Logi „dla admina” najczęściej służą do diagnozy problemów z wydajnością i stabilnością. Logi „dla bezpieczeństwa” mają pokazać, co się dzieje pod kątem dostępu, uprawnień i anomalii.
Przykład typowego rozdźwięku:
Admin włącza logowanie błędów aplikacji (stack trace, kody błędów HTTP, timeouty), bo to pomaga w debugowaniu.
Specjalista bezpieczeństwa potrzebuje logów:
kto się zalogował (user_id, IP, user agent),
do jakiego zasobu miał dostęp (ID klienta, numer zamówienia, numer dokumentu),
co próbował zrobić (akcja: odczyt, modyfikacja, eksport),
czy akcja się powiodła, czy została zablokowana.
Te dwie kategorie logów częściowo się pokrywają, ale nie są tym samym. Popularna rada „logujmy wszystko, bo może się przyda” kończy się tym, że:
dyski się zapychają bez realnej korzyści,
sensowne informacje giną w szumie,
nikt nie ma czasu ich przeglądać, więc i tak niczego nie wykrywasz.
Znacznie lepiej ustalić konkretną listę scenariuszy bezpieczeństwa, które chcesz wykrywać (np. „nieudane logowania do VPN”, „logowanie root z nietypowego kraju”, „eksport dużej liczby rekordów z CRM”) i pod te scenariusze dobrać wymagane logi, zamiast bezrefleksyjnie logować wszystko.
Źródła logów: system, sieć, aplikacje, chmura, SaaS
Żeby sensownie ustawić monitorowanie logów i alerty bezpieczeństwa z użyciem darmowych narzędzi, trzeba wiedzieć, z czego te logi zbierać. Typowe źródła:
Systemy operacyjne:
Linux: logi w /var/log, journald (journalctl), szczególnie auth.log, secure, syslog lub ich odpowiedniki.
bazy danych (PostgreSQL, MySQL/MariaDB, MS SQL, Oracle).
Chmura i SaaS:
logi audytowe z AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs,
logi administracyjne z usług SaaS: Office 365, Google Workspace, narzędzia do zarządzania projektami, HR, finanse.
Jeśli infrastruktura jest mała, łatwo wpaść w pułapkę „monitorujemy tylko serwery, bo to serce systemu”. Tymczasem sensowne incydenty często dotyczą właśnie warstwy SaaS (np. przejęcie konta w systemie do fakturowania) albo endpointów (laptopy pracowników), które nie wysyłają żadnych logów do centralnego systemu.
Gdy logów brakuje: praktyczny przykład skutków
Wyobraźmy sobie incydent: jedno konto użytkownika w systemie CRM zostało przejęte i użyte do masowego podglądu danych klientów. Bez sensownych logów bezpieczeństwa odpowiedź na pytania zarządu będzie bolesna:
„Czy wyciekły tylko dane z konta X, czy również innych klientów?” – brak logów dostępu do rekordów → brak odpowiedzi.
„Ilu klientów obejmuje incydent?” – brak ID rekordu lub brak powiązania użytkownik–akcja → można tylko zgadywać.
„Czy dane były tylko przeglądane, czy również eksportowane?” – brak logowania operacji eksportu → nie wiadomo.
Konsekwencje są praktyczne, nie teoretyczne: szerszy zakres zgłoszenia do regulatora, większa skala powiadamianych klientów, gorsza pozycja negocjacyjna przy roszczeniach. A to wszystko wyłącznie dlatego, że nie został skonfigurowany minimalny sensowny poziom logowania działań użytkowników.
Dlaczego „loguj wszystko” to zła rada w małych zespołach
„Loguj wszystko, bo storage jest tani” brzmi efektownie na prezentacjach. W realnej małej firmie, gdzie administracją zajmuje się jedna osoba, to przepis na chaos:
zbyt dużo danych → brak czasu na analizę,
brak polityki retencji → niespodziewane zapełnienie dysku i awarie,
brak priorytetów → w gąszczu informacji gubi się to, co naprawdę istotne.
Bardziej dojrzałe jest podejście odwrotne: najpierw scenariusze, potem logi. Czyli:
Definiujesz kilka konkretnych zagrożeń, które chcesz wykrywać (np. „logowanie do serwera produkcyjnego poza godzinami pracy”, „nietypowo duża liczba błędnych haseł do VPN”).
Ustalasz, jakie logi i jakie pola są potrzebne, żeby takie zdarzenia wykryć.
Dopiero wtedy włączasz logowanie i konfigurujesz alerty bezpieczeństwa.
Dopiero po opanowaniu tego podstawowego zestawu warto stopniowo rozszerzać zakres logowania – ale zawsze z myślą o tym, po co dane logi mają być użyte.
Podstawy logów bezpieczeństwa – co jest naprawdę istotne
Kluczowe typy logów z perspektywy bezpieczeństwa
Logi systemowe i aplikacyjne można dzielić na setki kategorii, ale pod kątem bezpieczeństwa kluczowych jest kilka:
Uwierzytelnianie i autoryzacja
logowania udane i nieudane (SSH, RDP, VPN, aplikacje webowe),
zmiany haseł, reset hasła, dodawanie lub usuwanie MFA,
dostęp do plików na udziałach sieciowych, systemach DMS.
Ruch sieciowy i próby ataków
połączenia przychodzące na otwarte porty,
bloki/odrzucenia firewalli, IDS/IPS, WAF,
nietypowe natężenie ruchu do/z internetu.
Dopóki te podstawowe kategorie nie są sensownie logowane i monitorowane, bardziej zaawansowane tematy (korelacje, uczenie maszynowe, „darmowe narzędzia SIEM”) nie mają większego sensu.
Jak czytać typowe logi w systemach Linux i Windows
Na Linuxie kluczowe są:
/var/log/auth.log lub /var/log/secure – logi uwierzytelniania: SSH, sudo, su, logowania lokalne.
journald (journalctl) – nowoczesne źródło logów w systemach z systemd; można filtrować po jednostce, priorytecie, dacie.
Przykładowy wpis w auth.log (skrócony):
Jan 10 12:34:56 web01 sshd[12345]: Failed password for root from 203.0.113.10 port 51234 ssh2
Już z tak prostego wpisu masz:
czas zdarzenia,
host (web01),
proces (sshd),
użytkownika (root),
adres zdalny (203.0.113.10),
rodzaj zdarzenia (nieudane hasło).
Na Windowsie najważniejszy jest dziennik Security (ID zdarzeń związanych z logowaniem, eskalacją uprawnień, zmianami konfiguracji) oraz System i Application. Przykładowe kategorie: logowanie lokalne/logowanie zdalne, blokady konta, błędy usług, nieudane próby dostępu do zasobów.
Żeby później zautomatyzować analizę (np. darmowymi narzędziami SIEM), potrzebujesz rozumieć, które ID zdarzeń odpowiadają konkretnym sytuacjom – np. na kontrolerze domeny znaczenie mają inne eventy niż na zwykłym laptopie z Windows.
Czego zwykle brakuje w domyślnych konfiguracjach logowania
Domyślne ustawienia logowania systemów i aplikacji tworzone są z myślą o wydajności i prostocie, nie o bezpieczeństwie. Typowe braki:
Brak logów audytowych działań użytkowników – aplikacja loguje błędy techniczne, ale nie zapisuje kto otwierał rekordy, jakie filtry stosował, jakie raporty generował.
Niewystarczający poziom szczegółowości – brak adresu IP, user agenta, identyfikatora sesji, ID obiektu (np. klienta), przez co nie da się odtworzyć działań.
Brak logowania zmian konfiguracji – zmiana parametrów bezpieczeństwa, włączenie/wyłączenie MFA, dodanie nowego konta administratora nie zostawia śladu.
Zbyt agresywna rotacja logów lokalnych – logi nadpisują się po kilku dniach i centralny system ich nie zdąży zebrać.
Domyślna konfiguracja jest dobra na start, ale nie powinna być docelową konfiguracją logów bezpieczeństwa. Trzeba świadomie włączyć dodatkowe logowanie tam, gdzie jest to kluczowe dla analizy incydentów.
Mylące założenie: „jak coś się stanie, to się znajdzie w logach”
Często przy inwestycjach w monitorowanie logów open source pojawia się założenie: „zainstalujemy ELK/Wazuh/Graylog i jak będzie incydent, to się doklika”. To z grubsza działa tylko wtedy, gdy:
logi rzeczywiście zawierają to, czego potrzebujesz (czas, użytkownik, akcja, wynik),
retencja jest ustawiona sensownie (np. kilkadziesiąt–kilkaset dni, a nie 7),
dane są znormalizowane, przynajmniej na tyle, żeby dało się je filtrować i agregować.
Jeśli żaden z tych warunków nie jest spełniony, nawet najlepsze narzędzie SIEM i najbardziej efektowne dashboardy nie pomogą. Monitorowanie logów bezpieczeństwa zaczyna się na poziomie źródła logów, nie na poziomie narzędzia do wizualizacji.
Minimalny zestaw pól, które muszą być w logu
Minimalny zestaw pól, które muszą być w logu (i dlaczego właśnie te)
Lista pól w logach potrafi urosnąć do małej encyklopedii. Przy ograniczonych zasobach rozsądniej jest narzucić sobie twarde minimum i dopiero później je rozbudowywać. W większości przypadków do sensownej analizy incydentów wystarczy, żeby każde istotne zdarzenie zawierało:
czas – najlepiej w jednym formacie (np. ISO 8601, z informacją o strefie czasowej lub w UTC),
źródło logu – nazwa hosta, usługi, aplikacji, urządzenia,
użytkownika lub podmiot – login, ID konta, identyfikator usługi/API,
akcję – co się wydarzyło, w możliwie ustrukturyzowanej formie (np. LOGIN_FAILED, EXPORT_STARTED, ACL_CHANGED),
wynik – sukces/porażka, ew. kod błędu,
kontekst sieciowy – adres IP (źródłowy i/lub docelowy), opcjonalnie port,
kontekst obiektu – ID zasobu, na którym wykonano operację (np. ID klienta, numer dokumentu, nazwa pliku),
identyfikator sesji lub korelacji – cokolwiek, co pozwala powiązać kilka logów w jedną historię.
Jeżeli któregoś z tych elementów brakuje, analiza szybko staje się żmudną łamigłówką. Przykładowo, bez ID obiektu nie da się sprawnie odpowiedzieć na pytanie: „kogo konkretnie dotyczył ten incydent?”. Z kolei brak identyfikatora sesji uniemożliwia łatwe odtworzenie sekwencji działań po zalogowaniu.
Popularna rada „zapisuj wszystko, co się da” kończy się zwykle logami pełnymi hałasu, gdzie kluczowych pól nadal brakuje. Podejście odwrotne – najpierw ustalenie minimalnego schematu, potem dopiero rozbudowa – lepiej się skaluje w małym zespole.
Normalizacja: wspólny język dla różnych źródeł logów
Nowicjusze często zaczynają od wizualizacji, a dopiero później orientują się, że każde źródło logów mówi innym dialektem. Ten sam typ zdarzenia (np. nieudane logowanie) może być opisany zupełnie inaczej w Linuxie, Windowsie, aplikacji SaaS i firewallu. Bez choćby szczątkowej normalizacji reguły detekcji zamieniają się w koszmar utrzymaniowy.
Minimalny poziom normalizacji, który da się wykonać nawet domowymi metodami, to sprowadzenie kluczowych pól do wspólnego schematu, np.:
Nie ma potrzeby implementować pełnego standardu typu ECS czy CEF, jeśli zespół ma dwie osoby. Kluczowe jest to, żeby własny prosty schemat był spójny i konsekwentnie używany. Nawet prymitywny skrypt, który parsuje surowe logi i dokleja kilka wspólnych pól JSON-em, jest lepszy niż dziesięć różnych formatów bez żadnego mapowania.
Wybór darmowego zestawu narzędzi – nie tylko ELK i nie zawsze „SIEM”
Kiedy klasyczne „darmowe SIEM” to zbyt ciężkie rozwiązanie
Wielu administratorów ma odruch: „monitorowanie logów = SIEM, najlepiej darmowy”. Szybko okazuje się jednak, że instalacja rozbudowanego stacka (ELK, OpenSearch, Wazuh, TheHive i podobne kombinacje) wymaga:
osobnych serwerów lub przynajmniej mocnych VM-ek,
opieki nad bazą danych, indeksami i retencją,
konserwacji integracji, które potrafią się „rozsypać” przy aktualizacji.
Jeśli zespół IT liczy jedną czy dwie osoby, a incydentów jest kilka w roku, rozbudowany system SIEM częściej konkuruje o czas z codzienną operacyjką niż realnie pomaga. W takim scenariuszu częściej sprawdza się mniejszy, ale stabilny zestaw narzędzi o ograniczonym zakresie.
Trzy typowe podejścia do darmowego monitorowania logów
Zamiast wskakiwać od razu w najcięższe rozwiązania, można zestawić proste komponenty w zależności od potrzeb. Praktycznie da się wyróżnić trzy bazowe modele:
„Lekki syslog + proste alerty” – dla kilku–kilkunastu hostów,
„Centralny log + przeszukiwanie + kilka dashboardów” – dla większej liczby serwerów i urządzeń,
„Prawie-SIEM” z darmowych klocków – gdy organizacja rośnie, ale budżet jeszcze nie.
1. Lekki syslog + proste alerty
To podejście dobrze działa, gdy:
monitorowanych hostów jest mało (kilka–kilkanaście),
ważniejsze są powiadomienia o anomaliach niż pełna analityka historyczna,
nie ma kogoś, kto będzie codziennie doglądał złożonego systemu.
Przykładowy zestaw:
rsyslog/syslog-ng jako centralny serwer logów dla Linuxa,
NxLog lub Winlogbeat do wysyłania logów z Windows,
swatchdog, prosty logcheck albo własne skrypty bash/python do generowania alertów e-mail/SMS/Slack na podstawie wyrażeń regularnych.
To podejście jest często lekceważone jako „zbyt prymitywne”. W praktyce, jeśli skonfiguruje się kilka konkretnych reguł (np. wykrywanie masowych nieudanych logowań SSH, tworzenie użytkownika root w nietypowej godzinie, restart krytycznych usług), potrafi dać realną wartość przy minimalnym obciążeniu administracyjnym.
2. Centralny log + przeszukiwanie + kilka dashboardów
Tu dochodzi potrzeba przeszukiwania logów z ostatnich tygodni czy miesięcy i budowania prostych raportów. Nie musi to jednak oznaczać pełnego ELK. Alternatywy:
Graylog – wyspecjalizowane narzędzie do logów oparte o Elasticsearch, z gotowym interfejsem, filtrami, strumieniami i podstawowymi alertami. Mniej „do zrobienia” niż surowy ELK.
OpenSearch Dashboards + Filebeat/Winlogbeat – gdy zespół czuje się pewniej w świecie Elastic/OpenSearch, ale nie potrzebuje SIEM-a, tylko centralnego logowania i prostych wizualizacji.
Loki + Promtail + Grafana – dla tych, którzy już używają Grafany. Loki jest „tańszy” w storage niż klasyczny ELK, co przy braku budżetu ma znaczenie.
Tu pojawia się też pokusa budowania zaawansowanych, kolorowych dashboardów. Jeżeli brakuje czasu, rozsądniej jest zacząć od dwóch–trzech praktycznych widoków, np.:
logowania i błędne logowania (po źródle, adresie IP, użytkowniku),
zmiany uprawnień i konfiguracji,
zdarzenia z firewalli (blokady, nietypowy ruch).
Reszta może poczekać. Kluczem jest odpowiedź na pytanie: „co realnie sprawdzam choćby raz w tygodniu?”.
3. „Prawie-SIEM” z darmowych klocków
Kiedy organizacja rośnie, a jednocześnie nie ma środków na komercyjny SIEM, można złożyć coś „pomiędzy” prostym centralnym logowaniem a pełnym systemem klasy enterprise. Najczęstsze przykłady:
Wazuh – open source będący rozwinięciem OSSEC, z agentem, korelacją, regułami, integracjami z chmurą i interfejsem webowym (często uruchamianym na Elastic/OpenSearch).
Security Onion – bardziej pod kątem sieci (IDS/NSM), ale z komponentami do logów i analizy bezpieczeństwa.
TheHive/Cortex jako warstwa „nad logami” do obsługi incydentów, gdy źródła logów są już gdzieś centralnie zbierane.
To rozwiązania, które mają większy sens, gdy:
jest choć jedna osoba z wyraźnym mandatem do roli „bezpieczeństwa/monitorowania”,
liczba źródeł logów jest duża (serwery, stacje, chmura, urządzenia sieciowe, aplikacje),
jest wypracowany minimalny proces reagowania (kto co robi, gdy przychodzi alert).
Bez tego, bardzo rozbudowany, darmowy system zostaje „półką z narzędziami”, do której nikt nie zagląda w dniu powszednim.
Kryteria wyboru: jak zawęzić opcje bez tygodni researchu
Zamiast porównywać dziesiątki projektów open source, lepiej odpowiedzieć na kilka prostych pytań:
Ilu ludzi będzie to obsługiwać i ile czasu mogą na to realnie poświęcić tygodniowo?
Ile źródeł logów chcemy objąć centralnym monitoringiem w ciągu najbliższego roku?
Czy ważniejsza jest dla nas zaawansowana detekcja, czy raczej możliwość szybkiego śledztwa po incydencie?
Czy mamy kompetencje do administrowania bazami typu Elasticsearch/OpenSearch?
Jeżeli odpowiedzi brzmią: „jedna osoba, kilka godzin tygodniowo, kilka serwerów, brak doświadczenia z ELK” – lepiej zacząć od lekkiego sysloga lub Grayloga niż od pełnego Wazuha. W drugą stronę: gdy infrastruktura jest rozproszona, jest dużo stacji roboczych, a firma już miała poważne incydenty – „syslog + grep” zacznie być kulą u nogi.
Źródło: Pexels | Autor: Ilman Muhammad
Architektura prostego systemu monitorowania logów
Elementy składowe: od źródeł po alerty
Nawet najprostszy system monitorowania logów składa się z kilku warstw. Nazwy narzędzi można wymieniać, ale logika pozostaje ta sama:
Źródła logów – systemy, aplikacje, urządzenia, usługi chmurowe,
Transport – agenty, syslog, API chmurowe,
Bufor/kolejka (opcjonalnie) – np. Redis, Kafka, żeby nie gubić logów przy chwilowych problemach,
Magazyn/log storage – baza czasoszeregowa, Elasticsearch/OpenSearch, Loki, a w najprostszym wariancie zwykłe pliki,
Warstwa analizy – wyszukiwarka, dashboardy, raporty,
Warstwa reguł i alertów – mechanizm wysyłania powiadomień, prosty lub bardziej zaawansowany.
W małej firmie częścią tej architektury może być… plik tekstowy i cron. Paradoksalnie, jeśli na jednym serwerze stoi rsyslog, a cron raz na 5 minut odpala skrypt szukający podejrzanych wpisów i wysyłający maila, to formalnie wciąż jest to system monitorowania logów. Tyle że ekstremalnie prosty.
Minimalna architektura dla kilku–kilkunastu hostów
Przykład układu, który da się zbudować w jeden dzień i utrzymać przy małym nakładzie pracy:
Na każdym serwerze Linux:
lokalne logi w journald lub plikach w /var/log,
rsyslog wysyłający wybrane logi (auth, syslog, nginx/apache) na centralny serwer przez UDP lub TCP z TLS.
Na każdej stacji/serwerze Windows:
Winlogbeat lub NxLog wysyłający dziennik Security/System/Application do centralnego serwera (np. Graylog lub serwer syslog z dodatkiem do przyjmowania logów z Windows).
Na centralnym serwerze:
rsyslog/syslog-ng odbierający logi z Linuxów,
Graylog lub Loki+Grafana do indeksowania/przeglądania,
kilka reguł alertów, np. wbudowany mechanizm Grayloga lub prosty skrypt czytający logi z pliku i wysyłający powiadomienia.
Taki układ nie jest „pełnym SIEM-em”, ale pozwala już:
szybko znaleźć, z których adresów IP ktoś masowo atakuje SSH,
sprawdzić historię logowań problematycznego konta w Windows,
udokumentować, że krytyczne usługi padały co noc o tej samej godzinie.
Bezpieczeństwo i niezawodność centralnego serwera logów
Centralny serwer logów jest atrakcyjnym celem – często zawiera informacje o całej infrastrukturze oraz ślady potencjalnych błędów konfiguracyjnych. Dlatego, nawet w najprostszej architekturze, kilka zasad opłaca się wdrożyć od razu:
Odrębny host – nie stawiać centralnego logowania na tym samym serwerze, na którym działa aplikacja produkcyjna.
Ograniczanie zaufania do logów i separacja uprawnień
Logi bezpieczeństwa mają tę przewrotną cechę, że są najbardziej potrzebne właśnie wtedy, gdy atakujący ma już częściową kontrolę nad systemem. To oznacza, że nadmierne zaufanie do nich potrafi być zgubne. Kilka prostych zasad ogranicza pole do manipulacji:
Minimalne uprawnienia do zapisu logów – procesy aplikacji nie powinny mieć dostępu do logów innych usług ani do konfiguracji narzędzi logujących. Typowy błąd: webserwer z możliwością nadpisania własnych plików logów w całości, zamiast dopisywania.
Forward-only z hostów produkcyjnych – na wrażliwych serwerach lepiej traktować logi lokalne jako „cache”, a za źródło prawdy przyjąć egzemplarze przechowywane centralnie. Gdy trzeba robić śledztwo, najpierw sprawdza się centralny magazyn.
Osobne konta administracyjne – osoba mająca pełne prawa do serwerów aplikacyjnych nie powinna mieć jednocześnie możliwości ingerencji w centralny serwer logów. Jeśli ktoś „sprząta po sobie” na produkcji, logi centralne pozostają do weryfikacji.
Ograniczony dostęp interaktywny – przeglądanie logów z centralnego systemu powinno odbywać się przez UI/API, a nie przez ssh na host z Elasticsearch czy bazą. Mniej okazji do przypadkowego usunięcia lub modyfikacji danych.
Popularna rada „logi trzymaj jak najdłużej” ma sens tylko wtedy, gdy są one jednocześnie jak najmniej podatne na modyfikacje. Inaczej przechowuje się przez lata mieszankę prawdy i fikcji, co utrudnia analizę zamiast ją ułatwiać.
Elementy odporności: redundancja i przetrwanie incydentu
Nawet w małych środowiskach opłaca się wprowadzić dwa–trzy proste mechanizmy na wypadek awarii lub ataku szyfrującego:
Oddzielne kopie „zimne” – migawki lub eksport logów (np. do plików gzip na NFS/S3) robione raz dziennie, z dostępem tylko do odczytu dla administracji operacyjnej. Nie chodzi o natychmiastową analitykę, tylko o archiwum śledcze.
Różne klasy storage – np. 7–14 dni na szybkim, drogim indeksie (Elasticsearch/Loki), a starsze dane skompresowane w tanim obiekcie lub archiwalnej bazie. Pozwala to utrzymać „świeżą” warstwę analityczną bez bankructwa na dyskach.
Minimalna redundancja – w najskromniejszym wydaniu: replikacja indeksu lub kopia bazy na inny serwer/VM. Nie musi to być pełne HA, raczej plan na wypadek śmierci pojedynczej maszyny.
Test przywracania – lepiej raz w kwartale przywrócić mały wycinek logów testowo, niż dowiedzieć się w dniu incydentu, że kopie są nieczytelne lub niespójne.
W praktyce większym problemem niż brak „pięknego” klastra bywa to, że nikt nie wie, jak zarchiwizowane logi przywrócić i w jakim formacie one tam leżą.
Konfiguracja zbierania logów z systemów Linux i Windows (krok po kroku)
Priorytety: co wysyłać z hosta, a czego nie dublować
Zanim przejdzie się do konkretnych poleceń, dobrze ustalić, co ma trafić do centralnego systemu. Klasyczny błąd to wysyłanie wszystkiego „na zapas”, a potem walka z hałasem i kosztem storage. Rozsądny zestaw na początek:
z Linux:
auth.log / dziennik uwierzytelniania (logowania, sudo, próby SSH),
logi jądra (kern) i systemowe (syslog),
logi kluczowych usług: webserwer, reverse proxy, VPN, bazy danych (w trybie „zdarzeniowym”, nie pełny query log),
logi narzędzi backupu i automatyzacji (Ansible, cron, systemd timers).
z Windows:
Security Event Log – logowania, zmiany uprawnień, polityk, kont,
System – błędy sterowników, restartów, usług,
Application – tylko wybrane źródła (np. agent AV/EDR, krytyczne aplikacje),
opcjonalnie PowerShell Operational, gdy w organizacji PowerShell jest intensywnie używany administracyjnie.
Eksport wszystkich zdarzeń z Application na serwerach terminalowych czy stacjach użytkowników niemal gwarantuje lawinę szumu. Tu lepiej zacząć skromniej i stopniowo dokładać źródła, gdy pojawia się realna potrzeba.
Linux: podstawowa konfiguracja rsyslog do centralnego serwera
Na większości dystrybucji rsyslog jest domyślnym demonem logującym. Prosty scenariusz: każdy host wysyła ważniejsze logi do jednego centralnego serwera logów po TCP z TLS.
Podwójny znak @@ oznacza TCP (pojedynczy – UDP). Można też stworzyć osobną regułę dla np. nginx:
if $programname == 'nginx' then @@logserver.example.local:6514
Rozmieszczenie certyfikatu CA w /etc/rsyslog/ssl/ca.crt, jeśli korzystamy z własnego CA.
Restart:
systemctl restart rsyslog
Typową pułapką w małych instalacjach jest uruchamianie forwardingu po UDP bez TLS „bo szybciej i prościej”. Problem pojawia się przy incydencie: ruch można podsłuchać lub spoofować, a logi są traktowane jako dowód, choć technicznie nim nie są.
Linux: gdy wszystko siedzi w journald (systemd)
W nowszych dystrybucjach większość logów ląduje w journald. Z jednej strony ułatwia to zbieranie (wszystko w jednym miejscu), z drugiej – wymaga odpowiedniej integracji z rsyslog lub dedykowanym agentem.
Forward journald → rsyslog – standardowo przez imjournal:
Reszta wygląda tak jak w klasycznym forwardzie rsyslog. Rozsądnie jest jednak filtrować po priorytetach, żeby nie wysyłać wszystkiego, co zgłasza każdy unit systemd.
Bezpośrednio journald → agent (np. Filebeat) – alternatywa, jeśli i tak planowany jest Elastic/OpenSearch:
# fragment filebeat.yml na hoście
filebeat.inputs:
- type: journald
seek: cursor
include_matches:
- "SYSLOG_FACILITY=auth"
- "_SYSTEMD_UNIT=sshd.service"
Wadą jest dodatkowy agent, zaletą – możliwość precyzyjnego filtrowania i wzbogacania logów już po stronie hosta.
Windows: Winlogbeat jako lekki agent do logów zdarzeń
Z perspektywy bezpieczeństwa Windows jest wrażliwym punktem – zwłaszcza stacje użytkowników. Zbieranie logów wyłącznie z serwerów AD i paru serwerów aplikacyjnych daje złudne poczucie całościowego obrazu. Winlogbeat jest często najprostszym sposobem, by zacząć zbierać logi bez budowania pełnego Windows Event Forwarding.
1. Instalacja Winlogbeat na hoście Windows
Pobranie Winlogbeat w wersji zgodnej z planowanym backendem (Elastic/OpenSearch) z oficjalnego źródła i instalacja jako usługi:
.winlogbeat-setup.ps1
Install-Service winlogbeat
W mniejszych środowiskach agent bywa instalowany ręcznie lub skryptem PowerShell rozsyłanym z AD.
Filtry po poziomie i providerach znacząco ograniczają szum. Popularna praktyka „wrzuć wszystko, najwyżej odfiltrujemy później” kończy się zwykle tym, że nikt nie ma czasu tych filtrów dopracować.
2. Wysyłka do centralnego systemu
Następny krok to wskazanie miejsca docelowego. Dwie typowe opcje:
Start-Service winlogbeat
# test wyjścia:
.winlogbeat.exe test output
.winlogbeat.exe test config
Windows Event Forwarding: kiedy warto zamiast (albo obok) agenta
Darmowa rada „zawsze używaj agenta” przestaje działać przy setkach hostów Windows w domenie. Przy takiej skali Windows Event Forwarding (WEF) bywa bardziej praktyczny, choć wymaga porządniejszej konfiguracji GPO.
Model jest inny: hosty forwardują wybrane zdarzenia do jednego (lub kilku) kolektorów WEF, a dopiero z tych kolektorów logi są wysyłane dalej, np. do SIEM-a czy ELK. Korzyści:
mniej połączeń do centralnego systemu logów (tylko z kolektorów),
scentralizowana konfiguracja filtrów WEF w GPO,
możliwość włączenia dodatkowej logiki po stronie kolektora (np. skrypty, Wazuh agent).
Co warto zapamiętać
Monitorowanie logów nie jest celem samym w sobie – ma dać twarde odpowiedzi na pytania typu „kto, kiedy, do czego się dobrał” i bez niego każda analiza incydentu opiera się na domysłach.
Logi „dla admina” (błędy, wydajność, stack trace) i logi „dla bezpieczeństwa” (kto, do czego, z jakiego IP, jaka akcja, czy się powiodła) to dwa różne światy; mylenie ich powoduje brak kluczowych danych przy incydentach.
Rada „loguj wszystko” w małych zespołach zwykle kończy się chaosem: zapchanym storage, szumem informacyjnym i sytuacją, w której nikt realnie logów nie analizuje.
Skuteczniejsze podejście to: najpierw zdefiniować kilka konkretnych scenariuszy bezpieczeństwa (np. nietypowe logowania, masowy eksport danych, nieudane logowania do VPN), a dopiero potem dobrać minimalny zestaw potrzebnych logów.
Źródła logów muszą obejmować nie tylko serwery, ale też urządzenia sieciowe, aplikacje, bazy danych, chmurę oraz usługi SaaS – realne incydenty często dotyczą właśnie kont w CRM, systemach księgowych czy na laptopach pracowników.
Brak sensownego logowania działań użytkowników (kto, do jakiego rekordu, jaka operacja) przekłada się wprost na wyższe ryzyko prawne i koszt obsługi incydentu, bo nie da się wiarygodnie określić skali wycieku.
Darmowe narzędzia do monitorowania mają sens dopiero wtedy, gdy zbierają dobrze przemyślane logi; nawet prosty setup daje dużą wartość, jeśli rejestruje kluczowe akcje zamiast bezrefleksyjnie archiwizować każdy komunikat systemowy.
