Bearbetningstid och CPU-användning i Snort IPS : En jämförelse mellan ARM Cortex-A53 och Cortex-A7

Bearbetningstid och CPU-användning i Snort IPS

HUVUDOMRÅDE: Datateknik

FÖRFATTARE: Al-Husein Nadji & Haval Sarbast Hgi HANDLEDARE:Sigurd Israelsson

Postadress: Besöksadress: Telefon:

Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom Datateknik. Författarna svarar själva för framförda åsikter, slutsatser och resultat.

Examinator: Anders Adlemo Handledare: Sigurd Israelsson Omfattning: 15 hp (grundnivå) Datum: 2020-10-28

Abstract

The purpose of this study is to examine how the processing time of the Snort intrusion prevention system varies on two different processors; ARM A53 and Cortex-A7. CPU usage was also examined to check if processing time depends on how much CPU Snort uses.

This study will provide knowledge about how important a processor is for Snort to be able to perform well in terms of processing time and CPU usage. This knowledge will help choosing between Cortex-A53 and Cortex-A7 when implementing Snort IPS.

To achieve the purpose of the study a literature search has been done to design an experimental environment. Snort can be classified as CPU-bound, which means that the system is dependent on a fast processor. In this context, a fast processor means that Snort is given enough time to process the amount of traffic it receives, otherwise the traffic can pass through without it being inspected, which can be harmful to the device that is protected by Snort.

The results of the study show that the processing time in Snort on Cortex-A53 and Cortex-A7 differs and an obvious difference in CPU usage between the processors is shown. The study also presents the connection between processing time and CPU usage for Snort.

In conclusion, ARM Cortex-A53 has better performance when using Snort IPS in terms of processing time and CPU usage,Cortex-A53 has 10 seconds less processing time and uses 2,87 times less CPU.

Keywords

Sammanfattning

Syftet med denna studie är att undersöka hur bearbetningstiden hos Snort

intrångsskyddssystem varierar mellan två olika processorer; ARM Cortex-A53 och Cortex-A7. CPU-användningen undersöktes även för att kontrollera om

bearbetningstid är beroende av hur mycket CPU Snort använder.

Denna studie ska ge kunskap om hur viktig en processor är för att Snort ska kunna prestera bra när det gäller bearbetningstid och CPU användning samt visa det

uppenbara valet mellan Cortex-A53 och Cortex-A7 när man ska implementera Snort IPS.

Med hjälp av litteratursökning konstruerades en experimentmiljö för att kunna ge svar på studiens frågeställningar. Snort kan klassificeras som CPU-bunden vilket innebär att systemet är beroende av en snabb processor. I detta sammanhang innebär en snabb processor gör att Snort hinner bearbeta den mängd nätverkstrafik den får, annars kan trafiken passera utan att den inspekteras vilket kan skada enheten som är skyddat av Snort.

Studiens resultat visar att bearbetningstiden i Snort på Cortex-A53 och Cortex-A7 skiljer sig åt och en tydlig skillnad i CPU-användning mellan processorerna observerades. Studien visar även kopplingen mellan bearbetningstiden och CPU-användning hos Snort.

Studiens slutsats är att ARM Cortex-A53 har bättre prestanda vid användning av Snort IPS avseende bearbetningstid och CPU-användning, där Cortex-A53 har 10 sekunder kortare bearbetningstid och använder 2,87 gånger mindre CPU.

Nyckelord

Innehållsförteckning

Abstract ... i

Sammanfattning ... ii

Innehållsförteckning ... iii

1 Introduktion ... 6

1.3SYFTE OCH FRÅGESTÄLLNINGAR ... 10

1.4OMFÅNG OCH AVGRÄNSNINGAR ... 11

1.5DISPOSITION ... 12

2 Teknisk bakgrund ... 13

2.1ARM ... 13

2.1.1 ARM CPU Arkitektur ... 14

2.1.2 Cortex-A53 ... 15

2.1.3 Cortex-A7 ... 16

2.1.4 Skillnaden mellan Cortex-A53 och Cortex-A7 ... 16

2.2INTRÅNGSDETEKTERINGSSYSTEM (IDS) OCH INTRÅNGSSKYDDSSYSTEM (IPS) ... 16

2.2.1 Nätverk-baserad ... 17

2.2.2 Host-baserad ... 17

2.2.3 Applikation-baserad ... 17

2.3RASPBIAN BUSTER LITE ... 17

2.4RASPBERRY PI ... 18

2.4.1 Rasberry Pi 2 modell B ... 18

2.4.2 Raspberry Pi 3 B+ ... 18

2.4.3 Raspberry Pi specifikationer ... 18

2.5SNORT ... 19

2.5.1 Regler och lägen... 19

2.6WIRESHARK ... 20

2.7SAR ... 20

2.8IPERF3 ... 20

3 Metod och genomförande ... 21

3.1INLEDNING ... 21

3.2.1 Litteratursökning... 21 3.2.2 Experiment ... 22 3.3ANSATS ... 22 3.4ARBETSPROCESS ... 22 3.5EXPERIMENTDESIGN ... 23 3.5.1 Mjukvara ... 23 3.5.2 Hårdvara ... 26 3.5.3 Fysisk nätverkstopologi ... 26 3.6EXPERIMENTET ... 28 3.7DATAANALYS ... 29 3.8TROVÄRDIGHET ... 29 3.8.1 Litteratursökning ... 29 3.8.2 Experiment ... 29

4 Teoretiskt ramverk ... 31

5 Empiri ... 33

5.1.1 Snort avaktiverad och Snort i idle-läge ... 34

5.1.2 Snort aktiv/av med Iperf-trafik ... 36

5.1.3 Snort I/O-bunden ... 38

6 Analys ... 39

6.1STANDARDAVVIKELSE PÅ SAMTLIGA TESTER ... 39

6.1.1 Cortex-A53... 39

6.1.2 Cortex-A7 ... 40

6.1.3 Tolkning av testerna ... 40

6.2 ANDRA CPU-ANMÄRKNINGAR ... 41

6.3 FRÅGESTÄLLNING 1 ... 43

6.4 FRÅGESTÄLLNING 2 ... 44

6.5 SNORT I/O-BUNDEN ... 45

7

Diskussion och slutsatser ... 46

7.1RESULTAT ... 46

7.2IMPLIKATIONER ... 48

7.3BEGRÄNSNINGAR ... 48

7.4SLUTSATSER OCH REKOMMENDATIONER ... 48

1 Introduktion

1.1 Bakgrund

Idag är samhället mer integrerad inom ”Internet of Things” [1]. Att vara uppkopplad till internet är viktigt i både sociala och ekonomiska sammanhang men eftersom mycket arbete sker på internet blir det viktigt att skydda sin data. Såväl hemmiljöer som företagsmiljöer väljer att vara uppkopplade till nätetökar kraven på att

konfidentiella data skyddas mot intrångsförsök. Därför är det viktigt att ett system som förebygger attacker finns. [2].

För att ett intrångsförsök ska kunna upptäckas kan ett intrångsdetekteringssystem (IDS) eller ett intrångsskyddssystem (IPS) användas. IDS är ett system eller en mjukvara som övervakar nätverkets inkommande attacker samt övervakar det som bryter nätverkspolicyer. IDS genererar sedan ett alarm [3]. Ett IPS genererar alarm och hindrar skadlig nätverkstrafik från intrångsförsök. Snort är ett sådant system som både kan användas som IDS eller IPS i en valfri hårdvara.

Snort är en av världens mest kända öppna IDS/IPS-källkoder och anses ha en enorm regeluppsättning för skadlig trafik, där Snort söker på väldigt specifika utdrag i trafikgenomströmningen och rapporterar varje instans från utdraget [4]. Den kan analysera nätverkstrafik i realtid samt upptäcka och hindra skadlig trafik. På så sätt kan man skydda ett nätverk mot hot.

Snort är användarvänlig och har en aktiv nätgemenskap. För användning av Snort behövs tidigare kunskap om nätverkssäkerhet men guiderna för Snort ger en ny användare goda möjligheter att sätta upp ett system inom de ramar som användaren kräver av ett IDS/IPS. En aktiv nätgemenskap uppdaterar Snort regelbundet. Snort är gratis för användning och har även vissa kostnadsfria regeluppsättningar, men om användaren skulle vilja utöka regeluppsättningarna tillförs däremot en kostnad.

Med rätt verktyg kan både hemanvändare och mindre företag upptäcka attacker och ingripa mot dessa. Ett exempel på ett sådant verktyg är Raspberry Pi som är en enkel enkortsdator med lågt underhållsbehov. I en tidigare studie från 2015 presenterades möjligheten att använda Snort på Raspberry Pi med en 32-bit Cortex-A7 processor

[5]. Sedermera har ARM utvecklats till Cortex-A53 processor med 64-bits arkitektur som är en efterföljare till Cortex-A7. En 64-bit är kapabel att hantera mer data samtidigt. 64-bit kan också spara fler beräkningsvärden detta inkluderar minnesadresser vilket innebär att den har åtkomst till över fyra miljarder fler minnesadresser än 32-bits processor [6].

