1/50
Logowanie: centralizacja logów i analiza w czasie rzeczywistym

Centralne zarządzanie logami sieciowymi

Prezentacja dotyczy centralnego zarządzania logami w sieci komputerowej z wykorzystaniem rsyslog i systemd-journald. Omówiono protokół syslog, strukturę wiadomości, etykiety Facility i Severity oraz narzędzia do rotacji i analizy logów. Przedstawiono architekturę klient-serwer, stos ELK oraz laboratorium transmisji logów.

ill

Prezentacja ósma z cyklu Administracja Sieci Komputerowych poświęcona jest najważniejszym aspektom bezpieczeństwa IT - centralizacji i analizie logów systemowych.

Omówiono rsyslog, logrotate, systemd-journald oraz stos ELK.

Większość ataków pozostawia ślady w logach - zadaniem admina jest ich analiza i reagowanie.

Bez centralnego repozytorium logów administrator traci możliwość odtworzenia sekwencji zdarzeń prowadzących do incydentu, co uniemożliwia skuteczną analizę powłamaniową i może narazić organizację na poważne konsekwencje prawne i finansowe.

Prezentacja kładzie nacisk na praktyczne aspekty konfiguracji, prezentując gotowe przykłady plików konfiguracyjnych oraz komend, które można od razu zastosować w środowisku laboratoryjnym lub produkcyjnym po odpowiednim dostosowaniu do lokalnych wymogów bezpieczeństwa.

Omawiane narzędzia, takie jak rsyslog i systemd-journald, są standardowo dostępne w większości dystrybucji Linuksa, co czyni przedstawione techniki łatwo dostępnymi i możliwymi do wdrożenia bez konieczności instalacji dodatkowego oprogramowania firm trzecich.

2/50
Cel warsztatu - zarządzanie bezpieczeństwem przez logi sieci

Praktyczne cele warsztatu z logów

  • Zrozumienie roli logów w bezpieczeństwie sieci
  • Poznanie protokołu syslog (RFC 3164)
  • Konfiguracja rsyslog jako klient i serwer
  • Sprawne posługiwanie się journalctl
  • Centralne repozytorium logów odporne na manipulacje
  • Analiza logów w czasie rzeczywistym
ill

Celem jest wyposażenie administratora w praktyczne umiejętności centralizacji i analizy logów.

Uczestnik nauczy się konfigurować rsyslog i używać journalctl.

Nacisk na bezpieczeństwo i wykrywanie prób zatarcia śladów przez napastnika.

Protokół syslog, zdefiniowany pierwotnie w RFC 3164, stanowi fundament komunikacji między systemami a centralnym repozytorium i jest obsługiwany nie tylko przez Linuksa, ale także przez urządzenia sieciowe Cisco, Juniper czy systemy FreeBSD, co czyni go uniwersalnym standardem wymiany informacji o zdarzeniach.

Warsztat obejmuje również zagadnienia związane z rotacją logów za pomocą logrotate, co jest niezbędne do zapobiegania przepełnieniu partycji systemowej oraz do zachowania zgodności z politykami przechowywania danych wymaganymi przez przepisy takie jak RODO czy PCI DSS.

Po ukończeniu warsztatu uczestnik będzie potrafił samodzielnie skonfigurować rozproszony system zbierania logów, przeanalizować zgromadzone dane pod kątem bezpieczeństwa oraz zidentyfikować typowe wzorce ataków na podstawie wpisów w dzienniku systemowym.

3/50
Agenda - plan prezentacji i laboratorium

Plan prezentacji krok po kroku

  • Część I (20 min): Koncepcja sysloga, wyścig zbrojeń, struktura protokołu, Facility/Severity, logrotate
  • Część II (15 min): rsyslog, systemd-journald, journalctl, porównanie
  • Część III (15 min): Serwery centralne, port 514, imudp/imtcp, ELK, Graylog, Splunk
  • Część IV (30 min): Laboratorium - konfiguracja klienta i serwera, test, weryfikacja
  • Część V (10 min): Cheat Sheet, dobre praktyki, pytania
ill

Agenda została podzielona na pięć bloków - od teorii przez konfigurację aż po lab.

Pierwsze 20 min to teoria sysloga i struktury komunikatu.

Ostatnie 10 min to podsumowanie z gotowym Cheat Sheetem.

Taki podział czasowy pozwala na stopniowe budowanie wiedzy - najpierw uczestnik poznaje koncepcje teoretyczne, następnie przechodzi do konkretnych narzędzi, a na końcu samodzielnie wykonuje ćwiczenia laboratoryjne utrwalające zdobyte umiejętności w praktycznym środowisku zbliżonym do rzeczywistych warunków produkcyjnych.

Blok drugi poświęcony porównaniu rsyslog i systemd-journald jest szczególnie istotny, ponieważ współczesne dystrybucje Linuksa coraz częściej korzystają z obu tych narzędzi jednocześnie, a zrozumienie ich wzajemnych relacji i możliwości integracji jest kluczowe dla poprawnego zaprojektowania architektury logowania w firmowej infrastrukturze IT.

Laboratorium w bloku czwartym zostało zaprojektowane tak, aby uczestnik mógł je wykonać na dwóch maszynach wirtualnych, co czyni je dostępnym nawet dla osób dysponujących ograniczonym sprzętem i pozwala na wielokrotne powtarzanie ćwiczeń aż do pełnego opanowania materiału.

4/50
Koncepcja sysloga - system rejestracji zdarzeń

Fundament rejestracji zdarzeń

  • Syslog - standard przesyłania komunikatów o zdarzeniach
  • RFC 3164 (2001), uaktualniony RFC 5424 (2009)
  • Aplikacje, jądro i usługi zgłaszają zdarzenia do rejestratora
  • Separacja mechanizmu logowania od przechowywania
  • Model klient-serwer: nadawca i odbiorca
  • Obsługiwany przez wszystkie Unix/Linux i urządzenia sieciowe
ill

Syslog to fundament rejestracji zdarzeń od lat 80. Protokół został zaprojektowany z myślą o prostocie.

RFC 3164 zdefiniował tekstowy format ASCII, RFC 5424 wprowadził dane strukturalne.

Architektura zakłada nadawcę i odbiorcę - to umożliwia skalowalne systemy logowania.

W praktyce oznacza to, że każda aplikacja lub usługa systemowa może wysyłać komunikaty do lokalnego demona rsyslog, który następnie decyduje o ich dalszym losie - zapisie do pliku, przekazaniu przez sieć lub wykonaniu zewnętrznego skryptu reagującego na konkretne zdarzenie.

Standard syslog został tak szeroko przyjęty, że obsługują go nie tylko systemy uniksowe, ale również urządzenia sieciowe, zapory ogniowe, systemy wykrywania włamań (IDS) oraz większość komercyjnych rozwiązań IT, co czyni go najbardziej uniwersalnym protokołem rejestracji zdarzeń w historii informatyki.

Warto zaznaczyć, że współczesna wersja rsyslog oferuje znacznie więcej niż podstawowy syslog - obsługuje zaawansowane filtrowanie na podstawie zawartości komunikatu, szablony wyjściowe, buforowanie dyskowe w razie utraty połączenia z serwerem centralnym oraz szyfrowanie transmisji za pomocą protokołu TLS.

5/50
Wyścig zbrojeń - administrator kontra haker

