Monitorowanie sieci - Prezentacja syslog: Poradnik: Syslog i rsyslog w systemie Linux

Cel slajdu: Przedstawienie kompletnego przewodnika wdrożenia centralnego serwera rsyslog w systemie Linux oraz konfiguracji bezpiecznego przekazywania zdarzeń z innych stacji Linux i routerów MikroTik RouterOS.

Strona tytułowa i wprowadzenie do przewodnika

Niniejszy przewodnik stanowi rozszerzenie zagadnień audytu i telemetrii omówionych w Wykładzie 6 ('Logowanie zdarzeń i bezpieczeństwo'). Przedstawia techniczne szczegóły wdrożenia produkcyjnego serwera rsyslog oraz podłączenia heterogenicznych węzłów sieciowych.

Cel inżynierski: Zbudowanie niezawodnego repozytorium zdarzeń systemowych odpornego na awarie łączy i próby zatarcia śladów przez intruzów
System operacyjny serwera: System Linux (Debian 12 / Ubuntu 22.04 / 24.04 LTS) z demonem rsyslog w wersji 8.x wspierającym nowoczesną składnię RainerScript
Źródła zdarzeń: Inne stacje i serwery Linux (systemd-journald, rsyslog, bufor dyskowy) oraz urządzenia sieciowe MikroTik RouterOS (wersje v6 i v7)
Standardy i bezpieczeństwo: Zgodność ze specyfikacjami RFC 3164, RFC 5424 (IETF Syslog), szyfrowanie TLS (RFC 5425) oraz tunelowanie VPN

Protokół Syslog: Standard komunikacyjny warstwy aplikacji definiujący jednolity format oraz protokół przesyłania powiadomień diagnostycznych, zdarzeń audytowych i błędów w sieciach IP, sformalizowany w dokumentach RFC 3164 oraz RFC 5424.

Cel slajdu: Przedstawienie topologii i przepływu zdarzeń z węzłów brzegowych do dedykowanego serwera logów.

Podstawy architektury i standardy

Centralizacja logowania opiera się na architekturze klient-serwer. Urządzenia generujące zdarzenia (nadawcy) przesyłają rekordy przez sieć do scentralizowanego demona rsyslog (odbiornik), który porządkuje je w strukturze katalogów.

Nadawcy (Klienci): Stacje robocze, serwery aplikacyjne, routery brzegowe MikroTik, punkty dostępowe Wi-Fi oraz przełączniki zarządzalne
Medium transportowe: Protokół bezpołączeniowy UDP (niski narzut, podatność na straty) lub połączeniowy TCP (gwarancja dostarczenia) na standardowym porcie 514
Bezpieczeństwo sesji: Szyfrowanie kanału protokołem TLS na porcie 6514 dla komunikacji wychodzącej poza zaufaną podsieć LAN
Separacja danych: Dynamiczne rozdzielanie napływających logów do odrębnych podkatalogów na podstawie nazwy hosta (%HOSTNAME%) i daty zdarzenia

Zasada integralności logów: Serwer logów powinien być maszyną dedykowaną z wyłączonymi zbędnymi usługami publicznymi. Dostęp do katalogu /var/log/remote/ powinien być ściśle ograniczony wyłącznie do uprawnionych audytorów i systemów klasy NMS/SIEM.

Cel slajdu: Porównanie historycznego formatu BSD z obowiązującym standardem IETF i uzasadnienie konieczności stosowania RFC 5424.

Podstawy architektury i standardy

Przez dekady w systemach UNIX dominował nieoficjalny format BSD Syslog (opisany informacyjnie w RFC 3164). Dopiero standard RFC 5424 wprowadził rygorystyczne reguły składniowe.

Standard BSD (RFC 3164): Definiuje nagłówek PRI, datę w formacie 'Mmm dd hh:mm:ss' oraz wolny tekst komunikatu. Brak roku powodował problemy przy archiwizacji na przełomie grudnia i stycznia
Standard IETF (RFC 5424): Wprowadza numer wersji protokołu, obowiązkowy znacznik czasu zgodny z ISO 8601 z przesunięciem strefowym oraz precyzją mikrosekundową
Dane strukturalne (Structured Data): Bloki par klucz-wartość ujęte w nawiasy kwadratowe [SD-ID param="val"], eliminujące konieczność pisania skomplikowanych wyrażeń regularnych (regex)
Dopasowanie do urządzeń: Nowoczesne dystrybucje Linux domyślnie wspierają RFC 5424. Urządzenia MikroTik RouterOS oferują przełącznik trybu (bsd-syslog=yes/no)

Przykład parsowania: W formacie RFC 3164 data "Feb 29 12:00:00" nie pozwala określić roku przestępnego. W formacie RFC 5424 zapis "2024-02-29T12:00:00.000000Z" jednoznacznie określa moment wystąpienia w skali globalnej.

Cel slajdu: Szczegółowe omówienie podziału na kategorie systemowe oraz stopnie pilności zdarzeń.

Podstawy architektury i standardy

Każdy komunikat w protokole Syslog jest precyzyjnie sklasyfikowany przy użyciu dwóch współrzędnych: źródła pochodzenia (Facility) oraz poziomu dotkliwości (Severity).

Facility (Kody źródeł 0–23): Określa podsystem, który wygenerował zdarzenie. Standard rezerwuje kody 0–15 dla funkcji systemowych (kern, mail, daemon, authpriv) oraz 16–23 (local0–local7) dla urządzeń sieciowych i aplikacji administratora
Severity (Ważność zdarzenia 0–7): Określa pilność komunikatu. Skala biegnie od poziomu 0 (Emergency – całkowita awaria systemu) do 7 (Debug – informacje developerskie)
Konwencja local0..local7: Urządzenia sieciowe MikroTik, Cisco oraz zapory ogniowe najczęściej konfiguruje się do wysyłania komunikatów z kodem local0 lub local1
Poufność audytowa: Kody 'auth' (4) i 'authpriv' (10) zawierają dane o logowaniu użytkowników i muszą być chronione przed dostępem niepowołanych procesów

Hierarchia ważności: Reguły filtrowania w rsyslog często wykorzystują relację nierówności, np. zapis kern.warning oznacza przechwytywanie zdarzeń jądra o poziomie warning (4) oraz wszystkich poważniejszych: error (3), crit (2), alert (1) i emerg (0).

