Strona główna 1: Wprowadzenie 2: Protokół SNMP 3: SNMP w praktyce 4: Systemy NMS 5: Kontenery i wdrożenie 6: Logowanie i bezpieczeństwo
Slajd 1/55
Logowanie zdarzeń i bezpieczeństwo sieci
Cel slajdu: Przedstawienie standardów, architektury i narzędzi centralnego gromadzenia logów systemowych oraz uwarunkowań prawno-audytowych w infrastrukturze teleinformatycznej.

Strona tytułowa i wprowadzenie do modułu

Dzienniki zdarzeń (logi) stanowią fundamentalne źródło wiedzy o incydentach bezpieczeństwa, błędach konfiguracyjnych i stanie operacyjnym urządzeń sieciowych.

  • Standardy protokołu Syslog: Ewolucja od nieformalnego formatu BSD (RFC 3164) do sformalizowanego standardu IETF (RFC 5424) z precyzyjnym czasem UTC
  • Silnik rsyslog i architektura centralna: Wdrożenie wydajnego serwera zbierania logów z buforowaniem dyskowym, dynamicznymi ścieżkami oraz szyfrowaniem TLS
  • Zaawansowana analityka i korelacja w SIEM: Integracja logów z platformami SIEM/XDR (Wazuh, Graylog, ELK) w celu natychmiastowej detekcji ataków
  • Zgodność z przepisami prawa i normami: Wymagania regulacyjne: RODO, dyrektywa NIS 2, Prawo komunikacji elektronicznej 2024 oraz norma ISO/IEC 27001:2022
Log zdarzeń (Audit Trail): Chronologiczny, integralny zapis aktywności systemu operacyjnego lub urządzenia sieciowego, zawierający znacznik czasu, identyfikator źródła, wagę zdarzenia oraz opis zaistniałego faktu operacyjnego lub incydentu bezpieczeństwa.
Wprowadzenie do logowania zdarzeń Logowanie zdarzeń i bezpieczeństwo sieci teleinformatycznych Standardy Syslog • IETF RFC 5424 / 3164 • Poziomy Severity (0-7) • Źródła Facility (0-23) Kalkulacja PRI Silnik rsyslog & Bezpieczeństwo • Składnia RainerScript • Dynamiczne DynaFiles • Szyfrowanie TLS (RFC 5425) Protokół RELP Audyt & Compliance • Platformy SIEM (Wazuh) • Norma ISO/IEC 27001 • RODO / Dyrektywa NIS 2 Prawo telekomunikacyjne Zakres tematyczny modułu: Architektura telemetryczna, centralizacja logów sieciowych, korelacja incydentów oraz dowodowość prawna.
Slajd 2/55
Spis treści prezentacji 6
Cel slajdu: Przedstawienie struktury modułu dydaktycznego obejmującego standardy Syslog, konfigurację infrastruktury, systemy klasy SIEM, aspekty formalno-prawne oraz ćwiczenia laboratoryjne.

Strona tytułowa i wprowadzenie do modułu

Materiał prezentacji został podzielony na trzy logiczne segmenty prowadzące od fundamentów protokołu po zaawansowaną analizę śledczą i compliance.

  • Część 1: Standardy protokołu Syslog i silnik rsyslog: Geneza standardu, nagłówek RFC 5424, poziomy ważności PRI, konfiguracja rsyslog, kolejkowanie i szyfrowanie TLS
  • Część 2: Konfiguracja urządzeń sieciowych i platform analitycznych: Generowanie logów w RouterOS i Cisco IOS, integracja z NMS, Graylog, rotacja logrotate oraz wektory zagrożeń
  • Część 3: Systemy SIEM, compliance i laboratoria: Wdrożenie Wazuh, zgodność z ISO 27001, RODO, NIS 2, Prawo komunikacji elektronicznej 2024 oraz 6 ćwiczeń praktycznych
Metodyka nauczania: Prezentacja łączy wiedzę teoretyczną i standaryzacyjną z bezpośrednimi przykładami konfiguracji wiersza poleceń oraz scenariuszami laboratoryjnymi do samodzielnego wykonania.
Spis treści modułu 6 Spis treści prezentacji 6: Logowanie i bezpieczeństwo Część 1: Standard Syslog i rsyslog (1-18) • Cztery cele logowania i ewolucja standardów • Format nagłówka RFC 5424, poziomy PRI • Silnik rsyslog: moduły, RainerScript, filtry • Kolejki buforowe, szyfrowanie TLS i RELP Część 2: Urządzenia i analityka (19-36) • Logowanie w MikroTik RouterOS i Cisco IOS • Integracja z systemd-journald i LibreNMS • Platformy Graylog i stos Elastic / OpenSearch • Rotacja logrotate, polityka retencji, ataki Część 3: SIEM, regulacje prawne i laboratoria (37-55) • Systemy SIEM: architektura Wazuh XDR • Reagowanie na incydenty wg NIST SP 800-61 • Zgodność: ISO 27001:2022 (A.8.15/16), RODO • NIS 2, Prawo komunikacji elektronicznej 2024 • Lab 1: Centralny serwer rsyslog na Linux • Lab 2: Konfiguracja zdalna w RouterOS • Lab 3-6: Analiza bash, TLS, LibreNMS, Wazuh • Słownik pojęć, pytania kontrolne i bibliografia
Slajd 3/55
Cztery cele logowania zdarzeń w sieciach LAN
Cel slajdu: Przedstawienie czterech filarów uzasadniających gromadzenie i analizę logów: diagnostyki technicznej, informatyki śledczej, rozliczalności personelu oraz zgodności prawnej.

Standardy protokołu Syslog i silnik rsyslog

Logowanie zdarzeń nie jest wyłącznie czynnością techniczną – pełni kluczową rolę w zapewnieniu ciągłości działania, bezpieczeństwa i legalności operacji teleinformatycznych.

  • Diagnostyka operacyjna (Troubleshooting): Bieżąca identyfikacja przyczyn awarii sprzętowych, przerw w transmisji, flappingu interfejsów oraz błędów tablic routingu
  • Informatyka śledcza (Digital Forensics): Niezbędny materiał dowodowy pozwalający odtworzyć kroki intruza (włamanie, eskalacja uprawnień, eksfiltracja danych) po wystąpieniu incydentu
  • Rozliczalność i niezaprzeczalność (Non-Repudiation): Możliwość jednoznacznego powiązania każdej modyfikacji konfiguracji sieciowej z konkretnym kontem użytkownika i znacznikiem czasu
  • Zgodność z przepisami prawa (Compliance): Realizacja formalnych wymogów prawnych narzucanych przez normy branżowe (ISO 27001), prawo unijne (RODO, NIS 2) oraz krajowe
Niezaprzeczalność (Non-Repudiation): Właściwość systemu teleinformatycznego zapewniająca, że podmiot wykonujący określoną akcję nie może zaprzeczyć jej dokonaniu, dzięki obecności niezmiennych i zabezpieczonych kryptograficznie wpisów w logach audytowych.
Cele logowania zdarzeń Cztery fundamentalne cele logowania zdarzeń w infrastrukturze 1. Diagnostyka operacyjna (Troubleshooting) • Lokalizacja źródła awarii sprzętu i łączy • Monitorowanie stanu protokołów STP/BGP • Identyfikacja błędów składni konfiguracji Cel: Skrócenie czasu MTTR awarii sieci 2. Informatyka śledcza (Digital Forensics) • Odtwarzanie chronologii włamania do sieci • Identyfikacja punktu wejścia (Initial Access) • Analiza ruchu bocznego (Lateral Movement) Cel: Identyfikacja wektora ataku i sprawcy 3. Rozliczalność i niezaprzeczalność • Rejestracja logowań administratorów (AAA) • Ewidencja zmian konfiguracji switchy/routerów • Dowód braku ingerencji w procesy biznesowe Cel: Zasada Non-Repudiation (niezaprzeczalność) 4. Zgodność z regulacjami (Compliance) • Norma ISO/IEC 27001:2022 (A.8.15) • Rozporządzenie RODO (art. 32 bezp. danych) • Dyrektywa NIS 2 i ustawa o KSC Cel: Uniknięcie sankcji prawnych i utraty licencji
Slajd 4/55
Historia i ewolucja protokołu Syslog
Cel slajdu: Przedstawienie genezy i drogi standaryzacji protokołu Syslog od lat 80. XX wieku po współczesny standard IETF RFC 5424.

Standardy protokołu Syslog i silnik rsyslog

Protokół Syslog przez ponad dwie dekady funkcjonował bez formalnego standardu jako rozwiązanie tworzone doraźnie na potrzeby systemu pocztowego BSD.

  • Narodziny w projekcie Sendmail (1980 r.): Stworzony przez Erica Allmana jako mechanizm logowania błędów serwera pocztowego w systemie 4.3BSD Unix
  • Dokument informacyjny RFC 3164 (2001 r.): Pierwsza próba spisania istniejących praktyk (tzw. BSD Syslog); brak rygoru składniowego i poważne ograniczenia formatu daty
  • Oficjalny standard IETF RFC 5424 (2009 r.): Formalny standard definiujący ścisłą gramatykę ABNF nagłówka, precyzyjny czas ISO 8601, kodowanie UTF-8 oraz dane strukturalne
  • Rozszerzenia transportowe: Późniejsze standardy transportowe: RFC 5425 (szyfrowanie TLS), RFC 5426 (UDP) oraz RFC 5427 (SNMP MIB dla Syslog)
Wada formatu daty RFC 3164: Format BSD zapisywał datę jako Mmm dd hh:mm:ss (np. Oct 11 22:14:15). Brak informacji o roku oraz strefie czasowej uniemożliwiał precyzyjną korelację logów z serwerów znajdujących się w różnych strefach geograficznych po zmianie czasu letniego/zimowego!
Ewolucja protokołu Syslog Ewolucja standardów: BSD Syslog (1980) do IETF Syslog (2009) 1980: BSD Sendmail Geneza powstania: • Autor: Eric Allman • Komponent projektu Sendmail • System 4.3BSD Unix Charakterystyka: • Brak formalnego RFC • Port UDP 514 • Nieustandaryzowany format • Różnice dialektów producentów 2001: IETF RFC 3164 Status: Informational • Tzw. "BSD Syslog" • Opis stanu zastanego de facto • Maks. rozmiar: 1024 bajty Ograniczenia: • Brak roku w dacie (Mmm dd) • Brak strefy czasowej • Tylko kodowanie ASCII • Brak ustrukturyzowanych pól 2009: IETF RFC 5424 Status: Proposed Standard • Oficjalny standard IETF • Zastępuje RFC 3164 • Brak sztywnego limitu 1024 B Nowości standardu: • Czas ISO 8601 (rok + mikrosek) • Jawny offset UTC (+02:00) • Kodowanie UTF-8 (BOM) • STRUCTURED-DATA (SD-ELEMENT)
Slajd 5/55
Architektura protokołu Syslog
Cel slajdu: Przedstawienie ról węzłów w topologii zbierania logów: nadawców (Originators), przekaźników (Relays) oraz centralnych odbiorników (Collectors).

Standardy protokołu Syslog i silnik rsyslog

Standard RFC 5424 formalnie definiuje relacje pomiędzy komponentami uczestniczącymi w generowaniu, tranzycie i składowaniu komunikatów.

  • Originator (Nadawca/Źródło): Proces systemowy lub urządzenie sprzętowe (przełącznik, router, demon jądra) generujące komunikat o zdarzeniu
  • Relay (Przekaźnik/Koncentrator): Węzeł pośredniczący: odbiera logi z podsieci lokalnej, filtruje je, buforuje na dysku i przesyła dalej w szyfrowanym kanale WAN
  • Collector (Odbiornik/Serwer): Punkt końcowy tranzytu: odpowiada za trwałą archiwizację, indeksowanie w bazach danych lub przekazanie do silnika SIEM
  • Porty i protokoły transportowe: Domyślny transport bezpołączeniowy UDP port 514, transport połączeniowy TCP port 514 oraz szyfrowany port TCP 6514 (TLS)
Rola węzła Relay w sieciach rozproszonych: W oddziałach firmy przekaźnik logów (Relay) przyjmuje pakiety UDP 514 z urządzeń sieciowych, które nie obsługują szyfrowania TLS, buforuje je w lokalnej kolejce RAM/dysk i bezpiecznie przesyła tunelem TLS do centralnego Data Center.
Architektura protokołu Syslog Trójwarstwowa architektura ról protokołu Syslog (RFC 5424) 1. Originator (Nadawca) Przełącznik Cisco Port flapping, logowania Router MikroTik Zapora ogniowa, DHCP Serwer Linux sshd, kernel, sudo Generuje komunikaty UDP 514 2. Relay (Przekaźnik) Lokalny koncentrator • Agregacja z segmentu LAN • Buforowanie dyskowe • Filtracja szumu (Debug) Konwersja transportu • Wejście: UDP 514 • Wyjście: TLS 6514 / RELP • Wzbogacenie metadanych Przekazuje dalej TLS 6514 3. Collector (Odbiornik) Serwer rsyslog / DB Zapis do plików / MariaDB System SIEM (Wazuh) Korelacja regułowa i alerty Archiwum WORM Niezmienna retencja prawna Przechowuje i analizuje
Slajd 6/55
Format komunikatu Syslog (RFC 5424)
Cel slajdu: Szczegółowa analiza składni nagłówka, pól danych ustrukturyzowanych (STRUCTURED-DATA) oraz kodowania treści w standardzie RFC 5424.

Standardy protokołu Syslog i silnik rsyslog

Standard RFC 5424 wyeliminował niejednoznaczność parsowania logów, wprowadzając rygorystyczny format pól rozdzielanych pojedynczymi spacjami.

  • PRI i VERSION: Priorytet ujęty w nawiasy ostre `<PRI>` oraz bezpośrednio po nim numer wersji formatu (obecnie zawsze `1`)
  • Precyzyjny TIMESTAMP: Czas w standardzie ISO 8601 zawierający pełny rok, miesiąc, dzień, czas z mikrosekundami oraz strefę czasową
  • Identyfikatory HOSTNAME, APP-NAME, PROCID i MSGID: Jawne rozdzielenie nazwy hosta, nazwy procesu, identyfikatora PID oraz typu wiadomości MSGID
  • Dane strukturalne (STRUCTURED-DATA): Pary klucz-wartość ujęte w nawiasy kwadratowe, umożliwiające automatyczne parsowanie bez konieczności pisania wyrażeń regularnych Regex
NILVALUE w RFC 5424: Jeśli dane pole nagłówka lub sekcja STRUCTURED-DATA nie posiada wartości, w jego miejscu wstawia się pojedynczy znak myślnika -. Zapobiega to przesunięciu indeksu kolumn podczas parsowania strumienia.
Format komunikatu RFC 5424 Struktura komunikatu według standardu IETF RFC 5424 Pola nagłówka HEADER (rozdzielane pojedynczą spacją ASCII) <PRI> <165> VER 1 TIMESTAMP (ISO 8601) 2026-09-29T22:15:00.123+02:00 HOSTNAME sw-core01 APP-NAME sshd PROCID 1420 MSGID AUTH01 Znak "-" w dowolnym polu oznacza jawną wartość NILVALUE (brak określonej wartości). STRUCTURED-DATA oraz MSG (Tekst komunikatu w UTF-8) [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] ↑ STRUCTURED-DATA: Klucz-wartość w nawiasach kwadratowych z prywatnym ID korporacyjnym IANA BOM Nieudane logowanie administratora z adresu IP 192.168.1.50 port 54122 ↑ MSG: Opcjonalny znacznik UTF-8 BOM (%xEF.BB.BF) oraz właściwa treść tekstowa komunikatu
Slajd 7/55
Poziomy dotkliwości (Severity Levels: 0–7)
Cel slajdu: Przedstawienie znormalizowanej 8-stopniowej skali wag zdarzeń (Severity), kryteriów kategoryzacji incydentów oraz ich wpływu na procedury alarmowania.

Standardy protokołu Syslog i silnik rsyslog

Standard Syslog definiuje dokładnie osiem poziomów ważności, gdzie najniższa wartość liczbowa oznacza zdarzenie o najwyższej krytyczności.

  • Poziomy krytyczne (0–2): Emergency (0), Alert (1) i Critical (2) – natychmiastowe zagrożenie dla działania infrastruktury wymagające natychmiastowej interwencji dyżurnego inżyniera NOC
  • Poziomy ostrzegawcze i błędów (3–4): Error (3) oraz Warning (4) – awarie pojedynczych komponentów lub przekroczenia progów ostrzegawczych (np. utrata redundancji zasilacza)
  • Poziomy operacyjne (5–6): Notice (5) oraz Informational (6) – rutynowe zdarzenia rejestrujące prawidłowe zmiany stanu urządzeń (np. zmiana topologii STP, logowanie administratora)
  • Poziom diagnostyczny (7): Debug (7) – generuje ogromny wolumen danych diagnostycznych; włączany tymczasowo wyłącznie podczas poszukiwania trudnych anomalii
Zagrożenie zalewem logów (Log Flooding): Włączenie poziomu Debug (7) na produkcyjnym przełączniku rdzeniowym może wygenerować dziesiątki tysięcy pakietów na sekundę, doprowadzając do 100% utylizacji procesora (Control Plane) i zablokowania procesów routingu!
Poziomy Severity (0-7) 8 poziomów ważności zdarzeń Syslog: Severity Levels (0–7) Kod Nazwa Severity Semantyka i kryteria zdarzenia Przykładowy incydent 0 Emergency (emerg) System całkowicie niezdatny do użytku Kernel panic, awaria zasilania 1 Alert (alert) Wymagana natychmiastowa akcja człowieka Uszkodzenie macierzy RAID 2 Critical (crit) Stan krytyczny komponentu sprzętowego Przegrzanie procesora routera 3 Error (err) Błąd wykonania operacji systemowej Zerwanie sesji BGP z operatorem 4 Warning (warning) Ostrzeżenie o potencjalnym problemie Wysycenie łącza >85%, błędy CRC 5 Notice (notice) Normalne, ale znaczące zdarzenie w sieci Podniesienie portu (linkUp) 6 Informational (info) Standardowy komunikat operacyjny Poprawne logowanie użytkownika 7 Debug (debug) Szczegółowe komunikaty deweloperskie Zrzuty pakietów, handshake OSPF
Slajd 8/55
Kody źródeł (Facility Codes: 0–23)
Cel slajdu: Przedstawienie klasyfikacji źródeł zdarzeń (Facility), podziału na usługi systemowe Unix oraz dedykowane pule lokalne (local0–local7) stosowane w urządzeniach sieciowych.

