Standardised Syslog Processing ... -...

8

Transcript of Standardised Syslog Processing ... -...

Rasmus Dahlberg a

nd Tobias Pulls |

Standardised Syslog Processi

ng

Standardised Syslog Processing

Today’s computer logs are like smoking guns and treasure maps in case of suspicious

system activities: they document intrusions, and log crucial information such as

failed system updates and crashed services. An adversary thus has a clear motive

to observe, alter, and delete log entries, considering that she could (i) start by using

the log’s content to identify new security vulnerabilities, and (ii) exploit them

without ever being detected. With this in mind we consider syslog standards and

open source projects that safeguard events during the storage and transit phases,

and examine how data compression effects security. We conclude that there are

syslog standards in place that satisfy security on a hop-by-hop basis, that there

are no such standards for secure storage, and that message compression is not

recommended during transit.

WORKING PAPER | September 2016

Faculty of Health, Science and Technology

Department of Mathematics and Computer Science

Faculty of Health, Science and Technology

Rasmus Dahlberg and Tobias Pulls

Standardised Syslog ProcessingRevisiting Secure Reliable Data Transfer and

Message Compression

StandardisedSyslogProcessing

RevisitingSecureReliableDataTransferandMessageCompression

RasmusDahlbergKarlstadUniversity,Dept.ofMathematicsand

ComputerScience,Sweden

TobiasPullsKarlstadUniversity,Dept.ofMathematicsand

ComputerScience,Sweden

ABSTRACTToday’scomputerlogsarelikesmokinggunsandtreasuremapsincaseofsuspicioussystemactivities:theydocumentintrusions,andlogcrucialinformationsuchasfailedsystemupdatesandcrashedservices.Anadversarythushasaclearmotivetoobserve,alter,anddeletelogentries,consideringthatshecould(i)startbyusingthelog’scontenttoidentifynewsecurityvulnerabilities,and(ii)exploitthemwithouteverbeingdetected. Withthisinmindweconsidersyslogstandardsandopensourceprojectsthatsafeguardeventsduringthestorageandtransitphases,andexaminehowdatacompressioneffectssecurity. Weconcludethattherearesyslogstandardsinplacethatsatisfysecurityonahop-by-hopbasis,thattherearenosuchstandardsforsecurestorage,andthatmessagecompressionisnotrecommendedduringtransit.

KeywordsSyslog,standardisedlogging,securedatacompression

1. INTRODUCTIONAcomputerlogwithdescriptionsofpastactivitysuchas

fileaccess,authorisationdecisions,andsystemdiagnosticsis,andhavelongbeen,aninvaluableresourceforsystemadministratorsduringtroubleshooting.Forexample,legacysyslog[18]datesbackasfarasthe1980s,andtobeginwiththeoriginaldesignhadlittleinterestinsecurity[13]. Thiscontradictsthecurrentneeds,consideringthattoday’slogscontainsensitivedatathatmustnotbeobserved,dropped,oraltered:securitynotifications,users’systemtraces,andsoforth.Inotherwords,itisessentialtoensuresecurelogmanagementonaprotocolandinfrastructurallevel,asisidentifiedinthesyslogrelatedrequestforcomments(RFCs)andinacomprehensivesurveypublishedbytheNationalInstituteofStandardsandTechnology(NIST)[14].Theconsequencesofunsecurelogmanagementisevidently

devastating.Considerwhatwouldhappeniflogentriesweretamperedwith,deleted,ormaliciouslyinsertedintothelogbyanadversary.Thetracesofanentireattackcouldeasilybehidden,andfalseevidenceproducedforevilpurposes.Evenmoreseverely,disclosureoftheusers’sensitivedatahaspreviouslydrivenpeopletosuicide[2]. Thus,asecurelogginginfrastructurecannotrunasifitmerelycontainsde-bugginginformation. Theimpactof,e.g.,denialofserviceattacks,confidentialitybreaches,andintegritycompromisesmustbecarefullyconsideredandaccountedforaccordingly,preferablydependingonwell-definedpolicies.

Currentlytherearemanysyslogrelatedstandards,someofwhichareoldorobsolete[23,30,31]andothersthatarequiterecent[9,10,13,20,24]. Apartfromthestandards,multipleopensourceprojectsexistthatprovidesecurelogmanagementsolutions[32,35].Intheresearchcommunitytherehasalsobeenseveralprevalentadvancements, mostnotablyincludingforward-secureconstructions[4,19].Ifthisisapplicable,however,isdependentonthesetting.Forinstance,aforwardsecureschemeservesnopurposewhenasystem’sdeviceshavetobetrustedatalltimes.

