Intrångsdetekteringssystem

Institutionen för Kommunikation och Information Examensarbete i datalogi 15 hp, C-nivå Vårterminen 2010 Intrångsdetekteringssystem En jämförelse mellan Snort och Suricata

Introduktion Intrångsdetekteringssystem Projektrapport inlämnad av till Högskolan i Skövde, Institutionen för kommunikation och information. Arbetet har handletts av Helen Pehrsson. 13:e september 2010 Härmed intygas att allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt identifierat och att inget material är inkluderat som tidigare använts för examinering på annan kurs. Signerat:

Introduktion Intrångsdetekteringssystem Sammanfattning Arbetets syfte är att jämföra intrångsdetekteringssystemen Snort och Suricata för att ge en uppfattning om vilken av applikationerna som lämpar sig att implementeras hos en internetleverantör för att upptäcka attacker och öka säkerheten på nätverket. Jämförelsen utförs med hänseende till antal upptäckta attacker, prestanda, implementeringstid, antal konfigurationsfiler samt vilka operativsystem de finns tillgängliga på. Resultatet visar att Suricata med sitt stöd för att använda signaturer skapade för Snort upptäcker fler attacker än Snort. Snort däremot går både smidigare och snabbare att implementera. Prestandamässigt så visar Suricata bäst resultat, genom att använda sig av flera kärnor och mindre minne. Nyckelord: Intrångsdetekteringssystem, IDS, Snort, Suricata, säkerhet

Introduktion Innehållsförteckning 1 Introduktion... 1 2 Bakgrund... 2 2.1 Intrångsdetekteringssystem... 2 2.1.1 Snort... 2 2.1.2 Suricata... 3 2.2 Klassificeringar... 3 2.3 Typer av intrångsdetekteringssystem... 3 2.3.1 Host-based Intrusion Detection System... 3 2.3.2 Network Intrusion Detection System... 4 2.4 Relaterade arbeten... 4 3 Problemställning... 5 3.1 Delmål... 5 3.1.1 Mäta antalet attacker som upptäcks... 5 3.1.2 Undersöka implementeringstid och antal konfigurationsfiler... 5 3.1.3 Undersöka prestanda och operativsystemstöd... 6 4 Metod... 7 4.1 Metodsteg... 7 4.1.1 Fördjupning... 7 4.1.2 Upprätta laborationsmiljö... 8 4.1.3 Utvärdera systemen... 8 4.1.4 Analys... 9 5 Resultat... 10 5.1 Fördjupning... 10 5.1.1 Snort... 10 5.1.2 Suricata... 11 5.1.3 Backtrack och Metasploit... 11 5.1.4 Attacker... 12 5.2 Upprätta laborationsmiljö... 16 5.2.1 Nätverkstopologi... 16 5.3 Utvärdera systemen... 17 5.3.1 Antalet attacker som upptäcks... 17 5.3.2 Implementeringstid och antal konfigurationsfiler... 19 5.3.3 Prestanda och operativsystemstöd... 19

Introduktion 5.4 Analys... 21 5.4.1 Antalet attacker som upptäcks... 21 5.4.2 Implementeringstid och antal konfigurationsfiler... 21 5.4.3 Prestanda och operativsystemstöd... 22 6 Slutsats... 23 6.1 Arbetets styrkor och svagheter... 23 7 Reflektion... 25 7.1 Snort... 25 7.2 Suricata... 25 8 Framtida arbete... 27 Referenser... 28 Bilaga A. Konfiguration av Snort... 1 Bilaga B. Konfiguration av Suricata... 1

Introduktion 1 Introduktion Dagens samhälle får ett större behov av Internet och dess informationstjänster varje dag vilket ökar kraven på internetleverantörerna. Internetleverantörernas roll är att förse samhället med Internet för att de informationstjänster som finns där ska ha en god tillgänglighet. För att den här tillgängligheten ska vara tillfredställande måste nätverken hålla en hög säkerhet som skyddar mot olika typer av tekniska attacker som annars kan försämra tillgängligheten (Barbard, Couto, Jajodia & Wu, 2001). De typer av skydd som man oftast talar om när det handlar om teknisk säkerhet är antivirusprogram och brandväggar. När dessa applikationer hålls uppdaterade kan de förhindra en del av den skadliga kod och attacker som befinner sig på nätverken. Många av de attacker som sker blir dock aldrig upptäckta eller rapporterade vilket gör att antivirusprogram och brandväggar kan skapa en falsk trygghet. Det är då intrångsdetekteringssystem behövs för att skapa ytterligare säkerhet. Då ett system aldrig kan vara helt säkert och sårbarheter existerar i olika grad överallt enligt Sundaram (1996), räcker det inte med en brandvägg för att hålla ett nätverk säkert och då kan ett intrångsdetekteringssystem vara ett bra komplement för att upptäcka olika typer av attacker och skadlig kod som befinner sig på nätverket. Det här arbetet kommer att fokusera på säkerheten hos internetleverantörers nätverk och inte personliga brandväggar och antivirusprogram hos klienter. Det ämne som det här arbetet ska omfatta är intrångsdetekteringssystem, vilket är en programvara som kan används för att analysera system och nätverk genom att leta efter mönster eller onormala händelser. Ett system av den här typen beskrivs av Sundaram (1996, s. 2) på följande vis: "It plays the role of an informant rather than a police officer". Applikationen detekterar följaktligen händelser som ser ut att vara av en farlig natur och ett alarm skickas till administratören. När administratören fått information om vad som har skett kan en närmare undersökning genomföras för att se om händelsen är oönskad. Om det var en oönskad händelse som inträffat kan administratören vidta lämpliga åtgärder för att förhindra att det händer igen. Det finns ett flertal olika intrångsdetekteringssystem så en jämförelse mellan två av dessa ska göras. De system som ska jämföras är Snort, som är det mest använda programmet inom intrångsdetekteringssystem enligt Aydin, Zaim & Ceylan (2008), samt Suricata som är ett relativt nytt projekt skapat av högt uppsatta personer inom säkerhetsindustrin och en passande utmanare till Snort. Denna jämförelse ska genomföras för att ge en uppfattning av vilken av applikationerna som bäst kan öka informationssäkerheten. Enligt Saltin som 2009 gjorde en utvärdering av systemet Snort behövs det också fler jämförelser mellan intrångsdetekteringssystem, vilket motiverar det här arbetet ytterligare. 1