Cel slajdu: Przedstawienie algorytmu obliczania pojedynczej liczby priorytetu PRI oraz operacji odwrotnej (dekodowania).

Podstawy architektury i standardy

Aby zminimalizować rozmiar nagłówka w pakietach UDP, twórcy protokołu Syslog połączyli kod źródła (Facility) oraz stopień ważności (Severity) w jedną wartość liczbową zwaną priorytetem (PRI).

Liczba PRI w nawiasach ostrych: Komunikat przesyłany przez sieć zawsze zaczyna się od zapisu <PRI>, np. <134> lub <37>
Operacja kodowania: PRI = (Facility * 8) + Severity. Mnożenie przez 8 odpowiada przesunięciu bitowemu w lewo o 3 bity (Facility << 3 | Severity)
Operacja dekodowania: Aby odzyskać kod źródła, wykonujemy dzielenie całkowite: Facility = PRI div 8. Aby odzyskać ważność: Severity = PRI mod 8 (lub operacja bitowa PRI & 0x07)
Maksymalny zakres: Ponieważ Facility przyjmuje wartości 0–23, a Severity 0–7, maksymalna wartość PRI wynosi (23 * 8) + 7 = 191

Weryfikacja wiersza poleceń: Jeśli w surowym zrzucie pakietów tcpdump widzimy nagłówek <189>: 189 / 8 = 23 (local7), 189 % 8 = 5 (notice). Oznacza to komunikat o statusie Notice ze źródła local7.

Cel slajdu: Przedstawienie budowy nowoczesnego rekordu logu z mikrosekundową precyzją UTC oraz blokami danych strukturalnych.

Podstawy architektury i standardy

Standard RFC 5424 eliminuje chaos interpretacyjny, wprowadzając rygorystyczny format nagłówka podzielony spacjami na ściśle określone pola.

PRI i VERSION: Zawiera liczbę priorytetu oraz bezpośrednio po niej numer wersji (obecnie zawsze 1)
TIMESTAMP ISO 8601: Format RRRR-MM-DDTHH:MM:SS.mmmmmm+/-HH:MM. Znak Z oznacza czas uniwersalny UTC, eliminując pomyłki wynikające ze zmian czasu letniego/zimowego
HOSTNAME i APP-NAME: Precyzyjna identyfikacja hosta (FQDN) oraz nazwy demona (zastępuje dawny tag BSD)
PROCID i MSGID: Identyfikator PID procesu oraz identyfikator rodzaju zdarzenia wykorzystywany przez systemy korelacji
STRUCTURED-DATA (SD): Pola par klucz=wartość z unikalnym identyfikatorem korporacyjnym (Private Enterprise Number IANA)

Brak danych (NILVALUE): Jeśli dane pole nagłówka (np. PROCID lub MSGID) nie jest znane, standard RFC 5424 nakazuje wstawienie pojedynczego znaku dywizu - jako wartości pustej (NILVALUE), co zachowuje pozycje kolejnych pól.

Cel slajdu: Zrozumienie modularnej budowy demona rsyslog oraz zalet nowoczesnej składni konfiguracyjnej RainerScript.

Konfiguracja serwera centralnego

Demon rsyslog (Rocket-fast System for Log Processing) to nowoczesny, wielowątkowy system przetwarzania zdarzeń w Linux. Zastąpił on archaicznego demona sysklogd.

Modularna architektura wejścia-wyjścia: Wszystkie funkcje realizowane są przez dedykowane moduły: wejściowe (im* - input modules) oraz wyjściowe (om* - output modules)
Wewnętrzny system kolejek: Komunikaty po odebraniu trafiają do głównej kolejki pamięciowej, co uniezależnia szybkość odbioru pakietów sieciowych od szybkości zapisu na dysku
Język RainerScript: Wprowadzony w rsyslog v6 i rozwinięty w v8 deklaratywny język konfiguracyjny z pełną obsługą bloków warunkowych if/then/else, funkcji i obiektów
Odejście od składni legacy: Przestarzałe dyrektywy z prefiksem dolara (np. $ModLoad, $InputTCPServerRun) są podatne na błędy kolejności i nie powinny być stosowane w nowych instalacjach

Zasada działania instrukcji stop: Słowo kluczowe stop (dawniej & ~) w RainerScript kończy przetwarzanie danego komunikatu w bieżącym potoku, co uniemożliwia jego zduplikowanie w standardowych logach systemowych (/var/log/syslog).

Cel slajdu: Prawidłowa konfiguracja systemu plików serwera Linux pod kątem bezpiecznego przechowywania logów zdalnych.

Konfiguracja serwera centralnego

Domyślnie demon rsyslog w nowoczesnych dystrybucjach Linux (Debian, Ubuntu) działa z obniżonymi uprawnieniami nieuprzywilejowanego użytkownika 'syslog' należącego do grupy 'adm'.

Lokalizacja magazynu: Zaleca się utworzenie odrębnego katalogu /var/log/remote/ dedykowanego wyłącznie dla hostów zewnętrznych
Uprawnienia katalogu głównego: Katalog /var/log/remote musi mieć prawa 0750 (rwxr-x---), gdzie właścicielem jest syslog, a grupą adm
Maska tworzenia plików: W konfiguracji rsyslog definiujemy globalne parametry $FileCreateMode 0640 oraz $DirCreateMode 0750
Prawa grupy adm: Członkowie grupy adm (administratorzy systemowi) mają prawo odczytu, co umożliwia analizę bez konieczności używania konta root
Osobny punkt montowania: W środowiskach produkcyjnych katalog /var/log/remote powinien być osobną partycją dyskową LVM lub montowaniem NFS/iSCSI

Zabezpieczenie przed atakiem DoS na dysk: Jeśli partycja /var/log ulegnie zapełnieniu w 100%, system Linux może przestać rejestrować nowe procesy i uniemożliwić logowanie po SSH. Umieszczenie /var/log/remote na odrębnym wolumenie dyskowym chroni system bazowy serwera.

Cel slajdu: Konfiguracja modułów wejściowych imudp oraz imtcp w rsyslog z wykorzystaniem składni RainerScript.

Konfiguracja serwera centralnego

Domyślnie po instalacji rsyslog w systemie Linux nasłuchuje wyłącznie na lokalnym gnieździe uniksowym /dev/log. Odbiór logów przez sieć wymaga jawnego załadowania modułów imudp i imtcp.

