Signature Detection in Sampled ack ets Gerhard unz Nico eber Geor Carle Computer Netw - PDF document

withlimitedbandwidthaswellaslimitedprocessingcapacitiesatthepacketanalyzer,thepacketanalysishastoberestrictedtoamaximumdatarateandpacketrate.Forthispurpose,appropriatepacketselectionstrategieshavetobeidentiedthat,ontheonehand,aresimpleenoughtobeimplementedatthemonitoringdevicesand,ontheotherhand,ensurethattheexporteddataissufcienttoachievetheanalysisgoals.SectionIIIpresentspossiblesolutionstothisproblem.Usually,itisnotnecessarytoexportentirepacketsasthepacketinspectionconcentratesonalimitednumberofheadereldsandpartsofpayload.Byadaptingthecontentoftheexportedpacketdataaccordingly,therequiredbandwidthcanbereducedfurtherwithoutimpairingtheanalysisresults.WeconductedastatisticalanalysisoftheSnortrulesetinordertodeterminewhichheadereldsaremostrelevantfortheruleset,andhowmanybytesofpayloadaretypicallyconsideredforsignature-basedattackdetection.TheoutcomeoftherulesetstudyispresentedinSectionIV.SectionVconcludesthispaperwithsomenalremarks.II.ARCHITECTUREANDIMPLEMENTATIONInthissection,wedescribethearchitectureandimplemen-tationofoursystemdepictedinFigure1.Therefore,westartwithabriefintroductiontoPSAMPandFlexibleNetow.Subsequently,weexplaintheintegrationofSnortwiththereal-timetrafcanalysisframeworkTOPAS.A.PSAMPandFlexibleNetowTheIETFPSAMPworkinggrouphasbeendevelopingtech-niquesforselectingpacketscapturedatanobservationpointandexportingpacketdatatoaremoteanalyzer[4].Severalltersandsamplingmechanismshavebeenstandardized[11]enablingdeterministicaswellasprobabilisticpacketselec-tions.PSAMPmakesuseoftheIPFIXprotocol[7]toexportpacketrecordsincludingheaderand/orpayloadinformationoftheselectedpackets.Astheactualrecordstructurecanbedenedinaexiblewayusingtemplates,itispossibletoexportonlythosepartsofapacketwhichareneededforlateranalysis.ThelatestversionofCiscoNetow,calledFlexibleNet-ow[6],alreadyimplementssomeofthePSAMPconcepts.AlthoughFlexibleNetowcurrentlysupportsalimitednumberofpacketselectionoptionsonlyanddeploysNetow.v9[8]insteadoftheIPFIXprotocol,weexpectthatPSAMPspeci-cationswillbesupportedbyCISCOassoonasthestandard-izationhasbeennished.InSectionsIIIandIV,wediscusswhichpacketselectiontechniquesaremostappropriateforthepurposesofsignaturedetection,andwhichper-packetinformationshouldbecon-tainedintheexportedpacketrecords.B.ImplementationTheprototypeimplementationofthepacketanalyzerbuildsonTOPASandtheopen-sourceintrusiondetectionsystemSnort.TOPAS[10]wasoriginallydevelopedattheUni-versityofTuebingenwithintheEuropeanprojectDiademFig.2.TOPASArchitectureFirewall[12]fordetectingDoSandDDoSattacksusingowrecords.TOPASintegratesacollectorforreceivingmonitoringdataexportedwithNetoworIPFIX,anddistributesthedatatooneormoredetectionmoduleswhichperformtheactualtrafcanalysisandattackdetection.DetectionresultsareencodedinIDMEF(IntrusionDetectionMessageeX-changeFormat)[13]andforwardedtoaneventsystemforpost-processing,suchascorrelationofalertsfromdifferentdetectionmodulesortriggeringresponsemechanisms.Forthepurposeofsignaturedetectioninsampledpackets,weintegratedSnort2.4[14]intotheTOPASframework.AsshowninFigure2,wedevelopedapcapwritermodulethattransformspacketrecordsintoframesinpcapformat[15].Ifapacketrecorddoesnotcontainacompletecopyofapacket,thepcapwritermodulesubstitutesmissingheadereldsandpayloadsectionswithpadding.ViaaUnixpipe,theresultispassedtoSnortwhichsearchesthepacketforknownsignaturesjustasifitwasrunningattheobservationpoint.AlthoughatighterandfasterintegrationofSnortiscertainlypossible,thepcapwritersolutionenablesustorunSnortwithoutanycodemodications,whichalsofacilitateskeepingpacewithupcomingSnortversions.InordertocollectSnortalerts,weusetheSnortIDMEFoutputpluginandasecondpipeintheoppositedirection.Aftersomeminormodicationsinthemessageheader,theIDMEFmessagesarepassedonforalertnoticationandpost-processing.Asmonitoringprobes,wedeployVERMONT(VERsatileMONnitoringToolkit)[16].VERMONTprovidesaninterfaceforremotecongurationbasedontheNetconfprotocol[17]andthecongurationdatamodelproposedin[18].Thisfeaturecanbeusedtodynamicallyadaptthepacketselectiontotherequirementsofthepacketanalyzerasdiscussedinthenextsection.III.PACKETSELECTIONAsstatedintheintroduction,theexportandanalysisofpacketdataaresubjecttobandwidthandprocessingresourcelimitations.Ifthenumberofobservedpacketsishigh,wearenotabletoexamineeverypacketbuthavetorestricttheanalysistosampledpackets.Agoodselectionstrategyisexpectedtoselectthosepacketswhicharerelevantforthe analysiswithhighprobability.Suchastrategyignorespacketsthatmostlikelydonotcontaininterestinginformation.Ofcoursethisclassicationintorelevantandnon-relevantpacketsdependsontheanalysisgoal.Forexample,suspiciousandpotentiallyharmfulpacketsarerelevantifweintendtodetectandidentifywormandattacktrafc.Forthepurposeoftrafcclassication,packetswithcharacteristicpayloadshouldbechosen.Inthefollowingsubsection,wegiveabriefoverviewonstandardlteringandsamplingmethodsanddiscusstheirappropriatenessforourapplication.Thereafter,wedescribehowwecanprotfromcongurablemonitoringdevicesthatenablethepacketanalyzertodynamicallyadapttheselectionstrategy.A.StandardFilteringandSamplingAnoverviewandtaxonomyofcommonpacketlteringandsamplingmethodsisgivenin[11].Aclassicationcanbemadebasedonthefollowingproperties:Deterministicvs.nondeterministic,dependingonwhetherthepacketselectionisalwaysidenticalwhenappliedtothesamesequenceofpackets.Content-dependentvs.content-independent,dependingonwhetherthepacketcontentistakenintoaccount.Nondeterministiccontent-independentmethodsresultinaran-dompacketselectionwhichneitherincreasenordecreasetheselectionprobabilityofrelevantpacketscomparedtonon-relevantpackets.Thesameappliestodeterministiccontent-independentmethods,suchassystematiccount-basedsam-plingandsystematictime-basedsampling.However,bothoftheseallowselectingmultiplepacketsinarow,e.g.therstmpacketsoutofeverysequenceofn�mpacketsinthecaseofsystematiccount-basedsampling,whichisanadvantageiftheanalysisrequiresseriesofconsecutivepacketsratherthanindividualpackets.Content-dependentmethods,suchaspacketlters(deter-ministic)ornon-uniformrandomsamplingalgorithms(nonde-terministic),arethemostappropriateforourpurposes.Theyallowdeningdifferentselectionprobabilitiesdependingoncertainpacketproperties,e.g.headereldvalues.Forexample,itispossibletofocusonpacketstargetingapotentiallyvulnerableserviceonaprotectedhost.Inadditiontoheaderelds,wecantakeintoconsiderationspecicpatternsinthepacketpayload,e.g.astringatagivenoffsetinthepayload.Consequently,ifthepacketanalyzersearchesforpatternsorsignaturescontainingsuchastringelement,averyefcientpacketselectioncanbeimplementedatthemonitoringdevice.Packetselectioncanrelyonsophisticatedpatterns,aslongasthenecessaryoperationsarenottoocomplextoslowdownthemonitoringprocessunacceptably.B.AdaptivePacketSelectionThissubsectiondescribeshowadynamicadaptationoftheselectionstrategycanhelptoachievebetteranalysisresults.Therefore,weconsiderpacketstobepartofows,denedasunidirectionalstreamsofpacketsbetweentwocommunicationendpoints.Inmanycases,theanalysisgoalistoclassifyowsandnotindividualpackets.Thisisquiteobviousinthecaseoftrafcclassicationwhereowsaretobeassignedtoserviceandapplicationclasses.Similarly,wormandattackdetectionaimsatidentifyingharmfulowsorconnections.Fortrafcanalysis,someowsaremoreinterestingthanothers,e.g.owswithrareorunknownsourcesordestinations,owsdirectedtovulnerableports,orowsoriginatingfromuntrustedhostsetc..Also,trafcanomaliesareusuallyworthbeingexamined,e.g.ifunusuallyhighnumbersofpacketsorowsaredirectedtoasingledestination.Theadaptationofpacketselectionanddataexportparametersrequiresdynam-icallycongurablemonitoringdevices.Anotherprerequisiteisaninterfaceforremotecongurationwhichenablesthepacketanalyzertoquicklychangethepacketselectionstrategyaccordingtoitscurrentanalysisgoalsandinterests.ApossiblesolutionprovidesthecongurationdatamodelforIPFIXandPSAMP[18]incombinationwiththeNetconfprotocol[17]asimplementedforVermont[19].Whiletheautonomousrecongurationofmonitoringde-vicesissubjectofongoingwork,apossibleapplicationscenariocanbedescribedasfollows.Thepacketanalyzerprovidesthemonitoringdeviceswithawhitelistdescribinglteringrulesforowswherenopacketinspectionisrequired.Withtheserules,mostofthenormaltrafcisomittedfrompacketsampling.Foranyotherow,packetdataistobeexporteduntilthepacketanalyzersendsastopsignaltothemonitoringdevices.Alternatively,amaximumnumberofexportedpacketsperowcouldbeconguredthatisusuallysufcienttoclassifyaow.Dependingontheanalysisresults,thepacketanalyzermayadaptthecongurationofthemonitoringdevices,e.g.byextendingthewhitelist.Aprotectionmechanismisnecessarytocopewithsituationswheremanynewowsnotmatchingthewhitelistrisktooverwhelmthepacketanalyzer.Onepossibilityistodiscardpacketsusingprobabilisticpacketsampling.Iftheanalysisrequiresconsecutivepacketsofaow,wecanapplyhash-basedlteringinsteadusingowkeyheadereldsasinputtothehashfunction[11].Asaresult,eitherallornopacketsofeachowareselected.IV.ANALYSISOFSNORTRULESAmeanstofurtherreducetheamountofmonitoringdataistoexportonlythosepacketheadereldsandpayloadsectionswhichareactuallyneededforpacketinspection.Inordertoknowwhichpartsofpacketarerelevantforsignaturedetection,weperformedastatisticalstudyontheSnortrulesetandfoundoutthatthemajorityofSnortsignaturesrefertoafewpacketheadereldsandincludeadditionalpatternstobesearchedforinthepacketpayload.ThefollowingsubsectionssummarizetheresultsofthestudyforthewholeSnortruleset(labeledAllinthetablesanddiagrams)aswellasforfourdisjointrulecategories:Backdoor:Variousrulesforbackdoors,exploits,andsuspiciousshellcommands(ruleles:backdoor,exploit,shellcode,tftp). TABLEIPROTOCOLS,DESTINATIONIPADDRESSES,ANDDESTINATIONPORTSINSNORTRULESRuleSetAllWebBackdoorServiceDoSTCP6494(92.49%)1594(100%)636(85.83%)657(96.48%)15(34.09%)UDP356(5.07%)0(0%)80(10.80%)24(3.52%)13(29.55%)ICMP132(1.88%)0(0%)1(0.13%)0(0%)15(34.09%)IP39(0.56%)0(0%)24(3.24%)0(0%)1(2.27%)Specicserver(s)1408(20.05%)958(60.10%)15(2.02%)414(60.79%)1(2,27%)Homenetwork4450(63.38%)625(39.21%)382(51.55%)242(35.54%)36(81.82%)Ext.network1130(16.09%)11(0.69%)331(44.67%)23(3.38%)7(15.91%)Specicaddress(es)10(0.14%)0(0%)0(0%)2(0.29%)0(0%)Anyhost23(0.33%)0(0%)13(1.75%)0(0%)0(0%)Specicport(s)5679(80.89%)1038(65.12%)371(50,07%)656(96.33%)25(56,82%)Anyport1342(19.11%)556(34.88%)370(49.93%)25(3.67%)19(43.18%)TABLEIIFREQUENCIESOFOTHERRULEATTRIBUTESProtocolIPTCPUDPICMPNumberofrules396494356132ip_proto9(23.08%)0(0%)0(0%)0(0%)ipopts3(7.69%)0(0%)0(0%)0(0%)fragbits2(5.13%)0(0%)0(0%)0(0%)ttl1(2.56%)1(0.02%)00%)0(0%)dsize0(0%)15(0.23%)4(1.12%)7(5.30%)flags0(0%)20(0.31%)0(0%)0(0%)itype0(0%)0(0%)0(0%)131(99.24%)icode0(0%)0(0%)0(0%)81(61.36%)icmp_id/_seq0(0%)0(0%)0(0%)17(12.88%)isdataat0(0%)128(1.97%)14(3.93%)0(0%)offset0(0%)1497(23.05%)128(35.96%)0(0%)content23(58.97%)5518(84.97%)349(98.03%)39(29.55%)uricontent0(0%)1396(21.50%)0(0%)0(0%)pcre0(0%)4262(65.63%)122(34.27%)0(0%)byte_jump/_test4(10.26%)0(0%)137(38.48%)0(0%)Web:Webserverandclientrules(web-*).Service:Otherservice-specicrules(dns,finger,ftp,imap,mysql,nntp,oracle,pop2,pop3,rservices,smtp,snmp,sql,x11).DoS:DoSandDDoSrules(dos,ddos).ThepresentedresultsarebasedontheofcialSnort2.4rulesreleasedforregisteredusersinOctober2006(2006-10-04).Inaddition,weanalyzedanolderrelease(2005-07-27)inordertodeterminepossibletrendsintheevolutionofsignatures.ThetworeleasesmainlydifferinthenumberofrulesintheBackdoorcategory,whichhadtripledwithin14months,andthenumberofWebrules,whichincreasedbymorethan40percent.HeaderFieldsandRuleAttributesEachSnortrulestartswithaheaderspecifyingsignaturevaluesforthetransportprotocolaswellasthesourceanddestinationaddressesandports.Awelldesignedruleheaderrestrictstheapplicationoftheruleusinginformationaboutthenetworktopology,e.g.theaddressrangeoftheprotectedhomenetworkoraddressesofspecicservers.Thisresultsinreducedprocessingoverheadperpacketandaspeed-upofthepacketanalysis.Inaddition,thenumberoffalsepositivealertscanbedecreased,e.g.byapplyingservice-specicrulestopacketsdirectedtocorrespondingserversonly.TableIshowsthedistributionoftheprotocolattributesandhowthedestinationIPaddressandportnumberarerestrictedtopredenedvalues.Ascanbeseen,mostrulesrefertoTCPtrafc;otherprotocolsmainlyoccurintheBackdoorandDoScategory.Obviously,destinationaddressandportareveryfrequentlyconsideredinthesignatures.However,theevaluationofthedestinationaddressrequiresknowledgeaboutwhichhostsareserversforspecicservices,andwhichhostsareclientsonly,informationthatmightnotbeavailableto 0 50 100 150 200 250 300 350 0 500 1000 1500 2000 2500 0 1000 2000 3000 4000 5000 6000 7000 8000FrequencyCumulative FrequencyRequired Payload Length (Bytes)AllFrequencyCumulative Frequency 0 50 100 150 200 250 300 0 500 1000 1500 2000 2500 0 200 400 600 800 1000 1200 1400 1600FrequencyCumulative FrequencyRequired Payload Length (Bytes)WebFrequencyCumulative Frequency 0 10 20 30 40 50 60 0 200 400 600 800 1000 1200 0 100 200 300 400 500 600 700 800FrequencyCumulative FrequencyRequired Payload Length (Bytes)BackdoorFrequencyCumulative Frequency 0 5 10 15 20 25 0 500 1000 1500 2000 2500 0 100 200 300 400 500 600FrequencyCumulative FrequencyRequired Payload Length (Bytes)ServiceFrequencyCumulative FrequencyFig.3.PayloadbyRuleSetnetworkoperators.Ontheotherhand,thedestinationportcanbeevaluatedwithoutanyfurtherknowledgeaslongasservicesarerunningonwell-knownportnumbers.Sourceaddressandportofapacketplayalessimportantrole.Thesourceportissettoaspecicvaluein13.7%ofallSnortrules,mainlyintheWebandBackdoorcategories.Theusageofthesourceaddressisnegligible;only0.5%oftherulesspecifyaspecicaddressorserver,whilemostofthemlookforanyhost,externalnetwork,orhomenetwork.ApossibilitytofurthereliminatefalsepositivesistoapplyTCPrulestopacketsofestablishedTCPconnectionsonly.InSnort,theTCPconnectionstateisdeterminedbyapre-processorpluginwhichsetstheso-calledflowattributeofapacket.ThisattributeisevaluatedbynearlyallTCPrules,andmostofthetimetherulesrefertoestablishedconnections.Consequently,itwouldbebenecialifthemonitoringdeviceswereabletodeterminetheconnectionstateandexportedonlypacketsofestablishedconnections;theflowattributecouldthenbeignored,andthepreprocessorplugindeactivated.TableIIliststhefrequencyofotherattributesusedinSnortrules.Attributesconcerningadditionalheadereldsarequiterare(ip_proto,ipopts,fragbits,ttl,dsize,flags).ICMPrulescommonlyevaluatethetype(itype)andcode(icode)elds.Otherfrequentlyusedattributesrefertothepacketpayload(isdataat,offset,content,etc.).Inthefollowingsubsection,weusethepatternlengthdistributionintheSnortsignaturestodetermineareasonablenumberofbytesofpayloadthatshouldbeexportedbythemonitoringdevices.B.RequiredPayloadLengthMostSnortrulessearchforagivenpatterninthepacketpayload.Sincethepayloadofasinglepacketcanbeverylong,wewouldliketosetanupperlimitforthenumberofexportedbytes.Therefore,weusedthepatternlengthandoffsetofaSnortruletocalculatetherequiredminimumpayloadlength.Thecalculatedvaluesarelowerestimatesbasedontheassumptionthatpatternsarelocatedattheearliestpossiblelocationinthepayloadunlessahigherpayloadlengthisspeciedbyadsizeorisdataatattribute.Figure3depictstheresultingfrequencydistributions.Thediagramsshowthatabout145bytesofpayloadarenecessarytosatisfy90percentofallrules.Fortheolderrulesetrelease(2005-07-27),90percentwerealreadyreachedat100bytes.ThisincreaseismainlycausedbynewlyaddedsignatureswithverylongpatternsintheWebcategory(rulele:web-clients)describingmaliciouscontents,e.g.Mi-crosoftActiveXobjects,thataredownloadedfromawebserver.Thetrendtowardsmoreandmorerulesforsuchserver-originated“attacks”isalsoreectedinthehighfrequencyofanydestinationportinTableIwhichincreasedbyafactoroftencomparedtotheolderruleset. C.ConclusionsBasedonourobservations,weconcludethatthemostrelevantheadereldsevaluatedbySnortrulesarethetransportprotocolandthesourceanddestinationportnumbers.Insteadofportnumbers,ICMPrulesrequireICMPtypeandcodevalues.ThedestinationIPaddresscanbeusefulforsignaturedetectionifthepacketanalyzerdisposesofknowledgeaboutpotentiallyvulnerableserversinthenetwork.Thedestinationaddressisalsoneededtoreportthetargetofadetectedattack.Inadditiontotheseheaderelds,mostrulesincludeapatternintherst145bytesofpayload.Ifmonitoringdevicesexportedthesepacketcontents,804of7021Snortrules(11.4%)wouldnotworkastheyevaluateotherorfurtherpacketinformation.Thisnumbercanbefurtherdecreasedatthecostofenlargingtheexportedpayloadsection,orexportingrarelyusedheadereldslikeTCPags.Furthermore,sourceaddresses,althoughnotrequiredbythesignatures,mightbeofinteresttoidentifytheoriginofattackpackets.D.VericationwithDARPAPacketTracesInordertoverifyourconclusions,wecomparedthede-tectionresultsusingapackettraceoftheDARPAIntrusionDetectionEvaluation20001[20]consistingof347,987pack-ets.Inarstrun,weconguredVermonttoexportaPSAMPrecordforeveryobservedpacket,containingacopyoftheentirepacketandatimestampwiththeobservationtime.Thisresultedin37.6megabytesofmonitoringdata,andSnortrunningonTOPASdetected47harmfulpackets.Inasecondrun,weexportedPSAMPrecordscontainingdestinationIPaddress,protocolidentier,166bytesofIPpayload(transportheaderandpayload),andtheobservationtime.IPpayloadwasusedsincetheexportoftransportlayerpayloadhasnotyetbeenstandardizedbyPSAMP.Theamountofmonitoringdatawasreducedto12.5megabytes(66%lessthenbefore).Asexpected,Snortwasstillabletodetectedmostoftheharmfulpackets(41or87.2%).ThesixmissedalarmsweretriggeredbytwoSnortrulesrequiringlongerpayloadsections.V.CONCLUSIONWepresentedanarchitectureandimplementationthaten-ablespatternmatchinginpacketdataexportedbyPSAMPandFlexibleNetowmonitoringdevices.Weevaluatedtowhichextendstandardsamplingandlteringmethodsareappropriatetoselectthosepacketswithhighprobabilitythatarerelevantforsignaturedetection,andwediscussedtheadvantagesofdynamicallyadaptingthepacketselectiontothecurrentanalysisgoals.WithastatisticalstudyofSnortrules,wegainedknowledgeaboutthepartsofpacketthatarerelevantforsignaturedetectionandthatshouldthereforebeexportedbythemonitoringdevices.AsPSAMPisinthenalphaseofstandardization,andasFlexibleNetowisalreadyavailableonthemarket,weexpectthattheexportofpacketdatabecomesacommonplaceextensionfordevicesalreadysupportingowinformation1DDoSscenarioLLDOS2.0.2,insidetrafcexporttoday,e.g.routers,switches,andmonitoringprobes.Basedonthisassumption,ourapproachrepresentsacost-effectivesolutiontoperformsignaturedetectioninhigh-speednetworkswherethedistributeddeploymentofconventionalnetworkanalyzersandintrusiondetectionsystemswouldbetooexpensive.Ourcurrentresearchactivitiesaimatvalidatingthepresentedpacketselectionandexportstrategiesunderrealtrafcconditions.Furthermore,weintendtocombineowandpacket-basedattackdetectionwithintheTOPASframeworkinordertoimprovethedetectionresultsofindividualmethods.REFERENCES[1]T.Karagiannis,K.Papagiannaki,andM.Faloutsos,“BLINC:MultilevelTrafcClassicationintheDark,”inProc.ofConferenceoftheSpecialInterestGrouponDataCommunication(SIGCOMM'05),Philadelphia,Pennsylvania,USA,Aug.2005.[2]A.W.MooreandK.Papagiannaki,“TowardtheAccurateIdenticationofNetworkApplications,”inProc.ofPassiveandActiveMeasurementWorkshop(PAM2005),Boston,MA,Mar.2005.[3]S.FideandS.Jenks,“ASurveyofStringMatchingApproachesinHardware,”DepartmentofElectricalEngineeringandComputerScience,UniversityofCalifornia,Irvine,Tech.Rep.TRSPDS06-01,Mar.2006.[4]N.Dufeld,D.Chiou,B.Claise,A.Greenberg,M.Grossglauser,P.Marimuthu,J.Rexford,andG.Sadasivan,“AFrameworkforPacketSelectionandReporting,”Internet-Draft,workinprogress,draft-ietf-psamp-framework-12,Jun.2007.[5]B.Claise,J.Quittek,andA.Johnson,“PacketSampling(PSAMP)ProtocolSpecications,”Internet-Draft,workinprogress,draft-ietf-psamp-protocol-08,Jun.2007.[6]CiscoSystems,“IntroductiontoCiscoIOSFlexibleNetFlow,”WhitePaper,Jun.2006.[Online].Available:http://www.cisco.com[7]B.Claise,S.Bryant,S.Leinen,T.Dietz,andB.H.Trammell,“IPFIXProtocolSpecications,”Internet-Draft,workinprogress,draft-ietf-ipx-protocol-26,Sep.2007.[8]B.Claise,G.Sadasivan,V.Valluri,andM.Djernaes,“CiscoSystemsNetFlowServicesExportVersion9,”RFC3954(Informational),Oct.2004.[9]M.Roesch,“Snort:LightweightIntrusionDetectionforNetworks,”inProc.of13thUSENIXConferenceonSystemAdministration.USENIXAssociation,Nov.1999.[10]G.M¨unzandG.Carle,“Real-timeAnalysisofFlowDataforNetworkAttackDetection,”inProc.ofIFIP/IEEESymposiumonIntegratedManagement(IM2007),Munich,Germany,May2007.[11]T.Zseby,M.Molina,N.Dufeld,S.Niccolini,andF.Raspall,“Sam-plingandFilteringTechniquesforIPPacketSelection,”Internet-Draft,workinprogress,draft-ietf-psamp-sample-tech-10,Jun.2007.[12]DiademFirewallHomepage,http://www.diadem-rewall.org/,2006.[13]H.Debar,D.Curry,andB.Feinstein,“TheIntrusionDetectionMessageExchangeFormat(IDMEF),”RFC4765(Experimental),Mar.2007.[14]SnortHomepage,http://www.snort.org/,2006.[15]LibpcapHomepage,http://www.tcpdump.org,2007.[16]R.T.Lampert,C.Sommer,G.M¨unz,andF.Dressler,“Vermont-AVersatileMonitoringToolkitforIPFIXandPSAMP,”inProc.ofIEEE/ISTWorkshoponMonitoring,AttackDetectionandMitigation(MonAM2006),Tuebingen,Germany,Sep.2006.[17]R.Enns,A.Bierman,K.Crozier,T.Goddard,E.Lear,P.Shafer,S.Wald-busser,andM.Wasserman,“NETCONFCongurationProtocol,”RFC4741(StandardsTrack),Dec.2006.[18]G.M¨unzandB.Claise,“CongurationDataModelforIPFIXandPSAMP,”Internet-Draft,workinprogress,draft-muenz-ipx-conguration-02.txt,Jun.2007.[19]G.M¨unz,A.Antony,F.Dressler,andG.Carle,“UsingNetconfforConguringMonitoringProbes,”inProc.ofIEEE/IFIPNetworkOperations&ManagementSymposium(NOMS2006),PosterSession,Vancouver,Canada,Apr.2006.[20]WebsiteofDARPAIntrusionDetectionEvaluation,http://www.ll.mit.edu/IST/ideval/,2007.