Bakgrund 2 Bakgrund Informationssäkerhet definieras enligt Pfleeger & Pfleeger (2006) som en kombination av tre olika aspekter: konfidentialitet, integritet samt tillgänglighet. När alla dessa tre krav är uppfyllda får man det som kallas säkerhet. En bild som demonstrerar hur dessa tre tillsammans skapar säkerhet finns att se i Figur 1. Figur 1 Illustration över hur säkerhet består av konfidentialitet, integritet samt tillgänglighet (Pfleeger & Pfleeger, 2006). Med den första aspekten, konfidentialitet, menas att bara de som ska ha åtkomst till någonting har det. Integritet innebär att det går att lita på att informationen inte har blivit modifierad eller är korrupt. Aspekten tillgänglighet går ut på att informationen som finns ska vara tillgänglig vid rätt tidpunkt (Pfleeger & Pfleeger, 2006). 2.1 Intrångsdetekteringssystem Intrångsdetekteringssystem är system som analyserar händelser på datorer eller nätverk för att upptäcka säkerhetsproblem. Den punkt i systemet som samlar in data för analys kallas sensor och det är vart denna placeras som påverkar hur mycket trafik systemet kan få tillgång till för analys. De intrång som sker på ett nätverk kallas attacker och kan kränka både konfidentialitet, integritet samt tillgänglighet som tidigare nämnts (Aydin, et al., 2008). 2.1.1 Snort Snort är ett intrångsdetekteringssystem som fungerar på flera plattformar och är enkelt att konfigurera. Applikationen är gratis att använda och går under GNU General Public License. Den motor som Snort använder sig av för att detektera intrång använder sig av ett enkelt språk, vilket gör att nya regler snabbt kan skapas och därmed göra det möjligt att upptäcka nya hot inom bara några timmar (Roesch, 1999). Snort har funktionalitet som en paketdetektor och en loggningsapplikation, som tillsammans med sina regler kan leta efter mönster i trafiken för att hitta attacker. Applikationen Snort konfigureras och körs via en terminal och har möjlighet att skicka alarm till administratören i realtid (Roesch, 1999). 2

Bakgrund 2.1.2 Suricata Suricata är precis som Snort ett intrångsdetekteringssystem och finns även detta tillgängligt till ett flertal olika plattformar. Programmet finns att ladda ner från tillverkarnas webbplats utan någon kostnad och använder sig av signaturer för att upptäcka attacker. Applikationen är skapad av The Open Information Security Foundation (OISF) och finansieras bland annat av Department of Homeland Security i Amerika. Målet med Suricata är att bygga ett nästa generations intrångsdetekteringssystem med hjälp av en multinationell grupp av ledande mjukvaruutvecklare inom säkerhetsindustrin (The Open Information Security Foundation, 2010). 2.2 Klassificeringar Ett intrångsdetekteringssystem kan vara av två olika klasser. Den första klassen är signaturbaserat och fungerar genom att leta efter händelser som bryter mot systemets policys. Detta görs genom att man skapar signaturer, vilket är mönster som beskriver egenskaperna för en attack. Med dessa signaturer analyserar man data och letar efter matchningar som tyder på att det är en attack (Aydin, et al., 2008). Det är den här tekniken som Snort och Suricata i det här arbetet använder sig av. Den andra metoden är avvikelsebaserad och analyserar data för att leta efter onormala händelser. De händelser som sticker ut och verkar avvikande kan systemet sedan flagga som en attack som kan undersökas vidare av administratören (Aydin, et al., 2008). Ett system av den här typen som inte är korrekt konfigurerat kan generera alarm även fast en attack inte inträffat, utan bara en onormal händelse. Fördelen med den här klassen är att en attack inte behöver vara känd för att den ska kunna upptäckas av systemet. Då båda dessa metoder har både för- och nackdelar finns det också hybridsystem som använder sig av båda klasserna som nämnts (Aydin, et al., 2008). 2.3 Typer av intrångsdetekteringssystem Ett intrångsdetekteringssystem kan vara av två olika typer. Vilken typ det är baseras på placeringen av sensorn och vilken typ av data som analyseras. 2.3.1 Host-based Intrusion Detection System Ett Host-based Intrusion Detection System (HIDS) är ett system som undersöker applikationer och händelser på ett operativsystem på en maskin. Det kan vara av en av tidigare nämnda klassificeringar som letar efter mönster eller avvikande beteende hos applikationer och filer som exekveras (Internet Security Systems, 1998). Ett exempel är ifall en applikation som vanligtvis inte läser och ändrar i viktiga systemfiler börjar göra detta. Vid en sådan händelse kan systemet rapportera till administratören så att en vidare undersökning kan göras för att se ifall applikationen blivit infekterad av någon form av skadlig kod (Internet Security Systems, 1998). 3

Bakgrund 2.3.2 Network Intrusion Detection System Den andra typen av intrångsdetekteringssystem är Network Intrusion Detection System (NIDS) och analyserar precis som HIDS data för att upptäcka mönster eller avvikande beteende. Skillnaden är den att ett NIDS analyserar nätverkstrafik istället för händelser inom ett operativsystem (Internet Security Systems, 1998). Den typ av attacker som ett system av den här typen kan upptäcka är bland annat överbelastningsattacker och sökningar efter öppna portar eller sårbarheter (Internet Security Systems, 1998). Det är den här typen av intrångsdetekteringssystem som kommer att utvärderas i följande arbete då internetleverantörer inte har kontroll över klienterna på nätverket. 2.4 Relaterade arbeten Tidigare arbeten som gjorts inom ämnet är bland annat en jämförelse på den prestanda man får ut av Snort beroende på vilket operativsystem som används. De operativsystem som användes var Linux och Windows Server 2003. Under arbetet kommer Salah och Kahtani (2010) fram till att Snort under Linux presterar bättre än Windows Server 2003 under hög belastning, men när belastningen är medelhög så är prestandan sämre i Linux än Windows Server 2003. Några jämförelser mellan Snort och Suricata specifikt har inte hittats men Henders och Opdyke gjorde 2005 en implementering av Snort på ett campusnätverk, vilket är intressant då detta arbete kommer att genomföras på en liknande nivå i nätverkshierarkin. En av de slutsatser som det här arbetet gav är att de loggfiler som skapas av Snort blir både stora och svåra att förstå. Tolkningen av dessa kan förenklas genom olika applikationer, vilket kan vara värt att tänka på under genomförandet av det här arbetet. 4