Moduł imudp: Odpowiada za nasłuch bezpołączeniowych datagramów UDP. Jest lekki i wysoce wydajny, niezbędny do obsługi urządzeń MikroTik RouterOS i przełączników sieciowych
Moduł imtcp: Odpowiada za zestawianie połączeń TCP. Zapewnia niezawodny strumień danych z mechanizmem retransmisji, idealny dla klientów Linux
Plik konfiguracyjny: Zaleca się umieszczanie konfiguracji serwera w pliku o wysokim priorytecie: /etc/rsyslog.d/10-server.conf
Restart i weryfikacja: Po edycji pliku wykonujemy restart serwisu: sudo systemctl restart rsyslog i sprawdzamy stan gniazd poleceniem ss -tulpn | grep 514

Wiązanie z konkretnym adresem IP: Domyślnie rsyslog nasłuchuje na wszystkich interfejsach (0.0.0.0). Jeśli serwer posiada dedykowaną kartę sieciową do zarządzania, możemy ograniczyć nasłuch: input(type="imtcp" port="514" address="192.168.1.100").

Cel slajdu: Wykorzystanie mechanizmu szablonów (templates) do automatycznej segmentacji logów według nazwy urządzenia i daty.

Konfiguracja serwera centralnego

Zapisywanie wszystkich logów z kilkudziesięciu urządzeń do jednego pliku doprowadziłoby do całkowitej nieczytelności repozytorium. Rsyslog udostępnia potężny mechanizm szablonów dynamicznych.

Koncepcja dynaFile: Szablon typu string definiujący docelową ścieżkę zapisu na podstawie zmiennych zawartych w przetwarzanym komunikacie
Automatyczne tworzenie katalogów: Jeśli podkatalog dla danego urządzenia nie istnieje, rsyslog utworzy go w locie z prawami zdefiniowanymi w $DirCreateMode
Zmienna %HOSTNAME% vs %FROMHOST-IP%: Wartość %HOSTNAME% pochodzi z nagłówka komunikatu. Jeśli zależy nam na bezpieczeństwie i uniknięciu podszywania się, zaleca się użycie adresu źródłowego %FROMHOST-IP%
Rotacja dzienna w nazwie: Zastosowanie znaczników roku, miesiąca i dnia w nazwie pliku eliminuje konieczność natychmiastowej rotacji zewnętrznej i ułatwia archiwizację

Zaawansowany szablon z podziałem na aplikacje:
string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%-%PROGRAMNAME%.log" rozdziela dodatkowo logi według demona (np. sshd, firewall, dhcp).

Cel slajdu: Zapobieganie zanieczyszczaniu lokalnych plików systemowych przez logi z urządzeń sieciowych za pomocą dedykowanych zestawów reguł.

Konfiguracja serwera centralnego

Jednym z najczęstszych problemów w niewłaściwie skonfigurowanym serwerze syslog jest 'zalewanie' lokalnych plików (/var/log/syslog i /var/log/messages) milionami wpisów z zewnętrznych routerów.

Zestawy reguł (ruleset): Pozwalają na utworzenie niezależnych, równoległych potoków przetwarzania zdarzeń całkowicie odseparowanych od kolejki domyślnej
Wiązanie z wejściem: Dyrektywa input(type="imudp" ... ruleset="RegulyZdalne") kieruje pakiety z danego portu bezpośrednio do wskazanego rulesetu
Instrukcja stop: Umieszczona na końcu reguły ruleset natychmiast zatrzymuje przetwarzanie wiadomości, uniemożliwiając jej przejście do reguł ogólnych systemu
Czystość audytowa: Lokalny system Linux zachowuje w /var/log/syslog wyłącznie własne logi serwisowe, a ruch sieciowy trafia czysto do /var/log/remote/

Uwaga weryfikacyjna: Przed zrestartowaniem demona rsyslog po wprowadzeniu zmian w plikach konfiguracyjnych należy zawsze sprawdzić poprawność składni poleceniem: sudo rsyslogd -N1. Kod błędu 0 oznacza poprawną składnię.

Cel slajdu: Ograniczenie dostępu do portu 514 wyłącznie do zaufanych adresów IP i podsieci zarządzających.

Konfiguracja serwera centralnego

Domyślnie otwarcie portu w rsyslog udostępnia usługę każdemu pakietowi trafiającemu do serwera. Protokół UDP jest podatny na podszywanie się pod źródłowy adres IP (IP spoofing).

Filtracja źródłowa: Zezwolenia na zaporze sieciowej muszą bezwzględnie definiować dozwolone adresy IP nadawców (from <IP/SUBNET>)
Separacja protokołów: Zaleca się otwieranie portu 514 osobno dla UDP (dla urządzeń sieciowych) i TCP (dla stacji roboczych)
Komentarze w regułach UFW: Dodanie parametru comment ułatwia późniejszy audyt reguł bezpieczeństwa
Alternatywa w nftables/iptables: Odpowiednik niskopoziomowy: iptables -A INPUT -p udp -s 192.168.1.0/24 --dport 514 -j ACCEPT
Blokada domyślna: Wszystkie pakiety syslog pochodzące z innych podsieci powinny być bezwzględnie zrzucane (DROP)

Zagrożenie atakiem Amplification/Reflection: Pozostawienie otwartego portu UDP w sieci publicznej naraża serwer na wykorzystanie w atakach DDoS oraz zalanie niechcianym ruchem śmieciowym.

Cel slajdu: Przedstawienie roli lokalnego demona rsyslog na stacji klienckiej jako pośrednika i bufora zdarzeń.

Konfiguracja klienta Linux

W systemie Linux aplikacje nie wysyłają logów bezpośrednio przez sieć. Zamiast tego komunikują się z lokalnym gniazdem /dev/log obsługiwanym przez demona rsyslog lub systemd-journald.

Rola lokalnego pośrednika: Lokalny demon rsyslog odbiera komunikaty z jądra i aplikacji, filtruje je, a następnie kieruje zarówno do lokalnych plików, jak i przez sieć do serwera
Izolacja aplikacji od awarii sieci: Jeśli sieć ulegnie awarii, aplikacje użytkownika (np. serwer WWW Apache/Nginx) nie zawieszają się w oczekiwaniu na odpowiedź serwera logów
Moduł omfwd: Wbudowany w rsyslog moduł wyjściowy realizujący przekazywanie sieciowe (Output Module Forwarding)
Stara vs nowa składnia: Klasyczny zapis *.* @@192.168.1.100:514 jest funkcjonalnym odpowiednikiem nowoczesnego bloku action(type="omfwd" ... protocol="tcp")