Walka o logi i ślady ataku

  • Admin gromadzi logi - haker stara się je zatrzeć
  • Lokalne przechowywanie to słaby punkt
  • Po uzyskaniu dostępu root haker czyści logi lokalne
  • Narzędzia: rm -rf /var/log/*, journalctl --rotate --vacuum-time=1s
  • Centralizacja uniemożliwia całkowite zatarcie śladów
  • Logi na centralnym serwerze są poza kontrolą napastnika
ill

Wyścig zbrojeń to kluczowy aspekt bezpieczeństwa IT.

Haker z uprawnieniami root może czytać, modyfikować i usuwać logi.

Centralizacja w zdalnym repozytorium to jedyny skuteczny sposób na zabezpieczenie śladów.

Doświadczeni administratorzy stosują zasadę najmniejszych uprawnień i ograniczają dostęp do konsoli root, jednak po przełamaniu tych zabezpieczeń napastnik uzyskuje pełną kontrolę nad lokalnymi plikami logów i może je bez przeszkód modyfikować w celu zatarcia śladów swojej aktywności w systemie.

Skuteczna centralizacja wymaga, aby logi były wysyłane na serwer zdalny natychmiast po wygenerowaniu, najlepiej za pomocą protokołu TCP gwarantującego dostarczenie, a dodatkowo warto zastosować szyfrowanie transmisji, aby napastnik nie mógł przechwycić i zmodyfikować pakietów w drodze do serwera centralnego.

W zaawansowanych środowiskach stosuje się również rozwiązania typu WORM (Write Once Read Many) na serwerze centralnym, które uniemożliwiają modyfikację lub usunięcie już zapisanych logów nawet w przypadku przejęcia kontroli nad samym serwerem kolektorem.

6/50
Niszczenie śladów lokalnie - metody i skutki

Zatarcie logów przez intruza

  • Usunięcie plików: rm -f /var/log/messages
  • Nadpisanie: cat /dev/null > /var/log/auth.log
  • Rotacja journald: journalctl --rotate --vacuum-time=1s
  • Modyfikacja timestampów: touch -t podmienia datę
  • Wstrzymanie rsyslog: systemctl stop rsyslog
  • Konsekwencja: brak możliwości odtworzenia ataku
ill

Napastnik po uzyskaniu dostępu wykonuje serię czynności mających na celu zatarcie śladów.

Najprostszą metodą jest rm, ale bardziej wyrafinowaną jest nadpisanie zawartości pliku.

Zaawansowani napastnicy wstrzymują rsyslog przed działaniami, a następnie go wznawiają.

Nadpisanie pliku za pomocą cat /dev/null usuwa oryginalną zawartość, ale pozostawia plik o rozmiarze zero, co może wzbudzić podejrzenia administratora podczas rutynowego przeglądu, dlatego niektórzy napastnicy stosują bardziej wyrafinowane techniki polegające na zastąpieniu logów fałszywymi wpisami maskującymi rzeczywiste działania.

Komenda journalctl --rotate --vacuum-time=1s wymusza natychmiastową rotację dziennika systemd i usunięcie wszystkich wpisów starszych niż jedna sekunda, co w praktyce oznacza całkowite wyczyszczenie dziennika przy zachowaniu pozorów normalnego działania mechanizmu rotacji.

Modyfikacja znaczników czasu za pomocą touch -t pozwala napastnikowi na zmianę daty modyfikacji plików logów, co utrudnia ustalenie dokładnego momentu naruszenia bezpieczeństwa i może wprowadzić w błąd zespół reagujący na incydenty podczas analizy chronologii zdarzeń.

7/50
Celowość natychmiastowej centralizacji zdalnej

Logi poza zasięgiem atakującego

  • Logi wysyłane w czasie rzeczywistym do niezależnego serwera
  • Serwer w innej strefie DMZ/VLAN - poza zasięgiem napastnika
  • Zasada 4 oczu: logi dostępne dla SOC, nie tylko lokalnego admina
  • Korelacja zdarzeń z wielu źródeł (NMS, IDS, firewall)
  • Gdy logi przestają napływać - alarm
  • Zgodność z PCI DSS, ISO 27001, RODO
ill

Centralizacja to nie tylko wygoda, ale przede wszystkim mechanizm obrony.

Zasada 4 oczu zakłada, że logi nie powinny być dostępne wyłącznie dla admina lokalnego.

Regulacje PCI DSS, ISO 27001 i RODO nakładają obowiązek gromadzenia i przechowywania logów.

Natychmiastowa centralizacja oznacza, że logi są wysyłane na serwer zdalny w czasie rzeczywistym, bez opóźnienia, co uniemożliwia napastnikowi przechwycenie ich przed transmisją - nawet jeśli uzyska on dostęp root na maszynie źródłowej, logi znajdujące się już na serwerze centralnym pozostają poza jego kontrolą.

Centralny serwer logów powinien znajdować się w wydzielonej strefie DMZ lub dedykowanym VLAN-ie z restrykcyjnymi regułami firewalla, a dostęp do niego powinien być możliwy tylko zaufanym członkom zespołu SOC przez dedykowane, szyfrowane kanały komunikacji.

W przypadku nagłego zatrzymania napływu logów z którejkolwiek maszyny system monitorujący powinien automatycznie wygenerować alert, ponieważ może to świadczyć o celowym wstrzymaniu usługi rsyslog przez napastnika w celu zatarcia śladów przed wykonaniem destrukcyjnych działań na zaatakowanym systemie.

8/50
Zalety centralizacji logów

Bezpieczeństwo i audyt w jednym miejscu

  • Bezpieczeństwo: logi poza zasięgiem atakującego
  • Wygoda: jeden punkt dostępu do logów z całej infrastruktury
  • Korelacja: łączenie zdarzeń z różnych systemów
  • Retencja: centralne zarządzanie polityką przechowywania
  • Analiza: zaawansowane narzędzia (ELK, Graylog, Splunk)
  • Oszczędność: logi nie zajmują miejsca na serwerach produkcyjnych
ill

Centralizacja daje jeden punkt dostępu do logów z setek serwerów.

Korelacja zdarzeń łączy wpisy z firewalla, serwera WWW i kontrolera domeny.

Centralne zarządzanie polityką retencji zapewnia zgodność z regulacjami.

Dzięki centralizacji administrator nie musi logować się do każdej maszyny z osobna, aby sprawdzić jej logi - wszystkie dane są dostępne w jednym miejscu, co znacząco przyspiesza diagnostykę problemów i skraca czas reakcji na incydenty bezpieczeństwa.

Korelacja zdarzeń z różnych źródeł pozwala na wykrycie zaawansowanych ataków typu APT, które pojedynczo mogą wyglądać na nieszkodliwe zdarzenia, ale analizowane łącznie ujawniają sekwencję działań napastnika przemieszczającego się między systemami w poszukiwaniu cennych danych.

Centralne repozytorium umożliwia również stosowanie zaawansowanych narzędzi analitycznych, takich jak systemy SIEM, które automatycznie identyfikują wzorce ataków, generują alerty i wspomagają zespół SOC w priorytetyzacji zdarzeń wymagających natychmiastowej interwencji.

9/50
Przepływ komunikatu syslog - od aplikacji do pliku

Droga logu od programu do pliku

  • Aplikacja wywołuje syslog() lub pisze do /dev/log
  • Biblioteka libc formatuje komunikat według RFC 3164/5424
  • Komunikat trafia na gniazdo UNIX /dev/log
  • Rsyslog odbiera przez moduł imuxsock (Unix socket)
  • Rsyslog dopasowuje do reguł (selektor + akcja)
  • Akcja: plik, sieć, baza, skrypt
ill

Przepływ rozpoczyna się w aplikacji wywołującej syslog() z libc.

Po sformatowaniu komunikat trafia do /dev/log, skąd odbiera go rsyslog.

Rsyslog porównuje priorytet z regułami i wykonuje akcję: zapis, przekaz lub wykonanie skryptu.

Gniazdo /dev/log jest gniazdem domeny UNIX typu datagram (AF_UNIX, SOCK_DGRAM), co oznacza, że komunikacja ma charakter lokalny i nie wymaga stosu TCP/IP, a szybkość transmisji jest ograniczona jedynie przepustowością pamięci operacyjnej i mocy obliczeniowej procesora.

Po odebraniu komunikatu rsyslog dopasowuje go do reguł konfiguracyjnych, sprawdzając najpierw facility i severity, a następnie ewentualne warunki dodatkowe, takie jak zawartość komunikatu, nazwę programu źródłowego czy adres IP hosta - pierwsze dopasowanie decyduje o wykonanej akcji.

Wybór akcji zależy od dyrektywy w pliku konfiguracyjnym: komunikat może zostać zapisany do pliku lokalnego, przekazany na serwer zdalny, zapisany do bazy danych MySQL lub PostgreSQL, wysłany do potoku (pipe) dla zewnętrznego programu analitycznego lub całkowicie odrzucony za pomocą znaku tyldy (~).

10/50
Przepływ komunikatu syslog przez sieć

Transmisja syslog przez sieć

# Przekaz na serwer centralny (TCP)
authpriv.* @@192.168.1.100:514

# Sprawdzenie czy port nasłuchuje
ss -tlnp | grep 514
  • Klient rsyslog odbiera lokalnie jak w modelu lokalnym
  • Reguła: @IP:514 (UDP) lub @@IP:514 (TCP)
  • Komunikat pakowany w datagram UDP lub strumień TCP
  • Serwer odbiera przez imudp (UDP) lub imtcp (TCP)
  • Serwer zapisuje według własnych reguł
  • Kaskadowe przekazywanie: klient -> serwer A -> serwer B
ill

Wybór między UDP a TCP ma znaczenie: UDP jest szybszy, ale nie gwarantuje dostarczenia.

TCP gwarantuje dostarczenie dzięki potwierdzeniom, ale wymaga utrzymywania połączenia.

Architektura kaskadowa pozwala budować hierarchię serwerów z buforowaniem.

W przypadku UDP istnieje ryzyko utraty pakietów przy dużym obciążeniu sieci lub przepełnieniu bufora odbiorczego na serwerze, co może prowadzić do luk w rejestracji zdarzeń, szczególnie w momentach krytycznych, gdy sieć jest najbardziej obciążona, a logi najcenniejsze z punktu widzenia bezpieczeństwa.

Protokół RELP (Reliable Event Logging Protocol) opracowany specjalnie dla rsyslog łączy zalety TCP i UDP - zapewnia niezawodność dostarczenia z potwierdzeniami na poziomie aplikacji, buforowanie po stronie nadawcy w przypadku przerwy w łączności oraz możliwość wznowienia transmisji od momentu przerwania bez duplikacji komunikatów.

W architekturze kaskadowej logi mogą przepływać przez wiele serwerów pośrednich, co jest przydatne w dużych organizacjach posiadających oddziały w różnych lokalizacjach geograficznych - każdy oddział może mieć własny serwer kolektor, który agreguje logi lokalnie i przekazuje je do centralnego repozytorium w głównej siedzibie firmy.

11/50
Architektura syslog - komponenty i role

Budowa systemu logowania

  • Nadawca: aplikacja, jądro, usługa generująca komunikat
  • Kolektor: demon rsyslog/syslog-ng odbierający
  • Moduły wejściowe: imuxsock, imudp, imtcp, imrelp
  • Silnik reguł: dopasowuje komunikaty do selektorów
  • Miejsce docelowe: plik, serwer zdalny, baza, potok
  • Moduły wyjściowe: omfile, omfwd, ommysql, omprog
ill

rsyslog ma budowę modułową - ładuje tylko potrzebne moduły.

Moduły wejściowe decydują, skąd rsyslog odbiera komunikaty.

Silnik reguł analizuje każdy komunikat i porównuje z regułami.

Moduły wejściowe (imuxsock, imudp, imtcp, imrelp, imjournal) odpowiadają za różne źródła danych - od lokalnych gniazd UNIX, przez sieciowe protokoły UDP i TCP, aż po odczyt z dziennika systemd-journald, co pozwala na elastyczne dostosowanie do potrzeb konkretnego środowiska.

Moduły wyjściowe (omfile, omfwd, ommysql, omprog, omelasticsearch) realizują akcje określone w regułach - od zapisu do pliku, przez przekazanie przez sieć, aż po zapis do bazy danych Elasticsearch czy wykonanie zewnętrznego skryptu w odpowiedzi na wystąpienie określonego zdarzenia lub wzorca w komunikacie.

Konfiguracja rsyslog w nowoczesnych dystrybucjach korzysta z podwójnej składni: tradycyjnej (zaczynającej się od znaku $) dla kompatybilności wstecznej oraz nowej składni modułowej RainerScript, która oferuje bardziej czytelną i elastyczną formę definiowania warunków, szablonów i akcji dla przetwarzanych komunikatów.

12/50
Demonstracja: generowanie komunikatu komendą logger

Testowanie syslog przez logger

# Podstawowe użycie
logger "Test komunikatu"

# Z priorytetem
logger -p user.err "Błąd aplikacji"

# Z tagiem
logger -t myapp -p local0.info "Serwis wystartował"

# Bezpośrednio przez sieć
logger -n 192.168.1.100 -P 514 "Test"
  • Logger to podstawowe narzędzie do ręcznego testowania syslog
  • -p facility.severity określa priorytet
  • -t (tag) przypisuje nazwę procesu dla łatwiejszego filtrowania
  • -n -P wysyła bezpośrednio przez sieć bez rsyslog
  • Idealne do testowania konfiguracji rsyslog
  • Sprawdzenie: tail -f /var/log/syslog | grep TEST
ill

Logger służy do ręcznego generowania komunikatów syslog i testowania konfiguracji.

-p określa priorytet facility.severity, -t ustawia tag procesu.

Wersja z -n -P pozwala testować bezpośrednio serwer z pominięciem lokalnego rsyslog.

Narzędzie logger jest szczególnie przydatne podczas weryfikacji reguł filtrowania na serwerze centralnym, ponieważ pozwala na symulację różnych typów komunikatów z różnymi priorytetami i treściami bez konieczności uruchamiania rzeczywistych usług systemowych.

Po wysłaniu komunikatu przez logger warto sprawdzić jego obecność zarówno w lokalnym pliku logów (np. /var/log/syslog), jak i na serwerze zdalnym, aby upewnić się, że cały łańcuch transmisji działa poprawnie - od aplikacji przez lokalny rsyslog aż po odbiór na serwerze centralnym.

Zaawansowani administratorzy wykorzystują logger w skryptach automatyzujących testowanie infrastruktury logowania, na przykład w ramach testów regresyjnych po zmianach konfiguracji rsyslog lub firewalla, co pozwala na szybkie wykrycie ewentualnych problemów zanim wpłyną one na działanie systemów produkcyjnych.

13/50
Struktura protokołu syslog - format wiadomości

Budowa komunikatu syslog

<PRI>TIMESTAMP HOSTNAME MSG

# Przykład:
<34>Oct 11 22:14:15 myhost sshd[1234]:
  Failed password for root from 10.0.0.5
  • <PRI>: priorytet = Facility*8 + Severity (0-191)
  • TIMESTAMP: MMM DD HH:MM:SS (bez strefy czasowej)
  • HOSTNAME: nazwa hosta lub adres IP źródła
  • MSG: treść, często z nazwą procesu i PIDem
  • RFC 5424 wprowadza format z pełnym znacznikiem ISO 8601
  • Znacznik czasu bez strefy = problem przy agregacji międzynarodowej
ill

Format RFC 3164 to tekstowy protokół oparty na ASCII.

Pole PRI koduje zarówno źródło, jak i wagę - Facility × 8 + Severity.

RFC 5424 rozwiązuje problem stref czasowych, wprowadzając ISO 8601.

W formacie RFC 3164 znacznik czasu nie zawiera informacji o strefie czasowej ani roku, co powoduje problemy przy agregacji logów z różnych stref czasowych i przechowywaniu danych przez okres dłuższy niż jeden rok, ponieważ nie można jednoznacznie określić, którego roku dotyczy wpis.

Format RFC 5424 wprowadza pełną datę w formacie ISO 8601 z uwzględnieniem strefy czasowej oraz opcjonalne dane strukturalne w formacie SD-ELEMENT, które pozwalają na dołączanie do komunikatu dodatkowych metadanych, takich jak identyfikator procesu, identyfikator sesji czy kod błędu w ustrukturyzowanej formie.

Przy konfiguracji rsyslog warto zwrócić uwagę na dyrektywę $ActionFileDefaultTemplate, która określa domyślny format zapisu logów do pliku - domyślnie używany jest RSYSLOG_TraditionalFileFormat zgodny z RFC 3164, ale w razie potrzeby można przełączyć się na RSYSLOG_SyslogProtocol23Format wspierający RFC 5424 z danymi strukturalnymi.

14/50
Etykiety Facility - źródło komunikatu

Kategoryzacja źródeł logów

KodFacilityOpis
0kernKomunikaty jądra
1userKomunikaty użytkownika
2mailSystem pocztowy
3daemonUsługi systemowe
4authLogowanie i autoryzacja
5syslogWewnętrzny syslog
9cronZadania cron
16-23local0-7Do definiowania przez aplikacje
  • Facility identyfikuje typ procesu lub podsystemu
  • 24 kategorie (0-23) w RFC 3164
  • kern (0) dla komunikatów jądra
  • auth/authpriv dla uwierzytelniania
  • local0-local7 do własnych aplikacji
ill

Facility identyfikuje źródło komunikatu - typ procesu lub podsystemu.

Facility kern rezerwowane dla jądra, auth dla logowania, local dla własnych aplikacji.

W konfiguracji używa się nazw facility zamiast kodów numerycznych.

Facility auth (kod 4) i authpriv (kod 10) są szczególnie ważne z punktu widzenia bezpieczeństwa, ponieważ dotyczą zdarzeń związanych z uwierzytelnianiem użytkowników, takich jak logowanie przez SSH, użycie sudo, zmiana hasła czy uwierzytelnianie w usługach sieciowych.

Facility local0-local7 (kody 16-23) są przeznaczone do wykorzystania przez aplikacje zewnętrzne i własne skrypty, co pozwala na oddzielenie logów aplikacyjnych od systemowych i ułatwia późniejsze filtrowanie oraz analizę w systemach SIEM.

W konfiguracji rsyslog facility zapisuje się jako nazwę symboliczną, a nie kod numeryczny, co zwiększa czytelność plików konfiguracyjnych - na przykład authpriv.* zamiast 10.*, a local0.err zamiast 16.3.

15/50
Etykiety Severity - poziom ważności komunikatu

Poziomy ważności alertów

KodSeverityOpis
0emergencySystem nie działa
1alertNatychmiastowa interwencja
2criticalStan krytyczny
3errorBłąd
4warningOstrzeżenie
5noticeWażne zdarzenie
6infoInformacja
7debugDane diagnostyczne
  • 8 poziomów ważności od 0 (najważniejszy) do 7
  • emergency (0) = system nie działa
  • alert (1) = wymaga natychmiastowej interwencji
  • *.info obejmuje info i wyższe (bardziej krytyczne)
  • *.!debug wyklucza tylko debug
ill

Severity określa pilność sytuacji - od emerg (0) do debug (7).

*.info oznacza info i wszystkie wyższe (niższy numer = wyższa ważność).

*.!debug wyklucza tylko debug, pozostawiając wszystkie pozostałe.

W praktyce severity emerg (0) jest używane niezwykle rzadko i oznacza sytuację, w której system jest całkowicie niesprawny i wymaga natychmiastowej interwencji, na przykład awaria jądra uniemożliwiająca dalsze działanie systemu operacyjnego.

Severity alert (1) i critical (2) są stosowane dla zdarzeń wymagających pilnej reakcji, takich jak wyczerpanie miejsca na dysku, awaria macierzy dyskowej czy wykrycie próby włamania - administratorzy często konfigurują alerty email lub SMS właśnie dla tych poziomów.

W selektorach rsyslog można stosować operatory porównania: .= (dokładnie ten poziom), .! (wykluczenie), . (od tego poziomu w górę, czyli bardziej krytyczne), co daje precyzyjną kontrolę nad tym, które komunikaty trafiają do poszczególnych plików lub są przekazywane na serwer centralny.

16/50
Priorytet (Priority) - kombinacja Facility i Severity

Priorytet jako suma Facility i Severity

# Wzór: Priority = Facility * 8 + Severity
# auth (4) + crit (2) = 34 -> <34>
# kern (0) + emerg (0) = 0 -> <0>

# W konfiguracji rsyslog:
authpriv.*          # wszystkie authpriv
*.err               # err i wyższe
kern.=crit          # tylko crit z kern
  • PRI = Facility × 8 + Severity
  • PRI przesyłany w nagłówku wiadomości w <>
  • W konfiguracji używa się notacji facility.severity
  • * = wszystkie wartości dla facility lub severity
  • .=severity oznacza dokładny poziom
  • ! wyklucza, , łączy selektory
ill

Priorytet łączy informację o źródle i wadze komunikatu.

W konfiguracji używa się czytelnej notacji facility.severity.

Selektory można łączyć przecinkami i wykluczać wykrzyknikiem.

Obliczenie priorytetu według wzoru Facility × 8 + Severity daje wartość w zakresie od 0 (kern.emerg) do 191 (local7.debug), która jest przesyłana w nagłówku wiadomości syslog w nawiasach ostrych, na przykład <34> dla auth.crit (4 × 8 + 2 = 34).

W konfiguracji rsyslog można definiować reguły z użyciem operatora porównania dla severity: =. oznacza dokładnie ten poziom, a !. oznacza negację, co pozwala na tworzenie precyzyjnych reguł, takich jak kern.=crit oznaczająca tylko komunikaty krytyczne z jądra, bez alertów i emerg.

Selektory można łączyć przecinkami w celu utworzenia listy dopasowań, na przykład auth.*,authpriv.*,*.err oznacza wszystkie komunikaty z auth i authpriv oraz wszystkie błędy z pozostałych facility, a wykrzyknik ! przed selektorem odwraca dopasowanie, wykluczając pasujące komunikaty z dalszego przetwarzania.

17/50
Przykłady komunikatów: kern, auth, mail, cron

Logi z jądra, poczty i cron

# Kern (jądro)
<0>May 10 08:15:30 srv1 kernel: Kernel panic

# Auth (logowanie SSH)
<38>May 10 08:20:00 srv1 sshd[2345]: Accepted publickey

# Mail (poczta)
<22>May 10 08:25:00 srv1 postfix/smtpd[3456]: connect from unknown

# Cron
<78>May 10 08:30:00 srv1 CRON[4567]: CMD run-parts

# User (błąd aplikacji)
<11>May 10 08:35:00 srv1 myapp[5678]: Connection refused
  • Kern panic = najpoważniejszy stan, wymaga restartu
  • Auth Accepted publickey = udane logowanie SSH (audyt)
  • Mail connect from unknown = próba dostarczenia poczty
  • Cron CMD = wykonanie zadania cyklicznego
  • User error = błąd aplikacji (problem z bazą danych)
ill

Komunikat jądra (PRI=0) sygnalizuje panic - najpoważniejszy stan.

Komunikaty auth dotyczą zdarzeń uwierzytelniania - istotne z punktu widzenia audytu.

Mail i cron to typowe zdarzenia w codziennej pracy serwera.

Komunikat kern z priorytetem 0 (emergency) jest generowany w sytuacji krytycznego błędu jądra, z którego system nie może się odtworzyć - Kernel Panic oznacza zatrzymanie pracy systemu i wymaga fizycznego restartu serwera, a wpis w logu zawiera zazwyczaj informację o adresie instrukcji, która spowodowała błąd oraz zawartość rejestrów procesora w momencie awarii.

Logi auth z priorytetem 38 (auth.info) rejestrują udane i nieudane próby logowania, co jest kluczowe dla audytu bezpieczeństwa - analiza wpisów "Failed password" pozwala na wykrycie ataków brute-force na SSH, a wpisy "Accepted publickey" potwierdzają udane logowania, które powinny być zgodne z listą autoryzowanych użytkowników.

Komunikaty cron z priorytetem 78 (cron.info) dokumentują wykonanie każdego zadania cron, w tym pełną linię polecenia, co jest przydatne do diagnostyki problemów z harmonogramem zadań i do wykrywania nieautoryzowanych wpisów w crontab, które mogły zostać dodane przez napastnika w celu utrzymania trwałego dostępu do systemu.

18/50
Zapis w /var/log - organizacja plików

Struktura katalogu /var/log

# Typowa zawartość /var/log (Debian/Ubuntu)
/var/log/
  syslog          # Główny plik logów
  auth.log        # Uwierzytelnianie
  kern.log        # Komunikaty jądra
  mail.log        # Poczta
  cron.log        # Cron
  mysql/          # Logi MySQL
  nginx/          # Logi Nginx
  • Główny plik: syslog (Debian) lub messages (RHEL)
  • auth.log - zdarzenia autoryzacji (SSH, sudo, login)
  • kern.log - komunikaty jądra
  • Osobne katalogi dla aplikacji (apache2/, nginx/, mysql/)
  • wtmp/btmp - logowania binarne (last, lastb)
ill

/var/log to centralne miejsce przechowywania logów w Linuksie.

Różnice między dystrybucjami wynikają z domyślnych konfiguracji rsyslog.

Pliki binarne wtmp i btmp są zarządzane przez login/sshd i odczytywane przez last/lastb.

W systemach Debian i Ubuntu głównym plikiem logów jest /var/log/syslog, podczas gdy w dystrybucjach RHEL, CentOS i Fedora odpowiada mu /var/log/messages - ta różnica wynika z odmiennych domyślnych konfiguracji rsyslog i warto o niej pamiętać podczas pisania skryptów analizujących logi na różnych platformach.

Plik /var/log/auth.log (Debian) lub /var/log/secure (RHEL) zawiera wszystkie zdarzenia związane z autoryzacją i uwierzytelnianiem, w tym logowania przez SSH, użycie sudo, zmiany haseł i operacje na kontach użytkowników, co czyni go jednym z najważniejszych plików do monitorowania z punktu widzenia bezpieczeństwa systemu.

Pliki binarne /var/log/wtmp i /var/log/btmp przechowują historię udanych i nieudanych logowań w formacie binarnym, który można odczytać za pomocą komend odpowiednio last (ostatnie udane logowania) i lastb (ostatnie nieudane próby) - w przeciwieństwie do tekstowych logów auth.log, te pliki są szczególnie trudne do sfałszowania przez napastnika.

19/50
Problem obrastania logami i zapchania dysku

Ryzyko przepełnienia dysku przez logi

  • Logi rosną bez ograniczeń - serwer WWW generuje GB dziennie
  • Brak rotacji = partycja /var 100% = system przestaje działać
  • Bazy danych nie startują, użytkownicy się nie logują
  • DDoS na logi: miliony fałszywych wpisów wypełniają dysk
  • Atakujący generuje logi by zasłonić właściwy atak
  • Rozwiązanie: logrotate + monitoring miejsca (alerty)
ill

Problem obrastania logami to jedno z najczęstszych zagrożeń stabilności.

Gdy /var jest pełny, bazy odmawiają startu, a użytkownicy nie mogą się zalogować.

Atak DDoS na logi generuje potok fałszywych wpisów, by ukryć właściwy atak.

Nowoczesne serwery WWW obsługujące tysiące zapytań na sekundę mogą generować gigabajty logów dziennie, co bez odpowiedniej rotacji doprowadziłoby do przepełnienia partycji w ciągu kilku dni, a w przypadku ataku DDoS nawet w ciągu kilku godzin.

Gdy partycja /var osiągnie 100% wykorzystania, system może odmówić zapisu nowych plików, co uniemożliwia działanie usług takich jak serwery baz danych, serwery pocztowe i demon logowania SSH, a użytkownicy mogą nie być w stanie zalogować się do systemu, ponieważ proces login nie może utworzyć wpisu w /var/log/wtmp.

Atak DDoS generujący olbrzymią liczbę fałszywych wpisów w logach nie tylko grozi przepełnieniem dysku, ale także utrudnia analizę bezpieczeństwa poprzez zagłuszenie rzeczywistych zdarzeń ataku, dlatego stosuje się mechanizmy rate-limitu w rsyslog oraz narzędzia do wykrywania anomalii w strumieniu logów.

20/50
logrotate - rotacja, kompresja i czyszczenie starych wpisów

Automatyczna rotacja plików logów

# /etc/logrotate.conf - konfiguracja globalna
daily
rotate 7
compress
delaycompress
missingok
notifempty

# /etc/logrotate.d/rsyslog
/var/log/syslog {
    weekly
    rotate 4
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
  • Narzędzie cron do rotacji plików logów
  • daily/weekly/monthly - częstotliwość rotacji
  • rotate N - liczba przechowywanych archiwów
  • compress (gzip), delaycompress (opóźniona kompresja)
  • postrotate - skrypt po rotacji (sygnał HUP do rsyslog)
  • dateext - dodanie daty do nazwy pliku
ill

logrotate automatyzuje rotację, kompresję i usuwanie starych logów.

Działa jako zadanie cron i przetwarza reguły z /etc/logrotate.conf i /etc/logrotate.d/.

postrotate wysyła sygnał HUP do rsyslog, by zamknąć stare deskryptory i otworzyć nowe.

Dyrektywa compress włącza kompresję gzip archiwizowanych plików logów, a delaycompress opóźnia kompresję o jeden cykl rotacji, co jest przydatne gdy rsyslog potrzebuje czasu na dokończenie zapisu do właśnie rotowanego pliku przed jego skompresowaniem.

Dyrektywa rotate N określa liczbę przechowywanych archiwów - po jej przekroczeniu najstarszy plik jest usuwany, co pozwala na precyzyjne kontrolowanie przestrzeni dyskowej zajmowanej przez logi, na przykład rotate 7 dla rotacji dziennej oznacza tydzień historii logów.

W konfiguracji /etc/logrotate.d/rsyslog sekcja postrotate wysyła sygnał HUP do procesu rsyslog, co powoduje zamknięcie wszystkich otwartych deskryptorów plików i otworzenie ich na nowo, zapobiegając utracie wpisów po przeniesieniu lub zmianie nazwy pliku logu przez logrotate.

21/50
Standard rsyslog w nowoczesnych dystrybucjach

Rsyslog jako domyślny syslogd

  • Następca tradycyjnego syslogd - standard w Debian/Ubuntu/RHEL
  • Obsługa TCP, UDP, RELP, TLS/SSL
  • Modułowa budowa: input, output, filtr
  • Wsparcie dla szablonów formatowania
  • Obsługa baz MySQL, PostgreSQL, MongoDB
  • Wydajność: dziesiątki tysięcy komunikatów na sekundę
ill

rsyslog to nowoczesny demon logów, który zastąpił syslogd we wszystkich dystrybucjach.

Modularna architektura pozwala ładować tylko potrzebne moduły.

rsyslog obsługuje szyfrowanie TLS, buforowanie dyskowe i potwierdzenia RELP.

Wydajność rsyslog na nowoczesnym sprzęcie sięga dziesiątek tysięcy komunikatów na sekundę, co czyni go odpowiednim nawet dla bardzo obciążonych serwerów produkcyjnych, a w razie potrzeby można go skalować poprzez zastosowanie wielu instancji lub wątków.

Obsługa protokołu RELP (Reliable Event Logging Protocol) stanowi znaczącą przewagę rsyslog nad tradycyjnym syslogd - RELP zapewnia potwierdzenia na poziomie aplikacji, buforowanie w przypadku przerw w łączności i automatyczne wznowienie transmisji od momentu przerwania bez utraty lub duplikacji komunikatów.

Wbudowane wsparcie dla baz danych MySQL, PostgreSQL i MongoDB pozwala na bezpośredni zapis logów do relacyjnych baz danych bez konieczności stosowania pośrednich skryptów, co upraszcza architekturę systemu logowania i zwiększa niezawodność poprzez eliminację dodatkowych punktów awarii.

22/50
Konfiguracja rsyslog - /etc/rsyslog.conf i /etc/rsyslog.d/

Pliki konfiguracyjne rsyslog

# /etc/rsyslog.conf
module(load="imuxsock")
module(load="imklog")
module(load="imudp")
module(load="imtcp")
$WorkDirectory /var/spool/rsyslog
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$IncludeConfig /etc/rsyslog.d/*.conf
  • Plik główny + katalog rsyslog.d/ z regułami
  • Moduły muszą być załadowane przed użyciem
  • imuxsock = gniazda UNIX (/dev/log)
  • imklog = bufor jądra (/dev/kmsg)
  • $IncludeConfig dołącza pliki *.conf z rsyslog.d/
  • Szablony: RSYSLOG_TraditionalFileFormat (RFC 3164)
ill

Konfiguracja opiera się na pliku głównym i katalogu rsyslog.d/.

Moduły muszą być załadowane przed użyciem - kolejność ma znaczenie.

Szablon TraditionalFileFormat używa RFC 3164, SyslogProtocol23Format używa RFC 5424.

Plik rsyslog.conf zawiera dyrektywy globalne i ładowanie modułów, podczas gdy katalog /etc/rsyslog.d/ przeznaczony jest dla reguł przetwarzania komunikatów, co pozwala na przejrzyste oddzielenie konfiguracji od reguł i ułatwia zarządzanie w środowiskach z wieloma źródłami logów.

Moduły muszą być załadowane przed jakimkolwiek ich użyciem w regułach, ponieważ rsyslog przetwarza konfigurację linearnie - próba użycia modułu przed jego załadowaniem zakończy się błędem składni i może uniemożliwić uruchomienie usługi, dlatego zaleca się umieszczanie dyrektyw module(load=...) na początku pliku.

Pliki umieszczone w katalogu /etc/rsyslog.d/ są dołączane w kolejności alfabetycznej, co ma znaczenie przy definiowaniu reguł - jeśli dwie reguły pasują do tego samego komunikatu, wykonywana jest pierwsza z nich, chyba że zawiera dyskontynuację (~) lub dyrektywę stop.

23/50
Reguły rsyslog - selektor i akcja

Selektor i akcja w regułach rsyslog

# Zapis do pliku
authpriv.*          /var/log/auth.log

# Przekaz na serwer (UDP @, TCP @@)
user.*              @@logserver:514

# Z szablonem dynamicznym
$template D,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?D

# Warunek if/then
if $msg contains "ERROR" then /var/log/errors.log

# Dyskontynuacja (stop)
local0.*            ~
  • Selektor: facility.severity (np. authpriv.*)
  • Akcja: plik, @UDP, @@TCP, szablon ?, baza
  • @ = UDP, @@ = TCP, ? = szablon
  • if/then z $msg, $hostname, $programname
  • ~ (dyskontynuacja) = nie przetwarzaj dalej
  • Kolejność reguł ma znaczenie
ill

Reguły składają się z selektora i akcji.

@ oznacza UDP, @@ oznacza TCP, ? oznacza szablon dynamiczny.

Dyskontynuacja (~) oznacza, że dopasowany komunikat nie będzie dalej przetwarzany.

Szablony dynamiczne z przedrostkiem ? pozwalają na tworzenie nazw plików na podstawie właściwości komunikatu, takich jak nazwa hosta (%HOSTNAME%), program źródłowy (%PROGRAMNAME%) czy priorytet (%syslogpriority%), co jest szczególnie przydatne na serwerze centralnym do segregacji logów z wielu maszyn.

Warunki if/then umożliwiają zaawansowane filtrowanie oparte na zawartości komunikatu lub właściwościach, na przykład if $msg contains "ERROR" then /var/log/errors.log, co pozwala na wyodrębnienie tylko istotnych wpisów bez konieczności przeszukiwania wszystkich logów.

Dyskontynuacja za pomocą znaku ~ zapobiega wielokrotnemu przetwarzaniu tego samego komunikatu przez kolejne reguły, co jest przydatne gdy chcemy, aby na przykład komunikaty local0 były zapisywane tylko do dedykowanego pliku i nie trafiały do głównego pliku syslog.

24/50
Rewolucja systemd-journald - nowa jakość logowania

Systemd-journald jako dziennik binarny

  • Wbudowany w systemd - dostępny na każdej dystrybucji z systemd
  • Format binarny - szybszy zapis i odczyt niż tekst
  • Strukturyzowane dane: każde pole osobno (PID, priorytet)
  • Automatyczna integracja: stdout/stderr usług trafia do journald
  • Indeksowane pola - szybkie filtrowanie bez grepa
  • Domyślnie ulotny (/run/log/journal), trwały wymaga /var/log/journal
ill

systemd-journald to komponent systemd do gromadzenia logów w formacie binarnym.

Każdy wpis to zestaw pól klucz-wartość: MESSAGE, PRIORITY, PID, UID.

Journald automatycznie przechwytuje stdout/stderr usług systemd.

Format binarny journald oferuje szybszy zapis niż tradycyjne pliki tekstowe, ponieważ dane są zapisywane w ustrukturyzowanej formie bez konieczności parsowania tekstu, a dodatkowo każdy wpis jest domyślnie kompresowany, co oszczędza miejsce na dysku.

Strukturyzowane dane w journald oznaczają, że każde pole komunikatu (MESSAGE, PRIORITY, PID, UID, GID, _HOSTNAME, _SYSTEMD_UNIT, _BOOT_ID) jest przechowywane osobno i indeksowane, co umożliwia błyskawiczne filtrowanie po dowolnym polu bez konieczności przeszukiwania całego pliku za pomocą grepa.

Domyślnie journald przechowuje logi w /run/log/journal, który jest systemem plików tmpfs (ulotnym), co oznacza utratę logów po restarcie systemu - aby logi były trwałe, należy utworzyć katalog /var/log/journal, po czym journald automatycznie przełączy się na przechowywanie trwałe.

25/50
Dziennik binarny journald vs tekstowe pliki rsyslog

Dziennik binarny kontra tekstowy

Cechajournaldrsyslog
FormatBinarny (indeksowany)Tekstowy (ASCII)
Wydajność zapisuBardzo wysokaWysoka
FiltrowanieIndeksowane polagrep/awk przez plik
PrzechowywanieUlotne (/run)Trwałe (pliki)
Przechwytywanie stdoutAutomatyczneWymaga konfiguracji
RotacjaAutomatycznalogrotate
Dostęp zdalnyWymaga forwardNatywny
  • Oba narzędzia są komplementarne - działają obok siebie
  • Journald = szybki lokalny dziennik
  • Rsyslog = zaawansowane przetwarzanie i routing
ill

Oba narzędzia nie są konkurencyjne, lecz komplementarne.

Journald ma przewagę w wydajności zapisu i indeksowaniu.

Rsyslog jest niezastąpiony w kwestii przekazywania przez sieć i integracji z narzędziami zewnętrznymi.

W praktyce najczęściej stosuje się konfigurację hybrydową: systemd-journald zbiera logi lokalnie z wysoką wydajnością, a następnie przekazuje je do rsyslog za pomocą ForwardToSyslog=yes w journald.conf lub rsyslog odbiera je przez moduł imjournal, co pozwala na dalsze przetwarzanie i przekazywanie na serwer centralny.

Format binarny journald jest szybszy przy zapisie, ale trudniejszy w bezpośrednim odczycie bez użycia narzędzia journalctl, podczas gdy tekstowe pliki rsyslog można odczytać zwykłym cat, tail, grep czy awk bez konieczności instalowania dodatkowego oprogramowania.

Wybór narzędzia zależy od konkretnego zastosowania: do szybkiej diagnostyki lokalnej na pojedynczej maszynie lepszy jest journald z journalctl, natomiast do centralnego zbierania, filtrowania i przekazywania logów z wielu źródeł niezastąpiony pozostaje rsyslog z bogatym zestawem modułów wejściowych i wyjściowych.

26/50
Odpytywanie journalctl - podstawy

Podstawy journalctl

# Wyświetlenie wszystkich logów
journalctl

# Logi z bieżącego boota
journalctl -b

# Lista bootów
journalctl --list-boots

# Ostatnie 10 minut
journalctl --since "10 min ago"

# Podgląd na żywo
journalctl -f
  • Bez opcji wyświetla wszystkie logi od najstarszych
  • -b tylko bieżący boot, -b -1 poprzedni
  • --list-boots lista wszystkich uruchomień
  • --since / --until filtrowanie czasowe
  • -f (follow) jak tail -f w czasie rzeczywistym
ill

journalctl to podstawowe narzędzie do odpytywania dziennika systemd-journald.

-b wyświetla logi tylko z bieżącej sesji - przydatne w diagnostyce.

Filtrowanie czasowe --since akceptuje elastyczne formaty, w tym względne określenia.

Bez żadnych opcji journalctl wyświetla wszystkie logi od najstarszych do najnowszych, co w przypadku systemu działającego od wielu miesięcy może oznaczać tysiące linii, dlatego praktycznie zawsze używa się go z filtrami ograniczającymi zakres wyników do interesującego przedziału czasu lub zdarzenia.

Parametr --list-boots wyświetla tabelę wszystkich uruchomień systemu od początku istnienia dziennika, z numerem boot (0 dla bieżącego, -1 dla poprzedniego), znacznikiem czasu oraz identyfikatorem boot ID, co ułatwia nawigację między logami z różnych sesji systemu.

Warto zapamiętać, że journalctl --since akceptuje zarówno formaty bezwzględne, takie jak "2024-01-15 10:00:00", jak i względne, takie jak "yesterday", "1 hour ago", "15 minutes ago", co czyni go niezwykle wygodnym narzędziem w codziennej pracy administratora.

27/50
Filtry journalctl: --since, -u, -p

Filtrowanie logów journalctl

# Po usłudze
journalctl -u ssh.service

# Po priorytecie
journalctl -p err

# Po polach
journalctl PRIORITY=3 _PID=1234

# Kombinacja
journalctl -u nginx.service -p err --since today

# Format JSON
journalctl -u nginx.service -o json-pretty
  • -u (unit) filtruje po jednostce systemd
  • -p (priority) = ten poziom i wyższe (bardziej krytyczne)
  • Własne filtry po polach: PRIORITY=3, _HOSTNAME=srv1
  • Kombinacje: -u -p --since precyzyjne zapytania
  • -o json dla automatyzacji i parsowania
ill

Filtry pozwalają precyzyjnie zawęzić wyniki do interesujących zdarzeń.

-u wyświetla logi dla określonej jednostki systemd - wygodniejsze niż szukanie po nazwie.

Własne filtry po polach wykorzystują strukturyzowany charakter journald.

Flaga -u (unit) przyjmuje nazwę jednostki systemd z lub bez rozszerzenia .service, na przykład journalctl -u ssh lub journalctl -u ssh.service, i wyświetla tylko wpisy związane z tą konkretną usługą, co jest znacznie szybsze niż filtrowanie po nazwie programu w tradycyjnych plikach tekstowych.

Filtrowanie po polach strukturyzowanych w journald pozwala na tworzenie precyzyjnych zapytań, takich jak PRIORITY=3 (błąd) AND _PID=1234 (konkretny proces) OR _HOSTNAME=srv1 (konkretny host), a warunki można łączyć w dowolny sposób, tworząc złożone kwerendy w stylu języka zapytań.

Format wyjściowy -o json lub -o json-pretty jest szczególnie przydatny w automatyzacji, ponieważ umożliwia przetwarzanie logów przez skrypty w Pythonie, Perlu czy Bashu za pomocą narzędzi takich jak jq, co otwiera możliwości zaawansowanej analizy i integracji z systemami monitorującymi.

28/50
Ciągły podgląd journalctl -f (follow)

Podgląd logów na żywo

# Podgląd na żywo
journalctl -f

# Podgląd usługi
journalctl -u nginx.service -f

# Tylko błędy na żywo
journalctl -p err -f

# Ostatnie 50 linii, potem follow
journalctl -u apache2.service -n 50 -f

# JSON do pliku
journalctl -u myapp.service -o json -f > /tmp/logs.json
  • -f jak tail -f - nowe logi w czasie rzeczywistym
  • Z -u nginx.service -f = monitoring usługi na żywo
  • -p err -f = tylko błędy na bieżąco
  • -n 50 -f = ostatnie 50 linii, potem follow
  • -o json -f do strumieniowego przetwarzania
ill

-f działa analogicznie do tail -f - pokazuje nowe logi na bieżąco.

Połączenie z -u i -p daje precyzyjne narzędzie monitorujące w czasie rzeczywistym.

-o json ułatwia automatyczne przetwarzanie i przekazywanie do systemów zewnętrznych.

Tryb follow (-f) jest niezastąpiony podczas diagnostyki na żywo, gdy administrator oczekuje na pojawienie się konkretnego komunikatu po wykonaniu określonej czynności, na przykład podczas testowania nowej konfiguracji usługi czy sprawdzania skuteczności reguł firewalla.

Połączenie -n 50 z -f pozwala na wyświetlenie ostatnich 50 linii dziennika przed przejściem w tryb nasłuchiwania, co daje kontekst sytuacji sprzed rozpoczęcia monitorowania i jest szczególnie przydatne przy analizie problemów, które już wystąpiły i wymagają obserwacji dalszego rozwoju sytuacji.

Strumieniowanie logów w formacie JSON do pliku za pomocą journalctl -o json -f > /tmp/logs.json pozwala na ciągłe zbieranie danych do analizy offline, co jest przydatne przy długotrwałym monitorowaniu lub gdy potrzebujemy przesłać strumień logów do zewnętrznego systemu analitycznego bezpośrednio z journald.

29/50
Porównanie zalet i wad rsyslog vs journald

Zalety i wady rsyslog i journald

Kryteriumrsyslogsystemd-journald
Centralizacja sieciowa+++ (natywna)-- (wymaga forward)
Szybkość odpytywania+ (grep)+++ (indeksy)
Trwałość danych+++ (zawsze dysk)+/- (ulotne)
Czytelność+++ (tekst)+ (wymaga journalctl)
RotacjalogrotateWbudowana
Bezpieczeństwo transmisji+++ (TLS)+ (przez rsyslog)
  • Wybór nie jest binarny - współpraca w nowoczesnych dystrybucjach
  • Hybryda: journald zbiera, rsyslog przekazuje
ill

Oba narzędzia są komplementarne w nowoczesnych dystrybucjach Linuxa.

Rsyslog sprawdza się jako centralny kolektor, journald jako szybki dziennik lokalny.

Rekomendacja: journald lokalnie + rsyslog z ForwardToSyslog=yes do centralnego serwera.

Wybór między rsyslog a journald nie powinien być traktowany jako decyzja binarna - oba narzędzia doskonale współpracują i każde z nich ma swoje mocne strony, dlatego optymalna architektura logowania wykorzystuje zalety obu systemów jednocześnie.

Do zalet rsyslog, które nie mają odpowiednika w journald, należą: zaawansowane filtrowanie oparte na wyrażeniach regularnych i zawartości komunikatu, możliwość zapisu do baz danych, elastyczne szablony wyjściowe, obsługa protokołów TLS i RELP oraz możliwość wykonywania zewnętrznych skryptów jako akcji.

Z kolei journald oferuje funkcje niedostępne w rsyslog: automatyczne przechwytywanie stdout/stderr usług systemd, wbudowany mechanizm korelacji logów z jednostkami systemd, indeksowane przechowywanie danych z możliwością błyskawicznego wyszukiwania po dowolnym polu oraz wbudowaną kompresję dziennika.

30/50
Współpraca rsyslog + journald

Integracja rsyslog z journald

# Opcja 1: rsyslog czyta z journald przez imjournal
module(load="imjournal" StateFile="imjournal.state")

# Opcja 2: journald przekazuje do rsyslog
# /etc/systemd/journald.conf:
ForwardToSyslog=yes

# Rsyslog zapisuje do plików
authpriv.*    /var/log/auth.log

# Przekaz na centralny serwer
*.* @@logserver:514
  • Rsyslog czyta z journald przez moduł imjournal
  • ForwardToSyslog=yes w journald.conf
  • Oba kierunki działają bez duplikacji
  • journalctl do szybkiego odpytywania lokalnego
  • Rsyslog do przekazywania i centralizacji
ill

Współpraca może przebiegać na dwa sposoby: imjournal lub ForwardToSyslog.

W nowszych dystrybucjach rsyslog ładuje imjournal do odczytu z journald.

Dzięki temu oba systemy działają równolegle bez konfliktu.

Moduł imjournal w rsyslog działa jako input odczytujący wpisy bezpośrednio z dziennika journald na podstawie pliku stanu (imjournal.state), który przechowuje informację o ostatnio przetworzonym wpisie, co gwarantuje, że żaden komunikat nie zostanie pominięty ani przetworzony dwukrotnie po restarcie usługi.

Alternatywna metoda, ForwardToSyslog=yes w journald.conf, powoduje, że journald przekazuje każdy odebrany wpis do tradycyjnego gniazda syslog (/dev/log), skąd odbiera go rsyslog, co jest prostsze konfiguracyjnie, ale może mieć nieco niższą wydajność niż bezpośredni odczyt przez imjournal.

Niezależnie od wybranej metody współpracy, użytkownik końcowy ma dostęp do logów zarówno przez journalctl (szybkie lokalne wyszukiwanie), jak i przez tradycyjne pliki w /var/log (odczyt za pomocą tail, grep, cat), co łączy zalety obu systemów bez konieczności rezygnacji z któregokolwiek z nich.

31/50
Serwery logów (Central Logging Servers)

Centralny serwer logów

  • Jeden lub kilka serwerów przyjmujących logi z całej infrastruktury
  • Każdy host, urządzenie, aplikacja wysyła do centralnego kolektora
  • Kolektor: rsyslog (prosty) lub ELK (zaawansowany)
  • Logi w ujednoliconym formacie, łatwe do przeszukiwania
  • Serwer w osobnej strefie bezpieczeństwa (DMZ/VLAN)
  • Dostęp tylko dla upoważnionych (SOC)
ill

Centralny serwer logów to kluczowy element infrastruktury bezpieczeństwa.

Architektura może być prosta (rsyslog) lub zaawansowana (ELK, Graylog, Splunk).

Bezpieczeństwo serwera logów jest krytyczne - powinien być w osobnej strefie z ograniczonym dostępem.

W przypadku wykorzystania rsyslog jako centralnego kolektora, na serwerze należy załadować moduły imudp (dla UDP) i imtcp (dla TCP), a następnie skonfigurować reguły segregujące logi według nazwy hosta źródłowego, co ułatwia późniejsze przeszukiwanie i zarządzanie danymi z różnych lokalizacji.

Dla zaawansowanych zastosowań stos ELK oferuje indeksowanie pełnotekstowe w Elasticsearch, transformację danych w Logstash oraz wizualizację w Kibanie, co pozwala na tworzenie interaktywnych dashboardów monitorujących i szybkie wyszukiwanie w milionach wpisów logów.

Niezależnie od wybranego rozwiązania, kluczowe jest zabezpieczenie samego serwera logów przed kompromitacją - powinien on znajdować się w wydzielonej strefie sieciowej z dostępem wyłącznie dla uprawnionych członków zespołu SOC, a wszystkie transmisje powinny być szyfrowane za pomocą TLS lub IPsec.

32/50
Architektura klient-serwer w rsyslog

Klient i serwer rsyslog

# KLIENT - wysyła logi
# /etc/rsyslog.d/60-central.conf
*.* @@192.168.1.100:514

# SERWER - odbiera logi
# /etc/rsyslog.conf
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
  • Każda maszyna może być klientem, serwerem lub oboma
  • @ = UDP, @@ = TCP w dyrektywie przekazu
  • Szablon %HOSTNAME% %PROGRAMNAME% segreguje logi
  • Serwer wymaga załadowania imudp i/lub imtcp
  • RELP dla niezawodnego protokołu
ill

Architektura klient-serwer jest prosta, ale elastyczna.

Na kliencie warto użyć szablonu %HOSTNAME% do segregacji plików.

Na serwerze trzeba jawnie załadować moduły i skonfigurować port nasłuchu.

W architekturze klient-serwer każda maszyna może pełnić obie role jednocześnie - odbierać logi lokalnie i przekazywać je dalej, co pozwala na budowanie hierarchicznych struktur kolektorów, gdzie serwer w oddziale agreguje logi z lokalnych maszyn i przesyła je do centralnego repozytorium w głównej lokalizacji.

Dyrektywa @@ (TCP) jest zalecana do transmisji logów w sieciach rozległych, gdzie pakiety mogą być tracone, podczas gdy @ (UDP) może być stosowany w niezawodnych sieciach lokalnych, gdzie szybkość transmisji jest ważniejsza niż gwarancja dostarczenia każdego komunikatu.

RELP (Reliable Event Logging Protocol) jest rozszerzeniem protokołu syslog dodającym potwierdzenia na poziomie aplikacji, co zapewnia jeszcze wyższą niezawodność niż TCP, ponieważ nawet w przypadku przerwania połączenia logi są buforowane po stronie klienta i automatycznie wysyłane po przywróceniu łączności.

33/50
Port 514 - UDP vs TCP w transmisji logów

Port 514 i protokoły transmisji

CechaUDP (514)TCP (514)
NiezawodnośćBrakGwarancja
SzybkośćBardzo wysokaWysoka (ACK)
KolejkowanieBrakWbudowane
BezpieczeństwoSpoofingTrudniejszy spoofing
FragmentacjaMTU ~1500BAutomatyczna
ZastosowanieLAN, mało krytyczneWAN, produkcja

Rekomendacja: używaj TCP (@@) w środowisku produkcyjnym

ill

UDP jest szybszy, ale nie gwarantuje dostarczenia - pakiety mogą ginąć.

TCP gwarantuje dostarczenie dzięki potwierdzeniom i retransmisji.

W produkcji: logi krytyczne przez TCP, mniej ważne przez UDP.

UDP ma niższy narzut protokołowy i nie wymaga utrzymywania stanu połączenia, co oznacza, że serwer może obsłużyć więcej klientów jednocześnie, ale w przypadku przeciążenia sieci lub bufora odbiorczego pakiety są po prostu odrzucane bez żadnego powiadomienia nadawcy.

TCP zapewnia gwarancję dostarczenia dzięki trójfazowemu uzgadnianiu połączenia, numerom sekwencyjnym, potwierdzeniom i retransmisji utraconych segmentów, ale za cenę wyższego narzutu i konieczności utrzymywania tabeli połączeń po stronie serwera, co ogranicza skalowalność.

W środowiskach produkcyjnych zaleca się stosowanie protokołu TCP dla logów o wysokim priorytecie (auth, kern, crit) oraz UDP dla logów o niższym znaczeniu (debug, info), a w przypadku bardzo krytycznych systemów warto rozważyć RELP, który łączy zalety obu protokołów z dodatkowym buforowaniem dyskowym.

34/50
Moduły imudp i imtcp - konfiguracja serwera

Moduły wejściowe rsyslog

# Moduł UDP
module(load="imudp")
input(type="imudp" port="514")

# Moduł TCP
module(load="imtcp")
input(type="imtcp" port="514")

# TCP z ograniczeniem do interfejsu
input(type="imtcp" port="514" address="192.168.1.100")

# Restart
systemctl restart rsyslog
  • Bez modułów rsyslog nie nasłuchuje sieci
  • imudp = nasłuch UDP na porcie 514
  • imtcp = nasłuch TCP na porcie 514
  • Ograniczenie do interfejsu (address=) zwiększa bezpieczeństwo
  • TLS/SSL z StreamDriver dla szyfrowania
ill

imudp i imtcp są niezbędne do odbierania logów przez sieć.

Ograniczenie do konkretnego adresu IP zapobiega przyjmowaniu logów z niepowołanych źródeł.

TLS z StreamDriver zapewnia szyfrowanie transmisji i uwierzytelnianie certyfikatami.

Moduły wejściowe rsyslog wymagają jawnego załadowania i skonfigurowania przed użyciem - bez linii module(load="imudp") i input(type="imudp" port="514") rsyslog nie będzie nasłuchiwał na żadnym porcie sieciowym, co jest częstym błędem początkujących administratorów podczas konfiguracji serwera centralnego.

Ograniczenie nasłuchu do konkretnego interfejsu sieciowego za pomocą parametru address= znacząco zwiększa bezpieczeństwo, ponieważ serwer akceptuje logi tylko z określonej sieci, ignorując ruch przychodzący z innych interfejsów, co uniemożliwia ataki z niepowołanych źródeł nawet przy otwartym porcie firewalla.

Konfiguracja TLS z StreamDriver wymaga wygenerowania certyfikatów CA i serwera, skonfigurowania parametrów auth i permittedPeer, a także użycia modułów imtcp z parametrami StreamDriver.Name="gtls" i StreamDriver.Mode="1", co zapewnia szyfrowanie transmisji i wzajemne uwierzytelnianie klienta i serwera.

35/50
Współczesne stosy analityczne - ELK Stack

Stos ELK do analizy logów

  • ELK = Elasticsearch + Logstash + Kibana
  • Elasticsearch - indeksowanie i wyszukiwanie pełnotekstowe
  • Logstash - odbiór i transformacja logów
  • Kibana - wizualizacja i dashboardy
  • Alternatywy: Graylog (prostszy), Splunk (komercyjny lider)
  • Beats - lekcy agenci zbierający dane na hostach
ill

ELK to obecnie najpopularniejszy stos do analizy logów w dużych środowiskach.

Elasticsearch indeksuje dane w czasie rzeczywistym, Logstash transformuje, Kibana wizualizuje.

Graylog łączy funkcje kolektora i interfejsu w jednym produkcie, Splunk jest liderem komercyjnym.

Stos ELK (Elasticsearch, Logstash, Kibana) jest rozwijany przez firmę Elastic i dostępny w wersji open source (z ograniczeniami w darmowej licencji podstawowej) oraz w płatnych wersjach oferujących dodatkowe funkcje bezpieczeństwa, monitorowania i alertowania.

Logstash pełni funkcję potoku ETL (Extract, Transform, Load) - odbiera logi z wielu źródeł (syslog, beat, HTTP, TCP/UDP), parsuje je za pomocą filtrów (grok, mutate, date, geoip) i wysyła do wybranego magazynu, którym najczęściej jest Elasticsearch, ale może być również Kafka, S3 lub plik.

Graylog stanowi prostszą alternatywę dla ELK, oferując wbudowany kolektor syslog, interfejs WWW z wyszukiwarką i dashboardami oraz mechanizm alertów w jednym zintegrowanym produkcie, co czyni go łatwiejszym w konfiguracji dla mniejszych zespołów.

36/50
Elasticsearch - indeksowanie i wyszukiwanie

Indeksowanie logów w Elasticsearch

  • Rozproszony silnik wyszukiwania oparty na Apache Lucene
  • Indeksowanie JSON z pełnotekstowym wyszukiwaniem
  • REST API - pełna kontrola przez HTTP
  • Skalowalność horyzontalna: dodawanie węzłów
  • Indeksy dzienne dla logów (logstash-YYYY.MM.DD)
  • Kibana jako graficzny interfejs użytkownika
ill

Elasticsearch to rozproszony silnik wyszukiwania analizujący dane w czasie rzeczywistym.

Logi są indeksowane w indeksach dziennych, co ułatwia rotację i zarządzanie retencją.

REST API pozwala na integrację z dowolnym językiem programowania.

Elasticsearch opiera się na bibliotece Apache Lucene, która zapewnia zaawansowane możliwości indeksowania i wyszukiwania pełnotekstowego, w tym obsługę analizatorów językowych, stemmingu, tokenizacji oraz zapytań geoprzestrzennych, co czyni go niezwykle elastycznym narzędziem do analizy logów.

Indeksy w Elasticsearch są domyślnie tworzone jako indeksy dzienne (np. logstash-2024.01.15), co ułatwia zarządzanie cyklem życia danych - starsze indeksy można automatycznie zamykać, kompresować lub usuwać za pomocą polityk ILM (Index Lifecycle Management), bez wpływu na dostępność nowszych danych.

Architektura Elasticsearch opiera się na klastrach składających się z wielu węzłów, które automatycznie dystrybuują dane i zapytania między sobą, co zapewnia wysoką dostępność i skalowalność horyzontalną - w razie potrzeby wystarczy dodać kolejne węzły do klastra, aby zwiększyć pojemność i wydajność.

37/50
Logstash - odbiór i transformacja logów

Transformacja logów przez Logstash

# Przykład konfiguracji Logstash
input {
  beats { port => 5044 }
  syslog { port => 514 }
}
filter {
  grok {
    match => { "message" => "%{SYSLOGBASE}" }
  }
  date {
    match => [ "timestamp", "MMM  d HH:mm:ss" ]
  }
}
output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "syslog-%{+YYYY.MM.dd}"
  }
}
  • Input: filebeat, syslog, tcp, udp, kafka
  • Filter: grok do parsowania, mutate do zmiany pól
  • Output: elasticsearch, kafka, s3, stdout
  • Pipeline ETL: Extract, Transform, Load
  • Grok z wzorcami Regex dla syslog, apache, nginx
ill

Logstash to narzędzie ETL do odbioru, transformacji i przekazywania logów.

Input odbiera dane z różnych źródeł, filter parsuje i wzbogaca, output wysyła do docelowego magazynu.

Grok to najważniejszy filter - używa wzorców Regex do wyodrębniania pól z surowych komunikatów.

Filtr grok w Logstash wykorzystuje bibliotekę wzorców regex do parsowania nieustrukturyzowanych komunikatów tekstowych na ustrukturyzowane pola - na przykład wzorzec %{SYSLOGBASE} wyodrębnia z komunikatu syslog takie pola jak timestamp, hostname, program, PID i message, co umożliwia późniejsze filtrowanie i analizę każdego z tych pól osobno.

Logstash obsługuje szeroką gamę źródeł wejściowych (input), w tym protokół syslog (port 514), Filebeat (port 5044), kolejki Kafka, gniazda TCP/UDP, pliki, HTTP oraz API, co czyni go niezwykle elastycznym narzędziem do zbierania danych z różnorodnych systemów i aplikacji w heterogenicznym środowisku IT.

Pipeline Logstash może być rozbudowany o dodatkowe filtry, takie jak mutate do zmiany typów i nazw pól, date do parsowania znaczników czasu, geoip do wzbogacania danych o lokalizację geograficzną na podstawie adresu IP oraz translate do zamiany wartości na podstawie słownika.

38/50
Kibana - wizualizacja i alternatywy

Wizualizacja danych w Kibanie

  • Kibana - graficzny interfejs dla Elasticsearch
  • Discover: przeszukiwanie logów w czasie rzeczywistym
  • Visualize: wykresy słupkowe, liniowe, mapy
  • Dashboard: łączenie wielu wizualizacji
  • Graylog: prostsza alternatywa dla małych środowisk
  • Splunk: komercyjny lider SIEM (licencja od $2000/rok)
ill

Kibana umożliwia tworzenie interaktywnych dashboardów z logów.

Graylog oferuje wbudowany kolektor syslog + interfejs WWW w jednym produkcie.

Splunk to najbardziej zaawansowane narzędzie SIEM, ale z wysokimi kosztami licencyjnymi.

Kibana, jako część stosu ELK, oferuje zakładkę Discover do eksploracji logów w czasie rzeczywistym z możliwością tworzenia zapytań KQL (Kibana Query Language), zakładkę Visualize do budowania wykresów i tabel oraz zakładkę Dashboard do łączenia wielu wizualizacji w jeden spójny panel monitorujący.

Graylog wyróżnia się na tle ELK łatwością konfiguracji - wbudowany kolektor syslog eliminuje potrzebę stawiania osobnego Logstash, a interfejs WWW oferuje intuicyjne wyszukiwanie, zapisywanie zapytań, tworzenie dashboardów oraz konfigurację alertów wysyłanych przez email, Slack lub webhook.

Splunk jest uważany za najbardziej zaawansowane narzędzie do analizy logów i bezpieczeństwa, oferujące wbudowane modele uczenia maszynowego do wykrywania anomalii, gotowe aplikacje SIEM z korelacją zdarzeń oraz zaawansowane możliwości raportowania, ale jego cena licencyjna (uzależniona od objętości przetwarzanych danych) czyni go dostępnym głównie dla dużych organizacji.

39/50
LAB: Cel i środowisko laboratoryjne

Cel i topologia laboratorium

# Wymagania laboratoryjne
# 2 maszyny Linux (np. Ubuntu 22.04)
# Klient: 192.168.1.10/24
# Serwer: 192.168.1.100/24
# rsyslog zainstalowany domyślnie
# Port 514 odblokowany w firewallu

systemctl status rsyslog
systemctl is-enabled rsyslog
  • Cel: uruchomienie transmisji logów z klienta na serwer
  • 2 maszyny Linux w tej samej sieci /24
  • rsyslog domyślnie zainstalowany i włączony
  • Port 514 musi być otwarty w firewalu
  • Konieczny dostęp root (sudo) do konfiguracji
ill

Laboratorium polega na skonfigurowaniu transmisji logów z klienta na serwer centralny.

Potrzebne są dwie maszyny Linux - można użyć maszyn wirtualnych VirtualBox.

rsyslog jest domyślnie zainstalowany na większości dystrybucji - wystarczy go skonfigurować.

Do wykonania laboratorium wystarczą dwie maszyny wirtualne z systemem Ubuntu Server 22.04 lub nowszym, połączone wewnętrzną siecią NAT lub host-only, co zapewnia izolację od sieci zewnętrznej i pozwala na bezpieczne przeprowadzenie ćwiczeń bez ryzyka zakłócenia działania innych systemów.

Przed rozpoczęciem konfiguracji należy upewnić się, że firewall na obu maszynach nie blokuje portu 514 oraz że obie maszyny mają przypisane statyczne adresy IP (klient 192.168.1.10, serwer 192.168.1.100), co zapewnia stabilność połączenia podczas trwania laboratorium.

Przydatne jest również sprawdzenie wersji rsyslog za pomocą rsyslogd -v, ponieważ starsze wersje (przed 8.x) mają inną składnię konfiguracyjną i mogą wymagać dostosowania przykładów przedstawionych w prezentacji do dostępnej wersji oprogramowania.

40/50
LAB: Konfiguracja klienta rsyslog

Konfiguracja klienta rsyslog

# Krok 1: Utwórz plik reguły na kliencie
cat > /etc/rsyslog.d/60-central.conf << EOF
# Wszystkie logi przez TCP na serwer
*.* @@192.168.1.100:514
EOF

# Krok 2: Restart rsyslog
systemctl restart rsyslog

# Krok 3: Sprawdzenie
systemctl status rsyslog
  • Utwórz plik /etc/rsyslog.d/60-central.conf
  • Wpisz regułę: *.* @@IP_SERWERA:514
  • Zrestartuj rsyslog: systemctl restart rsyslog
  • Sprawdź status: systemctl status rsyslog
  • Brak błędów = konfiguracja poprawna
ill

Na kliencie tworzymy nowy plik reguły w /etc/rsyslog.d/ z przekazem na serwer.

Używamy @@ (TCP) dla gwarancji dostarczenia logów.

Po restarcie sprawdzamy czy rsyslog działa poprawnie - brak błędów w statusie.

Plik konfiguracyjny klienta powinien mieć nazwę z prefiksem liczbowym (np. 60-central.conf), ponieważ pliki w /etc/rsyslog.d/ są przetwarzane w kolejności alfabetycznej, a odpowiednio dobrany prefiks pozwala na zachowanie pożądanej kolejności wykonywania reguł w stosunku do innych plików konfiguracyjnych.

Po utworzeniu pliku i restarcie rsyslog warto sprawdzić, czy klient faktycznie próbuje nawiązać połączenie z serwerem, używając polecenia ss -tlnp | grep 514 na kliencie - jeśli rsyslog nie wyświetla połączenia, oznacza to, że konfiguracja przekazu nie została poprawnie załadowana.

Test konfiguracji rsyslog za pomocą rsyslogd -N1 przed restartem usługi pozwala na wykrycie błędów składni w plikach konfiguracyjnych bez ryzyka przerwania działania działającej usługi, co jest dobrą praktyką przy każdorazowej modyfikacji konfiguracji.

41/50
LAB: Konfiguracja serwera rsyslog

Konfiguracja serwera rsyslog

# Krok 1: Konfiguracja serwera /etc/rsyslog.conf
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

# Krok 2: Reguła z szablonem
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

# Krok 3: Restart
systemctl restart rsyslog
  • Załaduj moduły imudp i imtcp w /etc/rsyslog.conf
  • Skonfiguruj nasłuch na porcie 514
  • Dodaj regułę z szablonem RemoteLogs
  • Utwórz katalog /var/log/remote/
  • Zrestartuj rsyslog i sprawdź nasłuch: ss -tlnp | grep 514
ill

Na serwerze ładujemy moduły imudp i imtcp do odbioru ruchu sieciowego.

Szablon RemoteLogs segreguje logi do katalogów według nazwy hosta i programu.

Po restarcie sprawdzamy czy rsyslog nasłuchuje na porcie 514.

Katalog /var/log/remote/ musi istnieć i mieć odpowiednie prawa dostępu przed uruchomieniem rsyslog - najlepiej utworzyć go ręcznie za pomocą mkdir -p /var/log/remote i ustawić właściciela na syslog:adm za pomocą chown syslog:adm /var/log/remote, co zapewni demonowi rsyslog możliwość zapisu do tego katalogu.

Szablon RemoteLogs tworzy strukturę katalogów według wzorca /var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log, co oznacza, że logi z każdego hosta źródłowego trafiają do osobnego podkatalogu z nazwą hosta, a w nim do plików podzielonych według nazwy programu, co znacznie ułatwia późniejsze przeszukiwanie i zarządzanie.

Po restarcie rsyslog na serwerze warto natychmiast sprawdzić, czy usługa nasłuchuje na porcie 514, wykonując ss -tlnp | grep 514 oraz ss -ulnp | grep 514 - jeśli w wyjściu nie widać procesu rsyslog, oznacza to, że moduły imudp lub imtcp nie zostały poprawnie załadowane, co jest najczęstszym błędem konfiguracji serwera.

42/50
LAB: Test połączenia - komenda logger

Test transmisji przez logger

# Na kliencie: wyślij testowy komunikat
logger -p user.err "TEST: błąd aplikacji - sprawdź log centralny"

# Sprawdź lokalnie
tail -f /var/log/syslog | grep TEST

# Sprawdź czy port jest otwarty
ss -tlnp | grep 514
ss -ulnp | grep 514
  • Na kliencie wywołaj logger z priorytetem user.err
  • Użyj wyraźnego tagu TEST do łatwego filtrowania
  • Sprawdź lokalnie: tail -f /var/log/syslog | grep TEST
  • Sprawdź komunikację: ss -tlnp | grep 514
  • Przejdź na serwer i sprawdź czy log dotarł
ill

Komenda logger symuluje zdarzenie systemowe - wysyła komunikat przez rsyslog.

Po wywołaniu sprawdzamy lokalnie czy log został zapisany, a następnie na serwerze czy dotarł.

ss -tlnp potwierdza, że rsyslog nasłuchuje na porcie 514.

Warto użyć opcji -t z logger do ustawienia czytelnego tagu (np. -t TEST_LAB), który ułatwi identyfikację testowego komunikatu zarówno w lokalnych plikach logów, jak i na serwerze centralnym, co jest szczególnie przydatne podczas zajęć laboratoryjnych, gdzie wiele osób może testować transmisję jednocześnie.

Jeśli log nie pojawia się na serwerze, pierwszym krokiem diagnostycznym powinno być sprawdzenie, czy pakiety w ogóle opuszczają klienta - można to zrobić za pomocą tcpdump -i eth0 host 192.168.1.100 and port 514 na kliencie, a następnie ponownie wywołać logger i obserwować, czy pakiety są wysyłane.

W przypadku gdy pakiety opuszczają klienta, ale nie docierają do serwera, problem leży najprawdopodobniej w firewallu - należy sprawdzić reguły iptables na serwerze (iptables -L INPUT -n -v | grep 514) i w razie potrzeby dodać regułę zezwalającą na ruch przychodzący na port 514.

43/50
LAB: Weryfikacja na serwerze

Sprawdzenie odebranych logów

# Na serwerze: sprawdź czy log dotarł
tail -f /var/log/remote/KLIENT/user.log | grep TEST

# Alternatywnie: przeszukaj wszystkie logi zdalne
grep -r "TEST" /var/log/remote/

# Lub: journalctl na serwerze
journalctl | grep "TEST"
  • Sprawdź katalog /var/log/remote/ na serwerze
  • Odszukaj plik z nazwą hosta klienta
  • Przefiltruj grep TEST w znalezionym pliku
  • Potwierdź poprawność transmisji
  • W razie problemów: tcpdump -i eth0 port 514
ill

Po wysłaniu testowego logu sprawdzamy na serwerze czy dotarł do katalogu zdalnego.

Używamy grepa do łatwego odszukania komunikatu z tagiem TEST.

W razie problemów używamy tcpdump do diagnostyki ruchu sieciowego na porcie 514.

Komenda grep -r "TEST" /var/log/remote/ przeszukuje wszystkie pliki w katalogu zdalnym, co jest wygodne gdy nie pamiętamy dokładnej ścieżki do pliku logu dla danego hosta i programu - działa to nawet przy bardzo dużej liczbie plików, choć w przypadku ogromnych zbiorów danych warto ograniczyć zakres wyszukiwania.

tcpdump -i eth0 port 514 -nn -X na serwerze pozwala na podejrzenie surowych pakietów przychodzących na port 514, co jest szczególnie przydatne gdy logi docierają do serwera (widać je w tcpdump), ale nie są zapisywane do pliku - w takim przypadku problem leży w konfiguracji reguł rsyslog na serwerze.

Warto również sprawdzić, czy komunikaty nie są blokowane przez mechanizm rate-limitu rsyslog - domyślnie rsyslog ogranicza liczbę przetwarzanych komunikatów do 200 na sekundę, co przy intensywnym testowaniu może powodować odrzucanie nadmiarowych wpisów, które będą widoczne w tcpdump, ale nie trafią do plików.

44/50
LAB: Podsumowanie laboratorium

Efekty laboratorium rsyslog

# Diagnostyka
grep "TEST" /var/log/remote/*/*.log