Problemställning 3 Problemställning Då samhället är beroende av Internet och de informationstjänster som där finns är det viktigt att internetleverantörer upptäcker attacker snabbt för att kunna erbjuda tillförlitliga uppkopplingar. Problemet är att många av de attacker som utförs aldrig upptäcks eller rapporteras. För att öka antalet attacker som upptäcks behövs det enligt Barbara, et al. (2001) applikationer i form av intrångsdetekteringssystem. Eftersom olika intrångsdetekteringssystem använder sig av olika metoder och ger olika resultat ska en jämförelse göras i det här arbetet. Detta för att ge en uppfattning om vilken applikation som lämpar sig hos en internetleverantör för att upptäcka attacker och öka säkerheten. Arbetet har följande frågeställning: Jämföra Snort och Suricata med hänseende till antal upptäckta attacker, prestanda, implementeringstid, antal konfigurationsfiler samt vilka operativsystem de finns tillgängliga på. Arbetet har också en tes vilket är att Snort som är de facto-standard inom intrångsdetekteringssystem upptäcker fler attacker och presterar bättre än systemet Suricata. Anledningen till att det är viktigt att problemet undersöks är för att man ska kunna hålla en god tillgänglighet på nätverken, så att de informationstjänster som finns där alltid är åtkomliga. Genom att undersöka vilket system som upptäcker flest attacker finns möjligheten att vidta fler åtgärder, vilket skapar högre tillgänglighet. Att snabbt identifiera och ta till åtgärder mot enheter som utför attacker eller blir attackerade är viktigt för att resterande användare på nätverket inte ska behöva lida av en långsam eller obefintlig uppkoppling. 3.1 Delmål Arbetet har delats upp i tre delmål som måste slutföras för att besvara den frågeställning som arbetet har. Under detta kapitel ges en förklaring på vad som ska uppnås med varje delmål samt en motivering till varför dessa är viktiga att genomföra. 3.1.1 Mäta antalet attacker som upptäcks Det första delmålet i arbetet är att mäta antalet attacker som upptäcks. Detta ska göras för både Snort och Suricata under samma förhållanden och samma attacker. Anledningen till att detta delmål är viktigt att genomföra är för att ge en uppskattning av hur många attacker som upptäcks av respektive system. Då anledningen till att intrångsdetekteringssystem används framförallt är att upptäcka attacker, kan denna punkt anses vara den betydande. 3.1.2 Undersöka implementeringstid och antal konfigurationsfiler Andra delmålet i arbetet är att undersöka hur lång implementeringstiden är för respektive system samt hur många konfigurationsfiler som behövs. Detta ska undersökas för att se ifall någon skillnad i komplexitet finns vilket kan vara avgörande för den administratör som använder systemet. 5

Problemställning 3.1.3 Undersöka prestanda och operativsystemstöd Det tredje och sista delmålet är att undersöka hur mycket processorkraft och minne de båda applikationerna använder vid olika belastning. En sammanställning över de operativsystem som applikationerna finns tillgängliga på ska också skapas för att ge en enkel överblick av hur mycket operativsystemstöd som finns. 6

Metod 4 Metod Den metod som kommer att användas i det här arbetet är experiment. Det ett arbete med metoden experiment fokuserar på är att verifiera huruvida ett antagande är korrekt eller inte (Berndtsson, Hansson, Olsson & Lundell, 2008). Anledningen till att experiment valts och inte exempelvis litteraturstudie är för att Suricata är ett så nytt projekt tidigare forskning om det är nästan obefintligt vilket inte möjliggör den här metoden. En jämförelse enligt metoden experiment ska alltså göras för att se vilken av applikationerna som lämpar sig bäst för att öka säkerheten i ett nätverk. Något som är viktigt att notera när det gäller metoden av typen experiment är att resultatet inte kan ses som något fullständigt bevis, utan snarare ge en indikation på huruvida antagandet stämmer. Anledningen till detta är att det kan finnas ett flertal faktorer som påverkar resultatet och kan göra det missvisande (Berndtsson, et al., 2008). Resultatet i det här arbetet kan bland annat bli missvisande beroende på hur konfigurationerna av systemen görs vilket kan förändra bland annat antal detekterade attacker. 4.1 Metodsteg För att uppnå de delmål som problemet är uppdelat i kommer här en förklaring av de steg som måste genomföras. Genom att slutföra alla steg ska ett resultat åstadkommas som ett svar på den frågeställning som arbetet bygger på. Under följade rubriker förklaras de fyra stegen och lösningsförslag på dessa, samt en motivering till vilken lösning som valts. 4.1.1 Fördjupning Det första steget är att göra en fördjupning inom ämnet intrångsdetektering. Detta kan genomföras på olika sätt genom att använda olika typer av källor. Det finns exempelvis artiklar, böcker och intervjuer. De typer av källor som ska användas för den här fördjupningen är framförallt artiklar, böcker och rapporter. Anledningen till detta är att källor i form av intervjuer visar vad personer anser om någonting snarare än ren fakta om hur det fungerar tekniskt sett. Den information om intrångsdetektering som ska tas fram är mer djupgående information om hur olika typer av intrångsdetekteringssystem kan fungera och vad som skiljer Snort och Suricata åt teoretiskt. Detta för att skapa en förståelse som kan behövas för att förstå resultatet som utvärderingen ger. Då en stor del av arbetet kommer bestå av att utföra attacker för att utvärdera systemen behövs information om olika attacker och hur dessa fungerar för att kunna göra ett urval av attacker som ska vara med i utvärderingen. Anledningen till att det är viktigt att förstå hur dessa attacker fungerar är för att kunna välja olika typer av attacker och dela upp dessa i lämpliga grupper. Det finns också olika programvaror så som Metasploit och BackTrack för att utföra attacker och dessa behöver skaffas mer information om för att avgöra vad som kan användas i detta arbete. 7