Med Snort installerat på en Raspberry Pi kan den således användas som ett IDS/IPS. Cortex-A53 och Cortex-A7 finns integrerade i Raspberry Pi. Processorerna som används har en ARM-arkitektur. Inom Raspberry Pi-serien finns det flera modeller [7]. Några av dessa är Raspberry Pi 2 modell B med en ARM Cortex-A7 processor och Raspberry Pi 3 modell B+ med en ARM Cortex-A53 processor som ska användas i denna studie. Dessa processorer tillsammans med Snort kommer vara studiens fokuspunkt.

1.2 Problembeskrivning

I en studie av Aspernäs och Simonsson (2015) undersöktes nätverksprestanda mellan Raspberry Pi B+ och Raspberry Pi 2 modell B när Snort intrångsdetekteringssystem implementerades i inline-läge. Ett IDS som sitter i inline-läge kan även kallas för IPS för att nätverkstrafiken som mottages måste kontrolleras och godkännas för att inte vara skadlig innan den kan nå slutmålet. IPS ger en realtidsrespons och låter inte skadlig nätverkstrafik passera medan ett IDS låter skadlig nätverkstrafik passera innan den kan ge respons [8]. Prestandan i studien definierades som

nätverksgenomströmningen i Mbits/s. Studien undersökte även CPU och minnesanvändningen [5].

Detta examensarbete inspirerades av den ovannämnda studien för deras användning av Snort i inline-läge med realtidsrespons när de undersöker nätverksgenomströmning och I/O-prestanda på två olika Raspberry Pi-modeller. När Snort är I/O-bunden läggs mycket tyngd på hårdvarans minne.

I detta examensarbete är CPU-bindning det primära fokuset för Snort.

Snort kan klassificeras som CPU-bunden, detta innebär att en CPU:s hastighet är väldigt viktig. Där tillbringar Snort mest av sin körningstid på att bearbeta och

analysera nätverkspaket. En CPU-bunden applikation är en applikation som begränsas av CPU:s hastighet [9]. För att Snort ska fungera effektivt måste den hinna analysera den mängd ökande nätverkstrafik som skickas idag då konsekvenserna kan bli stora för nätverkssäkerheten. Ett nätverksintrångsdetekteringsystem/nätverksskyddssystem som misslyckas med att inspektera nätverkspaket med den nödvändiga hastigheten eller bearbetningstiden, möjliggör nätverspaket att komma åt ett nätverk utan att det upptäcks [10, pp, 57]. Bearbetningstiden är från den tidpunkten då Snort får in nätverkstrafik till den tidpunkt då Snort har inspekterat klart trafiken. Denna process kan observeras genom CPU-användning. När Snort får in nätverkstrafik ökar CPU:s procentuella användning och sjunker när den har inspekterat klart trafiken.

CPU-användning visar hur mycket kapacitet från processorn som används av

systemet. Är processorns användning 100% innebär detta att man inte kan köra flera applikationer [11].

I en studie av Khan, Minallah och Said (2018) undersöktes körningstiden för bildkompression med kompressionsalgoritmen JPEG (Joint Photographic Experts Group) på två olika processorer; Cortex-A53 och Cortex-A7. Cortex-A53 är den utvecklade processorn av sin föregångare Cortex-A7. Cortex-A53 är en 64-bits processor med låg effekt. Den har en stor prestandaförbättring jämfört med Cortex-A7. Studien påvisade att testerna som utfördes på körningstiden för

bildkompressionen (JPEG algoritmen) i Cortex-A53 jämfört med Cortex-A7 var snabbare [12]. Utifrån denna information kommer skillnaden i bearbetningstid hos Snort att undersökas i detta examensarbete. Huvudarkitekten för Cortex-A53 menar att all förbättring som gjordes i processorn resulterade i en prestandaförbättring på 140% i SPECint-2000 benchmark [13]. SPECint-200 benchmark används för att mäta hur snabbt den kör CINT200 program. CINT200 programmen innehåller 17 program som mäter integer prestanda hos en enhet [14].

Då Snort är beroende av en snabb processor undersöks Snorts bearbetningstid på Cortex-A53 och Cortex-A7. Snorts utvecklare menar att ju mer CPU Snort använder desto sämre presterar den [15]. Att Snort börjar använda mer CPU har med

processorns prestanda att göra, därför undersöks även CPU-användningen på processorerna.

1.3 Syfte och frågeställningar

Syftet med detta examensarbete är att undersöka Snorts bearbetningstid och CPU-användning när nätverkstrafik skickas till en måldator igenom Raspberry Pi 2 modell B och Raspberry Pi 3 modell B+ där Cortex-A7 respektive Cortex-A53 används. I en Questions and Answers (Q&A) med huvudarkitekten för Cortex-A53 Peter Greenhalgh som hölls av AnandTech fick Greenhalgh en fråga om

prestandaskillnaden mellan Cortex-A7 och Cortex-A53. I sitt svar menade

Greenhalgh att all förbättring som gjordes i A53 från sin föregångare Cortex-A7 gav en ökning på SPECInt-2000 benchmark på 0.15-SPEC/MHz, alltså 1.4 gånger så stor som Cortex-A7 och att denna prestandaskillnad borde vara märkbar i

kommande generationer av smartmobiler som använder Cortex-A53 processor [13]. Utifrån Greenhalghs svar har en hypotes formulerats, att Snorts bearbetningstid kommer vara 1,4 gånger snabbare på Cortex-A53 jämfört med Cortex-A7. Dessa frågor ställs:

• Hur mycket skiljer sig Snort intrångsskyddssystemetsbearbetningstid mellan Cortex-A53 och Cortex-A7 när nätverkstrafik skickas?

• Hur mycket CPU använder Snort intrångsskyddssystemetnär den bearbetar nätverkstrafiken som skickas på Cortex-A53 till skillnad från Cortex-A7?

1.4 Omfång och avgränsningar

Typen av intrångsdetekteringssystem/intrångsskyddssystem som har valts är Snort. Snort kan köras på både Windows och Unixbaserade system samt på mindre

plattformar såsom en Raspberry Pi [16]. Att den kan köras på en Raspberry Pi är i vårt fall viktigt för studiens syfte och budget, samt att Snort är kostnadsfritt för privat användning.

ARM processorerna inom Cortex har tre grupperingar, dessa är Cortex-R, Cortex-M och Cortex-A. Studien kommer enbart innefatta Cortex-A processorer.

För att vår hypotes skall gå att undersöka är det viktigt för arbetet att val av Raspberry Pi använder de processorerna som utgör arbetets fokuspunkt. Raspberry Pi 3 modell B+ använder Cortex-A53 som processor och denna kommer att användas. Raspberry Pi 2 modell B har två versioner som använder två olika processorer. De två olika versionerna är etiketterade med v1.1 för den första utgåvan och v1.2 för den andra utgåvan. Version 1.1 använder Cortex-A7 vilket är det som kommer att användas. Version 1.2 använder samma processor som Raspberry Pi 3 modell B+.

Det valda operativsystemet är Raspbian Buster Lite då den är mindre resurskrävande vilket gör Rasbian till ett bra val av OS då Snort saknar GUI. I en tidigare studie har lite versionen av Raspbian använts för att inget kompatibilitetsproblem ska uppstå med Snort [16].

Vi undersöker inte om Snort detekterar inkommande hot från nätverkstrafik korrekt utan bara bearbetningstiden.

Experimenttiden kommer att vara 5 minuter med 1 extra minut när nätverkstrafik skickas för att Snort ska hinna bearbeta klart nätverkstrafiken som skickas igenom. Nätverkstrafiken genereras via Iperf3. Trafiken från Iperf3 kommer vara UDP-protokoll som är ett kommunikationsUDP-protokoll mellan olika datorenheter. Snort kan analysera fyra olika nätverksprotokoll men den har begränsats till UDP-protokoll.

I den här studien används även en Snort-regel för igenkänning av UDP-protokoll, detta för att presentera skillnaden mellan CPU-bindning och I/O-bindning.

1.5 Disposition

Kapitel 2 – Teknisk bakgrund:

Presenterar fakta kring val av mjukvara och hårdvara.

Kapitel 3 – Metod och genomförande:

Beskriver designen och genomförande samt vad som kontrolleras vid tester.

Kapitel 4 – Teoretisk ramverk:

Kommer innehålla teoretiska ramverk.

Kapitel 5 - Empiri:

Presenterar insamlade data från experiment.

Kapitel 6 - Analys:

Resultaten presenteras och analyseras.

Kapitel 7 – Diskussion och slutsatser:

Sammanfattning av insamlade data och diskussion.

2 Teknisk bakgrund

I detta kapitel förklaras val av hårdvara och mjukvara och deras tillämpningar i experimentdesignen.

2.1 ARM

