Syslog-server: så sätter du upp loggcentralisering
Vad är en syslog-server?
En syslog-server är en central mottagare som tar emot och lagrar loggmeddelanden från andra enheter i nätverket. Servrar, routrar, switchar, brandväggar och olika program skickar sina loggar via syslog-protokollet till en gemensam punkt istället för att spara dem lokalt. Det gör det möjligt att söka, korrelera och larma på händelser från hela infrastrukturen i ett och samma system.
Syslog skapades ursprungligen av Eric Allman på 1980-talet som en del av Sendmail-projektet och blev snabbt standard för loggning på Unix-system. Idag stödjs syslog av nästan all nätverksutrustning, server-operativsystem och säkerhetsprodukter. Två RFC:er definierar protokollet: RFC 3164 som beskriver det ursprungliga BSD-formatet, och RFC 5424 som är den moderna efterföljaren.
RFC 3164 mot RFC 5424
De två syslog-formaten skiljer sig på flera viktiga punkter. RFC 5424 publicerades 2009 och ersätter formellt RFC 3164, men det äldre BSD-formatet är fortfarande extremt vanligt på nätverksutrustning. Här är skillnaderna:
| Egenskap | RFC 3164 mot RFC 5424 |
|---|---|
| Tidsstämpel | 3164: format Mmm dd hh:mm:ss, saknar år och tidszon • 5424: ISO 8601 med tidszon och underdelar av sekunder |
| Strukturerad data | 3164: saknas • 5424: SD-element med nyckel/värde-par |
| Maxstorlek | 3164: 1024 byte • 5424: ingen formell gräns, beror på transport |
| App-namn och processID | 3164: del av fri text • 5424: egna fält |
| Tecken | 3164: ASCII • 5424: UTF-8 med BOM |
För nya installationer är RFC 5424 förstavalet. Strukturerade fält gör det enklare att parsa loggar maskinellt. Den exakta tidsstämpeln med tidszon eliminerar problem som annars uppstår när enheter skickar utan zoninformation. Många moderna analyssystem som Graylog, Splunk och Elastic Stack stödjer båda formaten parallellt.
Transportlager: UDP, TCP och TLS
Syslog kan transporteras på tre sätt. Valet påverkar både tillförlitlighet och säkerhet, och bör övervägas innan du sätter upp produktionen:
- UDP på port 514: Det ursprungliga transportsättet och fortfarande vanligast. Snabb och resurssnål, men paket kan tappas tyst utan att avsändaren märker det
- TCP på port 514 eller 1468: Garanterad leverans med kvittens. Använder fyra till tio gånger mer bandbredd än UDP men förlorar inte meddelanden
- TLS på port 6514: Krypterad TCP-transport enligt RFC 5425. Skyddar både innehåll och autentisering. Bör användas över otillförlitliga nät
För nätverksövervakning där enskilda förluster är acceptabla räcker UDP. För säkerhetsloggning, audit och allt med compliance-krav ska TLS eller åtminstone TCP användas. UDP kan tappa upp till 5 procent av meddelandena vid hög belastning utan att någonting larmar.
Severity och facility
Varje syslog-meddelande har två kodade fält: severity (allvarlighetsgrad) och facility (källkategori). Tillsammans bildar de prioritetsvärdet PRI, som beräknas som facility × 8 + severity. Severity ger åtta nivåer från noll till sju:
| Severity | Namn och betydelse |
|---|---|
| 0 | Emergency, system är obrukbart |
| 1 | Alert, åtgärd måste vidtas omedelbart |
| 2 | Critical, kritiska tillstånd |
| 3 | Error, felmeddelanden |
| 4 | Warning, varningar |
| 5 | Notice, normalt men noterbart |
| 6 | Informational, informationsmeddelanden |
| 7 | Debug, debug-information |
Facility identifierar källan, exempelvis kernel (0), mail (2), authentication (4) eller en av åtta lokala kategorier (16 till 23). Många nätverksprodukter använder en lokal facility för att skilja sina meddelanden från operativsystemets.
Populära syslog-servrar
Det finns flera mjukvaror som tar emot, lagrar och analyserar syslog. Valet beror på storlek på miljön, budget och behov av analysverktyg. Här är de mest använda:
- rsyslog: Standard på de flesta Linux-distributioner. Lätt, snabb och flexibel. Bra för enklare installationer
- syslog-ng: Mer avancerad parser och flödesmotor än rsyslog. Stark integration med moderna lagringssystem
- Graylog: Komplett analyssystem med webbgränssnitt, larm och instrumentpaneler. Bygger på Elasticsearch eller OpenSearch
- Splunk: Kraftfullt och dyrt analyssystem. Mycket vanligt i större företagsmiljöer och SOC
- Elastic Stack: Elasticsearch, Logstash och Kibana. Öppen källkod med kommersiella tillägg
Så sätter du upp en enkel rsyslog-server
En rsyslog-server på Ubuntu är snabb att sätta upp och räcker för att samla in loggar från ett mindre antal enheter. Stegen ser ut så här:
- Installera paketet:
sudo apt install rsyslog - Öppna konfigurationen:
sudo nano /etc/rsyslog.conf - Avkommentera raderna för UDP-mottagning:
module(load="imudp")ochinput(type="imudp" port="514") - Lägg till en regel som styr inkommande loggar till en fil per host:
$template RemoteLog,"/var/log/remote/%HOSTNAME%.log" - Starta om tjänsten:
sudo systemctl restart rsyslog - Öppna brandväggen för port 514 UDP:
sudo ufw allow 514/udp - Konfigurera klienterna att skicka loggar till serverns IP-adress
Säkerhet och åtkomst
En central syslog-server är en attraktiv måltavla. Loggar avslöjar nätverkets uppbyggnad, vilka system som finns och i värsta fall användarnamn och händelser som kan användas för att kartlägga miljön. Tre säkerhetsåtgärder är minimum:
- Skydda mottagaren med en brandvägg som bara släpper in trafik från kända loggkällor
- Kryptera trafiken med TLS så att loggarna inte kan avlyssnas eller manipuleras under transport
- Begränsa åtkomst till lagringen så att bara behöriga administratörer kan läsa eller radera loggar
Loggar bör helst vara skrivskyddade efter inläggning. Skickas de vidare till ett separat backup-system blir det svårare för en angripare som tagit kontroll över syslog-servern att radera spår.
Vanliga problem
Misslyckad syslog-mottagning beror oftast på en handfull konkreta orsaker. Hur loggar bäst korreleras med andra prestandadata behandlas i en separat genomgång av serverövervakning. Här är de tre vanligaste felen:
- Tappade UDP-paket: Vid hög belastning eller smal länk tappas meddelanden. Lösning: byt till TCP eller höj operativsystemets UDP-buffrar
- Fel tidszon på avsändaren: RFC 3164 saknar tidszon. Klienten måste konfigureras med korrekt zon eller använda RFC 5424
- Klockor som gått isär: Korrelering över flera enheter kräver att klockorna är synkroniserade. Använd NTP på alla syslog-källor
