Monitorowanie sieci - Warsztat: Zaawansowane logowanie zdalne Syslog, rsyslog i MikroTik RouterOS

Cel slajdu: Przedstawienie kompleksowego, laboratoryjnego samouczka inżynierskiego: konfiguracja od zera centralnego serwera rsyslog, dynamiczne rozdzielanie plików per host i severity, buforowanie awaryjne oraz telemetria RouterOS.

Wprowadzenie do warsztatu

Niniejsze opracowanie stanowi praktyczny przewodnik wdrożeniowy dla administratorów sieci LAN/WAN i inżynierów NMS. Krok po kroku przejdziemy od pustego systemu operacyjnego Linux Debian/Ubuntu/RHEL do w pełni zabezpieczonego, wysoce dostępnego klastra telemetrii zdarzeń.

Architektura centralnego kolektora: Uruchomienie nasłuchu UDP/TCP 514 w oparciu o nowoczesną składnię RainerScript v8+
Separacja danych per-PC: Dynamiczne szablony dynaFile tworzące automatycznie foldery dla każdego adresu IP lub nazwy hosta
Klasyfikacja wag zdarzeń: Wydzielanie logów krytycznych (emerg..err) do osobnych plików audytowych w katalogu urządzenia
Telemetria MikroTik RouterOS: Pełna integracja zdarzeń zapory sieciowej, dzierżaw DHCP, zmian stanu interfejsów i audytu logowań

Protokół Syslog (RFC 3164 / RFC 5424): Uniwersalny standard sieciowy umożliwiający urządzeniom brzegowym i stacjom roboczym natychmiastowe przesyłanie zdarzeń diagnostycznych, alarmów bezpieczeństwa i metadanych do scentralizowanego serwera rsyslog.

Weryfikacja wersji oprogramowania na węzłach laboratoryjnych

root@nms-syslog:~# rsyslogd -v | head -n 2 rsyslogd 8.2302.0 (aka 2023.02) compiled with runtime-x, libgcrypt, gnutls root@nms-syslog:~# uname -r 6.8.0-45-generic #45-Ubuntu SMP PREEMPT_DYNAMIC x86_64 [admin@MikroTik-CCR2004] > /system resource print uptime: 42d18h12m version: 7.15.2 (stable) board-name: CCR2004-16G-2S+ cpu: ARM64 (4 cores @ 1700MHz)

Cel slajdu: Przedstawienie topologii przepływu strumieni telemetrycznych z węzłów brzegowych do dedykowanego serwera rsyslog.

Fundamenty telemetrii sieciowej

Prawidłowo zaprojektowany system centralizacji zdarzeń opiera się na separacji ruchu telemetrycznego w dedykowanej warstwie zarządzania (Out-of-Band Management VLAN). Zapobiega to zakłócaniu pracy sieci produkcyjnej oraz zabezpiecza logi przed podsłuchem.

Źródła zdarzeń (Generators): Routery MikroTik, serwery Linux, stacje robocze PC, przełączniki managed i punkty dostępowe Wi-Fi
Kanały transmisyjne: UDP 514 dla urządzeń wbudowanych (MikroTik), TCP 514 dla systemów serwerowych oraz TLS 6514 dla połączeń szyfrowanych
Serwer centralny rsyslog: Wysokowydajny proces w przestrzeni użytkownika filtrujący pakiety w locie za pomocą wątków wejściowych
System plików (dynaFile): Fizyczne rozdzielanie logów do dedykowanych folderów na podstawie źródłowego adresu IP (%FROMHOST-IP%)

Zasada minimalizacji uprawnień serwera logów: Centralny serwer rsyslog nie powinien udostępniać żadnych publicznych usług (brak serwera WWW, FTP czy SMB). Dostęp do plików w /var/log/remote/ powinien być ograniczony wyłącznie do lokalnego konta audytora i agentów systemów NMS/SIEM.

Weryfikacja trasy pakietów telemetrycznych ze stacji roboczej do serwera rsyslog

user@PC-Stacja-01:~$ ip route get 192.168.1.100 192.168.1.100 dev enp3s0 src 192.168.1.150 uid 1000 cache <direct-lan> mtu 1500 rtt 0.182ms user@PC-Stacja-01:~$ nc -z -v -w2 192.168.1.100 514 Connection to 192.168.1.100 514 port [tcp/syslog] succeeded!

Cel slajdu: Zrozumienie ról poszczególnych węzłów w łańcuchu przetwarzania telemetrii według standardu RFC 5424.

Standardy i specyfikacja IETF

Standard IETF formalizuje podział ról w architekturze telemetrycznej. Nie każdy węzeł musi komunikować się bezpośrednio z głównym magazynem danych – w rozległych infrastrukturach kluczową rolę pełnią przekaźniki pośredniczące (Relays).

Generator (Device): Aplikacja lub demon systemowy tworzący komunikat o zdarzeniu i przypisujący mu początkowy priorytet
Przekaźnik (Relay): Węzeł pośredni odbierający komunikaty z lokalnej podsieci, buforujący je i przesyłający dalej tunelem szyfrowanym
Kolektor (Collector): Węzeł docelowy odpowiadający za parsowanie, bezpieczny zapis na nośnik trwały oraz indeksowanie dla NMS
Integralność metadanych: Standard nakazuje, aby przekaźnik nie modyfikował oryginalnej nazwy hosta źródłowego ani znacznika czasu zdarzenia

Różnica między FROMHOST a HOSTNAME: W rsyslog zmienna %HOSTNAME% to nazwa wpisana w nagłówku przez generator. Zmienna %FROMHOST-IP% to rzeczywisty adres IP gniazda pakietu sieciowego, z którego rsyslog odebrał ramkę. Z punktu widzenia bezpieczeństwa podział na katalogi należy opierać o %FROMHOST-IP%.

Konfiguracja przekaźnika pośredniego rsyslog (Relay) w pliku /etc/rsyslog.d/50-relay.conf

root@edge-relay:~# cat << 'EOF' > /etc/rsyslog.d/50-relay.conf # Odbierz z sieci lokalnej oddziału na UDP 514 module(load="imudp") input(type="imudp" port="514") # Przekaż dalej do centrali przez szyfrowany tunel TCP 514 action(type="omfwd" target="10.255.0.1" port="514" protocol="tcp" queue.type="LinkedList" queue.filename="relay_spool" queue.saveonshutdown="on") EOF

Cel slajdu: Przedstawienie standardowych kodów Facility i ich metodycznego mapowania na urządzenia infrastruktury teleinformatycznej.

Standardy i specyfikacja IETF

Kod kategorii (Facility) informuje serwer logów o tym, jaki podsystem wygenerował zdarzenie. Zakres od 0 do 15 zarezerwowano dla standardowych usług systemu operacyjnego, natomiast kody od 16 do 23 (local0..local7) oddano do dyspozycji administratorom sieci.

Kategorie systemowe (0..15): Standardowe źródła uniksowe: kern (0), user (1), daemon (3), auth (4), syslog (5), cron (9), authpriv (10)
Kategorie sieciowe (16..23): Pule local0..local7 dedykowane dla routerów MikroTik, zapór ogniowych, macierzy i przełączników
Separacja logiczna w rsyslog: Możliwość natychmiastowego skierowania strumienia local0 do pliku /var/log/mikrotik.log
Konwencja wdrożeniowa: Utrzymanie jednolitego standardu w całej organizacji (np. local0 = RouterOS, local1 = Cisco, local2 = Wi-Fi)

Generowanie zdarzenia z wybranym kodem Facility: Za pomocą narzędzia logger możemy zasymulować komunikat o statusie błędu z podsystemu uwierzytelniania lub urządzenia sieciowego:
logger -p local0.warn "MikroTik: Wykryto probę skanowania portu WAN".

Testowanie kategorii Facility za pomocą konsoli Linux

root@nms-syslog:~# logger -p local0.warning -t MIKROTIK-TEST "Brama 192.168.1.1 zgłosiła drop na WAN" root@nms-syslog:~# logger -p authpriv.alert -t SSH-AUDIT "Wykryto 10 błędnych prób logowania na konto root" root@nms-syslog:~# tail -n 2 /var/log/syslog 2026-09-29T19:05:12.102+02:00 nms-syslog MIKROTIK-TEST: Brama 192.168.1.1 zgłosiła drop na WAN 2026-09-29T19:05:15.844+02:00 nms-syslog SSH-AUDIT: Wykryto 10 błędnych prób logowania na konto root

Cel slajdu: Przedstawienie 8-stopniowej hierarchii wag zdarzeń oraz reguł filtrowania w języku konfiguracyjnym.

Standardy i specyfikacja IETF

Poziom ważności (Severity) określa stopień krytyczności zarejestrowanego faktu. Standard IETF definiuje poziomy od 0 (Emergency – najwyższy priorytet) do 7 (Debug – najniższy priorytet). Filtry rsyslog domyślnie interpretują poziomy hierarchicznie.

Strefa awaryjna (0..3): Emerg, Alert, Crit, Error – wymagają natychmiastowej reakcji inżyniera dyżurnego lub systemu NMS
Strefa operacyjna (4..5): Warning, Notice – stabilna praca sieci, ale z symptomami potencjalnych anomalii lub istotnych zmian
Strefa telemetryczna (6..7): Info, Debug – wysoki wolumen zdarzeń generowany podczas normalnej pracy i sesji diagnostycznych
Operatory filtrowania: Zapis *.=warning oznacza tylko poziom 4; *.warning oznacza poziomy 0..4; zapis *.*;*.!=info rejestruje wszystko oprócz samego poziomu informacyjnego (pojedynczy wykrzyknik odrzuca poziom i wszystkie wyższe)

Zasada filtrowania szumu: Włączenie poziomu debug (7) na routerze brzegowym w sieci korporacyjnej generuje tysiące pakietów na sekundę. W środowisku produkcyjnym reguły telemetryczne powinny domyślnie rejestrować poziom info (6) i wyższe, a debug powinien być aktywowany wyłącznie doraźnie podczas analizy problemu.

Sprawdzenie poziomów istotności w bieżącym pliku logów serwera

root@nms-syslog:~# awk '{print $5}' /var/log/syslog | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 5 1420 systemd 890 kernel 312 rsyslogd 145 sshd 48 CRON root@nms-syslog:~# grep -i "error\|crit\|alert" /var/log/syslog | wc -l 14

Cel slajdu: Opanowanie algorytmu kodowania i dekodowania wartości numerycznej PRI w surowych pakietach sieciowych.

Standardy i specyfikacja IETF

Na początku każdego pakietu Syslog przesyłana jest liczba całkowita ujęta w nawiasy ostrokątne, np. <134>. Wartość ta (Priority Value) jest jednobajtowym upakowaniem dwóch kluczowych parametrów: Facility i Severity.

Wzór kodowania: PRI = (Facility × 8) + Severity. Ponieważ 8 to 2^3, operacja odpowiada przesunięciu bitowemu (Facility << 3) | Severity
Algorytm dekodowania: Facility = PRI / 8 (dzielenie całkowite); Severity = PRI % 8 (reszta z dzielenia / modulo)
Przykład dekodowania <189>: 189 / 8 = 23 (kategoria local7); 189 % 8 = 5 (poziom notice)
Pozycja w ramce: Wartość PRI musi znajdować się na samym początku ładunku UDP/TCP (od bajtu 0)

Weryfikacja nagłówka PRI w surowym zrzucie tcpdump: Podgląd pierwszych bajtów pakietu UDP odebranego na serwerze z routera MikroTik ujawnia ciąg znaków ASCII <134>, co jednoznacznie wskazuje na kategorię local0 i ważność info.

Przechwytywanie i dekodowanie surowych pakietów Syslog na serwerze

