| syslog | |
|---|---|
| Navn | Syslog-protokol |
| Niveau (ifølge OSI-modellen ) | Anvendt |
| Familie | UDP/TCP |
| Port/ID | 514/ UDP , 601/ TCP , 6514/ UDP , 6514/ TCP |
| Formål med protokollen | Transmission og logning af hændelsesmeddelelser |
| 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 |
| Vigtigste implementeringer (klienter) | Indbygget i de fleste netværksoperativsystemer og mange netværksenheder |
| Kerneimplementeringer ( servere ) | Indbygget i de fleste netværksoperativsystemer |
| Sværhedskoder for meddelelser | |
|---|---|
| 0 | (Nød)system ikke operationelt |
| en | (Alert) system kræver øjeblikkelig indgriben |
| 2 | (Kritisk) systemets tilstand er kritisk |
| 3 | (Fejl) fejlmeddelelser |
| fire | (Advarsel) advarsler om mulige problemer |
| 5 | (Bemærk) beskeder om normale, men vigtige begivenheder |
| 6 | (Informations-) informationsmeddelelser |
| 7 | (Debug) debug-meddelelser |
| Koder for kategorier af emner, der danner beskeder | |
|---|---|
| 0 | operativsystemets kerne |
| en | brugersoftware |
| 2 | postsystemet |
| 3 | systemtjenester (dæmoner) |
| fire | sikkerhedsmeddelelser (autorisation). |
| 5 | native syslogd-meddelelser |
| 6 | udskrivningsundersystem |
| 7 | nyhedsgruppeundersystem (telekonference, NNTP) |
| otte | UUCP undersystem |
| 9 | tidstjenester |
| ti | sikkerhedsmeddelelser (autorisation). |
| elleve | FTP-tjeneste |
| 12 | NTP undersystem |
| 13 | revisionslog |
| fjorten | nødlog |
| femten | tidstjenester |
| 16 | lokal 0 |
| 17 | lokal 1 |
| atten | lokal 2 |
| 19 | lokal 3 |
| tyve | lokal 4 |
| 21 | lokal 5 |
| 22 | lokal 6 |
| 23 | lokal 7 |
syslog ( eng. system log - system log) er en standard til at sende og logge meddelelser om hændelser, der forekommer i systemet (det vil sige oprettelse af hændelseslogfiler ), der bruges i computernetværk ved hjælp af IP -protokollen . Udtrykket "syslog" refererer til både den nu standardiserede syslog-netværksprotokol og softwaren (applikation, bibliotek), der sender og modtager systemmeddelelser.
Standarden blev først implementeret på BSD -platformen af Eric Allman som en del af Sendmail- projektet [1] , og senere, på grund af dens enkelhed og skalerbarhed, blev den udbredt på Unix- og Linux -platforme og implementeret i mange netværksenheder.
Standarden foreskriver, at kilder danner simple tekstmeddelelser om hændelser, der forekommer i dem og overfører dem til Syslog-serveren (kaldet "syslogd", "syslog-dæmon" eller "syslog-server") til behandling ved hjælp af en af IP- familiens netværksprotokoller ( UDP eller TCP ). Dannelsen af hændelsesmeddelelser og deres transmission sker i henhold til visse regler, kaldet Syslog-protokollen. Som regel har meddelelsen en lille størrelse (op til 1024 bytes [2] ) og sendes klar. Men når du bruger specielle værktøjer (såsom Stunnel, sslio eller sslwrap), er det muligt at kryptere beskeder og sende dem over SSL / TLS .
Da meddelelseskilder og Syslog-serveren kan være placeret på forskellige maskiner, giver dette dig mulighed for at organisere indsamling og lagring af meddelelser fra mange geografisk spredte heterogene kilder i et enkelt lager (lager), hvilket er ekstremt vigtigt for netværksadministratorer, som måske ikke har fysisk adgang til alle enheder på én gang og computere på netværket.
Syslog-servere kan som regel ikke kun logge meddelelser, men også videresende dem til andre Syslog-servere, baseret på meddelelsens vigtighed ( Sværhedsgrad ) og kategorien af emnet, der genererede meddelelsen ( Facility ), som tillader organisering af for eksempel et hierarkisk lagersystem. Og det kan for eksempel være med til at reducere personalets responstid på kritiske hændelser. Lad os antage, at der er et eller andet stort netværk bestående af flere segmenter. Hvert shard har sin egen Syslog-server, som kun modtager beskeder fra kilder i dets shard. Hvis disse downstream-servere er konfigureret til at videresende meddelelser af et kritisk betydningsniveau og højere til én fælles hovedserver, så vil det være lettere for netværksadministratoren, som kontrollerer hele netværket gennem det, at spore forekomsten af en kritisk situation, da der er få sådanne beskeder, og de vil ikke drukne i strømmen af nødvendige, men mindre vigtige beskeder.
Den nuværende version af Syslog-protokollen tilbyder et forbedret meddelelsesformat, der tillader brugen af et nøjagtigt tidsstempel for oprettelsen af en meddelelse og stærk identifikation af kilden til meddelelsen, samt brugen af UTF-8- kodning til meddelelsen organ, som løser problemet med internationalisering. Valgfrie ekstra felter (strukturerede data) kan bruges til at formidle forskellige oplysninger, for eksempel fejlen i det lokale ur i meddelelseskilden og nøjagtigheden af dets synkronisering med et eksternt ur med nøjagtig tid, det sprog, som meddelelsen er skrevet på , osv. På grund af afbindingen til en specifik transport, kan Syslog-protokollen bruge enhver af meddelelsesleveringsmekanismerne beskrevet i separate RFC'er , men TLS -transporter foretrækkes .
I lang tid blev syslog brugt som en de facto standard uden nogen formel specifikation, hvilket resulterede i mange implementeringer, hvoraf nogle var inkompatible med hinanden. De første skridt til at løse dette problem blev taget i 2001 - syslog-protokollen blev beskrevet i RFC 3164 . En formel specifikation, standardisering af indholdet af meddelelser og en mekanisme for deres transmission blev udgivet i 2005 .
Den informative RFC 3164 "The BSD Syslog Protocol" fra august 2001 beskrev det nyeste på udgivelsestidspunktet. Som et resultat af analysen af eksisterende implementeringer blev Syslog-protokollens plads og betydning i informationssystemer fastlagt, meddelelsesstrukturen blev formaliseret, grundlæggende implementeringsmodeller blev overvejet, og mulige sikkerhedsproblemer blev formuleret. UDP (port 514) fra IPv4 -familien blev erklæret som en transportmekanisme , og der blev indført nogle begrænsninger i forbindelse med brugen af denne transport.
I november 2001 blev RFC 3195 "Reliable Delivery for Syslog" frigivet , som foreslog en løsning til at forbedre pålideligheden af Syslog-protokollen ved at bruge en bestemt implementering af BEEP-frameworks [3] som meddelelsesbærer og bruge TCP (port 601 ) fra IPv4- familien som transport.
Marts 2009 var præget af udgivelsen af en hel gruppe RFC'er , der foreslog ganske alvorlige forbedringer af Syslog-protokollen.
RFC 5424 "The Syslog Protocol" ( Syslog Protocol ) postulerede for det første, at enhver transport kan bruges som en meddelelsesleveringsmekanisme, og derfor blev definitionerne af transportmekanismer og følgelig beskrivelsen af restriktioner og sikkerhedsproblemer udelukket fra protokolbeskrivelse, direkte relateret til en specifik transport. For det andet foreslog han et nyt meddelelsesformat, der indebærer tilstedeværelsen i meddelelsens brødtekst, udover overskriften og teksten, også strukturerede data, hvis elementer enten er direkte registreret hos IANA , eller deres forvaltning er uddelegeret til virksomheder, der har registreret deres personnummer hos IANA i overensstemmelse med SMIv2 . Derudover giver det nye meddelelsesformat dig mulighed for mere præcist at lokalisere kilden og tidspunktet for meddelelsen. For det tredje, for at fortsætte internationaliseringsprocessen, foreslog han at bruge UTF-8- kodning til meddelelsesteksten som den foretrukne.
RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" beskrev brugen af TLS-mekanismen til at levere meddelelser ved hjælp af TCP ( port 6514) fra IPv4 / v6-familien som transport, dens begrænsninger og sikkerhedsproblemer.
RFC 5426 "Transmission af Syslog-meddelelser over UDP" beskrev en ikke- TLS - meddelelsesleveringsmekanisme over UDP (port 514) fra IPv4 / v6-familien som en transport, dens begrænsninger og sikkerhedsproblemer.
RFC 5427 "Tekstuelle konventioner for Syslog Management" definerede et sæt tekstkonventioner, der beskriver alvoren og faciliteten af Syslog MIB -meddelelser , så andre MIB-moduler kan bruge dem i processen med at definere administrerede objekter.
I oktober 2009 blev der frigivet en anden RFC , der forbinder objektstyring til Syslog-protokollen.
RFC 5674 "Alarmer i Syslog" banede vejen for brug af IETF Alarm Base (Alarm MIB) i Syslog-meddelelser.
RFC 5675 " Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages" og 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 til SNMP -meddelelser ( Simple Network Management Protocol) er selvforklarende ud fra titlerne på dokumenterne.
Udgivet i maj 2010, RFC 5848 "Signed Syslog Messages" beskrev brugen af en kryptografisk signatur i Syslog-meddelelser.
I oktober 2010 blev RFC 6012 "Datagram Transport Layer Security ( DTLS ) Transport Mapping for Syslog" udgivet , der foreslår brugen af TLS -mekanismen til levering af meddelelser ved hjælp af UDP (port 6514) fra IPv4/v6-familien som transport, dens begrænsninger og sikkerhedsspørgsmål.
Udgivet i april 2012, RFC 6587 "Transmission of Syslog Messages over TCP" beskrev de etablerede mekanismer til levering af beskeder, der ikke bruger TLS over TCP fra IPv4/v6-familien som transport, deres begrænsninger og sikkerhedsproblemer.
Følgende RFC'er udstedt af IETF beskriver således syslog [4] -protokollen :