1.1 TerminologyandSettingWeconsiderthreetypesoftrusteddevices,namely origi-nators,relays,andcollectors.Anoriginatorgenerateseventsthataresentacrossanunreliableandunsecurenetwork.Theeventsareformattedassyslogmessages,andmaybesenttomultiplerelaysandcollectors.Uponreceiptofanevent,arelayispreconfiguredtoserveaforwardingfunction.Thecollectors,ontheotherhand,archiveeventsandperformloganalysis.Adevicecanbeanycombinationoforiginator,relayandcollector.Figure1depictsoursetting. Anactiveadversarythatiscomputationallyboundedintercepts,examines,modifies,delays,andreplayseventsintransit.Shemayalsoattempttocauseavailabilityissuesbyinjectingmaliciouseventstoexhaustbothrelaysandcollectors. Further,thirdpartiesthatareabletoauthenticatethemselvesquerythecollectorsforevents,demandingverifiableresponseswithregardtotheoriginatorthatgeneratedwhicheventatroughlywhattime.

CollectorRelay

Originator

Client

query

answerm2

m1 m1

m2

Figure1:Asketchofoursetting.

Fororiginatorsandrelays,spaceisalimitedresourceintheorderofafewgigabytes. Thecollectorsareassumedtobemorepowerful,anditisdesirabletosavebandwidthwithoutcompromisinganysecurity. Wedonotconsiderreplicationatthecollectors,butthisisinherentlysupportedbythemodelsinceacollectorcanalsobearelay.

1

1.2 GoalandScopeWewishtoexaminesyslogstandardsandrelatedconcepts

thatareapplicabletoUnix-likeenvironments. Theaimistoprovideguidelinesbasedonoursettingwherealldeviceshavetobetrusted,andwehopetofindsolutionsthatoffer:

–Reliabletransportbetweenthedifferentdevices;

–Confidentiality,integrity,andavailability;

–Originauthenticationonaper-messagebasis,i.e.,whichoriginatorgeneratedwhatmessage.

Itisalsodesiredthatweconsidersecuredatacompressionduringtransitandlong-termstorage. Ourscopeislimitedtostandardisedandwellestablishedopensourceprojects.

1.3 RoadmapTheremainderofthereportisstructuredasfollows.Sec-

tion2providesanoverviewofexistingsyslogstandardsandthesecuritypropertiestheyenforce. Section3highlightspopularopensourceprojectsrelatedtoscalableandsecurelogginginfrastructures.Section4introducestechniquesfordatacompressionandhowtheyeffectsecurity. Section5setsourdiscussionintocontext,providingguidelinesbasedonbestpractices.Finally,Section6concludesthereport.

2. SYSLOGSTANDARDSFirstweintroducepastdevelopmentandimportantnotes

regardingthesyslogprotocol,thenthelateststandardsforreliabledatatransferandsecurityareexamined.

2.1 TheSyslogProtocolAfterawideuseacrossnetworksformanyyears,observed

behaviourofBSDsyslogwasdocumentedinRFC3164[18].Theintentwastoprovideasimpleprotocoltransportingeventsfromsourcestosinks,resultingintheuseofUDPwithoutacknowledgementsandsecurityconsiderations.RFC3164waslaterondeclaredobsoleteandprecededby

astandardinRFC5424[9].Alayeredarchitectureintermsofanapplicationandtransportlayerwasintroduced,andanewstructureforthemessageformatdefined. Whilenoneofthetraditionalsecuritypropertieswereaddressed,severalencodingissueswereresolvedandacommongroundtobuilduponprovided.Inotherwords,toattainpropertiessuchasguaranteeddelivery,confidentiality,andintegrity,otherstandardsorvendorspecificsolutionsmustbeconsidered.

2.2 UDPandTCPTransportMappingsDespitethegeneralinteresttosecuresyslog,exceptions

existwhereinatraditionaltransportlayersuffices.ForsuchpurposestherearebothUserDatagramProtocol(UDP)andTransmissionControlProtocol(TCP)mappingsdefinedforsyslog[10,24]. Noneoftheseoptionsareentirelyreliable,however,becausesyslogissimplexwithoutanyapplicationlevelacknowledgements. Forinstance,itcanbenontrivialtodeterminewhichmessageshavebeencorrectlyreceivedintheeventofaprematurelyclosedTCP-connection. Aseparaterecoverymechanismmaythereforebenecessary.TheTCPtransportmappingisnotwithoutdrawbacks.