root@nms-syslog:~# tcpdump -i eth0 -nn -A -s0 -c 1 "udp port 514" tcpdump: verbose output suppressed, sub-sample size 1 listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 19:10:04.812344 IP 192.168.1.1.41285 > 192.168.1.100.514: UDP, length 118 E..r..@.@.....0...d..."...J.<134>1 2026-09-29T19:10:04+02:00 MikroTik-GW firewall,info DROP_WAN: in:ether1 out:(unknown 0), src-mac 00:11:22:33:44:55, proto TCP, 203.0.113.50:44123->192.168.1.1:22, len 60 1 packet captured, 1 packet received by filter, 0 packets dropped by kernel

Cel slajdu: Zrozumienie technicznych różnic pomiędzy historycznym formatem BSD a współczesnym standardem IETF.

Standardy i specyfikacja IETF

Przez dekady standardem de facto był format BSD opisany informacyjnie w RFC 3164. W 2009 roku organizacja IETF opublikowała standard RFC 5424, usuwający fundamentalne wady poprzednika, takie jak brak roku w dacie czy brak mikrosekund.

Format RFC 3164 (Legacy): Struktura: <PRI>TIMESTAMP HOSTNAME TAG: MSG. Długość bufora do 1024 bajtów. Brak strefy czasowej
Format RFC 5424 (Standard): Struktura: <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG
Precyzja czasu ISO 8601: Format 2026-09-29T19:15:00.123456+02:00 eliminuje niejednoznaczności stref czasowych w logach międzynarodowych
Dane ustrukturyzowane (SD): Pola [exampleSDID@32473 iut="3" eventSource="firewall"] pozwalają silnikom NMS na parsowanie bez Regex

Zalecenie konfiguracyjne dla MikroTik RouterOS: W akcjach zdalnego logowania RouterOS zawsze ustawiaj opcję bsd-syslog=no. Ustawienie to wymusza pełną zgodność z formatem RFC 5424 i przekazuje mikrosekundowy znacznik czasu oraz pełny nagłówek urządzenia.

Porównanie nagłówków obu standardów w surowym pliku konfiguracyjnym rsyslog

# Wymuszenie formatu RFC 5424 w RainerScript dla pliku wyjściowego template(name="RSYSLOG_SyslogProtocol23Format" type="string" string="<%PRI%>1 %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n") # Domyślny przestarzały format RFC 3164 (niezalecany w nowych wdrożeniach) template(name="RSYSLOG_TraditionalFileFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n")

Cel slajdu: Dobór optymalnego protokołu transportowego w zależności od medium sieciowego, urządzeń i wymagań bezpieczeństwa.

Standardy i specyfikacja IETF

Wybór protokołu transportowego determinuje niezawodność i bezpieczeństwo telemetrii. Każde z dostępnych rozwiązań charakteryzuje się innym kompromisem pomiędzy wydajnością, narzutem sieciowym a pewnością dostarczenia.

Protokół UDP 514: Brak potwierdzeń i nawiązywania połączenia. Jeśli bufor kolektora jest pełny, pakiety są bezpowrotnie tracone
Protokół TCP 514: Niezawodne przesyłanie strumieniowe z kontrolą przepływu. Serwer zwalnia nadawcę w razie braku zasobów
Protokół TLS 6514 (RFC 5425): Bezpieczny kanał szyfrowany kluczami asymetrycznymi. Gwarantuje poufność i chroni przed fałszowaniem logów
Protokół RELP: Reliable Event Logging Protocol – autorski protokół rsyslog potwierdzający zapisanie rekordu na dysku fizycznym

Dlaczego RouterOS nie korzysta z TLS Syslog natywnie? Większość sprzętowych routerów sieciowych implementuje lekki stos UDP ze względu na minimalne zapotrzebowanie na moc procesora. Aby bezpiecznie przesyłać logi z MikroTik przez Internet, router zestawia tunel VPN (WireGuard lub IPsec) do serwera i wewnątrz tunelu przesyła pakiety UDP 514.

Weryfikacja strat w buforach gniazda UDP w systemie Linux

root@nms-syslog:~# netstat -su | grep -E "packet receive errors|receive buffer errors" 0 packet receive errors 0 receive buffer errors # Jeśli licznik błędów rośnie, należy zwiększyć rmem_max w /etc/sysctl.conf root@nms-syslog:~# sysctl -w net.core.rmem_max=16777216 net.core.rmem_max = 16777216 # 16 MB bufora pamięci dla gniazd UDP

Cel slajdu: Instalacja pakietu rsyslog, zrozumienie modularnej struktury plików oraz konfiguracja uprawnień systemowych.

Budowa serwera rsyslog od zera

Demon rsyslog (Rocket-fast System for Log Processing) jest domyślnym menedżerem logów w większości dystrybucji Linux. Przygotowanie serwera centralnego rozpoczynamy od upewnienia się, że pakiet jest zainstalowany i poprawnie zintegrowany z systemd.

Pakiety w dystrybucjach: Debian/Ubuntu: apt install rsyslog; RHEL/Rocky Linux: dnf install rsyslog
Struktura /etc/rsyslog.d/: Pliki konfiguracyjne ładowane są w kolejności alfanumerycznej. Prefiksy liczbowe (10-, 20-, 50-) definiują kolejność reguł
Użytkownik demoniczny: W Debianie proces rsyslog zrzuca uprawnienia roota i działa jako użytkownik syslog w grupie adm
Katalog magazynu zdalnego: Tworzymy dedykowany katalog /var/log/remote/ z prawami 0750 i własnością syslog:adm

Izolacja magazynu na odrębnym wolumenie: W środowiskach produkcyjnych katalog /var/log/remote/ powinien być zamontowany na dedykowanej partycji dyskowej lub wolumenie LVM. Chroni to główny system plików (/) serwera przed przepełnieniem w razie zmasowanego ataku logującego.

Instalacja rsyslog i przygotowanie katalogu magazynu zdalnego

root@nms-syslog:~# apt update && apt install -y rsyslog rsyslog is already the newest version (8.2302.0-1ubuntu4). root@nms-syslog:~# mkdir -p /var/log/remote root@nms-syslog:~# chown -R syslog:adm /var/log/remote root@nms-syslog:~# chmod 750 /var/log/remote root@nms-syslog:~# ls -ld /var/log/remote drwxr-x--- 2 syslog adm 4096 Sep 29 19:20 /var/log/remote/

Cel slajdu: Prawidłowa konfiguracja zapory sieciowej na serwerze logów ograniczająca dostęp wyłącznie do zaufanych podsieci.

Budowa serwera rsyslog od zera

Protokół UDP nie posiada mechanizmu handshake ani weryfikacji tożsamości nadawcy. Otwarcie portu 514 na świat pozwala każdemu użytkownikowi Internetu na wstrzykiwanie sfałszowanych wpisów lub przeprowadzenie ataku odmowy usługi (DoS) na dysk serwera.

Zasada białej listy (Whitelisting): Dostęp do portów 514 UDP/TCP powinien być otwarty wyłącznie ze znanych adresów IP routerów i podsieci serwerowych
Reguły UFW (Ubuntu/Debian): Jawne definiowanie źródła: ufw allow from 192.168.1.0/24 to any port 514 proto udp
Strefy Firewalld (RHEL/Rocky): Przypisanie dedykowanego interfejsu sieciowego do strefy 'internal' lub 'trusted' i otwarcie portu 514
Izolacja fizyczna/VLAN: Najbezpieczniejszym modelem jest skierowanie ruchu logów do odrębnej karty sieciowej serwera wpiętej w Management VLAN

Zagadnienie IP Spoofingu w UDP: Pakiety UDP można łatwo sfingować, podmieniając adres IP źródła w nagłówku IP. Dlatego w krytycznych środowiskach przełączniki dostępowe muszą mieć aktywną funkcję IP Source Guard oraz DHCP Snooping, co fizycznie uniemożliwia nadawanie pakietów z obcym IP na poziomie portu switcha.

Konfiguracja i weryfikacja reguł zapory ogniowej UFW

root@nms-syslog:~# ufw allow from 192.168.1.0/24 to any port 514 proto udp comment "Syslog MikroTik UDP" Rule added root@nms-syslog:~# ufw allow from 192.168.1.0/24 to any port 514 proto tcp comment "Syslog Linux TCP" Rule added root@nms-syslog:~# ufw status numbered | grep 514 [ 4] 514/udp ALLOW IN 192.168.1.0/24 # Syslog MikroTik UDP [ 5] 514/tcp ALLOW IN 192.168.1.0/24 # Syslog Linux TCP

Cel slajdu: Przedstawienie przewagi nowoczesnej składni obiektowo-blokowej RainerScript nad przestarzałym formatem dyrektyw $.

Budowa serwera rsyslog od zera

W Internecie wciąż można znaleźć wiele przestarzałych poradników wykorzystujących historyczną składnię dyrektyw dolarowych ($ModLoad, $ActionQueueType). Oficjalna dokumentacja projektu rsyslog uznaje format ten za przestarzały (deprecated) i zaleca stosowanie wyłącznie języka RainerScript.

Problem składni legacy ($): Dyrektywy $ modyfikują globalny stan procesora. Kolejność wpisów w pliku decyduje o zachowaniu, co prowadzi do trudnych do wykrycia błędów
Zalety RainerScript: Czysta struktura blokowa module(), input(), template(), action(), jawne przekazywanie parametrów w nawiasach
Instrukcje sterujące: Wsparcie dla pełnych bloków logicznych: if $fromhost-ip == '192.168.1.1' then { ... } else { ... }
Wydajność parsera: Składnia RainerScript jest kompilowana przez wewnętrzny optymalizator rsyslog do wydajnego kodu bajtowego

Dlaczego należy unikać mieszania stylów? Łączenie w jednym pliku starego zapisu $ActionFileDefaultTemplate z nowym blokiem action(type="omfile") może wywołać nieoczekiwane zachowanie demona, w którym parametry globalne przesłaniają jawne definicje akcji. W całym poradniku stosujemy w 100% czysty RainerScript.

Wzorzec składniowy RainerScript w nowoczesnym pliku konfiguracyjnym

# Deklaracja modułu wejściowego z parametrami module(load="imtcp" StreamDriver.AuthMode="anon") # Definicja gniazda nasłuchującego powiązanego z regułami input(type="imtcp" port="514" ruleset="remote_network") # Warunkowe przetwarzanie i routing zdarzeń if ($syslogseverity <= 3) then { action(type="omfile" file="/var/log/critical_all.log") }

Cel slajdu: Uruchomienie modułów imudp i imtcp oraz powiązanie procesu rsyslog z portami sieciowymi 514.

Budowa serwera rsyslog od zera

Domyślna instalacja rsyslog nasłuchuje wyłącznie na lokalnym gnieździe uniksowym /dev/log. Aby serwer stał się centralnym kolektorem telemetrycznym, musimy załadować moduły sieciowe imudp (Input Module UDP) oraz imtcp (Input Module TCP).

Dedykowany plik konfiguracyjny: Tworzymy plik /etc/rsyslog.d/10-network-inputs.conf, co oddziela definicję gniazd od logiki routingu plików
Moduł imudp: module(load="imudp") oraz input(type="imudp" port="514") – obsługa urządzeń MikroTik i switchy
Moduł imtcp: module(load="imtcp") oraz input(type="imtcp" port="514") – niezawodny strumień dla stacji roboczych Linux
Ograniczenie do interfejsu: Opcjonalny parametr address="192.168.1.100" wiąże nasłuch z konkretnym adresem IP zamiast 0.0.0.0

Wiązanie z dedykowanym adresem IP: Jeśli serwer posiada kilka kart sieciowych, zaleca się ograniczenie nasłuchu wyłącznie do adresu w podsieci zarządzającej:
input(type="imudp" port="514" address="192.168.1.100")
input(type="imtcp" port="514" address="192.168.1.100").