Standardy protokołu Syslog i silnik rsyslog

Kod Facility określa podsystem generujący log. Umożliwia to routing komunikatów do różnych plików docelowych w zależności od typu urządzenia.

  • Źródła systemowe (0–15): Podsystemy systemu operacyjnego: `kern` (0), `daemon` (3), `cron` (9) oraz krytyczny podsystem bezpieczeństwa `authpriv` (10)
  • Pula użytkownika i sieci (16–23: local0–local7): Zarezerwowana specjalnie dla administratorów do kategoryzacji urządzeń infrastruktury sieciowej
  • Standard Cisco IOS (`local7`): Domyślnym kodem źródła dla urządzeń Cisco jest `local7` (23); przełączniki przesyłają logi z nagłówkiem Facility 23
  • Izolacja uprawnień pliku authpriv: Dzienniki z kodem `authpriv` zawierają wrażliwe próby uwierzytelnienia i posiadają restrykcyjne uprawnienia odczytu (chmod 600)
Dobra praktyka inżynierska: W korporacyjnych sieciach zaleca się standaryzację kodów localX, np.: local7 dla switchy szkieletowych, local6 dla brzegowych routerów BGP, local5 dla zapór ogniowych NGFW, a local4 dla kontrolerów Wi-Fi. Ułatwia to reguły routingu w rsyslog!
Kody Facility (0-23) Klasyfikacja źródeł komunikatów: Kody Facility (0–23) Podsystemy systemu operacyjnego (0–15) 0 kern Komunikaty jądra systemu Linux 1 user Zdarzenia na poziomie użytkownika 2 mail Podsystem poczty elektronicznej 3 daemon Ogólne demony systemowe 4 auth Uwierzytelnianie (starsze systemy) 9 cron Harmonogram zadań cyklicznych 10 authpriv Bezpieczeństwo i dostęp (sshd, sudo) 11 ftp Transfer plików demonów FTP authpriv: chroniony dostęp do logów haseł Źródła lokalne sieciowe (16–23) 16 local0 Domyślne dla części switchy i NMS 17 local1 Często przypisywane do MikroTik 18 local2 Serwery proxy / Reverse Proxy 19 local3 Serwery bazodanowe (MariaDB) 20 local4 Kontrolery sieci bezprzewodowej Wi-Fi 21 local5 Serwery VPN / Koncentratory IPsec 22 local6 Zapory sieciowe NGFW / UTM 23 local7 Domyślny standard Cisco IOS / Nexus local0-7: podstawa segmentacji logów sieci
Slajd 9/55
Kalkulacja wartości priorytetu (PRI)
Cel slajdu: Przedstawienie matematycznego algorytmu wyznaczania wartości pola PRI, kodowania bitowego oraz odwrotnego dekodowania wartości Facility i Severity.

Standardy protokołu Syslog i silnik rsyslog

Pole PRI łączy kod źródła (Facility) oraz wagę zdarzenia (Severity) w jedną liczbę całkowitą zawartą w nawiasach ostrych na początku pakietu.

  • Równanie kodowania wartości PRI: Wzór: `PRI = (Facility * 8) + Severity`. Wartość mieści się w przedziale od 0 (kern.emerg) do 191 (local7.debug)
  • Operacje bitowe w kodzie parsera: Mnożenie przez 8 odpowiada przesunięciu bitowemu o 3 pozycje w lewo (`Facility = PRI >> 3`)
  • Ekstrakcja wagi zdarzenia (Severity): Trzy najmłodsze bity reprezentują poziom ważności: operacja maskowania `Severity = PRI & 0x07` (lub `PRI % 8`)
  • Przykłady z rzeczywistej sieci: Komunikat `<188>` oznacza zdarzenie z routera Cisco (local7) o wadze Warning (4). Komunikat `<139>` to MikroTik (local1) z błędem Error (3)
Dekodowanie PRI w pcap: Gdy inżynier analizuje zrzut pakietów w Wiresharku i widzi nagłówek <165>: 165 / 8 = 20 (Facility 20 = local4, np. kontroler Wi-Fi), a reszta z dzielenia 165 % 8 = 5 (Severity 5 = Notice).
Kalkulacja priorytetu PRI Matematyka i operacje bitowe wartości priorytetu: Pole PRI Wzór formalny według specyfikacji IETF RFC 5424 PRI = (Facility * 8) + Severity Przykład 1: Przełącznik Cisco Catalyst • Źródło: local7 (Facility = 23) • Waga: Warning (Severity = 4) PRI = (23 * 8) + 4 = 188 Początek ramki w locie: <188>1 Przykład 2: Router MikroTik RouterOS • Źródło: local1 (Facility = 17) • Waga: Error (Severity = 3) PRI = (17 * 8) + 3 = 139 Początek ramki w locie: <139>1
Slajd 10/55
rsyslog – Zaawansowany demon logowania w Linuksie
Cel slajdu: Przedstawienie architektury demona rsyslog, modułowego podziału na moduły wejścia (im*), wyjścia (om*) oraz zaawansowanego języka konfiguracji RainerScript.

Standardy protokołu Syslog i silnik rsyslog

Demon rsyslog (Rocket-Fast System for Log Processing) jest domyślnym silnikiem logowania w większości dystrybucji Linuksa (Ubuntu, Debian, RHEL), zdolnym przetwarzać ponad milion zdarzeń na sekundę.

  • Modułowa architektura wejścia (`im*`): Dedykowane wtyczki: `imudp` (odbiór UDP), `imtcp` (odbiór TCP), `imuxsock` (gniazdo systemowe) oraz `imjournal`
  • Język konfiguracji RainerScript: Nowoczesny, strukturalny język zastępujący przestarzałą składnię sysklogd; pełne wsparcie dla bloków `if ... then { ... }`
  • Odporność na awarie dzięki kolejkom (Queuing): Wielopoziomowe kolejkowanie zdarzeń: kolejka główna w RAM ze wsparciem bufora dyskowego przy przestojach bazy danych
  • Elastyczne moduły wyjścia (`om*`): Zapis do tradycyjnych plików tekstowych (`omfile`), baz relacyjnych (`ommysql`), protokołu RELP (`omrelp`) oraz Kafki
RainerScript vs stara składnia: Starsza składnia z jednym plikiem (np. local7.* /var/log/cisco.log) nie pozwalała na zaawansowaną logikę warunkową. RainerScript wprowadził pełnoprawną strukturę obiektową ruleset(), input(), action() oraz zmienne systemowe.
Architektura silnika rsyslog Wielowątkowa architektura modułowa silnika rsyslog v8 Moduły wejścia (im*) imudp Port 514 UDP imtcp Port 514 TCP imuxsock Socket /dev/log imrelp Protokół RELP Rdzeń przetwarzania (RainerScript) Parsowanie i filtry regułowe Instrukcje warunkowe if/then/else, regex Kolejki buforowe (Queues) Pamięć RAM + Dysk (Disk-Assisted) Zero utraty pakietów przy awarii bazy Silnik szablonów (Templates) Formatowanie JSON, RFC 5424, CSV Moduły wyjścia (om*) omfile Zapis na dysk (DynaFile) omfwd Forwarding UDP/TCP ommysql Zapis do MariaDB omrelp Niezawodny RELP
Slajd 11/55
Podstawowa konfiguracja rsyslog (/etc/rsyslog.conf)
Cel slajdu: Przedstawienie anatomii pliku konfiguracyjnego rsyslog, dyrektyw globalnych, ładowania modułów wejściowych oraz reguł włączania podkatalogu /etc/rsyslog.d/.

Standardy protokołu Syslog i silnik rsyslog

Konfiguracja rsysloga w nowoczesnych dystrybucjach Linuksa opiera się na pliku głównym oraz modularnych plikach reguł w katalogu `/etc/rsyslog.d/`.

  • Ładowanie modułów za pomocą `module(load=...)`: Jawna deklaracja niezbędnych wtyczek: `imuxsock` dla systemu, `imklog` dla kernela oraz `imudp`/`imtcp` dla sieci
  • Katalog roboczy buforowania (`workDirectory`): Wskazanie bezpiecznej ścieżki `/var/spool/rsyslog` dla kolejek dyskowych (spooling)
  • Kontrola uprawnień POSIX (`$FileCreateMode`): Wymuszenie tworzenia plików logów z maską 0640 i właścicielem `syslog:adm`, zapobiegające nieautoryzowanemu odczytowi
  • Modułowa dyrektywa `include()`: Automatyczne ładowanie plików reguł z katalogu `/etc/rsyslog.d/` sortowanych alfabetycznie (np. `10-network.conf`)
Kolejność plików w /etc/rsyslog.d/: Pliki konfiguracyjne przetwarzane są w porządku leksykograficznym. Dlatego reguły sieciowe nazywa się np. 10-network.conf, aby zostały przetworzone przed domyślnym plikiem dystrybucyjnym 50-default.conf.
Konfiguracja rsyslog.conf Struktura pliku konfiguracyjnego /etc/rsyslog.conf # 1. Dyrektywy globalne i ładowanie modułów wejścia: module(load="imuxsock") # Obsługa lokalnego gniazda systemowego /dev/log module(load="imklog") # Odczyt komunikatów jądra Linux (klogd) module(load="imudp") # Moduł odbiornika UDP dla urządzeń sieciowych input(type="imudp" port="514") # 2. Globalne parametry uprawnień plików i katalogów: global(workDirectory="/var/spool/rsyslog") $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 # 3. Dołączanie dedykowanych plików konfiguracyjnych: include(file="/etc/rsyslog.d/*.conf" mode="optional") # Zalecenie: Konfiguracje sieciowe umieszczaj w plikach /etc/rsyslog.d/10-network.conf
Slajd 12/55
Selektory i akcje w konfiguracji rsyslog
Cel slajdu: Przedstawienie logiki selektorów, operatorów progowych Severity oraz akcji zapisu do plików i przekazywania logów przez sieć (omfwd).

Standardy protokołu Syslog i silnik rsyslog

Selektor określa, jakie komunikaty mają zostać przechwycone, a akcja definiuje, co silnik rsyslog ma z nimi zrobić (zapisać, przekazać, porzucić).

  • Domyślna semantyka 'od poziomu wzwyż': Zapis `mail.crit` przechwytuje poziom Critical oraz wszystkie ważniejsze: Alert i Emergency
  • Modyfikatory równości (`=`) i negacji (`!`): Operator `=debug` ogranicza przechwytywanie wyłącznie do poziomu Debug, a `!err` ignoruje błędy
  • Wyłączenie synchronicznego zapisu (`-`): Znak minus przed ścieżką pliku (np. `-/var/log/syslog`) zapobiega wymuszaniu operacji `fsync()` po każdym komunikacie
  • Przekazywanie sieciowe: `@` vs `@@`: Pojedynczy znak `@host` oznacza wysyłkę po protokole UDP, natomiast podwójny `@@host` wymusza połączenie TCP
Wpływ znaku minus na wydajność I/O: Brak znaku - przed ścieżką pliku wymusza zapis synchroniczny (fsync). Przy odebraniu 5000 pakietów/s z urządzeń sieciowych serwer zablokuje operacje dyskowe I/O, powodując gwałtowny wzrost obciążenia (Load Average)!
Selektory i akcje rsyslog Selektory, operatory ważności i akcje w rsyslog # 1. Klasyczna składnia selektorów: <facility>.<severity> <action> auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog # Znak "-" przed ścieżką wyłącza synchroniczny flush bufora dyskowego (optymalizacja I/O) # 2. Operatory poziomów dotkliwości (Severity Comparison): mail.crit /var/log/mail_critical.log # Wagi crit, alert, emerg (wzwyż!) kern.=debug /var/log/kernel_debug.log # Wyłącznie waga debug (operator =) daemon.!warn /var/log/daemon_low.log # Wagi poniżej warn (negacja !) # 3. Akcje przekierowania strumienia sieciowego (Forwarding): # Tradycyjny forward UDP (pojedyncza małpa @): *.* @10.99.0.10:514 # Niezawodny forward TCP (podwójna małpa @@): *.* @@10.99.0.10:514 # Zatrzymanie dalszego przetwarzania dopasowanego logu: stop (lub & ~ w starej składni)
Slajd 13/55
Konfiguracja rsyslog jako centralnego serwera logów
Cel slajdu: Przedstawienie procedury uruchomienia bezpiecznego serwera zbierania logów sieciowych z restrykcją adresu nasłuchiwania oraz regułami zapory ogniowej.

Standardy protokołu Syslog i silnik rsyslog

Przekształcenie zwykłego serwera Linux w centralny kolektor logów wymaga włączenia modułów sieciowych oraz ścisłego ograniczenia dostępu na zaporze sieciowej.

  • Selektywne wiązanie adresu IP (`address`): Powiązanie usługi nasłuchu z adresem w sieci zarządzającej `10.99.0.10` zamiast niebezpiecznego nasłuchiwania na `0.0.0.0`
  • Jednoczesna obsługa UDP i TCP: Uruchomienie portu UDP 514 dla starszych switchy oraz portu TCP 514 dla krytycznych routerów brzegowych
  • Przygotowanie przestrzeni dyskowej `/var/log/network/`: Utworzenie odizolowanego katalogu z odpowiednimi uprawnieniami grupy `adm`
  • Filtrowanie dostępowe na zaporze UFW/nftables: Bezwzględna blokada ruchu Syslog spoza autoryzowanej podsieci zarządzającej VLAN Management
Ryzyko otwartego portu UDP 514: Ponieważ protokół UDP nie weryfikuje adresu nadawcy (brak 3-way handshake), wystawienie portu 514 na publiczny Internet pozwala atakującym na wstrzykiwanie fałszywych logów (Syslog Spoofing) lub zalanie dysku serwera śmieciowymi danymi.
Centralny serwer rsyslog Konfiguracja centralnego kolektora Syslog i reguł Firewall # 1. Konfiguracja pliku /etc/rsyslog.d/00-remote-server.conf: module(load="imudp") input(type="imudp" port="514" address="10.99.0.10") # Nasłuch tylko na IP OOB/MGMT module(load="imtcp") input(type="imtcp" port="514" address="10.99.0.10") # 2. Utworzenie dedykowanego katalogu na logi urządzeń sieciowych: $ sudo mkdir -p /var/log/network $ sudo chown -R syslog:adm /var/log/network && sudo chmod 0750 /var/log/network # 3. Zabezpieczenie na zaporze Linux UFW / iptables (Restrykcja podsieci MGMT): $ sudo ufw allow from 10.99.0.0/24 to 10.99.0.10 port 514 proto udp comment "Syslog UDP" $ sudo ufw allow from 10.99.0.0/24 to 10.99.0.10 port 514 proto tcp comment "Syslog TCP" # 4. Weryfikacja aktywnego nasłuchu na gniazdach sieciowych: $ ss -tulpn | grep 514 udp UNCONN 0 0 10.99.0.10:514 users:(("rsyslogd",pid=1250,fd=5))
Slajd 14/55
Szablony (Templates) i dynamiczne ścieżki w rsyslog
Cel slajdu: Przedstawienie mechanizmu dynamicznych ścieżek plików (DynaFiles) oraz szablonów formatowania wiadomości w celu automatycznej segregacji logów sieciowych.

Standardy protokołu Syslog i silnik rsyslog

DynaFiles to jedna z najpotężniejszych funkcji rsysloga, umożliwiająca automatyczne tworzenie struktury katalogów na dysku na podstawie metadanych wiadomości.

  • Dynamiczne generowanie ścieżek (`dynaFile`): Automatyczne tworzenie podkatalogu dla każdego urządzenia (np. `/var/log/network/sw-core01/`) oraz podziału na dni kalendarzowe
  • Zmienne systemowe właściwości (Properties): Dostęp do właściwości pakietu: `%HOSTNAME%`, `%$YEAR%`, `%$MONTH%`, `%$DAY%`, `%fromhost-ip%`
  • Szablony listowe (List Templates): Precyzyjne budowanie formatu wyjściowego z wykorzystaniem stałych tekstowych i formatowania daty w standardzie RFC 3339
  • Izolacja strumieni w dedykowanych plikach: Zapewnienie porządku w logach: zdarzenia z routera brzegowego nie mieszają się z logami przełączników accessowych
DynaFile: Wzorzec ścieżki pliku zawierający makrozmienne. Gdy rsyslog odbiera log z nowego hosta, automatycznie tworzy wymagane katalogi i plik na dysku bez konieczności uprzedniej ręcznej konfiguracji przez administratora.
Szablony i dynamiczne ścieżki Dynamiczne szablony ścieżek (DynaFiles) i formatowania # 1. Definicja szablonu dynamicznej ścieżki pliku (DynaFile): template(name="NetworkDeviceLogs" type="string" string="/var/log/network/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log") # 2. Definicja formatu linii logu (JSON lub sformatowany tekst): template(name="StandardFormat" type="list") { property(name="timestamp" dateFormat="rfc3339") constant(value=" ") property(name="hostname") constant(value=" [") property(name="syslogseverity-text") constant(value="] ") property(name="msg" spifno1stsp="on") constant(value="\n") } # 3. Zastosowanie szablonu w regule akcji dla źródeł sieciowych: if ($facility-text startswith 'local') then { action(type="omfile" dynaFile="NetworkDeviceLogs" template="StandardFormat") stop }
Slajd 15/55
Zaawansowane filtrowanie logów w RainerScript
Cel slajdu: Przedstawienie instrukcji warunkowych języka RainerScript, operatorów logicznych, dopasowywania wzorców Regex oraz technik odsiewania szumu informacyjnego.

Standardy protokołu Syslog i silnik rsyslog