Thereislittlecontrolregardingwhenapacketissent,andbydesignthethroughputislessthanthatofUDP.TheTCPpushflagmighthelptoensurethatimportanteventscannotresideinsidebuffersforlongperiodsoftime,but

extralatencyisinevitabledueto,e.g.,theinitialhandshakeandcongestionmechanism.Furthermore,ifTCPisfeasible,itislikelythattheTransportLayerSecurity(TLS)mappingisapplicable(seeSection2.3). TheDatagramTransportLayerSecurity(DTLS) mappingforsyslogcouldalsobeofinterestincircumstanceswherereliabledatatransferisirrelevantortoocostlyintermsofoverhead[34].

2.3 TLSTransportMappingTheuseofTLSisrecommendedtoprotectsyslogevents

onahop-by-hopbasis,i.e.,intransitfromoriginatorsandrelaystootherrelaysandcollectors[9,24].Forthispurpose,thereisaTLStransport mappingdefinedforsyslog[20].Mutualauthenticationispreferablycertificate-based,andconfidentialityandintegrityispreservedbyencapsulatingallsyslogmessagesasTLSapplicationdata.Notethatreliabledatatransferisnotnecessarilyprovided(seeSection2.2),anddenialofserviceisonlypartiallyguardedagainstduetotheprovidedauthenticationcapabilities. WewilldiscussselectionofTLSciphersuiteslateroninSection5.2.

2.4 IPsecforSyslogInternetProtocolSecurity(IPsec)isasecurityprotocolthatoperatesonthenetworklayer[15].AlltransportlayerservicesthatrunontopofIPsecwillthusreaptheharvestfromtheprovidedsecurityproperties,followingfromtwoassociatedIPsecprotocols. First,anauthenticatedheaderoffersintegrity,originauthentication,andoptionalreplayresistance.Second,anencapsulatedsecuritypayloadoffersthesamesetofservicesaswellasconfidentiality. Bothofthetwoprotocolssupportaccesscontrol,andrunineithertransportortunnel mode. Thedifferent modesdeterminedetailsregarding,e.g.,howadatagramshouldbeprocessed.WhatisnotapparentfromthisbriefintroductionisthatIPsecisacomplexprotocolwithmanyquirks[26].Itspanshundredsofpages,andevenseveralRFCs.However,whilecomplexityisoftenconsideredasecurityconcern[8],IPsecdoesaddressmanysecurityissuesifimplementedcorrectly.

2.5 SignedSyslogMessagesSyslog-sign[13]usesthestructureddataelementsdefined

inRFC5424[9]toauthenticateastreamofsyslogmessages,introducingsignatureandcertificateblocks. AsdepictedinFigure2,asignatureblockcontainshashesofpreviouslysentmessagesandisdigitallysigned. Theassociatedkey ma-terialisdistributedperiodicallythroughcertificateblocks,andmustbeprotectedexternally,e.g.,viaTLS,topreventman-in-the-middleattacks.Itshouldbenotedthatneithersignaturenorcertificateblocksareincludedinthestreamofsignedmessages. Theyare,however,encodedusingthesyslogmessageformat.

... s e H(ms) ... H(me) σ

p;σ← Sig(sk,p)

Figure2: Therationalebehindsignatureblocks;sanderefertothefirstandlastmessageindices,respectively.

Theresultingsyslog-signprotocolprovidesintegritycheck-ing,sequencingofevents,andoriginauthentication.Thus,replayattacksandmissingeventscanbeaccountedfor.Inaddition,twoproceduresforonlineandofflineverification

2

aredefined,andvendorspecificverificationissupported.Finally,duetosignaturegroups,eventscanbegroupedandsignedseparatelybytheoriginator. Thisisanimportantfeaturewhendifferenteventsshouldbeforwardedtovari-oussetsofcollectors,e.g.,dependingonapplication,priority,andreplicationpolicy.

3. OPENSOURCEPROJECTSSeveralopensourceprojectsexistthatareaimedtowards

securelogmanagement. Webrieflydescribetwoofthemostestablishedones,namelysyslognewgeneration(syslog-ng)andtherocket-fastsystemforlogprocessing(rsyslog).Thenaloggingutilitythatresideswithinsystemdishighlighted.

3.1 Syslog-ngSyslog-ng[35]isacentralisedlogginginfrastructurethatisavailableonmanyhardwarearchitecturesandoperatingsystems,includingx86andUnix-likeenvironments.Amongotherfeatures,suchasdatabasemanagementandfiltering,thereissupportforreliabledatatransfer,messagesecrecyandintegrity,andmutualauthentication.Syslog-ngisalsocompatiblewithIPv4/IPv6networks,andtheclient,relay,andservermodesareparticularlyconvenientforoursetting.Notethatsyslog-ngisnotintendedforloganalysis:itcan