Tworzenie pliku wejść sieciowych i weryfikacja gniazd nasłuchujących

root@nms-syslog:~# cat << 'EOF' > /etc/rsyslog.d/10-network-inputs.conf # Odbior UDP dla MikroTik RouterOS module(load="imudp") input(type="imudp" port="514") # Odbior TCP dla stacji roboczych Linux module(load="imtcp") input(type="imtcp" port="514") EOF root@nms-syslog:~# systemctl restart rsyslog root@nms-syslog:~# ss -tulpn | grep 514 udp UNCONN 0 0 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=1540,fd=6)) tcp LISTEN 0 25 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=1540,fd=7))

Cel slajdu: Zrozumienie działania szablonów RainerScript i zmiennych właściwości (properties) używanych do generowania ścieżek.

Budowa serwera rsyslog od zera

Szablony (Templates) to jedna z najpotężniejszych funkcji demona rsyslog. Pozwalają one na formatowanie wyglądu komunikatów wyjściowych oraz dynamiczne wyliczanie ścieżek plików docelowych (tzw. dynaFile) na podstawie danych wyciągniętych z przetwarzanego pakietu.

Koncepcja dynaFile: Szablon typu string zwracający pełną ścieżkę do pliku na dysku. Różne komunikaty mogą trafić do różnych plików
Automatyczne tworzenie katalogów: Rsyslog automatycznie tworzy brakujące podkatalogi z uprawnieniami określonymi w konfiguracji
Właściwość %FROMHOST-IP%: Zawiera zweryfikowany adres IP stacji roboczej lub routera. Uniemożliwia zatrucie ścieżki (Path Traversal)
Właściwości czasowe: %$YEAR%, %$MONTH%, %$DAY% pozwalają na codzienną separację logów bez zewnętrznych narzędzi rotujących

Różnica między parametrem 'file' a 'dynaFile': W akcji action(type="omfile") parametr file="/sciezka/stala.log" przyjmuje stałą nazwę pliku, natomiast parametr dynaFile="NazwaSzablonu" przekazuje nazwę szablonu, który dynamicznie oblicza ścieżkę dla każdego napływającego rekordu.

Definicja szablonu dynamicznej ścieżki w RainerScript

# Szablon generujący strukturę: /var/log/remote/<IP_URZADZENIA>/<ROK>-<MIESIAC>-<DZIEN>.log template(name="RemoteHostDaily" type="string" string="/var/log/remote/%FROMHOST-IP%/%$YEAR%-%$MONTH%-%$DAY%.log") # Akcja omfile wykorzystująca zdefiniowany dynaFile action(type="omfile" dynaFile="RemoteHostDaily" dirCreateMode="0750" fileCreateMode="0640")

Cel slajdu: Praktyczna implementacja separacji logów: każda stacja robocza i router otrzymują własny katalog z dziennym podziałem.

Budowa serwera rsyslog od zera

Podstawowy wymóg stawiany centralnemu serwerowi logów to przejrzystość. Administrator nie może szukać incydentów stacji roboczej PC-01 pośród milionów wpisów zapory MikroTik. Rozwiązaniem jest automatyczna kreacja folderów per urządzenie.

Tworzenie pliku 20-remote-hosts.conf: Wszystkie reguły dotyczące odbierania telemetrii z obcych maszyn umieszczamy w dedykowanym pliku
Szablon RemotePerHost: Ścieżka /var/log/remote/%FROMHOST-IP%/%$YEAR%-%$MONTH%-%$DAY%.log izoluje maszyny według ich fizycznego IP
Parametry uprawnień: dirCreateMode="0750" oraz fileCreateMode="0640" gwarantują, że nowe katalogi nie będą dostępne dla nieuprawnionych
Automatyczna kreacja w locie: Rsyslog sprawdza istnienie folderu w momencie nadejścia pierwszego pakietu i tworzy go automatycznie

Wariant szablonu z nazwą hosta zamiast IP: Jeśli urządzenia mają prawidłowo skonfigurowane unikalne nazwy w nagłówkach RFC 5424, możemy użyć:
string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log"
W środowiskach zaufanych ułatwia to przeglądanie (np. foldery 'router-biuro', 'srv-baza').

Tworzenie pliku /etc/rsyslog.d/20-remote-hosts.conf i test składni

root@nms-syslog:~# cat << 'EOF' > /etc/rsyslog.d/20-remote-hosts.conf # Szablon zapisu per host/IP z podziałem na dni template(name="RemotePerHost" type="string" string="/var/log/remote/%FROMHOST-IP%/%$YEAR%-%$MONTH%-%$DAY%.log") # Reguła zapisu dla komunikatów sieciowych action(type="omfile" dynaFile="RemotePerHost" dirCreateMode="0750" fileCreateMode="0640") EOF root@nms-syslog:~# rsyslogd -N1 rsyslogd: End of config validation run. No syntax errors found. [SUCCESS]

Cel slajdu: Konfiguracja precyzyjnego sortowania komunikatów wewnątrz katalogu danej stacji roboczej na osobne pliki.

Budowa serwera rsyslog od zera

Zapisywanie wszystkich zdarzeń z maszyny do jednego pliku all.log jest poprawne, ale w sytuacji awarii administrator traci cenny czas na wyłuskiwanie błędów krytycznych. Skonfigurujemy rsyslog tak, aby równolegle zapisywał błędy do pliku critical.log.

Plik critical.log: Zawiera zdarzenia o poziomie ważności <= 3 (emerg, alert, crit, err). Pierwsze miejsce kontroli podczas awarii
Plik warning.log: Zawiera zdarzenia o poziomie 4 (warning) – symptomatyczne ostrzeżenia o przeciążeniach lub spadkach napięcia
Plik auth.log: Filtruje kategorie uwierzytelniania (auth, authpriv.*) – audyt logowań administratorów i nieudanych autoryzacji
Plik all.log: Pełne archiwum chronologiczne zawierające wszystkie rekordy (w tym zdarzenia informacyjne i dzierżawy DHCP)

Brak duplikacji pamięciowej: Rsyslog przetwarza rekord w pamięci RAM i przekazuje wskaźnik do rekordu do wielu akcji jednocześnie. Zapis tego samego komunikatu do all.log i critical.log nie powoduje podwójnego narzutu obliczeniowego.

Konfiguracja wielopoziomowego zapisu w pliku /etc/rsyslog.d/20-remote-hosts.conf

# Szablony dynamicznych ścieżek w folderze urządzenia template(name="HostCrit" type="string" string="/var/log/remote/%FROMHOST-IP%/critical.log") template(name="HostWarn" type="string" string="/var/log/remote/%FROMHOST-IP%/warning.log") template(name="HostAuth" type="string" string="/var/log/remote/%FROMHOST-IP%/auth.log") template(name="HostAll" type="string" string="/var/log/remote/%FROMHOST-IP%/all.log") # 1. Zapisz wszystkie logi do archiwum głównego maszyny action(type="omfile" dynaFile="HostAll" dirCreateMode="0750" fileCreateMode="0640") # 2. Jeśli to błąd krytyczny (poziomy 0..3), zapisz również do critical.log if ($syslogseverity <= 3) then { action(type="omfile" dynaFile="HostCrit" dirCreateMode="0750" fileCreateMode="0640") } # 3. Jeśli to kategoria auth/authpriv, zapisz do auth.log if ($syslogfacility-text == 'auth' or $syslogfacility-text == 'authpriv') then { action(type="omfile" dynaFile="HostAuth" dirCreateMode="0750" fileCreateMode="0640") }

Cel slajdu: Wdrożenie dedykowanych zestawów reguł (ruleset) w celu odseparowania logów zdalnych od logów systemowych serwera.

Budowa serwera rsyslog od zera

Domyślnie wszystkie wejścia w rsyslog kierowane są do jednego, wspólnego potoku reguł. Bez jawnego podziału na zestawy reguł (rulesets), logi ze stacji roboczych i routera MikroTik trafią równolegle do lokalnego pliku /var/log/syslog serwera, powodując jego błyskawiczne zalanie.

Koncepcja Ruleset: Niezależny potok przetwarzania posiadający własne kolejki, szablony i reguły filtrowania
Wiązanie gniazda z ruleset: Dyrektywa input(type="imudp" port="514" ruleset="remote_network") natychmiast przekazuje pakiet do dedykowanego toru
Czystość /var/log/syslog: Lokalny plik /var/log/syslog rejestruje wyłącznie zdarzenia lokalnego systemu operacyjnego serwera
Optymalizacja wątkowa: Każdy ruleset może posiadać dedykowaną kolejkę wątkową, co uniemożliwia zawieszenie systemu przy zatorze sieciowym

Zasada działania bloku ruleset(): Blok ruleset(name="remote_network") { ... } definiuje zamkniętą przestrzeń reguł. Rekordy wpadające do tego bloku wykonują wyłącznie akcje w nim zdefiniowane i nie przechodzą do standardowych plików 50-default.conf.

Konfiguracja wejść sieciowych z parametrem ruleset w /etc/rsyslog.d/10-network-inputs.conf

root@nms-syslog:~# cat << 'EOF' > /etc/rsyslog.d/10-network-inputs.conf module(load="imudp") module(load="imtcp") # Przypisanie gniazd sieciowych do wyizolowanego potoku 'remote_network' input(type="imudp" port="514" ruleset="remote_network") input(type="imtcp" port="514" ruleset="remote_network") EOF

Cel slajdu: Zrozumienie mechanizmu kończenia przetwarzania rekordu i trwałej ochrony lokalnych plików serwera.

Budowa serwera rsyslog od zera

W architekturze rsyslog domyślnym zachowaniem po wykonaniu akcji jest przekazanie rekordu do kolejnych reguł w łańcuchu. Instrukcja stop (będąca nowoczesnym odpowiednikiem dawnego znaku & ~) nakazuje silnikowi natychmiastowe przerwanie przetwarzania danego komunikatu.

Działanie instrukcji stop: Kończy bieg przetwarzania bieżącego rekordu w danym potoku reguł i zwalnia jego strukturę w pamięci
Ochrona plików systemowych: Gwarantuje, że zdarzenia sieciowe z MikroTik i stacji PC nie przenikną do /var/log/syslog, /var/log/messages ani /var/log/auth.log
Dawna składnia & ~: W starszych wersjach rsyslog stosowano zapis & ~ po linii akcji. W RainerScript v8+ jest on przestarzały i zastąpiony słowem 'stop'
Pozycja w konfiguracji: Instrukcja stop musi znajdować się na samym końcu bloku ruleset, po wykonaniu wszystkich zamierzonych akcji zapisu

Uwaga na kolejność wpisów: Jeśli umieścisz słowo stop przed akcją action(type="omfile"), rsyslog natychmiast porzuci pakiet i plik na dysku w ogóle nie zostanie utworzony! Prawidłowa sekwencja to zawsze: Szablony → Akcje zapisu → stop.

Testowanie obecności obcych wpisów w lokalnym pliku /var/log/syslog

root@nms-syslog:~# tail -n 100 /var/log/syslog | grep -i "MikroTik\|DROP_WAN" # Brak jakichkolwiek wyników oznacza pełną izolację strumieni! # Kod wyjścia 1: Czysto! Logi sieciowe trafiają wyłącznie do /var/log/remote/ root@nms-syslog:~# ls -la /var/log/remote/192.168.1.1/ -rw-r----- 1 syslog adm 284192 Sep 29 19:35 2026-09-29.log Logi routera zapisują się wyłącznie w dedykowanym magazynie!

Cel slajdu: Opanowanie bezpiecznych procedur walidacji składni przed restartem usługi oraz weryfikacji stanu usługi.

Budowa serwera rsyslog od zera