Składnia znaków @: W klasycznym formacie rsyslog pojedynczy znak @ oznacza transport UDP (np. @192.168.1.100:514), natomiast podwójny znak @@ oznacza transport TCP (np. @@192.168.1.100:514).

Cel slajdu: Wdrożenie mechanizmu buforowania dyskowego (Disk-Assisted Queue) na wypadek awarii sieci lub serwera centralnego.

Konfiguracja klienta Linux

Standardowa wysyłka sieciowa bez bufora dyskowego traci logi w momencie zresetowania klienta lub awarii łącza trwającej dłużej niż pojemność bufora RAM.

Kolejka LinkedList: Wielowątkowa kolejka w pamięci operacyjnej o zmiennym rozmiarze, zapewniająca minimalne opóźnienia w normalnym trybie pracy
Bufor dyskowy (Disk-Assisted): Po przekroczeniu limitu elementów w pamięci RAM rsyslog automatycznie zrzuca nadmiarowe komunikaty do plików w katalogu /var/spool/rsyslog/
Parametr queue.saveonshutdown: Gwarantuje, że podczas restartu lub zamykania stacji klienckiej zawartość pamięci RAM zostanie bezpiecznie zapisana na nośnik trwały
Nieskończone ponawianie (resumeRetryCount -1): Klient nigdy nie porzuca prób ponownego połączenia z serwerem i wznawia wysyłkę natychmiast po usunięciu awarii

Katalog bufora: Przed aktywacją kolejki upewnij się, że katalog bufora istnieje i ma poprawne uprawnienia:
sudo mkdir -p /var/spool/rsyslog && sudo chown -R syslog:adm /var/spool/rsyslog.

Cel slajdu: Przedstawienie zasad konfiguracji szybkiej wysyłki UDP w prostych sieciach lokalnych oraz analiza ograniczeń protokołu.

Konfiguracja klienta Linux

Protokół UDP przez lata był domyślnym standardem transportowym protokołu Syslog ze względu na minimalny narzut i prostotę implementacji.

Zasada 'Wyślij i zapomnij': System wysyła datagram UDP pod adres 192.168.1.100:514 bez oczekiwania na jakąkolwiek odpowiedź zwrotną ze strony serwera
Brak kontroli przeciążenia: W przypadku zalania łącza pakiety UDP są po cichu odrzucane przez przełączniki sieciowe, a nadawca nigdy się o tym nie dowiaduje
Długość komunikatu i MTU: Specyfikacja RFC 3164 ogranicza całkowity rozmiar komunikatu do 1024 bajtów (co bez trudu mieści się w standardowym MTU Ethernetu 1500 B bez fragmentacji IP; nowszy RFC 5424 zaleca min. 2048 B)
Kiedy stosować UDP?: W stabilnych sieciach lokalnych LAN o niskim obciążeniu lub na prostych urządzeniach IoT pozbawionych stosu TCP

Weryfikacja wysyłki UDP: Na kliencie możemy podejrzeć wysyłane pakiety narzędziem tcpdump:
sudo tcpdump -i any -nn udp port 514.

Cel slajdu: Wdrożenie połączeniowego przesyłu zdarzeń z potwierdzeniem dostarczenia na poziomie warstwy transportowej.

Konfiguracja klienta Linux

Wykorzystanie protokołu TCP (Transmission Control Protocol) rozwiązuje problem zawodności UDP. Przesyłanie komunikatów opiera się na ciągłym strumieniu danych z kontrolą przepływu.

Potwierdzenia odbioru (ACK): Każdy rekord przekazany przez gniazdo TCP musi zostać potwierdzony przez stos sieciowy odbiorcy
Automatyczna retransmisja: Jeśli pakiet zostanie zgubiony przez router pośredni, jądro systemu Linux powtarza transmisję bez ingerencji aplikacji
Współpraca z kolejkami rsyslog: Dopiero gdy rsyslog otrzyma błąd zapisu do gniazda TCP, przełącza się na buforowanie w pamięci RAM lub na dysku
Znacznik podwójnej małpy (@@): W klasycznych plikach rsyslog.conf zapis @@ wskazuje protokół TCP na porcie 514

Framing w strumieniu TCP (Octet Counting): Ponieważ TCP jest protokołem strumieniowym (nie zachowuje granic datagramów), standard RFC 6587 definiuje metodę Octet Counting (poprzedzenie komunikatu długością w bajtach), co zapobiega sklejaniu sąsiednich komunikatów.

Cel slajdu: Optymalizacja pasma i rozmiaru bazy logów poprzez selektywne wysyłanie wyłącznie kluczowych zdarzeń audytowych i błędów.

Konfiguracja klienta Linux

Przesyłanie każdego pojedynczego komunikatu diagnostycznego (np. z crona uruchamianego co minutę) z setek stacji roboczych niepotrzebnie obciąża serwer logów. Dobrą praktyką jest selekcja źródeł.

Selektory klasyczne: Zapis 'auth,authpriv.*' przekazuje wszystkie zdarzenia związane z logowaniem, podnoszeniem uprawnień i bezpieczeństwem
Filtrowanie według poziomu: Dyrektywa '*.err' powoduje wysłanie wyłącznie zdarzeń o stopniu pilności Error (3), Critical (2), Alert (1) i Emergency (0)
Filtry właściwości (Property-based): Możliwość filtrowania po nazwie programu ($programname), treści wiadomości ($msg) lub identyfikatorze procesu
Ochrona łącza WAN: W oddziałach firmy spiętych wolnymi łączami VPN selektywna filtracja redukuje ruch telemetryczny o ponad 90%

Wykluczanie kategorii (none): Składnia *.*;mail.none;cron.none oznacza przekazanie wszystkich logów z wyjątkiem podsystemu poczty i harmonogramu zadań cron.

Cel slajdu: Zapewnienie poprawnego przekazywania logów z nowoczesnych serwisów zarządzanych przez systemd do demona rsyslog.