Nowoczesne środowiska NMS wymagają inteligentnego filtrowania zdarzeń w locie, aby odciążyć dyski serwera i wyeliminować powtarzalny szum operacyjny.

  • Operatory logiczne i relacyjne: Budowanie złożonych warunków: `and`, `or`, `not`, `==`, `!=`, `<`, `>`, `startswith`, `contains`
  • Wyrażenia regularne (`re_match`): Wyszukiwanie precyzyjnych wzorców awarii w treści komunikatu (np. zerwania sąsiedztwa BGP lub OSPF)
  • Odrzucanie szumu instrukcją `stop`: Natychmiastowe zatrzymanie przetwarzania mało istotnych zdarzeń (np. flapping negocjacji PoE lub okresowe komunikaty CDP)
  • Wykonywanie zewnętrznych skryptów (`omprog`): Możliwość natychmiastowego wywołania skryptu powłoki lub webhooka w momencie wykrycia krytycznego wzorca zdarzenia
Eliminacja szumu (De-Noising): W dużych sieciach przełączniki generują miliony zdarzeń informacyjnych dziennie. Odsianie zbędnych powiadomień na poziomie rsysloga (instrukcja stop) potrafi zredukować wielkość bazy danych nawet o 60-70%!
Filtrowanie w RainerScript Logika warunkowa i wyrażenia regularne w RainerScript # 1. Filtrowanie na podstawie adresu IP źródła i wagi zdarzenia: if ($fromhost-ip == '10.99.0.1' and $syslogseverity <= 3) then { action(type="omfile" file="/var/log/network/core_errors.log") # Równoległe powiadomienie skryptem zewnętrznym o awarii rdzenia: action(type="omprog" binary="/usr/local/bin/send_noc_alert.sh") } # 2. Zaawansowane dopasowywanie treści wyrażeniem regularnym POSIX Regex: if ($msg re_match "BGP-5-ADJCHANGE.*Down") then { action(type="omfile" file="/var/log/network/bgp_failures.log") } # 3. Odrzucanie szumu (Blacklisting nieistotnych komunikatów): if ($msg contains "CDP-4-DUPLEX_MISMATCH" or $msg contains "DOT1X-5-SUCCESS") then { stop # Porzucenie logu przed zapisem na dysk w celu ochrony I/O }
Slajd 16/55
Przekazywanie logów (Forwarding) i kolejki buforowe
Cel slajdu: Przedstawienie architektury niezawodnego przekazywania logów z wykorzystaniem asynchronicznych kolejek dyskowo-pamięciowych (Disk-Assisted Memory Queue).

Standardy protokołu Syslog i silnik rsyslog

Podczas awarii łącza WAN lub restartu centralnego serwera logów zwykły klient Syslog gubi pakiety. Rozwiązaniem jest zaawansowana kolejka rsyslog.

  • Architektura Disk-Assisted Memory Queue: Domyślna praca w ultraszybkiej pamięci RAM; w razie zapełnienia bufora następuje automatyczny zrzut na dysk (spooling)
  • Progi HighWaterMark i LowWaterMark: Parametry kontrolujące moment rozpoczęcia zrzucania zdarzeń na dysk (domyślnie w rsyslog 90% pojemności kolejki) i powrotu do pamięci (domyślnie 70%)
  • Odporność na restart klienta (`queue.saveonshutdown`): Bezpieczne zachowanie nieprzetworzonych komunikatów w plikach dyskowych podczas wyłączania systemu operacyjnego
  • Nieblokujące działanie aplikacji źródłowych: Aplikacje systemowe generujące logi nie zawieszają się, oczekując na potwierdzenie sieciowe (pełna asynchroniczność)
Parametry kolejki w RainerScript:
action(type="omfwd" target="10.99.0.10" port="514" protocol="tcp" queue.type="LinkedList" queue.filename="fwd_q" queue.maxdiskspace="10g" queue.saveonshutdown="on")
Kolejki buforowe w rsyslog Mechanizmy buforowania: Kolejka Disk-Assisted Memory Queue Kolejka w pamięci RAM • Typ: LinkedList • Rozmiar: 100 000 zdarzeń (domyślnie 1000) • Ekstremalnie niski narzut opóźnienia • Buforuje normalny ruch sieciowy Próg wysokiej wody (HighWater): Zrzut na dysk (domyślnie 90% bufora) Działanie standardowe: bufor w RAM Spooling Kolejka dyskowa (On-Disk Spool) • Katalog: /var/spool/rsyslog/ • Plik: fwd_queue.00000001 • Maksymalny limit: 10 GB • Ochrona przed awarią łącza Próg niskiej wody (LowWater): Powrót do RAM (domyślnie poniżej 70%) Wysoka ochrona przed utratą logów
Slajd 17/55
Bezpieczny transport logów przez TLS (RFC 5425)
Cel slajdu: Przedstawienie standardu szyfrowania strumienia Syslog z wykorzystaniem protokołu TLS na dedykowanym porcie TCP 6514 oraz obustronnego uwierzytelniania mTLS.

Standardy protokołu Syslog i silnik rsyslog

Przesyłanie logów otwartym tekstem po protokole UDP stwarza ryzyko podsłuchu poufnych danych oraz wstrzyknięcia fałszywych zdarzeń. RFC 5425 rozwiązuje te problemy.

  • Standard IETF RFC 5425: Oficjalny standard enkapsulacji ramek Syslog w bezpiecznym tunelu TLS z domyślnym portem IANA `TCP 6514`
  • Poufność i integralność kryptograficzna: Szyfrowanie symetryczne (AES-256-GCM) uniemożliwia odczytanie treści komunikatów przez osoby podsłuchujące sieć
  • Obustronne uwierzytelnienie certyfikatami (mTLS): Zarówno serwer weryfikuje tożsamość nadawcy, jak i klient potwierdza autentyczność kolektora logów
  • Sterownik `lmnsd_gtls` w rsyslog: Implementacja biblioteki GnuTLS lub OpenSSL w rsyslog zapewniająca wysoką przepustowość szyfrowania
Dlaczego tradycyjny Syslog UDP 514 jest niebezpieczny? Logi sieciowe często zawierają adresy IP, nazwy kont użytkowników, błędy zapytań SQL, a niekiedy nawet hasła wpisane przez pomyłkę w polu loginu. Transmisja niezaszyfrowana stanowi bezpośrednie naruszenie art. 32 RODO!
Syslog over TLS (RFC 5425) Bezpieczny transport Syslog przez TLS (RFC 5425 / Port TCP 6514) Klient rsyslog • Certyfikat X.509 • Klucz prywatny • Certyfikat CA Weryfikacja CA Sprawdzenie tożsamości serwera centralnego Kanał szyfrowany TLS 1.3 • Port docelowy: TCP 6514 • Poufność: Szyfrowanie AES-GCM • Integralność: Tag uwierzytelniający AEAD • Ochrona: Brak podsłuchu i spoofingu 🔒 mTLS Uwierzytelnienie obustronne Serwer centralny • Certyfikat serwera • Klucz prywatny • Baza urzędu CA Walidacja klienta Odrzucenie połączeń bez ważnego certyfikatu
Slajd 18/55
Protokół RELP (Reliable Event Logging Protocol)
Cel slajdu: Przedstawienie zasady działania protokołu RELP eliminującego utratę danych wynikającą z asynchroniczności buforów jądra w standardowym protokole TCP.

Standardy protokołu Syslog i silnik rsyslog

Wbrew powszechnemu przekonaniu, sam protokół TCP nie gwarantuje dostarczenia logów do aplikacji odbiorczej. Protokół RELP wprowadza potwierdzenia na poziomie warstwy aplikacji.

  • Ułomność zwykłego transportu TCP: Potwierdzenie TCP ACK jest generowane przez jądro systemu odbiorcy, zanim demon logowania zdąży zapisać wiadomość na dysku
  • Zasada działania protokołu RELP: Klient numeruje każdą ramkę identyfikatorem transakcji (TXNR); serwer odsyła potwierdzenie aplikacyjne dopiero po fizycznym zapisie logu
  • Model dostarczania 'At-Least-Once': Ochrona przed utratą logów podczas awarii sieci lub awarii procesu rsyslog odbiorcy (przy retransmisji dopuszczalne duplikaty)
  • Dedykowany moduł `imrelp` / `omrelp`: Natywna obsługa w rsyslogu z możliwością jednoczesnego tunelowania w bezpiecznym kanale TLS na porcie `TCP 20514`
Scenariusz utraty logu w TCP: Klient wysyła pakiet -> jądro serwera odsyła TCP ACK -> klient usuwa log z pamięci -> w tym ułamku sekundy następuje restart serwera. Log znajdujący się w buforze jądra znika bezpowrotnie! Protokół RELP eliminuje ten problem dzięki potwierdzeniom warstwy aplikacji.
Protokół RELP Niezawodny protokół RELP: Potwierdzenia w warstwie aplikacji Problem: Syslog over standard TCP 1. Klient wysyła pakiet Syslog w TCP 2. Karta sieciowa serwera odsyła TCP ACK 3. Pakiet trafia do bufora jądra Linux 4. Awaria zasilania / Crash demona serwera! Skutek: Utrata danych! Klient uważa log za dostarczony, chociaż nigdy nie trafił na dysk. Brak potwierdzenia aplikacyjnego Rozwiązanie: Protokół RELP 1. Klient wysyła ramkę RELP z TXNR 2. Serwer zapisuje log na dysku / bazie 3. Dopiero po zapisie serwer odsyła RELP ACK 4. Klient usuwa log z kolejki w RAM Gwarancja: At-Least-Once Delivery Jeśli serwer ulegnie awarii, klient ponowi wysyłkę po restarcie. Port domyślny RELP: TCP 20514
Slajd 19/55
Logowanie zdarzeń w MikroTik RouterOS
Cel slajdu: Przedstawienie architektury podsystemu logowania w systemie MikroTik RouterOS v7, typów akcji (memory, disk, echo, remote) oraz konfiguracji wysyłki zdalnej.

Konfiguracja urządzeń i platformy analityczne

RouterOS posiada elastyczny mechanizm logowania oparty na rozdziale celów zapisu (Actions) od reguł filtrowania zdarzeń (Rules).

  • Podsystem akcji (`/system logging action`): Definiuje medium docelowe: bufor ulotny w pamięci RAM (`memory`), plik na dysku Flash (`disk`) lub wysyłkę sieciową (`remote`)
  • Ochrona pamięci Flash routera: Częsty zapis do akcji `disk` może doprowadzić do przedwczesnego zużycia komórek pamięci NAND wbudowanej w płytę RouterBOARD
  • Konfiguracja celu zdalnego (`remote`): Wskazanie adresu IP serwera rsyslog, portu UDP 514, adresu źródłowego oraz przypisanego kodu Facility (np. `local1`)
  • Jednoczesne logowanie do wielu celów: RouterOS pozwala na jednoczesne wysyłanie tego samego zdarzenia do bufora RAM oraz na serwer centralny
Zużycie pamięci Flash na MikroTik: Domyślna konfiguracja RouterOS zapisuje logi do RAM (memory). Włączenie pełnego logowania zapory ogniowej do akcji disk generuje setki tysięcy cykli zapisu i może trwale uszkodzić pamięć Flash routera w ciągu kilku miesięcy! Zawsze loguj do akcji remote.
Logowanie w MikroTik RouterOS Podsystem logowania w MikroTik RouterOS: Akcje i cele # 1. Definicja zdalnej akcji logowania (Remote Syslog Action): [admin@MikroTik] > /system logging action add name=CentralNms target=remote remote=10.99.0.10 remote-port=514 \ src-address=10.99.0.1 syslog-facility=local1 syslog-severity=auto # 2. Domyślne wbudowane akcje celów logowania w RouterOS: • memory: Bufor kołowy w RAM (domyślnie 1000 linii, ulotny po restarcie) • disk: Zapis do pamięci Flash (/log.0.txt; uwaga na zużycie komórek NAND!) • echo: Wyświetlanie komunikatów w czasie rzeczywistym w oknie konsoli CLI • remote: Wysyłka pakietów UDP Syslog do centralnego serwera rsyslog # 3. Przypisanie zdarzeń krytycznych do akcji zdalnej i lokalnej: [admin@MikroTik] > /system logging add topics=critical action=CentralNms add topics=error action=CentralNms add topics=warning action=CentralNms # Zdarzenia krytyczne są natychmiast strumieniowane do serwera 10.99.0.10
Slajd 20/55
Tematy (Topics) i prefiksy w MikroTik RouterOS
Cel slajdu: Przedstawienie logiki tematów (Topics), filtrowania wielotematowego, stosowania operatorów negacji oraz znakowania komunikatów unikalnymi prefiksami.

Konfiguracja urządzeń i platformy analityczne

Zamiast sztywnych kodów Facility system RouterOS posługuje się elastycznym mechanizmem tematów (Topics), które można łączyć w logiczne filtry.

  • Hierarchia tematów (Topics): Główne obszary: `system`, `firewall`, `account`, `dhcp`, `ospf`, `bgp`, `wireless`, `dns`, `script`
  • Tematy wagowe (Severities w RouterOS): Flagi dotkliwości: `critical`, `error`, `warning`, `info`. Mogą występować samodzielnie lub w parze z podsystemem
  • Dodawanie prefiksów identyfikujących (`prefix`): Statyczny ciąg znaków wstrzykiwany na początku wiadomości (np. `R1-WAW`), ułatwiający filtrowanie na serwerze rsyslog
  • Operatory logiczne w tematach: Możliwość precyzyjnego wykluczania szumu za pomocą znaku wykrzyknika, np. `topics=dhcp,!info` (rejestruje tylko błędy DHCP)
Audyt zmian konfiguracyjnych w RouterOS: Włączenie tematu account rejestruje każde logowanie (przez WinBox, SSH, WebFig) oraz każdą wykonaną komendę zmiany konfiguracji wraz z nazwą użytkownika i adresem IP!
Tematy i prefiksy RouterOS Tematy (Topics) i prefiksy w MikroTik RouterOS # 1. Logowanie odrzuconych pakietów na zaporze ogniowej Firewall: [admin@MikroTik] > /ip firewall filter add chain=input action=drop log=yes log-prefix="FW-DROP-INPUT: " \ comment="Blokada i rejestracja nieautoryzowanych prob logowania" # 2. Skierowanie tematu firewall do centralnego serwera z prefiksem: [admin@MikroTik] > /system logging add topics=firewall action=CentralNms prefix="R1-WAW" # 3. Logowanie zdarzeń administracyjnych (kto i co zmienial w konfiguracji): [admin@MikroTik] > /system logging add topics=account action=CentralNms prefix="R1-WAW" # 4. Wykluczanie szumu za pomocą negacji tematu (operator !): [admin@MikroTik] > /system logging add topics=wireless,!debug action=CentralNms prefix="R1-WAW" # Rejestruje zdarzenia Wi-Fi z wyłączeniem szumu debugowania stacji
Slajd 21/55
Logowanie na urządzeniach Cisco IOS
Cel slajdu: Przedstawienie standardu konfiguracji demona logowania w Cisco IOS/IOS-XE, formatowania znaczników czasu ze stemplem milisekundowym oraz izolacji ruchu źródłowego.

Konfiguracja urządzeń i platformy analityczne

Przełączniki i routery Cisco posiadają jeden z najbardziej rozbudowanych podsystemów logowania, wymagający jednak prawidłowej konfiguracji stempli czasowych.

  • Precyzyjne znaczniki czasu (`service timestamps`): Kluczowa komenda wymuszająca format milisekundowy (`msec`) oraz strefę czasową (`show-timezone`), bez której logi są bezużyteczne śledczo
  • Interfejs źródłowy (`logging source-interface`): Wymuszenie wysyłki pakietów Syslog ze stałego adresu IP interfejsu wirtualnego `Loopback0`
  • Próg ważności wysyłki (`logging trap`): Ograniczenie ruchu zdalnego do poziomu `warnings` (4) wzwyż w celu ochrony przepustowości sieci
  • Wyłączenie logowania na konsoli szeregowej (`no logging console`): Ochrona procesora switcha: wypisywanie logów na wolnym porcie RS-232 (9600 bps) może zawiesić urządzenie!
Blokada procesora przez port konsoli: Wyświetlanie tysięcy komunikatów na fizycznym porcie konsoli szeregowej (UART 9600 bodów) odbywa się synchronicznie w przerwaniach procesora. Przy awarii sieci przełącznik z włączoną opcją logging console może całkowicie przestać przekazywać pakiety!
Logowanie w Cisco IOS Konfiguracja podsystemu Cisco IOS Syslog i synchronizacja czasu # 1. Bezwzględnie wymagana synchronizacja czasu i precyzja znaczników: Switch-Core(config)# ntp server 10.99.0.5 Switch-Core(config)# service timestamps log datetime msec show-timezone # Generuje znaczniki w formacie: Sep 29 22:20:15.124 CEST # 2. Definicja zdalnego serwera logów oraz interfejsu źródłowego: Switch-Core(config)# logging host 10.99.0.10 transport udp port 514 Switch-Core(config)# logging source-interface Loopback0 # 3. Konfiguracja poziomu ważności i kodu źródła Facility: Switch-Core(config)# logging trap warnings # Wysyła poziomy 0, 1, 2, 3, 4 Switch-Core(config)# logging facility local7 # 4. Optymalizacja lokalnego bufora w pamięci RAM przełącznika: Switch-Core(config)# logging buffered 64000 informational Switch-Core(config)# no logging console # Wyłączenie spowalniania portu konsoli! # Podgląd lokalnego bufora: show logging
Slajd 22/55
Logowanie w systemach Linux: journald i integracja
Cel slajdu: Przedstawienie relacji między natywnym dziennikiem systemd-journald a demonem rsyslog oraz procedury eksportu logów serwerów do centralnego kolektora.

Konfiguracja urządzeń i platformy analityczne