Zrestartowanie demona rsyslog z błędem składni w pliku konfiguracyjnym skutkuje natychmiastowym zatrzymaniem usługi i utratą wszystkich napływających logów sieciowych. Linux udostępnia wbudowany tryb walidacji rsyslogd -N1.

Polecenie rsyslogd -N1: Weryfikuje poprawność leksykalną i gramatyczną wszystkich plików w /etc/rsyslog.conf oraz /etc/rsyslog.d/
Kod powrotu $?: Zwrócenie wartości 0 oznacza pełny sukces. Kod różny od 0 oznacza wykrycie błędu i wskazuje numer linii
Inspekcja journalctl: journalctl -u rsyslog -f pozwala na bieżąco obserwować komunikaty startowe procesu
Weryfikacja gniazd ss: Polecenie ss -tulpn | grep 514 potwierdza, że proces powiązał się z portami UDP i TCP

Nigdy nie restartuj bez testu -N1: Wprowadź żelazną zasadę administracyjną: przed każdym wykonaniem systemctl restart rsyslog zawsze wywołaj rsyslogd -N1. Zabezpiecza to infrastrukturę przed przypadkowym wyłączeniem rejestracji zdarzeń.

Pełna sesja walidacji i uruchomienia centralnego serwera rsyslog

root@nms-syslog:~# rsyslogd -N1 rsyslogd: version 8.2302.0, config validation run... rsyslogd: End of config validation run. No syntax errors found. [SUCCESS] root@nms-syslog:~# echo $? 0 root@nms-syslog:~# systemctl restart rsyslog root@nms-syslog:~# systemctl is-active rsyslog active root@nms-syslog:~# ss -tulpn | grep 514 udp UNCONN 0 0 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=1680,fd=6)) tcp LISTEN 0 25 0.0.0.0:514 0.0.0.0:* users:(("rsyslogd",pid=1680,fd=7))

Cel slajdu: Prześledzenie drogi komunikatu telemetrycznego od aplikacji w przestrzeni użytkownika do gniazda sieciowego.

Konfiguracja zdalnych stacji roboczych Linux

W nowoczesnych systemach Linux architektura rejestrowania zdarzeń łączy binarny dziennik systemd-journald z uniwersalnym demonem rsyslog. Zrozumienie relacji pomiędzy tymi procesami jest kluczem do bezbłędnej konfiguracji klienta sieciowego.

Gniazdo /dev/log: Standardowy punkt wejścia dla biblioteki libc (funkcja syslog()). Kompatybilny ze wszystkimi demonami Uniksa
Rola systemd-journald: Współczesny menedżer systemd przechwytuje strumienie stdout/stderr usług i zapisuje je w pamięci ulotnej
Przekierowanie do rsyslog: Opcja ForwardToSyslog=yes w /etc/systemd/journald.conf przekazuje kopię każdego rekordu do rsyslog
Moduł wyjściowy omfwd: Output Module Forwarding – dedykowany komponent rsyslog odpowiedzialny za transmisję pakietów przez sieć IP

Dlaczego nie wysyłać logów bezpośrednio z journald? Demon systemd-journald posiada wprawdzie moduł systemd-journal-upload, lecz wymaga on osobnego serwera z protokołem HTTP/HTTPS. Demon rsyslog zapewnia natywną zgodność ze standardem IETF Syslog, buforowanie dyskowe i bezpośrednią integrację z routerami MikroTik.

Weryfikacja gniazda /dev/log i powiązania z systemd na stacji roboczej

user@PC-01:~$ ls -l /dev/log lrwxrwxrwx 1 root root 28 Sep 29 18:00 /dev/log -> /run/systemd/journal/dev-log user@PC-01:~$ systemctl is-active systemd-journald rsyslog active active

Cel slajdu: Praktyczne wdrożenie konfiguracji przekazywania strumienia zdarzeń ze stacji roboczej do serwera centralnego.

Konfiguracja zdalnych stacji roboczych Linux

Na stacji roboczej lub serwerze aplikacyjnym Linux konfiguracja przesyłania sprowadza się do utworzenia pliku z dyrektywą modułu wyjściowego omfwd. Zalecanym medium dla maszyn linuksowych jest protokół połączeniowy TCP na porcie 514.

Plik 99-forward-all.conf: Prefiks 99 gwarantuje, że reguła zostanie przetworzona na samym końcu, po zapisaniu logów lokalnych stacji
Parametr target: Wskazuje adres IP lub nazwę FQDN centralnego kolektora rsyslog (192.168.1.100)
Parametr protocol="tcp": Wymusza nawiązanie trwałej sesji TCP, zapewniając retransmisję w razie chwilowych zatorów sieciowych
Weryfikacja połączenia: Polecenie ss -tan | grep 514 na stacji roboczej potwierdza stan ESTABLISHED dla sesji z serwerem

Zachowanie logów lokalnych na stacji: Zastosowanie dyrektywy action(type="omfwd" ...) bez instrukcji stop powoduje, że logi są jednocześnie zapisywane lokalnie w /var/log/syslog stacji oraz wysyłane przez sieć na serwer centralny.

Wdrożenie pliku przekazywania na stacji roboczej i sprawdzenie sesji TCP

root@PC-01:~# cat << 'EOF' > /etc/rsyslog.d/99-forward-all.conf # Przekazanie wszystkich zdarzeń stacji roboczej na serwer centralny rsyslog action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp") EOF root@PC-01:~# rsyslogd -N1 && systemctl restart rsyslog root@PC-01:~# ss -tan | grep 192.168.1.100:514 ESTAB 0 0 192.168.1.150:48212 192.168.1.100:514

Cel slajdu: Optymalizacja pasma sieciowego i zasobów serwera poprzez wstępną selekcję zdarzeń u źródła.

Konfiguracja zdalnych stacji roboczych Linux

W dużych infrastrukturach przesyłanie wszystkich komunikatów ze stacji roboczych (np. każdego zapytania DNS czy uruchomienia zadania cron co minutę) prowadzi do marnotrawstwa pasma sieciowego i przestrzeni dyskowej. Stacja kliencka powinna filtrować zdarzenia u źródła.

Filtr *.warning: Przekazuje na serwer wyłącznie anomalie, błędy jądra, awarie dysków i ostrzeżenia usług
Filtr auth,authpriv.*: Gwarantuje, że każde logowanie użytkownika, użycie sudo czy próba ataku na SSH trafi do centralnego audytu
Wykluczanie kategorii (none): Zapis *.*;cron.none;mail.none zapobiega wysyłaniu rutynowych powiadomień harmonogramu
Elastyczność wdrożenia: Możliwość zdefiniowania różnych poziomów dla stacji deweloperskich (tylko błędy) i serwerów bazodanowych (pełen audyt)

Składnia selektorów w rsyslog: Średnik ; oddziela poszczególne reguły selektora. Wyrażenie *.info;mail.none;authpriv.none oznacza: wysyłaj zdarzenia o poziomie info i wyższym z dowolnego źródła, z wyjątkiem poczty i prywatnego podsystemu uwierzytelniania.

Konfiguracja zoptymalizowanego filtra klienta w /etc/rsyslog.d/99-forward-filtered.conf

root@PC-01:~# cat << 'EOF' > /etc/rsyslog.d/99-forward-filtered.conf # Przekazuj ważne zdarzenia: ostrzeżenia, błędy oraz pełny audyt logowania *.warning;auth,authpriv.* action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp") EOF root@PC-01:~# systemctl restart rsyslog Zastosowano filtr: Stacja PC-01 wysyła wyłącznie zdarzenia krytyczne i audyt!

Cel slajdu: Zrozumienie mechanizmu buforowania awaryjnego (Disk-Assisted Memory Queue) zapobiegającego utracie danych.

Konfiguracja zdalnych stacji roboczych Linux

Gdy serwer rsyslog ulegnie restartowi lub pracom konserwacyjnym, stacja robocza próbująca wysyłać pakiety przez TCP napotyka na zamknięte gniazdo. Domyślnie rsyslog zablokuje kolejkę pamięciową, co może doprowadzić do zawieszenia demonów systemowych piszących do /dev/log.

Architektura hybrydowa: Kolejka typu LinkedList w pamięci RAM wspomagana awaryjnym zrzutem na dysk (Disk-Assisted)
Pojemność kolejki RAM: Standardowo mieści kilka tysięcy komunikatów. Gdy próg zostanie przekroczony, demon uruchamia wątek zapisu dyskowego
Katalog bufora /var/spool/rsyslog: Pliki fwd_spool.* przechowują wiadomości w kolejności nadejścia aż do momentu powrotu łączności
Parametr timeoutenqueue="0": Gwarantuje, że aplikacje lokalne nigdy nie będą blokowane (natychmiastowe przyjęcie do bufora lub zrzut)

Zabezpieczenie przed wyłączeniem stacji (SaveOnShutdown): Parametr queue.saveonshutdown="on" nakazuje demonowi rsyslog zrzucenie całej zawartości kolejki RAM na dysk podczas zamykania systemu (reboot/shutdown). Zapobiega to utracie logów w trakcie restartu stacji roboczej.

Weryfikacja zachowania bufora dyskowego podczas symulowanej awarii serwera

root@PC-01:~# ls -la /var/spool/rsyslog/ total 8 drwxr-x--- 2 syslog adm 4096 Sep 29 19:40 . drwxr-xr-x 8 root root 4096 Sep 29 18:00 .. # Podczas awarii sieci pojawiają się pliki zrzutu: root@PC-01:~# ls -la /var/spool/rsyslog/ -rw------- 1 syslog adm 1048576 Sep 29 19:42 fwd_spool.00000001 # Rsyslog bezpiecznie buforuje logi na dysku lokalnym!

Cel slajdu: Praktyczna implementacja odpornego mechanizmu kolejkowania omfwd w pliku konfiguracyjnym klienta.

Konfiguracja zdalnych stacji roboczych Linux

Składamy wszystkie elementy wiedzy w jeden produkcyjny blok konfiguracyjny. Utworzymy katalog bufora z odpowiednimi uprawnieniami oraz wdrożymy pełną definicję akcji omfwd w pliku /etc/rsyslog.d/99-forward-ha.conf.

Przygotowanie katalogu bufora: mkdir -p /var/spool/rsyslog && chown -R syslog:adm /var/spool/rsyslog && chmod 700 /var/spool/rsyslog
Parametr resumeRetryCount="-1": Wartość -1 nakazuje rsyslog ponawianie prób połączenia w nieskończoność bez porzucania akcji
Zabezpieczenie limitu dyskowego: queue.maxdiskspace="1g" gwarantuje, że bufor awaryjny nie zajmie więcej niż 1 GB przestrzeni dyskowej
Format pliku bufora: Rsyslog dzieli bufor dyskowy na części o rozmiarze 10 MB (fwd_spool.00000001, fwd_spool.00000002 itd.)

Uprawnienia do katalogu spool: Jeśli katalog /var/spool/rsyslog będzie należał do roota i nie będzie miał praw zapisu dla użytkownika syslog, mechanizm bufora dyskowego nie zadziała i rsyslog zgłosi błąd w journalctl.

Wdrożenie kompletnego pliku 99-forward-ha.conf na stacji roboczej

root@PC-01:~# mkdir -p /var/spool/rsyslog root@PC-01:~# chown -R syslog:adm /var/spool/rsyslog root@PC-01:~# chmod 700 /var/spool/rsyslog root@PC-01:~# cat << 'EOF' > /etc/rsyslog.d/99-forward-ha.conf action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp" action.resumeRetryCount="-1" queue.type="LinkedList" queue.filename="fwd_spool" queue.spoolDirectory="/var/spool/rsyslog" queue.maxdiskspace="1g" queue.saveonshutdown="on") EOF root@PC-01:~# rsyslogd -N1 && systemctl restart rsyslog Klient skonfigurowany w trybie wysokiej dostępności (HA) z buforem dyskowym!