# tcpdump do debugowania
tcpdump -i eth0 port 514 -nn

# Sprawdzenie firewalla
iptables -L -n | grep 514
ufw status

# Test konfiguracji rsyslog
rsyslogd -N1
  • Sprawdzenie czy logi dotarły w obie strony
  • tcpdump do diagnostyki ruchu na porcie 514
  • Sprawdzenie firewalla: iptables -L -n | grep 514
  • Test konfiguracji rsyslog: rsyslogd -N1
  • Potwierdzenie: centralizacja działa poprawnie
ill

Po zakończeniu laboratorium warto przećwiczyć diagnostykę najczęstszych problemów.

tcpdump pokazuje czy pakiety w ogóle docierają do serwera, a rsyslogd -N1 testuje konfigurację.

Firewall może blokować port 514 - sprawdź iptables, ufw lub firewalld.

Komenda rsyslogd -N1 wykonuje suchy test konfiguracji (tryb debugowania bez uruchamiania usługi) i raportuje wszystkie błędy składni oraz brakujące pliki lub katalogi, co pozwala na szybkie wykrycie problemów przed ponownym uruchomieniem rsyslog w środowisku produkcyjnym.

W przypadku gdy logi docierają na serwer (potwierdzone przez tcpdump), ale nie są zapisywane do pliku, najczęstszą przyczyną są nieprawidłowe prawa dostępu do katalogu /var/log/remote/ lub jego podkatalogów - rsyslog działa jako użytkownik syslog i musi mieć prawo zapisu do wszystkich katalogów w ścieżce docelowej.

