Bro A System for Detecting Network Intruders in Re

Bro:ASystemforDetectingNetworkIntrudersinReal-TimeVernPaxsonLawrenceBerkeleyNationalLaboratory,Berkeley,CAandAT&TCenterforInternetResearchatICSI,Berkeley,[e-mail],astand-alonesystemfordetectingnet-workintrudersinreal-timebypassivelymonitoringanet-worklinkoverwhichtheintruder'straffictransits.Wegiveanoverviewofthesystem'sdesign,whichemphasizeshigh-speed(FDDI-rate)monitoring,real-timenotification,clearseparationbetweenmechanismandpolicy,andextensibility.Toachievetheseends,Broisdividedintoan“eventengine”thatreducesakernel-filterednetworktrafficstreamintoase-riesofhigher-levelevents,anda“policyscriptinterpreter”thatinterpretseventhandlerswritteninaspecializedlan-guageusedtoexpressasite'ssecuritypolicy.Eventhandlerscanupdatestateinformation,synthesizenewevents,recordinformationtodisk,andgeneratereal-timenotificationsviasyslog.Wealsodiscussanumberofattacksthatattempttosubvertpassivemonitoringsystemsanddefensesagainstthese,andgiveparticularsofhowBroanalyzesthesixap-plicationsintegratedintoitsofar:Finger,FTP,Portmapper,Ident,TelnetandRlogin.Thesystemispubliclyavailableinsourcecodeform.1IntroductionWithgrowingInternetconnectivitycomesgrowingoppor-tunitiesforattackerstoillicitlyaccesscomputersoverthenetwork.Theproblemofdetectingsuchattacksistermednetworkintrusiondetection,arelativelynewareaofsecurityresearch[MHL94].Wecandividethesesystemsintotwotypes,thosethatrelyonauditinformationgatheredbythehostsinthenetworktheyaretryingtoprotect,andthosethatoperate“stand-alone”byobservingnetworktrafficdirectly,andpassively,usingapacketfilter.Thereisalsoincreasinginterestinbuildinghybridsystemsthatcombinethesetwoapproaches[Ax99].ThispaperappearsinComputerNetworks,31(23–24),pp.2435–2463,14Dec.1999.ThisworkwassupportedbytheDirector,OfficeofEnergyResearch,OfficeofComputationalandTechnologyResearch,Mathemati-cal,Information,andComputationalSciencesDivisionoftheUnitedStatesDepartmentofEnergyunderContractNo.DE-AC03-76SF00098.Anear-lierversionofthispaperappearedintheProceedingsofthe7thUSENIXSecuritySymposium,SanAntonio,TX,January1998.Inthispaperwefocusontheproblemofbuildingstand-alonesystems,whichwewillterm“monitors.”Thoughmon-itorsnecessarilyfacethedifficultiesofmorelimitedinfor-mationthansystemswithaccesstoaudittrails,monitorsalsogainthemajorbenefitthattheycanbeaddedtoanet-workwithoutrequiringanychangestothehosts.Forourpurposes—monitoringacollectionofseveralthousandhet-erogeneous,diversely-administeredhosts—thisadvantageisimmense.OurmonitoringsystemiscalledBro(anOrwellianre-minderthatmonitoringcomeshandinhandwiththepo-tentialforprivacyviolations).Anumberofcommer-cialproductsexistthatdowhatBrodoes,generallywithmuchmoresophisticatedinterfacesandmanagementsoft-ware[In99,To99,Ci99],andlarger“attacksignature”li-braries.Toourknowledge,however,therearenodetailedaccountsinthenetworksecurityliteratureofhowmonitorscanbebuilt.Furthermore,monitorscanbesusceptibletoanumberofattacksaimedatsubvertingthemonitoring;webelievetheattackswediscussherehavenotbeenpreviouslydescribedintheliterature.Thus,thecontributionofthispa-perisnotatheartanovelidea(thoughwebelieveditnovelwhenweundertooktheproject,in1995),butratherade-tailedoverviewofsomeexperienceswithbuildingsuchasystem.PriortodevelopingBro,wehadsignificantoperationalex-periencewithasimplersystembasedonoff-lineanalysisoftcpdump[JLM89]tracefiles.Outofthisexperienceweformulatedanumberofdesigngoalsandrequirements:High-speed,largevolumemonitoringForourenviron-ment,weviewthegreatestsourceofthreatsasexternalhostsconnectingtoourhostsovertheInternet.Sincethenetworkwewanttoprotecthasasinglelinkcon-nectingittotheremainderoftheInternet(a“DMZ”),wecaneconomicallymonitorourgreatestpotentialsourceofattacksbypassivelywatchingtheDMZlink.Oratleastappear,accordingtotheirproductliterature,todothesamethings—wedonothavedirectexperiencewithanyoftheseproducts.Asomewhatdifferentsortofproduct,the“NetworkFlightRecorder,”isdescribedin[RLSSLW97],thoughitisnowincreasinglyusedforintrusiondetection[Ne99].1However,thelinkisanFDDIring,sotomonitoritre-quiresasystemthatcancapturetrafficatspeedsofupto100Mbps.NopacketfilterdropsIfanapplicationusingapacketfil-tercannotconsumepacketsasquicklyastheyarriveonthemonitoredlink,thenthefilterwillbufferthepack-etsforlaterconsumption.However,eventuallythefil-terwillrunoutofbuffer,atwhichpointitdropsanyfurtherpacketsthatarrive.Fromasecuritymonitor-ingperspective,dropscancompletelydefeatthemon-itoring,sincethemissingpacketsmightcontainex-actlytheinterestingtrafficthatidentifiesanetworkin-truder.Givenourfirstdesignrequirement—high-speedmonitoring—thenavoidingpacketfilterdropsbecomesanotherstrongrequirement.Itissometimestemptingtodismissaproblemsuchaspacketfilterdropswithanargumentthatitisunlikelyatrafficspikewilloccuratthesametimeasanattackhappenstobeunderway.Thisargument,however,iscompletelyunderminedifweassumethatanattackermight,inparallelwithabreak-inattempt,attackthemonitoritself(seebelow).Real-timenotificationOneofourmaindissatisfactionswithourinitialoff-linesystemwasthelengthydelayincurredbe