We współczesnych dystrybucjach Linuksa dziennik systemd-journald odpowiada za zbieranie logów lokalnych, a rsyslog za ich bezpieczną telemetrię sieciową.

  • Natywny demon `systemd-journald`: Gromadzi logi w zoptymalizowanym formacie binarnym; rejestruje komunikaty jądra oraz wyjścia `stdout`/`stderr` wszystkich usług systemd
  • Przekazywanie przez gniazdo (`ForwardToSyslog`): Dyrektywa w `/etc/systemd/journald.conf` przekazuje kopię strumienia do gniazda `/run/systemd/journal/syslog`
  • Moduł `imjournal` w rsyslog: Pozwala rsyslogowi na bezpośredni odczyt bazy journald wraz ze wszystkimi metadanymi systemowymi (np. `_SYSTEMD_UNIT`, `_COMM`)
  • Komenda `journalctl` do analizy lokalnej: Potężne narzędzie diagnostyczne pozwalające na filtrowanie per jednostka (`-u sshd`), czas (`--since '1 hour ago'`) czy priorytet (`-p err`)
Przydatne kwerendy journalctl dla inżyniera:
journalctl -u rsyslog.service -f (śledzenie w czasie rzeczywistym)
journalctl -p err..emerg --since today (wyświetlenie tylko błędów z dzisiejszego dnia)
journald i rsyslog Integracja podsystemu systemd-journald z silnikiem rsyslog systemd-journald (Natywny Linux) • Binarne pliki dziennika (/run, /var) • Metadane procesu (PID, UID, cgroup) • Przechwytuje stdout/stderr usług • Podgląd narzędziem: journalctl ForwardToSyslog=yes Przekazywanie do gniazda unix Lokalne rejestrowanie usług /dev/log rsyslog (Centralizacja & Sieć) • Moduł wejścia: imuxsock / imjournal • Filtrowanie regułami RainerScript • Buforowanie w kolejkach dyskowych • Szyfrowana wysyłka TLS (port 6514) action(type="omfwd" ...) Wysyłka logów OS do NMS / SIEM Eksport sieciowy do centrali
Slajd 23/55
Trójwarstwowa architektura centralnego gromadzenia logów
Cel slajdu: Przedstawienie skalowalnego modelu architektonicznego zbierania logów w organizacjach rozproszonych geograficznie: warstwy brzegowej, agregacyjnej i centralnej.

Konfiguracja urządzeń i platformy analityczne

W sieciach korporacyjnych bezpośrednie przesyłanie logów z setek urządzeń przez Internet do jednego serwera jest nieefektywne i zawodne. Stosuje się model trójwarstwowy.

  • Warstwa 1: Urządzenia brzegowe (Edge Tier): Generatory zdarzeń wysyłające logi w lokalnym segmencie sieci zarządzającej (zwykle po porcie UDP 514)
  • Warstwa 2: Regionalne koncentratory (Relay Tier): Lokalne serwery rsyslog w oddziałach firmy, buforujące pakiety na dysku SSD i przesyłające je do centrali w szyfrowanym strumieniu TLS
  • Warstwa 3: Centralny klaster analityczny (Core Tier): Równoważenie obciążenia (Load Balancer), kolejka buforowa Apache Kafka oraz klaster przeszukiwania (OpenSearch/SIEM)
  • Zalety modelu wielowarstwowego: Odporność na zerwania łączy WAN, kompresja ruchu sieciowego, redukcja opóźnień i skalowalność do milionów zdarzeń/s
Rola kolejki Apache Kafka w warstwie centralnej: Kafka działa jako niezatapialny bufor strumieniowy między odbiornikami Syslog a bazą danych OpenSearch. Gdy ruch gwałtownie rośnie (np. podczas ataku DDoS), Kafka przyjmuje miliony zdarzeń na sekundę, chroniąc silnik wyszukiwarki przed przeciążeniem.
Architektura 3-warstwowa logów Trójwarstwowa architektura zbierania logów w skali Enterprise Warstwa 1: Brzeg (Edge) Switche i AP Wi-Fi UDP 514 lokalnie w VLAN Routery MikroTik Zdarzenia zapory i BGP Serwery wirtualne journald + agent rsyslog Generacja >50k msg/s LAN Warstwa 2: Relays (Oddziały) Lokalny serwer Relay • Odbiór UDP w oddziale • Buforowanie dyskowe SSD • Kompresja strumienia logów Bezpieczny tranzyt WAN • Szyfrowany tunel TLS 6514 • Odporność na awarie łącza Agregacja i kompresja WAN/TLS Warstwa 3: Data Center Klaster Load Balancer HAProxy / Nginx Stream Kafka / Logstash Kolejkowanie strumieniowe Klaster SIEM / OpenSearch Wazuh, reguły, dashboardy Składowanie i SOC
Slajd 24/55
Platforma Graylog – Zaawansowana analiza logów
Cel slajdu: Przedstawienie architektury platformy Graylog, podziału na moduły przetwarzania, bazę OpenSearch i MongoDB oraz formatu GELF.

Konfiguracja urządzeń i platformy analityczne

Graylog to wiodąca platforma klasy Log Management, zaprojektowana specjalnie do centralizacji, wzbogacania i szybkiego przeszukiwania logów sieciowych i serwerowych.

  • Format GELF (Graylog Extended Log Format): Nowoczesny format zapisu logów w JSON z kompresją GZIP, eliminujący ograniczenia długości tradycyjnego Sysloga
  • Potoki przetwarzania (Processing Pipelines): Reguły w locie modyfikujące wiadomości: parsowanie adresów IP, dopasowywanie baz GeoIP, usuwanie danych wrażliwych
  • Separacja uprawnień i strumienie (Streams): Możliwość odseparowania logów zapory sieciowej (dostępne dla SOC) od logów przełączników dostępowych (dla administratorów LAN)
  • Architektura trójelementowa: Serwer Graylog przetwarza dane, OpenSearch odpowiada za superszybkie indeksowanie, a MongoDB przechowuje konfigurację
Zaleta formatu GELF nad Syslog: GELF pozwala na przesyłanie komunikatów o wielkości wielu megabajtów (automatyczne dzielenie na fragmenty), natywne wsparcie dla typów danych (liczby, ciągi, float) oraz brak konieczności parsowania tekstu.
Platforma Graylog Architektura platformy Graylog: Serwer, OpenSearch i MongoDB 1. Graylog Server (Core) Kolektory wejścia (Inputs) Syslog UDP/TCP, GELF, Beats Rurociągi (Pipelines) Transformacja i wzbogacanie GeoIP Strumienie (Streams) Routing logów do zespołów NOC/SOC Przetwarzanie w locie 2. Baza OpenSearch Indeksowanie odwrócone Wyszukiwanie pełnotekstowe w ułamku sekundy Zarządzanie indeksami Rotacja dzienna / po rozmiarze Automatyczne czyszczenie Pamięć masowa i kwerendy 3. MongoDB & Web UI Baza metadanych (Mongo) Konta, uprawnienia RBAC, reguły alertów i dashboardy Panel Web GUI (Port 9000) Interaktywne wykresy, mapy GeoIP, alerty email Prezentacja i metadane
Slajd 25/55
Stos ELK / OpenSearch (Elasticsearch, Logstash, Kibana)
Cel slajdu: Przedstawienie architektury ekosystemu ELK / OpenSearch do wielkoskalowej analizy logów teleinformatycznych, wzorców Grok oraz cyklu życia indeksów.

Konfiguracja urządzeń i platformy analityczne

Stos oparty na silnikach OpenSearch lub Elasticsearch stanowi standard branżowy dla organizacji przetwarzających terabajty logów dziennie.

  • Ekstrakcja danych filtrem Grok w Logstash: Rozbijanie surowego tekstu logów sieciowych na ustrukturyzowane pola JSON za pomocą gotowych wzorców `% {IP:client}`
  • Indeksowanie odwrócone (Inverted Index): Kluczowa technologia bazodanowa pozwalająca przeszukiwać miliardy wpisów w czasie poniżej sekundy
  • Cykl życia indeksów (Index State Management - ISM): Automatyczna migracja danych: faza Hot (dyski NVMe), Warm (dyski HDD), Cold (archiwum S3) i usunięcie po okresie retencji
  • Wizualizacja w OpenSearch Dashboards / Kibana: Budowa dynamicznych dashboardów NOC/SOC prezentujących trendy awaryjności i korelacje zdarzeń
Indeks odwrócony (Inverted Index): Struktura danych przypominająca skorowidz na końcu książki. Zamiast przeszukiwać każdy log po kolei, baza przechowuje listę wszystkich unikalnych słów (tokenów) i przypisane do nich numery dokumentów, co gwarantuje natychmiastowe wyszukiwanie.
Stos ELK i OpenSearch Stos Elastic / OpenSearch w monitorowaniu sieci 1. Logstash / Fluentbit Input Plugins Odbiór Syslog UDP/TCP, NetFlow v9, IPFIX, sFlow Filtry Grok & Mutate Wyrażenia Grok: zamiana tekstu na obiekty JSON Ingest & Normalizacja 2. OpenSearch (Baza) Indeksy Lucene Shardy pierwotne i repliki Odporność na awarię węzła Zarządzanie ISM Index State Management Hot -> Warm -> Cold -> Delete Skalowalny klaster 3. Dashboards (Kibana) Język zapytań KQL Błyskawiczne filtrowanie: host: "sw-core*" AND err Wizualizacje NOC Histogramy błędów CRC, statystyki awarii łączy Eksploracja i analityka
Slajd 26/55
Integracja logów Syslog z LibreNMS
Cel slajdu: Przedstawienie mechanizmu integracji logów sieciowych z systemem LibreNMS, roli skryptu syslog.php oraz powiązania wpisów z identyfikatorem device_id.

Konfiguracja urządzeń i platformy analityczne

LibreNMS integruje metryki SNMP z logami Syslog w jednym spójnym panelu, co pozwala inżynierom widzieć wykresy interfejsów obok zdarzeń systemowych.

  • Struktura tabeli `syslog` w bazie bazy danych: Logi składowane są w dedykowanej tabeli powiązanej kluczem obcym `device_id` z tabelą monitorowanych węzłów
  • Skrypt parsowania pośredniczącego (`syslog.php`): Odbiera strumień ze standardowego wejścia z demona rsyslog lub syslog-ng, rozpoznaje adres IP nadawcy i przypisuje właściwe `device_id`
  • Korelacja wykresów RRD ze zdarzeniami: Zdarzenia Syslog (np. restart interfejsu) są nanoszone jako pionowe linie znaczników bezpośrednio na wykresy ruchu portów
  • Generowanie alertów z treści komunikatów: Silnik alertów LibreNMS pozwala zdefiniować regułę wyzwalającą powiadomienie e-mail/webhook w momencie nadejścia określonego logu
Czyszczenie tabeli syslog w LibreNMS: Tabela syslog rośnie w zawrotnym tempie. LibreNMS posiada wbudowany mechanizm czyszczenia (daily maintenance), domyślnie usuwający wpisy starsze niż 30 dni (parametr $config['syslog_purge'] = 30;).
Syslog w LibreNMS Integracja podsystemu Syslog w środowisku LibreNMS # 1. Rola tabeli syslog w relacyjnej bazie danych MariaDB LibreNMS: CREATE TABLE `syslog` ( `seq` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `device_id` int(10) unsigned NOT NULL, -- Powiązanie z tabelą devices! `facility` varchar(10) NOT NULL, `priority` varchar(10) NOT NULL, `msg` text NOT NULL, `timestamp` timestamp NOT NULL, PRIMARY KEY (`seq`), KEY `device_id` (`device_id`) ) ENGINE=InnoDB; # 2. Konfiguracja odbiornika syslog-ng / rsyslog w LibreNMS: destination d_librenms { program("/opt/librenms/syslog.php" template("$HOST $FACILITY $PRIORITY $LEVEL $TAG $YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC $MSG\n")); }; # 3. Widok w panelu Web UI LibreNMS: Zakładka: Overview -> Eventlog lub Device -> Logs -> Syslog # LibreNMS automatycznie parsuje adres IP i przypisuje log do kafelka urządzenia
Slajd 27/55
Obsługa logów w systemie MikroTik The Dude
Cel slajdu: Przedstawienie wbudowanego serwera Syslog w systemie MikroTik The Dude, wizualnego wiązania zdarzeń z mapą topologii oraz powiadomień dźwiękowych i dymkowych.

Konfiguracja urządzeń i platformy analityczne

System MikroTik The Dude posiada zintegrowany serwer Syslog, który odbiera komunikaty z routerów i przełączników, przypisując je bezpośrednio do ikon na mapie.

  • Zintegrowany serwer Syslog na porcie UDP 514: Uruchomienie nasłuchu bezpośrednio w usłudze The Dude bez konieczności instalowania zewnętrznych demonów
  • Kontekstowe wiązanie z mapą sieci: Logi powiązane są z konkretnymi węzłami topologii; operator widzi historię incydentów danego switcha w oknie jego właściwości
  • Wielokanałowe powiadomienia (Notifications): Wyzwalanie akcji po wykryciu słowa kluczowego w logu: dźwięk w stacji roboczej, okno typu Popup, wysyłka e-mail
  • Składowanie w bazie SQLite i retencja: Wpisy składowane są w centralnej bazie The Dude; konieczność konfiguracji automatycznego czyszczenia (np. retencja 14 dni)
Wydajność bazy SQLite w The Dude: Podsystem bazy danych The Dude oparty na SQLite nie jest przystosowany do odbierania tysięcy logów na sekundę. W dużych sieciach w The Dude loguje się wyłącznie zdarzenia o wadze error i critical, a logi masowe kieruje się do rsysloga/Grayloga.
Syslog w MikroTik The Dude Wbudowany serwer Syslog w MikroTik The Dude v7 # 1. Konfiguracja wbudowanej usługi Syslog w The Dude (RouterOS CLI): [admin@CHR-Dude] > /dude set syslog-enabled=yes syslog-port=514 # 2. Wizualne powiązanie logów z topologią sieci na mapie: • Odebrane logi są automatycznie mapowane na ikony urządzeń na podstawie adresu IP • Dwuklik na ikonie routera otwiera zakładkę "Syslog" z historią danego węzła • Możliwość definiowania filtrów grupujących według prefiksów i wagi zdarzenia # 3. Definiowanie powiadomień Notifications na podstawie wzorców logów: [admin@CHR-Dude] > /dude notification add name="Syslog-Alert-Popup" type=popup-message add name="Sound-Alarm" type=sound sound=critical # 4. Magazyn danych i retencja w bazie SQLite The Dude: [admin@CHR-Dude] > /dude set syslog-storage=sqlite syslog-retention=14d # Zalecenie: Ogranicz retencję do 14 dni, aby nie przeciążyć bazy SQLite
Slajd 28/55
Metody analizy logów: Regex, wzorce i anomalie
Cel slajdu: Przedstawienie metodyki analizy strumieni logów: od prostego dopasowywania wzorców wyrażeniami regularnymi po reguły progowe i zaawansowaną detekcję anomalii.

Konfiguracja urządzeń i platformy analityczne

Przeglądanie milionów linii tekstu przez człowieka jest niemożliwe. Nowoczesny monitoring wykorzystuje zautomatyzowane metody korelacji i ekstrakcji wzorców.

  • Dopasowywanie sygnaturowe (Regex & Grok): Identyfikacja znanych, powtarzalnych komunikatów o błędach (np. błędy modułów optycznych SFP, awarie zasilaczy)
  • Reguły progowe w oknach czasowych (Thresholding): Zliczanie zdarzeń w określonym czasie (np. wykrycie ataku Password Spraying: 10 nieudanych logowań w 60 sekund z jednego adresu IP)
  • Korelacja wieloźródłowa (Cross-Device Correlation): Łączenie zdarzeń z różnych urządzeń: komunikat `linkDown` na switchu zbieżny z alertem utraty trasy BGP na routerze
  • Analiza anomalii behawioralnych (UEBA): Wykrywanie nietypowych godzin aktywności administratora, logowań z niespotykanych geolokalizacji lub gwałtownego wzrostu liczby odrzuceń na zaporze
Korelacja zdarzeń (Event Correlation): Proces analityczny łączący pozornie odizolowane wpisy w logach z wielu urządzeń sieciowych w jeden spójny incydent bezpieczeństwa lub awarii, eliminujący fałszywe alarmy i wskazujący pierwotną przyczynę (Root Cause).
Metody analizy logów Metody analizy logów: Regex, korelacja i detekcja anomalii 1. Wzorce Regex Dopasowywanie składni: • Błędy autoryzacji SSH: Failed password for.*from • Flapping interfejsu: changed state to down Zastosowanie: Ekstrakcja IP i portu Statyczna sygnatura 2. Reguły progowe Korelacja w oknie czasu: • Licznik błędów > 5 • To samo źródło IP • Okno czasowe: 60 sek Automatyczna akcja: Ban IP na firewallu Detekcja ataków 3. Anomalie w czasie Analiza statystyczna: • Skok wolumenu zdarzeń • Logowania o 03:00 w nocy • Nowy nieznany agent user Baseline i odchylenia: Wykrywanie zagrożeń 0-day Machine Learning / UEBA
Slajd 29/55
Rotacja logów w systemie Linux: narzędzie logrotate
Cel slajdu: Przedstawienie zasad automatycznej rotacji, kompresji i retencji plików dzienników za pomocą narzędzia logrotate oraz obsługi sygnału SIGHUP dla rsysloga.

Konfiguracja urządzeń i platformy analityczne

Brak rotacji logów prowadzi do niekontrolowanego rozrostu plików, wyczerpania przestrzeni dyskowej oraz drastycznego spowolnienia operacji wyszukiwania.

  • Cykliczność rotacji (`daily`, `weekly`): Określenie częstotliwości archiwizacji dzienników; dla logów sieciowych zaleca się rotację codzienną
  • Okres przechowywania (`rotate 90`): Definicja liczby zachowywanych cykli (np. 90 dni); po tym czasie najstarsze pliki są automatycznie usuwane
  • Kompresja w tle (`compress`, `delaycompress`): Automatyczna kompresja algorytmem gzip redukująca zajętość dysku o 85–95% bez blokowania bieżącego zapisu
  • Sygnał ponownego otwarcia deskryptorów (`SIGHUP`): Sekcja `postrotate` wysyła sygnał HUP do demona rsyslog, nakazując zamknięcie starych i otwarcie nowych plików
