| syslog | |
|---|---|
| namn | Syslog-protokoll |
| Nivå (enligt OSI-modellen ) | Applicerad |
| Familj | UDP/TCP |
| Port/ID | 514/ UDP , 601/ TCP , 6514/ UDP , 6514/ TCP |
| Syftet med protokollet | Sändning och loggning av händelsemeddelanden |
| Specifikation | RFC 3164 , RFC 3195 , RFC 5424 , RFC 5425 , RFC 5426 , RFC 5427 , RFC 5674 , RFC 5675 , RFC 5676 , RFC 5848 , RFC 60125 , RFC 60125 |
| Huvudsakliga implementeringar (klienter) | Inbyggd i de flesta nätverksoperativsystem och många nätverksenheter |
| Kärnimplementationer ( servrar ) | Inbyggd i de flesta nätverksoperativsystem |
| Meddelandets allvarlighetskod | |
|---|---|
| 0 | (Nöd)systemet fungerar inte |
| ett | (Larm)system kräver omedelbart ingripande |
| 2 | (Kritisk) systemets tillstånd är kritiskt |
| 3 | (Fel) felmeddelanden |
| fyra | (Varning) varningar om möjliga problem |
| 5 | (Anmärkning) meddelanden om normala men viktiga händelser |
| 6 | (Informations-) informationsmeddelanden |
| 7 | (Debug) felsök meddelanden |
| Koder för kategorier av ämnen som bildar meddelanden | |
|---|---|
| 0 | operativsystemets kärna |
| ett | användarprogramvara |
| 2 | Postsystem |
| 3 | systemtjänster (demoner) |
| fyra | säkerhetsmeddelanden (auktorisering). |
| 5 | inbyggda syslogd-meddelanden |
| 6 | utskriftsdelsystem |
| 7 | nyhetsgruppsundersystem (telekonferenser, NNTP) |
| åtta | UUCP delsystem |
| 9 | tidstjänster |
| tio | säkerhetsmeddelanden (auktorisering). |
| elva | FTP-tjänst |
| 12 | NTP-delsystem |
| 13 | revisionslogg |
| fjorton | nödlogg |
| femton | tidstjänster |
| 16 | lokal 0 |
| 17 | lokal 1 |
| arton | lokal 2 |
| 19 | lokal 3 |
| tjugo | lokal 4 |
| 21 | lokal 5 |
| 22 | lokal 6 |
| 23 | lokal 7 |
syslog ( eng. system log - system log) är en standard för att skicka och logga meddelanden om händelser som inträffar i systemet (det vill säga skapa händelseloggar ) som används i datornätverk som använder IP- protokollet . Termen "syslog" avser både det nu standardiserade nätverksprotokollet syslog och programvaran (applikation, bibliotek) som skickar och tar emot systemmeddelanden.
Standarden implementerades först på BSD- plattformen av Eric Allman som en del av Sendmail- projektet [1] , och senare, på grund av dess enkelhet och skalbarhet, blev den utbredd på Unix- och Linux- plattformar och implementerades i många nätverksenheter.
Standarden föreskriver att källor bildar enkla textmeddelanden om händelser som inträffar i dem och överför dem till Syslog-servern (kallad "syslogd", "syslog-demon" eller "syslog-server") för bearbetning med ett av IP- familjens nätverksprotokoll ( UDP eller TCP ). Bildandet av händelsemeddelanden och deras överföring sker enligt vissa regler, kallat Syslog-protokollet. Som regel har meddelandet en liten storlek (upp till 1024 byte [2] ) och skickas i klartext. Men när du använder specialverktyg (som Stunnel, sslio eller sslwrap) är det möjligt att kryptera meddelanden och skicka dem över SSL / TLS .
Eftersom meddelandekällor och Syslog-servern kan placeras på olika maskiner, låter detta dig organisera insamling och lagring av meddelanden från många geografiskt spridda heterogena källor i en enda lagring (repository), vilket är extremt viktigt för nätverksadministratörer som kanske inte har fysisk åtkomst till alla enheter på en gång och datorer i nätverket.
Dessutom kan Syslog-servrar, som regel, inte bara logga meddelanden, utan också vidarebefordra dem till andra Syslog-servrar, baserat på graden av betydelse för meddelandet ( Severity ) och kategorin för ämnet som genererade meddelandet ( Facility ), som tillåter organisering av till exempel ett hierarkiskt lagringssystem. Och detta kan till exempel hjälpa till att minska personalens responstid på kritiska händelser. Låt oss anta att det finns något stort nätverk som består av flera segment. Varje shard har sin egen Syslog-server, som endast tar emot meddelanden från källor inom dess shard. Om dessa nedströmsservrar är konfigurerade att vidarebefordra meddelanden av en kritisk betydelsenivå och högre till en gemensam huvudserver, blir det lättare för nätverksadministratören, som kontrollerar hela nätverket genom den, att spåra uppkomsten av en kritisk situation, eftersom det finns få sådana meddelanden och de kommer inte att drunkna i flödet av nödvändiga men mindre viktiga meddelanden.
Den nuvarande versionen av Syslog-protokollet erbjuder ett förbättrat meddelandeformat som tillåter användning av en korrekt tidsstämpel för att skapa ett meddelande och en stark identifiering av meddelandets källa, samt användning av UTF-8- kodning för meddelandet organ, som löser problemet med internationalisering. Valfria ytterligare fält (strukturerade data) kan användas för att förmedla olika information, till exempel felet i den lokala klockan i meddelandekällan och noggrannheten i dess synkronisering med en extern klocka med exakt tid, språket som meddelandet är skrivet på , etc. På grund av avbindningen till en specifik transport kan Syslog-protokollet använda vilken som helst av meddelandeleveransmekanismerna som beskrivs i separata RFC :er, men TLS- transporter är att föredra .
Under lång tid användes syslog som en de facto-standard utan någon formell specifikation, vilket resulterade i många implementeringar, varav några var inkompatibla med varandra. De första stegen för att lösa detta problem togs 2001 - syslog-protokollet beskrevs i RFC 3164 . En formell specifikation, standardisering av innehållet i meddelanden och en mekanism för överföring av dem släpptes 2005 .
Den informativa RFC 3164 från augusti 2001 "The BSD Syslog Protocol" beskrev den senaste tekniken vid tidpunkten för publiceringen. Som ett resultat av analysen av befintliga implementeringar fastställdes Syslog-protokollets plats och betydelse i informationssystem, meddelandestrukturen formaliserades, grundläggande implementeringsmodeller övervägdes och möjliga säkerhetsproblem formulerades. UDP (port 514) från IPv4- familjen deklarerades som en transportmekanism och vissa restriktioner infördes relaterade till användningen av denna transport.
I november 2001 släpptes RFC 3195 "Reliable Delivery for Syslog" , som föreslog en lösning för att förbättra tillförlitligheten för Syslog-protokollet genom att använda en viss implementering av BEEP-ramverk [3] som meddelandebärare och använda TCP (port 601 ) från IPv4- familjen som transport.
Mars 2009 präglades av lanseringen av en hel grupp RFC :er som föreslog ganska allvarliga förbättringar av Syslog-protokollet.
RFC 5424 "The Syslog Protocol" ( Syslog Protocol ), för det första, postulerade att vilken transport som helst kan användas som en meddelandeleveransmekanism, och därför uteslöts definitionerna av transportmekanismer och följaktligen beskrivningen av restriktioner och säkerhetsproblem från protokollbeskrivning, direkt relaterad till en specifik transport. För det andra föreslog han ett nytt meddelandeformat som antyder närvaron i meddelandets brödtext, förutom rubriken och texten, även strukturerad data, vars delar antingen är direkt registrerade hos IANA , eller så är deras hantering delegerad till företag som har registrerat sitt personnummer hos IANA i enlighet med SMIv2 . Dessutom låter det nya meddelandeformatet dig mer exakt lokalisera källan och tidpunkten för meddelandet. För det tredje, för att fortsätta internationaliseringsprocessen, föreslog han att använda UTF-8- kodning för meddelandetexten som den föredragna.
RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" beskrev användningen av TLS-mekanismen för att leverera meddelanden med TCP ( port 6514) från IPv4 / v6-familjen som transport, dess begränsningar och säkerhetsproblem.
RFC 5426 "Transmission of Syslog Messages over UDP" beskrev en icke- TLS - meddelandeleveransmekanism över UDP (port 514) från IPv4 / v6-familjen som en transport, dess begränsningar och säkerhetsproblem.
RFC 5427 "Textuella konventioner för Syslog Management" definierade en uppsättning textkonventioner som beskriver svårighetsgraden och funktionaliteten för Syslog MIB- meddelanden så att andra MIB-moduler kan använda dem i processen för att definiera hanterade objekt.
I oktober 2009 släpptes ytterligare en RFC som länkade objekthantering till Syslog-protokollet.
RFC 5674 "Larm i Syslog" banade väg för att använda IETF Alarm Base (Alarm MIB) i Syslog-meddelanden.
RFC 5675 " Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages" och RFC 5676 " Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management" Protocol (SNMP) Notifications" ( Managed Entity Definitions for Syslog Message Translation Mechanism till SNMP- meddelanden ( Simple Network Management Protocol ) är självförklarande från titeln på dokumenten.
Släppt i maj 2010, RFC 5848 "Signed Syslog Messages" beskrev användningen av en kryptografisk signatur i Syslog-meddelanden.
I oktober 2010 släpptes RFC 6012 "Datagram Transport Layer Security ( DTLS ) Transport Mapping for Syslog" , som föreslår användning av TLS- mekanismen för att leverera meddelanden med UDP (port 6514) från IPv4/v6-familjen som transport, dess begränsningar och säkerhetsfrågor.
Utgiven i april 2012, RFC 6587 "Transmission of Syslog Messages over TCP" beskrev de etablerade mekanismerna för att leverera meddelanden som inte använder TLS över TCP från IPv4/v6-familjen som transport, deras begränsningar och säkerhetsproblem.
Följande RFC :er utfärdade av IETF beskriver syslog [4] -protokollet :