Monitorowanie sieci - Prezentacja 6: Logowanie i bezpieczeństwo (Wersja 10h)

Cel slajdu: Przedstawienie roli centralnego logowania zdarzeń w sieciach teleinformatycznych, standardu protokołu Syslog oraz uwarunkowań bezpieczeństwa i audytu.

Rejestracja zdarzeń jako fundament audytu i bezpieczeństwa

Ciągła rejestracja dzienników zdarzeń (logów) to nieodzowny element inżynierii bezpieczeństwa sieci, umożliwiający rekonstrukcję incydentów, wykrywanie ataków oraz spełnienie wymogów prawnych.

Zakres modułu: Protokół Syslog (RFC 5424), demon rsyslog, składnia RainerScript, zdalne logowanie z MikroTik RouterOS i Cisco IOS
Architektura centralizacji: Bezpieczny transport TLS (RFC 5425), niezawodny protokół RELP, dynamiczne szablony i segregacja per host
Systemy SIEM i XDR: Platforma Wazuh, korelacja zdarzeń, reguły detekcji incydentów oraz metodyka reagowania według NIST SP 800-61
Zgodność z prawem i normami: Wymogi normy ISO/IEC 27001:2022, rozporządzenia RODO, dyrektywy NIS 2, ustawy o KSC oraz standardu PCI DSS v4.0

Log zdarzeń (Dziennik systemowy): Chronologiczny, niezmienny zapis informacji o zdarzeniach systemowych, błędach, próbach uwierzytelnienia oraz zmianach stanu urządzeń sieciowych.

Cel slajdu: Przedstawienie struktury zagadnień modułu szóstego dedykowanego logowaniu zdarzeń, systemom rsyslog i SIEM oraz zgodności z regulacjami prawnymi.

Układ materiału i plan wykładu

Materiał obejmuje pełny cykl życia logu sieciowego: od formatu ramki RFC 5424, przez konfigurację centralnego serwera rsyslog i urządzeń aktywnych, po analitykę SIEM i audyt prawny.

Blok 1: Protokół Syslog i demon rsyslog: Architektura, format RFC 5424, kalkulacja priorytetu PRI, konfiguracja rsyslog, RainerScript i szablony dynamiczne
Blok 2: Bezpieczny transport i urządzenia sieciowe: Syslog over TLS, protokół RELP, logowanie z MikroTik RouterOS (Topics/Prefixes), Cisco IOS i Linux journald
Blok 3: Analiza, retencja i integracje: Trójwarstwowa architektura, ELK/Graylog, integracja z LibreNMS, rotacja logrotate i polityka retencji danych
Blok 4: Bezpieczeństwo, SIEM i normy prawne: Integralność logów, architektura Wazuh SIEM, NIST SP 800-61, ISO 27001, RODO, NIS 2, KSC oraz PCI DSS v4.0

Plan dydaktyczny modułu 6: Opanowanie zasad bezpiecznego projektowania, zbierania, przechowywania, analizy i ochrony prawnej logów w środowiskach teleinformatycznych.

Cel slajdu: Zrozumienie czterech głównych celów gromadzenia logów oraz poznanie architektury przepływu zdarzeń od nadawcy do centralnego repozytorium.

Cztery filary logowania i topologia klient-serwer

Lokalne przechowywanie logów w pamięci ulotnej urządzeń (RAM bufor) jest zawodne; restart urządzenia lub celowe działanie intruza bezpowrotnie niszczy ślady.

Cztery cele logowania: 1. Diagnostyka awarii (Troubleshooting); 2. Wykrywanie incydentów bezpieczeństwa (Security); 3. Rozliczalność działań administratorów (Accountability); 4. Zgodność z prawem i normami (Compliance)
Ewolucja protokołu Syslog: Od nieformalnego protokołu BSD (RFC 3164, 2001) do dojrzałego standardu IETF (RFC 5424, 2009)
Role w architekturze Syslog: Nadawca (Device / Originator) generujący komunikat; Przekaźnik (Relay) buforujący i forwardujący; Odbiorca/Kolektor (Collector / Receiver) zapisujący logi
Zasada natychmiastowej transmisji: Komunikat Syslog jest emitowany niezwłocznie w momencie wystąpienia zdarzenia, zanim potencjalny intruz zdąży zatrzeć ślady na urządzeniu