Dlaczego sygnał SIGHUP jest kluczowy? W systemach Linux proces trzyma otwarty deskryptor pliku przez numer i-węzła (inode). Jeśli logrotate zmieni nazwę pliku, a rsyslog nie otrzyma sygnału SIGHUP, proces będzie nadal zapisywał dane do zarchiwizowanego pliku .log.1, zamiast pisać do nowo utworzonego pliku!
Narzędzie logrotate Automatyzacja cyklu życia logów: Konfiguracja logrotate # 1. Konfiguracja rotacji dla /var/log/network/*.log (/etc/logrotate.d/network): /var/log/network/*/*.log { daily # Rotacja wykonywana codziennie rotate 90 # Przechowywanie 90 zarchiwizowanych plików missingok # Brak błędu jeśli plik nie istnieje notifempty # Nie rotuj pustych plików compress # Kompresja zarchiwizowanych plików (gzip) delaycompress # Odłóż kompresję ostatniego pliku o 1 cykl dateext # Dodaj datę do nazwy: .log-20260929.gz sharedscripts postrotate /usr/lib/rsyslog/rsyslog-rotate || systemctl kill -s HUP rsyslog.service endscript } # Ręczne wymuszenie testu rotacji w trybie debug: logrotate -d /etc/logrotate.d/network
Slajd 30/55
Polityka retencji danych – jak długo przechowywać logi?
Cel slajdu: Przedstawienie zasad projektowania wielopoziomowej polityki przechowywania logów (Tiered Storage) bilansującej koszty infrastruktury z wymogami regulacyjnymi.

Konfiguracja urządzeń i platformy analityczne

Przechowywanie wszystkich logów w nieskończoność na szybkich dyskach jest ekonomicznie nieuzasadnione, natomiast ich zbyt szybkie kasowanie grozi sankcjami prawnymi.

  • Poziom gorący (Hot Tier: 0–30 dni): Wysokowydajne dyski NVMe; dane w pełni zaindeksowane w silniku wyszukiwania pod kątem natychmiastowej reakcji NOC na awarie
  • Poziom ciepły (Warm Tier: 31–90 dni): Tanie dyski pojemnościowe; indeksy tylko do odczytu z mocną kompresją, wykorzystywane przez analityków bezpieczeństwa podczas śledztw
  • Poziom zimny (Cold / Frozen Archive: 1–5 lat): Skompresowane pakiety plików w chmurze (S3 Glacier) lub na taśmach LTO, zabezpieczone sumami SHA-256 na potrzeby ewentualnego postępowania sądowego
  • Prawo a retencja: Wymogi sektorowe: telekomunikacja (12 miesięcy wg Prawa komunikacji elektronicznej), finanse PCI DSS (12 miesięcy, w tym 90 dni online)
Zasada minimalizacji danych (RODO art. 5): Logi zawierające adresy IP powiązane z osobami fizycznymi nie mogą być przechowywane dłużej, niż jest to niezbędne do celów, w których zostały zebrane. Po upływie okresu retencji dane muszą zostać bezpowrotnie usunięte lub zanonimizowane!
Polityka retencji danych Wielopoziomowa polityka retencji danych logów (Tiered Storage) 1. Hot Tier (0–30 dni) Pamięć szybka (NVMe): • Natychmiastowe kwerendy • Czas odpowiedzi < 1 sek • Pełne indeksowanie pól Przeznaczenie: Bieżący monitoring NOC Wysoki koszt / GB 2. Warm Tier (31–90 dni) Pamięć pojemna (HDD/SSD): • Indeksy tylko do odczytu • Wymuszone scalanie segmentów • Skompresowane bloki Przeznaczenie: Śledztwa i audyty SOC Średni koszt / GB 3. Cold Tier (1–5 lat) Archiwum (S3 Glacier / Taśma): • Skompresowane archiwum tar • Sumy kontrolne SHA-256 • Zabezpieczenie przed zapisem Przeznaczenie: Wymogi prawne i sądowe Minimalny koszt / GB
Slajd 31/55
Wektory zagrożeń i ataki na infrastrukturę logowania
Cel slajdu: Przedstawienie metod ataków na systemy logowania (podsłuch, spoofing, injection, flooding, manipulacja plikami) oraz technik przeciwdziałania tym zagrożeniom.

Konfiguracja urządzeń i platformy analityczne

Serwery logowania stanowią priorytetowy cel zaawansowanych grup przestępczych (APT), pragnących ukryć swoją obecność lub sparaliżować reakcję SOC.

  • Fałszowanie tożsamości i wstrzykiwanie logów (Log Injection): Wysyłanie sfałszowanych pakietów UDP z kodami znaków nowej linii (`\r\n`), wprowadzających w błąd analityków
  • Zalew komunikatami (Syslog Flooding / Denial of Service): Sztuczne generowanie setek tysięcy zdarzeń na sekundę w celu zapełnienia dysków i zamaskowania realnego ataku
  • Lokalne kasowanie i modyfikacja śladów (Log Tampering): Próby usunięcia plików `/var/log/` po uzyskaniu uprawnień superużytkownika root na skompromitowanym hoście
  • Manipulacja czasem systemowym (NTP Poisoning): Zafałszowanie zegara w celu uniemożliwienia prawidłowej korelacji zdarzeń w łańcuchu przyczynowo-skutkowym
