Syslog

syslog
Név Syslog protokoll
Szint ( az OSI modell szerint ) Alkalmazott
Család UDP/TCP
Port/ID 514/ UDP , 601/ TCP , 6514/ UDP , 6514/ TCP
A protokoll célja Eseményüzenetek továbbítása és naplózása
Leírás RFC 3164 , RFC 3195 , RFC 5424 , RFC 5425 , RFC 5426 , RFC 5427 , RFC 5674 , RFC 5675 , RFC 5676 , RFC 5848 , RFC 601628
Főbb megvalósítások (kliensek) A legtöbb hálózati operációs rendszerbe és számos hálózati eszközbe beépítve
Alapvető megvalósítások ( szerverek ) A legtöbb hálózati operációs rendszerbe beépítve
Üzenet súlyossági kódjai
0 (Sürgősségi) rendszer nem működik
egy (Riasztó) rendszer azonnali beavatkozást igényel
2 (Kritikus) a rendszer állapota kritikus
3 (Hiba) hibaüzenetek
négy (Figyelmeztetés) figyelmeztetések a lehetséges problémákról
5 (Megjegyzés) üzenetek normális, de fontos eseményekről
6 (Információs) információs üzenetek
7 (Debug) hibakeresési üzenetek
Üzeneteket alkotó témák kategóriáinak kódjai
0 operációs rendszer kernel
egy felhasználói szoftver
2 postai rendszer
3 rendszerszolgáltatások (démonok)
négy biztonsági (engedélyező) üzenetek
5 natív syslogd üzenetek
6 nyomtatási alrendszer
7 hírcsoport alrendszer (telekonferencia, NNTP)
nyolc UUCP alrendszer
9 időszolgáltatások
tíz biztonsági (engedélyező) üzenetek
tizenegy FTP szolgáltatás
12 NTP alrendszer
13 ellenőrzési napló
tizennégy vészhelyzeti napló
tizenöt időszolgáltatások
16 helyi 0
17 helyi 1
tizennyolc helyi 2
19 helyi 3
húsz helyi 4
21 helyi 5
22 helyi 6
23 helyi 7

A syslog ( eng.  rendszernapló  - rendszernapló) a rendszerben előforduló eseményekről szóló üzenetek küldésére és naplózására szolgáló szabvány (vagyis eseménynaplók létrehozása ), amelyeket számítógépes hálózatokban használnak IP protokollt használva . A "syslog" kifejezés egyaránt vonatkozik az immár szabványosított syslog hálózati protokollra és a rendszerüzeneteket küldő és fogadó szoftverre (alkalmazás, könyvtár).

A szabványt először a BSD platformon Eric Allman implementálta a Sendmail projekt [1] részeként , majd később egyszerűsége és méretezhetősége miatt Unix és Linux platformokon is elterjedt, és számos hálózati eszközben implementálták.

Mechanizmus

A szabvány előírja, hogy a források egyszerű szöveges üzeneteket hoznak létre a bennük előforduló eseményekről, és továbbítják azokat a Syslog szerverre (úgynevezett "syslogd", "syslog démon" vagy "syslog szerver"), hogy az IP család valamelyik hálózati protokolljával feldolgozzák. ( UDP vagy TCP ). Az eseményüzenetek létrehozása és továbbítása bizonyos szabályok szerint történik, amelyeket Syslog protokollnak neveznek. Általános szabály, hogy az üzenet kis méretű (legfeljebb 1024 bájt [2] ), és tiszta formában kerül elküldésre. Speciális eszközök (például Stunnel, sslio vagy sslwrap) használatakor azonban lehetőség van az üzenetek titkosítására és SSL / TLS -en keresztüli elküldésére .

Mivel az üzenetforrások és a Syslog-szerver különböző gépeken helyezkedhet el, ez lehetővé teszi számos földrajzilag szétszórt, heterogén forrásból származó üzenetek gyűjtését és tárolását egyetlen tárolóban (repositoryban), ami rendkívül fontos a hálózati rendszergazdák számára, akik esetleg nem rendelkeznek fizikai hozzáférés egyszerre az összes eszközhöz és a hálózaton lévő számítógépekhez.

Ezenkívül a Syslog-szerverek általában nem csak naplózhatják az üzeneteket, hanem továbbíthatják azokat más Syslog-szervereknek, az üzenet fontossági szintje ( Súlyosság ) és az üzenetet generáló tárgy kategóriája ( Facility ) alapján. amely lehetővé teszi például egy hierarchikus tárolórendszer megszervezését. Ez pedig segíthet például csökkenteni a személyzet kritikus eseményekre adott válaszidejét. Tegyük fel, hogy van valami nagy hálózat, amely több szegmensből áll. Minden szilánk saját Syslog-kiszolgálóval rendelkezik, amely csak a szilánkon belüli forrásokból fogad üzeneteket. Ha ezek a downstream szerverek úgy vannak beállítva, hogy a kritikus fontosságú és magasabb szintű üzeneteket egy közös fejszerverhez továbbítsák, akkor a hálózat egészét ezen keresztül irányító hálózati rendszergazda könnyebben követheti a kritikus helyzet bekövetkezését, mivel kevés ilyen üzenet van, és nem fulladnak bele a szükséges, de kevésbé fontos üzenetek folyamába.

A Syslog protokoll jelenlegi verziója továbbfejlesztett üzenetformátumot kínál, amely lehetővé teszi az üzenet létrehozásának pontos időbélyegzését és az üzenet forrásának erős azonosítását, valamint az üzenet UTF-8 kódolását . szervezet, amely megoldja a nemzetköziesedés problémáját. Opcionális kiegészítő mezők (strukturált adatok) különféle információk továbbítására használhatók, például az üzenetforrás helyi órájának hibája és a pontos idő külső órájával való szinkronizálás pontossága, az üzenet írásának nyelve , stb. Egy adott szállításhoz való kötődés feloldása miatt a Syslog protokoll használhatja a különálló RFC -kben leírt üzenetkézbesítési mechanizmusok bármelyikét, de a TLS -átvitelt részesítik előnyben .

Szabványosítás

A syslog-ot hosszú ideig de facto szabványként használták minden formális specifikáció nélkül, ami sok olyan implementációt eredményezett, amelyek egy része inkompatibilis volt egymással. A probléma megoldásának első lépéseit 2001 -ben tették meg  – a syslog protokollt az RFC 3164 írja le . 2005 -ben megjelent a formális specifikáció, az üzenetek tartalmának szabványosítása és továbbításuk mechanizmusa .

A 2001. augusztusi tájékoztató RFC 3164 "The BSD Syslog Protocol" ismerteti a publikálás idején a technika állását. A meglévő implementációk elemzése eredményeként meghatározásra került a Syslog protokoll helye és jelentősége az információs rendszerekben, formalizálták az üzenetstruktúrát, átgondolták az alapvető telepítési modelleket, megfogalmazták az esetleges biztonsági problémákat. Az IPv4 családból származó UDP -t (514-es port) szállítási mechanizmusnak nyilvánították , és bizonyos korlátozásokat vezettek be ennek a szállításnak a használatával kapcsolatban.

2001 novemberében jelent meg az RFC 3195 "Reliable Delivery for Syslog" , amely megoldást javasolt a Syslog protokoll megbízhatóságának javítására a BEEP keretrendszerek [3] bizonyos megvalósításával üzenethordozóként és TCP (601-es port) használatával. az IPv4 család , mint szállítás.

2009 márciusát az RFC -k egész csoportja jelentette, amelyek meglehetősen komoly fejlesztéseket javasoltak a Syslog protokollon.

Az RFC 5424 "The Syslog Protocol" ( Syslog Protocol ) egyrészt azt feltételezte, hogy bármilyen szállítás használható üzenetkézbesítési mechanizmusként, ezért a szállítási mechanizmusok definíciói és ennek megfelelően a korlátozások és biztonsági problémák leírása kimaradt a jelentésből. protokoll leírása, közvetlenül egy adott szállításhoz kapcsolódik. Másodsorban olyan új üzenetformátumot javasolt, amely az üzenet törzsében a fejlécen és a szövegen kívül strukturált adatokat is tartalmaz, amelyek elemeit vagy közvetlenül az IANA regisztrálja , vagy kezelésüket olyan vállalkozásokra ruházzák át, amelyek regisztrálták személyi számukat az IANA -nál az SMIv2 szerint . Ezenkívül az új üzenetformátum lehetővé teszi az üzenet forrásának és időpontjának pontosabb lokalizálását. Harmadszor, folytatva a nemzetközivé válás folyamatát, az UTF-8 kódolást javasolta az üzenetszövegnek preferáltnak.

Az RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" leírása a TLS-mechanizmus használatát írja le az üzenetek TCP -n ( 6514-es porton) történő kézbesítésére az IPv4 / v6 családból , mint átvitel, annak korlátozásait és biztonsági kérdéseit.

Az RFC 5426 „Transmission of Syslog Messages over UDP” leírása az IPv4 / v6 családból származó UDP -n keresztüli nem TLS - üzenetek kézbesítési mechanizmusát (514-es port), mint átvitelt, annak korlátozásait és biztonsági problémáit írta le.

Az RFC 5427 "Szövegkonvenciók a Syslog-kezeléshez" szöveges konvenciók halmazát határozta meg, amelyek leírják a Syslog MIB - üzenetek súlyosságát és elérhetőségét, így más MIB-modulok használhatják azokat a felügyelt objektumok meghatározása során.

2009 októberében egy másik RFC is megjelent , amely az objektumkezelést a Syslog protokollhoz kapcsolta.

Az RFC 5674 „Alarms in Syslog” előkészítette az utat az IETF riasztási bázis (Alarm MIB) Syslog üzenetekben való használatához.

RFC 5675 " Simple Network Management Protocol (SNMP) értesítések leképezése SYSLOG üzenetekhez" és RFC 5676 " Felügyelt objektumok definíciói SYSLOG üzenetek egyszerű hálózatkezeléshez való leképezéséhez" Protokoll (SNMP) értesítések" ( Kezelt entitás definíciói a Translation Mechanizmushoz Az egyszerű hálózatkezelési protokoll ( SNMP ) értesítései) a dokumentumok címeiből magától értetődőek.

A 2010 májusában kiadott RFC 5848 "Signed Syslog Messages" leírja a kriptográfiai aláírás használatát a Syslog üzenetekben.

2010 októberében megjelent az RFC 6012 "Datagram Transport Layer Security ( DTLS ) Transport Mapping for Syslog" , amely a TLS -mechanizmus használatát javasolja az IPv4/v6 család UDP -n (6514-es porton) keresztül történő üzenetek kézbesítésére átvitelként, annak korlátai és biztonsági kérdések.

A 2012 áprilisában kiadott RFC 6587 "Transmission of Syslog Messages over TCP" ismerteti az IPv4 /v6 családból származó TLS-t nem használó üzenetek kézbesítésének bevett mechanizmusait , azok korlátait és biztonsági problémáit.

Így az IETF által kiadott következő RFC -k írják le a syslog [4] protokollt :

Jegyzetek

  1. "A sendmail egyik sikeres mellékprojektje a syslog volt." (Az egyik sikeres spin-off projekt, amely a sendmailből nőtt ki, a syslog volt.) The Architecture of Open Source Applications, I. kötet, 17. rész, Sendmail (Eric Allman) Archiválva : 2012. december 27. a Wayback Machine -nél
  2. ↑ Ezt az RFC 3164-ben bevezetett általános korlátozást az RFC 5424 -ben eltávolították . Mivel az üzenethossz-korlátok szállítástól függenek, külön RFC-kbe kerülnek, amelyek leírják a szállítási mechanizmusokat.
  3. Lásd RFC 3080 "The Blocks Extensible Exchange Protocol Core".
  4. Jelenleg (2013. január) az IETF munkacsoportjai dolgoznak a "Syslog Extension for Cloud Using Syslog Structured Data" 2016. március 4-én archiválva a Wayback Machine -nél és a "Syslog Format for NAT Logging" vázlatain is dolgoznak , 2012. december 23-án a Wayback Machine -nél. .
  5. RFC 5424 oroszul . Letöltve: 2014. november 27. Az eredetiből archiválva : 2014. december 19.
  6. RFC 5426 oroszul . Letöltve: 2014. november 27. Az eredetiből archiválva : 2014. december 19.