Cel slajdu: Prawidłowa konfiguracja przekazywania zdarzeń z binarnego dziennika systemd do rsyslog na stacjach roboczych.

Konfiguracja zdalnych stacji roboczych Linux

W nowoczesnych dystrybucjach Linux menedżer systemd zarządza procesami i loguje ich komunikaty przez systemd-journald. Aby te zdarzenia mogły zostać wysłane do sieci przez moduł omfwd, journald musi przekazywać je do demona rsyslog.

Plik /etc/systemd/journald.conf: Kluczowa dyrektywa ForwardToSyslog=yes nakazuje journald przesyłanie kopii do gniazda /run/systemd/journal/syslog
Moduł imuxsock: Domyślny moduł rsyslog odbierający tradycyjne pakiety z gniazda unixowego z minimalnym narzutem procesora
Moduł imjournal (Opcjonalny): Czyta bezpośrednio z binarnej bazy journald. Umożliwia wyciąganie zaawansowanych metadanych (_SYSTEMD_UNIT, _EXE)
Zalecenie produkcyjne: W środowiskach o dużym natężeniu logów preferowany jest imuxsock ze względu na wyższą wydajność i brak blokowania bazy journald

Dlaczego niektóre usługi nie trafiały do Syslog? Jeśli w pliku journald.conf opcja ForwardToSyslog jest zakomentowana lub ustawiona na no, komunikaty generowane przez usługi piszące wyłącznie do standardowego wyjścia (stdout) zostaną uwięzione w binarnej bazie journald i nigdy nie trafią na serwer centralny!

Konfiguracja i restart usługi systemd-journald

root@PC-01:~# sed -i 's/^#ForwardToSyslog=.*/ForwardToSyslog=yes/' /etc/systemd/journald.conf root@PC-01:~# systemctl restart systemd-journald root@PC-01:~# systemctl is-active systemd-journald active # Usługa journald przekazuje teraz 100% zdarzeń do rsyslog

Cel slajdu: Praktyczna weryfikacja toru telemetrycznego za pomocą syntetycznych zdarzeń generowanych z wiersza poleceń.

Konfiguracja zdalnych stacji roboczych Linux

Standardowe uniksowe narzędzie logger jest niezastąpionym instrumentem każdego inżyniera sieciowego. Pozwala ono na wygenerowanie dowolnego rekordu o zadanym kodzie Facility i Severity bez konieczności oczekiwania na wystąpienie realnej awarii.

Narzędzie CLI logger: Standardowy komponent pakietu bsdutils / util-linux obecny w każdej dystrybucji Linuksa
Przełącznik -p: Definiuje parę kategoria.ważność, np. local0.warning, authpriv.alert, kern.crit
Przełącznik -t: Nadaje procesowi unikalny identyfikator TAG, ułatwiający korelatorom NMS identyfikację źródła
Przełącznik -s: Wypisuje komunikat na standardowe wyjście błędów (stderr) konsoli, umożliwiając podgląd w skryptach

Skrypt automatyzujący testy weryfikacyjne: Możesz utworzyć prosty skrypt Bash wysyłający serię komunikatów o rosnącym poziomie istotności, aby zweryfikować czy serwer poprawnie rozdziela je do warning.log i critical.log.

Generowanie serii testowej poleceniem logger ze stacji roboczej PC-01

user@PC-01:~$ logger -p local0.info -t NMS-AUDIT "KROK 1: Test komunikatu informacyjnego info" user@PC-01:~$ logger -p local0.warning -t NMS-AUDIT "KROK 2: Test komunikatu ostrzegawczego warning" user@PC-01:~$ logger -p local0.crit -t NMS-AUDIT "KROK 3: Test krytycznego błędu critical" user@PC-01:~$ journalctl -t NMS-AUDIT -n 3 --no-pager Sep 29 19:48:01 PC-01 NMS-AUDIT[2104]: KROK 1: Test komunikatu informacyjnego info Sep 29 19:48:03 PC-01 NMS-AUDIT[2105]: KROK 2: Test komunikatu ostrzegawczego warning Sep 29 19:48:05 PC-01 NMS-AUDIT[2106]: KROK 3: Test krytycznego błędu critical

Cel slajdu: Opanowanie diagnostyki sieciowej za pomocą bezpośredniej wysyłki pakietów RFC 5424 przez UDP i TCP.

Konfiguracja zdalnych stacji roboczych Linux

Gdy serwer nie rejestruje logów ze stacji roboczej, inżynier musi ustalić, czy problem leży w konfiguracji lokalnego demona rsyslog na stacji, w regułach zapory sieciowej, czy na samym serwerze. Narzędzie logger pozwala na całkowite ominięcie lokalnego rsyslog.

Parametr -n <IP>: Kieruje pakiet bezpośrednio do gniazda sieciowego zdalnego serwera z pominięciem /dev/log
Wymuszenie protokołu: Przełącznik -T wymusza nawiązanie sesji TCP, z kolei -d (domyślny) wysyła pojedynczy datagram UDP
Flaga --rfc5424: Generuje nowoczesną ramkę IETF z pełnym znacznikiem czasu ISO 8601 oraz wersją protokołu
Struktury Structured Data: Możliwość dołączenia parametrów --sd-id oraz --sd-param do testowania parserów SIEM

Testowanie portu UDP z konsoli: Ponieważ narzędzie telnet ani standardowy nc nie dają pewności przy UDP, komenda logger -n 192.168.1.100 -P 514 -d "Test UDP" jest najszybszym i najbardziej niezawodnym sposobem zweryfikowania odbioru datagramów UDP.

Bezpośrednie wstrzykiwanie testowego pakietu RFC 5424 przez TCP

user@PC-01:~$ logger -n 192.168.1.100 -P 514 -T --rfc5424=app-name,procid -t TEST-DIRECT "Wstrzyknięcie bezpośrednie przez TCP RFC5424" # Pakiet przesłany bezpośrednio do gniazda TCP serwera 192.168.1.100:514 user@PC-01:~$ logger -n 192.168.1.100 -P 514 -d -p local0.alert -t TEST-UDP "Wstrzyknięcie datagramu UDP 514" # Datagram UDP wysłany do serwera!

Cel slajdu: Potwierdzenie prawidłowego działania dynamicznych szablonów na serwerze i podgląd napływających logów.

Konfiguracja zdalnych stacji roboczych Linux

Po wysłaniu pierwszych zdarzeń ze stacji roboczej przechodzimy na konsolę serwera rsyslog. Sprawdzamy, czy demon w locie utworzył katalog odpowiadający adresowi IP stacji (192.168.1.150) oraz czy odpowiednie pliki zostały zasilone rekordami.

Polecenie tree /var/log/remote: Błyskawiczny podgląd drzewa katalogów utworzonych przez reguły dynaFile
Weryfikacja uprawnień: Katalogi powinny mieć prawa drwxr-x--- (0750) z właścicielem syslog:adm
Śledzenie ciągłe tail -f: tail -f /var/log/remote/192.168.1.150/all.log pozwala obserwować napływające pakiety na żywo
Kontrola critical.log: Sprawdzenie, czy zdarzenie o poziomie 'crit' trafiło równolegle do pliku critical.log