Innym częstym problemem jest przepełnienie partycji /var - gdy miejsce na dysku spadnie poniżej krytycznego progu, rsyslog przestaje zapisywać nowe wpisy, aby zapobiec całkowitemu zablokowaniu systemu, a komunikaty o tym zdarzeniu są zapisywane w dzienniku systemd-journald i można je podejrzeć za pomocą journalctl -u rsyslog -p err.

45/50
Troubleshooting: prawa zapisu w katalogach

Problemy z prawami do katalogów

# Sprawdzenie praw dostępu
ls -la /var/log/
ls -la /var/log/remote/

# Naprawa praw
chown syslog:adm /var/log/remote/ -R
chmod 755 /var/log/remote/

# Test konfiguracji rsyslog
rsyslogd -N1

# Podgląd logów rsyslog
journalctl -u rsyslog -p err
  • rsyslog musi mieć prawa zapisu do katalogów docelowych
  • Sprawdź: ls -la /var/log/remote/
  • Napraw: chown syslog:adm -R, chmod 755
  • rsyslogd -N1 testuje składnię konfiguracji
  • journalctl -u rsyslog pokazuje błędy demona
ill

Najczęstszym problemem są nieprawidłowe prawa dostępu do katalogów.

rsyslog działa jako użytkownik syslog - musi mieć prawo zapisu do docelowych katalogów.