Atak Log Injection: Jeśli aplikacja zapisuje nazwę użytkownika bezpośrednio do logu bez sanityzacji, intruz podający login admin\nSep 29 22:00:00 srv sshd[123]: Accepted password for root fałszuje linię w pliku dziennika!
Ataki na infrastrukturę logowania Wektory zagrożeń i typowe ataki na systemy zbierania logów 1. Spoofing & Injection Podszywanie się UDP: • Fałszowanie nagłówka IP • Wstrzykiwanie fałszywych logów • Ataki Log Injection (\r\n) • Ukrywanie prawdziwego celu Obrona: Szyfrowanie TLS / mTLS Fałszowanie dowodów 2. Syslog Flooding (DoS) Zalew komunikatami: • Przepełnienie buforów • Zapełnienie dysku serwera • Przeciążenie bazy SIEM • Zgubienie realnych alertów Obrona: Rate-limiting w rsyslog Blokada operacyjna 3. Tampering / Deletion Zacieranie śladów: • Kasowanie /var/log/* • Modyfikacja wpisów w edytorze • Zmiana zegara systemowego • Wyłączenie demona rsyslog Obrona: Magazyn WORM / Append-only Niszczenie dowodów
Slajd 32/55
Zabezpieczanie transmisji i uwierzytelnianie źródeł
Cel slajdu: Przedstawienie wielowarstwowej strategii zabezpieczania przesyłu logów: od natywnego TLS, przez tunele VPN (IPsec/WireGuard), po dedykowane sieci OOB.

Konfiguracja urządzeń i platformy analityczne

Wiele starszych przełączników sieciowych nie wspiera nowoczesnego szyfrowania TLS. Zapewnienie bezpieczeństwa wymaga zastosowania odpowiednich technik ochronnych.

  • Natywny transport TLS (RFC 5425): Najbardziej eleganckie rozwiązanie stosowane na serwerach i nowoczesnych routerach; eliminuje potrzebę dodatkowych tuneli
  • Tunele VPN WireGuard i IPsec: Idealne rozwiązanie dla zdalnych oddziałów: nieszyfrowany ruch UDP 514 z urządzeń sieciowych trafia do tunelu VPN i jest szyfrowany w locie
  • Dedykowany VLAN zarządzający (OOB): W serwerowniach ruch Syslog powinien być bezwzględnie odizolowany od podsieci użytkowników biurowych i gościnnych
  • Filtrowanie adresów na firewallu serwera: Rygorystyczne reguły `iptables`/`ufw` zezwalające na pakiety portu 514 wyłącznie z konkretnych adresów IP routerów
Architektura hybrydowa: Urządzenia brzegowe wysyłają logi po UDP 514 do lokalnego routera MikroTik z podniesionym tunelem WireGuard do centrali. Router przesyła pakiety bezpiecznym tunelem, eliminując ryzyko podsłuchu w Internecie.
Zabezpieczanie transmisji logów Zabezpieczanie kanałów transmisyjnych: Tunele VPN i izolacja Metody ochrony transmisji logów w zależności od możliwości urządzeń Metoda 1: Natywne szyfrowanie Syslog-over-TLS (RFC 5425 / TCP 6514) • Dedykowane dla: Nowoczesne serwery Linux, firewalle nowej generacji, routery Enterprise ✓ Obustronne uwierzytelnianie certyfikatami X.509 (mTLS), zerowy narzut tunelowania Metoda 2: Enkapsulacja w tunelu VPN (WireGuard / IPsec ESP) • Dedykowane dla: Oddziały firmy, urządzenia z obsługą wyłącznie UDP (starsze switche/MikroTik) ✓ Szyfrowanie całego ruchu między lokalnym przekaźnikiem a centralnym kolektorem Metoda 3: Fizyczna lub logiczna separacja w sieci OOB (Management VLAN) • Dedykowane dla: Centrum danych (Data Center), sieć lokalna kampusowa ✓ Całkowity brak routingu do Internetu, rygorystyczne listy kontroli dostępu ACL L3/L4
Slajd 33/55
Zapewnienie integralności logów (Tamper-Evidence)
Cel slajdu: Przedstawienie kryptograficznych metod weryfikacji integralności logów (RFC 5848, łańcuchy skrótów Hash-Chaining) oraz technologii nośników niezmiennych WORM.

Konfiguracja urządzeń i platformy analityczne

Aby logi stanowiły niepodważalny materiał dowodowy w sądzie lub przed audytorem, system musi gwarantować natychmiastowe wykrycie każdej próby ich modyfikacji.

  • Standard IETF RFC 5848 (Signed Syslog Messages): Mechanizm okresowego wstrzykiwania do strumienia podpisanych cyfrowo bloków sum kontrolnych (tzw. Signature Blocks)
  • Łańcuchy skrótów kryptograficznych (Hash-Chaining): Każdy wpis w logu zawiera skrót SHA-256 wpisu poprzedniego; zmiana lub usunięcie choćby jednej spacji unieważnia cały łańcuch
  • Nośniki typu WORM (Write Once, Read Many): Sprzętowa ochrona przed skasowaniem (np. Amazon S3 Object Lock w trybie Compliance lub dedykowane macierze WORM)
  • Atrybut systemu plików `chattr +a` (Append-Only): Blokada poziomu ext4/xfs: plik można wyłącznie powiększać o nowe wpisy; modyfikacja istniejących linii i obcięcie (truncate) są zablokowane dla wszystkich procesów, a usunięcie pliku wymaga uprzedniego zdjęcia atrybutu przez roota lub wycofania uprawnienia CAP_LINUX_IMMUTABLE
Wymóg dowodowy w procesie sądowym: Zgodnie z normą ISO/IEC 27037 cyfrowe dowody (logi) muszą posiadać udokumentowany łańcuch nadzoru (Chain of Custody) oraz sumy kontrolne SHA-256 potwierdzające, że administrator nie zmodyfikował treści po zaistnieniu incydentu.
Integralność logów i WORM Integralność kryptograficzna i ochrona przed manipulacją (RFC 5848) Łańcuch kryptograficzny bloków logów (Hash-Chaining) Wpis Logu #101 Treść zdarzenia Hash: 8f4a12... Wpis Logu #102 Zawiera Hash #101 Hash: c31b99... Wpis Logu #103 Zawiera Hash #102 Hash: e520fa... Podpis cyfrowy Klucz asymetryczny RFC 5848 Signature Praktyczne technologie gwarantujące niezmienność (WORM) • Nośniki WORM (Write Once, Read Many): Fizyczna lub sprzętowa blokada modyfikacji i usuwania plików przez zdefiniowany okres retencji (S3 Object Lock). • Atrybut Append-Only w systemie Linux: sudo chattr +a /var/log/network/audit.log (Zezwala wyłącznie na dopisywanie nowych linii na końcu pliku!)
Slajd 34/55
Zabezpieczenie dostępu do systemów zbierania logów
Cel slajdu: Przedstawienie procedur kontroli dostępu do centralnego repozytorium logów, modelu ról RBAC, uwierzytelniania wieloskładnikowego oraz audytu zapytań analityków.

Konfiguracja urządzeń i platformy analityczne

Centralny serwer logów zawiera wrażliwe informacje o całej infrastrukturze i użytkownikach. Dostęp do niego musi być rygorystycznie kontrolowany.

  • Zasada najmniejszych uprawnień (Least Privilege): Ścisły podział uprawnień: inżynier utrzymania sieci nie powinien mieć wglądu w logi kadrowe czy finansowe
  • Uwierzytelnianie wieloskładnikowe (MFA / FIDO2): Bezwzględny wymóg stosowania drugiego składnika uwierzytelniania przy logowaniu do paneli Graylog, Wazuh czy LibreNMS
  • Integracja z korporacyjnym katalogiem tożsamości: Wykorzystanie protokołów SAML 2.0 / OpenID Connect z Active Directory lub FreeIPA
  • Logowanie aktywności analityków (Audit the Auditors): Rejestrowanie każdego zapytania przeszukującego bazę logów w celu wykluczenia inwigilacji pracowników bez uzasadnienia
Audyt zapytań (Query Logging): Mechanizm chroniący organizację przed wewnętrznymi nadużyciami. Gdy analityk bezpieczeństwa przeszukuje logi pod kątem aktywności konkretnego adresu IP pracownika, system rejestruje dokładną treść kwerendy, datę oraz uzasadnienie biznesowe.
Kontrola dostępu do logów Zabezpieczenie dostępu i kontrola uprawnień w systemach NMS Matryca kontroli dostępu do repozytorium zdarzeń 1. Model RBAC Separacja ról: • Administrator NMS (zarządzanie) • Inżynier NOC (odczyt urządzeń) • Analityk SOC (pełny dostęp do logów) • Audytor (tylko raporty zgodności) Zasada Least Privilege 2. MFA / 2FA Metody uwierzytelniania: • Klucze sprzętowe FIDO2 / U2F • Aplikacje TOTP (Google Auth) • Integracja SAML 2.0 / OIDC • Ochrona przed kradzieżą haseł Ochrona tożsamości 3. Kto pyta o logi? Logowanie kwerend: • Rejestracja zapytań SQL/KQL • Kto przeszukiwał logi pracowników • Wykrywanie nadużyć uprawnień • Zgodność z RODO i etyką Audyt audytorów
Slajd 35/55
Standardy bezpieczeństwa i wytyczne CIS dla logowania
Cel slajdu: Przedstawienie międzynarodowych zaleceń Center for Internet Security (CIS Controls v8) w obszarze zarządzania dziennikami zdarzeń i audytu bezpieczeństwa.

Konfiguracja urządzeń i platformy analityczne

Wytyczne CIS Controls stanowią globalny punkt odniesienia dla inżynierów projektujących bezpieczne systemy rejestracji i nadzoru zdarzeń.

  • Zabezpieczenie CIS Control 8: Audit Log Management: Kompleksowy zestaw 12 podpunktów (Safeguards) standaryzujących cykl życia logów w przedsiębiorstwie
  • Bezwzględny wymóg synchronizacji czasu (CIS 8.4): Zastosowanie protokołu NTP na wszystkich węzłach sieciowych w celu zapewnienia dokładności znaczników czasu (poziom IG2)
  • Przechowywanie logów przez minimum rok (CIS 8.9): Wymóg retencji obejmującej co najmniej 90 dni w trybie natychmiastowego przeszukiwania oraz do roku w archiwum (poziom IG2)
  • Okresowy przegląd i audyt logów (CIS 8.11): Automatyzacja korelacji oraz procedury regularnej weryfikacji raportów anomalii przez personel cyberbezpieczeństwa
Wymogi Implementation Group (IG1, IG2, IG3): CIS dzieli zabezpieczenia na trzy poziomy dojrzałości. Zbieranie logów i zapewnienie przestrzeni dyskowej (CIS 8.2 i 8.3) to poziom podstawowy IG1. Standaryzacja czasu NTP (CIS 8.4), centralizacja (CIS 8.5) oraz roczna retencja (CIS 8.9) wchodzą w skład poziomu IG2.
Standardy CIS dla logowania Wytyczne Center for Internet Security: CIS Controls v8 (Zabezpieczenie 8) CIS Control 8: Zarządzanie dziennikami audytowymi (Audit Log Management) CIS 8.2: Zbieranie logów audytowych (Collect Audit Logs) [IG1] Zapewnij, że wszystkie zasoby sieciowe i serwery generują i przesyłają logi do centralnego repozytorium. CIS 8.3: Odpowiednia przestrzeń dyskowa (Ensure Adequate Storage) [IG1] Gwarancja wystarczającej pojemności magazynu logów, aby zapobiec ich nadpisaniu lub utracie. CIS 8.4: Standaryzacja synchronizacji czasu NTP (Standardize Time Sync) [IG2] Wszystkie węzły muszą synchronizować zegary z co najmniej dwoma zaufanymi serwerami NTP (Stratum 1/2). CIS 8.9: Roczna retencja dzienników (Require Min 1 Year Audit Log Retention) [IG2] Retencja przez min. rok, w tym natychmiastowa dostępność zapytań przez min. 90 dni.
Slajd 36/55
Nadzór nad zmianami konfiguracji sieci (Config Auditing)
Cel slajdu: Przedstawienie mechanizmów audytu zmian konfiguracji urządzeń sieciowych w Cisco IOS oraz automatyzacji wersjonowania w Git za pomocą narzędzia Oxidized.

Konfiguracja urządzeń i platformy analityczne

Większość awarii sieciowych wynika z błędów ludzkich podczas ręcznych zmian konfiguracyjnych. Rejestracja komend i wersjonowanie w Git to fundament nowoczesnego zarządzania.

  • Moduł Cisco IOS `archive log config`: Wymusza rejestrowanie każdego wykonanego polecenia w trybie konfiguracyjnym wraz z loginem administratora
  • Powiadomienie Syslog (`notify syslog`): Przełącznik natychmiast emituje zdarzenie `%PARSER-5-CFGLOG_LOGGEDCMD` do centralnego serwera
  • Automatyzacja backupu sterowana zdarzeniami (Event-Driven): Odebranie komunikatu o zmianie wyzwala zadanie w Oxidized pobierające nowy plik `running-config`
  • Wersjonowanie w Git i podgląd różnic (Diff): Możliwość błyskawicznego porównania zmian linii po linii i cofnięcia błędnej konfiguracji w kilka sekund
Event-Driven Configuration Backup: Zamiast odpytywać wszystkie przełączniki raz na dobę w nocy, system nasłuchuje zdarzeń Syslog. Kopia zapasowa w repozytorium Git powstaje dokładnie w ułamku sekundy po zatwierdzeniu zmian przez inżyniera!
Audyt zmian konfiguracji Automatyczny audyt i wersjonowanie konfiguracji urządzeń # 1. Konfiguracja logowania zmian konfiguracyjnych w Cisco IOS (Archive): Switch-Core(config)# archive Switch-Core(config-archive)# log config Switch-Core(config-archive-log-cfg)# logging enable Switch-Core(config-archive-log-cfg)# notify syslog # Wysyłaj komendy do Sysloga! # Każda wpisana komenda w trybie config generuje natychmiastowy komunikat Syslog # 2. Przykładowy wpis wygenerowany przez przełącznik w Syslogu: %PARSER-5-CFGLOG_LOGGEDCMD: User:jan logged command:interface GigabitEthernet0/24 %PARSER-5-CFGLOG_LOGGEDCMD: User:jan logged command:shutdown # 3. Integracja z narzędziem Oxidized (Wersjonowanie w Git): • Syslog odbiera komunikat o zmianie konfiguracji (CFGLOG_LOGGEDCMD) • Webhook wyzwala natychmiastowe pobranie konfiguracji przez Oxidized • Automatyczny commit do repozytorium Git i podgląd różnic (diff) ✓ Pełna rozliczalność zmian: Kto, kiedy i co dokładnie zmodyfikował w sieci!
Slajd 37/55
Systemy SIEM w architekturze operacyjnej SOC
Cel slajdu: Przedstawienie roli systemów SIEM (Security Information and Event Management) w nowoczesnym Security Operations Center oraz etapów normalizacji i korelacji zdarzeń.

Analiza incydentów, regulacje i laboratoria

Podczas gdy serwery Syslog skupiają się na samym odbiorze i składowaniu tekstu, systemy klasy SIEM analizują strumienie zdarzeń w czasie rzeczywistym, identyfikując wieloetapowe ataki.

  • Centralizacja i normalizacja schematów: Konwersja niejednorodnych logów z routerów, zapór sieciowych i serwerów do standardów takich jak ECS lub OCSF
  • Silnik korelacji zdarzeń (Rule Engine): Łączenie pozornie niepowiązanych wpisów (np. 10 prób logowania na SSH, skan portów i modyfikacja reguły firewalla) w jeden incydent
  • Integracja z macierzą MITRE ATT&CK: Automatyczne tagowanie alarmów identyfikatorami technik ataku (np. T1110 Brute Force, T1046 Network Service Discovery)
  • Trzypoziomowa obsługa w zespole SOC: Weryfikacja alarmów przez analityków Tier 1 (triage), pogłębiona analiza w Tier 2 oraz zaawansowany forensics w Tier 3
SIEM vs SOAR: System SIEM odpowiada za detekcję, indeksowanie i korelację zdarzeń. Z kolei platforma SOAR (Security Orchestration, Automation and Response) wykonuje automatyczne scenariusze reakcji (Playbooks), np. odcina port na przełączniku lub blokuje złośliwy adres IP na brzegu sieci w ciągu ułamka sekundy.
Architektura SIEM i SOC Przepływ danych w systemie SIEM i centrum SOC 1. Źródła logów • Routery & switche • Zapory NGFW • Serwery Linux/AD • Kontenery & K8s • Punkty końcowe Formaty surowe: Syslog, WinEvent, JSON 2. Przetwarzanie • Bufor Kafka/Queue • Parsery Grok / regex • Normalizacja ECS • Schemat OCSF • Wzbogacanie GeoIP Wspólny schemat: source.ip, event.code 3. Silnik korelacji • Okna czasowe (sliding) • Reguły progowe • Mapowanie ATT&CK • Detekcja anomalii • Redukcja szumów Agregacja alarmów: Incydent w SOC 4. Reakcja (SOC) • Triage Tier 1 • Śledztwo Tier 2 • Forensics Tier 3 • Platforma SOAR • Zgłoszenie CSIRT Mitygacja: Blokada IP, izolacja
Slajd 38/55
Otwarty system klasy SIEM i XDR: Architektura Wazuh
Cel slajdu: Przedstawienie budowy, modułów funkcjonalnych oraz mechanizmów zbierania i analizy logów w systemie Wazuh SIEM.

Analiza incydentów, regulacje i laboratoria

Wazuh to wiodąca platforma open-source łącząca funkcjonalności SIEM (zarządzanie logami) oraz XDR (Extended Detection and Response) na stacjach roboczych, serwerach i urządzeniach sieciowych.

  • Architektura trójmodułowa: Wazuh Agent (zbieranie danych), Wazuh Manager (dekodowanie, reguły, ocena) oraz Wazuh Indexer (baza OpenSearch)
  • Logowanie bezagentowe (Agentless): Odbiór zdarzeń z urządzeń sieciowych Cisco, MikroTik i przełączników brzegowych bezpośrednio przez protokół Syslog
  • Monitorowanie integralności plików (FIM): Śledzenie zmian w kluczowych plikach systemowych (np. /etc/passwd, pliki binarne) z wyliczaniem sum SHA-256 w czasie rzeczywistym
  • Aktywna reakcja (Active Response): Wykrycie zdefiniowanej sygnatury ataku wyzwala skrypt natychmiast blokujący adres IP na zaporze firewall lub w tabeli null-route
Skala ważności reguł w Wazuh (Rule Levels): Wazuh kategoryzuje reguły od poziomu 0 (ignorowane) do poziomu 16 (atak krytyczny w toku). Poziom 12 i wyższy z reguły kwalifikuje się do natychmiastowego zgłoszenia w dyżurze bezpieczeństwa SOC.
Architektura platformy Wazuh Architektura otwartej platformy SIEM/XDR Wazuh Kolekcja danych Wazuh Agents: • Linux / Windows / macOS • File Integrity (FIM) • Log collector & auditd Agentless (Syslog): • Cisco IOS / Catalyst • MikroTik RouterOS • Zapory pfSense / OPNsense Transport: TLS Port 1514 / Syslog 514 Wazuh Server (Manager) Silnik analityczny: • Dekodery (XML parsing) • Baza reguł (Ruleset 0-16) • Detekcja podatności CVE • Kontrola zgodności CIS • Integracje Threat Intel Active Response: Automatyczne blokowanie IP przez skrypt firewall-drop Indexer & Dashboard Wazuh Indexer: • Klaster na bazie OpenSearch • Indeksy dzienne (wazuh-alerts-*) • Szybkie zapytania analityczne Wazuh Dashboard: • Wizualizacje MITRE ATT&CK • Raporty audytowe (PCI, GDPR) Interfejs graficzny: Zarządzanie incydentami
Slajd 39/55
Scenariusze i sygnatury detekcji incydentów w logach
Cel slajdu: Przedstawienie praktycznych wektorów ataków sieciowych identyfikowanych na podstawie analizy korelacyjnej wpisów w dziennikach zdarzeń.

Analiza incydentów, regulacje i laboratoria

Pojedynczy log o błędzie logowania lub zablokowanym pakiecie nie świadczy o ataku. Dopiero korelacja agregująca zdarzenia w oknach czasowych pozwala wykryć rzeczywiste zagrożenie.

  • Ataki słownikowe i Password Spraying: Wielokrotne nieudane próby logowania z jednego adresu IP na różne konta użytkowników w krótkim przedziale czasu
  • Rekonesans i skanowanie portów (SYN Scan): Wysyp logów firewalla z odrzuceniami pakietów (DROP/REJECT) na kolejnych portach TCP/UDP z jednego źródła
  • Niestabilność topologii (BGP/OSPF/STP Flapping): Cykliczne komunikaty o zmianie stanu sąsiedztwa lub blokowaniu portu, wskazujące na pętlę w sieci lub atak DoS
  • Anomalie wolumetryczne i transfer danych: Logi zapór sieciowych wskazujące na nietypowy transfer dziesiątek gigabajtów danych na zewnętrzny adres IP w godzinach nocnych
Wskaźniki kompromitacji (IoC): W trakcie analizy logów inżynierowie poszukują tzw. IoC (Indicators of Compromise), takich jak znane adresy IP serwerów Command & Control (C2), hasze złośliwych plików czy nietypowe nagłówki User-Agent.
Detekcja ataku w logach Korelacja logów: Wykrywanie ataku typu Brute-Force # Strumień logów z serwera SSH (/var/log/auth.log): 10:14:01 sshd[1201]: Failed password for root from 198.51.100.44 10:14:04 sshd[1204]: Failed password for admin from 198.51.100.44 10:14:07 sshd[1208]: Failed password for user from 198.51.100.44 10:14:11 sshd[1212]: Failed password for test from 198.51.100.44 10:14:15 sshd[1215]: Failed password for cisco from 198.51.100.44 10:14:19 sshd[1219]: Failed password for ubuntu from 198.51.100.44 Statystyka w oknie 60 sekund: • Unikalny adres źródłowy: 198.51.100.44 • Zdarzenia: 6 nieudanych prób logowania • Różne nazwy kont: Password Spraying Reguła korelacyjna SIEM IF event == 'auth_failed' AND count(event) >= 5 AND timespan <= 60s GROUP BY source.ip Wygenerowany Alarm: • Poziom: Severity High (Waga 10) • MITRE: T1110 (Brute Force) • Akcja: Uruchomienie skryptu blokady ✓ Powiadomienie dyżurnego SOC
Slajd 40/55
Cykl reagowania na incydenty sieciowe według NIST SP 800-61
Cel slajdu: Przedstawienie standardowej procedury obsługi incydentów bezpieczeństwa opracowanej przez National Institute of Standards and Technology (NIST SP 800-61 Rev. 3).

Analiza incydentów, regulacje i laboratoria

Skuteczna reakcja na incydent sieciowy wymaga ustrukturyzowanego podejścia procesowego. Logi zdarzeń stanowią kluczowy materiał badawczy w każdej fazie tego cyklu.

  • Faza 1: Przygotowanie (Preparation): Zapewnienie infrastruktury centralnego logowania, synchronizacji czasu NTP oraz konfiguracji retencji przed wystąpieniem incydentu
  • Faza 2: Wykrywanie i analiza (Detection & Analysis): Wykorzystanie logów sieciowych i reguł SIEM do określenia dokładnego momentu naruszenia, zakresu penetracji i tożsamości agresora
  • Faza 3: Powstrzymywanie i usuwanie skutków (Containment & Eradication): Mitygacja rozprzestrzeniania się ataku (np. zmiana VLAN, izolacja hosta) oraz weryfikacja w logach czy kanał boczny został odcięty
  • Faza 4: Działania poincydentalne (Post-Incident Activity): Wnioski poincydentalne (Lessons Learned), opracowanie oficjalnego raportu technicznego oraz wzbogacenie bazy reguł detekcji
Materiał dowodowy (Chain of Custody): Logi wykorzystywane w postępowaniach prawno-karnych muszą posiadać nienaruszony łańcuch dowodowy, poświadczony sumami kryptograficznymi oraz zabezpieczeniami uniemożliwiającymi ich modyfikację przez osoby trzecie.
Cykl obsługi incydentów NIST Cztery fazy cyklu reagowania na incydenty (NIST SP 800-61 Rev. 3) 1. Przygotowanie Działania wstępne: • Narzędzia Syslog/SIEM • Synchronizacja NTP • Szkolenia personelu • Polityki i procedury Rola logów: Gotowość do zapisu pełnego śladu 2. Detekcja & Analiza Identyfikacja: • Alerty zapór NGFW • Reguły korelacyjne • Triage i ocena wagi • Weryfikacja fałszywek Rola logów: Identyfikacja czasu t0 i wektora wejścia 3. Powstrzymywanie Mitygacja ataku: • Izolacja sieciowa (VLAN) • Blokada portu na switchu • Usunięcie złośliwego kodu • Przywrócenie z backupu Rola logów: Sprawdzenie czy atak nie przeniósł się dalej 4. Działania poincydentalne Podsumowanie: • Spotkanie Lessons Learned • Raport z incydentu • Aktualizacja reguł SIEM • Archiwizacja materiału Rola logów: Materiał dowodowy i podstawa raportu
Slajd 41/55
Wymagania normy ISO/IEC 27001:2022 dotyczące logowania
Cel slajdu: Przedstawienie zaktualizowanych wymagań normy ISO/IEC 27001:2022 w zakresie rejestracji zdarzeń, monitorowania aktywności i synchronizacji czasu.

Analiza incydentów, regulacje i laboratoria

Norma ISO/IEC 27001 definiuje wymagania dla Systemu Zarządzania Bezpieczeństwem Informacji (SZBI). Rewizja z 2022 roku kładzie szczególny nacisk na aktywne wykrywanie zagrożeń.

  • Zabezpieczenie A.8.15 (Rejestrowanie zdarzeń): Organizacja musi generować, przechowywać i chronić logi rejestrujące aktywności użytkowników, wyjątki i błędy
  • Zabezpieczenie A.8.16 (Monitorowanie aktywności): Wprowadzenie wymogu ciągłego monitorowania sieci i systemów pod kątem nietypowych zachowań w czasie rzeczywistym
  • Zabezpieczenie A.8.17 (Synchronizacja zegarów): Wszystkie systemy teleinformatyczne przetwarzające informacje muszą synchronizować zegary z referencyjnym źródłem NTP
  • Zabezpieczenie A.8.24 (Kryptografia): Zapewnienie poufności i niezmienności dzienników audytowych w tranzycie i w spoczynku przy użyciu algorytmów kryptograficznych
Audyt certyfikacyjny ISO 27001: Brak centralnego serwera logów, brak synchronizacji czasu na przełącznikach lub możliwość usunięcia logów przez administratora bez pozostawienia śladu stanowi niezgodność krytyczną (Major Non-Conformity).
Wymogi ISO/IEC 27001:2022 Zabezpieczenia Załącznika A normy ISO/IEC 27001:2022 A.8.15 Rejestrowanie zdarzeń (Logging) • Obowiązek tworzenia logów audytowych • Rejestracja aktywności uprzywilejowanych • Ochrona przed modyfikacją i kasowaniem Wymóg: Regularny przegląd dzienników A.8.16 Monitorowanie aktywności • Ciągły nadzór sieci i serwerów • Identyfikacja anomalii w czasie zbliżonym • Porównanie z linią bazową (Baseline) Wymóg: Zautomatyzowane alerty A.8.17 Synchronizacja zegarów • Wspólne, zweryfikowane źródło czasu • Wykorzystanie protokołu NTP / PTP • Dokładność znaczników czasu logów Wymóg: Jednolity czas w całej domenie A.8.24 Wykorzystanie kryptografii • Szyfrowanie transmisji logów (TLS 1.3) • Haszowanie integralności (SHA-256) • Podpisy cyfrowe wpisów (RFC 5848) Wymóg: Niezaprzeczalność dowodów
Slajd 42/55
Ochrona danych osobowych (RODO / GDPR) a logi sieciowe
Cel slajdu: Przedstawienie prawnych aspektów przetwarzania adresów IP i danych telemetrycznych w kontekście Ogólnego Rozporządzenia o Ochronie Danych (RODO).

Analiza incydentów, regulacje i laboratoria

Adres IP zarejestrowany w dzienniku zdarzeń może stanowić daną osobową. Administrator sieci musi zapewnić zgodność operacji logowania z przepisami unijnymi.

  • Precedensowy wyrok TSUE C-582/14 (Breyer): Trybunał Sprawiedliwości UE orzekł, że dynamiczny adres IP stanowi daną osobową, jeżeli administrator posiada środki do powiązania go z osobą
  • Podstawa prawna przetwarzania (Art. 6 ust. 1 lit. f): Prawnie uzasadniony interes administratora obejmuje zapewnienie odporności i ciągłości działania sieci teleinformatycznej
  • Zasada minimalizacji danych (Art. 5 ust. 1 lit. c): Konieczność filtrowania wrażliwych danych użytkowników (haseł, numerów PESEL, tokenów sesyjnych) ze strumieni logów
  • Pseudonimizacja i maskowanie (Art. 32): Stosowanie anonimizacji adresów IP (np. zerowanie ostatniego oktetu) w logach serwerów aplikacyjnych niekluczowych dla śledztw forensics
Wyciek haseł w nagłówkach HTTP: Błędy programistyczne często powodują zapisywanie haseł użytkowników w logach żądań GET serwerów proxy lub zapór sieciowych. Jest to naruszenie ochrony danych wymagające zgłoszenia do UODO w ciągu 72 godzin!
Logi sieciowe a RODO Przetwarzanie adresów IP w logach a zasady RODO Wyrok TSUE C-582/14 (Breyer) Status prawny adresu IP: • Dynamiczny adres IP stanowi daną osobową, gdy operator posiada środki prawne do zidentyfikowania użytkownika przez ISP. Podstawa prawna (Art. 6 ust. 1 lit. f): • Prawnie uzasadniony interes administratora: zapewnienie cyberbezpieczeństwa sieci, odpieranie ataków DDoS i brute-force. Wniosek prawny: Logowanie IP jest w pełni legalne Zasady Privacy by Design (Art. 25) 1. Minimalizacja danych (Data Minimization): Nie zapisuj haseł ani tokenów w logach URL! 2. Maskowanie / Pseudonimizacja adresu IP: Surowy IP: 198.51.100.44 Zamaskowany: 198.51.100.0/24 (IPv4) IPv6 Prefix: 2001:db8:abcd::/48 3. Ograniczenie przechowywania (Storage): Określenie twardego limitu retencji (np. 90 dni) i automatyczne usuwanie przez skrypt logrotate. Zgodność z Art. 5 i 32 RODO
Slajd 43/55
Dyrektywa NIS 2 oraz Krajowy System Cyberbezpieczeństwa (KSC)
Cel slajdu: Przedstawienie wymogów Dyrektywy unijnej NIS 2 i polskiej ustawy o Krajowym Systemie Cyberbezpieczeństwa w zakresie monitorowania logów oraz raportowania incydentów.

Analiza incydentów, regulacje i laboratoria

Dyrektywa NIS 2 drastycznie rozszerza krąg podmiotów zobowiązanych do posiadania systemów ciągłego monitorowania sieci i raportowania incydentów do właściwych zespołów CSIRT.

  • Podział na podmioty kluczowe i ważne: Objęcie regulacjami sektorów energii, transportu, bankowości, zdrowia, infrastruktury cyfrowej oraz dostawców ICT
  • Ścisły harmonogram powiadomień (Art. 23): Obowiązek wysłania wczesnego ostrzeżenia do CSIRT w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie
  • Pełne zgłoszenie w 72 godziny: Szczegółowy opis incydentu, jego skutków oraz wstępnych wskaźników kompromitacji wyekstrahowanych z logów
  • Kary finansowe i odpowiedzialność zarządu: Kary do 10 mln EUR lub 2% rocznego globalnego obrotu za brak adekwatnych systemów detekcji i nadzoru nad bezpieczeństwem
CSIRT Poziomu Krajowego w Polsce: Incydenty w ramach ustawy o KSC są raportowane do właściwego zespołu w zależności od sektora: CSIRT NASK (operatorzy cyfrowi i biznes), CSIRT GOV (administracja państwowa) lub CSIRT MON (sektor obronny).
Wymogi raportowania NIS 2 Harmonogram raportowania incydentu według Dyrektywy NIS 2 Wykrycie t0 Identyfikacja: • Alert w SIEM • Przełamanie zapór • Triage incydentu Start zegara: Początek biegu terminów NIS 2 24 Godziny Wczesne ostrzeżenie: • Zgłoszenie do CSIRT • Czy incydent wynika z działania celowego • Wpływ transgraniczny Rola logów: Dowód wykrycia i skali awarii 72 Godziny Oficjalny raport: • Wstępna ocena strat • Skutki dla usług • Wskaźniki IoC Rola logów: Ekstrakcja IoC z przepływów NetFlow 1 Miesiąc Raport końcowy: • Przyczyna źródłowa • Wdrożona naprawa • Koszty i wnioski Rola logów: Pełny audyt forensic trail
Slajd 44/55
Prawo komunikacji elektronicznej (PKE 2024) i retencja danych
Cel slajdu: Przedstawienie regulacji ustawy Prawo komunikacji elektronicznej z 2024 r. dotyczących obowiązkowej retencji logów transmisyjnych przez operatorów sieci.

Analiza incydentów, regulacje i laboratoria

Ustawa Prawo komunikacji elektronicznej zastąpiła dotychczasowe Prawo telekomunikacyjne, precyzując zasady zatrzymywania i zabezpieczania danych o połączeniach teleinformatycznych.

  • Ustawowy obowiązek retencji danych (art. 47 ust. 1 pkt 1 PKE): Przedsiębiorcy telekomunikacyjni są zobowiązani zatrzymywać i przechowywać dane transmisyjne przez 12 miesięcy, licząc od dnia połączenia lub nieudanej próby połączenia
  • Rozróżnienie metadanych i treści (Content vs Metadata): Retencji podlegają wyłącznie dane transmisyjne (IP, porty, czas trwania, MAC); zatrzymywanie treści komunikatów jest bezwzględnie zabronione
  • Zabezpieczenie przed dostępem nieuprawnionym: Magazyny logów retencyjnych muszą być szyfrowane i odizolowane od reszty sieci korporacyjnej
  • Procedura niszczenia danych po 12 miesiącach: Po upływie ustawowego okresu retencji dane muszą zostać trwale i nieodwracalnie usunięte z nośników
Udostępnianie logów organom ścigania: Dostęp do danych retencyjnych może nastąpić wyłącznie na pisemny lub elektroniczny wniosek sądu, prokuratury lub uprawnionych służb na zasadach określonych w ustawie. Każde zapytanie musi być odnotowane w rejestrze dostępu.
Retencja danych PKE 2024 Zasady retencji danych telekomunikacyjnych według PKE 2024 Zakres retencji (Art. 47 PKE) Dane transmisyjne: • Identyfikatory zakończenia sieci (IP, MAC) • Data, godzina i czas trwania sesji • Adresy IP źródłowe i docelowe w sesji • Porty i protokoły warstwy transportowej Czego NIE wolno zatrzymywać: • Treści przekazu telekomunikacyjnego • Treści e-maili i przesyłanych plików Tajemnica komunikacji: Ochrona konstytucyjna i ustawowa Wymogi techniczne retencji 1. Okres zatrzymywania danych: • 12 miesięcy od dnia połączenia lub próby połączenia • Po tym okresie: bezwzględny obowiązek zniszczenia 2. Bezpieczeństwo i integralność: • Składowanie w wydzielonych repozytoriach • Szyfrowanie bazy danych retencyjnych • Rejestracja każdego dostępu uprawnionych osób 3. Udostępnianie uprawnionym organom: • Sądy, prokuratura, służby państwowe (Policja, ABW) Ustawa z 12 lipca 2024 r. (Dz.U. 2024 poz. 1221)
Slajd 45/55
Standard PCI DSS v4.0: Wymóg 10 – Rejestracja i audyt dostępu
Cel slajdu: Przedstawienie rygorystycznych wymagań standardu PCI DSS v4.0 dotyczących logowania w infrastrukturze przetwarzającej dane kart płatniczych.

Analiza incydentów, regulacje i laboratoria

Standard bezpieczeństwa branży kart płatniczych (PCI DSS) w Wymogu 10 precyzuje zasady logowania każdego dostępu do środowiska Cardholder Data Environment (CDE).

  • Rejestracja działań administracyjnych (10.2.1.2): Każda zmiana uprawnień, logowanie na konto uprzywilejowane (root/admin) i uruchomienie poleceń konfiguracyjnych musi generować ślad audytowy
  • Szczegółowość rekordu audytowego (10.2.2): Każdy wpis musi zawierać tożsamość użytkownika, datę i czas z dokładnością mikrosekundową, typ zdarzenia, wskaźnik sukces/porażka oraz źródło
  • Ochrona i kopia centralna (10.3.3 – 10.3.4): Natychmiastowe przesyłanie logów na bezpieczny serwer centralny oraz monitorowanie integralności plików FIM w celu wykrywania zmian
  • Codzienny przegląd i retencja (10.4.1 i 10.5.1): Obowiązkowy codzienny przegląd logów z CDE; retencja przez min. 12 miesięcy, w tym co najmniej 90 dni w trybie natychmiastowego przeszukiwania
Wymóg FIM w PCI DSS v4.0 (10.3.4): Standard nakazuje stosowanie oprogramowania monitorującego integralność plików dzienników (File Integrity Monitoring). Każda próba modyfikacji lub usunięcia pliku z logami musi wywołać natychmiastowy alert w centrum operacji bezpieczeństwa (SOC).
Wymóg 10 PCI DSS v4.0 Standard PCI DSS v4.0: Kluczowe zasady Wymogu 10 Rejestracja zdarzeń (10.2) Zdarzenia podlegające rejestracji: • Dostęp do danych posiadaczy kart (10.2.1.1) • Wszelkie działania kont root / admin (10.2.1.2) • Dostęp do dzienników audytowych (10.2.1.3) • Nieudane próby uwierzytelnienia (10.2.1.4) • Użycie mechanizmów uwierzytelniania (10.2.1.5) • Start i zatrzymanie demona logów (10.2.1.6) Wymóg 10.2.2: ID użytkownika, data, typ zdarzenia, sukces/błąd Ochrona i inspekcja (10.3 - 10.5) 1. Ochrona i integralność (10.3): • Kopia logów na bezpieczny serwer centralny (10.3.3) • Narzędzia FIM monitorujące integralność (10.3.4) 2. Codzienny przegląd logów (10.4): • Obowiązkowa codzienna analiza logów z CDE (10.4.1) • Badanie anomalii i wyjątków (10.4.2) 3. Czas retencji (10.5.1): • Minimum 3 miesiące: natychmiastowa dostępność (Hot) • Minimum 12 miesięcy: archiwum dostępne do analizy PCI Security Standards Council v4.0
Slajd 46/55
Opracowanie formalnej polityki logowania zdarzeń w organizacji
Cel slajdu: Przedstawienie struktury, kluczowych sekcji i zasad tworzenia wewnętrznej polityki zarządzania logami zdarzeń (Log Management Policy).

Analiza incydentów, regulacje i laboratoria

Polityka logowania to nadrzędny dokument organizacyjny regulujący kto, co, gdzie i przez jaki czas rejestruje w infrastrukturze przedsiębiorstwa.

  • Zakres i klasyfikacja źródeł: Precyzyjne zdefiniowanie urządzeń podlegających logowaniu oraz minimalnych poziomów ważności komunikatów
  • Podział obowiązków (Segregation of Duties): Administrator zarządzający serwerem nie może posiadać uprawnień do edycji ani usuwania logów z tego serwera na centralnym kolektorze
  • Matryca retencji danych: Określenie czasu składowania logów w podziale na warstwy (Hot, Warm, Cold) zgodnie z wymogami RODO, PKE i PCI DSS
  • Procedury kontroli i testów odtworzeniowych: Okresowe testy weryfikujące kompletność zbieranych zdarzeń, poprawność sum kontrolnych oraz czas reakcji na alarmy
Zasada podwójnej kontroli (Four-Eyes Principle): Dostęp do archiwalnych logów zawierających wrażliwe dane lub operacja ich przedterminowego usunięcia musi wymagać autoryzacji przez dwóch uprawnionych pracowników (np. Administratora Bezpieczeństwa oraz Inspektora IOD).
Struktura polityki logowania Struktura formalnej polityki logowania zdarzeń w organizacji 1. Zakres podmiotowy i urządzenia • Ewidencja wszystkich węzłów (CMDB / SoT) • Minimalne poziomy Severity dla urządzeń • Zakaz wyłączania logowania przez adminów Zasada: 100% krytycznych węzłów pod nadzorem 2. Transport i synchronizacja czasu • Obowiązek szyfrowania TLS (RFC 5425) poza LAN • Serwery NTP Stratum-1 z redundancją • Standard ISO 8601 dla znaczników czasu Zasada: Spójność czasowa i poufność 3. Polityka retencji (Cykl życia) • Magazyn Hot: 90 dni (Elastic/OpenSearch) • Magazyn Cold: 12 miesięcy (S3 Glacier / WORM) • Certyfikowane niszczenie po okresie retencji Zasada: Balans kosztów, prawa i bezpieczeństwa 4. Podział ról i uprawnień (RBAC) • Inżynier Sieci: konfiguracja nadajników • Administrator SIEM: utrzymanie platformy • Analityk SOC: codzienna inspekcja i triage Zasada: Rozdział obowiązków (Segregation of Duties)
Slajd 47/55
Laboratorium 1: Wdrożenie centralnego serwera rsyslog na Ubuntu 24.04 LTS
Cel slajdu: Praktyczne wdrożenie centralnego kolektora logów rsyslog odbierającego strumienie UDP i TCP oraz segregującego pliki w strukturze katalogowej.

Analiza incydentów, regulacje i laboratoria

W ramach pierwszego ćwiczenia studenci konfigurują demon rsyslog na dystrybucji Ubuntu 24.04 LTS w celu stworzenia niezawodnego serwera odbiorczego dla całej sieci.

  • Aktywacja modułów `imudp` oraz `imtcp`: Włączenie równoległego nasłuchu na porcie 514 dla protokołów bezpołączeniowych i połączeniowych
  • Bezpieczny szablon dynamiczny (DynaFile): Tworzenie podkatalogów na podstawie adresu IP nadawcy (`%fromhost-ip%`) oraz plików według bieżącej daty
  • Ochrona przed Path Traversal (`secpath-drop`): W przypadku użycia `%HOSTNAME%` konieczna jest opcja `secpath-drop`/`secpath-replace`; `%fromhost-ip%` uniemożliwia wstrzyknięcie fałszywej ścieżki i podszywanie
  • Instrukcja warunkowa i słowo kluczowe `stop`: Odseparowanie zdarzeń sieciowych od lokalnych logów serwera (`/var/log/syslog`) za pomocą `& stop`
Prawa do katalogów i ochrona ścieżek: Demon rsyslog w Ubuntu działa z uprawnieniami użytkownika `syslog` i grupy `adm`. Upewnij się, że katalog docelowy posiada odpowiednie prawa (`chown syslog:adm /var/log/remote/`). Stosowanie `%fromhost-ip%` zamiast nagłówkowego `%HOSTNAME%` chroni przed atakami Directory Traversal (np. przesłaniem `../../etc/`).
Laboratorium: rsyslog Ubuntu Laboratorium 1: Konfiguracja serwera rsyslog (Ubuntu 24.04) # 1. Konfiguracja nasłuchu w /etc/rsyslog.d/10-central-server.conf: module(load="imudp") # Załadowanie modułu UDP input(type="imudp" port="514") module(load="imtcp") # Załadowanie modułu TCP input(type="imtcp" port="514") # 2. Bezpieczny szablon dynaFile (IP źródłowe chroni przed podszywaniem): template(name="RemoteDeviceLog" type="string" string="/var/log/remote/%fromhost-ip%/%$YEAR%-%$MONTH%-%$DAY%.log") if ($fromhost-ip != '127.0.0.1') then { action(type="omfile" dynaFile="RemoteDeviceLog" CreateDirs="on") stop } # 3. Zastosowanie konfiguracji i weryfikacja otwartych portów: $ sudo systemctl restart rsyslog $ ss -tulpn | grep 514 # Oczekiwany nasłuch na udp/514 i tcp/514
Slajd 48/55
Laboratorium 2: Zdalne logowanie zdarzeń w MikroTik RouterOS
Cel slajdu: Skonfigurowanie podsystemu logowania w routerze MikroTik RouterOS v7 w celu automatycznego wysyłania zdarzeń bezpieczeństwa i zapory sieciowej do serwera centralnego.

Analiza incydentów, regulacje i laboratoria

RouterOS dysponuje modułowym mechanizmem logowania opartym o akcje i tematy. W tym laboratorium konfigurujemy przekazywanie zdarzeń z prefixami ułatwiającymi filtrację.

  • Tworzenie akcji `remote` w RouterOS: Wskazanie adresu IP serwera rsyslog, portu 514, adresu źródłowego interfejsu zarządzania oraz facility `local0`
  • Konfiguracja reguł tematów (`topics`): Skierowanie do akcji zdalnej zdarzeń uwierzytelniania (`account`), pakietów odrzuconych przez firewall (`firewall,info`) oraz alertów krytycznych (`critical`)
  • Zastosowanie prefixów tekstowych: Dodanie przedrostków takich jak `MT-AUTH` i `MT-FW-DROP` umożliwiających błyskawiczne parsowanie regułami w Wazuh lub Graylog
  • Praktyczny test transmisji: Wymuszenie błędnego logowania SSH na routerze i natychmiastowa weryfikacja zapisu w pliku dziennika na serwerze rsyslog
Ograniczenie obciążenia łącz logami zapory: Reguły firewalla na routerze MikroTik odrzucające skany mogą wygenerować tysiące pakietów na sekundę. Zawsze stosuj opcję `log-prefix` oraz ograniczanie częstości w regułach (`limit` lub `psd`) przed aktywacją `action=log`.
Laboratorium: Syslog MikroTik Laboratorium 2: Zdalne logowanie w MikroTik RouterOS v7 # 1. Definicja akcji zdalnego logowania (Remote Action): /system logging action add name=central-syslog target=remote \ remote=192.168.10.50 remote-port=514 \ src-address=192.168.10.1 syslog-facility=local0 syslog-severity=auto # 2. Przekierowanie kluczowych tematów (Topics) do centrali: /system logging add action=central-syslog topics=account prefix="MT-AUTH" add action=central-syslog topics=firewall,info prefix="MT-FW-DROP" add action=central-syslog topics=critical prefix="MT-CRIT" # 3. Testowanie i weryfikacja odbioru po stronie serwera Linux: # Wywołanie błędnego logowania na routerze, a następnie na serwerze: $ tail -f /var/log/remote/192.168.10.1/2026-09-29.log Sep 29 10:15:22 192.168.10.1 MT-AUTH: user admin login failure from 10.0.0.105 via ssh
Slajd 49/55
Laboratorium 3: Zaawansowana analiza logów z wykorzystaniem potoków CLI
Cel slajdu: Opanowanie technik szybkiej analizy śledczej (Incident Forensics) i agregacji danych z plików logów przy użyciu standardowych narzędzi systemu Linux.

Analiza incydentów, regulacje i laboratoria

Zanim logi trafią do indeksów bazy danych lub w sytuacji awarii panelu graficznego, biegła znajomość uniksowych potoków pozwala inżynierowi ustalić przebieg incydentu w kilka sekund.

  • Filtrowanie i selekcja wzorców (`grep` / `ripgrep`): Wyszukiwanie krytycznych fraz takich jak `Failed password`, `DROP` czy `unauthorized` w wielogigabajtowych plikach
  • Wycinanie i przetwarzanie kolumn (`awk`): Precyzyjne wyodrębnianie pól adresów IP (`$(NF-3)`), nazw użytkowników oraz znaczników czasu
  • Agregacja statystyczna (`sort | uniq -c | sort -nr`): Zliczanie powtórzeń, identyfikacja najaktywniejszych agresorów oraz tworzenie rankingów Top-N
  • Grupowanie czasowe: Analiza dynamiki ataku z podziałem na godziny lub minuty pozwalająca na określenie momentu rozpoczęcia kampanii złośliwego oprogramowania
Wydajność przeszukiwania logów: Dla bardzo dużych plików (powyżej 10 GB) warto stosować narzędzie ripgrep (komenda rg) zamiast standardowego grep. Wykorzystuje ono zoptymalizowane przetwarzanie wielowątkowe i instrukcje SIMD procesora.
Laboratorium: Analiza potokami CLI Laboratorium 3: Analiza śledcza logów z potokami Linux CLI # Zadanie 1: Wykrycie 5 najaktywniejszych adresów atakujących SSH: $ grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' \ | sort | uniq -c | sort -nr | head -n 5 1420 198.51.100.44 890 203.0.113.89 312 192.0.2.15 # Zadanie 2: Rozkład nieudanych logowań w ujęciu godzinnym: $ grep "Failed password" /var/log/auth.log | awk '{print $1, $2, substr($3,1,2)}' \ | uniq -c 450 Sep 29 08 # Spokojny poranek 3820 Sep 29 09 # SZCZYT ATAKU: Wykryto atak brute-force! # Zadanie 3: Najczęściej atakowane nazwy kont użytkowników: $ grep "Failed password for invalid user" /var/log/auth.log \ | awk '{print $(NF-5)}' | sort | uniq -c | sort -nr | head -n 3 2100 admin | 1450 test | 980 root
Slajd 50/55
Laboratorium 4: Wdrożenie szyfrowania Syslog over TLS (RFC 5425)
Cel slajdu: Skonfigurowanie bezpiecznego, szyfrowanego kanału przesyłania logów w oparciu o protokół TLS i certyfikaty cyfrowe X.509 zgodnie ze standardem RFC 5425.

Analiza incydentów, regulacje i laboratoria

Przesyłanie logów otwartym tekstem przez sieci publiczne lub WAN niesie ryzyko podsłuchu i modyfikacji. Standard RFC 5425 definiuje szyfrowanie Sysloga z wykorzystaniem protokołu TLS.

  • Instalacja modułu `rsyslog-gnutls`: Dołączenie do silnika rsyslog bibliotek kryptograficznych GnuTLS obsługujących szyfrowanie strumieniowe
  • Uwierzytelnienie wzajemne (mTLS): Weryfikacja certyfikatu serwera przez klienta oraz autoryzacja tożsamości klienta na podstawie jego certyfikatu i nazwy CN
  • Port IANA TCP 6514 dla Syslog-TLS: Otwarcie dedykowanego portu sieciowego przeznaczonego wyłącznie dla zabezpieczonego protokołu RFC 5425
  • Walidacja połączenia za pomocą `openssl s_client`: Test poprawności łańcucha certyfikatów, wersji protokołu TLS 1.3 oraz bezpiecznych zestawów szyfrów
Ochrona przed Man-in-the-Middle (MitM): Opcja StreamDriverPermittedPeers wymusza ścisłą weryfikację nazwy domenowej wystawcy certyfikatu. Nawet jeśli napastnik podstawi własny certyfikat wystawiony przez inne CA, połączenie zostanie natychmiast zerwane.
Laboratorium: Syslog over TLS Laboratorium 4: Szyfrowany transport logów TLS (RFC 5425) # 1. Konfiguracja Serwera rsyslog z modułem GTLS (/etc/rsyslog.d/20-tls.conf): global( DefaultNetstreamDriver="gtls" DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca-chain.crt" DefaultNetstreamDriverCertFile="/etc/rsyslog-keys/server.crt" DefaultNetstreamDriverKeyFile="/etc/rsyslog-keys/server.key" ) module(load="imtcp" StreamDriver.Name="gtls" StreamDriver.Mode="1" StreamDriver.Authmode="x509/name") input(type="imtcp" port="6514" name="tcp-tls") # Standaryzowany port IANA RFC 5425 # 2. Konfiguracja Klienta (Przesyłanie szyfrowane do serwera): action(type="omfwd" protocol="tcp" target="syslog.firma.pl" port="6514" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="syslog.firma.pl") # 3. Weryfikacja handshake TLS z poziomu wiersza poleceń: $ openssl s_client -connect syslog.firma.pl:6514 -CAfile /etc/ssl/certs/ca-chain.crt Verification: OK | Protocol: TLSv1.3 | Cipher: TLS_AES_256_GCM_SHA384
Slajd 51/55
Laboratorium 5: Integracja centralnego Sysloga z panelem LibreNMS
Cel slajdu: Zintegrowanie strumienia logów systemowych z bazą danych i interfejsem graficznym LibreNMS w celu korelacji zdarzeń z metrykami SNMP.

Analiza incydentów, regulacje i laboratoria

Połączenie systemu monitorowania SNMP z rejestracją logów w jednym panelu LibreNMS daje administratorom pełny obraz stanu infrastruktury sieciowej w czasie rzeczywistym.

  • Aktywacja modułu Syslog w LibreNMS: Włączenie obsługi poleceniem `lnms config:set enable_syslog true` oraz zdefiniowanie retencji czyszczenia (`syslog_purge`)
  • Dedykowany szablon 8 pól (`t_librenms`): Parser LibreNMS wymaga formatu z 8 polami rozdzielonymi `||` (host, IP, facility, priority, severity, tag, timestamp, msg)
  • Przekierowanie przez moduł `omprog`: Przesyłanie przetworzonych rekordów do skryptu `/opt/librenms/syslog.php` oraz zatrzymanie reguły instrukcją `& stop`
  • Korelacja i reguły alertowe: Automatyczne mapowanie adresu IP nadawcy na rekord w tabeli `devices` oraz wyzwalanie reguł alertowych (Alert Rules)
Wymóg szablonu 8-polowego w LibreNMS: Skrypt `syslog.php` rozbija każdą linię separatorem `||` na dokładnie 8 atrybutów. Zastosowanie domyślnego szablonu liniowego (np. `RSYSLOG_TraditionalFileFormat`) uniemożliwia sparsowanie komunikatu i skutkuje brakiem jakichkolwiek wpisów w bazie danych! Pamiętaj o dodaniu & stop, aby rsyslog nie duplikował logu w lokalnych plikach.
Laboratorium: Integracja LibreNMS Laboratorium 5: Integracja rsyslog z bazą i panelem LibreNMS # 1. Aktywacja modułu Syslog w konfiguracji LibreNMS: $ lnms config:set enable_syslog true $ lnms config:set syslog_purge 30 # Czyszczenie wpisów po 30 dniach # 2. Szablon z 8 polami i rurociąg omprog (/etc/rsyslog.d/30-librenms.conf): template(name="t_librenms" type="string" string="%FROMHOST%||%FROMHOST-IP%||%syslogfacility%||%syslogpriority%||%syslogseverity%||%syslogtag%||%$year%-%$month%-%$day% %timegenerated:8:15%||%msg:::sp-if-no-1st-sp%%msg%\n") module(load="omprog") action(type="omprog" binary="/opt/librenms/syslog.php" template="t_librenms") & stop # Zakończenie dalszego przetwarzania przekazanego logu # 3. Weryfikacja zapisu w bazie danych MariaDB: $ mysql -u librenms -p librenms -e "SELECT seq, device_id, program, msg FROM syslog ORDER BY seq DESC LIMIT 2;" | 8401 | 12 | BGP | %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down | # 4. Automatyczna reguła alertu w LibreNMS (Alert Rule): Reguła: syslog.msg LIKE '%DOWN%' AND syslog.program = 'LINEPROTO' Akcja: Natychmiastowe wysłanie alertu Webhook na kanał Slack/Teams!
Slajd 52/55
Laboratorium 6: Tworzenie reguł detekcji incydentów w Wazuh SIEM
Cel slajdu: Zaprojektowanie i wdrożenie wielopoziomowej reguły korelacyjnej w formacie XML w systemie Wazuh SIEM w celu detekcji ataku brute-force na urządzenia Cisco.

Analiza incydentów, regulacje i laboratoria

Wazuh wykorzystuje hierarchiczny silnik reguł oparty na strukturze XML. W tym laboratorium studenci budują własną regułę reagującą na powtarzające się zdarzenia w oknie czasowym.

  • Dopasowanie dekodera (`decoded_as`): Powiązanie surowego komunikatu z wbudowanym dekoderem przełączników sieciowych `cisco-ios`
  • Reguła bazowa (`id 100051`): Rejestracja pojedynczego zdarzenia o niskiej wadze (poziom 4), stanowiącego element składowy korelacji
  • Agregacja czasowa (`frequency` i `timeframe`): Definicja warunku wyzwalającego alert poziomu 10, gdy zdarzenie powtórzy się 5 razy w ciągu 60 sekund
  • Mapowanie do MITRE ATT&CK (`<mitre><id>T1110</id></mitre>`): Automatyczne przypisanie techniki T1110 (Brute Force) w dashboardzie analitycznym SOC
Walidacja narzędziem `wazuh-logtest`: Przed wdrożeniem reguły na środowisku produkcyjnym należy zawsze przetestować ją narzędziem `wazuh-logtest`. Pozwala ono prześledzić krok po kroku dopasowanie do dekodera, ekstrakcję pól oraz wyzwolone identyfikatory reguł.
Laboratorium: Reguły Wazuh SIEM Laboratorium 6: Wdrażanie reguły korelacyjnej w Wazuh SIEM # 1. Definicja reguły w pliku /var/ossec/etc/rules/local_rules.xml: <group name="cisco,network_security,"> <!-- Reguła bazowa: pojedyncza próba błędnego logowania na przełącznik --> <rule id="100051" level="4"> <decoded_as>cisco-ios</decoded_as> <match>%SEC_LOGIN-4-LOGIN_FAILED</match> <description>Cisco IOS: Nieudane logowanie użytkownika</description> </rule> <!-- Reguła korelacyjna: Ponad 5 prób w 60 sekund z tego samego IP --> <rule id="100052" level="10" frequency="5" timeframe="60"> <if_matched_sid>100051</if_matched_sid> <same_source_ip /> <description>Atak Brute-Force na urządzenie sieciowe!</description> <mitre><id>T1110</id></mitre> </rule> </group> # Test reguły: /var/ossec/bin/wazuh-logtest <<< "%SEC_LOGIN-4-LOGIN_FAILED: Login failed..."
Slajd 53/55
Słownik najważniejszych pojęć – Moduł 6
Cel slajdu: Usystematyzowanie i utrwalenie 10 najważniejszych terminów technicznych oraz regulacyjnych związanych z logowaniem zdarzeń i audytem sieci.

Podsumowanie, słownik i weryfikacja wiedzy

Poniższy słownik stanowi kompendium terminologiczne z zakresu protokołów telemetrycznych, systemów analitycznych oraz norm cyberbezpieczeństwa.

  • Standardy protokołu: Precyzyjne rozróżnienie pomiędzy formatem nagłówka Syslog (RFC 5424), wagą Severity (0-7), kategorią Facility (0-23) oraz wartością PRI
  • Architektura niezawodności: Zastosowanie protokołu RELP eliminujące utratę zdarzeń podczas awarii sieci lub restartu serwera docelowego
  • Platformy analityczne SIEM i FIM: Rola ciągłej korelacji logów oraz monitorowania integralności plików w wykrywaniu zaawansowanych zagrożeń
  • Ramy prawne i retencyjne: Praktyczne implikacje Dyrektywy NIS 2, ustawy PKE 2024 oraz technologii niezmienności danych WORM
Standard terminologiczny: Poprawne posługiwanie się pojęciami Severity i Facility jest wymagane podczas konfiguracji zapór sieciowych, routerów brzegowych oraz przygotowywania raportów audytowych ISO 27001.
Słownik pojęć modułu 6 Słownik 10 kluczowych pojęć – Moduł 6 1. Syslog (RFC 5424) Standaryzowany protokół rejestracji zdarzeń ze strukturą nagłówka. 2. Severity (Poziom istotności) Waga incydentu w skali od 0 (Emergency) do 7 (Debug). 3. Facility (Kategoria źródła) Identyfikator podsystemu generującego log (kody od 0 do 23). 4. Wartość PRI (Priority Value) Liczbowa reprezentacja ważności wyliczana jako (Facility * 8) + Severity. 5. Protokół RELP Protokół niezawodnego transportu logów z potwierdzeniami warstwy aplikacji. 6. SIEM (Security Information & Event Management) System centralizacji, normalizacji i korelacji zdarzeń w czasie rzeczywistym. 7. FIM (File Integrity Monitoring) Narzędzie śledzenia zmian w plikach z weryfikacją sum kryptograficznych. 8. Pamięć WORM (Write Once, Read Many) Technologia zapisu gwarantująca fizyczną niezmienność plików audytowych. 9. Dyrektywa NIS 2 Unijne prawo nakładające obowiązek monitoringu i 24h zgłaszania incydentów. 10. Retencja danych telekomunikacyjnych Ustawowy wymóg (PKE 2024) przechowywania logów transmisyjnych przez 12 miesięcy.
Slajd 54/55
Pytania kontrolne i zagadnienia problemowe
Cel slajdu: Sprawdzenie stopnia opanowania wiedzy inżynierskiej, umiejętności obliczeniowych oraz znajomości ram regulacyjnych z zakresu logowania i bezpieczeństwa.

Podsumowanie, słownik i weryfikacja wiedzy

Odpowiedzi na poniższe pytania problemowe pozwalają ocenić gotowość studentów do projektowania i eksploatacji bezpiecznych systemów zbierania logów.

  • Kalkulacja wartości PRI: Znajomość wzoru `PRI = (Facility * 8) + Severity` oraz umiejętność dekodowania nagłówków binarnych w strumieniach sieciowych
  • Architektura odporna na awarie: Wskazanie przewag protokołów RELP i Syslog TLS nad przestarzałą transmisją UDP 514
  • Wymogi formalno-prawne Dyrektywy NIS 2: Precyzyjne określenie terminów zgłoszeń (24h / 72h / 1 miesiąc) w cyklu raportowania incydentów do CSIRT
  • Status prawny adresu IP w świetle orzecznictwa TSUE: Rozróżnienie podstaw prawnych przetwarzania logów oraz stosowanie technik pseudonimizacji zgodnie z RODO
Zadanie praktyczne dla studentów: Zaprojektuj regułę rsyslog filtrującą komunikaty o wadze error i wyższej, wysyłając je szyfrowanym tunelem TLS do klastra SOC, a pozostałe zapisując wyłącznie do lokalnego archiwum rotowanego co 7 dni.
Pytania kontrolne Pytania kontrolne i weryfikacja wiedzy inżynierskiej Pytanie 1: Wartość PRI w Syslogu Jaka jest wartość PRI dla komunikatu z Facility local4 (20) i Severity Warning (4)? Odpowiedź: PRI = 164 (20 * 8) + 4 = 160 + 4 = 164 (kod: <164>) Pytanie 2: Ograniczenia UDP 514 Dlaczego UDP 514 jest niewystarczający i jakie protokoły rozwiązują jego wady? Odpowiedź: Brak ACK, spoofing IP, brak TLS Rozwiązanie: Syslog TLS (RFC 5425) oraz RELP Pytanie 3: Terminy zgłoszeń w NIS 2 W jakim czasie podmiot kluczowy musi wysłać wczesne ostrzeżenie do właściwego CSIRT? Odpowiedź: 24 godziny Kolejno: 72h pełny raport, 1 miesiąc końcowy Pytanie 4: Status adresu IP w RODO Czy dynamiczny adres IP w logach to dana osobowa zgodnie z wyrokiem TSUE Breyer? Odpowiedź: TAK, stanowi daną osobową Podstawa logowania: Prawnie uzasadniony interes
Slajd 55/55
Źródła wiedzy, normy międzynarodowe i literatura
Cel slajdu: Przedstawienie oficjalnych specyfikacji IETF RFC, norm międzynarodowych, dokumentacji technicznych oraz aktów prawnych regulujących logowanie zdarzeń.

Podsumowanie, słownik i weryfikacja wiedzy

Wszystkie prezentowane procedury, formaty nagłówków oraz konfiguracje bazują na obowiązujących standardach międzynarodowych i oficjalnej dokumentacji projektów open-source.

  • IETF RFC 5424 i RFC 5425: Podstawowe dokumenty standaryzujące strukturę protokołu Syslog oraz szyfrowany transport TLS
  • IETF RFC 5848 (Signed Syslog): Specyfikacja mechanizmu kryptograficznego podpisywania bloków komunikatów zapewniająca niezaprzeczalność
  • NIST Special Publication 800-61 Rev. 3: Przewodnik po obsłudze incydentów komputerowych wydany przez National Institute of Standards and Technology (zastępujący wersję Rev. 2)
  • Oficjalne dokumentacje narzędzi: Podręczniki konfiguracyjne systemów rsyslog, Wazuh SIEM, LibreNMS oraz wytyczne CIS Controls v8
Kluczowe linki do materiałów źródłowych:
• IETF RFC 5424: RFC 5424 Syslog Protocol
• IETF RFC 5425: RFC 5425 TLS Transport for Syslog
• IETF RFC 5848: RFC 5848 Signed Syslog
• NIST SP 800-61 Rev. 3: NIST Incident Response Recommendations
• Dokumentacja rsyslog: rsyslog documentation
• Dokumentacja Wazuh: Wazuh SIEM Documentation
• CIS Controls v8: CIS Controls List
Standardy i literatura Oficjalne źródła, standardy IETF i literatura Standardy IETF i Wytyczne NIST • IETF RFC 5424: The Syslog Protocol (Podstawowy standard) • IETF RFC 5425: Transport Layer Security (TLS) Transport • IETF RFC 5848: Signed Syslog Messages (Integralność) • NIST SP 800-61 Rev. 3: Incident Response Recommendations (CSWP) Internet Engineering Task Force Oficjalne dokumenty RFC Dokumentacja i Regulacje • Silnik rsyslog v8: Podręcznik konfiguracji RainerScript i modułów • Platforma Wazuh SIEM/XDR: Architektura klastrowa, dekodery i reguły XML • Dyrektywa NIS 2 (UE 2022/2555): Środki zarządzania ryzykiem w cyberbezpieczeństwie • Prawo komunikacji elektronicznej: Ustawa z 12 lipca 2024 r. (Dz.U. 2024 poz. 1221) Center for Internet Security (CIS) CIS Controls v8: Control 8 Log Management
← Poprzednia prezentacja Następna prezentacja →