Podgląd wielu maszyn jednocześnie: Za pomocą narzędzia multitail lub potoku tail -f /var/log/remote/*/*.log administrator może obserwować strumienie ze wszystkich podłączonych maszyn w jednym oknie terminala.

Weryfikacja na serwerze rsyslog po odebraniu zdarzeń ze stacji PC-01

root@nms-syslog:~# ls -la /var/log/remote/192.168.1.150/ total 24 drwxr-x--- 2 syslog adm 4096 Sep 29 19:50 . drwxr-x--- 3 syslog adm 4096 Sep 29 19:45 .. -rw-r----- 1 syslog adm 420 Sep 29 19:50 all.log -rw-r----- 1 syslog adm 142 Sep 29 19:50 critical.log -rw-r----- 1 syslog adm 280 Sep 29 19:50 warning.log root@nms-syslog:~# cat /var/log/remote/192.168.1.150/critical.log 2026-09-29T19:50:05+02:00 PC-01 NMS-AUDIT[2106]: KROK 3: Test krytycznego błędu critical Potwierdzono: Rekord krytyczny trafił do dedykowanego pliku critical.log!

Cel slajdu: Zrozumienie trójwarstwowej struktury logowania w systemie RouterOS: Tematy (Topics), Reguły decyzyjne i Cele (Actions).

Zdalne logowanie w MikroTik RouterOS

Podsystem logowania w MikroTik RouterOS (zarówno w wersji 6, jak i nowoczesnej wersji 7) różni się architektonicznie od klasycznego demona linuksowego. Zamiast sztywnego podziału na Facility i Severity, RouterOS posługuje się elastycznym mechanizmem tematów (Topics) i akcji (Actions).

Tematy (Topics): Znaczniki przypisywane do każdego zdarzenia przez jądro i pakiety RouterOS (np. firewall, info, critical, dhcp, ospf)
Tabela reguł /system logging: Łączy wybrane kombinacje tematów z konkretną akcją docelową (odpowiednik reguł filtrujących)
Miejsca docelowe (Actions): Definiują sposób utrwalenia zdarzenia: pamięć RAM (memory), pamięć masowa (disk), ekran konsoli (echo) lub sieć (remote)
Obsługa w RouterOS v6 i v7: Architektura jest w pełni spójna pomiędzy generacjami, z rozszerzeniem v7 o lepsze wsparcie dla IPv6 i FQDN

Wielotematowość zdarzeń w RouterOS: Pojedynczy komunikat w RouterOS może posiadać kilka tematów jednocześnie, np. firewall,info lub system,error,critical. Reguła dopasowuje zdarzenie tylko wtedy, gdy zawiera ono wszystkie tematy wymienione w regule.

Podgląd domyślnej konfiguracji logowania w konsoli RouterOS

[admin@MikroTik-GW] > /system logging print Flags: X - disabled, I - invalid, * - default # TOPICS ACTION PREFIX 0 * info memory 1 * error memory 2 * warning memory 3 * critical echo # Uwaga: Domyślnie logi info, error i warning trafiają do ulotnej pamięci RAM (memory), a critical — do konsoli (echo)!

Cel slajdu: Zrozumienie ograniczeń lokalnych akcji RouterOS oraz konieczności stosowania akcji zdalnej (remote).

Zdalne logowanie w MikroTik RouterOS

RouterBoardy posiadają ograniczone zasoby sprzętowe. Modele takie jak hEX, RB750Gr3 czy hAP ac2 wyposażone są w miniaturowe kości pamięci flash o pojemności zaledwie 16 MB. Nieodpowiedzialne logowanie na dysk wewnętrzny prowadzi do nieodwracalnego uszkodzenia urządzenia.

Ulotność akcji memory: Bufor pamięci RAM trzyma domyślnie 1000 ostatnich linii. Restart urządzenia kasuje wszystkie ślady włamania
Ryzyko zużycia Flash (Wear-out): Kości NAND posiadają ograniczoną liczbę cykli zapisu (P/E cycles). Ciągły zapis logów zapory prowadzi do uszkodzenia pamięci
Przewaga akcji remote: Pakiety UDP są wysyłane asynchronicznie bezpośrednio z pamięci RAM do sieci, nie dotykając pamięci flash routera
Nieograniczona retencja: Serwer centralny rsyslog dysponuje macierzami SSD o pojemności terabajtów, umożliwiając przechowywanie logów przez lata

Zasada projektowa dla MikroTik: Nigdy nie ustawiaj action=disk dla tematów o wysokiej częstotliwości (firewall, dhcp, wireless). Pamięć flash powinna być zarezerwowana wyłącznie dla konfiguracji urządzenia i kopii zapasowych. Wszystkie logi operacyjne powinny być natychmiast wysyłane do akcji remote.

Podgląd parametrów akcji w RouterOS CLI

[admin@MikroTik-GW] > /system logging action print detail where name="remote" Flags: * - default 3 * name="remote" target=remote remote="0.0.0.0" remote-port=514 src-address=0.0.0.0 bsd-syslog=no syslog-facility=daemon syslog-severity=auto # Domyślna akcja 'remote' jest nieskonfigurowana (remote=0.0.0.0)

Cel slajdu: Pełna parametryzacja akcji 'remote' w wierszu poleceń MikroTik RouterOS i wyjaśnienie każdego atrybutu.

Zdalne logowanie w MikroTik RouterOS

Zamiast modyfikować domyślną akcję 'remote', dobrą praktyką inżynierską jest utworzenie nowej, nazwanej akcji docelowej (np. syslog-server). Pozwala to na precyzyjne dostosowanie parametrów bez zakłócania innych podsystemów routera.

Nazwa akcji (name=syslog-server): Unikalna nazwa celu używana później w regułach /system logging
Typ celu i adres (target=remote remote=192.168.1.100): Określa akcję sieciową oraz docelowy adres IP serwera rsyslog (w RouterOS v7 może to być także nazwa FQDN)
Kategoria (syslog-facility=local0): Wymusza kod Facility 16 (local0), co pozwala serwerowi Linux na bezbłędne rozpoznanie routera
Format czasu (bsd-syslog=no): Flaga nakazująca generowanie znacznika czasu ISO 8601 ze strefą czasową zamiast skróconego formatu BSD

Rola parametru src-address: Jeśli router posiada kilka interfejsów (np. WAN, LAN, DMZ, Loopback), pakiet UDP może opuścić router z różnymi adresami źródłowymi w zależności od tablicy routingu. Ustawienie src-address=192.168.1.1 wymusza stały adres IP nadawcy, dzięki czemu rsyslog zawsze zapisze logi w tym samym katalogu /var/log/remote/192.168.1.1/!

Wprowadzenie konfiguracji akcji zdalnej w CLI MikroTik

[admin@MikroTik-GW] > /system logging action add name=syslog-server target=remote remote=192.168.1.100 remote-port=514 syslog-facility=local0 syslog-severity=auto bsd-syslog=no src-address=192.168.1.1 [admin@MikroTik-GW] > /system logging action print detail where name="syslog-server" 4 name="syslog-server" target=remote remote="192.168.1.100" remote-port=514 src-address=192.168.1.1 bsd-syslog=no syslog-facility=local0 syslog-severity=auto Akcja zdalna skonfigurowana poprawnie i gotowa do powiązania z tematami!

Cel slajdu: Precyzyjne zdefiniowanie zestawu reguł przekazujących kluczowe zdarzenia z routera na serwer rsyslog.

Zdalne logowanie w MikroTik RouterOS

Po utworzeniu akcji docelowej musimy wskazać, które zdarzenia mają być do niej kierowane. W podmenu /system logging tworzymy zestaw reguł przechwytujących błędy systemowe, próby logowania, reguły zapory oraz stan dzierżaw DHCP.

Tematy krytyczne (critical, error, warning): Podstawa każdego wdrożenia – informuje o awariach zasilania, restarcie usług i błędach konfiguracji
Temat account: Audyt bezpieczeństwa – rejestruje logowania administratorów przez WinBox, SSH, WebFig i konsolę
Temat firewall: Zdarzenia generowane przez reguły zapory ogniowej z włączoną flagą log=yes
Tematy złożone (dhcp,info): Zapis dhcp,info przechwytuje zdarzenia serwera DHCP bez konieczności włączania całego ogólnego tematu info

Przestroga przed tematem info bez filtrów: Dodanie reguły topics=info action=syslog-server w sieci, gdzie router pełni rolę serwera DNS i obsługuje setki klientów, wygeneruje potok tysięcy pakietów na sekundę. Zawsze stosuj tematy zawężone (np. dhcp,info) lub wykluczenia (!dns).

Wprowadzanie reguł logowania w CLI RouterOS

[admin@MikroTik-GW] > /system logging add action=syslog-server topics=critical [admin@MikroTik-GW] > /system logging add action=syslog-server topics=error [admin@MikroTik-GW] > /system logging add action=syslog-server topics=warning [admin@MikroTik-GW] > /system logging add action=syslog-server topics=account [admin@MikroTik-GW] > /system logging add action=syslog-server topics=firewall [admin@MikroTik-GW] > /system logging add action=syslog-server topics=dhcp,info [admin@MikroTik-GW] > /system logging print Reguły zostały aktywowane i router natychmiast rozpoczyna nadawanie UDP 514!

Cel slajdu: Prawidłowa konfiguracja logowania odrzucanych pakietów zapory sieciowej z unikalnymi znacznikami identyfikacyjnymi.

Zdalne logowanie w MikroTik RouterOS

Domyślnie reguły zapory RouterOS odrzucają pakiety po cichu (silent drop). Aby zarejestrować próbę ataku na serwerze rsyslog, na wybranej regule musimy aktywować flagę log=yes oraz zdefiniować unikalny parametr log-prefix.

Flaga log=yes: Wymusza wygenerowanie zdarzenia o temacie 'firewall' w momencie wykonania akcji reguły (np. drop, reject)
Parametr log-prefix: Dowolny tekst doklejany na początku każdego komunikatu. Pozwala zidentyfikować, która reguła odrzuciła pakiet
Zasada wydajnościowa: Nigdy nie loguj reguł akceptujących ruch Established/Related! Loguj wyłącznie pakiety odrzucane na interfejsie WAN
Struktura rekordu firewall: Pakiet zawiera: in-interface, out-interface, src-mac, src-ip:port, dst-ip:port, proto oraz wielkość pakietu len

Zalecana konwencja nazewnicza prefiksów: Używaj zwięzłych, wielkich liter ze znakiem dwukropka, np. log-prefix="FW_DROP_WAN_IN: ", log-prefix="FW_PORT_SCAN: ", log-prefix="FW_BRUTE_FORCE: ". Ułatwia to automatyczne parsowanie w potokach Bash i silnikach SIEM.

Konfiguracja reguły zapory z logowaniem w CLI MikroTik

[admin@MikroTik-GW] > /ip firewall filter add chain=input in-interface-list=WAN protocol=tcp dst-port=22,8291 action=drop log=yes log-prefix="DROP_MANAGEMENT_ATTEMPT: " comment="Blokada prób logowania SSH/WinBox z WAN" # W momencie uderzenia pakietu z zewnątrz serwer rsyslog rejestruje wpis: 2026-09-29T19:55:12+02:00 MikroTik-GW firewall,info DROP_MANAGEMENT_ATTEMPT: in:ether1 out:(unknown 0), src-mac 00:50:56:c0:00:08, proto TCP (SYN), 198.51.100.24:54122->192.168.1.1:22, len 60

Cel slajdu: Rejestrowanie przychodzących połączeń przekierowywanych przez mechanizm DST-NAT do wewnętrznych serwerów.

Zdalne logowanie w MikroTik RouterOS

Gdy serwer wewnątrz sieci LAN lub DMZ udostępnia usługi dla publicznego Internetu przez przekierowanie portów (DSTNAT), zapora routera dokonuje translacji adresu docelowego. Logowanie reguły DSTNAT jest niezbędne dla spełnienia norm bezpieczeństwa (audyt dostępu do zasobów wewnętrznych).

Logowanie reguł DSTNAT: Rejestruje publiczny adres IP klienta, port źródłowy oraz prywatny adres IP serwera docelowego
Identyfikacja prób eksploracji: Pozwala wykryć próby skanowania podatności webowych jeszcze zanim dotrą one do logów serwera aplikacji
Przestroga przed logowaniem SRCNAT/Masquerade: Logowanie każdego pakietu wychodzącego generuje gigabajty danych na godzinę i przeciąża CPU routera
Znaczenie w dochodzeniach: Zgodnie z wymaganiami KRI i RODO administrator musi być w stanie wykazać, kto i kiedy łączył się z bazą danych

Kiedy logować pakiety INVALID? W łańcuchu forward warto dodać regułę logującą pakiety ze statusem connection-state=invalid z prefiksem "DROP_INVALID: ". Pakiety te często świadczą o próbach ominięcia filtrów stanowych lub błędach routingu asymetrycznego u dostawcy ISP.

Konfiguracja reguły logowania podejrzanych pakietów invalid

[admin@MikroTik-GW] > /ip firewall filter add chain=forward connection-state=invalid action=drop log=yes log-prefix="DROP_INVALID_FWD: " comment="Odrzucanie pakietów uszkodzonych/nieprawidłowych" [admin@MikroTik-GW] > /ip firewall filter print where log=yes Flags: X - disabled, I - invalid, D - dynamic 0 chain=input action=drop log=yes log-prefix="DROP_WAN_INPUT: " 1 chain=forward action=drop connection-state=invalid log=yes log-prefix="DROP_INVALID_FWD: "

Cel slajdu: Rejestrowanie cyklu przyznawania adresów IP oraz wykrywanie konfliktów i obcych stacji w sieci LAN.

Zdalne logowanie w MikroTik RouterOS

W dynamicznych sieciach biurowych stacje robocze regularnie zmieniają adresy IP. Aby w razie wykrycia incydentu (np. pobrania złośliwego oprogramowania) ustalić, który pracownik korzystał z danego IP o godzinie 14:15, administrator musi dysponować kompletnym archiwum dzierżaw DHCP.

Zdarzenie assigned: Rejestruje przydział nowego adresu IP wraz z adresem MAC karty sieciowej oraz nazwą stacji roboczej (hostname)
Zdarzenie conflict detected: Alarmuje o sytuacji, w której stacja ustawiła statyczny adres IP zajęty już w puli DHCP
Zdarzenie deassigned: Informuje o zwolnieniu adresu lub wygaśnięciu czasu dzierżawy (Lease Time)
Zgodność z audytem prawnym: Kluczowy dowód kryminalistyczny w sprawach naruszeń praw autorskich lub włamań z sieci Wi-Fi

Wyszukiwanie adresu MAC dla historycznego incydentu: Za pomocą prostego polecenia na serwerze Linux możemy ustalić, jakie urządzenie posiadało dany IP w przeszłości:
grep "192.168.1.155" /var/log/remote/192.168.1.1/all.log | grep "assigned".

Weryfikacja logów DHCP RouterOS na centralnym serwerze rsyslog

root@nms-syslog:~# grep "dhcp,info" /var/log/remote/192.168.1.1/all.log | tail -n 3 2026-09-29T20:00:15+02:00 MikroTik-GW dhcp,info defconf assigned 192.168.1.155 to 3C:06:30:11:22:33 (laptop-jnowak) 2026-09-29T20:01:22+02:00 MikroTik-GW dhcp,info defconf assigned 192.168.1.156 to F4:D4:88:55:66:77 (drukarka-ksiegowosc) 2026-09-29T20:02:10+02:00 MikroTik-GW dhcp,info defconf deassigned 192.168.1.150 from BC:24:11:AA:BB:CC Pełna historia dzierżaw zindeksowana w repozytorium zdalnym!

Cel slajdu: Rejestrowanie sesji administracyjnych oraz wykrywanie nieautoryzowanych prób logowania do routera.

Zdalne logowanie w MikroTik RouterOS

Zabezpieczenie routera brzegowego wymaga ścisłego monitorowania dostępu do kont administracyjnych. Temat 'account' w RouterOS rejestruje każdą próbę autoryzacji, adres IP stacji zarządzającej oraz typ użytego interfejsu (WinBox port 8291, SSH port 22 czy REST API port 443).

Temat account,info: Informuje o poprawnym zalogowaniu administratora (logged in) oraz wylogowaniu (logged out)
Temat account,warning: Kluczowy alert bezpieczeństwa – rejestruje zdarzenia 'login failure' wraz z użytą nazwą konta i IP intruza
Zdarzenia system,info: Rejestruje zmiany w konfiguracji urządzenia (dodanie reguły, zmiana hasła, restart)
Odporność na sabotaż: Nawet jeśli intruz po udanym logowaniu usunie lokalny log, serwer rsyslog posiada już nienaruszalny zapis

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.

Weryfikacja nieudanych prób logowania na routerze z konsoli serwera

root@nms-syslog:~# grep "login failure" /var/log/remote/192.168.1.1/all.log | tail -n 3 2026-09-29T20:05:44+02:00 MikroTik-GW account,warning: login failure for user root from 203.0.113.88 via ssh 2026-09-29T20:05:46+02:00 MikroTik-GW account,warning: login failure for user admin from 203.0.113.88 via ssh 2026-09-29T20:05:48+02:00 MikroTik-GW account,warning: login failure for user ubnt from 203.0.113.88 via ssh Wykryto zmasowany atak brute-force SSH na router MikroTik!

Cel slajdu: Rejestrowanie zdarzeń awarii łączy fizycznych, przełączania tras zapasowych oraz sesji OSPF/BGP.

Zdalne logowanie w MikroTik RouterOS

Standardowy polling SNMP odpytuje routery zazwyczaj co 1 lub 5 minut. W przypadku przecięcia kabla światłowodowego asynchroniczny komunikat Syslog trafia na serwer w czasie poniżej 10 milisekund od zgaśnięcia diody portu, co pozwala systemowi NMS na natychmiastowe zaalarmowanie inżynierów.

Temat interface,info: Rejestruje natychmiastową zmianę stanu interfejsu (link down / link up) oraz negocjację prędkości (speed 1Gbps, full duplex)
Zjawisko Link Flapping: Wykrywa niestabilne łącza radiowe lub uszkodzone wkładki SFP, które generują dziesiątki przełączeń na minutę
Tematy OSPF i BGP: Rejestrują przejścia stanów sąsiedztwa routingu dynamicznego (Neighbor Down, Full State)
Korelacja z metrykami SNMP: Potwierdza przyczynę nagłego spadku wykresu ruchu SNMP do zera na łączu głównym

Dlaczego Syslog jest szybszy od SNMP: SNMP opiera się na cyklicznym odpytywaniu (Pull Model) – jeśli awaria nastąpi tuż po zapytaniu, NMS dowie się o niej dopiero za 60 sekund. Syslog działa w modelu zdarzeniowym (Push Model) – pakiet opuszcza router natychmiast po wykryciu braku nośnej na złączu fizycznym.

Weryfikacja zmian stanu interfejsów w logach serwera

root@nms-syslog:~# grep "interface,info" /var/log/remote/192.168.1.1/all.log | tail -n 2 2026-09-29T20:10:00+02:00 MikroTik-GW interface,info: sfp-sfpplus1 link down 2026-09-29T20:11:15+02:00 MikroTik-GW interface,info: sfp-sfpplus1 link up (speed 10Gbps, full duplex) Czas trwania przerwy w fizycznej łączności światłowodowej: dokładnie 75 sekund.

Cel slajdu: Opanowanie zaawansowanych poleceń wiersza poleceń RouterOS do podglądu, filtrowania i śledzenia logów.

Zdalne logowanie w MikroTik RouterOS

Podczas prac wdrożeniowych na routerze inżynier często musi na bieżąco weryfikować, czy tworzone reguły zapory lub akcje logowania działają poprawnie. RouterOS CLI udostępnia zaawansowane narzędzia filtrowania bufora pamięci ulotnej.

Polecenie /log print: Wyświetla aktualną zawartość bufora pamięci RAM wraz z czasem, tematami i tekstem wiadomości
Przełącznik follow: Wymusza tryb ciągłego śledzenia w czasie rzeczywistym (odpowiednik uniksowego tail -f)
Filtrowanie wyrażeniami regularnymi (~): Klauzula where topics~"firewall" lub where message~"DROP" zawęża wyniki do interesujących zdarzeń
Statystyki zdarzeń: Przełącznik count-only pozwala szybko zliczyć liczbę incydentów w danym przedziale czasu

Szybki test wysyłki logów z CLI RouterOS: Możesz wygenerować testowy wpis logu bezpośrednio z konsoli MikroTik poleceniem:
:log info "TEST_MANUAL: Reczny test wysylki logu do rsyslog"
i natychmiast sprawdzić czy pojawił się on w /var/log/remote/192.168.1.1/all.log.

Interaktywna sesja śledzenia logów zapory w RouterOS CLI

[admin@MikroTik-GW] > /log print follow where topics~"firewall" 20:15:10 firewall,info DROP_WAN_INPUT: in:ether1 proto TCP, 198.51.100.12:44122->192.168.1.1:23, len 40 20:15:12 firewall,info DROP_WAN_INPUT: in:ether1 proto UDP, 203.0.113.55:5060->192.168.1.1:5060, len 320 20:15:14 firewall,info DROP_INVALID_FWD: in:ether1 proto TCP, 198.51.100.99:80->192.168.1.200:54122, len 52 -- naciśnij Ctrl+C aby zatrzymać śledzenie --

Cel slajdu: Budowa bezpiecznego, zgodnego z normami audytowymi magazynu /var/log/remote/ w systemie plików Linux.

Integracja, bezpieczeństwo i utrzymanie

Centralne repozytorium zdarzeń gromadzi poufne informacje o użytkownikach, adresach IP, otwartych portach oraz próbach logowań. Niewłaściwe uprawnienia w systemie plików mogłyby umożliwić nieuprawnionym pracownikom odczyt danych objętych tajemnicą przedsiębiorstwa.

Prawa katalogów 0750 (drwxr-x---): Właściciel 'syslog' ma pełen dostęp (rwx), grupa 'adm' ma wgląd (r-x), pozostali nie mają dostępu (---)
Prawa plików 0640 (-rw-r-----): Zapewniają możliwość odczytu przez narzędzia audytorskie bez ryzyka przypadkowej modyfikacji zawartości
Grupa administracyjna adm: Zamiast logować się na konto roota, administratorów dodaje się do grupy systemowej: usermod -aG adm audytor
Atrybut niezmienności (append-only): W skrajnie restrykcyjnych systemach pliki można zabezpieczyć atrybutem chattr +a (dozwolone tylko dopisywanie)

Zarządzanie kontami audytorów: Nadanie użytkownikowi uprawnienia do grupy adm pozwala mu na przeglądanie logów poleceniami less, grep i zgrep, chroniąc jednocześnie system przed przypadkowym skasowaniem plików.

Konfiguracja konta audytora i weryfikacja praw dostępu

root@nms-syslog:~# usermod -aG adm inzynier_sieci root@nms-syslog:~# id inzynier_sieci uid=1001(inzynier_sieci) gid=1001(inzynier_sieci) groups=1001(inzynier_sieci),4(adm) root@nms-syslog:~# su - inzynier_sieci -c "head -n 2 /var/log/remote/192.168.1.1/critical.log" 2026-09-29T20:10:00+02:00 MikroTik-GW interface,info: sfp-sfpplus1 link down # Odczyt powiódł się bez uprawnień konta root!

Cel slajdu: Zabezpieczenie serwera przed wyczerpaniem dysku za pomocą cyklicznej rotacji, kompresji gzip i retencji.

Integracja, bezpieczeństwo i utrzymanie

Serwer rsyslog w sieci korporacyjnej rejestruje od kilkuset megabajtów do kilkunastu gigabajtów danych dziennie. Bez automatycznej rotacji partycja dyskowa uległaby zapełnieniu w ciągu kilku tygodni. Narzędzie logrotate zarządza cyklem życia plików dziennika.

Maska wieloznaczna /var/log/remote/*/*.log: Obejmuje automatycznie wszystkie podfoldery utworzone dynamicznie przez dynaFile dla każdego hosta
Dyrektywy compress i delaycompress: Kompresuje archiwa algorytmem gzip (oszczędność do 90% dysku). delaycompress chroni procesy przed zablokowaniem
Parametr rotate 90: Utrzymuje historię zdarzeń z 90 ostatnich dni, automatycznie usuwając najstarsze archiwa
Blok postrotate (rsyslog-rotate): Wysyła sygnał SIGHUP do rsyslogd, nakazując ponowne otwarcie uchwytów plików po rotacji