ARM-Holdings är ett företag som skapar halvledare och designar mjukvara. Deras teknologi når upp till 70% av världens population [17]. ARM-Holdings är skaparna till bland annat processorerna Cortex-A7 och Cortex-A53.

En processor utför olika uppgifter beroende på dess arkitektur. En processors arkitektur är en design som utgår från flera år av forskning och kan definiera olika programmerares modeller som täcker alla aspekter av designen. En arkitektur är en design och en processor är en enhet [18, pp.7]. Den nyaste arkitekturen för ARM är ARMv8.

ARM är en samling av Reduced Instruction Set Computing (RISC) som är en

klassificering av en processorsarkitektur. Processorerna är ledande på marknaden och anledningen till detta är att de konsumerar lite energi [19]. De klassiska processorerna heter ARM följt av ett nummer men sedan 2004 har processorerna släppts under Cortex [18, pp.8].

Inom Cortex finns tre grupperingar utifrån deras egenskaper, nämligen Cortex-R, Cortex-M och Cortex-A. Cortex-R är en snabb processor som är kapabel till realtidsrespons och återfinns i till exempel bil-system. Cortex-M är den med minst kraft och har en lägre prestanda än A och R. Cortex-M finns i mikrokontroller i små fabrikssystem. Cortex-A är en applikationsprocessor och är designad att fungera som en dator. Cortex-A kan hittas i till exempel mobiler [18, pp.7].

2.1.1 ARM CPU Arkitektur

Figur 1 visar skillnaden mellan processorerna som kör på en ARMv7 respektive ARMv8, där de processorer som kör på ARMv8 stödjer både 32-bit och 64-bit. Figur 1 tydliggör att processorerna i grön färg är för ARMv7 arkitektur och blå färg tillhör processorer för ARMv8 arkitektur. Figuren kategoriserar processorerna inom sin arkitektur i grupperna hög prestanda, hög effektivitet och ultrahög effektivitet [21].

Utvecklingen av ARMv8 visas i figur 2. Utvecklingen har introducerat ett par

förändringar som gör det möjligt för processorn att ha högre prestanda samtidigt som den är bakåtkompatibel med ARMv7. ARMv8 kan därmed köra både AArch64 och AArch32 tillämpningar medan ARMv7 är begränsad till AArch32 tillämpningar [22].

Figur 1. ARM CPU arkitektur ARMv7 och ARMv8

ARMs instruktionsuppsättning arkitektur (ISA) definierar hur en mjukvara styr CPU. I ARM ISA ges möjligheten för utvecklare att arbeta inom ARMs specifikationer med vetskap om att allt arbete som görs kan köras inom alla processorer som är ARM-baserad. ARMs arkitektur stödjer tre instruktionsuppsättningar, dessa är A64, A32 och T32 [23].

A64 introducerades med ARMv8 för att stödja 64-bitsarkitekturen [24]. A32 som kallas ”ARM” finns inom ARMv7 och ARMv6 [25].

T32, känd som ”Thumb”, är en mix av 32- och 16-bits ISA [26].

2.1.2 Cortex-A53

Cortex-A53 är den processor som används i störst utsträckning. Det är en processor som har en god balans mellan effektivitet och prestanda. Eftersom den är tillverkad för en låg strömkonsumtion är den tillgänglig i flera enheter som kräver en kraftfull processor som är begränsad i energiförbrukning. Den är förbättrad avseende prestanda och strömförbrukning jämfört med tidigare processorer [28].

Den använder en processor med ARMv8-A. Eftersom ARMv8 stödjer både 64-bit och 32-bit är Cortex-A53 backkompatibel med ARMv7 kod.

2.1.3 Cortex-A7

Cortex-A7 är den minsta och mest energisnåla processorn för 32-bit arkitektur, dess bästa egenskap är att den är väldigt energisnål samtidigt som prestandan bevaras. Den är den processorn med högst effektivitet av alla processorer som kör på ARMv7 [30].

2.1.4 Skillnaden mellan Cortex-A53 och Cortex-A7

Skillnaden mellan ARM Cortex-A7 och Cortex-A53 är att Cortex-A7 använder 32-bit mikroprocessor med ARMv7 arkitektur [31]. Till skillnad från den tidigare versionen Cortex-A8 är Cortex-A7 mer strömsnål, mindre och enklare att använda. Den kan användas i en big.LITTLE arkitektur [32]. Cortex-A53 är en av de två första mikroarkitekturer som använder ARMv8 arkitektur 64-bit ISA. Den kan användas fristående som ett mer energisnålt alternativ eller användas i en big.LITTLE konfiguration med en kraftfullare mikroarkitektur [33].

2.2 Intrångsdetekteringssystem (IDS) och intrångsskyddssystem (IPS)

Ett IDS eller IPS kan vara ett system som har i uppgift att automatiskt hitta och varna användaren närett intrångsförsök pågår.IDS har inte som ändamål att skydda själva systemet, det är IPS till för. IPS ser till att trafiken kontrolleras, om den skulle

innehålla hot varnar IPS och ser till att trafiken inte kommer igenom. De IDS/IPS som finns tillgängliga kan klassificeras i tre olika grupper; Nätverk-baserad, Host-baserad och Applikation-baserad [34]. Snort är Nätverk-baserad.

2.2.1 Nätverk-baserad

Snort övervakar nätverkstrafiken för att sedan analysera till exempel vad som skickas och om detta beteende är misstänksamt. Det finns tre olika sätt att samla

nätverkstrafik: String signaures, Port signatures och Header signatures [34]. String signatures fungerar genom att identifiera en text som är relaterad till händelse inom paketdata. Port signatures övervakar en specifik port inom nätverket. Header signatures övervakar paketdatans headers och kontrollerar farliga och ologiska förfrågningar. Under mycket arbete, hög nätverkstrafik i nätverket kan Nätverk-baserad bli sårbar för attacker och börja ignorera paket som går igenom [35]. 2.2.2 Host-baserad

Host-baserad kan ha i uppgift att övervaka och analysera interna komponenter i ett datorsystem. Den kontrollerar allt som sker i systemet och vid ändringar kollar den igenom systemet genom hashing och genererar därmed en ny logg [34]. Skulle detta sedan matcha med existerande logg skickar systemet ut en varning till

systemadministratören. Till skillnad från Nätverk-baserad har Host-baserad

övervakning på attacker inifrån, en fördel med detta är att noggrannheten ökar och att Host-baserad kan förklara vad för typ av attack det är. Dock är den resurskrävande och responstiden är långsam, därmed kan den inte ge realtidrespons [35].

2.2.3 Applikation-baserad

Fungerar som en Host-baserad som är designad till att övervaka en specifik applikation. Den är effektiv med att upptäcka farlig aktivitet för applikationen den skyddar men hot som inte har applikationen som mål kan gå igenom utan varning [35].

2.3 Raspbian Buster Lite

Raspbian Buster Lite är ett operativsystem av Rasbian lite-sortimentet som släpptes 7 juli 2019 men som uppdateras kontinuerligt. Lite-versionen innebär ett operativt system utan grafiskt användargränssnitt som bara använder ett kommandofönster för att ta emot kommando från ett tangentbord. Ingen mus behövs. Enligt en studie som undersökte möjligheten att använda ett IDS på mikrodatorer med en cloud server och två hemnätverk menar att Buster Lite version är mindre resurskrävande samt kan

hjälpa med att hindra kompatibilitetsproblem med Snort [16]. Detta kan vara en fördel för studiens resultat.

2.4 Raspberry Pi

Raspberry Pi är en liten enkortsdator som kan användas som en stationär dator och programmera elektroniska komponenter [36].

2.4.1 Rasberry Pi 2 modell B

Raspberry Pi 2 B v.1.1 använder ett Broadcom BCM2836 ARM-Chip. Det finns två versioner av Rasberry Pi 2 modell B, skillnaden är processorn som hårdvaran använder. Version 1.1 använder Cortex-A7 och är relevant för studien. Version 1.2 använder samma processor som Raspberry Pi 3 modell B+ [37].

2.4.2 Raspberry Pi 3 B+

Raspberry Pi 3 modell B+ är efterföljaren till Raspberry Pi 3 modell B+ samt sista versionen i Raspberry Pi 3-sortimentet. Liksom version 1.2 av Raspberry Pi 3 modell B+ använder den Broadcom BCM2837B0 ARM-Chip [38].

2.4.3 Raspberry Pi specifikationer

Figur 5 visar hårdvaruspecifikationer på studiens Raspberry Pi modeller.

2.5 Snort

Snort är en IDS/IPS med öppen källkod. Den är kapabel till att utföra trafikanalys och loggning av IP-nätverk i realtid. Snort kan upptäcka flera olika typer av attacker och försök till intrång som till exempel Common Gateway Interface (CGI)-attacker. Det finns tre primära användningsområden för Snort nämligen som paketanalysator (IDS), paketloggning (IDS) eller som ett intrångsskyddssystem (IPS). Med hjälp av dessa kan Snort upptäcka och förhindra attacker på nätverk [39].