Konfiguracja klienta Linux

W nowoczesnych dystrybucjach Linux menedżerem rozruchu i serwisów jest systemd, który gromadzi logi w formacie binarnym za pośrednictwem demona systemd-journald.

Przechwytywanie strumieni stdout/stderr: Serwisy uruchamiane przez pliki .service (np. Docker, Nginx, WireGuard) wypisują logi na standardowe wyjście, które trafia bezpośrednio do journald
Gniazdo /run/systemd/journal/syslog: Aktywacja parametru 'ForwardToSyslog=yes' powoduje przekazywanie kopii komunikatów do tradycyjnego gniazda obsługiwanego przez rsyslog
Moduł imjournal vs imuxsock: Moduł imjournal czyta bezpośrednio z bazy binarnej journala, natomiast moduł imuxsock czyta z gniazda uniksowego. W dystrybucjach Debian/Ubuntu zaleca się imuxsock z ForwardToSyslog
Spójność metadanych: Rsyslog automatycznie mapuje identyfikatory systemd (np. _SYSTEMD_UNIT=nginx.service) na standardowe pola Facility i APP-NAME

Polecenie journalctl: Weryfikacja bezpośrednia na stacji klienckiej:
journalctl -u ssh.service -f pozwala na podgląd tych samych rekordów, które rsyslog wysyła na serwer centralny.

Cel slajdu: Wykorzystanie narzędzia logger do ręcznego generowania zdarzeń testowych o zadanym priorytecie i weryfikacji ich odbioru.

Konfiguracja klienta Linux

Standardowe uniksowe polecenie 'logger' jest podstawowym narzędziem administratora do weryfikacji konfiguracji logowania bez konieczności symulowania rzeczywistych awarii.

Flaga -p (Priority): Umożliwia określenie źródła i ważności w formacie facility.severity (np. auth.notice, kern.crit)
Flaga -t (Tag): Ustawia nazwę procesu/aplikacji generującej zdarzenie (pole APP-NAME w RFC 5424)
Flagi -n (Host) oraz -P (Port): Pozwalają na wysłanie pakietu bezpośrednio na zdalny adres IP, omijając lokalny proces rsyslog (idealne do testowania reguł zapory serwera)
Wybór protokołu (-d / -T): Flaga -d wymusza protokół UDP (datagram), natomiast flaga -T wymusza nawiązanie połączenia TCP

Skrypt automatyzujący testy: Administrator może umieścić wywołanie logger -p local0.alert "TEST_PING_FAIL" w skrypcie watchdog, aby weryfikować działanie reguł alarmowych w systemie LibreNMS.

Cel slajdu: Zrozumienie dwupoziomowego modelu logowania w RouterOS: definicji celów akcji (Actions) oraz filtrów reguł (Rules).

Zdalne logowanie z MikroTik RouterOS

Podsystem logowania w MikroTik RouterOS (zarówno w wersji v6, jak i v7) opiera się na rozdziale definicji miejsca zapisu (Actions) od kryteriów selekcji zdarzeń (Rules).

Tematy zdarzeń (Topics): RouterOS nie stosuje tradycyjnych kodów Facility wewnątrz systemu; zamiast tego zdarzenia oznaczane są etykietami tematycznymi (np. firewall, account, dhcp, wireless, ospf)
Dwupoziomowa konfiguracja: Najpierw tworzymy akcję zdalną (/system logging action), określając adres IP serwera, a następnie tworzymy regułę (/system logging add), przypisującą tematy do tej akcji
Ochrona kości Flash: Zapisywanie tysięcy wpisów zapory ogniowej na dysk flash routera (action=disk) potrafi zniszczyć pamięć NAND w ciągu kilku miesięcy
Ulokowanie w pamięci RAM: Domyślna akcja 'memory' przechowuje tylko 1000 ostatnich linii, co w przypadku awarii zasilania uniemożliwia ustalenie jej przyczyny

Podgląd konfiguracji w CLI RouterOS:
/system logging print wyświetla aktualne reguły, a /system logging action print wyświetla parametry celów akcji.

Cel slajdu: Precyzyjna konfiguracja akcji typu remote ze zdefiniowaniem adresu IP serwera, portu oraz formatu nagłówka.

Zdalne logowanie z MikroTik RouterOS

Aby router MikroTik mógł wysyłać komunikaty przez sieć, należy utworzyć profil akcji wskazujący parametry serwera rsyslog.

Parametr target=remote: Deklaruje, że dane wyjściowe będą pakowane w datagramy sieciowe UDP i kierowane pod wskazany adres IP
Przełącznik bsd-syslog=no: Flaga formatu znacznika czasu. Ustawienie wartości 'no' (lub w v7 syslog-time-format=iso8601) nakazuje routerowi generowanie daty i czasu w standardzie ISO 8601 ze strefą czasową zamiast tradycyjnego skróconego formatu BSD. Sam pakiet zachowuje strukturę RFC 3164
Wybór syslog-facility=local0: Przypisuje zdarzeniom kod źródła 16, co pozwala serwerowi Linux na natychmiastowe rozpoznanie, że nadawcą jest urządzenie sieciowe
Opcja syslog-severity=auto: RouterOS automatycznie przypisuje wagę: zdarzenia critical otrzymują kod 2, error kod 3, warning kod 4, a info kod 6

Adres źródłowy routera: Jeśli router posiada wiele interfejsów i adresów IP, upewnij się, że tablica routingu kieruje pakiety z adresu dozwolonego na zaporze serwera rsyslog (np. z sieci zarządzającej). Można to wymusić konfigurując trasę statyczną do serwera logów.

Cel slajdu: Właściwy dobór kategorii komunikatów przesyłanych do serwera rsyslog oraz wykluczanie zbędnego szumu informacyjnego.

Zdalne logowanie z MikroTik RouterOS

Samo utworzenie akcji 'zdalny-syslog' nie powoduje wysyłania jakichkolwiek danych. Należy jawnie przypisać reguły łączące tematy (topics) z nowo utworzoną akcją.