Testowanie reguł w trybie symulacji (-d): Przed wdrożeniem nowego pliku rotacji zawsze przetestuj go w trybie debugowania: logrotate -d /etc/logrotate.d/remote-syslog. W tym trybie logrotate wypisuje na ekran dokładnie to, co zamierza zrobić, nie modyfikując żadnego pliku na dysku!

Tworzenie pliku rotacji i test próbny w trybie symulacji

root@nms-syslog:~# cat << 'EOF' > /etc/logrotate.d/remote-syslog /var/log/remote/*/*.log { daily rotate 90 compress delaycompress missingok notifempty sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate endscript } EOF root@nms-syslog:~# logrotate -d /etc/logrotate.d/remote-syslog reading config file /etc/logrotate.d/remote-syslog considering log /var/log/remote/192.168.1.1/all.log -> log does not need rotating [SUCCESS]

Cel slajdu: Rozwiązywanie problemów z odmową dostępu mechanizmów kontroli dostępu Mandatory Access Control.

Integracja, bezpieczeństwo i utrzymanie

Gdy magazyn logów zostanie przeniesiony na zewnętrzny punkt montowania (np. /data/log/ lub /mnt/storage/remote/), rsyslog pomimo posiadania praw konta root/syslog może zgłaszać błędy 'Permission Denied'. Przyczyną są mechanizmy kontroli wymuszonej (MAC) – SELinux oraz AppArmor.

Zasada działania SELinux: Proces rsyslogd działa w domenie syslogd_t i ma prawo zapisu wyłącznie do plików z kontekstem var_log_t
Polecenie semanage fcontext: semanage fcontext -a -t var_log_t "/data/log(/.*)?" trwale rejestruje kontekst w polityce jądra
Polecenie restorecon -Rv: Aplikuje zdefiniowane etykiety bezpieczeństwa do istniejących plików i katalogów
Profile AppArmor (Debian/Ubuntu): Jeśli katalog wykracza poza standardowe /var/log/, należy dodać regułę do /etc/apparmor.d/local/usr.sbin.rsyslogd

Nigdy nie wyłączaj SELinux (setenforce 0): Wyłączenie SELinux w środowisku produkcyjnym to rażące naruszenie zasad bezpieczeństwa. Prawidłowym podejściem inżynierskim jest nadanie właściwych etykiet kontekstu za pomocą semanage i restorecon.

Diagnoza i naprawa kontekstów SELinux dla magazynu zdalnego

root@nms-rhel:~# ls -dZ /var/log/remote unconfined_u:object_r:default_t:s0 /var/log/remote # Błędny kontekst default_t! root@nms-rhel:~# semanage fcontext -a -t var_log_t "/var/log/remote(/.*)?" root@nms-rhel:~# restorecon -Rv /var/log/remote Relabeled /var/log/remote from default_t to var_log_t. root@nms-rhel:~# ls -dZ /var/log/remote system_u:object_r:var_log_t:s0 /var/log/remote # Prawidłowy kontekst var_log_t!

Cel slajdu: Wdrożenie kryptograficznej ochrony strumienia logów przesyłanych przez niezaufane sieci publiczne.

Integracja, bezpieczeństwo i utrzymanie

