{"id":4836,"date":"2026-08-11T20:59:14","date_gmt":"2026-08-11T18:59:14","guid":{"rendered":"https:\/\/www.sycope.com\/?post_type=dictionary-item&#038;p=4836"},"modified":"2026-08-11T22:47:00","modified_gmt":"2026-08-11T20:47:00","slug":"syslog","status":"publish","type":"dictionary-item","link":"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/syslog","title":{"rendered":"Syslog"},"content":{"rendered":"<p><strong>Syslog<\/strong> to standard i protok\u00f3\u0142, kt\u00f3ry pozwala urz\u0105dzeniom i aplikacjom wysy\u0142a\u0107 komunikaty o zdarzeniach (logi) do jednego, centralnego miejsca \u2014 tzw. kolektora. Ka\u017cdy komunikat opisuje pojedyncze zdarzenie i zawiera m.in. warto\u015b\u0107 <code>PRI<\/code> (koduj\u0105c\u0105 \u017ar\u00f3d\u0142o i wag\u0119 zdarzenia), znacznik czasu, identyfikator hosta i sam\u0105 tre\u015b\u0107. Syslog powsta\u0142 w latach 80. jako cz\u0119\u015b\u0107 projektu Sendmail (autorstwa Erica Allmana). Przez lata by\u0142 standardem de facto, a p\u00f3\u017aniej spisano go w dokumentach IETF: <code>RFC 3164<\/code> (2001, tzw. BSD syslog) oraz <code>RFC 5424<\/code> (2009, nowszy, uporz\u0105dkowany format).<\/p>\n<h2>Jak zbudowany jest komunikat syslog?<\/h2>\n<p>Komunikat syslog ma trzy cz\u0119\u015bci: nag\u0142\u00f3wek <code>PRI<\/code>, cz\u0119\u015b\u0107 opisow\u0105 (HEADER) i tre\u015b\u0107 (MSG). Najwa\u017cniejszy jest <code>PRI<\/code> \u2014 liczba w nawiasach ostrych na pocz\u0105tku, np. <code>&lt;34&gt;<\/code>. Koduje ona jednocze\u015bnie dwie rzeczy: <strong>facility<\/strong> (sk\u0105d pochodzi komunikat) i <strong>severity<\/strong> (jak jest pilny). Liczy si\u0119 to prostym wzorem:<\/p>\n<ul>\n<li><strong>PRI = facility \u00d7 8 + severity<\/strong> \u2014 np. <code>&lt;34&gt;<\/code> to facility 4 (security\/authorization) i severity 2 (Critical).<\/li>\n<\/ul>\n<p>Facility m\u00f3wi, jaki podsystem nada\u0142 komunikat. Przyjmuje warto\u015bci <strong>0\u201323<\/strong> \u2014 m.in. <code>kern<\/code> = 0, <code>user<\/code> = 1, <code>mail<\/code> = 2, <code>daemon<\/code> = 3, <code>auth\/security<\/code> = 4, a tak\u017ce <code>local0<\/code>\u2013<code>local7<\/code> = 16\u201323 do w\u0142asnych zastosowa\u0144. Severity okre\u015bla wag\u0119 zdarzenia w skali <strong>0\u20137<\/strong>. Im ni\u017csza liczba, tym pilniejsze zdarzenie:<\/p>\n<ol>\n<li><strong>0 \u2014 Emergency<\/strong>: system nie dzia\u0142a<\/li>\n<li><strong>1 \u2014 Alert<\/strong>: trzeba zareagowa\u0107 natychmiast<\/li>\n<li><strong>2 \u2014 Critical<\/strong>: stan krytyczny<\/li>\n<li><strong>3 \u2014 Error<\/strong>: b\u0142\u0105d<\/li>\n<li><strong>4 \u2014 Warning<\/strong>: ostrze\u017cenie<\/li>\n<li><strong>5 \u2014 Notice<\/strong>: co\u015b istotnego, ale normalnego<\/li>\n<li><strong>6 \u2014 Informational<\/strong>: zwyk\u0142a informacja<\/li>\n<li><strong>7 \u2014 Debug<\/strong>: szczeg\u00f3\u0142y diagnostyczne<\/li>\n<\/ol>\n<h2>Czym r\u00f3\u017cni si\u0119 RFC 3164 od RFC 5424?<\/h2>\n<p>Oba dokumenty opisuj\u0105 ten sam \u015bwiat syslog, ale r\u00f3\u017cni\u0105 si\u0119 formatem komunikatu i precyzj\u0105:<\/p>\n<ul>\n<li><strong>RFC 3164 (BSD syslog)<\/strong> \u2014 dokument opisowy, nie normatywny. Spisa\u0142 to, co ju\u017c istnia\u0142o. Znacznik czasu w formacie <code>Mmm dd hh:mm:ss<\/code> (bez roku i strefy czasowej), prosta nazwa hosta, znacznik aplikacji z PID i swobodna tre\u015b\u0107. Brak strefy czasowej i niska precyzja czasu utrudniaj\u0105 \u0142\u0105czenie log\u00f3w z r\u00f3\u017cnych \u017ar\u00f3de\u0142.<\/li>\n<li><strong>RFC 5424<\/strong> \u2014 w\u0142a\u015bciwy, normatywny standard. Wprowadza znacznik czasu zgodny z <code>ISO 8601 \/ RFC 3339<\/code> (z milisekundami i stref\u0105 czasow\u0105), pe\u0142n\u0105 nazw\u0119 hosta (FQDN), pola <code>APP-NAME<\/code>, <code>PROCID<\/code>, <code>MSGID<\/code> oraz sekcj\u0119 <strong>structured data<\/strong> (pary klucz\u2013warto\u015b\u0107 w nawiasach kwadratowych). Dzi\u0119ki temu komunikaty \u0142atwiej przetwarza\u0107 maszynowo. Standard wymaga te\u017c kodowania UTF-8.<\/li>\n<\/ul>\n<p>W praktyce wiele urz\u0105dze\u0144 sieciowych nadal wysy\u0142a format zbli\u017cony do RFC 3164, a nowsze systemy i kolektory wol\u0105 RFC 5424. To, \u017ce tre\u015b\u0107 komunikatu nie ma jednego formatu, jest jednym z g\u0142\u00f3wnych problem\u00f3w przy ujednolicaniu log\u00f3w.<\/p>\n<h2>Jak syslog jest przesy\u0142any przez sie\u0107? (porty i transport)<\/h2>\n<p>Syslog dzia\u0142a w modelu klient\u2013serwer: nadawca (urz\u0105dzenie, demon) wysy\u0142a komunikaty do kolektora (serwera syslog). Mo\u017cna to zrobi\u0107 na kilka sposob\u00f3w:<\/p>\n<ul>\n<li><strong>UDP, port 514<\/strong> \u2014 najstarszy i wci\u0105\u017c domy\u015blny transport. Lekki i szybki, ale bezpo\u0142\u0105czeniowy i zawodny. Nie ma potwierdze\u0144 odbioru, wi\u0119c przy przeci\u0105\u017ceniu lub utracie pakiet\u00f3w komunikaty mog\u0105 po cichu znikn\u0105\u0107.<\/li>\n<li><strong>TCP, port 514<\/strong> \u2014 transport po\u0142\u0105czeniowy, bardziej niezawodny, z mechanizmem zwalniania nadawcy przy przeci\u0105\u017ceniu (back-pressure). Spos\u00f3b dzielenia komunikat\u00f3w na ramki opisuje <code>RFC 6587<\/code> (octet-counting lub non-transparent framing).<\/li>\n<li><strong><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/tls-ssl\">TLS<\/a>, port 6514<\/strong> \u2014 syslog szyfrowany zgodnie z <code>RFC 5425<\/code> (TLS, czyli Transport Layer Security). Zapewnia poufno\u015b\u0107, integralno\u015b\u0107 i potwierdzenie to\u017csamo\u015bci stron za pomoc\u0105 certyfikat\u00f3w. Zalecany, gdy logi id\u0105 przez sieci, kt\u00f3rym nie ufasz, oraz tam, gdzie obowi\u0105zuj\u0105 wymogi zgodno\u015bci.<\/li>\n<li><strong>RELP \/ RFC 3195<\/strong> \u2014 mechanizmy gwarantuj\u0105ce dostarczenie: RELP (rozwini\u0119ty w rsyslog) potwierdza odbi\u00f3r komunikat\u00f3w kana\u0142em zwrotnym, a RFC 3195 opisuje dostarczanie oparte na BEEP.<\/li>\n<\/ul>\n<h2>Jakie s\u0105 popularne implementacje syslog?<\/h2>\n<p>Po stronie systemu syslog obs\u0142uguj\u0105 demony, kt\u00f3re zbieraj\u0105, filtruj\u0105 i przekazuj\u0105 dalej komunikaty:<\/p>\n<ul>\n<li><strong>rsyslog<\/strong> \u2014 domy\u015blny demon w wielu dystrybucjach Linuksa. Obs\u0142uguje TCP, TLS, zapis do baz danych, filtrowanie, przekazywanie do <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/collector-kolektor\">kolektor<\/a>\u00f3w i protok\u00f3\u0142 RELP.<\/li>\n<li><strong>syslog-ng<\/strong> \u2014 elastyczny demon z rozbudowanym filtrowaniem, transportem TCP\/TLS i kierowaniem komunikat\u00f3w do r\u00f3\u017cnych cel\u00f3w.<\/li>\n<li><strong>syslogd \/ klasyczne implementacje<\/strong> oraz <strong>NXLog<\/strong> i inne agenty s\u0142u\u017c\u0105ce do zbierania i przekazywania log\u00f3w, tak\u017ce z system\u00f3w spoza \u015bwiata uniksowego.<\/li>\n<\/ul>\n<h2>Jaki jest zwi\u0105zek syslog z SIEM i zarz\u0105dzaniem logami?<\/h2>\n<p>Syslog to jeden z podstawowych sposob\u00f3w dostarczania danych do system\u00f3w <strong>log management<\/strong> oraz <strong><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/siem\">SIEM<\/a><\/strong> (Security Information and Event Management \u2014 zarz\u0105dzanie informacjami i zdarzeniami bezpiecze\u0144stwa). Urz\u0105dzenia sieciowe, zapory, serwery i aplikacje wysy\u0142aj\u0105 komunikaty do centralnego kolektora, kt\u00f3ry je ujednolica, indeksuje i \u0142\u0105czy ze sob\u0105. Uporz\u0105dkowany strumie\u0144 log\u00f3w (zw\u0142aszcza w RFC 5424) u\u0142atwia ich przetwarzanie, pisanie regu\u0142 wykrywania i wy\u0142apywanie anomalii. Centralne zbieranie log\u00f3w ma te\u017c znaczenie dla audytu i zgodno\u015bci z regulacjami (np. PCI DSS, HIPAA, SOX), kt\u00f3re wymagaj\u0105 przechowywania i ochrony zapis\u00f3w zdarze\u0144.<\/p>\n<h2>Dlaczego syslog jest wa\u017cny dla bezpiecze\u0144stwa i jakie ma ograniczenia?<\/h2>\n<p>Logi syslog to dow\u00f3d dla zespo\u0142\u00f3w <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/soc-security-operations-center\">SOC<\/a> oraz dla monitoringu sieci i wykrywania zagro\u017ce\u0144 (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/ndr-network-detection-and-response\">NDR<\/a>). Sam protok\u00f3\u0142 ma jednak kilka ogranicze\u0144 istotnych dla bezpiecze\u0144stwa:<\/p>\n<ul>\n<li><strong>Brak uwierzytelniania i szyfrowania w UDP<\/strong> \u2014 w wariancie UDP\/plaintext nie da si\u0119 sprawdzi\u0107, kto naprawd\u0119 wys\u0142a\u0142 komunikat, ani ochroni\u0107 jego tre\u015bci. Otwiera to drog\u0119 do <strong>spoofingu<\/strong> (podszywania si\u0119 pod \u017ar\u00f3d\u0142o) oraz wstrzykiwania spreparowanych wpis\u00f3w, kt\u00f3re za\u015bmiecaj\u0105 logi i myl\u0105 analityk\u00f3w.<\/li>\n<li><strong>Brak gwarancji dostarczenia (UDP)<\/strong> \u2014 przy przeci\u0105\u017ceniu komunikaty mog\u0105 przepa\u015b\u0107, a wraz z nimi dowody. Atakuj\u0105cy mo\u017ce celowo zala\u0107 system tysi\u0105cami log\u00f3w (log-flooding), \u017ceby przykry\u0107 \u015blady prawdziwego incydentu.<\/li>\n<li><strong>Podmiana i kasowanie log\u00f3w lokalnych<\/strong> \u2014 napastnik, kt\u00f3ry dosta\u0142 si\u0119 na host, mo\u017ce zmieni\u0107 lub usun\u0105\u0107 logi, zanim zostan\u0105 wys\u0142ane. Dlatego wa\u017cne jest szybkie, ci\u0105g\u0142e przesy\u0142anie ich do osobnego, zabezpieczonego kolektora.<\/li>\n<li><strong>Brak jednego formatu tre\u015bci<\/strong> \u2014 lu\u017ana cz\u0119\u015b\u0107 MSG utrudnia przetwarzanie maszynowe i mo\u017ce ukry\u0107 dane wa\u017cne dla wykrywania zagro\u017ce\u0144.<\/li>\n<\/ul>\n<p>Jak ograniczy\u0107 to ryzyko w praktyce: u\u017cywa\u0107 <code>TLS (RFC 5425, port 6514)<\/code> lub niezawodnych mechanizm\u00f3w (TCP, RELP), wydziela\u0107 i filtrowa\u0107 ruch na porcie 514, chroni\u0107 kolektor przed manipulacj\u0105 oraz pilnowa\u0107 samego strumienia log\u00f3w. Przerwa w nap\u0142ywie spodziewanych komunikat\u00f3w te\u017c bywa sygna\u0142em incydentu.<\/p>\n<h2>Dowiedz si\u0119 wi\u0119cej<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/arp-spoofing-jak-wykryc-atak-man-in-the-middle-i-zatruwanie-arp-w-sieci-lan\">ARP Spoofing \u2013 jak wykry\u0107 atak Man-in-the-Middle i zatruwanie ARP w sieci LAN<\/a> \u2014 Syslog pomaga korelowa\u0107 zdarzenia ARP z innymi logami przy wykrywaniu MITM.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/czym-jest-netflow-i-jak-wykorzystuje-sie-go-w-praktyce\">Czym jest NetFlow i jak ten protok\u00f3\u0142 jest wykorzystywany w praktyce?<\/a> \u2014 Syslog uzupe\u0142nia <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/netflow\">NetFlow<\/a> o szczeg\u00f3\u0142y zdarze\u0144 z urz\u0105dze\u0144 i system\u00f3w.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/architektura-zero-trust-rola-widocznosci-sieci-i-mikrosegmentacji-w-bezpieczenstwie\">Architektura Zero Trust \u2013 rola widoczno\u015bci sieci i mikrosegmentacji w bezpiecze\u0144stwie<\/a> \u2014 Syslog dostarcza zdarze\u0144 do kontroli dost\u0119pu i weryfikacji zasad Zero Trust.<\/li>\n<\/ul>\n","protected":false},"featured_media":0,"template":"","class_list":["post-4836","dictionary-item","type-dictionary-item","status-publish","hentry"],"acf":{"tytul":"Syslog","ikona":"","krotki_opis":"Standard i protok\u00f3\u0142 wysy\u0142ania komunikat\u00f3w o zdarzeniach systemowych z urz\u0105dze\u0144 i aplikacji do centralnego kolektora; ka\u017cdy wpis koduje \u017ar\u00f3d\u0142o (facility) i wag\u0119 (severity)."},"_links":{"self":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item\/4836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item"}],"about":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/types\/dictionary-item"}],"wp:attachment":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media?parent=4836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}