2.5.1 Regler och lägen

En regel för Snort säger till system hur den ska uppföra sig vid ett intrångsförsök. Snort IPS som I/O-bunden måste använda regler, utan regler kommer nätverkstrafik att flöda igenom utan analysering. Vid utförande av experimentet används en regel för UDP-protokoll för jämförelse av CPU-bindning och I/O-bindning.

En regel kan skrivas med sex olika syntaxer nämligen alert, log, pass, drop, reject och sdrop. I regeln väljs också vilket protokoll som ska kontrolleras och Snort kan

analysera fyra nämligen TCP, UDP, ICMP och IP [40].

Snort har olika lägen, inline och offline, där den kan bete sig annorlunda beroende på vilket läge den befinner sig i. I offline-läge är Snort ett detekteringssystem som bara kan varna för intrångsförsök/attacker. I inline-läge har den möjligheten att köra som IPS, i detta läge har Snort möjlighet att stoppa attacker samt varna användaren.

Snort kan köras i daemon-läge vilket innebär att Snort är aktiverad i bakgrunden.I detta läge är den och skannar nätverkstrafik samtidigt som användaren kan arbeta med andra program.

2.6 Wireshark

Wireshark är en nätverksprotokollanalysator som tidigare hette Ethereal. Den har möjlighet att låta användaren fånga och bläddra igenom trafiken som existerar i datornätverket i realtid. Den har en öppen källkod, vilket har gjort den till ett av de mest använda programmen för allt från säkerhetsexperter till studenter. Wireshark finns till de flesta operativsystem som används idag. Den är utvecklad och underhålls av ett globalt team som består av protokollexperter [41].

2.7 SAR

SAR är en mjukvara som används för att samla och spara systemaktivitet som bland annat CPU-aktiviteter, minnesaktivitet, avbrott, enheter som belastar och information angående nätverket [42].

2.8 Iperf3

Iperf3 är ett mjukvaruverktygsom används för att undersöka hastigheten hos ett visst nätverk. Det görs genom att verktyget i standardläge skickar Internet protokoll från server till client under några sekunder eller valfri tid och sedan beräknar ett

3 Metod och genomförande

3.1 Inledning

Experimentmetoden användes under studien med hjälp av litteratursökning. För utförandet av experimentet på processorerna används Raspbian Buster Lite operativsystem på båda Raspberry Pi-modellerna. Experimentet består av 4 olika tester som utfördes 5 gånger var för att förstärka reliabiliteten. Utöver dessa har tester gjorts för att kontrollera hastigheten igenom fysiska nätverkstopologin och för att säkerställa att det är Snort som är aktiv när trafiken börjar flöda igenom topologin. Experimentet förklaras mer utförligt senare i detta kapitel.

3.2 Koppling mellan frågeställningar och metod

För att besvara frågeställningarna har litteratursökningar gjorts för att kunna bygga miljön där experimentet ska utföras och för att få en bättre inblick och förståelse för hur verktygen och systemen fungerar optimalt, se figuren nedan.

3.2.1 Litteratursökning

I studien har litteratursökning använts som hjälpmedel för att kunna ta fram experimentmiljön. Tidigare forskning som har använt Snort med Raspberry Pi har varit till hjälp för att bygga en egen miljö [5]. Alla program som har använts har undersökts teoretiskt för att fastställa den korrekta användningen för experimentet. Då några av dessa program har flera användningar har de begränsats till vad som är nödvändigt för att besvara frågeställningar, exempelvis Wireshark som kan göra mer än vad den har använts till i denna studie. En litteratursökning har skett genom att söka information om hur Snort fungerar samt vad det innebär att den är I/O och CPU-bunden [40]. Till skillnad från en litteraturstudie har inte de flesta artiklarna granskats med syfte att svara på frågeställningarna utan har använts som hjälpmedel för att kunna utföra de för studiens nödvändiga tester.

3.2.2 Experiment

Ett experiment är en undersökningsmetod som har i syfte att testa studiens hypotes. Till skillnad från andra metoder krävs det att utförandet görs aktivt, det vill säga att personerna som utför det måste vara engagerade under experimentets gång. Inom metoden finns det olika sätt att samla in data men för att svara på frågeställningarna måste testerna ge utdata i form av siffror som senare statistiskt kan analyseras, därför har kvantitativ metod använts. Experimentet ska kunna ge trovärdiga utdata om den är upprepningsbart. Att den är upprepningsbart gör att vissa anomalier som dyker upp kan bli möjliga att identifiera [44].

I denna studie har experimenten utförts genom att skicka nätverkstrafik via Iperf3 till Raspberry Pi 2 modell B och Raspberry Pi 3 modell B+ där Cortex-A7 respektive Cortex-A53 finns. SAR har sedan använts för att mäta och spara processorernas aktivitet i realtid.

3. 3 Ansats

Metoden går ut på att samla in empiriska data för att senare kunna analysera dem samt presentera pålitliga resultat. Insamling av empiriska data genomförs genom att utföra experiment och observera utgående data [44]. Då experimentet görs flera gånger används kvantitativ forskning. Med en kvantitativ metod ska det ge en god översikt och analys av de data som är insamlade.

3.4 Arbetsprocess

Figur 8 visar arbetsprocessen. Under studien har sökning av relevant litteratur gjorts för att bygga miljön till experimentet. För en ökad reliabilitet repeterades

experimentet om efter att resultatet analyserat.

3.5 Experimentdesign

3.5.1 Mjukvara

I denna sektion beskrivs mjukvaran och de nödvändiga kommandon som har använts.

3.5.1.1 Iperf3

Iperf3 har använts för att kontrollera trafikhastigheten igenom topologin och för att skicka nätverkstrafik när experimenten ska utföras. Nätverksprotokollet är TCP som är standardprotokoll för Iperf3. Kommandot nedan har satt UDP till det protokoll som ska skickas som nätverkstrafik. Eftersom TCP försenar sändning när nätverket blir överbelastat samt har en långsam hastighet på Iperf3 blev valet UDP, som är snabb och ej anslutningsbaserad vilket gör att ett program som Iperf3 kan skicka många packet till ett annat program, som till exempel SAR.

Detta har skett genom att en dator blir server och tar emot all nätverkstrafikfrån client för att testa hur snabb hastigheten (bandwidth) är.

Följande Iperf3 kommandon har använts: - Server

Iperf3 -s

- Client

Iperf3 -c 192.168.2.4 -u -b 1G -t 300

3.5.1.2 Wireshark

Wiresharks användninghar varit för att bekräfta att trafiken som skickas når måldatorn samt att det är rätt nätverksprotokoll som har ankommit.

3.5.1.3 Snort

Snort har i experimenten använts i inline-läge och körts i daemon-läge. Detta innebär att i inline-läge körs den som en IPS och att den i daemon-läge arbetar i bakgrunden. Det utförda experimentet innebär att undersöka processorernas aktivitet under skickad trafik. För att jämföra CPU-bindning med I/O-bindning valdes även att aktivera en regel hos Snort, vilket gör hela processen I/O-bunden.

Så här kan regler för Snort när den är I/O-bunden se ut:

- alert tcp 192.168.1.X any -> !HOME_NET any (msg:”TCP”; sid:123456;) - alert udp 192.168.1.X any -> !HOME_NET any (msg:”UDP”; sid:123456;)

Där HOME_NET är satt till den IP-adress som ska skyddas av Snort och anledningen till att IP-källan inte är any är för att säkerställa att trafiken som skickas till slutmålet är från den avsedda källan.

Kommandot som används för att köra Snort IPS i daemon-läge på Raspberry Pi som använder operativsystemet Rasbian Buster Lite ser ut på följande sätt:

- Pi-3# sudo snort -A console -c /etc/snort/snort.conf -Q -i eth0:eth1 -D

För att bland annat aktivera Snort i bakgrunden har följande kommandon använts: - Aktivera

Pi-3# sudo systemctl start snort

- Avaktivera

Pi-3# sudo systemctl stop snort

- Status

Pi-3# sudo systemctl status snort

När trafiken skickas färdigt genererar Snort en logg-fil. I loggfilen finns det information för nätverkstrafik som har kontrollerats av de satta reglerna. Detta har

använts i syfte att bekräfta att Snort är I/O-bunden. Ifall en logg-fil genereras när ett test för CPU-bindning körs innebär det att regler är aktiva och måste avaktiveras.

För att öppna en logg-fil behövs ett speciellt kommando där x:en står för en tidsstämpel:

- Pi-3# sudo snort -r /var/log/snort/snort.log.xxxxxxxxx

3.5.1.4 SAR

SAR har använts för att mäta CPU-användning i realtid. Den har möjligheten att spara en fil för mätningarna som SAR har utfört. SAR användes för att kontrollera och mäta CPU-användningen i procentuell form.

Följande kommando är ett exempel: - Pi-3# sar -u 1 10 -o filnamn