Metod 4.1.2 Upprätta laborationsmiljö Steg två är att upprätta en laborationsmiljö där testerna kan utföras. Den miljö som utvärderingen kommer ske i, kommer vara hos internetleverantören Studentnätet vid Högskolan i Skövde för att få tillgång till riktig trafik att utvärdera systemen med. Det finns ett flertal alternativ för hur man kan placera sensorn i ett nätverk. Ett av alternativen är att placera sensorn på förbindelsen mellan de noder man vill analysera. Genom att göra detta när det inte finns några alternativa vägar som trafiken kan ta måste den gå igenom sensorn för analys. Denna placering kommer inte att användas i följande arbete på grund av att installationen av denna miljö skulle resultera i driftstopp och otillgängligt Internet för användarna under installationen. Istället kommer sensorn att placeras vid sidan om den lager 3 switch som hanterar förbindelsen ut mot Internet. Sensorn kommer där att anslutas via en länk med gigabithastighet dit trafiken in och ut på Internet speglas så att den kan analyseras. Operativsystemet som ska användas i utvärderingen är OpenBSD. Detta val baseras på att tidigare miljö hos internetleverantören består av maskiner med OpenBSD och en heterogen miljö vill undvikas. OpenBSD är också ett operativsystem inriktat på säkerhet och har enligt Valchev (2007) bara haft två säkerhetshål under tio års tid. Anledningen till att operativsystemets säkerhet är viktig när det handlar om sensorn är för att minimera risken för att sensorn ska kunna bli attackerad. Då sensorn har tillgång till all data som flödar in och ut från nätverket kan denna vara ett stort mål för attacker på grund av att den har tillgång till denna trafik. Installation och konfiguration av intrångsdetekteringssystemen Snort och Suricata kommer att ske med den grundläggande förståelse för hur systemen fungerar som tagits fram i fördjupningen. Genom att använda sig av denna information ska båda system sättas upp med en standardkonfiguration som använder sig av signaturer från Vulnerability Research Team (VRT) och Emerging Threats vilket verkar vara det vanligaste. 4.1.3 Utvärdera systemen Det tredje steget i arbetet är att utvärdera de två system som implementerats. De alternativa lösningar som finns för att utvärdera vilka attacker systemen upptäcker är automatiskt och manuellt. Den automatiska metoden fungerar som så att en applikation som exempelvis Canvas Immunity används för att automatiskt generera attacker som sedan intrångsdetekteringssystemet får analysera. Den här automatiska metoden kommer inte kunna användas i det här arbetet då de applikationer som påträffats är kommersiella och resurser till dessa inte finns. Istället har det manuella alternativet valts att användas för att utföra attackerna. Applikationer för att förenkla den här typen av penetrationstest finns att tillgå utan kostnader. Två av de hjälpmedel som finns är Metasploit och BackTrack. Båda dessa innehåller samlingar av verktyg för att utföra olika typer av attacker och kommer i arbetet att användas för att komplettera varandra. Då även riktig data finns att tillgå ska även denna analyseras av de båda systemen under en given tidsperiod för att se vilka attacker som upptäcks av vilka system. 8

Metod Utöver tester för att kontrollera hur många attacker som upptäcks ska även utvärdering av följande fyra aspekter göras: prestanda, implementeringstid, antal konfigurationsfiler samt vilka operativsystem systemen finns tillgängliga på. Anledningen till att även dessa ska utvärderas är för att få en bredare uppfattning om de egenskaper som kan vara viktigt för de administratörer som ska välja system när ett nätverk ska skyddas med hjälp av ett intrångsdetekteringssystem. Resultatet kommer att presenteras med hjälp av grafer och tabeller. Anledningen till att grafiska illustrationer i form av grafer kommer att användas är för att det ska gå enkelt att få en överblick över resultatet. En mer djupgående förklaring av resultatet kommer även att ske i form av text. 4.1.4 Analys Analysen kommer att bestå av en diskussion kring resultatet och varför det blivit som det blivit, samt vad som kan ha påverkat det. Resultatet eller delar av det kommer också att jämföras med resultat av tidigare arbeten inom området. Enligt Berndtsson, et al. (2008) ska också resultatet analyseras mot delar av den frågeställning som arbetets baserats på, så även detta kommer att vara en del av analysen. 9

Database Resultat 5 Resultat Följande avsnitt syftar till att genomföra delmålen i arbetet och redovisa de resultat som testerna resulterat i. 5.1 Fördjupning Den här fördjupningens syfte är att ta fram mer djupgående information om de två intrångsdetekteringssystem som ska testas. Detta ska göras för att skapa en insikt i hur systemen är uppbyggda och fungerar, vilket kan ge en djupare förståelse av de resultat som senare presenteras i arbetet. Fördjupningen ger även en teoretisk aspekt över vad som skiljer de två olika systemen åt, och grupperingar för de attacker som ska utföras skapas. 5.1.1 Snort När Snort började utvecklas av Marty Roesch i november 1988 var tanken att det bara skulle bli en paketsniffer, då han inte var tillfredställd med paketsniffern tcpdump. Då Snort senare gjordes tillgängligt för fler operativsystem och funktionalitet för att agera intrångsdetekteringssystem blev möjligt ändrade projektets riktning till en mer modulär arkitektur (Ehinger, 2004). Arkitekturen som den ser ut nu består av ett flertal olika moduler som samarbetar för att skapa ett komplett intrångsdetekteringssystem. En bild över hur dessa moduler är sammankopplade kan man se i Figur 2. Network Packets Sniffer (libpcap) Snort Packet Decode Engine Preprocessors Plugins Logfiles/Database Rulesets Alerts/Logs Detection Engine Detection Plugins Output Plugins Figur 2 En bild över arkitekturen för Snort och hur dess moduler samarbetar (Ehinger, 2004). Den första modulen i Snort kallas för sniffer och är den del av applikationen som samlar in paket som senare ska behandlas. De protokoll som stöds är bland annat Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP) och Internet Control Message Protocol (ICMP). Efter att paketen passerat sniffern skickas de vidare till en modul som avkodar paketen från de olika protokollen och gör den data som finns där mer hanterbar till de nästkommande processerna (Ehinger, 2004). När paketen är avkodade går de genom modulen som kallas för preprocessors. Dessa preprocessors avgör om ett paket ska skickas vidare till detection engine eller inte. De används också för att skapa ett större samband mellan de paket som analyseras. Om bara signaturer används för att upptäcka attacker analyseras paketen var för sig och om då attacken är fragmenterad till flera paket upptäcks inte detta. Det är det 10