Centralny serwer logów (Syslog Collector): Dedykowany, zabezpieczony serwer sieciowy odbierający, parsujący i indeksujący strumienie komunikatów zdarzeń przesyłane ze wszystkich urządzeń w sieci.

Cel slajdu: Szczegółowa analiza ustrukturyzowanego formatu komunikatu zdefiniowanego w standardzie RFC 5424.

Anatomia komunikatu według nowoczesnego standardu IETF

Specyfikacja RFC 5424 zastąpiła archaiczny format BSD precyzyjną, ustrukturyzowaną ramką gwarantującą jednoznaczne parsowanie znaczników czasu i danych.

Segment PRI: Liczba całkowita w nawiasach ostrokątnych <PRI> kodująca źródło i wagę komunikatu
Wersja protokołu (VERSION): Cyfra 1 wskazująca zgodność ze standardem RFC 5424
Precyzyjny znacznik czasu (TIMESTAMP): Format ISO 8601 / RFC 3339 z dokładnością do mikrosekund i strefą czasową: 2026-10-01T14:32:05.123456+02:00
Metadane nadawcy: HOSTNAME (nazwa lub IP urządzenia), APP-NAME (nazwa procesu), PROCID (identyfikator PID), MSGID (typ zdarzenia)
Dane ustrukturyzowane (STRUCTURED-DATA): Bloki [id_elementu klucz="wartość"] pozwalające na bezbłędne parsowanie parametrów przez systemy analityczne

Standard RFC 5424: Oficjalny standard IETF The Syslog Protocol definiujący nowoczesny, ustrukturyzowany format zapisu komunikatów zdarzeń sieciowych i systemowych.

Cel slajdu: Opanowanie algorytmu wyliczania wartości priorytetu PRI oraz interpretacji kodów Facility i Severity.

Matematyczna reprezentacja ważności i pochodzenia zdarzenia

Wartość PRI umieszczana na początku każdego komunikatu Syslog to pojedyncza liczba całkowita będąca wynikiem operacji bitowej łączącej źródło zdarzenia z jego powagą.

Kody źródeł (Facility Codes 0–23): Identyfikują podsystem: kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), local0-local7 (16-23) powszechnie używane przez sprzęt sieciowy
Poziomy dotkliwości (Severity Levels 0–7): 0: Emergency (awaria krytyczna), 1: Alert, 2: Critical, 3: Error, 4: Warning, 5: Notice (normalne zdarzenie), 6: Informational, 7: Debug
Wzór na kalkulację PRI: PRI = (Facility * 8) + Severity; operacja odpowiada przesunięciu bitowemu: (Facility << 3) | Severity
Przykład rachunkowy: Zdarzenie local0 (16) o poziomie Warning (4) daje priorytet: 16 * 8 + 4 = 132; w nagłówku pojawi się <132>

Wartość PRI (Priority): Liczba całkowita w nagłówku Syslog determinująca wagę i podsystem zdarzenia, wykorzystywana przez serwery rsyslog do filtrowania i routingu logów.

Cel slajdu: Poznanie budowy wewnętrznej demona rsyslog oraz opanowanie klasycznej składni selektorów i akcji.

Modułowa architektura przetwarzania logów w Linuksie

Demon rsyslog (Rocket-fast System for Log Processing) to domyślny, wysoce wydajny serwer logowania w większości dystrybucji Linuksa, zdolny przetwarzać ponad milion zdarzeń na sekundę.

