| syslog | |
|---|---|
| Nume | Protocol Syslog |
| Nivel (conform modelului OSI ) | Aplicat |
| Familie | UDP/TCP |
| Port/ID | 514/ UDP , 601/ TCP , 6514/ UDP , 6514/ TCP |
| Scopul protocolului | Transmiterea și înregistrarea mesajelor de evenimente |
| Specificație | RFC 3164 , RFC 3195 , RFC 5424 , RFC 5425 , RFC 5426 , RFC 5427 , RFC 5674 , RFC 5675 , RFC 5676 , RFC 5848 , RFC 601628 , RFC 601628 |
| Principalele implementări (clienți) | Încorporat în majoritatea sistemelor de operare de rețea și în multe dispozitive de rețea |
| Implementări de bază ( servere ) | Încorporat în majoritatea sistemelor de operare de rețea |
| Codurile de severitate ale mesajelor | |
|---|---|
| 0 | Sistemul (de urgență) nu este operațional |
| unu | Sistemul (alertă) necesită intervenție imediată |
| 2 | (Critic) starea sistemului este critică |
| 3 | Mesaje de eroare (de eroare). |
| patru | (Avertisment) avertismente despre posibile probleme |
| 5 | (Notă) mesaje despre evenimente normale, dar importante |
| 6 | mesaje informative (informaționale). |
| 7 | (Depanare) mesaje de depanare |
| Codurile categoriilor de subiecte care formează mesaje | |
|---|---|
| 0 | nucleul sistemului de operare |
| unu | software-ul utilizatorului |
| 2 | sistem postal |
| 3 | servicii de sistem (daemoni) |
| patru | mesaje de securitate (autorizare). |
| 5 | mesaje syslogd native |
| 6 | subsistem de imprimare |
| 7 | subsistem grup de știri (teleconferințe, NNTP) |
| opt | subsistemul UUCP |
| 9 | servicii de timp |
| zece | mesaje de securitate (autorizare). |
| unsprezece | Serviciu FTP |
| 12 | subsistemul NTP |
| 13 | Jurnal de audit |
| paisprezece | jurnalul de urgență |
| cincisprezece | servicii de timp |
| 16 | local 0 |
| 17 | local 1 |
| optsprezece | local 2 |
| 19 | local 3 |
| douăzeci | local 4 |
| 21 | local 5 |
| 22 | local 6 |
| 23 | local 7 |
syslog ( eng. jurnal de sistem - jurnal de sistem) este un standard pentru trimiterea și înregistrarea mesajelor despre evenimentele care au loc în sistem (adică crearea jurnalelor de evenimente ) utilizate în rețelele de calculatoare folosind protocolul IP . Termenul „syslog” se referă atât la protocolul de rețea syslog standardizat, cât și la software-ul (aplicație, bibliotecă) care trimite și primește mesaje de sistem.
Standardul a fost implementat pentru prima dată pe platforma BSD de Eric Allman ca parte a proiectului Sendmail [1] , iar mai târziu, datorită simplității și scalabilității sale, a devenit larg răspândit pe platformele Unix și Linux și implementat în multe dispozitive de rețea.
Standardul prevede că sursele formează mesaje text simple despre evenimentele care au loc în ele și le transferă pe serverul Syslog (numit „syslogd”, „syslog daemon” sau „server syslog”) pentru procesare folosind unul dintre protocoalele de rețea ale familiei IP ( UDP sau TCP ). Formarea mesajelor de eveniment și transmiterea lor are loc după anumite reguli, numite protocol Syslog. De regulă, mesajul are o dimensiune mică (până la 1024 de octeți [2] ) și este trimis în clar. Cu toate acestea, atunci când utilizați instrumente speciale (cum ar fi Stunnel, sslio sau sslwrap), este posibil să criptați mesajele și să le trimiteți prin SSL / TLS .
Deoarece sursele de mesaje și serverul Syslog pot fi localizate pe mașini diferite, acest lucru vă permite să organizați colectarea și stocarea mesajelor din multe surse eterogene dispersate geografic într-o singură stocare (depozitare), ceea ce este extrem de important pentru administratorii de rețea care nu au acces fizic la toate dispozitivele simultan și la computerele din rețea.
De asemenea, serverele Syslog, de regulă, nu pot doar să înregistreze mesajele, ci și să le redirecționeze către alte servere Syslog, în funcție de nivelul de importanță al mesajului ( Severity ) și de categoria subiectului care a generat mesajul ( Facility ), care permite organizarea, de exemplu, a unui sistem de stocare ierarhic. Și acest lucru poate ajuta, de exemplu, la reducerea timpului de răspuns al personalului la evenimente critice. Să presupunem că există o rețea mare formată din mai multe segmente. Fiecare shard are propriul său server Syslog, care primește mesaje numai de la surse din shard-ul său. Dacă aceste servere din aval sunt configurate pentru a transmite mesaje cu un nivel de importanță critică și mai mare către un server principal comun, atunci va fi mai ușor pentru administratorul de rețea, care controlează întreaga rețea prin intermediul acesteia, să urmărească apariția unei situații critice, deoarece sunt puține astfel de mesaje și nu se vor îneca în fluxul de mesaje necesare, dar mai puțin importante.
Versiunea actuală a protocolului Syslog oferă un format de mesaj îmbunătățit care permite utilizarea unui marcaj de timp precis al creării unui mesaj și identificarea puternică a sursei mesajului, precum și utilizarea codificării UTF-8 pentru mesaj. organism, care rezolvă problema internaționalizării. Câmpurile suplimentare opționale (date structurate) pot fi folosite pentru a transmite diverse informații, de exemplu, eroarea ceasului local al sursei mesajului și acuratețea sincronizării acesteia cu un ceas extern de timp exact, limba în care este scris mesajul , etc. Datorită dezlegarii la un anumit transport, protocolul Syslog poate folosi oricare dintre mecanismele de livrare a mesajelor descrise în RFC -uri separate, dar transporturile TLS sunt preferate .
Multă vreme, syslog a fost folosit ca standard de facto fără nicio specificație formală, ceea ce a dus la multe implementări, unele dintre ele incompatibile între ele. Primii pași pentru a rezolva această problemă au fost făcuți în 2001 - protocolul syslog a fost descris în RFC 3164 . O specificație formală, standardizarea conținutului mesajelor și un mecanism de transmitere a acestora au fost lansate în 2005 .
RFC 3164 informativ din august 2001 „Protocolul BSD Syslog” a descris stadiul tehnicii la momentul publicării. În urma analizei implementărilor existente, s-a determinat locul și semnificația protocolului Syslog în sistemele informaționale, a fost oficializată structura mesajului, au fost luate în considerare modele de implementare de bază și au fost formulate posibile probleme de securitate. UDP (portul 514) din familia IPv4 a fost declarat ca mecanism de transport , iar unele restricții au fost introduse legate de utilizarea acestui transport.
În noiembrie 2001, a fost lansat RFC 3195 „Reliable Delivery for Syslog” , care propunea o soluție de îmbunătățire a fiabilității protocolului Syslog prin utilizarea unei anumite implementări a cadrelor BEEP [3] ca purtător de mesaje și folosind TCP (portul 601) de la familia IPv4 ca transport.
Martie 2009 a fost marcată de lansarea unui întreg grup de RFC -uri care au propus îmbunătățiri destul de serioase ale protocolului Syslog.
RFC 5424 „Protocolul Syslog” ( Protocolul Syslog ), în primul rând, a postulat că orice transport poate fi utilizat ca mecanism de livrare a mesajelor și, prin urmare, definițiile mecanismelor de transport și, în consecință, descrierea restricțiilor și problemelor de securitate, au fost excluse din descrierea protocolului, direct legată de un anumit transport. În al doilea rând, a propus un nou format de mesaj care presupune prezența în corpul mesajului, pe lângă antet și text, și date structurate, ale căror elemente fie sunt înregistrate direct la IANA , fie gestionarea lor este delegată întreprinderilor care și-au înregistrat numărul personal la IANA în conformitate cu SMIv2 . În plus, noul format de mesaj vă permite să localizați mai precis sursa și ora mesajului. În al treilea rând, continuând procesul de internaționalizare, el a sugerat utilizarea codării UTF-8 pentru textul mesajului ca cea preferată.
RFC 5425 „Transport Layer Security (TLS) Transport Mapping for Syslog” a descris utilizarea mecanismului TLS pentru a livra mesaje folosind TCP ( portul 6514) din familia IPv4 / v6 ca transport, limitările sale și problemele de securitate.
RFC 5426 „Transmiterea mesajelor Syslog prin UDP” a descris un mecanism de livrare a mesajelor non- TLS prin UDP (portul 514) din familia IPv4 / v6 ca transport, limitările acestuia și problemele de securitate.
RFC 5427 „Convenții textuale pentru managementul Syslog” a definit un set de convenții textuale care descriu gravitatea și facilitatea mesajelor MIB Syslog , astfel încât alte module MIB să le poată utiliza în procesul de definire a obiectelor gestionate.
În octombrie 2009, a fost lansat un alt RFC care leagă gestionarea obiectelor la protocolul Syslog.
RFC 5674 „Alarme în Syslog” a deschis calea pentru utilizarea bazei de alarmă IETF (Alarm MIB) în mesajele Syslog.
RFC 5675 „ Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages” și RFC 5676 „ Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management” Protocol (SNMP) Notificări” ( Managed Entity Definitions for the Syslog Message Translation Mechanism to Notificări Simple Network Management Protocol ( SNMP ) se explică de la sine din titlurile documentelor.
Lansat în mai 2010, RFC 5848 „Mesaje Syslog semnate” a descris utilizarea unei semnături criptografice în mesajele Syslog.
În octombrie 2010, a fost lansat RFC 6012 „Datagram Transport Layer Security ( DTLS ) Transport Mapping for Syslog” , care propune utilizarea mecanismului TLS pentru livrarea mesajelor folosind UDP (portul 6514) din familia IPv4/v6 ca transport, limitările acestuia și probleme de securitate.
Lansat în aprilie 2012, RFC 6587 „Transmission of Syslog Messages over TCP” a descris mecanismele stabilite pentru livrarea mesajelor care nu utilizează TLS prin TCP din familia IPv4/v6 ca transport, limitările și problemele de securitate ale acestora.
Astfel, următoarele RFC -uri emise de IETF descriu protocolul syslog [4] :