rsyslogd -N1 testuje konfigurację bez uruchamiania usługi - przydatne przed restartem.

Aby sprawdzić, pod jakim użytkownikiem działa rsyslog, można użyć polecenia ps aux | grep rsyslog - zazwyczaj jest to użytkownik syslog w dystrybucjach Debian/Ubuntu lub root w niektórych starszych wersjach - znajomość tego użytkownika jest kluczowa przy ustawianiu praw dostępu do katalogów z logami.

W przypadku błędów praw dostępu rsyslog zapisuje odpowiednie komunikaty do własnego dziennika, który można podejrzeć za pomocą journalctl -u rsyslog -p err, co jest znacznie szybsze niż ręczne przeszukiwanie wszystkich plików konfiguracyjnych w poszukiwaniu źródła problemu.

Po naprawie praw dostępu i restarcie rsyslog warto ponownie wykonać test za pomocą logger i sprawdzić, czy logi poprawnie zapisują się w docelowych katalogach - systematyczne testowanie po każdej zmianie konfiguracji zapobiega kumulacji błędów i ułatwia szybkie identyfikowanie źródła problemów.

46/50
Troubleshooting: weryfikacja portu 514 (netstat/ss)

Sprawdzenie nasłuchu na porcie 514

# Sprawdzenie nasłuchu TCP
ss -tlnp | grep 514