Gdy stacje robocze lub serwery oddziałowe przesyłają logi przez publiczny Internet bez tunelu VPN, nieszyfrowany protokół TCP/UDP naraża organizację na podsłuch haseł, danych osobowych oraz modyfikację rekordów w ataku Man-in-the-Middle. Standard RFC 5425 definiuje bezpieczny transport TLS na porcie 6514.

Sterownik rsyslog-gnutls: Dostarcza moduł biblioteki GnuTLS dla procesora sieciowego rsyslog
Certyfikacja x509: Lokalny urząd certyfikacji (Internal CA) podpisuje certyfikaty serwera i klientów
Parametr StreamDriver.Mode="1": Wymusza szyfrowanie sesji TLS. Połączenia czystym tekstem są natychmiast odrzucane
Uwierzytelnianie x509/name: Klient weryfikuje czy nazwa CN certyfikatu serwera zgadza się z oczekiwanym adresem

Uprawnienia do kluczy prywatnych: Pliki kluczy prywatnych (np. server.key) muszą mieć bezwzględnie ograniczone uprawnienia: chmod 600 /etc/rsyslog.d/keys/*.key && chown syslog:adm /etc/rsyslog.d/keys/*.key.

Konfiguracja klienta Linux przesyłającego logi przez TLS 6514

root@PC-01:~# apt install -y rsyslog-gnutls root@PC-01:~# cat << 'EOF' > /etc/rsyslog.d/99-tls-forward.conf global(DefaultNetstreamDriver="gtls" DefaultNetstreamDriverCAFile="/etc/rsyslog.d/keys/ca.crt" DefaultNetstreamDriverCertFile="/etc/rsyslog.d/keys/pc01.crt" DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/keys/pc01.key") action(type="omfwd" target="syslog.firma.pl" port="6514" protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name") EOF

Cel slajdu: Rozwiązanie braku natywnego TLS w RouterOS za pomocą nowoczesnego tunelowania VPN.

Integracja, bezpieczeństwo i utrzymanie

MikroTik RouterOS nie implementuje standardu RFC 5425 (TLS Syslog), a wysyłanie nieszyfrowanych pakietów UDP 514 przez publiczny Internet narusza podstawowe zasady cyberbezpieczeństwa. Standardem inżynierskim jest tunelowanie ruchu telemetrycznego przez WireGuard lub IPsec.

Architektura Overlay VPN: Zestawienie lekkiego, szyfrowanego tunelu WireGuard pomiędzy routerem a serwerem rsyslog
Prywatna podsieć tunelowa: Przydział dedykowanej puli adresowej punkt-punkt (np. 10.255.0.0/30) dla ruchu telemetrycznego
Parametry akcji remote: Ustawienie target=10.255.0.1 oraz src-address=10.255.0.2 kieruje cały ruch UDP 514 do wnętrza tunelu
Wydajność kryptograficzna: Szyfr ChaCha20-Poly1305 w WireGuard jest akcelerowany sprzętowo i nie obciąża procesora routera

Zaleta WireGuard w RouterOS v7: WireGuard jest natywnie wbudowany w jądro RouterOS v7. W przeciwieństwie do OpenVPN nie wymaga skomplikowanego handshake'u TCP ani certyfikatów – konfiguracja opiera się na statycznych kluczach publicznych Curve25519.

Weryfikacja tunelu WireGuard na serwerze Linux

root@nms-syslog:~# wg show wg0 interface: wg0 public key: 8vBqF1K...= listening port: 51820 peer: WzK9... (MikroTik-CCR2004) endpoint: 198.51.100.24:13231 allowed ips: 10.255.0.2/32 latest handshake: 14 seconds ago # Tunel aktywny! transfer: 4.21 MiB received, 112 KiB sent

Cel slajdu: Opanowanie szybkich potoków powłoki Bash do wyciągania informacji telemetrycznych i wykrywania incydentów.

Integracja, bezpieczeństwo i utrzymanie

Prawdziwą siłą systemu Linux jest możliwość błyskawicznej analizy milionów wierszy logów za pomocą standardowych narzędzi potokowych (grep, zgrep, awk, sed, sort, uniq). Inżynier NMS potrafi w kilka sekund ustalić źródło anomalii bez uruchamiania ciężkich interfejsów graficznych.

Narzędzie zgrep: Wyszukuje wzorce bezpośrednio w plikach skompresowanych algorytmem gzip (.gz) bez ich wcześniejszego rozpakowywania na dysk
Potok awk '{print $field}': Wyciąga konkretne kolumny tekstu (np. adres IP, protokół, nazwę użytkownika)
Kombinacja sort | uniq -c: Zlicza wystąpienia unikalnych wartości, tworząc natychmiastowe zestawienia statystyczne
Flaga grep -oE: Wyciąga wyłącznie dopasowaną część wyrażenia regularnego (Regex), eliminując zbędny tekst nagłówka

Wyszukiwanie incydentów z określonego przedziału godzinowego: Polecenie awk '$1 >= "2026-09-29T14:00:00" && $1 <= "2026-09-29T15:00:00"' /var/log/remote/192.168.1.1/all.log filtruje zdarzenia z dokładnością do godziny na podstawie znacznika czasu ISO 8601.

Szybki potok Bash analizujący próby ataków na routerze MikroTik

root@nms-syslog:~# zgrep "DROP_MANAGEMENT_ATTEMPT" /var/log/remote/192.168.1.1/*.log* | grep -oE "[0-9]{1,3}(\.[0-9]{1,3}){3}:[0-9]+->" | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 3 1420 198.51.100.88 892 203.0.113.14 314 192.0.2.77 Wykryto 3 główne źródła ataków. Gotowe do przekazania do Fail2ban!

Cel slajdu: Połączenie centralnego serwera rsyslog z platformą monitorowania LibreNMS i korelacja zdarzeń z metrykami SNMP.

Integracja, bezpieczeństwo i utrzymanie

Pliki tekstowe na dysku są idealne do archiwizacji i audytu, lecz operatorzy centrum monitorowania NOC potrzebują interaktywnego pulpitu WWW z wykresami i automatycznymi powiadomieniami. Rsyslog potrafi zduplikować napływający strumień i przekazać go do LibreNMS.

Równoległa akcja omfwd: Wewnątrz tego samego bloku ruleset rsyslog wykonuje zapis dynaFile na dysk oraz przekazuje pakiet na port 5140 kontenera LibreNMS
Tabela syslog w MariaDB: LibreNMS parsuje komunikaty i indeksuje je w bazie danych, wiążąc rekord z urządzeniem po adresie IP
Korelacja z SNMP: Gdy wykres ruchu interfejsu spada do zera, w zakładce Syslog natychmiast widoczny jest powiązany komunikat 'link down'
Silnik reguł alertacyjnych: Możliwość zdefiniowania reguły: wyślij powiadomienie na Slack/E-mail, jeśli w logu pojawi się fraza 'DROP_WAN_INPUT'

Dlaczego nie podłączać urządzeń bezpośrednio do LibreNMS? Rsyslog posiada zoptymalizowany, wielowątkowy silnik w języku C z buforami dyskowymi. Bezpośrednie skierowanie tysięcy pakietów UDP do interpretera PHP w LibreNMS doprowadziłoby do utraty logów przy zatorach. Rsyslog pełni rolę bufora ochronnego.

Konfiguracja rsyslog duplikująca strumień do kontenera LibreNMS

# W pliku /etc/rsyslog.d/20-remote-hosts.conf wewnątrz ruleset: ruleset(name="remote_network") { # 1. Trwały zapis na dysk SSD serwera action(type="omfile" dynaFile="RemotePerHost") # 2. Przekazanie kopii do lokalnego kontenera LibreNMS na porcie 5140 action(type="omfwd" target="127.0.0.1" port="5140" protocol="udp") stop }

Cel slajdu: Budowa pętli aktywnej odpowiedzi na incydenty: automatyczne blokowanie atakujących na routerze MikroTik przez Fail2ban.

Integracja, bezpieczeństwo i utrzymanie

Pasywne logowanie zdarzeń to dopiero połowa sukcesu. Prawdziwą przewagę osiągamy, gdy serwer rsyslog staje się mózgiem systemu aktywnej obrony. Narzędzie Fail2ban na serwerze Linux może na bieżąco analizować plik logów routera i po wykryciu ataku dynamicznie zablokować IP intruza na MikroTiku.

Analiza strumienia logpath: Fail2ban śledzi plik /var/log/remote/192.168.1.1/all.log za pomocą mechanizmu inotify
Wyrażenie regularne failregex: Wzorzec wychwytuje próby ataku: login failure for user .* from <HOST>
Akcja blokady (action): Skrypt na serwerze Linux łączy się przez RouterOS REST API lub SSH i dodaje adres do tablicy /ip firewall address-list
Automatyczny timeout: Wpis w Address-List otrzymuje parametr timeout=24h, po czym zostaje automatycznie wykasowany bez udziału człowieka

Sprzętowa reguła zapory w RouterOS: Aby zablokować adresy z listy, w MikroTiku dodajemy na samej górze regułę zapory: /ip firewall filter add chain=input src-address-list=black_list action=drop comment="Fail2ban Auto-Block".

Weryfikacja aktywnego zablokowania adresu IP intruza na routerze

root@nms-syslog:~# fail2ban-client status mikrotik-ssh Status for the jail: mikrotik-ssh |- Filter | |- Currently failed: 0 | `- Total failed: 6 `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: 203.0.113.88 # Adres został automatycznie zablokowany! [admin@MikroTik-GW] > /ip firewall address-list print # LIST ADDRESS TIMEOUT 0 black_list 203.0.113.88 23h59m48s

Cel slajdu: Finalne zestawienie procedur weryfikacyjnych i macierz odbiorcza gotowości produkcyjnej systemu telemetrii.

Podsumowanie warsztatu inżynierskiego

Gratulacje! Przeszedłeś przez wszystkie etapy budowy profesjonalnego, scentralizowanego systemu logowania. Aby upewnić się, że żadna krytyczna dyrektywa nie została pominięta, przed przekazaniem systemu do eksploatacji produkcyjnej zweryfikuj kompletną listę kontrolną (Deployment Checklist).

Rdzeń serwera: Potwierdź czystość składni rsyslogd -N1, aktywne gniazda UDP/TCP 514 oraz dedykowany potok ruleset ze słowem kluczowym stop
Magazyn dynaFile: Sprawdź czy katalog /var/log/remote/ posiada prawa 0750, a podkatalogi per host tworzą się automatycznie
Stacje robocze Linux: Zweryfikuj obecność kolejki LinkedList na wypadek awarii sieci oraz integrację z systemd-journald
Routery MikroTik: Upewnij się, że opcja bsd-syslog jest wyłączona (bsd-syslog=no) oraz że reguły zapory posiadają jednoznaczne prefiksy log-prefix

Pieczęć gotowości produkcyjnej: System spełnia rygorystyczne normy bezpieczeństwa teleinformatycznego (ISO 27001, PCI-DSS, KRI). Zdarzenia są rejestrowane asynchronicznie, segregowane dynamicznie na poziomie systemu plików i zabezpieczone przed utratą w razie awarii.

Automatyczny audyt gotowości produkcyjnej na serwerze Linux

root@nms-syslog:~# ./verify-syslog-stack.sh [*] Sprawdzanie procesu rsyslog... [PASS] [*] Sprawdzanie nasłuchu gniazd UDP/TCP 514... [PASS] [*] Walidacja składni rsyslogd -N1... [PASS] [*] Uprawnienia katalogu /var/log/remote (0750)...[PASS] [*] Konfiguracja rotacji logrotate... [PASS] [*] Odbiór pakietów z routera MikroTik... [PASS] [*] Odbiór pakietów ze stacji roboczych Linux... [PASS] ================================================================ STATUS: System zdalnego logowania w 100% gotowy do eksploatacji!