performrule-basedfilteringandtransform messagesfromoneformattoanother,butnotinterprettheir meaning.Moreover,thereiscurrentlynomechanismdefinedthatcangenerateproofswithregardtotimeandorigin.

3.2 RsyslogRsyslog[32]isacentralisedlogginginfrastructurethat

isavailableonseveralLinuxdistribution,includingUbuntuandCentOS.Thereissupportforfeaturessuchasdatabases,filtering,andsecurityadd-ons,whereinreliableandsecuretransitisenforcedusingTCP/TLS,andakeylesssigna-tureinfrastructureguardsagainstunauthorisedlog modi-fications. Likesyslog-ng,rsyslogdoesnotincorporatethesyslog-signprotocol. Therefore,neithermessageoriginnorthetimeofeventgenerationcanbeproventoathirdparty.Interestingly,rsyslogsupportsdatacompressionduring

transitforstreamsandindividualmessages. AsdescribedfurtherinSections4–5,thiscouldbeasecurityissue.

3.3 JournaldandSystemdThejournaldisaloggingutilitythatispartofthesystemd

daemon.Itisrelatedtosyslog,supportingstructuredbinaryencodings[37]andforwardsecuresealing[27]. Theformerincreasesstorageandautomatedsearchefficiency,whilethelatterwilllikelydetectanadversarythattamperswithpastlogentries.Itshouldbenotedthattheeffectivenessofsuchintegrityprotectionreliesonacheckpointfrequency,i.e.,howoftenkeymaterialissecurelyincremented,anditas-sumesthatdeletionoftheentirelogcanbedetectedbyothermeans.Asacaveat,thecheckpointfrequencymightnotbesufficientlylargebydefault.Thus,ensurethatisconfiguredproperlyforthesysteminquestion.

4. DATACOMPRESSIONForthewell-beingoftheentireInternet,itisofgeneral

interesttoreducebandwidthrequirements.Likewise,thereare manygainsinreducingstoragerequirements.Inthissectionweaimtohighlightpotentialsecurityissueswith

themostcommoncompressiontechniques,whichwillbeourbasiswhendiscussingthesubjectspecificallyforoursetting.

4.1 HuffmanCodingAtraditionalcharacterencodingrepresentseachsymbolwithequally manybits. Huffmancodingaimstoreducethenumberofbitsforthemostfrequentsymbols,therebyyieldingasuccinctrepresentationoftheoriginalstring[12].Forexample,withUTF-8,thestring“Mississippi”requires88← 11·8bits.AsshowninFigure3,thiscanbereducedto21bitsusingHuffmancodingasfollows.First,countthefrequencyofeachletterandordertheminincreasingorder.Second,repeatedlybuildabinarytree,bottom-up,wherethetwonodeswhosecombinedsymbolfrequenciesarethesmallest.Eachleftandrighttraversalisinterpretedaszeroandone,respectively.Finally,theresultingpathsdowntotheleavesdefineanoptimisedcharacterencoding.

(a)

fi 4s 4p 2M 1

(b)

ispM11

spM7

pM3

M1p2

s4

i4

(c)

ei 0s 10p 110M 111

Figure3:AHuffmanencodingfor“Mississippi”,resultinginthebinarystring111010100101001101100.

4.2 TheLempel-ZivFamilyTheseminalpaperbyZivandLempel[38]introduceda

compressionmechanism(now)namedLZ771.AsopposedtoHuffmancodingthattargetsindividualsymbols,repeatedsequencesarereplacedwithbackwardreferencestoreduceredundancy. Thebasicprincipleisasfollows. Acharacterstreamisprocessed,andaslidingwindowisadvancedsuchthatthereisasearchbuffertotheleftandalook-aheadbuffertotheright. Foreachwindowposition,thelongestprefixmatchisfirstdeterminedinthesearchbuffer. Next,itisreplacedwithareferenceontheform<d,l,c>,wheredisadistancetothepreviousoccurrence,litslength,andcthenextcharacterinthelook-aheadbuffer. Finally,thewindowisforwardedbyd+1steps.Anexamplebasedonthestring“Mississippi”isshown