# Sprawdzenie nasłuchu UDP
ss -ulnp | grep 514

# Alternatywnie netstat
netstat -tulnp | grep 514

# lsof
lsof -i :514
  • ss -tlnp = nasłuch TCP, ss -ulnp = nasłuch UDP
  • Port 514 wymaga uprawnień root do otwarcia
  • Brak rsyslog w wyjściu = moduł nie załadowany
  • netstat -tulnp jako alternatywa dla ss
  • lsof -i :514 pokazuje proces na porcie
ill

ss (socket statistics) to nowoczesny zamiennik netstat.

Jeśli rsyslog nie pojawia się w wyjściu ss, oznacza to że moduł nie został załadowany.

Port 514 jest uprzywilejowany (< 1024) - rsyslog musi działać jako root.

Narzędzie ss jest domyślnie dostępne w nowoczesnych dystrybucjach Linuksa i oferuje bardziej szczegółowe informacje niż przestarzały netstat, w tym wyświetlanie procesów nasłuchujących na poszczególnych portach, co jest kluczowe przy diagnostyce konfiguracji rsyslog na serwerze centralnym.

Jeśli w wyjściu ss -tlnp | grep 514 pojawia się wpis, ale zamiast nazwy procesu widnieje tylko numer PID w nawiasie, oznacza to, że rsyslog nasłuchuje na porcie, ale użytkownik wykonujący polecenie nie ma uprawnień do odczytu szczegółów procesu - w takim przypadku należy użyć sudo ss -tlnp | grep 514.

