Syslog in de 21e eeuw

Syslog in de 21e eeuw

DearBytesBlogSyslog in de 21e eeuw

dinsdag 1 december 2015

Syslog bestaat al 35 jaar (het is in 1980 bedacht door  Eric Allman als onderdeel van Sendmail) en is tot op de dag van vandaag hét mechanisme om system logging van Unix-systemen en appliances met Unix op te slaan en te versturen naar (bijvoorbeeld) een SIEM. Syslog heeft voor- en nadelen, maar hoewel er wel ontwikkelingen zijn in syslog, lijken veel organisaties nog gebruik te maken van oude, onveilige syslog-methodieken.

Het syslog-protocol is gestandaardiseerd in RFC 3164 (later vervangen door RFC 5424) en beschrijft het mechanisme waarmee syslog-berichten worden verstuurd. Tijdens het ontwerp is gekozen voor eenvoud en snelheid, waardoor er concessies zijn gedaan aan de security. Syslog wordt standaard niet versleuteld verstuurd, en vaak via UDP. Er is geen beperking van zogenoemde control characters (denk aan een backspace), waardoor een aanvaller berichten kan wijzigen. Ook bestaat er geen replay-mogelijkheid, zodat berichten tijdens het transport van server naar SIEM voorgoed verloren kunnen gaan. Het grootste probleem is echter dat elke leverancier zijn eigen interpretatie van syslog heeft. Het komt vaak voor dat headers niet conform RFC zijn of een eigen logformaat aanhouden, en dat heeft weer gevolgen voor het correct parsen in SIEM.

BIVV en CIAA

syslog-blog_logs_display-De afkorting BIV (of CIA) zullen voor de meesten wel bekend zijn, maar al jaren wordt geopperd dat verantwoordelijkheid (accountability) hieraan zou moeten worden toegevoegd. Verantwoordelijkheid houdt in dat iemand verantwoordelijk kan worden gehouden voor bepaalde acties. Stel dat een gebruiker heeft geprobeerd om een firewall-configuratie aan te passen zonder dat er een wijzigingsaanvraag voor is ingediend. Door die aanpassing komt vervolgens een aanvaller binnen in het netwerk. U wilt dan graag achteraf kunnen zien wie wat heeft gedaan, waar en wanneer. Om verantwoordelijkheid te kunnen aantonen moeten we onbetwistbaar laten zien dat gebruiker X wijziging Y heeft doorgevoerd. De SIEM houdt al dit soort informatie bij, maar er wordt nu gebruikgemaakt van een protocol dat totaal geen garantie biedt. Syslog biedt geen garantie dat een bericht aankomt, dat het bericht niet is aangepast tijdens het transport, dat het überhaupt van de bron afkomstig is en dat het goed wordt verwerkt in de SIEM.

De grote vraag is dan ook waarom het bedrijfsleven nog zo vasthoudt aan het huidige format van syslog, terwijl de waarde van de berichten steeds groter wordt. We hebben inmiddels de meeste cleartext-protocollen (telnet, ftp) uit ons netwerk verbannen, maar syslog in cleartext blijft in 2015 nog steeds actueel. Waarom?

CEF en TLS

Een van de redenen is dat er vanuit leveranciers nog geen druk is om naar een ander format over te gaan. Er zijn in het verleden verschillende initiatieven geweest om syslog te verbeteren. Zo is CEF een format om het bericht in syslog te uniformeren, maar veel leveranciers voelen zich hierdoor helaas toch te beperkt, en gaan voor een eigen format. Ook JSON en XML komen op als gestandaardiseerd format, maar het zal nog jaren duren voordat leveranciers hierop overstappen. Er zijn ook al initiatieven geweest om een beter protocol te maken dan syslog. RSYSLOG is bijvoorbeeld zo’n systeem. Syslog-NG is een ander voorbeeld. In de afgelopen jaren zijn deze systemen geëvolueerd van een reguliere syslog-deamon tot een systeem dat op een veilige manier syslog kan versturen. Zo bestaat er de mogelijkheid tot gebruik van TLS en biedt het meer betrouwbaarheid doordat syslog-berichten niet kwijt kunnen raken tijdens het transport, of wanneer het systeem tijdelijk niet beschikbaar is (bijvoorbeeld tijdens een herstart). Het mooie is dat de SIEM van Intel Security TLS syslog al sinds 2012 ondersteunt.

Het belang wordt groter

Zelfs RFC 5424 adviseert het gebruik van TLS voor transport, maar waarom gebruiken organisaties dit dan niet? Dit heeft veelal te maken met risicobepaling en acceptatie. Op veel systemen is syslog al geconfigureerd en het activeren van TLS kan veel tijd vragen. Tevens worden door veel organisaties het eventuele verlies van informatie en de onzekerheid over integriteit voor lief genomen ten behoeve van eenvoud en snelheid. Ik zie echter dat bij veel organisaties nu een groter belang wordt gehecht aan deze logs. Vanuit De Nederlandse Bank wordt bijvoorbeeld meer druk uitgeoefend om meer aandacht te besteden aan SIEM, encryptie, logging en monitoring. Maar ook de aankomende meldplicht datalekken legt meer druk op het belang van een SIEM en een betrouwbare verzameling van berichten.

Denk bij de implementatie van een SIEM dus niet alleen na over de manier van verzameling en opslag, maar ook over de manier van transport en het formaat van de inhoud. Hoe belangrijker de informatie is voor uw organisatie, hoe meer u de nadruk moet leggen op een betrouwbare transportmethode en een betrouwbare manier van parsen.