inTable1. Thelongestprefixmatchinthesearchbufferishighlightedbyagraybackground,thenextcharacterinthelook-aheadbufferisbold,andtheresultingstringis<0,0,m><0,0,i><0,0,s><1,1,i><3,3,p><1,1,i>.Inpractise,thesizeofthesearchandlook-aheadbuffersarefixedinadvance,andnodelimitingcharactersareused.ThereisanentirefamilyofcompressionalgorithmsthatarerelatedtotheworkofZivandLempel. Thedifferentvariationsoffertrade-offswithregardtocompressiontimeandratio,andcanbecombinedwithotherapproaches.OnesuchcombinationisDEFLATE[5]:applyLZ77,followedbyHuffmancoding.Forfurtherdetails,pleaserefertothecomprehensivebookondatacompressionbySalomon[33].

1LZisanacronymfortheauthors,LempelandZiv,and(19)77referstotheyearofpublication.

3

Table1:DerivinganLZ77encodingfor“Mississippi”

i Search Look-ahead Output1 Mississippi <0,0,M>2 M ississippi <0,0,i>3 Mi ssissippi <0,0,s>3 Mis sissppi <1,1,i>

4 Missi ssippi <3,3,p>5 Mississip pi <1,1,i>

6 Mississippi

4.3 AttackingCompressionMechanismsWithoutdoubt,thepastdecadesshowhownontrivialthe

designandimplementationofsecurecomputersystemare.Yettodate,newvulnerabilitiesarefoundinSSL/TLS[25],certificateauthoritiesarecompromised[16,29],andnationalstateagenciesbreaksupposedlysecuredevices[21]. Whileisolatedcryptographicprimitivesmightbesecureontheirown,securitydoesnotcompose.Infact,proceduresthatwereneverintendedforsecuritycancausetrouble.OnesuchexampleisdatacompressionwhenappliedtoTLS[11].CompressionRatioInfo-LeakMadeEasy(CRIME)isan

exploitdevelopedbyRizzoandDoung[7].Anadversaryisabletohijacktheusers’privateTLSsessionsbyguessingtheauthenticationcookiesifthefollowingconditionsaremet:

–Theadversarycanobservethenetworktraffic,e.g.,viaawirelessmedium.

–Theadversarycaninjectcodeintothevictim’sbrowser,e.g.,byprovidingamaliciouslinkthatisclicked.

–ThevictimauthenticatesoveranHTTPSconnectionthatusesanLZ-likecompressionmechanism.

Theattackproceedsasfollows.First,theadversaryinjectscodeintothevictim’sbrowser. Thisallowsforachosenplaintextattack. Next,specialHTTPrequestsarecraftedsuchthatthesecretcookiecanbebrute-forcedonesymbolatatime. Finally,aguessisconsideredcorrectwhentheobservedciphertextisreducedduetoincreasedredundancy.Inotherwords,thetrickisthatarbitrarilychosenstringsarecompressedtogetherwiththesecretinformation,andLZ77causescorrectguessestoproducesmallerciphertexts.SomeoftheproposedcountermeasuresagainstCRIME

includenevercompressingsecretsandadversarycontrolleddata. Thesafestoption,however,appearstobedisablingcompressionalltogether2.Forinstance,inthefootstepsofCRIMEfollowBREACH[28]andTIME[3]. TheytargetthecompressionofHTTPresponses,andTIMErelaxestheprerequisitestolaunchasuccessfulattackbyeliminatingtheneedtoeavesdrop.Thus,weconcludethatdatacompressionisasensitivetopicthatmustbecarefullyconsidered.

5. RECOMMENDATIONSFirstweprovideanoverviewofwhattheexistingsyslog

standardscanandcannotaccomplishinoursetting,thenadditionaldetailsregardingcryptographicprimitives,securedatacompression,andverifiablequeriesarediscussed.

2ThecurrentdraftforTLS1.3removesdatacompression.

5.1 OverviewInasettingwherealldeviceshavetobetrusted,theex-

istingsyslogstandardscansupportthefollowingproperties:

–Confidentialityandintegrityduringtransit.UseTCP,anapplicationlevelrecoverymechanismforfullreliability,andeitherIPsecorTLS.

–Serverand mutualauthentication.UseastrongauthenticationmechanismbasedonTLSorIPsec.

–Originauthenticationandreplaydetection. Usesyslog-sign.Thiswillalsodetectmissingeventsduetoasequencingscheme,andthesignatureblockswillbetheproofsofcorrectnessforthequeryingclients.

Despitecombiningvarioussyslogstandards,thefollowingpropertiescannotbeprovided:

–Securestorage. Neitherconfidentiality,integrity,noravailabilityisensuredduringstorage.

–Secure DataCompression.Nosuchstandardsaredefinedforsyslog.

–Availability. Whilemutualauthenticationhelpstopreventdenialofservice,filteringandlogrotationisnecessarytoassurethatanadversarycannotexhaustthenetworkanditsdevices.ForlogrotationthereisaLinuxservicethatmightbeuseful[36].