Potok przetwarzania rsyslog: Moduły wejściowe (Input Modules: imuxsock, imklog, imudp, imtcp) => Silnik reguł (Ruleset / Filter) => Moduły wyjściowe (Output Modules: omfile, omfwd, ommysql)
Plik konfiguracyjny /etc/rsyslog.conf: Główny plik konfiguracyjny; dołączanie dyrektywą $IncludeConfig /etc/rsyslog.d/*.conf
Klasyczne selektory: Konstrukcja facility.severity akcja; np. auth,authpriv.* /var/log/auth.log
Modyfikatory ważności: Gwiazdka * (wszystkie poziomy), średnik ; (separator reguł), słowo kluczowe none (wykluczenie danego podsystemu)

Demon rsyslog: Zaawansowany, wielowątkowy demon logowania w systemach uniksowych oferujący modularną budowę, buforowanie pamięciowo-dyskowe oraz zaawansowane filtrowanie komunikatów.

Cel slajdu: Nauczenie się konfiguracji rsyslog jako centralnego kolektora sieciowego oraz automatycznej segregacji logów do osobnych plików per urządzenie.

Włączenie nasłuchu sieciowego i szablony dynamicznych ścieżek dynaFile

Wrzucanie logów ze wszystkich przełączników i routerów do jednego pliku prowadzi do chaosu; mechanizm dynamicznych szablonów rsyslog automatycznie tworzy katalogi na podstawie IP nadawcy.

Włączenie modułów sieciowych: Załadowanie modułu UDP module(load="imudp") i uruchomienie nasłuchu input(type="imudp" port="514"); analogicznie moduł imtcp
Szablony dynamiczne (Templates): Zdefiniowanie wzorca ścieżki pliku: template(name="RemoteHost" type="string" string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")
Automatyczna segregacja (dynaFile): Zastosowanie akcji: action(type="omfile" dynaFile="RemoteHost"); rsyslog tworzy podkatalogi per host i pliki per dzień
Formatowanie wpisów: Wymuszenie formatu zgodnego z RFC 5424: template(name="RSYSLOG_SyslogProtocol23Format" ...)

Szablon dynaFile (rsyslog): Funkcja generowania dynamicznych ścieżek plików na dysku w oparciu o zmienne wyciągnięte z nagłówka komunikatu (np. nazwa hosta, data).

Cel slajdu: Opanowanie programistycznej składni RainerScript, mechanizmów buforowania odpornych na awarie oraz protokołu RELP.

Struktury warunkowe, kolejki buforowe Disk-Assisted i protokół RELP

Nowoczesna konfiguracja rsyslog opiera się na języku RainerScript, pozwalającym na tworzenie złożonych bloków warunkowych if-then-else i buforowanie danych w przypadku awarii sieci.

Składnia RainerScript: Nowoczesny styl konfiguracyjny; operatory logiczne, wyrażenia regularne: if ($fromhost-ip startswith '10.99.') and ($msg contains 'FAIL') then { ... }
Kolejki buforowe (Queues): Buforowanie komunikatów w pamięci RAM z automatycznym zrzutem na dysk (Disk-Assisted Queue) w przypadku niedostępności serwera docelowego
Ograniczenia Syslog over TCP: Zerwanie sesji TCP podczas transmisji może spowodować utratę pakietów będących w locie bez powiadomienia nadawcy
Protokół RELP (RFC-less Reliable Event Logging Protocol): Otwarty protokół warstwy aplikacji gwarantujący dostarczenie każdego logu (At-Least-Once Delivery) dzięki potwierdzeniom na poziomie sesji

Protokół RELP: Niezawodny protokół transportowy dla logów systemowych eliminujący utratę pakietów przy awariach sieci lub restartach serwerów kolektora.

Cel slajdu: Przedstawienie standardu kryptograficznej ochrony strumienia zdarzeń oraz wdrożenia uwierzytelniania w oparciu o certyfikaty X.509.

Poufność i integralność transmisji logów w standardzie RFC 5425

Standardowy protokół Syslog (UDP/TCP 514) przesyła logi otwartym tekstem; logi zawierają nazwy użytkowników, adresy IP i próby haseł, co wymusza stosowanie szyfrowania TLS.

Specyfikacja RFC 5425: Standard IETF definiujący enkapsulację protokołu Syslog wewnątrz szyfrowanego kanału TLS na dedykowanym porcie TCP 6514
Uwierzytelnianie dwustronne (mTLS): Zarówno serwer logów, jak i urządzenie sieciowe weryfikują swoje certyfikaty X.509 wystawione przez zaufane centrum certyfikacji (Internal CA)
Ochrona przed podsłuchem i manipulacją: Całkowite wyeliminowanie ryzyka podsłuchu wrażliwych danych w tranzycie oraz wstrzykiwania sfałszowanych logów (Log Forgery)
Konfiguracja sterownika gtls w rsyslog: Dyrektywy DefaultNetstreamDriverCAFile, DefaultNetstreamDriverCertFile oraz DefaultNetstreamDriverKeyFile

Syslog over TLS (RFC 5425): Znormalizowany protokół bezpiecznego przesyłania zdarzeń zapewniający szyfrowanie asymetryczne, integralność transmisji oraz uwierzytelnianie stron certyfikatami X.509.

Cel slajdu: Opanowanie konfiguracji podsystemu logowania w MikroTik RouterOS z podziałem na tematy i prefiksy zapory ogniowej.

Struktura Topics, akcje zdalne i prefiksy reguł Firewall w RouterOS

MikroTik RouterOS posiada unikalny podsystem logowania oparty na tematach (topics), umożliwiający precyzyjne sterowanie, jakie zdarzenia mają trafiać do centralnego serwera rsyslog.

Definicja akcji zdalnej (/system logging action): Utworzenie akcji typu remote: /system logging action add name=central-syslog target=remote remote=10.99.0.10 remote-port=514 src-address=10.99.0.1
Filtrowanie według tematów (/system logging): Powiązanie tematów (topics: firewall, critical, warning, account, ospf) ze zdefiniowaną akcją zdalną
Prefiksy zapory ogniowej (Log-Prefix): Dodanie parametru log=yes log-prefix="FW-DROP-IN:" w regułach filtru; umożliwia natychmiastowe parsowanie i analizę ataków w rsyslog
Zgodność formatu: Możliwość wyboru protokołu BSD Syslog (RFC 3164) lub kompatybilności z formatem Syslog RFC 5424

Temat (Topic w RouterOS): Kategoria zdarzenia w systemie MikroTik określająca jego kontekst operacyjny (np. system, firewall, wireless, dhcp, ipsec).

Cel slajdu: Przedstawienie procedur wdrożenia zdalnego logowania na urządzeniach Cisco oraz integracji jądra Linuksa i demona systemd-journald z serwerem rsyslog.

Format komunikatów Cisco IOS i integracja journald w Linuksie

Infrastruktura korporacyjna wymaga ujednolicenia zbierania logów ze sprzętu transmisyjnego Cisco oraz systemów operacyjnych serwerów Linux.

Konfiguracja Cisco IOS: logging host 10.99.0.10; logging trap notifications (poziom Severity 5); logging facility local6
Precyzja znaczników czasu w Cisco: service timestamps log datetime msec show-timezone – bezwzględny wymóg dodawania milisekund do logów
Stos logowania w systemie Linux: Demon systemd-journald gromadzi logi binarne z jądra i usług systemd; moduł imjournal lub gniazdo /run/systemd/journal/syslog przekazuje je do rsyslog
Ujednolicenie formatów: Centralny serwer rsyslog konwertuje specyficzne znaczniki Cisco (np. %LINK-3-UPDOWN) do ustandaryzowanego rekordu bazy danych

Demon systemd-journald: Usługa systemowa nowoczesnych dystrybucji Linuksa zbierająca i indeksująca komunikaty jądra i usług w binarnych plikach dziennika (journal).

Cel slajdu: Zrozumienie wielkoskalowej architektury przetwarzania logów oraz poznanie platform analitycznych klasy Big Data.

Akwizycja, indeksacja i analityka: platformy Graylog i ELK

W dużych środowiskach korporacyjnych (tysiące zdarzeń na sekundę) tradycyjne pliki tekstowe są niewystarczające; logi trafiają do klastrów wyszukiwawczych Elasticsearch lub OpenSearch.

Trzy warstwy przetwarzania: 1. Akwizycja i buforowanie (rsyslog / Kafka); 2. Indeksowanie i parsowanie (Logstash / Graylog Server); 3. Wyszukiwanie i wizualizacja (OpenSearch / Kibana)
Platforma Graylog: Wyspecjalizowane środowisko Open Source zorientowane na logi; wbudowany silnik reguł (Pipelines), zarządzanie strumieniami (Streams) oraz obsługa formatu GELF
Stos ELK / OpenSearch: Elastyczny ekosystem oparty na silniku Lucene; błyskawiczne przeszukiwanie terabajtów logów z wykorzystaniem zapytań pełnotekstowych
Format GELF (Graylog Extended Log Format): Nowoczesny format JSON eliminujący ograniczenia długości pola komunikatu i kompresujący dane przesyłane przez sieć

Stos OpenSearch / ELK: Rozproszony silnik wyszukiwania i analityki danych zorientowany na indeksowanie dokumentów JSON, wykorzystywany do wielkoskalowej analizy logów.

Cel slajdu: Przedstawienie metod integracji strumienia logów Syslog z interfejsem graficznym systemów LibreNMS i The Dude.

Konsolidacja telemetrii i dzienników w jednym panelu NMS

Wyświetlanie logów bezpośrednio w oknie szczegółów urządzenia w systemie NMS przyspiesza diagnozowanie usterek i ułatwia weryfikację wpływu rekonfiguracji na stan łączy.

Tabela syslog w LibreNMS: Demon syslog-ng / rsyslog zapisuje sparsowane komunikaty bezpośrednio do bazy MariaDB LibreNMS
Wyszukiwanie w LibreNMS GUI: Zakładka 'Syslog' w karcie każdego urządzenia; filtrowanie według programów, poziomu ważności oraz słów kluczowych
Reguły alarmowe na logach: Możliwość stworzenia reguły w LibreNMS wyzwalającej alert po pojawieniu się logu o określonym wzorcu (np. 'BGP Neighbor Down')
Logi w The Dude: Konfiguracja serwera Syslog wbudowanego w The Dude; logi wyświetlane w dedykowanej zakładce z powiązaniem do ikon na mapie

Korelacja logów w LibreNMS: Mechanizm automatycznego przypisywania przychodzących komunikatów Syslog do właściwych węzłów w bazie NMS na podstawie adresu IP nadawcy.

Cel slajdu: Opanowanie zaawansowanych potoków wiersza poleceń do analizy plików logów oraz konfiguracji automatycznej rotacji i kompresji.

Potoki CLI (grep, awk, sed) oraz cykliczna rotacja z logrotate

Zdolność błyskawicznej analizy logów w terminalu za pomocą standardowych narzędzi uniksowych to kluczowa umiejętność inżyniera sieciowego w sytuacji awarii.

Filtrowanie i potoki CLI: Śledzenie na żywo: tail -f /var/log/syslog | grep --line-buffered 'DROP'; agregacja statystyczna poleceniem awk '{print $5}' | sort | uniq -c | sort -nr
Wyrażenia regularne (Regex): Precyzyjne dopasowywanie wzorców adresów IP, kodów błędów i identyfikatorów sesji za pomocą grep -E lub sed
Narzędzie logrotate (/etc/logrotate.d/): Automatyczna archiwizacja; parametry daily, rotate 30, kompresja compress (gzip) oraz opcja delaycompress
Zapobieganie awariom dysku: Dyrektywy maxsize 500M i missingok chroniące partycję /var/log przed całkowitym zapełnieniem

Narzędzie logrotate: Usługa systemowa Linuksa realizująca automatyczną rotację, kompresję, usuwanie i wysyłkę zarchiwizowanych plików dzienników systemowych.

Cel slajdu: Zrozumienie zasad projektowania polityki retencji logów z uwzględnieniem kosztów pamięci masowej i wymogów prawnych.

Cykl życia logu i zrównoważona retencja danych

Przechowywanie wszystkich logów w nieskończoność jest niemożliwe z powodów technicznych i kosztowych, a często również nielegalne w świetle przepisów o ochronie prywatności.

Fazy cyklu życia logu: 1. Gorąca (Hot) – szybki zapis i bieżąca analiza (SSD); 2. Ciepła (Warm) – rzadkie wyszukiwanie (HDD); 3. Zimna (Cold/Archive) – skompresowane archiwum offline
Okresy retencji według krytyczności: Logi diagnostyczne debug: 7–14 dni; logi zdarzeń firewall/system: 3–6 miesięcy; logi uwierzytelniania i audytu: 1–5 lat
Kompresja i deduplikacja: Skompresowane archiwa logów tekstowych (gzip/zstd) osiągają stopień kompresji rzędu 90–95%, drastycznie redukując koszty macierzy
Bezpieczne niszczenie danych: Procedury bezpowrotnego usuwania przeterminowanych logów zgodnie z polityką bezpieczeństwa informacji

Polityka retencji logów: Formalny dokument określający, jak długo poszczególne kategorie dzienników zdarzeń muszą być przechowywane, gdzie archiwizowane i kiedy niszczone.

Cel slajdu: Przedstawienie technik ochrony serwerów logów przed atakami, zacieraniem śladów oraz fałszowaniem wpisów.

Wektory ataków, niezaprzeczalność i ochrona przed manipulacją

Dla napastnika zacieranie śladów w logach to kluczowy etap ataku; infrastruktura logowania musi być zaprojektowana tak, aby uniemożliwić modyfikację zarejestrowanych zdarzeń.

Wektory zagrożeń: Ataki DoS na serwer logów (zalew fałszywymi pakietami UDP), modyfikacja plików przez intruza z uprawnieniami roota, podsłuch transmisji (Eavesdropping)
Architektura WORM (Write Once, Read Many): Zapis logów na nośnikach uniemożliwiających modyfikację lub nadpisanie raz zapisanych bloków danych
Podpisy kryptograficzne i łańcuchy skrótów: Narzędzie LogSignature w rsyslog; każdy wpis zawiera kryptograficzny skrót (hash) powiązany z wpisem poprzednim (Blockchain-like)
Izolacja serwera kolektora: Dedykowana maszyna z restrykcyjnymi uprawnieniami, wyłączonym dostępem przez SSH z sieci ogólnej i logowaniem audytowym dostępu

Właściwość Tamper-Evidence: Cecha systemu logowania gwarantująca, że każda próba modyfikacji, skasowania lub wstrzyknięcia fałszywego wpisu zostanie natychmiast wykryta.

Cel slajdu: Poznanie zaleceń Center for Internet Security w zakresie logowania oraz procedur audytu zmian konfiguracji w sieci LAN.

Wytyczne CIS Benchmark i wykrywanie nieautoryzowanych rekonfiguracji

Większość awarii w sieciach korporacyjnych nie wynika z wad sprzętu, lecz z błędów lub nieautoryzowanych zmian w konfiguracji wprowadzanych przez personel techniczny.

Standard CIS Network Devices Benchmark: Zbiór rygorystycznych zaleceń: obowiązek wysyłki logów do minimum dwóch niezależnych serwerów, rejestracja każdej sesji CLI
Rejestracja komend konfiguracyjnych: Konfiguracja serwerów TACACS+ / RADIUS rejestrujących każde polecenie wpisane przez administratora wraz z tożsamością i znacznikiem czasu
Audyt zmian z narzędziem Oxidized: Natychmiastowe wykrycie różnic (diff) w konfiguracji przełącznika; generowanie alertu Syslog o wykryciu modyfikacji
Zasada czterech oczu: Wymóg akceptacji krytycznych zmian konfiguracji sieci szkieletowej przez drugiego inżyniera

Config Auditing (Audyt konfiguracji): Ciągły proces rejestrowania i analizowania wszystkich zmian wprowadzanych w konfiguracji urządzeń aktywnych w celu zapewnienia rozliczalności.

Cel slajdu: Przedstawienie roli systemów klasy SIEM/XDR w nowoczesnym centrum bezpieczeństwa oraz architektury otwartoźródłowej platformy Wazuh.

Korelacja zdarzeń bezpieczeństwa i architektura platformy Wazuh

Zwykły serwer Syslog jedynie gromadzi pliki; system klasy SIEM analizuje strumienie logów w czasie rzeczywistym, wykrywając złożone scenariusze ataków.

Rola systemu SIEM (Security Information and Event Management): Centralizacja logów, normalizacja, korelacja wieloźródłowa i automatyczne alarmowanie o incydentach
Architektura platformy Wazuh: Otwartoźródłowy system SIEM/XDR; komponenty: Wazuh Agent (serwery), Wazuh Server (silnik analityczny) oraz Wazuh Indexer / Dashboard
Bezagencyjny odbiór logów sieciowych: Wazuh Server odbiera strumienie Syslog z przełączników i routerów, parsuje je za pomocą dekoderów XML i dopasowuje do reguł detekcji
Automatyczna reakcja (Active Response): Możliwość automatycznego zablokowania adresu IP atakującego na zaporze ogniowej po wykryciu ataku brute-force

System SIEM: Zintegrowana platforma cyberbezpieczeństwa gromadząca i korelująca zdarzenia z całej infrastruktury IT w celu natychmiastowej identyfikacji zagrożeń.

Cel slajdu: Poznanie reguł detekcji popularnych ataków sieciowych oraz znormalizowanego cyklu reagowania na incydenty komputerowe.

Sygnatury ataków w logach i czterofazowy cykl reakcji NIST

Standard NIST SP 800-61 Rev. 2 definiuje uniwersalną metodykę postępowania z incydentami bezpieczeństwa w organizacji.

Przykłady sygnatur w logach: Atak Brute-Force (dziesiątki zdarzeń 'authentication failure' w ciągu sekund); Skanowanie portów (lawina wpisów 'FW-DROP' z jednego IP)
Faza 1: Przygotowanie (Preparation): Wdrożenie centralnego logowania, procedur operacyjnych, narzędzi analitycznych i przeszkolenie zespołu CSIRT
Faza 2: Detekcja i analiza (Detection & Analysis): Identyfikacja symptomów naruszenia bezpieczeństwa w logach SIEM, ocena skali i kwalifikacja incydentu
Faza 3: Powstrzymanie, usunięcie i odzyskanie (Containment, Eradication & Recovery): Izolacja zainfekowanego segmentu VLAN, usunięcie zagrożenia i przywrócenie usług
Faza 4: Działania poincydentalne (Post-Incident Activity): Analiza wyciągniętych wniosków (Lessons Learned), modyfikacja reguł detekcji i aktualizacja dokumentacji

Cykl NIST SP 800-61: Znormalizowany przez amerykański Narodowy Instytut Standardów i Technologii model zarządzania incydentem komputerowym obejmujący cztery powiązane fazy.

Cel slajdu: Przedstawienie wymogów normy ISO 27001 oraz zasad legalnego przetwarzania danych telemetrycznych w świetle europejskiego rozporządzenia RODO.

Kontrole normatywne ISO 27001 i wymogi prywatności RODO

Prowadzenie logowania zdarzeń jest obowiązkowe w świetle norm bezpieczeństwa, jednak musi odbywać się z poszanowaniem prywatności użytkowników i ochrony danych osobowych.

Norma ISO/IEC 27001:2022 (Punkt A.8.15 - Rejestrowanie zdarzeń): Bezwzględny wymóg rejestrowania aktywności użytkowników, wyjątków, błędów i incydentów bezpieczeństwa
Punkt A.8.16 (Monitorowanie aktywności): Obowiązek ciągłego nadzoru nad sieciami, systemami i aplikacjami pod kątem anomalii i zagrożeń
Adresy IP jako dane osobowe w RODO/GDPR: Zgodnie z wyrokiem TSUE (sprawa C-582/14 Breyer), dynamiczne adresy IP stanowią dane osobowe podlegające ochronie
Zasady legalnego przetwarzania: Zasada minimalizacji danych (zbieranie tylko niezbędnych parametrów), ograniczenie dostępu (RBAC) oraz obowiązek pseudonimizacji

Kontrola A.8.15 (ISO/IEC 27001:2022): Znormalizowany wymóg tworzenia, ochrony i okresowego przeglądania dzienników zdarzeń rejestrujących aktywność w systemach teleinformatycznych.

Cel slajdu: Przegląd krajowych i europejskich aktów prawnych nakładających obowiązek centralnego logowania i retencji danych.

Krajowy i europejski porządek prawny w obszarze cyberbezpieczeństwa

Współczesny inżynier sieciowy musi znać ramy prawne determinujące obowiązki w zakresie monitorowania, raportowania incydentów oraz retencji danych.

Dyrektywa NIS 2 (UE 2022/2555): Zaostrzenie wymogów dla podmiotów kluczowych i ważnych; obowiązek wdrożenia środków zarządzania ryzykiem, audytu i szybkiego zgłaszania incydentów (w ciągu 24h)
Ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC): Implementacja dyrektyw unijnych w prawie polskim; obowiązek ciągłego monitorowania zagrożeń i współpracy z właściwymi zespołami CSIRT (NASK, GOV, MON)
Prawo komunikacji elektronicznej (PKE 2024): Ustawa z 12 lipca 2024 r. (Dz.U. 2024 poz. 1221); obowiązek retencji danych transmisyjnych przez operatorów telekomunikacyjnych przez 12 miesięcy na potrzeby uprawnionych organów
Standard PCI DSS v4.0 (Wymóg 10): Rygorystyczny standard branży płatniczej: codzienna inspekcja logów, synchronizacja NTP, ochrona przed modyfikacją oraz retencja minimum 1 rok

Ustawa o KSC: Fundamentalny polski akt prawny określający organizację krajowego systemu cyberbezpieczeństwa, obowiązki operatorów usług kluczowych oraz zasady obsługi incydentów.

Cel slajdu: Podsumowanie wiedzy z zakresu logowania i bezpieczeństwa, utrwalenie terminologii oraz weryfikacja kompetencji.

Leksykon pojęciowy modułu 6, pytania kontrolne i bibliografia

Zakończenie całego cyklu wykładów; student posiada kompletną wiedzę od fundamentów diagnostyki sieciowej, przez protokół SNMP i platformy NMS, po logowanie i cyberbezpieczeństwo.

Pytania sprawdzające: 1. Wylicz wartość PRI dla zdarzenia local7 o wadze Critical (2). 2. W jaki sposób szablon dynaFile w rsyslog organizuje logi per host? 3. Czym różni się Syslog over TLS (RFC 5425) od klasycznego Sysloga UDP?
Zadania laboratoryjne: 1. Skonfiguruj centralny serwer rsyslog na Ubuntu z nasłuchem UDP/TCP 514; 2. Skonfiguruj zdalne logowanie w MikroTik RouterOS z prefiksem zapory; 3. Sprawdź rotację logów w logrotate
Słownik pojęć: Syslog, RFC 5424, Facility, Severity, PRI, rsyslog, RainerScript, RELP, RFC 5425, SIEM, Wazuh, NIST SP 800-61, ISO 27001, RODO, NIS 2, KSC, PKE
Źródła normatywne: RFC 5424 (Syslog Protocol), RFC 5425 (TLS for Syslog), ISO/IEC 27001:2022, NIST SP 800-61 Rev. 2, Dyrektywa NIS 2 (UE 2022/2555)

Kompetencje modułu 6: Zdolność do samodzielnego zaprojektowania, wdrożenia, zabezpieczenia i audytowania centralnej infrastruktury logowania zdarzeń sieciowych zgodnie z międzynarodowymi normami i polskim prawem.