Ovanstående kommando säger att SAR ska kontrollera CPU-användningen med -u. 1 säger att SAR skall uppdatera visningen av CPU-aktiviteten varje sekund. 10 säger att hela processen skall köras i totalt 10 sekunder. -o filnamn säger att hela processen skall spara i filen filnamn.

Dessa mjukvaruversioner var aktuella för den använda hårdvaran. Värt att notera är att nyare versioner kan ha kommit under studiens gång men ovanstående har behållits.

3.5.2 Hårdvara

Följande hårdvaror har använts för experimentet.

Utöver dessa har även två USB-Ethernet adapters använts till följande: • Koppla laptop till Raspberry Pi

• Koppla Raspberry Pi (Snort) med dator och agera som en brygga. 3.5.3 Fysisk nätverkstopologi

Miljön för experimentet har sett ut på följande sätt, en ROG G501VW laptop som kör på operativsystem Windows 10. Trafiken skickades sedan till en måldator med hjälp av Iperf3. Trafiken skickades igenom Raspberry Pi för att nå måldatorn.

Raspberry Pi med Snort i Inline-läge. All trafik går igenom Snort.

Client

Figur 11: Fysisk nätverkstopologi

Server Figur 10: Beskrivning av hårdvara

Hastigheten igenom topologin: Raspberry Pi 2 modell B:

Raspberry Pi 3 modell B+:

Figur 12 och figur 13 visar att Raspberry Pi 3 modell B+ kan skicka nätverkstrafik i högre hastighet än Raspberry Pi 2 modell B. För att båda processorerna ska bli

undersökta inom samma omständigheter har vi begränsat hastigheten för Raspberry Pi 3 till 100 mb/s vilket ger en medelhastighet på 95 mb/s via Iperf3.

Figur 12. Standard ethernet-hastighet

3.6 Experimentet

Experimentet utgörs av 4 tester som ska upprepas 5 gånger var. Totalt blir det 20 tester för båda processorerna. Varje gång Snort är aktiverad under dessa tester har inga regler varit aktiva. All CPU-aktivitet har sedan dokumenterats i realtid med hjälp av SAR.

De två första testerna syftar till att kontrollera CPU-aktiviteten när Snort är avaktiverad samt Snort är aktiverad utan att nätverkstrafik skickas, enligt följande steg:

• Snort är AVAKTIVERAD. Raspberry Pi arbetar utan inkommande nätverkstrafik eller aktivitet utöver systemprogram.

• Snort är AKTIVERAD. Raspberry Pi arbetar med Snort utan inkommande nätverkstrafik eller aktivitet utöver systemprogram.

Ovanstående skall testas under 5 minuter (300 sekunder) per gång och 5 gånger vardera för både Cortex-A53 och Cortex-A7. Utifrån observationer när nätverkstrafik skickas med Snort aktiverad har CPU-användningen varit konstant, därför

begränsades tiden till 5 minuter. Längre tester skulle inte ge bättre resultat. Att utföra testerna 5 gånger tycktes ge tillräckligt med data för granskning av

standardavvikelsen.

Resterande två tester ska jämföra när Snort är avaktiverad och nätverkstrafik skickas igenom via Iperf3. Samma trafik ska skickas igen, dock när Snort är aktiverad i bakgrunden. Följande steg har följts:

• Snort är AVAKTIVERAD och trafik skickas från laptop till dator genom Iperf3.

• Snort är AKTIVERAD och trafik skickas från laptop till dator genom Iperf3. När trafiken skickas med Snort aktiverad har vi satt en 30 sekunders buffert i början samt när trafiken skickas klart. Tiden blir då 6 minuter (360 sekunder) för just detta test. Detta för att se när CPU-användningen börjar bli påverkad och när trafiken har bearbetats klart. Följande steg har följts:

• Kontrollera att Snort är aktiverad.

• Starta SAR och dokumentera CPU-användning.

• Skicka trafik efter att 30 sekunder har passerats (buffert).

Utöver dessa 4 tester har ytterligare ett test utförts, för att säkerställa att det sista ovannämnda test inte är I/O-bunden och därmed har utförts med en regel aktiverad medan trafik skickas med Iperf3.

3.7 Dataanalys

Insamling av data har gjorts i realtid med SAR. SAR har sedan sparat all data från testerna som därefter överförts till Excel. I Excel har data lästs in från de olika testerna för båda Cortex-A7 och Cortex-A53. Eftersom SAR dokumenterar CPU-användningen nedåtgående från 100% har datainsamlingen i Excel omformulerats till att få en stigande graf som visar den CPU-procentandel som är under användning av systemet. Med hjälp av Excel har det även gjorts jämförelser i form av grafer och stapeldiagram mellan de olika testerna, vilket redovisas i analyskapitlet (kapitel 6).

3.8 Trovärdighet

3.8.1 Litteratursökning

Sökningen som har gjorts har varit begränsad till rapporter, studier och manualer för system. Med hjälp av manualer har användningen av systemen och felsökning förbättrats. För att öka trovärdigheten har endast studier som genomgått peer review använts. Sökmotorer som har använts för att hitta studierna är Diva, Google Scholar och Primo. För att säkerställa att studierna genomgått peer review har publikationerna granskats.

3.8.2 Experiment

För att säkerställa att nätverstrafiken kommer från laptoppen har det använts statiska IP-adresser och med hjälp av Wireshark kunnat bekräfta att nätverkstrafiken har tagits emot av måldatorn. Trafikhastigheten har även testats igenom topologin, vilket har lett fram till en experimentmiljö som är rättvis för både Cortex-A7 och Cortex-A53.

Med hjälp av inbyggda program i Buster Lite OS som HTOP och TOP har det kunnat säkerställas att när Snort är avaktiverad syns den inte på de aktiva processorfälten i programmen och när den aktiveras syns den. Samt att när trafiken börjar skickas har det med hjälp av HTOP och TOP bekräftats att det är just Snort som börjar uppta mer processoraktivitet.

4 Teoretiskt ramverk

Snort kan klassificeras som en CPU-bunden applikation vars körningstid begränsas av CPU:s hastighet, vilket betyder att Snort är ”bottlenecked” av den processor som används i hårdvaran. Men den kan även klassificeras som en I/O-bunden applikation. En I/O-bunden applikation är en applikation vars körningstid begränsas av I/O (Input / Output), och som kan klassificeras som I/O-bunden genom hela exekveringen av applikationen eller bara i en viss period. Snort börjar klassificeras som I/O-bunden när Snort använder regler som börjar känna av skadlig trafik, då läggs mycket tyngd på alert- och eventinspelningar (Snorts logg-fil). I hårdvaror såsom en PC skulle det framförallt handla om exempelvis disk och databasoperationer [45].

Nätverkstrafiken som används i denna studie är UDP-protokoll och är inte skadlig eller regelstyrd vilket gör att Snort blir CPU-bunden genom hela sin körningstid vilket gör att även frågeställningen ”Hur mycket skiljer sig Snorts bearbetningstid mellan Cortex-A53 och Cortex-A7 när nätverkstrafik skickas?” blir CPU-baserad.

Studien av Khan, Minallah och Said (2018) menar att Cortex-A53 har bättre prestanda på grund av att det är en 64-bit processor med låg effekt. ARMv8-A är arkitekturen som finns i Cortex-A53, den ger processorn nya funktioner såsom en 64-bit register, 64-bit databearbetning och en utökad virtuell adressering. Cortex-A53 är den första processorn som använder ARMv8-A, utöver de nämnda nya funktionerna har den även förbättrad integer-, NEON- och Floating-Point Unit-prestanda [46].

Genom att undersöka CPU-användningen besvaras frågeställningen ”Hur mycket CPU använder Snort när den bearbetar nätverkstrafiken som skickas på Cortex-A7 till skillnad från Cortex-A53?” därmed ser man om Snort får någon fördel av den utökade prestandan på Cortex-A53.

Ovannämnda studien påvisade att testerna som de utförde på körningstiden för bildkompressionen (JPEG algoritmen) i Cortex-A53 var snabbare än Cortex-A7 [12]. De visade att körningstiden är beroende av upplösningen på bilderna som

komprimerades. Detta innebär att ju mer detaljerade bilderna är desto längre

körningstid bildkompressionen får. Då ökas CPU-användningen på grund av bildens resolution.

En 32-bits processor använder ett 32-bits register som kan lagrar 232 bytes medan en 64-bits processor använder ett 64-bit register som kan lagra 264 bytes. Detta betyder att en 64-bits processor kan lagra cirka 4,3 miljarder gånger fler bytes. CPU:s register lagrar minnesadresser vilket är så en processor får tillgång till data från RAM. Denna information berättar att en 32-bits processor kan maximalt erhålla 4 GB RAM medan en 64-bits processor kan erhålla över 4 GB RAM [47]. Skulle man använda 16 GB RAM med en 32-bits processor blir cirka 12 GB RAM oåtkomlig av processorn.

