Syslog to standard i protokół, który pozwala urządzeniom i aplikacjom wysyłać komunikaty o zdarzeniach (logi) do jednego, centralnego miejsca — tzw. kolektora. Każdy komunikat opisuje pojedyncze zdarzenie i zawiera m.in. wartość PRI (kodującą źródło i wagę zdarzenia), znacznik czasu, identyfikator hosta i samą treść. Syslog powstał w latach 80. jako część projektu Sendmail (autorstwa Erica Allmana). Przez lata był standardem de facto, a później spisano go w dokumentach IETF: RFC 3164 (2001, tzw. BSD syslog) oraz RFC 5424 (2009, nowszy, uporządkowany format).
Jak zbudowany jest komunikat syslog?
Komunikat syslog ma trzy części: nagłówek PRI, część opisową (HEADER) i treść (MSG). Najważniejszy jest PRI — liczba w nawiasach ostrych na początku, np. <34>. Koduje ona jednocześnie dwie rzeczy: facility (skąd pochodzi komunikat) i severity (jak jest pilny). Liczy się to prostym wzorem:
- PRI = facility × 8 + severity — np.
<34>to facility 4 (security/authorization) i severity 2 (Critical).
Facility mówi, jaki podsystem nadał komunikat. Przyjmuje wartości 0–23 — m.in. kern = 0, user = 1, mail = 2, daemon = 3, auth/security = 4, a także local0–local7 = 16–23 do własnych zastosowań. Severity określa wagę zdarzenia w skali 0–7. Im niższa liczba, tym pilniejsze zdarzenie:
- 0 — Emergency: system nie działa
- 1 — Alert: trzeba zareagować natychmiast
- 2 — Critical: stan krytyczny
- 3 — Error: błąd
- 4 — Warning: ostrzeżenie
- 5 — Notice: coś istotnego, ale normalnego
- 6 — Informational: zwykła informacja
- 7 — Debug: szczegóły diagnostyczne
Czym różni się RFC 3164 od RFC 5424?
Oba dokumenty opisują ten sam świat syslog, ale różnią się formatem komunikatu i precyzją:
- RFC 3164 (BSD syslog) — dokument opisowy, nie normatywny. Spisał to, co już istniało. Znacznik czasu w formacie
Mmm dd hh:mm:ss(bez roku i strefy czasowej), prosta nazwa hosta, znacznik aplikacji z PID i swobodna treść. Brak strefy czasowej i niska precyzja czasu utrudniają łączenie logów z różnych źródeł. - RFC 5424 — właściwy, normatywny standard. Wprowadza znacznik czasu zgodny z
ISO 8601 / RFC 3339(z milisekundami i strefą czasową), pełną nazwę hosta (FQDN), polaAPP-NAME,PROCID,MSGIDoraz sekcję structured data (pary klucz–wartość w nawiasach kwadratowych). Dzięki temu komunikaty łatwiej przetwarzać maszynowo. Standard wymaga też kodowania UTF-8.
W praktyce wiele urządzeń sieciowych nadal wysyła format zbliżony do RFC 3164, a nowsze systemy i kolektory wolą RFC 5424. To, że treść komunikatu nie ma jednego formatu, jest jednym z głównych problemów przy ujednolicaniu logów.
Jak syslog jest przesyłany przez sieć? (porty i transport)
Syslog działa w modelu klient–serwer: nadawca (urządzenie, demon) wysyła komunikaty do kolektora (serwera syslog). Można to zrobić na kilka sposobów:
- UDP, port 514 — najstarszy i wciąż domyślny transport. Lekki i szybki, ale bezpołączeniowy i zawodny. Nie ma potwierdzeń odbioru, więc przy przeciążeniu lub utracie pakietów komunikaty mogą po cichu zniknąć.
- TCP, port 514 — transport połączeniowy, bardziej niezawodny, z mechanizmem zwalniania nadawcy przy przeciążeniu (back-pressure). Sposób dzielenia komunikatów na ramki opisuje
RFC 6587(octet-counting lub non-transparent framing). - TLS, port 6514 — syslog szyfrowany zgodnie z
RFC 5425(TLS, czyli Transport Layer Security). Zapewnia poufność, integralność i potwierdzenie tożsamości stron za pomocą certyfikatów. Zalecany, gdy logi idą przez sieci, którym nie ufasz, oraz tam, gdzie obowiązują wymogi zgodności. - RELP / RFC 3195 — mechanizmy gwarantujące dostarczenie: RELP (rozwinięty w rsyslog) potwierdza odbiór komunikatów kanałem zwrotnym, a RFC 3195 opisuje dostarczanie oparte na BEEP.
Jakie są popularne implementacje syslog?
Po stronie systemu syslog obsługują demony, które zbierają, filtrują i przekazują dalej komunikaty:
- rsyslog — domyślny demon w wielu dystrybucjach Linuksa. Obsługuje TCP, TLS, zapis do baz danych, filtrowanie, przekazywanie do kolektorów i protokół RELP.
- syslog-ng — elastyczny demon z rozbudowanym filtrowaniem, transportem TCP/TLS i kierowaniem komunikatów do różnych celów.
- syslogd / klasyczne implementacje oraz NXLog i inne agenty służące do zbierania i przekazywania logów, także z systemów spoza świata uniksowego.
Jaki jest związek syslog z SIEM i zarządzaniem logami?
Syslog to jeden z podstawowych sposobów dostarczania danych do systemów log management oraz SIEM (Security Information and Event Management — zarządzanie informacjami i zdarzeniami bezpieczeństwa). Urządzenia sieciowe, zapory, serwery i aplikacje wysyłają komunikaty do centralnego kolektora, który je ujednolica, indeksuje i łączy ze sobą. Uporządkowany strumień logów (zwłaszcza w RFC 5424) ułatwia ich przetwarzanie, pisanie reguł wykrywania i wyłapywanie anomalii. Centralne zbieranie logów ma też znaczenie dla audytu i zgodności z regulacjami (np. PCI DSS, HIPAA, SOX), które wymagają przechowywania i ochrony zapisów zdarzeń.
Dlaczego syslog jest ważny dla bezpieczeństwa i jakie ma ograniczenia?
Logi syslog to dowód dla zespołów SOC oraz dla monitoringu sieci i wykrywania zagrożeń (NDR). Sam protokół ma jednak kilka ograniczeń istotnych dla bezpieczeństwa:
- Brak uwierzytelniania i szyfrowania w UDP — w wariancie UDP/plaintext nie da się sprawdzić, kto naprawdę wysłał komunikat, ani ochronić jego treści. Otwiera to drogę do spoofingu (podszywania się pod źródło) oraz wstrzykiwania spreparowanych wpisów, które zaśmiecają logi i mylą analityków.
- Brak gwarancji dostarczenia (UDP) — przy przeciążeniu komunikaty mogą przepaść, a wraz z nimi dowody. Atakujący może celowo zalać system tysiącami logów (log-flooding), żeby przykryć ślady prawdziwego incydentu.
- Podmiana i kasowanie logów lokalnych — napastnik, który dostał się na host, może zmienić lub usunąć logi, zanim zostaną wysłane. Dlatego ważne jest szybkie, ciągłe przesyłanie ich do osobnego, zabezpieczonego kolektora.
- Brak jednego formatu treści — luźna część MSG utrudnia przetwarzanie maszynowe i może ukryć dane ważne dla wykrywania zagrożeń.
Jak ograniczyć to ryzyko w praktyce: używać TLS (RFC 5425, port 6514) lub niezawodnych mechanizmów (TCP, RELP), wydzielać i filtrować ruch na porcie 514, chronić kolektor przed manipulacją oraz pilnować samego strumienia logów. Przerwa w napływie spodziewanych komunikatów też bywa sygnałem incydentu.
Dowiedz się więcej
- ARP Spoofing – jak wykryć atak Man-in-the-Middle i zatruwanie ARP w sieci LAN — Syslog pomaga korelować zdarzenia ARP z innymi logami przy wykrywaniu MITM.
- Czym jest NetFlow i jak ten protokół jest wykorzystywany w praktyce? — Syslog uzupełnia NetFlow o szczegóły zdarzeń z urządzeń i systemów.
- Architektura Zero Trust – rola widoczności sieci i mikrosegmentacji w bezpieczeństwie — Syslog dostarcza zdarzeń do kontroli dostępu i weryfikacji zasad Zero Trust.