Podstawowe kategorie awarii: Zdarzenia o tematach 'critical', 'error' oraz 'warning' powinny być bezwzględnie przesyłane do serwera centralnego
Audyt kont i bezpieczeństwo (account): Rejestruje każde udane i nieudane logowanie do routera (przez WinBox, SSH, WWW, API) oraz zmianę konfiguracji
Operator negacji (!): Znak wykrzyknika przed nazwą tematu oznacza wykluczenie (np. !dns wyklucza zapytania klientów do wbudowanego serwera DNS cache)
Łączenie tematów przecinkiem: Zapis topics=system,info oznacza zdarzenia systemowe o statusie informacyjnym (np. restart interfejsu)

Przestroga przed tematem !dns: Jeśli router pełni rolę serwera DNS dla kilkudziesięciu stacji, włączenie tematu topics=dns generuje setki pakietów na sekundę, co może całkowicie sparaliżować serwer logów.

Cel slajdu: Monitorowanie zablokowanych pakietów (Drop) i skanowania portów z czytelnym oznakowaniem prefiksem (Log Prefix).

Zdalne logowanie z MikroTik RouterOS

Reguły zapory ogniowej w RouterOS posiadają atrybut log=yes oraz log-prefix. Prefiks ten jest wstawiany na początku wiadomości i stanowi kluczowy element późniejszej analizy automatycznej.

Atrybut log-prefix: Krótki łańcuch znakowy jednoznacznie identyfikujący regułę zapory (np. FW_DROP_WAN, PORT_SCAN, BLACKLIST)
Szczegółowość rekordu: RouterOS automatycznie dołącza nazwę interfejsu wejściowego/wyjściowego, adres MAC, protokół (TCP/UDP/ICMP), flagi (np. SYN) oraz porty
Ułatwienie dla SIEM i Fail2ban: Dzięki prefiksowi skrypty na serwerze Linux mogą błyskawicznie wyłuskać adres IP intruza za pomocą polecenia grep 'FW_DROP_WAN:'
Ograniczanie częstotliwości (Log Limiting): Aby skanowanie portów nie zalało serwera, w /ip firewall filter stosujemy parametr psd (Port Scan Detection) lub limit

Zasada wydajnościowa zapory: Nigdy nie włączaj log=yes na regule akceptującej ruch Established/Related! Loguj wyłącznie pakiety odrzucane (Drop) w łańcuchu input oraz pakiety tworzące nowe podejrzane połączenia w łańcuchu forward.

Cel slajdu: Centralny audyt przydzielania adresów IP, asocjacji użytkowników sieci bezprzewodowych oraz nawiązywania połączeń tunelowych.

Zdalne logowanie z MikroTik RouterOS

Router brzegowy pełni najczęściej rolę bramy domyślnej, serwera DHCP, kontrolera sieci bezprzewodowej Wi-Fi oraz koncentratora VPN.

Audyt dzierżaw DHCP (dhcp,info): Rejestruje moment przydzielenia adresu IP (assigned), odnowienia dzierżawy (renewed) oraz zwolnienia (deassigned) z powiązaniem do adresu fizycznego MAC
Telemetria sieci bezprzewodowej (wireless/caps): Pozwala na śledzenie roamingu klientów pomiędzy punktami dostępowymi (AP), siły sygnału RSSI oraz błędów uwierzytelniania WPA2/WPA3
Sesje tunelowe VPN (ppp,account,wireguard): Rejestruje czas trwania połączeń pracowników zdalnych, ich publiczne adresy źródłowe oraz wolumen przesłanych bajtów
Rozliczalność i RODO: Centralne archiwum logów DHCP pozwala po miesiącach ustalić, które konkretnie urządzenie fizyczne korzystało z danego adresu IP w chwili incydentu

Przykładowy rekord DHCP w rsyslog:
router-mikrotik dhcp,info: defconf assigned 192.168.1.155 to 3C:06:30:11:22:33 (laptop-zarzad).

Cel slajdu: Rejestracja prób logowania przez protokoły SSH, WinBox i WebFig oraz wykrywanie ataków siłowych.

Zdalne logowanie z MikroTik RouterOS

Urządzenia sieciowe wystawione na styk z operatorem WAN są celem nieustannych ataków słownikowych i prób zgadywania haseł przez zautomatyzowane botnety.

Temat account: Kluczowy podsystem audytowy rejestrujący nazwę użytkownika, adres IP, metodę dostępu (WinBox, SSH, Web, API) oraz wynik autoryzacji
Błędy logowania (login failure): Generowane przy podaniu błędnego hasła ze statusem warning lub critical
Modyfikacje konfiguracji: Pomyślne zalogowanie administratora i wydanie polecenia (np. dodanie reguły zapory) jest odnotowywane z dokładnym czasem i nazwą konta
Obrona aktywna: Logi przesłane do serwera rsyslog mogą być w czasie rzeczywistym analizowane przez narzędzie Fail2ban, które automatycznie dodaje adres atakującego do czarnej listy routera

Zasada minimalizacji usług zarządzających: W celach bezpieczeństwa wyłącz nieużywane usługi w /ip service (np. telnet, ftp, www) i pozostaw wyłącznie zaszyfrowany SSH oraz WinBox na niestandardowych portach lub w dedykowanej strefie VPN.

Cel slajdu: Eliminacja ryzyka podsłuchu i modyfikacji logów w sieci tranzytowej za pomocą kryptograficznego tunelu TLS na porcie 6514.

Bezpieczeństwo i zaawansowany transport

Standardowy protokół Syslog przesyła wszystkie informacje jawnym tekstem. W przypadku przesyłania danych przez Internet lub współdzieloną sieć korporacyjną stanowi to krytyczne zagrożenie.

Specyfikacja RFC 5425: Oficjalny standard IETF definiujący transport komunikatów syslog w bezpiecznym tunelu TLS (Transport Layer Security)
Standardowy port TCP 6514: Dedykowany port IANA zarezerwowany dla bezpiecznego protokołu Syslog-over-TLS
Zagrożenia transmisji jawnej: W logach pojawiają się wrażliwe metadane: nazwy kont systemowych, próby błędnych haseł, wersje oprogramowania czy adresacja wewnętrzna
Pakiet rsyslog-gnutls: Rozszerzenie demona rsyslog w systemie Linux realizujące obsługę protokołów kryptograficznych TLS 1.2 i TLS 1.3

Wymóg normy PCI-DSS (Rozdział 10): Transmisja danych audytowych przez sieci publiczne lub bezprzewodowe musi być bezwzględnie szyfrowana za pomocą silnych protokołów kryptograficznych.