Resultat här sambandet en preprocessor kan se så att möjligheten att upptäcka bland annat fragmenteringsattacker och portskanningar också finns (Ehinger, 2004). Då paketen skickas vidare till nästa modul, detection engine, kontrolleras det ifall data som finns i paketen matchar mot någon av de signaturer man har inkluderat i Snort. Utöver detection engine finns det detection plugins, vilket är till för att skapa en möjlighet att lägga till ytterligare funktioner för detektering. Dessa funktioner kan vara av typen reguljära uttryck eller avvikelsebaserad detektering. Den sista modultypen som finns i Snort är output plugins, dessa är olika typer av loggningsmekanismer. Med hjälp av de här mekanismerna kan man få Snort att logga till bland annat syslog, tcpdump och olika typer av databaser (Ehinger, 2004). 5.1.2 Suricata Då Suricata är ett relativt nytt projekt har bara en artikel samt information från projektets webbplats hittats, och inte några ytterligare forskningsartiklar. Fokus i fördjupningen kommer därför istället att ligga på personerna bakom Suricata och funktionalitet som finns som en potentiell utmanare till Snort, snarare än tekniken bakom som tidigare kapitel om Snort. Suricata släppte enligt The Open Information Security Foundation (2010) sin första version den 31 december 2009. Styrelsen och gruppen som arbetar med Suricata består av personer med mycket erfarenhet inom området säkerhet, så som Jennifer Steffens som arbetade på Sourcefire med att lansera en kommersiell version av Snort. Även Marc Norton som var en av ledarna för Snort och Matt Jonkman som startat projektet Emerging Threats som skapar signaturer arbetar nu med Suricata. Då Snort i skrivande stund är de facto-standard inom intrångsdetektering har Suricata gjort det möjligt att använda signaturer för Snort i applikationen. Detta gör att Suricata lättare kan utmana Snort då något stort bibliotek av signaturer inte behöver skapas om. Utvecklarna för Suricata har dock utlovat speciella signaturer för Suricata i framtiden. Suricata har även introducerat en funktion till intrångsdetekteringssystem som tillåter applikationen att använda flera processorkärnor. Då kärnan är den del av processorn som läser och exekverar instruktioner ska detta ge möjlighet till att få bättre prestanda och kunna analysera större mängder data. Det är även möjligt att i Suricata använda sig av grafikkortsacceleration vilket innebär att processorn på grafikkortet används för beräkningar som kan ge goda prestandaresultat då denna processor är snabb på att utföra beräkningar (The Open Information Security Foundation, 2010). 5.1.3 Backtrack och Metasploit Backtrack är en modifierad Linuxdistribution med hundratals förinstallerade och konfigurerade applikationer för penetrationstestning. Målet med Backtrack är enligt Offensive Security (2009) att kunna utföra penetrationstester på ett enkelt sätt direkt efter installationen av operativsystemet. 11

Resultat För att enkelt kunna generera attacker i det här arbetet kommer Backtrack att installeras och användas för att få tillgång till alla verktyg på ett enkelt sätt. Backtrack innehåller också Metasploit som också kommer användas för att få tillgång till ytterligare attacker. Metasploit är en plattform som används för att skriva, testa och utnyttja sårbarheter mot olika system (Metasploit, 2009). Anledningen till att Backtrack med Metasploit har valt att användas är för att detta är ett användarvänligt och välanvänt verktyg och har enligt Espenschied (2008) ett stort utbud på hundratals olika moduler för att utnyttja sårbarheter. 5.1.4 Attacker Ett antal attacker ska utföras mot ett system för att jämföra vilka attacker som upptäcks av Snort och Suricata. För att kunna generera dessa attacker behöver en måldator installeras som attackerna kan utföras mot. Baserat på en undersökning av Net Market Share (2010) som uppdateras dagligen är Windows XP i skrivande stund (22 april, 2010) det mest använda operativsystem, ett diagram över detta finns att se i Figur 3. Statistik över operativsystem 64,46 % - Windows XP 16,01 % - Windows Vista 10,23 % - Windows 7 2,26 % - Mac OS X 10.5 2,13 % - Mac OS X 10.6 1,03 % - Linux 3,75 % - Other Figur 3 Statistik över vilka operativsystem som används mest (Net Market Share, 2010). Målmaskinen kommer således att använda sig av Windows XP utan Service Pack och uppdateringar för att möjliggöra så många attacker som möjligt. Någon brandvägg kommer heller inte att konfigureras på maskinen för att det ska bli enklare att utföra attackerna och se om de lyckats. Anledningen till att attackerna ska lyckas är för att det ska gå att se att de verkligen fungerar och har utförts korrekt, och är ingenting som ska påverka om de upptäcks eller inte av systemen. Attackerna som ska utföras är totalt nio stycken jämnt fördelade över tre kategorier. Anledningen till att antalet attacker är nio är för att varje kategori ska få ett mindre antal attacker, samtidigt som det inte är för många för att utföra inom arbetets tidsramar. Valet av attacker har skett slumpmässigt bland de som finns tillgängliga via Backtrack samt Metasploit och utnyttjar tjänster som är igång automatiskt på en Windows XP maskin. De valdes slumpmässigt då detta ansågs mest rättvist samt att tidigare arbeten inom området av bland annat Saltin (2009) använt denna metod. 12

Resultat Kategorierna är uppdelade enligt den modell som Paquet (2009) beskriver, då den gör att man kan dela upp alla sorters attacker i tre grupper som enkelt kan återkopplas till modellen som Pfleeger & Pfleeger (2006) använder för att beskriva informationssäkerhet. 5.1.4.1 Rekognosceringsattacker Rekognosceringsattacker är attacker som går ut på att samla in data om system, tjänster och sårbarheter. Detta görs vanligtvis genom att använda sig av paketavläsningsapplikationer och portskanningar. Informationen man samlar kan efteråt användas för att utnyttja sårbarheterna man hittat för att göra exempelvis accessattacker eller tillgänglighetsattacker. Rekognosceringsattacker kan liknas vid hur en inbrottstjuv smyger runt i grannskapet för att leta efter ett hus där ingen är hemma (Paquet, 2009). Det ska utföras tre rekognosceringsattacker i det här arbetet, dessa tre är portskanning, operativsystemsdetektering samt webbserverdetektering. En förklaring på vad de gör och hur de ska utföras följer nedan. Attack 1 - Portskanning Att skanna efter öppna portar görs för att se vilka som är öppna och utifrån det kunna dra slutsatser om vilka tjänster som används på en maskin. För att göra en sådan här attack kan applikationen Nmap användas, exempelvis såhär: # nmap -p 1-65535 192.168.0.10 Genom att köra det här kommandot skannar man alla portar på maskinen som har IP-adressen 192.168.0.10. Det man är ute efter när man gör en portskanning är portar som har statusen öppen, vilket innebär att en tjänst körs där och möjligheter för sårbarheter finns. En port kan även befinna sig i ett läge som kallas för stängt, där det inte finns någon tjänst som använder porten men den är fortfarande oskyddad. Dessa portar kan också vara en säkerhetsrisk, så det man bör göra är att blockera dessa portar med en brandvägg, så att en portskanning inte kan avgöra om porten är öppen eller inte då paketen för att kontrollera detta blockeras (Nmap, 2010a). Attack 2 - Operativsystemsdetektering Operativsystemsdetektering är en attack som används för att identifiera vilket operativsystem en maskin använder sig av. I vissa fall kan till och med attacken meddela attackeraren vilka Service Pack som är installerade vilket gör det lättare att hitta sårbarheter för att senare utföra en access- eller tillgänglighetsattack. En attack av den här karaktären kan man utföra med följande kommando: # nmap -O 192.168.0.10 När man kör detta kommando så skickar Nmap en rad olika förfrågningar mot maskinen för att kunna analysera svaren. Svaren undersöks bit för bit och jämförs mot en databas för att dra en slutsats om vilket operativsystem maskinen använder sig av (Nmap, 2010b). 13