Finally,itshouldbenotedthatasignificantamountofoverheadwillbeintroducedwhenoneswitchesfromlegacysyslogtoasecurelogginginfrastructure. Theopensourceprojectsmightbeapplicableforsomevendors,anditislikelythatthejournaldloggingutilityisworthconsidering.

5.2 SelectingCryptographicPrimitivesItappearsthattherearenocurrentrecommendationswhenselectingcryptographicprimitivesforsecurelogging:thepresentedopensourceprojectsprovidenohelpinthisregard,andthesyslogstandardsareold. Therefore,wesuggestthattheguidelinesprovidedbyGoogle’ssecurityresearchersbefollowed,andpossiblythattheciphersuitessupportedbyChromeandFirefoxcouldbeconsidered3.Langley[17]discussedselectionofTLSciphersuitesatthe

Googlesecurityblog.HeconcludedthatTLS1.0shouldbeavoidedduetoseveralknownflaws,includingthosefoundinthestreamcipherRC4,andthatTLS1.1shouldbeavoidedtoo,ifpossible. Forinstance,theCBCblockciphermodeisvulnerabletotwoattacks: BEAST[6]andLucky13[1].Theformertargetsthegenerationofinitialisationvectorsandhasbeenpatched,whereasthelatterisatimingat-tackthatcouldbepreventedbyproperconfigurationoftheTLSserver.However,itisimpossiblefortheTLSclientstoknownifthatisthecaseinadvance.Thus,likeLangley,wedonotrecommendsuitesbasedonRC4orCBCmode.Instead,thebetteroptionistoselectsuitesofferedbyTLS1.2,inparticularthosebasedontheGCMblockciphermodeortheChaCha20-Poly1305cipher.Forexample,onaWindowsmachinethatrunsChromeversion51.0.2704.103,128-bitsecuritywithAESinGCMmodeisthefirstchoice,

3Todeterminetheciphersuitessupportedbyaparticulararchitecture,operatingsystem,andbrowser,visithttps://cc.dcsec.uni-hannover.dewiththeset-upinquestion.

4

thenChaCha20-Poly1305.EllipticcurvesarealsofavouredoverRSAforkeyagreementandauthentication,andSHA-256asthemessageauthenticationprimitive.Inotherwords,thefollowingciphersuiteswith128-bitkeysarerecommended:

–ECDHE-ECDSA-AES128-GCM-SHA256;

–ECDHE-RSA-AES128-GCM-SHA256;

–ECDHE-ECDSA-CHACHA20-POLY1305-SHA256;

–ECDHE-RSA-CHACHA20-POLY1305-SHA256.

Furthermore,avoidoldsuitesthatoriginatefromTLS1.0,andpaycloseattentiontothereleaseofTLS1.3.Sincetheciphersuitesalreadyselectahashfunctionand

adigitalsignaturescheme,wesuggestthatthoseprimitivesareusedifsyslog-signisinplace. ForcompatibilitywithRFC5848[13],newversionnumbersmustbedefined.

5.3 SecureDataCompressionThemorestructurethereisinthedatabeingcompressed,

theeasieritistoseparatesecretsfromadversarycontrolleddata.Forsyslog,especially,suchseparationcouldbefeasibleifthestandardisedmessageformatisused.First,somefieldsmightnotbeconsideredconfidential,inwhichcasetheycanbecompressedwithoutlosinganysecurity. Second,ifanadversaryisunabletogenerateplaintextforcompression,allotherfieldscouldbecompressedsecurely. Whilethefirstapproachisstraightforwardandeasilymappedfromasecuritypolicy,thelatterisnontrivialbecauseanadversarycanlikelyinfluencethegeneratedevents.Consideringtheinvolvedcomplexitywhenattemptingto

compressdataduringtransit,wedonotrecommendit.Inaddition,evenifonemanagestoseparatesecretsandusercontrolleddata,itisquestionablewhethertheresultingband-widthgainsaresignificantenough.Duringstorage,however,datacompressionentailsnoknownissues. Werecommenditbecauseitfavoursavailability.

5.4 VerifiableQueriesClientsthatquerycollectorsforeventsdemandproofsof

correctness.Forthispurpose,wesuggestaccompanyingtheretrievedeventswiththecorrespondingsignatureblocks.Aclientacceptssuchproofsiftheretrievedeventsarehashedcorrectlyandifthesignaturesareauthentic. Thissufficesbecauseeverythingistrusted,asbothtimeofgenerationandorigincanbevouchedforbytheoriginator’ssignature.Itisquestionablewhethersyslog-signisworthwhilewhen