Brak jakiegokolwiek wpisu na porcie 514 w wyjściu ss przy jednocześnie działającym rsyslog (potwierdzonym przez systemctl status rsyslog) jednoznacznie wskazuje na brak załadowanych modułów imudp/imtcp w konfiguracji serwera.

47/50
Troubleshooting: reguły iptables blokujące ruch

Blokada portu 514 przez firewall

# Sprawdzenie reguł iptables
iptables -L INPUT -n -v | grep 514

# Dodanie reguły ACCEPT dla rsyslog
iptables -A INPUT -p tcp --dport 514 -j ACCEPT
iptables -A INPUT -p udp --dport 514 -j ACCEPT

# Dla ufw
ufw allow 514/tcp
ufw allow 514/udp

# Dla firewalld
firewall-cmd --add-port=514/tcp --permanent
firewall-cmd --reload
  • Domyślna polityka INPUT DROP blokuje port 514
  • Sprawdź: iptables -L INPUT -n | grep 514
  • Dodaj regułę: iptables -A INPUT -p tcp --dport 514 -j ACCEPT
  • Dla ufw: ufw allow 514/tcp
  • Dla firewalld: firewall-cmd --add-port=514/tcp
ill

Firewall może blokować ruch na porcie 514, nawet gdy rsyslog jest poprawnie skonfigurowany.