Resultat Attack 3 - Webbserverdetektering Webbserverdetektering fungerar på ett liknande sätt som detekteringen av operativsystem men det sker istället mot en webbserver. Följande kommando används för att undersöka vilken tjänst som körs på port 80: # nmap -sv -p 80 192.168.0.10 Anledningen till att man vill kunna göra en sådan här attack är för att man inte kan avgöra vilken tjänst som körs bara av vilket portnummer det är. Även om port 80 oftast används för en webbserver finns möjligheterna att det är en annan tjänst (Nmap, 2010c). 5.1.4.2 Accessattacker Accessattacker är de attacker som utnyttjar sårbarheter för framförallt autentisering. En lyckad accessattack ger alltså attackeraren åtkomst till exempelvis webbplatser, databaser, servrar eller andra tjänster. Accessattacker kan genomföras på många olika sätt, bland annat genom att gissa sig fram till lösenord med hjälp av program eller utnyttja sårbarheter i applikationer för att injicera ett gränssnitt som tillåter attackeraren att styra den angripna maskinen (Paquet, 2009). De tre accessattacker som ska genereras i det här arbetet riktas alla mot tjänster som är igång som standard på en Windows XP maskin. Attackerna förklaras i nedanstående rubriker. Attack 4 - Microsoft RPC DCOM Interface Overflow Den första accessattacken utnyttjar en sårbarhet som finns i Microsofts tjänst Remote Procedure Call (RPC) som använder sig av port 135. Anledningen till att sårbarheten går att utnyttja är för att Distributed Component Object Model (DCOM) som används för att kommunicera mellan olika mjukvarukomponenter har otillräckliga kontroller över vilka objekt som aktiveras (SecurityFocus, 2003). Attacken ger möjlighet att exekvera kod som har samma behörighet som det lokala systemet. För att utnyttja sårbarheten med hjälp av Metasploit används modulen som heter windows/dcerpc/ms03_026_dcom. Attack 5 - Microsoft Server Service Relative Path Stack Corruption Precis som ovanstående sårbarhet utnyttjar även denna ett säkerhetshål i RPC. Detta görs enligt Microsoft TechNet (2008) genom att skicka ett specialutformat paket mot tjänsten och med hjälp av detta kunna exekvera kod på målmaskinen utan autentisering. Sårbarheten heter i Metasploit windows/smb/ms08_067_netapi och ett innehåll kan skickas med för att exempelvis kunna styra måldatorn genom en terminal. Attack 6 - Microsoft LSASS Service Overflow Tjänsten Local Security Authority Subsystem Service (LSASS) som används i Windows för att hantera säkerhetspolicys, har ett säkerhetshål av typen buffer overflow. Detta gör att programmet skriver data till minnesplatser som den inte har blivit tilldelad vilket kan skriva över andra applikationers minne (SecurityFocus, 2004). 14

Resultat En lyckad attack kan ge attackeraren möjlighet att få full kontroll över måldatorn via exempelvis en terminal eller fjärrstyrning. För att använda sårbarheten med hjälp av Metasploit anges modulen windows/smb/ms04_011_lsass. 5.1.4.3 Tillgänglighetsattacker Tillgänglighetsattacker minskar tillgängligheten till en tjänst för de användare som vill använda tjänster på ett legitimt sätt. Detta görs genom att skicka extremt stora mängder förfrågningar mot en eller flera servrar för att överbelasta dessa så att legitim trafik inte hinner besvaras av servern (Paquet, 2009). En tillgänglighetsattack kan också genomföras genom att skicka felformaterade paket mot en server vilka den inte vet hur de ska hanteras och därmed resultera i att den kraschar. De tre tillgänglighetsattacker som utförs i arbetet är alla riktade mot Server Message Block (SMB) då detta var den enda tjänst som det fanns denna typ av sårbarheter emot och är igång som standard i Windows. Attack 7 - Microsoft SRV.SYS WriteAndX Invalid DataOffset Protokollet SMB är det som används av Windows främst för att dela resurser över ett nätverk. Sårbarheten ligger i hur SMB hanterar speciellt utformade paket vilket får maskinen som attackeras att krascha och starta om (Microsoft TechNet, 2009). Enligt OSVDB (2008) så är det WRITE_ANDX SMB-paket som kan generera detta beteende och för att skicka ett sådan med hjälp av applikationen Metasploit så laddas modulen med namnet dos/windows/smb/ms09_001_write. Attack 8 - Microsoft SRV.SYS Mailslot Write Corruption Den här attacken utnyttja en funktion i Windows vid namn mailslot. När mailslotfunktionen används så returneras två värden som inkluderas i svarspaketet som skickas iväg. Om de värden som returneras är satta till ett speciellt värde kommer koden som genererar svarspaketet att långsamt göra minnet korrupt (Metasploit, 2010). Attacken heter i Metasploit dos/windows/smb/ms06_035_mailslot, och något mer datapaket behöver inte skickas med då syftet med attacken är att göra datorn otillgänglig. Attack 9 - Microsoft SRV.SYS Pipe Transaction No Null Precis som de två tidigare tillgänglighetsattackerna i det här arbetet är denna attack riktad mot SMB-protokollet. Enligt Common Vulnerabilities and Exposures (2006) så använder sig drivrutinen srv.sys sig av meddelanden som avslutas med värdet null. Attacken skickar ett meddelande av den här typen som inte slutar med null vilket resulterar i att måldatorn kraschar. Den här attacken används på samma sätt som de andra tillgänglighetsattackerna och kallas i Metasploit för dos/windows/smb/ms06_063_trans. 15