SPECint-2000 används för att testa integer prestanda hos CPU, minnes arkitektur och kompilatorer [48]. Integer prestandan utförs genom att låta ett system utföra integer operationer. Dessa operationer kan till exempel vara värdetestning såsom att

undersöka om A = B och C [49]. Integer operationer är allmänt snabba jämfört med till exempel Floating-point operationer som är långsammare [50].

5 Empiri

Empirin har gått ut på att procentuellt mäta hur mycket CPU Snort använder samt Snorts bearbetningstid när trafik skickas via Iperf3. För att säkerställa att mätningarna som har gjorts gäller när Snort är CPU-bunden har även mätningar för I/O-bundenhet utförts, och på så vis presenteras olikheterna mellan dessa två. Datainsamlingen har utförts med verktyget SAR där samtliga tester har utförts 5 gånger var. Ett test motsvarar mätningen av CPU-aktivitet i realtid. SAR uppdaterar och visar CPU:s aktivitet efter varje sekund, därför har medelvärdet för varje sekund hos de samtliga testerna räknats fram. Detta gjordes efter att testerna har upprepats 5 gånger.

5.1 Experimentet

Nedan visas grafer och stapeldiagram för de experiment som har utförts. För att få en mer detaljerad graf har skalan på Y-axeln hos graferna och stapeldiagrammen

minskats.

Dataetiketterna på stapeldiagrammen är avrundade till två decimaler. Diagram axlarna tolkas som följande:

• X-axeln: Tid i sekunder

5.1.1 Snort avaktiverad och Snort i idle-läge

Här visas CPU-aktiviteten för när Snort inte är aktiverad på varken Cortex-A7 eller Cortex-A53. 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort avaktiverad| Cortex-A7

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort avaktiverad | Cortex-A53

Figur 14. När Snort är avaktiverad på Cortex-A7

Här visas grafer av CPU-aktiviteten för när Snort är i idle-läge på både Cortex-A7 och Cortex-A53. 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort IDLE | Cortex-A7

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort IDLE | Cortex-A53

Figur 16. När Snort är idle för Cortex-A7

5.1.2 Snort aktiv/av med Iperf-trafik

Nedan visas grafer för när Snort är påslagen samtidigt som nätverkstrafik från Iperf3 skickas igenom topologin. Efter att ha observerat när Snort blir klar med sin

bearbetning av nätverkstrafik som skickas i 300 sekunder på både Cortex-A7 och Cortex-A53 har tidsintervallet ökat till 360 sekunder. Detta dels för att visa CPU-aktiviteten på den tidpunkten då trafiken skickas och även ge Snort den tid den behöver för att bearbeta klart trafiken.

0 5 10 15 20 25 30 35 40 45 50 1 _{14 27 40 53 66 79 92} 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 300 313 326 339 352

Snort aktiv med Iperf-trafik | Cortex-A7

0 5 10 15 20 25 30 35 40 45 50 1 _{14 27 40 53 66 79 92} 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 300 313 326 339 352

Snort aktiv med Iperf-trafik | Cortex-A53

Figur 18. Nätverkstrafik skickas på Cortex-A7

Nedan visas grafer för när Snort är av medan Iperf-trafik skickas i 300 sekunder. Detta testas för att undersöka om Cortex-A7 och Cortex-A53 reagerar på inkommande trafik utan ett IDS/IPS.

0 5 10 15 20 25 30 35 40 45 50 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort avaktiverad med Iperf-trafik | Cortex-A7

0 5 10 15 20 25 30 35 40 45 50 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Snort avaktiverad med Iperf-trafik | Cortex-A53

Figur 20. Snort avaktiverad och nätverkstrafik skickas på Cortex-A7

5.1.3 Snort I/O-bunden

Nedan visas grafer för I/O-bindning när Snort är aktiv medan Iperf-nätverkstrafik skickas igenom topologin. Då Iperf-nätverkstrafiken som skickas är UDP-protokoll har en alert regel för UDP skrivits och aktiverats, detta gör att Snort börjar logga den trafik den får in, vilket gör hela processen I/O-bunden.

0 10 20 30 40 50 60 70 80 90 100 1 _{14 27 40 53 66 79 92} 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 300 313 326 339 352

Aktiv UDP alert-regel hos Snort med Iperf-trafik |

Cortex-A7

Aktiv UDP alert-regel hos Snort med Iperf-trafik |

Cortex-A53

Figur 22. Snort på med regler, nätverkstrafik skickas på Cortex-A7

6 Analys

Analyskapitlet introducerar begreppet standardavvikelse som sedan blir ett hjälpmedel till att analysera studiens upprepade tester för god trovärdighet.

Kapitlet analyserar även insamlade data för att svara på studiens frågeställningar. Diagramaxlarna tolkas enligt följande:

• X-axeln: Tid i sekunder

• Y-axeln: Procentandelar för CPU-användningen Stapeldiagrammen tolkas enligt följande:

• Y-axeln: Procentandelar för den genomsnittliga CPU-användningen

6.1 Standardavvikelse på samtliga tester

Standardavvikelsen visar hur nära värdena i en insamlad datauppsättning är till medelvärdet. En låg standardavvikelse innebär att värdena i en datauppsättning ligger förhållandevis nära medelvärdet medan en hög standardavvikelse innebär att värdena är mer utspridda runt medelvärdet 𝒙̅ [51].

6.1.1 Cortex-A53 Test 1 2 3 4 5 𝒙 ̅ 0,65 0,69 0,66 0,67 0,71 𝝈 0,45 0,40 0,38 0,36 0,45 Test 1 2 3 4 5 𝒙̅ 0,67 0,74 0,65 0,63 0,72 𝝈 0,28 0,47 0,31 0,33 0,52 Test 1 2 3 4 5 𝒙 ̅ 1,58 1,91 1,78 1,72 1,90 𝝈 0,67 0,80 0,80 0,74 0,87

Tabell 1: Snort avaktiverad

Test 1 2 3 4 5 𝒙 ̅ 8,54 8,68 9,19 9,83 9,94 𝝈 3,59 3,64 3,72 3,92 3,95 Test 1 2 3 4 5 𝒙 ̅ 35,84 33,17 35,36 36,33 35,56 𝝈 17,86 19,94 17,65 17,41 17,98 6.1.2 Cortex-A7 Test 1 2 3 4 5 𝒙 ̅ 0,81 0,84 0,85 0,77 0,78 𝝈 0,35 0,47 0,39 0,34 0,28 Test 1 2 3 4 5 𝒙 ̅ 0,87 0,82 0,78 0,84 0,87 𝝈 0,37 0,25 0,25 0,38 0,29 Test 1 2 3 4 5 𝒙 ̅ 3,18 3,55 3,21 3,11 3,80 𝝈 1,21 1,29 1,33 1,41 1,19 Test 1 2 3 4 5 𝒙 ̅ 26,80 26,42 26,41 26,51 26,65 𝝈 9,80 9,72 9,70 9,53 9,76 Test 1 2 3 4 5 𝒙 ̅ 47,64 47,85 47,28 48,47 48,28 𝝈 18,68 16,47 18,44 15,59 17,31 6.1.3 Tolkning av testerna

Standardavvikelsen varierar för varje test men visar ingen drastisk avvikelse som gör testet opålitligt. Man kan argumentera för att vissa tester är bättre än andra på grund

Tabell 3: Iperf-trafik när Snort är avaktiverad

Tabell 4: Snort aktiv med Iperf-trafik

Tabell 5: När Snort är I/O-bunden

Tabell 6: Snort avaktiverad

Tabell 7: Snort i idle-läge

Tabell 8: Iperf-trafik när Snort är avaktiverad

Tabell 9: Snort aktiv med Iperf-rafik

av deras lägre standardavvikelse men det betyder inte att de andra testerna är defekta. Vanligen finns bakgrundsprocessorer som även i idle-läge kan skicka signaler till processorn, detta kan synas som plötsliga höga procentuella ökningar i CPU-användningen. Vilket i sin tur resulterar i stora skillnader i standardavvikelsen och medelvärdet.

6.2 AndraCPU-anmärkningar

Dessa tester utfördes för att visa hur mycket CPU Snort använder i Idle-läge.

Figur 24 och figur 25 visar ingen större inbördes skillnad. Detta visar att Snort i idle-läge inte använder en hög procentuell andel av processorns kapacitet. Man kan tolka detta som att Snort i idle-läge existerar som en backgrundsprocessor där den enbart börjar arbeta när den behöver.

0,84 0,68 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 A7 A53

Snort avaktiverad

Snort IDLE

Figur 26 och 27 visar jämförelser mellan figur 14 och 20 respektive figur 15 och 21. Dessa jämförelser gjordes för att redogöra för att Ethernet-interface påverkar

processorn även utan ett IDS/IPS. Graferna visar en skillnad i CPU-användningen men den skillnaden är mindre hos Cortex-A53. Den genomsnittliga

CPU-användningen på ”Snort av med trafik” på Cortex-A7 och Cortex-A53 är cirka 3,37%