Należy sprawdzić reguły firewalla i dodać wyjątek dla portu 514.

Po zmianie reguł warto przetestować połączenie komendą logger.

W systemie Ubuntu domyślnym narzędziem firewall jest ufw (Uncomplicated Firewall), który może być włączony nawet jeśli administrator nie konfigurował go ręcznie - wartość domyślna to ufw disable, ale warto to zweryfikować przed rozpoczęciem laboratorium, aby uniknąć frustrujących problemów z transmisją logów.

W systemach RHEL/CentOS/Fedora domyślnym firewallem jest firewalld, który używa stref (zones) do zarządzania regułami - aby otworzyć port 514, należy dodać go do strefy public lub internal za pomocą firewall-cmd --zone=public --add-port=514/tcp --permanent, a następnie przeładować konfigurację.

Niezależnie od używanego narzędzia firewall, po dodaniu reguł warto wykonać test połączenia w obie strony za pomocą logger -n IP_SERWERA -P 514 "TEST FIREWALLA" z klienta oraz sprawdzić tcpdump na serwerze, aby potwierdzić, że pakiety przechodzą przez firewall bez blokowania.

48/50
Cheat Sheet: komendy i flagi journalctl

Ściągawka poleceń journalctl

# Najważniejsze flagi journalctl
journalctl -b                    # Bieżący boot
journalctl -b -1                 # Poprzedni boot
journalctl -u ssh.service         # Konkretna usługa
journalctl -p err                 # Błędy i wyższe
journalctl -f                     # Podgląd na żywo
journalctl -n 50                  # Ostatnie 50 linii
journalctl --since "1 hour ago"   # Zakres czasu
journalctl -o json                # Format JSON
journalctl --list-boots           # Lista bootów
journalctl --disk-usage           # Użycie dysku
  • -b (boot) = tylko bieżący boot, -b -1 = poprzedni
  • -u (unit) = konkretna jednostka systemd
  • -p (priority) = filtr po ważności
  • -f (follow) = podgląd na żywo jak tail -f
  • -n (lines) = liczba linii do wyświetlenia
ill

journalctl to podstawowe narzędzie do odpytywania dziennika systemd.

Kluczowe flagi: -b (boot), -u (unit), -p (priority), -f (follow).

--disk-usage pokazuje ile miejsca zajmują logi - przydatne przy planowaniu pojemności.

Flaga -b (--boot) przyjmuje opcjonalny parametr numeryczny: -b oznacza bieżący boot, -b -1 oznacza poprzedni, -b -2 przedostatni i tak dalej, co jest szczególnie przydatne przy analizie awarii, która spowodowała restart systemu i chcemy sprawdzić logi z sesji poprzedzającej awarię.

Flaga --since i --until akceptują nie tylko daty bezwzględne, ale również wygodne skróty, takie jak "yesterday", "today", "now", a także kombinacje typu "1 hour ago" czy "-30min", co pozwala na szybkie zawężenie zakresu bez konieczności wpisywania pełnych dat i godzin.

Parametr --disk-usage wyświetla całkowity rozmiar dziennika oraz informację o tym, ile miejsca zajmują archiwa skompresowane i nieskompresowane, co jest przydatne do monitorowania wzrostu bazy journald i planowania przestrzeni dyskowej na partycji /var/log.

49/50
Cheat Sheet: opcje rotacji w /etc/logrotate.conf

Ściągawka konfiguracji logrotate

# Opcje logrotate
daily | weekly | monthly    # Częstotliwość
rotate 7                    # Liczba archiwów
compress                    # Kompresja gzip
delaycompress               # Opóźniona kompresja
dateext                     # Data w nazwie pliku
missingok                   # Nie błąd gdy brak pliku
notifempty                  # Nie rotuj pustego pliku
maxsize 100M                # Maksymalny rozmiar
postrotate / endscript     # Skrypt po rotacji

# Test konfiguracji
logrotate -d /etc/logrotate.conf
  • daily/weekly/monthly - częstotliwość rotacji
  • rotate N - liczba przechowywanych archiwów
  • compress - kompresja gzip, delaycompress - opóźniona
  • postrotate - skrypt wykonany po rotacji
  • logrotate -d = test (dry run) konfiguracji
ill

logrotate to niezbędne narzędzie do zarządzania plikami logów.

Opcja compress włącza kompresję gzip, delaycompress pomija kompresję najnowszego pliku.

postrotate wysyła sygnał HUP do rsyslog po rotacji, by przeładować deskryptory.

Dyrektywa maxsize 100M powoduje rotację pliku natychmiast po przekroczeniu rozmiaru 100 MB, niezależnie od zadeklarowanej częstotliwości (daily/weekly/monthly), co jest szczególnie przydatne dla bardzo ruchliwych serwerów WWW lub baz danych, które mogą wygenerować 100 MB logów w ciągu kilku minut.

Dyrektywa dateext dodaje do nazwy archiwizowanego pliku datę w formacie YYYYMMDD zamiast numeru sekwencyjnego, co ułatwia identyfikację archiwów i przydaje się przy długoterminowym przechowywaniu logów wymaganym przez regulacje prawne, takie jak RODO czy PCI DSS.

Przed wdrożeniem nowej konfiguracji logrotate warto wykonać test składni za pomocą logrotate -d /etc/logrotate.conf, który symuluje wykonanie rotacji bez faktycznego przenoszenia plików i raportuje wszystkie potencjalne problemy, takie jak brakujące pliki czy nieprawidłowe dyrektywy.

50/50
Cheat Sheet: narzędzia BASH do analizy logów na żywo

Ściągawka analizy logów w BASH

# Podgląd na żywo
tail -f /var/log/syslog
tail -f /var/log/auth.log | grep "Failed"

# Filtrowanie
grep "ERROR" /var/log/*.log
grep -r "192.168.1." /var/log/

# Analiza kolumn
awk '{print $1, $5}' /var/log/auth.log
cut -d' ' -f1-3 /var/log/syslog

# Cykliczne odświeżanie
watch -n 5 'tail -n 50 /var/log/syslog | grep ERROR'

# Statystyki
awk '{print $5}' /var/log/apache2/access.log | sort | uniq -c | sort -nr
  • tail -f = podgląd na żywo, grep = filtrowanie wzorców
  • awk '{print $1, $5}' = wybieranie kolumn z logu
  • cut -d' ' -f1-3 = wycinanie pól z delimitatorem
  • watch -n 5 'polecenie' = cykliczne odświeżanie
  • sort | uniq -c | sort -nr = statystyki częstotliwości
ill

Narzędzia BASH są niezastąpione w szybkiej analizie logów na żywo.

Kombinacja tail -f z grep pozwala monitorować konkretne zdarzenia w czasie rzeczywistym.

awk i cut są przydatne do wyodrębniania konkretnych pól z plików logów.

Polecenie watch -n 5 'tail -n 50 /var/log/syslog | grep ERROR' wykonuje cyklicznie co 5 sekund polecenie wyświetlenia ostatnich 50 linii logu z filtrowaniem błędów, co daje efekt automatycznie odświeżanego monitora zdarzeń w czasie rzeczywistym bez konieczności używania dedykowanych narzędzi monitorujących.

Potok sort | uniq -c | sort -nr to klasyczna sekwencja do generowania statystyk częstotliwości występowania wartości w logach - na przykład awk '{print $5}' /var/log/apache2/access.log | sort | uniq -c | sort -nr pokaże adresy IP posortowane według liczby żądań, co pozwala szybko zidentyfikować najbardziej aktywnych klientów lub potencjalne ataki DDoS.

Zaawansowani administratorzy łączą te narzędzia w skrypty monitorujące, które wysyłają alerty email lub SMS po wykryciu określonych wzorców w logach, na przykład po pojawieniu się komunikatu "Failed password" więcej niż 10 razy w ciągu minuty z tego samego adresu IP, co prawdopodobnie oznacza atak brute-force na SSH.