Resultat 5.2 Upprätta laborationsmiljö Miljön som testerna ska utföras i kommer att befinna sig hos internetleverantören Studentnätet vid Högskolan i Skövde för att få tillgång till data att analysera. Laborationsmiljön kommer att bestå av två servermaskiner av modell Dell PowerEdge SC1435 som har AMD Opteron-processorer med 64-bitars arkitektur. Servrarna har identisk hårdvara och ska köra ett system var där testerna ska utföras. Operativsystemet som används under testerna är OpenBSD då det har fokus på säkerhet vilket kan behövas för att skydda den data som sensorn har tillgång till. De signaturer som kommer att användas i utvärderingen för Snort och Suricata är regeluppsättningarna från VRT och Emerging Threats. Senaste versionen av reglerna från VRT är i skrivande stund 2860 och f ör Emerging Threats version 6177. Alla de regler som finns med i regeluppsättningarna inkluderas inte då det finns en mängd för att upptäcka multimedia, chatt och liknande policys som i första hand är för företag. De regelfiler som inkluderas är de samma för båda systemen och konfigurationen för respektive system finns att se i Bilaga A och B. 5.2.1 Nätverkstopologi Den nätverkstopologi som kommer att användas är av den typen där sensorn är placerad på ett ställe som inte kommer skapa driftstopp i nätverket. De två maskiner som har installerats och konfigurerats placeras vid sidan av den Cisco 4503 lager 3 switch som finns i nätverket, en bild över denna topologi finns att tillgå i Figur 4 nedan. Figur 4 - Nätverkstopologi som beskriver vart Snort och Suricata har placerats. Servrarna som används har två gigabitlänkar vardera kopplade till sig för att kunna separera trafiken som ska analysera från den som är till för att administrera servern. För att serverarna ska få tag på den trafik som klienterna genererar konfigureras lager 3 switchen att spegla den trafik som flödar in och ut genom porten mot klienterna, till maskinerna med Snort och Suricata. Genom att ha två länkar till varje server och separera trafiken undviker man att administrationstrafiken drunknar i all data som skickas för analys, och fördröjning undviks. 16

Antal unika alarm Resultat 5.3 Utvärdera systemen Under utvärderingen som gjorts har signaturer från VRT och Emerging Threats används, som tidigare nämnts. Av de regelfiler som inkluderades klarade Snort av att ladda 11579 signaturer medans Suricata laddade 11796. Varför den här skillnaden finns kan bero på hur reglerna är skrivna och de hanteras olika vid inläsning. Skillnaden är värd att notera då den skulle kunna påverka resultatet. 5.3.1 Antalet attacker som upptäcks För att mäta antalet attacker som respektive intrångsdetekteringssystem upptäcker har två tester utförts. Första testet använder den data som finns tillgänglig via den internetleverantör som arbetet utförs hos, för att analysera riktig trafik på ett nätverk som används i drift. Då det i detta test inte går att kontrollera huruvida alarmen som genereras är äkta eller falska, har ytterligare ett test utförts under mer kontrollerad miljö. Det första testet utfördes genom att använda de maskiner och konfigurerade system som satts upp, för att analysera samma trafik under samma tidsperiod på 30 minuter. När testet var slutfört analyserades loggfiler för att sortera och presentera den data som erhållits. Nedan i Figur 5 finns ett stapeldiagram som visar antalet unika alarm som skapades av Snort respektive Suricata under testperioden. Antal unika alarm 200 175 150 125 100 75 50 25 0 Intrångsdetekteringsysstem Snort Suricata Figur 5 Antal unika alarm som genererats av Snort respektive Suricata under 30 minuter. Som diagrammet visar har Snort genererat 98 unika alarm mer än vad Suricata har gjort, och för att se vad det kan bero på har alarmen analyserats ytterligare. Då bara en siffra på antal unika alarm inte berättar någonting om vilka typer av attacker som faktiskt upptäckts behandlades loggfilerna var för sig. Behandlingen resulterade i en lista över antal alarm för de olika attacker som rapporterats. Ett diagram som visar hur många alarm som genererats för varje attack av de båda systemen finns att se i Figur 6 nedan. 17

Attacker Resultat Upptäckta attacker Bare byte unicode Denial of Service attack DNS spoof Encrypted FTP traffic Executable shellcode Experimental TCP options Compromised traffic Russian Business Network Malware Simbar Remote MySQL-server scan Oversize URI directory Safari heap overflow Portscan Portsweep SQL version overflow Trojan Brontok Unknown keepalive Worm Allaple Suricata Snort 0 10 20 30 40 50 60 70 80 90 100 110 Antal alarm Figur 6 - Diagram över hur många alarm respektive system genererat för samtliga attacker. Som man kan se i diagrammet har Snort genererat alarm för fler olika attacker än vad Suricata har gjort och även en stor mängd alarm för portsweeps. Det är alltså framförallt på grund av portsweeps som Snort har genererat fler antal unika alarm än Suricata, och anledningen till att detta skiljer sig åt kan bero på hur systemens preprocessorer arbetar och vilken data dessa kan analysera. Det andra testet gick ut på att generera egna attacker med hjälp av Backtrack och Metasploit, resultatet över vilka attacker som upptäcktes av de båda systemen presenteras i Tabell 1 nedan. Tabell 1 Tabell över vilka attacker som upptäckts av Snort och Suricata. Attack Namn Snort Suricata 1 Portskanning Ja Ja 2 Operativsystemdetektering Ja Ja 3 Webbserverdetektering Nej Ja 4 Microsoft RPC DCOM Interface Overflow Ja Ja 5 Microsoft Server Service Relative Path Stack Corruption Ja Ja 6 Microsoft LSASS Service Overflow Ja Ja 7 Microsoft SRV.SYS WriteAndX Invalid DataOffset Nej Nej 8 Microsoft SRV.SYS Mailslot Write Corruption Ja Ja 9 Microsoft SRV.SYS Pipe Transaction No Null Ja Ja 18