alldevicesaretrustedandTCP/TLSisinplace. Clearly,eachmessagewillarriveintacttothecollectors,andsincealldevicesaretrustedtheyshouldnotaltertheoriginators’identifiersandtimestamps. Thereforesequencingschemesandsignaturesservelittletonopurpose,whichmightbethereasonwhynoneofthepopularopensourceprojectssupportit.Nevertheless,NetBSDprovidesanoldimplementationofsyslog-signthatcouldbeinterestingtoexamine[22].

6. CONCLUDINGREMARKSOurgoalwastoexamineexistingstandardsthatsecure

syslog,bothduringthestorageandtransitphases. Wefoundthatthereexistnosuchstandardsforstorage,butavail-ability,integrity,andconfidentialitycanbeguardedagainstduringtransit. Astandardisedprotocolforsigningsyslog

messageswasalsodiscovered,andcanbeusedtoprovethedevicesthatgeneratedwhicheventsatroughlywhattimes.Italsodetectsmissingevents,anddefinesacountermeasureagainstreplayattacks.Thesyslogrelatedstandardsfailtoprovideguidelineson

howtoselectcryptographicprimitives,andtheyarenotasusefulunlessalldevicesaretrusted.Likewise,theopensourceprojectsfailinthisregardtoo,buttheyareapplicableforoursettingifsyslog-signisimplemented.Inaddition,weexaminedhowmessagecompressioneffectssecurity,andconcludedthatitmightbedangerousbecauseitintroducescomplexitywithpresumablysmallgains.Finally, weencouragethereadertoconsiderasetting

wherethedevicescanbecompromisedatsomepointintime.Thenjournaldisaprevalentfirststeptoprotectthelog’sintegrity,andsimilarapproachescanbeusedtoensureconfidentiality.

7. ACKNOWLEDGEMENTWewouldliketothankStefanLindskogforhisvaluablefeedback.RasmusDahlbergandTobiasPullshavereceivedfundingfromtheHITSresearchprofilefundedbytheSwedishKnowledgeFoundation.

8. REFERENCES[1]N.J.AlFardanandK.G.Paterson.Luckythirteen:BreakingtheTLSandDTLSrecordprotocols.InIEEESymposiumonSecurityandPrivacy,pages526–540,May2013.

[2]C.Baraniuk.Ashleymadison:’suicides’overwebsitehack.BBCNews,August2015.http://www.bbc.com/news/technology-34044506.

[3]T.Be’eryandA.Shulman.AperfectCRIME?OnlyTIMEwilltell.BlackHatEurope,March2013.

[4]K.D.Bowers,C.Hart,A.Juels,andN.Triandopoulos.PillarBox:Combatingnext-generationmalwarewithfastforward-securelogging.InResearchinAttacks,IntrusionsandDefenses—17thInternationalSymposium,pages46–67,September2014.

[5]P.Deutsch.DEFLATEcompresseddataformatspecificationversion1.3.RFC1951,May1996.InternetRequestsforComments.

[6]T.DuongandJ.Rizzo.BEAST:SurprisingcryptoattackagainstHTTPS.ekopartySecurityConference,September2011.

[7]T.DuongandJ.Rizzo.TheCRIMEattack.ekopartySecurityConference,September2012.

[8]N.FergusonandB.Schneier.AcryptographicevaluationofIPsec,December2003.https://www.schneier.com/academic/paperfiles/paper-ipsec.pdf.

[9]R.Gerhards.Thesyslogprotocol.RFC5424,March2009.InternetRequestsforComments.

[10]R.GerhardsandC.Lonvick.TransmissionofsyslogmessagesoverTCP.RFC6587,April2012.InternetRequestsforComments.

[11]R.Holz,Y.Sheffer,andP.Saint-Andre.Summarizingknownattacksontransportlayersecurity(TLS)anddatagramTLS(DTLS).RFC7457,February2015.InternetRequestsforComments.

[12]D.A.Huffman.Amethodfortheconstructionof

5

minimum-redundancycodes.ProceedingsoftheIRE,40(9):1098–1101,September1952.

[13]J.Kelsey,J.Callas,andA.Clemm.Signedsyslogmessages.RFC5848,May2010.InternetRequestsforComments.

[14]K.Kent.Guidetocomputersecuritylogmanagement.TechnicalReportSP800-92,September2006.NationalInstituteofStandardsandTechnology.

[15]S.KentandK.Seo.SecurityarchitecturefortheInternetprotocol.RFC4301,December2005.InternetRequestsforComments.