Cel slajdu: Procedura krok po kroku generowania urzędu certyfikacji CA, certyfikatu serwera i klientów za pomocą OpenSSL.

Bezpieczeństwo i zaawansowany transport

Prawidłowa implementacja protokołu TLS wymaga utworzenia lokalnej infrastruktury klucza publicznego (PKI) opartej na certyfikatach X.509.

Lokalny urząd Root CA: Organizacja tworzy własny, prywatny urząd certyfikacji (ca.pem), który podpisuje certyfikaty serwera i urządzeń klienckich
Certyfikat serwera (server-cert.pem): Zawiera nazwę FQDN lub adres IP serwera logów. Klient weryfikuje ten certyfikat podczas nawiązywania połączenia
Certyfikat klienta (client-cert.pem): Umożliwia serwerowi weryfikację tożsamości klienta (wzajemne uwierzytelnienie - Mutual TLS / mTLS)
Poufność kluczy prywatnych: Pliki *.key muszą mieć bezwzględnie uprawnienia 0400 i być dostępne wyłącznie dla użytkownika root lub syslog

Uprawnienia plików kluczy: Po skopiowaniu certyfikatów do katalogu /etc/rsyslog.d/keys/ upewnij się, że użytkownik syslog ma prawo odczytu kluczy prywatnych:
sudo chown -R syslog:adm /etc/rsyslog.d/keys/ && sudo chmod 400 /etc/rsyslog.d/keys/*-key.pem.

Cel slajdu: Pełna konfiguracja sterownika gtls po stronie serwera i klienta Linux z wzajemną autoryzacją.

Bezpieczeństwo i zaawansowany transport

Do obsługi szyfrowania rsyslog wykorzystuje moduł sieciowy lmnsd_gtls oparty na bibliotece GnuTLS (pakiet rsyslog-gnutls).

Sterownik DefaultNetstreamDriver: Wskazuje 'gtls' jako domyślny silnik strumieniowy dla modułów sieciowych imtcp oraz omfwd
Tryb StreamDriver.Mode=1: Wymusza bezwzględne stosowanie szyfrowania TLS (odrzuca połączenia nieszyfrowane w czystym tekście)
Autoryzacja x509/name: Serwer i klient weryfikują podpis CA oraz sprawdzają, czy nazwa w certyfikacie (Common Name / SAN) zgadza się z listą dozwolonych węzłów
Port 6514: Gniazdo nasłuchowe dedykowane dla bezpiecznych strumieni, odseparowane od standardowego portu 514

Instalacja wymaganego pakietu: W systemach Debian/Ubuntu obsługa TLS nie jest wbudowana w pakiet podstawowy. Wymaga wydania polecenia: sudo apt install -y rsyslog-gnutls.

Cel slajdu: Zabezpieczenie transmisji UDP ze sprzętowych routerów MikroTik za pomocą tunelu WireGuard lub IPsec.

Bezpieczeństwo i zaawansowany transport

RouterOS nie wspiera natywnego szyfrowania Syslog-over-TLS (RFC 5425). Aby bezpiecznie przesyłać logi z odległych oddziałów firmy przez publiczny Internet, ruch ten kapsułkuje się w tunelu VPN.

Ograniczenie sprzętowe RouterOS: Podsystem /system logging w RouterOS potrafi wysyłać pakiety wyłącznie po protokole UDP bez natywnego szyfrowania TLS
Tunel WireGuard w RouterOS v7: Nowoczesny, niezwykle szybki protokół VPN oparty na kryptografii ChaCha20-Poly1305, wbudowany bezpośrednio w jądro RouterOS v7 i Linux
Adresacja wewnątrz tunelu: Serwer rsyslog otrzymuje dedykowany adres IP w tunelu (np. 10.99.0.1), a router adres 10.99.0.2
Brak modyfikacji pakietu: Router wysyła zwykły datagram UDP pod adres 10.99.0.1, a stos sieciowy automatycznie szyfruje go w locie

Alternatywa IPsec: W przypadku starszych routerów z RouterOS v6 stosuje się tunel IPsec w trybie transportowym lub tunel GRE z szyfrowaniem IPsec (IKEv2 z certyfikatami).

Cel slajdu: Zabezpieczenie serwera przed przepełnieniem dysku przez konfigurację automatycznej rotacji katalogu /var/log/remote/.

Utrzymanie, analiza i integracja

Bez automatycznej rotacji serwer logów ulegnie awarii w wyniku wyczerpania przestrzeni dyskowej. Narzędzie logrotate zarządza kompresją i usuwaniem przedawnionych plików.

Dyrektywa compress (gzip): Tekstowe pliki dziennika kompresują się ze współczynnikiem sięgającym 90–95%, co drastycznie obniża koszty pamięci masowej
Okres retencji (rotate 90): Określa liczbę przechowywanych cykli (dni). Normy branżowe (np. PCI DSS, CIS Controls) oraz polityka firmy określają wymagany czas retencji (np. 90 dni szybkiego dostępu, do roku w archiwum; RODO wymaga zasady ograniczenia przechowywania)
Opcja delaycompress: Pozostawia ostatnio zrotowany plik nieskompresowany przez dodatkowy dzień, co ułatwia pracę skryptom analitycznym
Sygnał postrotate (HUP): Poinformowanie demona rsyslog o zrotowaniu plików, aby zwolnił stare deskryptory plików i rozpoczął zapis do nowych

Testowanie konfiguracji logrotate: Weryfikacja reguł bez modyfikacji plików (tryb symulacji):
sudo logrotate -d /etc/logrotate.d/remote-syslog.

Cel slajdu: Praktyczne techniki przeszukiwania, agregacji i ekstrakcji informacji z milionów wpisów logów za pomocą potoków GNU.

Utrzymanie, analiza i integracja

Przed wdrożeniem ciężkich systemów graficznych każdy inżynier sieciowy powinien opanować standardowe narzędzia wiersza poleceń Linux (grep, awk, sed, sort, uniq).

Szybkość filtrowania: Potoki uniksowe potrafią przeszukać gigabajty skompresowanych logów (zgrep / zcat) w kilka sekund bez narzutu baz danych
Wyciąganie adresów IP: Kombinacja grep -oE z wyrażeniem regularnym IPv4 pozwala wyizolować adresy intruzów bezpośrednio ze strumienia tekstu
Agregacja statystyczna: Potok 'sort | uniq -c | sort -nr' tworzy natychmiastowe zestawienie częstości występowania zdarzeń
Narzędzie awk: Pozwala na zaawansowaną obróbkę kolumnową i filtrowanie według pól nagłówka RFC 5424

Wyszukiwanie w plikach skompresowanych .gz: Narzędzie zgrep "login failure" /var/log/remote/mikrotik/2026-09-*.log.gz przeszukuje zarchiwizowane logi bez konieczności ich uprzedniego rozpakowywania na dysk.

Cel slajdu: Monitorowanie napływających zdarzeń w trybie na żywo oraz automatyczne blokowanie intruzów przez integrację z Fail2ban.

Utrzymanie, analiza i integracja

Analiza statyczna po fakcie to tylko jedna strona medalu. Równie ważne jest śledzenie incydentów na żywo oraz natychmiastowa reakcja obronna.

Narzędzie multitail: Zaawansowany program konsolowy umożliwiający jednoczesny podgląd wielu plików dziennika w podzielonych oknach z kolorowaniem syntaktycznym
Śledzenie journalctl -f: Dla lokalnych i zdalnych serwisów systemd pozwala na ciągły nasłuch nowych rekordów w strumieniu
Integracja z Fail2ban: Popularne narzędzie obronne może czytać pliki tworzone przez rsyslog i na podstawie filtrów regex wykrywać złośliwe zachowania
Pętla sprzężenia zwrotnego (Feedback loop): Serwer logów wykrywa atak i automatycznie dodaje adres atakującego do czarnej listy na routerze brzegowym MikroTik

Automatyzacja bezpieczeństwa (SOAR): Zestawienie rsyslog + Fail2ban + MikroTik API tworzy lekki, autonomiczny system przeciwdziałania intruzom bez konieczności kupowania drogich licencji komercyjnych.

Cel slajdu: Przekierowanie strumienia zdalnego rsyslog bezpośrednio do bazy LibreNMS i powiązanie wpisów z urządzeniami w panelu NMS.

Utrzymanie, analiza i integracja

W Wykładzie 4 poznaliśmy architekturę LibreNMS. Połączenie metryk odpytywania SNMP z asynchronicznym strumieniem zdarzeń Syslog daje pełen obraz stanu sieci.

Architektura hybrydowa: Lokalny rsyslog na serwerze Linux może archiwizować surowe pliki na dysku, a równocześnie przekazywać kopię strumienia do kontenera/procesu LibreNMS
Automatyczne mapowanie hostów: LibreNMS dopasowuje pole %FROMHOST-IP% do zdefiniowanych urządzeń sieciowych w swojej bazie i przypisuje logi do właściwego węzła
Widok Unified Timeline: Inżynier analizujący awarię portu widzi jednocześnie wykres obciążenia interfejsu (SNMP) oraz komunikat 'link DOWN' przesłany przez Syslog
Reguły powiadomień: Możliwość zdefiniowania alertu: 'Jeśli w logach MikroTik pojawi się prefiks FW_DROP_WAN więcej niż 100 razy w ciągu 5 minut, wyślij alert'

Włączenie modułu Syslog w LibreNMS: W pliku konfiguracyjnym lub przez CLI (lnms config:set enable_syslog true) włączamy moduł, a w rsyslog stosujemy wtyczkę omprog ze skryptem /opt/librenms/syslog.php i 8-polowym szablonem t_librenms.

Cel slajdu: Przewodnik rozwiązywania typowych usterek: brak odbioru pakietów UDP, blokady SELinux/AppArmor, błędy uprawnień i pętle logowania.

Utrzymanie, analiza i integracja

Podczas uruchamiania centralnego logowania administratorzy napotykają szereg typowych trudności konfiguracyjnych i systemowych.

Weryfikacja składni (rsyslogd -N1): Podstawowy test poprawności wszystkich plików konfiguracyjnych przed restartem demona
Przechwytywanie ruchu (tcpdump): Sprawdzenie, czy pakiety fizycznie docierają do interfejsu sieciowego serwera (wyklucza problem z routingiem i zaporami pośrednimi)
Błędy uprawnień do katalogów: Demon rsyslog działający jako użytkownik 'syslog' po cichu porzuca zapis, jeśli katalog nie posiada flagi zapisu dla tej grupy
Pętle logowania (Syslog Storm): Sytuacja, w której rsyslog generuje komunikat o błędzie zapisu, który następnie próbuje sam zalogować, doprowadzając do natychmiastowego nasycenia CPU
Moduły bezpieczeństwa (AppArmor / SELinux): Mogą blokować zapis do niestandardowych ścieżek poza /var/log/. Wymagają aktualizacji profilu w /etc/apparmor.d/

Zwiększenie bufora gniazda UDP w Linux: Przy dużym natężeniu ruchu UDP jądro może gubić pakiety. Zwiększ rozmiar bufora w /etc/sysctl.conf:
net.core.rmem_max = 16777216.

Cel slajdu: Synteza zdobytej wiedzy w postaci gotowej do użycia listy kontrolnej (Checklist) wdrożenia korporacyjnego serwera logów.

Podsumowanie i dobre praktyki

Prawidłowo wdrożony system centralnego logowania to fundament bezpieczeństwa teleinformatycznego, spełniający wyśrubowane normy audytowe i umożliwiający błyskawiczną reakcję na incydenty.

Kluczowa rola synchronizacji czasu: Wszystkie urządzenia w sieci (serwer Linux, klienci, routery MikroTik) muszą bezwzględnie synchronizować czas z serwerem NTP. Rozbieżność zegarów uniemożliwia jakąkolwiek korelację zdarzeń
Separacja uprawnień i retencja: Logi muszą być chronione przed modyfikacją, a ich cykl życia zautomatyzowany przez skrypty logrotate
Niezawodność buforowania: Klienci wyposażeni w kolejki dyskowe chronią organizację przed utratą danych podczas przerw w komunikacji sieciowej
Holistyczne podejście do NMS: Centralny magazyn logów w połączeniu z systemem LibreNMS tworzy kompletną platformę monitoringu zgodną z modelem FCAPS

Podsumowanie wdrożenia: Wdrożony został kompletny system zdalnego logowania Syslog i rsyslog w systemie Linux oraz konfiguracja routerów MikroTik RouterOS.