Resultat Attackerna utfördes en i taget och noteringar gjordes efter varje attack ifall systemet genererade alarm eller inte. Som tabellen visar upptäckte Suricata åtta av nio attacker, vilket är mer än Snort som upptäckte sju av nio attacker. 5.3.2 Implementeringstid och antal konfigurationsfiler Implementeringstiden har mätts genom att kontrollera hur lång tid det tog att installera och göra en grundkonfiguration för systemen. Värt att notera är att implementering är gjord av en person med treårig högskoleutbildning inom nätverkoch systemadministration. Antal konfigurationsfiler som mätts upp är de som har behövts ändras i för att få systemen att fungera. Resultatet går att se i Tabell 2 nedan. Tabell 2 Antal konfigurationsfiler och hur lång tid implementeringen tog för de två systemen. Intrångsdetekteringssystem Antal konfigurationsfiler Implementeringstid Snort 2 3 timmar Suricata 1 4 timmar Som man kan se i tabellen krävde installation och konfigurering av Suricata en timme mer än för Snort, men värt att nämna är att Suricata inte finns i något färdigt paket utan kräver att man kompilerar det, vilket tar extra tid. 5.3.3 Prestanda och operativsystemstöd Den prestanda som har mätts upp i arbetet är hur mycket processor- respektive minnesanvändning de båda systemen använder under drift. Mätningarna har gjorts med hjälp av Unix-kommandot top för att få reda på hur mycket kapacitet som använts. Ett perl-script skapades som hämtade information om minnes- och processoranvändning med hjälp av top med 60 sekunders mellanrum. För att prestandan ska gå att placera mer i kontext till hur mycket data som analyserats har statistik om detta samlats in under testet. I Figur 7 nedan kan man se hur många Mbit/s trafik som analyserats under de 30 minuter som testet genomförts. Det visas även en graf för hur många paket per sekund som analyserats, vilket också kan vara intressant i prestandasyfte. Figur 7 Trafikmängd i Mbit/s och paket per sekund under de 30 minuter som testerna genomförts. 19

Megabyte Procent Resultat Nedan i Figur 8 visas den processoranvändning som de båda systemen hade under de 30 minuter som testet utfördes. Anledningen till att procenten går upp till 200 i diagrammet beror på att maskinerna som används har dubbla processorkärnor. Processoranvändning 200 175 150 125 100 75 50 25 0 1 4 7 10 13 16 19 22 25 28 Tid i minuter Snort Suricata Figur 8 - Processoranvändning för Snort och Suricata under 30 minuter. Diagrammet visar tydligt att Suricata använder sig nästan fullt ut av båda processorkärnorna medans Snort bara använder en maximalt. Nästa del av testet kontrollerar hur mycket minne som systemen använde under tiden testet pågick. Figur 9 nedan presenterar resultatet av testet med minnesanvändning. 500 Minnesanvändning 400 300 200 Snort Suricata 100 0 1 4 7 10 13 16 19 22 25 28 Tid i minuter Figur 9 - Minnesanvändning för Snort och Suricata under 30 minuter. Som man kan se i diagrammet använder Suricata runt 100 Megabyte mindre minne än vad Snort gör. Operativsystemen som systemen finns tillgängliga till skiljer sig lite åt. Enligt Snort (2010) finns applikationen att ladda ner till både Windows och Linux. Det finns binärer till både Red Hat Linux och Windows, och även källkoden finns att tillgå. Suricata däremot finns enligt The Open Information Security Foundation (2010) tillgängligt till Linux, Mac, FreeBSD, UNIX och Windows. Men några färdiga paket finns inte att ladda ner, utan bara källkod som kräver att man kompilerar applikationen för att den ska kunna köras. 20

Resultat 5.4 Analys Analysen kommer som Berndtsson, et al. (2008) rekommenderar att innehålla en utvärdering och diskussion av resultatet mot den frågeställning som arbetet har. För att göra det så systematiskt som möjligt kommer detta göras för ett delmål i taget för att i nästkommande kapitel presentera en slutsats. 5.4.1 Antalet attacker som upptäcks Resultatet som åstadkoms av de tester som gjordes för att undersöka hur många och vilka attacker som upptäcktes av respektive system, visar att Snort genererade fler alarm än Suricata. Mycket alarm behöver inte alltid vara bra utan kan också vara en nackdel vilket Sommer & Paxson (2003) till och med påstår kan vara det största problemet med nätverkbaserade intrångsdetekteringssystem. Enligt Lippmann, Webster & Stetson (2002) genereras ofta för mycket alarm per dag vilket resulterar i att analytiker spenderar flera timmar dagligen på att undersöka alarm utan något större värde. För att avgöra huruvida de alarm som genererats av de båda systemen kan anses vara av värde analyserades loggfilerna och resultatet presenteras i Figur 6 under kapitel 7.1. Man kan här se att en stor del av de alarm som Snort har genererat består av portsweeps. Enligt Lawrence (2000) används portskanningar av attackerare för att undersöka vilka tjänster som körs för att sedan kunna utnyttja sårbarheter i dessa. Portsweeps används i samma syfte som portskanningar men utförs istället mot ett större antal maskiner snarare än ett fåtal. Även om portskanningar och portsweeps kan användas till detta anser Panjwani, Tan, Jarrin & Cukier (2005) som utfört ett experiment för att undersöka om det finns en korrelation mellan portskanningar och attacker, att det inte bör ses som en indikation till att en attack ska ske. Resultatet visar att över 50 % av attackerna inte föregicks av någon form av skanning och därför inte kan anses vara ett tecken på en attack. Om man med detta som grund bortser från de alarmen genererats på grund av portskanningar och portsweeps har Suricata ett fåtal fler unika alarm än Snort. Testet där attacker genererades med hjälp av Backtrack och Metasploit presenteras i Tabell 1 under kapitel 7.1 och här kan man se att Suricata upptäcker alla attacker förutom attack nummer 7. Inte heller Snort upptäcker denna attack. Snort upptäcker inte heller webbserverdetekteringen som utfördes, det vill säga attack nummer 3. Precis som med portskanningen är denna attack en rekognosceringsattack och det går diskutera ifall detta ska klassas som en indikation till en allvarligare attack. Utifrån det här resultatet kan man se att de båda systemen presterar väldigt lika när det gäller antalet attacker som upptäcks. Även om Suricata är relativt nytt inom intrångsdetektering kan det med sitt stöd för att använda signaturer skrivna för Snort upptäcka lite fler attacker av de som utförts i det här arbetet än Snort. 5.4.2 Implementeringstid och antal konfigurationsfiler Den tid det tog att installera och göra en enkel grundkonfiguration av Snort och Suricata var tre respektive fyra timmar. Detta är relativt kort tid om man sätter det i kontext till en administratörs arbetsdag. Största anledningen till att Suricata tog längre tid att installera är för att det behöver kompileras och kataloger för 21