0 5 10 15 20 25 30 35 40 45 50 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Cortex-A7

Snort av utan trafik Snort av med trafik

0 5 10 15 20 25 30 35 40 45 50 1 _{12 23 34 45 56 67 78 89} 100 111 122 133 144 155 166 177 188 199 210 221 232 243 254 265 276 287 298

Cortex-A53

Snort av utan trafik Snort av med trafik

Figur 26. Jämförelse mellan med trafik och utan trafik på Cortex-A7.

respektive 1,77%. Vilket visar en skillnad på cirka 2,53% på Cortex-A7 och 1,09% på Cortex-A53.

6.3 Frågeställning 1

För att kunna besvara frågeställningen ”Hur mycket skiljer sig Snorts bearbetningstid mellan Cortex-A53 och Cortex-A7 när nätverkstrafik skickas?” presenteras följande graf.

Nätverkstrafiken började skickas 30 sekunder efter att Snort aktiverats i idle-läge och slutade skickas efter 300 sekunder och detta ser man tydligt på grafen.

CPU-användningen är konsekvent fram till att trafiken har skickats klart vilket är efter totalt 330 sekunder, sedan uppför sig Snort annorlunda på båda processorerna, detta kan vara på grund av arkitekturskillnaden. Hur Snort väljer att uppföra sig efter att trafiken har skickats är oklart men grafen visar en ökning i CPU-användning hos Cortex-A53 efter 330 sekunder, detta kan betyda att Snort behöver använda mer CPU för att bearbeta klart den sista biten av trafik till skillnad ifrån Cortex-A7 som behöver mindre CPU men mer tid att bearbeta klart det sista av trafiken.

0 5 10 15 20 25 30 35 40 45 50 1 _{14 27 40 53 66 79 92} 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 300 313 326 339 352

Snort aktiv med Iperf-trafik

A7 A53

Skillnaden i bearbetningstid är tydlig i grafen, där visar den att bearbetningstiden hos Cortex-A53 är 10 sekunder kortare än hos Cortex-A7.

Efter att trafiken har bearbetats klart borde CPU-aktiviteten se ut som i figur 16 och 17.

6.4 Frågeställning 2

För att kunna besvara frågeställningen ”Hur mycket CPU använder Snort när den bearbetar nätverkstrafiken som skickas på Cortex-A7 till skillnad från Cortex-A53?” presenteras följande stapeldiagram.

Stapeldiagrammet visar den genomsnittliga CPU-användningen när Iperf3 UDP-trafik skickas medan Snort är aktiv, från figur 28. Resultatet visar att Cortex-A7 använder cirka 2,87 gånger mer CPU jämfört med Cortex-A53.

26,56 9,24 0 5 10 15 20 25 30 A7 A53

Snort med Iperf-trafik

6.5 Snort I/O-bunden

Figur 30 visar när Snort är I/O-bunden, i detta fall har Snort börjat logga och alerta trafiken den får in på grund av att regel för UDP-trafikprotokoll är aktiverad, då påverkar bland annat minnet CPU-aktiviteten, vilket resulterar i en större ökning i CPU-användning jämfört med när Snort är CPU-bunden.

CPU-aktiviteten på Cortex-A53 är mindre stabil jämfört med Cortex-A7. Man ser tydligt att CPU-aktiviteten hos Cortex-A53 ibland korsars med Cortex-A7.

På samma sätt som testerna för när Snort är CPU-bunden skickas nätverkstrafiken efter 30 sekunder och skickas klart efter 300 sekunder. På grafen ser man tydligt att Snort behöver mer tid för att bearbeta klart trafiken. Hela grafen skulle behöva ett större tidsintervall för att se när Cortex-A7 har bearbetat klart sin nätverkstrafik.

0 10 20 30 40 50 60 70 80 90 100 1 _{14 27 40 53 66 79 92} 105 118 131 144 157 170 183 196 209 222 235 248 261 274 287 300 313 326 339 352

Aktiv UDP alert-regel hos Snort med Iperf-trafik

A7 A53

7 Diskussion och slutsatser

7.1 Resultat

Ingen tydlig slutsats kan dras gällande skillnaderna i CPU-användning mellan när Snort är i idle-läge och när den är avaktiverad. Då Snort syns som bakgrundsprocessor så antas att Snort endast använder mer CPU när den börjar bearbeta nätverkstrafiken. Figur 28 som hjälper att besvara studiens första frågeställning visar att Cortex-A7 använder mer CPU än Cortex-A53. Som tidigare nämnts i studien, ju mer CPU Snort använder desto sämre presterar den, enligt Snorts utvecklare. Grafen visar att detta påstående från utvecklarna kan anpassas till bearbetningstiden då bearbetningstiden är 10 sekunder kortare på Cortex-A53. En hastighet på 95 mb/s innebär i detta fall att cirka 118 MB nätverkstrafik fortfarande bearbetas under dessa 10 sekunder.

En tydlig skillnad kan ses på CPU-användningen när Snort börjar bearbeta

nätverkstrafiken från Iperf3. Cortex-A53 fick ett medelvärde på 9,24% och Cortex-A7 på 26,56%. En ökning hos Cortex-A7 som är cirka 2,87 gånger större än Cortex-A53. Detta kan mycket väl ha att göra med ARMs utveckling av CPU-arkitektur på Cortex-A53 där ARMv8 stödjer både AArch7 och AArch8 samtidigt som den är en 64-bits processor.

Det är svårt att dra en slutsats kring varför kurvorna i figur 18 och 19 ser annorlunda ut mot slutet. När trafiken slutar skickas efter 330 sekunder och CPU-användningen börjar återgå till sitt föregående värde antas processorerna hanterar detta på olika sätt. ARMv7 för Cortex-A7 och ARMv8 för Cortex-A53 har samma

instruktionsuppsättningar. Däremot har ARMv8 andra nya instruktionsuppsättningar som bestämmer över hur en applikation styr CPU [23].

Studiens hypotes säger att bearbetningstiden hos Cortex-A53 kommer bli 1,4 gånger snabbare än hos Cortex-A7. Resultatet för frågeställning 1 visar att bearbetningstiden hos Cortex-A53 är 1,03 gånger snabbare än Cortex-A7. Resultatet motbevisar således studiens hypotes.

Körningstiden för komprimering av bilderna från studien av Khan, Minallah och Said (2018) är olika beroende på upplösning. Den närmaste körningstidskillnaden mellan Cortex-A7 och Cortex-A53 enligt studien, kan jämföras med denna studies

bearbetningstidsskillnad på 10 sekunder är när de komprimerade en bild med

1000x667 upplösning, vilket tog 19.18 sekunder på Cortex-A7 och 10,74 sekunder på Cortex-A53. Då visades en körningstidskillnad på 8,44 sekunder. Genom att reflektera kring resultaten kan man dra en slutsats att en bild med en upplösning på omkring 1000x667, ger Cortex-A7 och Cortex-A53 nästan samma tidsskillnad som Snorts bearbetningstidsskillnad. De testar två bilder med upplösningen 1000x667 och båda ger ungefär samma körningstidsskillnad. Dock i deras fall är körningstiden för komprimering av 1000x667 upplösning på Cortex-A53 1,78 gånger snabbare än Cortex-A7. Detta påvisar även att SPECint-2000 benchmark är enbart beroende av integer prestanda och kan inte användas till att jämföra andra applikationers prestanda på Cortex-A7 och Cortex-A53. För att körningstiden ska vara 1,4 gånger så snabb på Cortex-A53 måste körningstiden ligga runt cirka 15 sekunder på Cortex-A7, vilket innebär att körningstidsskillnaden enbart får vara cirka 4,29 sekunder. För att uppnå resultatet att Cortex-A53 är 1,4 gånger snabbare hos Snort IPS måste

bearbetningstiden vara 434 sekunder på Cortex-A7. Alltså måste Snorts bearbetningstidsskillnad på Cortex-A53 och Cortex-A7 vara 124 sekunder.

När Aspernäs och Simonsson (2015) undersökte CPU-användningen på Cortex-A7 för när Snort är avaktiverad och trafik skickas fick de ett CPU-värde på 25,88%, medan i denna studie låg genomsnittliga CPU-användningen på 3,37%. Detta kan betyda att Aspernäs och Simonsson hade bakgrundsprocessorer aktiva innan de påbörjade sina tester. Operativ systemet som de använde har ett GUI vilket kan vara resurshungrig och vara förklaringen till 25,88% CPU-användningen. Hastigheten för

nätverkstrafiken från Iperf3 var 94,02 Mbit/s på Raspberry Pi 2 modell B med Cortex-A7 enligt Aspernäs och Simonsson, medan i denna studie blev hastigheten 95 Mbit/s. Det är cirka 1 Mbit/s skillnad vilket inte borde vara en faktor till att

