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.
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 .
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 :