[16]A.Langely.Enhancingdigitalcertificatesecurity.GoogleResearch,January2013.https://security.googleblog.com/2013/01/enhancing-digital-certificate-security.html.

[17]A.Langely.Arosteroftlsciphersuitesweaknesses.GoogleResearch,November2013.https://security.googleblog.com/2013/11/a-roster-of-tls-cipher-suites-weaknesses.html.

[18]C.Lonvick.TheBSDsyslogprotocol.RFC3164,August2001.InternetRequestsforComments.

[19] G.A.MarsonandB.Poettering.Practicalsecurelogging:Seekablesequentialkeygenerators.InESORICS,pages111–128,September2013.

[20]F.Miao,Y.Ma,andJ.Salowey.Transportlayersecurity(TLS)transportmappingforsyslog.RFC5425,March2009.InternetRequestsforComments.

[21]E.Nakashima.FBIpaidprofessionalhackersone-timefeetocracksanbernardinoiPhone,April2016.https://www.washingtonpost.com/world/national-security/fbi-paid-professional-hackers-one-time-fee-to-crack-san-bernardino-iphone/2016/04/12/5397814a-00de-11e6-9d36-33d198ea26c5story.html.

[22]NetBSD.syslogdconfigurationfile—syslog.conf(5).manpages.

[23]D.NewandM.T.Rose.Reliabledeliveryforsyslog.RFC3195,November2001.InternetRequestsforComments.

[24]A.Okmianski.TransmissionofsyslogmessagesoverUDP.RFC5426,March2009.InternetRequestsforComments.

[25]OpenSSL.Vulnerabilities.https://www.openssl.org/news/vulnerabilities.html,RetrievedJuly2016.

[26]K.G.Paterson.AcryptographictouroftheIPsecstandards.InformationSecurityTechnicalReport,11(2):72–81,2006.

[27]L.Poettering.Forwardsecuresealingisfinallycompoingtosystemd’sjournal.Google+Blog,August2012.https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/g1E6AxVKtyc.

[28]A.Prado,N.Harris,andY.Gluck.SSL,gonein30seconds.BlackHatUSA,July2012.

[29]R.Prins.Diginotarcertificateauthoritybreach—“operationblacktulip”.Fox-IT,September2011.

[30] M.Rose.Theblocksextensibleexchangeprotocolcore.RFC3080,March2001.InternetRequestsforComments.

[31] M.Rose.MappingtheBEEPcoreontoTCP.RFC

3081,March2001.InternetRequestsforComments.

[32]Rsyslog.Therocket-fastsystemforlogprocessing.http://www.rsyslog.com/,RetrievedJuly2016.

[33]D.Salomon.DataCompression:TheCompleteReference.Springer-VerlagLondon,4edition,2007.

[34]J.Salowey,T.Petch,R.Gerhards,andF.H.Datagramtransportlayersecurity(DTLS)transportmappingforsyslog.RFC6012,October2010.InternetRequestsforComments.

[35]Syslog-ng.Opensourcelogmanagementsolutionwithoveramillionusersworldwide.https://syslog-ng.org/,RetrievedJuly2016.

[36]E.TroanandP.Brown.logrotate—rotates,compresses,andmailssystemlogs,November2002.

[37]Ubuntu-16.04.Specialjournalfields—systemd.journal-fields(7).manpages.

[38]J.ZivandA.Lempel.Auniversalalgorithmforsequentialdatacompression.IEEETransactionsonInformationTheory,23(3):337–343,1977.

6

Rasmus Dahlberg a

nd Tobias Pulls |

Standardised Syslog Processi

ng

Standardised Syslog Processing

Today’s computer logs are like smoking guns and treasure maps in case of suspicious

system activities: they document intrusions, and log crucial information such as

failed system updates and crashed services. An adversary thus has a clear motive

to observe, alter, and delete log entries, considering that she could (i) start by using

the log’s content to identify new security vulnerabilities, and (ii) exploit them

without ever being detected. With this in mind we consider syslog standards and

open source projects that safeguard events during the storage and transit phases,

and examine how data compression effects security. We conclude that there are

syslog standards in place that satisfy security on a hop-by-hop basis, that there

are no such standards for secure storage, and that message compression is not

recommended during transit.

WORKING PAPER | September 2016

Faculty of Health, Science and Technology

Department of Mathematics and Computer Science

Faculty of Health, Science and Technology

Rasmus Dahlberg and Tobias Pulls

Standardised Syslog ProcessingRevisiting Secure Reliable Data Transfer and

Message Compression