CPU-användningen ligger på 25,88% hos Aspernäs och Simonsson. I denna studie har det tagits hänsyn till att inga bakgrundsprocessorer är aktiva som kan störa eller förändrar resultatet på det utförda experimentet, vilket gör resultaten mer pålitliga. Med en CPU-användningen på 25,88% när Snort är avaktiverad ges längre bearbetningstid för Snort, därför är det viktigt med låg CPU-värde från början.

Testerna som utfördes för när Snort är I/O-bunden är endast till för att jämföras med när Snort är CPU-bunden samt för att kunna dra slutsatsen att Snort kommer larma och logga när den är I/O-bunden. På så vis påverkas hårdvarans minne för att spara alla loggar i filformat och detta lägger tyngd på processorn, därav den ökning i CPU-användning på 21,35% hos Cortex-A7 och 26% hos Cortex-A53 jämfört med när Snort är CPU-bunden. Man ser även att bearbetningstiden är över 23 sekunder längre hos Cortex-A7. Anledningen till att ökningen ligger på 26% hos Cortex-A53 är oklar. ARM-arkitekturen på Cortex-A53 kanske behandlar I/O-bindningen annorlunda jämfört med Cortex-A7 samt olika RAM på Raspberry Pi kan även vara en faktor.

Figur 26 och 27 visar en ökning av CPU-användningen hos processorerna när trafiken skickas med Snort avaktiverad. Studien utesluter inte den ökningen från slutsatsen av den statistiska analysen av erhållna data kring frågeställning 1 då Ethernet-interface är en naturlig del av ett IDS/IPS.

7.2 Implikationer

Denna studie skall ge kunskap om hur viktig kopplingen mellan Snort IPS och en processor är genom de tester som har utförts. Studiens resultat kan hjälpa Snorts användare att välja den processor där Snort fungerar bäst.

7.3 Begränsningar

Under examensarbetets gång har antalet forskningsstudier för Snort och Cortex-A53 samt Cortex-A7 varit begränsade. Forskningsstudierna skall hjälpa med att förstå kopplingen mellan Snort och ARM-processorer.

7.4 Slutsatser och rekommendationer

Även om resultatet i denna studie visar att bearbetningstiden uppvisar 10 sekunders skillnad mellan processorerna behöver Snort använda 2,87 gånger mer CPU hos Cortex-A7 för att kontrollera samma nätverkstrafik.Det kan tas för givet att valet av en processor för Snort inte spelar någon roll. Empirin motbevisar detta och visar en tydlig skillnad på CPU-användning och att en kapabel processor bör användas för att få det bästa ur Snort. Resultatet på experimentet visar tydligt att Cortex-A53 är det uppenbara valet för Snort IPS när det gäller snabbare bearbetningstid och lägre CPU-användning.

Vanligen kommer Snort vara I/O-bunden när man har bestämt sig för att använda Snort som ett IDS/IPS och denna studie visar att skillnaden mellan när Snort är CPU-bunden och I/O-CPU-bunden är stor, där I/O-bindning använder betydligt mer CPU vilket ger en bearbetningstidsskillnad på över 23 sekunder jämfört med CPU-bindning där skillnaden var 10 sekunder. En regel användes för I/O-bindning vilket gav den ökningen i CPU-användningen. Flera regler kommer resultera i en betydligt större ökning i CPU-användning. Därför är detta en ytterligare anledning till att använda en bra processor. I situationer där man vet att Snort kommer logga och larma mycket ska man använda en 64-bits processor för att 64-bits registret som finns i processorn ger hårdvaran tillgång till mer RAM-minne vilket är essentiellt för Snort när den är I/O-bunden.

Med begränsat antal regler kan det räcka för en hemanvändare att använda en processor som Cortex-A7 där trafiken som genereras av all nätverksaktivitet inte överstiger processorns gräns och därmed kan kontrollera trafiken. Skulle Snort användas av till exempel ett företag som genererar mycket trafik kan den börja jobba för mycket och använda mycket av processorn [52]. Därmed ökar användningen av CPU och Snort börjar att köras långsammare då de inte finns mer resurser från processorn och skadlig trafik kan då komma igenom.

7.5 Vidare forskning

Raspberry Pi och ARM-processorer är något som hela tiden uppgraderas och nya versioner lanseras. Därför kan denna studie göras om med nyare versioner av möjligen både Raspberry Pi och nyare ARM-processor.

En annan studie mätte CPU-användning när flera regeluppsättningar för Snort är igångdå TCP-trafik skickas igenom [5]. Man skulle kunna sätta ihop denna studie med deras och kontrollera bearbetningstiden.

Det går att utföra ett test där man har två clienter, där en av dem skickar skadlig nätverkstrafik och den andra vanlig nätverkstrafik till servern för att se hur Snort påverkar processorn. Detta kan göras på ARM-processor eller annan valfri processor.

Referenser

[1] Biljana L. Risteska Stojkoska & Kire V. Trivodaliev (2016). A review of Internet

of Things for smart home: Challenges and solutions. Faculty of Computer Science

and Engineering, University “Ss. Cyril and Methodius”, Skopje, Macedonia. [Online], Tillgänglig:https://www.sciencedirect.com/science/article/pii/S095965261631589X

[Hämtad: 16 December 2019]

[2] Asmaa S. Ashoor & Shared, Gore (2011). Importance of Intrusion Detection

System (IDS). International Journal of Scientific Engineering Research. [Online],

Tillgänglig:

https://pdfs.semanticscholar.org/2a84/3c5894f2ef76c1d1b5d9829c0cc88852b4e5.pdf

[Hämtad: 20 juni 2020]

[3] Robichaux P. Noticing and responding to network-borne attacks. Microsoft. [Online], Tillgänglig:

https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc723457(v=technet.10)?redirectedfrom=MSDN [Hämtad: 16 december 2019] [4] Ar K. K., Tuzhu C. & Justin, J. (2015). Pi-IDS: Evaluation of Open-Source

Intrusion Detection Systems on Raspberry Pi 2. Institute of Electrical and Electronics

Engineers. [Online], Tillgänglig:

https://ieeexplore-ieee-org.proxy.library.ju.se/stamp/stamp.jsp?tp=&arnumber=7435523 [Hämtad: 20 juni 2020] [5] Simonsson, T. & Aspernäs, A. 2015. IDS on Raspberry Pi: A Performance

Evaluation. Linnaeus University, Faculty of Technology, Department of Computer

Science. Växjö. [Online], Tillgänglig:

http://www.diva-portal.org/smash/record.jsf?dswid=5047&pid=diva2%3A819555&c=4&searchType=SIMPLE &language=en&query=aspern%C3%A4s&af=%5B%5D&aq=%5B%5B%5D%5D&aq2=%5B%5 B%5D%5D&aqe=%5B%5D&noOfRows=50&sortOrder=author_sort_asc&sortOrder2=title_s ort_asc&onlyFullText=false&sf=all. [Hämtad: 16 december 2019]

[6] Martindale, J. (2020, 16 april). 32-bit vs. 64-bit: Understanding what these options

really mean. digitaltrends. [Online], Tillgänglig:

0once.&text=Here%27s%20the%20key%20difference%3A%2032,capable%20of%20utilizing %20much%20more.. [Hämtad: 4 juli 2020]

[7] Cellan-Jones, R. (2011). A 15 pound computer to inspire young programmers. BBC [Online], Tillgänglig:

https://www.bbc.co.uk/blogs/thereporters/rorycellanjones/2011/05/a_15_computer_to_ins pire_young.html. [Hämtad: 11 november 2019]

[8] Paquet, C. (2009). Network Security Using Cisco IOS IPS. Cisco Press. [Online], Tillgänglig: https://www.ciscopress.com/articles/article.asp?p=1336425 [Hämtad: 25 april 2020]

[9] Salah, K, & Kahtani, A. (2010). Performance evaluation comparison of Snort

NIDS under Linux and Windows Server. Journal of Network and Computer

Applications. [Online], Tillgänglig:

https://www.sciencedirect.com/science/article/pii/S1084804509001040 [Hämtad: 23 april 2020]

[10] Beale, J. (2004). Snort 2.1 Intrusion Detection, Second Edition. Syngress Media, Inc. [Hämtad: 10 januari 2020]

[11] Easey, C. Definition of CPU Usage. [Online], Tillgänglig:

https://itstillworks.com/definition-cpu-usage-5076431.html [Hämtad: 20 januari 2020] [12] Khan, W., Said, N., Minallah, N. (2018). Benchmarking 4x ARM Cortex-A7 CPU

and 4x ARM Cortex-A53 for Multimedia Systems using JPEG Compression. 2018

International Conference on Computing, Mathematics and Engineering Technologies – ICoMET 2018. [Online], Tillgänglig:

https://www.researchgate.net/publication/324785627_Benchmarking_4x_ARM_Corte

x-A7_CPU_and_4x_ARM_Cortex-A53_for_multimedia_systems_using_JPEG_compression [Hämtad: 24 april 2020] [13] Shimpi, L, A. (2013). Answered by the Experts: ARM’S Cortex A53 Lead

Architect, Peter Greenhalgh. Anandtech. [Online], Tillgänlig: