Akademin f¨
or Innovation Design och Teknik
V¨
aster˚
as, Sverige
Examensarbete f¨
or h¨
ogskoleingenj¨
orsexamen i n¨
atverksteknik 15hp
˚
ATG ¨
ARDER F ¨
OR ATT MOTVERKA
S ¨
AKERHETSBRISTER I
KATALOGTJ ¨
ANSTER
Johan Hanna
Jha14001@student.mdh.seExaminator: Mats Bj¨
orkman
M¨alardalen H¨ogskola, V¨aster˚as, Sverige
Handledare: Sara Lundahl
M¨alardalen H¨ogskola, V¨aster˚as, Sverige
Helena Innerg˚
ard
Engvall Security AB, V¨aster˚as, Sverige
Ort: V¨
aster˚
as
Sammanfattning
Katalogtj¨anster ¨ar och f¨orblir en central och kritisk del i informationssystem. I katalog-tj¨ansterna samlas stora m¨angder information om anv¨andare och beh¨origheter f¨or respek-tive anv¨andare. I h¨ogriskmilj¨oer, d¨ar bland annat hemlig och annan skyddsv¨ard informa-tion samlas, ¨ar katalogtj¨ansterna i en utsatt situation. Om en katalogtj¨anst svarar fel p˚a en resursf¨orfr˚agan kan konsekvenserna vara stora. Arbetet grundade sig i att med hj¨alp av olika s¨akerhetsh¨ojande ˚atg¨arder bygga upp ett mer robust system f¨or att skydda ka-talogtj¨ansten mot att beh¨orighetsprinciperna bryts och ger obeh¨orig personal eller andra akt¨orer tillg˚ang till skyddsv¨arda resurser. Arbetet syftade till att ¨oka medvetenheten kring de hypotetiska s˚arbarheterna som finns i en katalogtj¨anst och baserat p˚a detta resulte-ra i hur de potentiella s˚arbarheterna i ˚atkomstprinciperna kan motverkas eller mildras. F¨or att uppn˚a detta resonerades det fram tv˚a testfall varav ett teoretiskt. Dessa byggde p˚a att ett Intrusion Prevention System (IPS) implementerades i ett av testfallen och en brandv¨agg i det andra teoretiska fallet. B˚ada ˚atg¨arderna implementerades i trafikfl¨odets riktning i respektive n¨atverkssegment f¨or att kontrollera anv¨andarnas beh¨origheter i real-tid. Testfallen byggdes upp simulerat med hj¨alp av bland annat GNS3 och Virtualbox. Det experiment som uppr¨attades med IPS:en som huvudkomponent gav ett positivt utfall d¨ar enheten med hj¨alp av en upps¨attning regler kunde utl¨asa specifika trafikfl¨oden till resurser som den avsedda anv¨andaren inte hade tillg˚ang till och baserat p˚a detta utf¨ora olika ty-per av ˚atg¨arder. Experimentet med brandv¨aggen gav d¨aremot inte ¨onskat resultat, detta berodde p˚a att det inte fanns st¨od f¨or den efters¨okta funktionaliteten i de brandv¨aggar med ¨oppen k¨allkod som unders¨oktes f¨or implementationen. Det resultat som genererades med hj¨alp av IPS:ens f¨orm˚aga att analysera trafik i realtid och baserat p˚a detta utf¨ora f¨ordefinierade ˚atg¨arder betyder att det effektivt kan byggas upp ytterligare en barri¨ar av skydd ut¨over katalogtj¨anstens egna s¨akerhet. Vidare medf¨or detta ¨aven att om en IPS implementeras kr¨avs det att tv˚a av varandra oberoende s¨akerhets˚atg¨arder fallerar innan ett felsvar realiseras vilket ¨ar att anv¨andaren f˚ar tillg˚ang till resursen.
1 Inledning . . . 1
2 Bakgrund . . . 2
2.1 Katalogtj¨anster . . . 2
2.2 Windows Server . . . 2
2.2.1 Remote Authentication Dial-In Services . . . 3
2.2.2 Active Directory . . . 4 2.3 Hot . . . 5 2.4 S˚arbarheter . . . 5 2.5 Attackvektorer . . . 5 2.6 Virtualisering . . . 6 2.6.1 Virtualbox . . . 7
2.6.2 Graphical Network Simulator 3 . . . 7
2.7 Kontroll av paketfl¨ode . . . 7
2.8 Intrusion Prevention System . . . 8
2.8.1 Signature-based . . . 8 2.8.2 Anomaly-based . . . 8 2.8.3 Policy-based . . . 8 2.8.4 Atomic Signature . . . 8 2.8.5 Stateful Signature . . . 9 2.9 Raspberry Pi . . . 9 2.10 Brandv¨agg . . . 9
2.10.1 Packet Filtering Firewall . . . 9
2.10.2 Proxy Firewall . . . 10
2.10.3 Reverse Proxy Firewall . . . 10
2.10.4 Packet-inspection Firewall . . . 11
3 Litteraturstudie . . . 12
4 Fr˚agest¨allning . . . 14
5 Metod . . . 15
6 Etik och samh¨alleliga aspekter . . . 16
7 Design och genomf¨orande av experiment . . . 17
7.1 Program . . . 17
7.2 Scenario . . . 17
7.2.1 Scenario 1 IPS . . . 17
7.2.2 Uppr¨attandet av scenario 1 . . . 18
7.2.3 Uppr¨attandet av IPS . . . 19
7.3 Funktion . . . 20
7.3.1 Scenario 2 brandv¨agg . . . 21
8 Resultat . . . 22
8.1 IT-systemets utformning . . . 23
8.2 S¨akerst¨allandet av s¨akerhets˚atg¨arden . . . 24
10 Slutsatser . . . 26
11 Framtida arbete . . . 27
Referenser . . . 30
Figurer
1 Active Directory Logisk topologi . . . 42 Attackvektor: Fl¨ode . . . 5
3 Virtualiserade tj¨anster . . . 6
4 Resurs˚atg˚ang: Fysiska enheter . . . 7
5 Resurs˚atg˚ang: Enhet med virtualiserade tj¨anster . . . 7
6 Brandv¨agg: Ett n¨atverks insida och utsida . . . 9
7 Brandv¨agg: Packet filtering firewall [1] . . . 10
8 Brandv¨agg: Proxy firewall [1] . . . 10
9 Brandv¨agg: Reverse Proxy Firewall [1] . . . 11
10 Brandv¨agg: Packet-Inspection Firewall [1] . . . 11
11 Overgripande arbetsfl¨¨ ode . . . 15
12 Oversiktsbild f¨¨ or scenariogrund . . . 15
13 Oversiktsbild f¨¨ or scenario 1: Analys (IPS) . . . 18
14 Topologi f¨or scenario 1: Analys (IPS) . . . 19
15 Oversikt signatur . . . .¨ 20
16 Signaturens upps¨attning . . . 20
17 Oversiktsbild f¨¨ or scenario 2: Brandv¨agg . . . 22
18 Utslag p˚a beh¨orighets¨overtr¨adelse . . . 23
19 Utslag p˚a beh¨orighets¨overtr¨adelse IPS . . . 23
Tabeller
1 Pakettyper i RADIUS . . . 32 Signaturens default ˚atg¨arder . . . 19
3 Signaturens upps¨attning . . . 20
4 Uppr¨attandet av n¨atverksbrygga . . . 21
1
Inledning
Dagens n¨atverk har i huvuduppgift att tillhandah˚alla h¨og tillg¨anglighet av data och tj¨anster. I och med att fler system och klienter installeras ¨okar ¨aven volymerna k¨ansliga data som r¨or sig och/eller lagras i n¨atverken. Ett ¨overgripande krav p˚a ett IT-system ¨ar att det ska klara av att st¨otta verksamheter d¨ar informationsm¨angden ¨ar s˚adan att alla anv¨andare inte har samma beh¨orighet till alla resurser i n¨atverket [2][3] . Ser man till h¨ogriskmilj¨oer d¨ar bland annat myndigheter och milit¨ara anl¨aggningar ing˚ar ¨ar detta ett tydligt krav. Systemen m˚aste s¨akras upp samt att s¨akerhets˚atg¨arderna som implemen-terats m˚aste kunna p˚avisas. Ett exempel p˚a detta ¨ar system avsedda f¨or behandling av personuppgifter d¨ar det tydligt framg˚ar att adekvata s¨akerhets˚atg¨arder ska anv¨andas [3] [4].
Tidiga implementationer av IT-system byggde i h¨og grad p˚a decentraliserade system. Funktionaliteten i de systemen delades s˚aledes upp p˚a flertalet enheter med specifik funktionalitet d¨ar exempelvis s¨akerheten administrerades fr˚an en specifik enhet medan anv¨andare administrerades fr˚an en annan [5, pp. 2 - 7]. I nutid har de traditionella decent-raliserade systemen harmoniserats till ett centraliserat system med en katalogtj¨anst som nav. Katalogtj¨ansten har i uppgift att bland annat styra anv¨andare, grupper, filytor och ˚atkomstbeh¨origheter [6].
I och med den centrala roll som katalogtj¨ansten spelar i IT-milj¨oerna ¨ar dessa utsatta f¨or attacker och kr¨aver d¨arf¨or omfattande skydds˚atg¨arder. Jag har i arbetet d¨arf¨or valt att, med hj¨alp av tv˚a fr˚agest¨allningar, unders¨oka bland annat hur ˚atkomstprinciperna kan skyddas i en katalogtj¨anst. En katalogtj¨anst kan uts¨attas f¨or en rad olika angrepp med hj¨alp av attackmetoder som bland annat; Rekogniceringsattacker vilka ofta initierar ett an-grepp. Syftet med dessa ¨ar att samla information om de s˚arbarheter som finns i systemen, Brute Force-attacker som ¨ar en form av l¨osenordsgissning och eskalering av beh¨orighet till systemresurser [7]. Dessa ¨ar endast ett axplock av s˚arbarheter och attackmetoder som kan hota s¨akerheten i en katalogtj¨anst. Ett intressant omr˚ade ¨ar ˚atkomstprinciper. De styr bland annat beh¨origheter till olika resurser i systemet vilket kan ge f¨or¨odande konsekven-ser om dessa bryts. Problematiken som kan uppst˚a med ˚atkomstprinciperna och hur den kan motverkas eller mildras avhandlas d¨arf¨or ing˚aende i rapporten.
Jag valde att utf¨ora en litteraturstudie som skapade grunden f¨or testscenarierna som uppr¨attades i efterf¨oljande experimentfas. Milj¨on byggdes upp enligt en f¨ordefinierad to-pologi som delvis strukturerades om inf¨or respektive scenario. Genom att arbeta utifr˚an scenarierna i en simulerad milj¨o m¨ojliggjordes en h¨og flexibilitet i uppbyggnaden d¨ar mo-difieringar kunde utf¨oras utan st¨orre ingrepp. Arbetet som utf¨ordes avhandlar s˚arbarheter i katalogtj¨anster och ¨amnar n˚a adekvata metoder f¨or hur ˚atkomstprinciper kan skyddas. En stor del i examensarbetet har varit att eliminera single-point-of-failure och implemen-tera ytterligare s¨akerhets˚atg¨arder ut¨over katalogtj¨anstens. Studien visar att detta g˚ar att uppn˚a med hj¨alp av ett utav de tv˚a testfallen.
2
Bakgrund
Uppr¨attandet av IT-system grundar sig i en robust n¨atverksinfrastruktur som har i uppgift att transportera data som fl¨odar mellan kontrollenheter, servrar, ¨overvakningssystem och ¨
andnoder. Det underliggande n¨atverket kan i sin enkelhet ses som en transportkanal i mo-derna system. I syfte att ge n¨atverket specifik funktionalitet tills¨atts servrar vilka ansvarar f¨or bland annat anv¨andar- och s¨akerhetsadministration samt Network Attached Storage-funktionalitet (NAS). Vidare installeras klienter vilka nyttjar b˚ade n¨atverket och funktio-naliteten som servrarna tillhandah˚aller. I och med att klienterna anv¨ander n¨atverket i sitt dagliga arbete ¨okar m¨angden skyddsv¨ard data som fl¨odar i IT-systemen vilket ger upphov till ett omfattande s¨akerhetsarbete och ett robust system vilket i f¨orl¨angningen ¨aven ger h¨ogre motst˚andskraft mot riktade f¨ors¨ok att forcera s¨akerheten i systemen.
2.1 Katalogtj¨anster
En katalogtj¨anst m¨ojligg¨or centraliserad eller distribuerad administration av bland annat; beh¨orighetsprinciper, anv¨andare, grupper, n¨atverksresurser och regler i en hierarkisk struk-tur, detta f¨or att minimera den administrativa b¨ordan i att bibeh˚alla ett uppdaterat och effektivt system [5, pp. 3 - 6]. I f¨orl¨angningen betyder detta ¨aven att katalogtj¨ansten utg¨or en central punkt d¨ar anv¨andarnas beh¨origheter samlas och till˚ater s˚aledes anv¨andarna att nyttja olika resurser och tj¨anster som tillhandah˚alls i n¨atverket. D˚a f¨oretag och organisa-tioner kan str¨acka sig ¨over l˚anga geografiska str¨ackor implementeras ofta flertalet servrar som alla ¨ar en del av den ursprungliga katalogtj¨ansten. Detta medf¨or att informationen ¨ar n˚abar f¨or alla anv¨andare i organisationen utan krav p˚a fysisk plats. Katalogtj¨anster finns i en rad olika genomf¨oranden exempelvis Microsofts Active Directory, OpenLDAP och 389 Directory Services. Active Directory ¨ar marknadsledande med en sammanlagd procentuell anv¨andning om 87.17% enligt Spiceworks utv¨ardering av anv¨andandet av operativsystem f¨or servrar [8]. D˚a Microsofts Active Directory ¨ar dominerande p˚a marknaden kommer arbetet fokusera p˚a den katalogtj¨ansten.
2.2 Windows Server
Microsofts Windows Server ¨ar ett samlingsnamn f¨or operativsystem ¨amnade f¨or servrar, ¨
aven kallade n¨atverksoperativsystem (NOS). Utvecklandet av operativsystemet har hi-storiskt sett utf¨orts parallellt med utvecklandet av operativsystemen f¨or arbetsdatorer och hemdatorer d¨ar exempelvis Windows 7 och Windows 10 ing˚ar. Genom introduktio-nen av Windows Server-familjen gav Microsoft f¨oretag, organisationer och myndigheter m¨ojligheten att centralisera sina resurser p˚a ett och samma st¨alle. Operativsystemet till-handah˚aller ¨aven roller som ¨ar en samling tj¨anster som ger servern sin funktionalitet. Tj¨anster s˚a som Active Directory (AD), Domain Naming System (DNS), Dynamic Host Configuration Protocol (DHCP), Internet Information Services (IIS) [5, pp. 24 - 28]. Ut¨over rollerna ˚aterfinns ¨aven programtill¨agg som h¨ojer en eller flera rollers funktionalitet.
2.2.1 Remote Authentication Dial-In Services
Remote Access Dial-In User Service (RADIUS) ¨ar ett protokoll som ger administrat¨orer m¨ojlighet att administrera autentisering, beh¨origheter och samla statistik ¨over anv¨andning av resurser [9]. Protokoll som har attributen g˚ar under namnet AAA-protokoll (Authen-tication, Authorization and Accounting).
Autentisering En anv¨andare som skickar en f¨orfr˚agan om att f˚a tillg˚ang till n¨atverket eller specifika resurser m˚aste autentisera sig mot enhe-ten som k¨or tj¨ansten RADIUS. Med detta menas att anv¨andaren m˚aste uppge s¨akerhetsinformation som understryker att denne ¨
ar vem den utger sig f¨or att vara.
Beh¨orighetskontroll Efter en genomf¨ord autentiseringskontroll kontrolleras ¨aven vil-ka beh¨origheter anv¨andaren har i systemet. Anv¨andaren kan exempelvis endast vara beh¨orig att b¨ara sin trafik via Hyper-text Transfer Protocol (HTTP) vilket kontrolleras i beh¨ orighets-kontrollen.
¨
Overvakning Radius ger ¨aven administrat¨oren m¨ojlighet att kontrollera re-surs˚atg˚angen per anv¨andare. Detta ¨ar vanligt f¨orekommande bland exempelvis Internet Service Providers (ISP) och telekom-f¨oretag.
Radius anv¨ander sig av en rad olika typer av paket som skickas mellan klienten och ser-vern. Paketen som skickas har i uppgift att s¨akerst¨alla om klienter f˚ar tillg˚ang till n¨atverk och specifika resurser, bland dessa ˚aterfinns Access-Request, Access-Accept, Access-Reject, Access-Challenge [10, pp. 16 - 21]. Se tabell 1 f¨or information om de olika pakettyperna.
Tabell 1: Pakettyper i RADIUS
Access-Request Paketen skickas fr˚an klienten till servern i form av en f¨orfr˚agan d¨ar m˚alet med f¨orfr˚agan ¨ar att kontrollera om anv¨andaren har beh¨orighet att anv¨anda n¨atverket eller den specifika resursen. Access-Accept Servern kontrollerar uppgifterna i Request-paketet och om
f¨orfr˚agan godk¨anns skickas ett Access-Accept tillbaka till klien-ten.
Access-Reject Om Request-paketet d¨aremot inte godk¨anns svarar servern med ett Access-Reject.
Access-Challenge Challenge paketen skickas i syfte att kontrollera klientens upp-gifter och beh¨origheter p˚a nytt. Access-Challenge skickas f¨or att tvinga klienten att skicka ett nytt Access-Request meddelande, detta kontrolleras p˚a nytt och ett Access-Accept, Access-Reject eller Access-Challenge skickas p˚a nytt.
2.2.2 Active Directory
Tidiga implementationer av en intern och fullst¨andig infrastruktur grundade sig i ett de-centraliserat system d¨ar information om anv¨andarna lagrades i en databas medan anv¨andarnas konton samlades p˚a en fysiskt fr˚anskild server. S¨akerhets˚atg¨arder f¨or de specifika kontona kunde i vissa fall ¨aven dessa l¨aggas ut p˚a ytterligare en avskild enhet [5, pp. 3 - 6]. AD:t g¨or det m¨ojligt att centralisera informationen i en server eller distribuera funktionaliteten p˚a flera likv¨ardiga servrar.
En Windows Server med Active Directory (AD) installerat blir per definition en dom¨ an-kontrollant. All data som samlas i AD kallas objekt. Objekten katalogiseras i sin tur i mappar som kallas organisationsenheter (organizational unit (OU)) [6, pp. 17 - 18]. Systemet kan uppr¨attas centraliserat och distribuerat mellan olika dom¨ankontrollanter. Dom¨ankontrollanterna ¨ar en naturlig del i dom¨anernas hierarkiska struktur som grundar sig i ett s˚a kallat dom¨antr¨ad. Dom¨antr¨adet utg¨or de yttre gr¨anserna och samlar de under-liggande dom¨anerna [6, pp. 20-22]. Tr¨aden samlas i sin tur i en hierarkisk struktur kallad en skog [6, p. 22], se figur 1 f¨or en ¨oversiktlig bild av den logiska strukturen.
AD ¨ar byggt p˚a en rad olika tj¨anster och Active Directory Domain Services (AD DS) ¨ar en av dessa [5][6]. Active Directory Domain Services ¨ar Microsofts svar p˚a en katalogtj¨anst. AD DS samlar alla n¨atverksanslutna enheter i en hierarkisk struktur f¨or att underl¨atta administration av resurserna [5]. Den hierarkiska strukturen samlas och styrs i ett s˚a kallat Schema [5]. Schemat kan modifieras f¨or att g¨ora rum f¨or specifika tidigare odefinierade resurser.
2.3 Hot
Med hot mot en IT-milj¨o syftas det ofta till obeh¨origa intr˚ang som kan f¨orekomma, i alla sina former [11]. Alla akt¨orer med upps˚at att skada eller g¨ora data och tj¨anster on˚abara r¨aknas som hot [12]. Exempel p˚a hot kan vara k¨anslig data som kan hamna i fel h¨ander p˚a grund av att de anst¨allda ¨ar outbildade i omr˚adet IT, h˚ard- och mjukvara som inte uppdateras kontinuerligt samt hackers. Andra h¨andelser s˚a som naturkatastrofer och slarv r¨aknas ¨aven de in bland hoten. K¨anslig data ¨ar alltid utsatt f¨or hot fr˚an olika akt¨orer, som via s˚arbarheter kan n˚a m˚alet som ¨ar den ¨onskade resursen [13].
2.4 S˚arbarheter
En s˚arbarhet ¨ar ett s¨akerhetsh˚al i ett IT-system eller applikation som g¨or systemet mot-tagligt mot angrepp. H˚alen f¨orekommer i allt fr˚an h˚ardvara till personen som konfigurerar eller nyttjar enheten i sitt dagliga bruk. S˚arbarheterna kan vara en f¨oljd av den m¨anskliga faktorn d¨ar personen i fr˚aga konfigurerat en enhet eller tj¨anst fel, s˚arbarheterna kan ¨aven grunda sig i tillverkares konfigurationsmisstag eller att de helt enkelt inte uppm¨arksammat h˚alet under produktion. H˚alen nyttjas i sin tur av en angripare f¨or att n˚a k¨anslig data. [12] [14]
2.5 Attackvektorer
En attackvektor ¨ar i sin enkelhet ett medel vilken en akt¨or med illvilja kan nyttja i syfte att f˚a tillg˚ang till klienter samt det underliggande n¨atverket [15]. Medlet kan exempelvis vara en PDF-fil, en hemsida, ett svagt l¨osenord, den m¨anskliga faktorn eller en konfi-gurationsmiss som l¨amnar en s˚arbarhet i systemet vilken kan nyttjas som attackvektor. Attackvektorn g¨or det m¨ojligt f¨or akt¨oren att leverera en nyttolast, vilken ¨ar den data som skickas med f¨or att utf¨ora ett angrepp och den anv¨ands f¨or att forcera s¨akerheten och f˚a tillg˚ang till de ¨onskade resurserna eller skyddsv¨ard data. Se figur 2 f¨or ett ¨overgripande f¨orlopp f¨or hur en attackvektor anv¨ands i syfte att ¨aventyra s¨akerheten i ett IT-system.
Ett scenario f¨or att p˚avisa vad en attackvektor ¨ar och hur den anv¨ands kan exempelvis vara, att en Microsoft Office Word-fil (.docx) anv¨ands som attackvektor i syfte att exploatera en k¨and s˚arbarhet i Microsoft Office.
2.6 Virtualisering
Virtualisering ¨ar en teknik f¨or att skapa flertalet simulerade komponenter i en IT-milj¨o samt att i vissa fall simulera kompletta milj¨oer vilket redovisas grafiskt i figur 3. En simu-lerad komponent kallas f¨or en virtuell maskin, dessa simuleras p˚a h˚ardvaran via en hyper-visor. Hypervisorerna finns i tv˚a genomf¨oranden, Typ 1 och Typ 2. En Typ 1-hypervisor implementeras direkt p˚a h˚ardvaran och blir s˚aledes det enda lagret ”mellan” h˚ardvaran och de virtuella maskinerna. En hypervisor av typen 2 installeras d¨aremot ovanp˚a ett un-derliggande operativsystem som exempelvis Windows eller Linux. [16, pp. 5 - 14]
Figur 3: Virtualiserade tj¨anster
Virtualisering av operativsystem kan anv¨andas i syfte att nyttja h˚ardvarans fulla kapacitet samt effektivisera hanteringen av tj¨anster. Traditionellt implementeras tj¨anster i separata servrar dedikerade f¨or en specifik tj¨anst vilket g¨or att systemen i m˚anga fall har ¨overfl¨odiga resurser kvar som inte nyttjas enligt figur 4.
Figur 4: Resurs˚atg˚ang: Fysiska enheter
Virtualiseringen g¨or det m¨ojligt att nyttja hela resursspektrumet, se figur 5, detta ge-nom att installera tj¨ansterna sida vid sida med bland annat f¨ordefinierad processorkraft, v¨axlingsutrymme och portar. [16, pp. 5 - 14] [17]
Figur 5: Resurs˚atg˚ang: Enhet med virtualiserade tj¨anster
2.6.1 Virtualbox
Virtualbox ¨ar en mjukvara med ¨oppen k¨allkod som g¨or det m¨ojligt att virtualisera flertalet operativsystem i en fysisk enhet. Mjukvaran utvecklades initialt av Innotek GmbH som senare f¨orv¨arvades av Oracle Corporation. Virtualbox ¨ar en typisk Typ 2 -hypervisor i det att mjukvaran installeras ovanp˚a ett operativsystem som ¨aven kallas Host operating system. [18]
2.6.2 Graphical Network Simulator 3
Graphical Network Simulator 3 (GNS3) ¨ar en grafisk simulator framtagen av Jeremy Gross-man [19] . Mjukvaran sl¨apptes f¨or allm¨annheten ˚ar 2008 och g¨or det m¨ojligt att virtualisera, designa och testk¨ora olika typer av n¨atverksmilj¨oer [19] [20, p. 1 - 2]. Mjukvaran ¨ar en av f˚a som klarar av att simulera funktionaliteten fr˚an olika tillverkares operativsystem och h˚ardvara. Virtualisering av routrar, switchar och servrar i GNS3 ger en bra bild av hur ett n¨atverk beter sig i verkligheten [20, pp. 2-8].
2.7 Kontroll av paketfl¨ode
Wireshark ¨ar ett program som g¨or det m¨ojligt att analysera paketfl¨oden i realtid. Inneh˚allet i trafikfl¨odena kan med hj¨alp av mjukvaran unders¨okas i syfte att ¨overvaka vad som r¨or sig mellan enheterna internt samt vad som mottas fr˚an internet. Wireshark g¨or det ¨aven m¨ojligt att ¨overvaka och analysera paketfl¨odena i realtid och presenterar dessa i ett gra-fiskt gr¨anssnitt. Attributen som karakt¨ariserar Wireshark ger administrat¨orer m¨ojlighet att fels¨oka problem i n¨atverket, unders¨oka s¨akerheten samt kontrollera hur enheter och applikationer nyttjar n¨atverket och uppkopplade enheter. [21]
2.8 Intrusion Prevention System
Ett Intrusion Prevention System (IPS) [22] ¨ar en mjuk- eller h˚ardvara implementerad i en IT-milj¨o. IPS:en g¨or det m¨ojligt att i realtid ¨overvaka och kontrollera trafik mot specifika signaturer i syfte att f¨orhindra attacker och utnyttjandet av s˚arbarheter [23]. Systemet implementeras inline, det betyder att IPS:en implementeras mellan tv˚a enheter exempelvis enligt nedan:
Klientenhet → IPS → Switch
Enheten kan ¨aven placeras p˚a en strategisk plats i infrastrukturen exempelvis mellan olika kontorsn¨atverk enligt nedan:
Ekonomi → IPS → F orskning
Signaturerna som anv¨ands av IPS:en ¨ar i sin enkelhet en upps¨attning regler. Reglerna ¨ar uppbyggda f¨or att para ihop trafiken som i realtid r¨or sig igenom IPS:en. Dessa matchas mot signaturerna vilka ¨ar uppbyggda med bland annat regler som g¨or k¨anda attacker synliga och egenskapade regler f¨or trafik som inte f˚ar r¨ora sig mellan exempelvis olika n¨atverkssegment [22]. IPS:en kan konfigureras enligt tre ¨overgripande metoder vilka ¨ar Signature-based, Anomaly-based och Policy-based. Signaturerna kan uppr¨attas i tv˚a olika former, atomic- och stateful-signaturer.
2.8.1 Signature-based
En IPS som uppr¨attas enligt signature-based-metoden konfigureras f¨or att analysera tra-fikfl¨odena och matcha dessa mot en databas som ¨ar uppbyggd av k¨anda attacksignaturer. F¨or att kunna matcha trafikfl¨odena unders¨oks pakethuvudet samt informationen som skic-kas med i paketet. [24, p. 14]
2.8.2 Anomaly-based
En anomaly-based-enhet grundar sig i en f¨orberedelseperiod d¨ar n¨atverket ¨overvakas ¨over tid f¨or att ge IPS:en en f¨orst˚aelse ¨over vad som ¨ar normalanv¨andning av n¨atverket. N¨ar normalen v¨al ¨ar uppr¨attad kan IPS:en utifr˚an normalfallet detektera anomalier i trafik-fl¨odena som f¨ardas i n¨atverket. [24, p. 15 ]
2.8.3 Policy-based
Uppr¨attas enheten enligt metoden Policy-based utg˚ar den fr˚an f¨ordefinierade regler. Reg-lerna grundar sig generellt sett i parametrar som att till˚ata och neka trafik fr˚an specifika avs¨andare till de avsedda mottagarna ¨over k¨anda protokoll. [24, p. 15]
2.8.4 Atomic Signature
En atomic signature ¨ar den enklaste typen av signaturer. De bygger p˚a att unders¨oka ett paket eller ett event i taget. En atomic signature beh¨over ingen information om d˚atida eller framtida aktivitet i n¨atverket f¨or att kunna utf¨ora sina beslut ¨over vad som ska g¨oras med de specifika paketen. De beh¨over allts˚a inte ¨overvaka hela trafikfl¨oden utan matchar ist¨allet varje paket mot reglerna f¨or att hitta och motverka ett eventuellt angrepp. [24, pp. 245 - 246]
2.8.5 Stateful Signature
En Stateful signature kontrollerar till skillnad ifr˚an en atomic signature hela trafikfl¨oden f¨or att skapa en bild av om det ¨ar ett eventuellt angrepp eller legitim trafik. Under kontrollen av paketfl¨odet samlas delar av information in under en f¨ordefinierad tid f¨or att kunna matcha mot de specifika attacksignaturerna som samlats i databasen. [24]
2.9 Raspberry Pi
Raspberry Pi [25] ¨ar en mini-dator som skapats i syfte att vara ett solitt och ett kostnads-effektivt alternativ f¨or att l¨ara ut grundl¨aggande datavetenskap i skolor. F¨orsta versionen sl¨apptes 2012 och var utrustad med 256 Mb RAM. H˚ardvaran har utvecklats sedan dess och ¨ar numera utrustad med en kraftfullare processor och RAM vilket g¨or det m¨ojligt att anv¨anda enheten till mer resurskr¨avande funktioner s˚a som en brandv¨agg eller IPS. F¨or att ge h˚ardvaran sin funktionalitet kr¨avs ett operativsystem. Linux ¨ar det f¨oredragna ope-rativsystemet p˚a enheten med bland annat distributioner som Ubuntu och Debian vilka har specifikt framtagna distributioner f¨or Raspberry Pi.
2.10 Brandv¨agg
En brandv¨agg ¨ar en s¨akerhetsh¨ojande enhet som i sin enkelhet till˚ater och nekar olika typer av trafikfl¨oden i n¨atverken. Enheten delar upp n¨atverket i olika zoner d¨ar dessa markerar ”omr˚aden” i n¨atverket, som antingen ¨ar s¨akra eller os¨akra enligt vad administrat¨oren konfigurerat. Vidare agerar brandv¨aggen som en vakt mellan zonerna d¨ar regler uppr¨attas f¨or att till˚ata eller blockera trafikfl¨oden som r¨or sig mellan zonerna via brandv¨aggen, se figur 6. Brandv¨aggarna kan uppr¨attas i en rad olika genomf¨oranden, bland annat som Packet Filtering Firewall, Stateful Firewall, Proxy Firewall och Packet-Inspection Firewall.
Figur 6: Brandv¨agg: Ett n¨atverks insida och utsida
2.10.1 Packet Filtering Firewall
En packet filtering firewall grundar sina beslut p˚a parametrar som ˚aterfinns i den trafik som fl¨odar i n¨atverken s˚a som; vilket protokoll som anv¨ands, s¨andar- och mottagaradresser och vilken typ av tj¨anst trafiken tillh¨or. Reglerna som uppr¨attas i en brandv¨agg av den h¨ar typen ¨ar statiska vilket betyder att de inte f¨or¨andras ¨over tid. Detta ¨oppnar upp och kan ge en hacker en attackm¨ojlighet i det att nyttolasten som anv¨ands vid attacken tunnlas igenom brandv¨aggen vilket hade gett angriparen en ¨oppning in i systemet. Den h¨ar typen
av brandv¨agg finns och g˚ar att konfigurera p˚a majoriteten av enheterna som ˚aterfinns i ett n¨atverk som exempelvis routrar, switchar och klientenheter, se figur 7 f¨or en ¨overgripande bild av hur en packet filtering firewall arbetar. [1]
Figur 7: Brandv¨agg: Packet filtering firewall [1]
2.10.2 Proxy Firewall
Proxy firewall arbetar p˚a lager sju i OSI-modellen. Lager sju ¨ar applikationslagret d¨ar tj¨ansterna som k¨ors p˚a klientenheterna arbetar. Den h¨ar typen av brandv¨agg agerar i sin enkelhet som en m¨otesplats d¨ar tj¨ansten som k¨ors p˚a klientenheten exempelvis en webbl¨asare vilken ¨oppnar en hemsida m¨oter hemsidans inneh˚all. Det klienten ¨oppnar ett trafikfl¨ode fr˚an sig sj¨alv till brandv¨aggen som i sin tur ¨oppnar ett fl¨ode med sig sj¨alv som mottagare till hemsidan som efterfr˚agats. N¨ar fl¨odet v¨al ¨ar uppr¨attat rel¨aar brandv¨aggen hemsidan till klienten se figur 8. [1]
Figur 8: Brandv¨agg: Proxy firewall [1]
2.10.3 Reverse Proxy Firewall
En Reverse Proxy Firewall arbetar i stort p˚a samma s¨att som en Proxy firewall, skillnaden ¨
ar att denna fokuserar p˚a att skydda servern ist¨allet f¨or klienten. En anv¨andare som efterfr˚agar en specifik resurs skickar d˚a denna via en proxy-server till den avsedda servern med resursen, vidare kan ¨aven brandv¨aggen agera lastbalanserare och skicka f¨orfr˚agan till flera olika servrar med samma resurs, se figur 9. [1]
Figur 9: Brandv¨agg: Reverse Proxy Firewall [1]
2.10.4 Packet-inspection Firewall
Tekniken Packet-inspection grundar sig i att brandv¨aggen kontrollerar hela paketfl¨oden mellan s¨andare och mottagare. Det vill s¨aga fr˚an det att f¨orsta paketet skickas till dess att sista paketet ¨ar mottaget kontrollerar brandv¨aggen om trafikfl¨odet ¨ar beh¨origt att f¨oras in eller ut i n¨atverket. I paketfl¨odet ˚aterfinns bland annat information om protokoll, sessioner, s¨andar- och mottagar-adress samt tj¨anstespecifik information, exempelvis vilka File Transfer Protokoll portar som anv¨ands. Vidare arbetar brandv¨aggen enligt f¨oljande fl¨odesschema: en anv¨andare efterfr˚agar en specifik resurs p˚a servern, f¨orfr˚agan f¨ardas d˚a in i brandv¨aggen som kontrollerar om f¨orfr˚agan ¨ar beh¨orig att passera ut mot resursen, i vissa fall kan brandv¨aggen ¨aven unders¨oka nyttodatan som skickas. Processen syftas ofta till som deep-packet inspection. Om parametrarna ¨overensst¨ammer med regelverket som uppr¨attats i brandv¨aggen sl¨apps trafiken igenom och fl¨odet forts¨atter att ¨overvakas. Returtrafiken kontrolleras ¨aven denna mot regelverket det vill s¨aga att om trafiken som kommer tillbaka som svar p˚a fr˚agan ¨ar legitim eller inte. Anses trafiken legitim skickas den vidare till klienten och om inte filtreras den bort, se figur 10 f¨or ¨overgripande funktionalitet. [1]
3
Litteraturstudie
I M. R. DeLong et al. Dukes university’s protected network [26] unders¨oktes m¨ojligheten att skydda forskarnas data vid Dukes universitet. F¨orfattarnas m˚al med arbetet var att genom s¨akerhetsh¨ojande ˚atg¨arder och riktlinjer s¨akra k¨anslig data som bearbetas av fors-karna, bland annat personuppgifter, h¨alsodeklarationer/journaler samt ¨ovrig skyddsv¨ard data. Arbetet inleddes med att s¨akerhetsklassa information i tre ¨overgripande kategorier vilka var k¨anslig, begr¨ansad ˚atkomst och ¨oppen. Kategoriernas respektive s¨akerhetsklass skapade en l¨agsta niv˚a d¨ar den ¨oppna informationen inte ans˚ags vara lika skyddsv¨ard som informationen med begr¨ansad ˚atkomst och den k¨ansliga informationen. Arbetet fokuserade fr¨amst p˚a kategorin k¨anslig information d¨ar bland annat personnummer och bankuppgif-ter ˚aterfanns.
Utredningen utgick fr˚an att ¨overgripligt s¨akra upp systemet p˚a de intressanta fronterna, bland annat unders¨oktes m¨ojligheten att segmentera upp infrastrukturen samt gransk-ning av autentiserings- och identitetskontroll. Systemet byggdes upp med hj¨alp av vir-tualisering och administrativa grupper f¨or att effektivt kunna segmentera resurserna och ge anv¨andarna en flexibel upplevelse som samtidigt uppn˚adde f¨orfattarnas f¨ordefinierade krav p˚a IT-milj¨on.
I en studie utf¨ord av C. H. Hsieh et al. [27] unders¨oktes ¨overvakning av anomalier i Active Directories logghantering. Anomalierna av intresse var Advanced Persistent Th-reats (APT), vilket ¨ar hacking-processer som arbetar ¨over l˚ang tid. APT k¨or kontinuer-liga processer i syfte att utnyttja s˚arbarheter i systemen n¨ar dessa hittats. Arbetet slog fast en l¨osningsmetod som grundade sig i att hot skulle synligg¨oras genom att ¨overvaka anv¨andarkontons beteende i AD-loggarna. Vidare kontrollerade dom¨ankontrollanten bete-endet ur loggarna. 95 konton ¨overvakades under tv˚a m˚anader, under den tiden samlades 22.5 GB data till loggarna. Vidare analyserade f¨orfattarna de skapade AD-loggarna in-neh˚allande anv¨andarkontonas beteende p˚a det lokala n¨atverket. Det visade sig dock att den valda algoritmen inte var optimal f¨or ¨andam˚alet, f¨orfattarna ans˚ag Markov-modellen ihop andra olika typer av loggar och kontexter kan vara av v¨arde i det framtida arbetet med att ¨overvaka om anomalier och insiderhot som f¨orekommer i det lokala n¨atverket.
D. Chadwick utf¨orde i Threat Modelling for Active Directory en unders¨okning i vilken hotbild som finns mot Active Directory och anslutna webbtj¨anster. Arbetet kartlade de ¨
overgipande hoten och attackerna som tj¨ansten kan uts¨attas f¨or, bland dessa ˚aterfanns spoofing, eskalering av r¨attigheter, manipulering av data och Distributed Denial of Ser-vice (DDOS). Kartl¨aggningen gav ¨aven upphov till metoder f¨or att mildra eller f¨orhindra angreppen helt. Metoderna som gjorde sig synliga i arbetet var bland annat; kryptering och autentisering av trafik som skickas via ett ”os¨akert” n¨atverk, att via access-listor be-gr¨ansa r¨attigheterna till AD samt begr¨ansa vad klienten har m¨ojlighet att skicka med i f¨orfr˚agan till servern. [28]
En viktig aspekt att ta i beaktning ¨ar informationen som samlas i katalogtj¨ansterna om bland andra personal och kunder som i m˚anga fall ¨ar skyddsv¨ard. W. Claycomb et al. [29] unders¨okte problematiken i personlig information som inte var tillr¨ackligt skyddad i IT-milj¨oerna. Id´en grundade sig i en stor ¨okande m¨angd identitetsst¨older. F¨orfattarnas fokus var att s¨akra upp informationen mot interna hot, exempelvis att en systemadmi-nistrat¨or h¨amtar informationen f¨or egen vinning, modifierar den eller raderar den helt.
Problematiken med obeh¨origas tillg˚ang till den personliga informationen arbetades till del bort genom anv¨andandet av virtuella kataloger som implementerades mellan klient och server samt anv¨andandet av distribuerade krypteringsnycklar. En vidareutveckling f¨orfattarna fattade intresse f¨or var att implementera l¨osningen ihop med existerande Pub-lic Key Infrastructure-system (PKI), f¨or att minimera underh˚allet p˚a anv¨andarnas kryp-teringsnycklar och l¨osenord.
Litteraturen som unders¨okts tog bland annat ett helhetsgrepp ¨over s¨akerheten i AD, IT-milj¨oerna, beteendem¨onster baserat p˚a hur anv¨andarkonton arbetade i det lokala n¨atverket och hur insiderhot mildras. I arbetet som utf¨ors i den h¨ar rapporten fokuserar jag p˚a att hit-ta en l¨osning p˚a hur man kan g¨ora AD mer robust i hur systemet behandlar f¨orfr˚agningar till resurser hemmah¨orande i servern vilket ocks˚a blir mitt till¨agg i diskussionen kring s¨akerhetsrelaterade arbeten med fokus p˚a Windows Server och katalogtj¨ansten AD.
4
Fr˚
agest¨
allning
En IT-milj¨o grundar sig generellt sett i en katalogtj¨anst vilken ¨ar den centrala punkt d¨ar anv¨andare, grupper, n¨atverksresurser och enheter samlas. Windows Server med tj¨ansten Active Directory ¨ar marknadsledande i segmentet [8]. D˚a Active Directory implementeras i milj¨oer med h¨oga krav p˚a s¨akerheten s˚a som milit¨ara anl¨aggningar och myndigheter, kr¨avs ett gediget s¨akerhetsarbete f¨or att s¨akerst¨alla ett robust system. D˚a felsvar ¨ar ett hot och en eventuell attackvektor i ett IT-system kr¨avs ett f¨orebyggande arbete f¨or att motverka dessa.
Arbetet syftar till att ¨oka medvetenheten kring de hypotetiska s˚arbarheterna som finns i en katalogtj¨anst. Arbetet str¨avar ¨aven efter att definiera riktlinjer ¨over hur en po-tentiell s˚arbarhet i ˚atkomstprinciper kan motverkas eller mildras samt hur ˚atg¨arderna kan s¨akerst¨allas och p˚avisas. M˚alet med arbetet ¨ar att med hj¨alp av s¨akerhetsh¨ojande ˚atg¨arder i form av en IPS och en brandv¨agg s¨akra upp katalogtj¨anstens ˚atkomstprinciper samt p˚avisa dessas funktionalitet. Teknikerna valdes ut baserat p˚a f¨orm˚agan att i realtid analysera trafik och utifr˚an den analyserade trafiken utf¨ora olika typer av f¨ordefinierade ˚atg¨arder. Rapporten ¨amnar ¨aven att ge motiv f¨or att arbeta proaktivt f¨or att f¨orebygga eventuella s˚arbarheter och hot i katalogtj¨ansternas ˚atkomstprinciper. Nedan presenteras fr˚agest¨allningarna som rapporten ska besvara:
1. Hur kan en IT-milj¨o utformas s˚a att en hypotetisk och allvarlig s˚arbarhet i katalog-tj¨ansten inte riskerar att ¨aventyra viktiga ˚atkomstprinciper?
2. Hur kan de implementerade s¨akerhets˚atg¨arderna p˚a katalogtj¨ansten s¨akerst¨allas och p˚avisas?
Fr˚agest¨allningarna kommer att besvaras med hj¨alp av nedanst˚aende delfr˚agor.
• Kan en katalogtj¨ansts ˚atkomstprinciper s¨akras upp med hj¨alp av ett Intrusion Pre-vention System?
• Kan ˚atg¨arden s¨akerst¨allas och p˚avisas?
• Kan katalogtj¨anstens ˚atkomst- och autentiseringsprinciper skyddas med hj¨alp av en brandv¨agg?
• Kan ˚atg¨arden s¨akerst¨allas och p˚avisas?
Den laboration som kommer att utf¨oras utg˚ar fr˚an en generisk topologi som fokuserar p˚a den interna s¨akerheten i katalogtj¨ansten och alla dess lager, bland annat administrativa-anv¨andar- och ˚atkomstbeh¨origheter. Det underliggande n¨atverket kommer endast att agera transportkanal och kommer inte avhandlas ing˚aende i arbetet. Arbetet kommer inte heller ta h¨ansyn till den m¨anskliga faktorns p˚averkan p˚a s¨akerheten.
5
Metod
Inledningsvis utf¨ordes en litteraturstudie i syfte att inh¨amta relevant information kring s¨akerhet i katalogtj¨anster samt vilka s˚arbarheter en katalogtj¨anst medf¨or. De tidigare verken omsattes vidare i rapporten och skapade en stabil grund f¨or det kommande arbetet i experimentfasen, se figur 11 f¨or en ¨overgripande bild ¨over arbetsfl¨odet.
Figur 11: ¨Overgripande arbetsfl¨ode
Experimenten som utf¨ordes grundade sig i en statisk simulerad milj¨o d¨ar katalogtj¨ansten sattes i fokus. I experimentfasen implementerades s¨akerhets˚atg¨arderna stegvis i syfte att kontrollera hela arbetsfl¨odet. Genom att anv¨anda en simulerad milj¨o kunde modifieringar p˚a tj¨ansterna g¨oras utan n˚agra st¨orre ingrepp.
Den simulerade milj¨on bestod av ett n¨atverk som endast agerade transportkanal, ett god-tyckligt antal slutanv¨andare installerades samt en server. De tester som utf¨ordes i den simulerade milj¨on kategoriserades in i olika scenarier. Scenarion uppr¨attades f¨or att ge oli-ka infallsvinklar p˚a hur ˚atkomstprinciperna kan skyddas. Milj¨on modifierades f¨or att till˚ata olika typer av testfall d¨ar exempelvis enheter tillsattes f¨or att kontrollera f¨orfr˚agningar. Detta f¨or att uppn˚a en adekvat metod f¨or att h¨oja s¨akerheten i systemet med avseende fr¨amst p˚a ˚atkomstprinciperna. Se figur 12 f¨or en principskiss av scenariogrunden.
Scenarierna grundade sig i att ytterligare ett lager av skydd implementerades i syfte att g¨ora systemet mer robust. Syftet med experimenten var att testa om f¨orfr˚agningarna kun-de analyseras och ˚atg¨arda eventuella anomalier som uppm¨arksammats i fl¨odena samt att forcera fram fel i hur servern svarar p˚a beh¨orighetsregelverket.
Olika typer av s¨akerhetsh¨ojande ˚atg¨arder implementerades i syfte att mildra effekten av att beh¨origheterna br¨ots. ˚Atg¨arderna var i form av exempelvis en IPS vilken implementera-des inline och kontrollerade f¨orfr˚agningarna som skickades via enheten till serven, vidare gjorde IPS:en avv¨agandet om klienten var beh¨orig till resursen eller inte. Denna struk-tur uppr¨attades i ett scenario som virtualiserades i VirtualBox och GNS3. M¨atningarna ¨
overvakades med Wireshark av den anledning att GNS3 st¨odjer programmet samt att funktionaliteten i Wireshark ger en djupg˚aende kunskap i paketens uppbyggnad och in-neh˚all. Den information som gick att utl¨asa i Wireshark lade ¨aven grunden f¨or hur regel-verket i IPS:en skrevs. Ett teoretiskt resonemang arbetades ¨aven fram d¨ar en brandv¨agg agerade s¨akerhetsh¨ojande ˚atg¨ard. Denna var t¨ankt att harmonisera analys, autentisering och auktorisation av anv¨andare och f¨orfr˚agningar i symbios med katalogtj¨ansten.
6
Etik och samh¨
alleliga aspekter
D˚a arbetet inte inneh˚aller varken kvantitativa eller kvalitativa intervjuer samt att den si-mulerade laborationsmilj¨on ¨ar uppsatt och utf¨ors privat i en milj¨o som ej p˚averkar omgiv-ningen ger arbetet i sig inte upphov till n˚agra etiska fr˚agest¨allningar. Implementeras IPS:er eller brandv¨aggar enligt det f¨oreslagna l¨osningsf¨orslaget i ett produktionsn¨atverk kan det medf¨ora ett ¨overtramp p˚a bland annat personalens integritet. Detta d˚a trafiken analyse-ras och i vissa fall loggas f¨or att analyseras b˚ade i realtid samt vid ett senare skede. Kan ¨
overtramp i form av otill˚aten kartl¨aggning av den enskilda anv¨andarens anv¨andningsvanor i IT-systemen samt internet utf¨oras? Fr˚agest¨allningar i enlighet med denna kan komma att beh¨ova regleras och styras mot riktlinjer och g¨allande lagstiftning.
Unders¨okningen medf¨or ¨aven vissa samh¨alleliga aspekter. F¨or att s¨atta arbetet som helhet och katalogtj¨ansten i sitt sammanhang sett till verkligheten ska man vara v¨al medveten om att tj¨ansten ¨ar implementerad och verkar i stora som sm˚a f¨oretag, myndigheter, mi-lit¨ara anl¨aggningar och andra skyddsobjekt. Katalogtj¨ansten ¨ar ett nav f¨or administration av bland annat anv¨andares beh¨origheter. I och med den centrala del i ett IT-system som katalogtj¨ansten utg¨or kr¨avs ett gediget arbete f¨or att minimera exempelvis felsvar p˚a f¨orfr˚agningar.
Ett felsvar kan i praktiken vara harml¨ost men det kan ¨aven ge f¨or¨odande konsekvenser d¨ar personer med ont upps˚at f˚ar tillg˚ang till hemliga dokument, funktioner och beh¨origheter i systemet. Felsvar som uppkommer i samh¨allskritisk infrastruktur s˚a som myndigheter och f¨oretag som tillhandah˚aller vitala tj¨anster och funktioner i samh¨allet kan vara kritis-ka. I f¨orl¨angningen kan felsvar ¨aven anv¨andas av externa akt¨orer och fr¨ammande makter som en attackvektor f¨or att sl˚a ut funktionerna samt stj¨ala exempelvis hemlig informa-tion. Vidare kan ¨aven felsvar av katalogtj¨ansten som ger obeh¨origa tillg˚ang till exempelvis f¨oretagshemligheter ge upphov till ekonomisk vinning f¨or individen eller akt¨oren och i f¨orl¨angningen en potentiell ekonomisk f¨orlust f¨or det avsedda f¨oretaget.
7
Design och genomf¨
orande av experiment
Arbetet grundade sig i olika typer av scenarion som skapades i tv˚a genomf¨oranden. De olika scenarierna uppr¨attades med samma grundtanke, vilken var att ¨oka s¨akerheten i IT-systemet med fokus p˚a katalogtj¨anstens funktionalitet. Testfallen utgick fr˚an en grundto-pologi som byggdes upp modul¨art f¨or att m¨ojligg¨ora enklare modifieringar i milj¨on f¨or att n˚a de olika kraven p˚a testfallen.
7.1 Program
F¨or att skapa testmilj¨on kr¨avdes ett antal olika program och operativsystem. I centrum stod virtualiseringsmjukvarorna GNS3 och Virtualbox. Virtualbox ¨ar en open-source-mjukvara som g¨or det m¨ojligt att virtualisera olika typer av operativsystem, vilket var v¨aldigt anv¨andbart i de simulerade testerna. GNS3 anv¨andes i syfte att virtualisera n¨ atverks-enheterna samt att knyta ihop s¨acken med de virtualiserade operativsystemen i Virtual-box. Windows Server 2012 R2 spelade en stor roll i topologin d˚a Active Directory (Ka-talogtj¨ansten) installerades p˚a operativsystemet och enheten fungerade som en central administrativ punkt i grundtopologin. Vidare skapades bland annat en Linux-maskin som agerade IPS. IPS:en som valdes ut f¨or ¨andam˚alet var open-source-mjukvaran Snort fr¨amst av den anledningen att denna ¨ar en mjukvara med ¨oppen k¨allkod vilket medf¨or att mjukva-ran kan modifieras och konfigureras efter definierade behov. I Snort finns ¨aven m¨ojligheten att skapa egna signaturer och upps¨attningen av systemet var bekant. Snort g¨or det ¨aven m¨ojligt att baserat p˚a de skapade reglerna utf¨ora specifika ˚atg¨arder med de specifika tra-fikfl¨oden som r¨or sig igenom enheten.
7.2 Scenario
Testfallen byggde p˚a tv˚a scenarier som b˚ada utgick fr˚an samma grundbult. Denna var att med s¨akerhetsh¨ojande ˚atg¨arder g¨ora systemet mer robust mot att beh¨orighetsprinciperna bryts och ger obeh¨orig personal eller akt¨orer tillg˚ang till skyddsv¨arda resurser. Scenario 1 bestod av grundtopologin med till¨agget att en IPS implementerades medan scenario 2 grundade sig i en proxy brandv¨agg, vilken inte implementerades praktiskt.
7.2.1 Scenario 1 IPS
Ett Intrusion Prevention System konfigureras f¨or att kontrollera viss typ av trafik. Den tra-fik som ska kontrolleras baseras p˚a AD-registrets uppbyggnad och anv¨andarnas/kontorens beh¨origheter i syfte att ¨overvaka fl¨oden, specifika m¨onster och baserat p˚a dessa kunna utf¨ora f¨ordefinierade ˚atg¨arder. Den trafik som matchas kontrolleras mot signaturer skapa-de ur katalogtj¨anstens beh¨orighetsprinciper. Genom att IPS:en analyserar trafikfl¨odena och j¨amf¨or dessa mot signaturerna i realtid kan enheten godk¨anna eller underk¨anna f¨orfr˚agningarna. IPS:en placeras i trafikfl¨odet (inline), detta f¨or att ge enheten m¨ojlighet att agera p˚a anomalier i trafikfl¨odena vilka ¨ar obeh¨origa f¨ors¨ok att n˚a specifika resurser, se figur 13 f¨or en ¨oversiktsbild ¨over IPS-topologin.
Figur 13: ¨Oversiktsbild f¨or scenario 1: Analys (IPS)
7.2.2 Uppr¨attandet av scenario 1
Experimentfasen delades in i tv˚a testfall med olika konfigurationer d¨ar b˚ade praktiska och teoretiska till¨ampningar ingick. Grundtopologin som anv¨andes bestod av en Windows Ser-ver virtualiserad i Virtualbox med tj¨ansten Active Directory. Enheten importerades vidare in i GNS3 d¨ar den underliggande n¨atverksinfrastrukturen ¨aven virtualiserades, enligt Figur 14. En virtualiserad Linuxmaskiner uppr¨attades och huserade bland annat IPS-mjukvaran Snort. Uppbyggnaden av IPS-scenariot enligt nedan:
Operativsystem • Windows Server 2012 R2 • Ubuntu Mate 16.04 LTS • Windows 7 Mjukvara • Active Directory • Snort Topologi • Tr¨adstruktur
Figur 14: Topologi f¨or scenario 1: Analys (IPS)
AD uppr¨attades i en grundl¨aggande konfiguration d¨ar en skog skapades med ett tillh¨orande tr¨ad och en dom¨an. I denna konfigurerades tv˚a anv¨andare med en hemmapp f¨or respek-tive anv¨andare d¨ar de endast fick tillg˚ang till den egna hemmappen. En switch imple-menterades f¨or att kunna f¨ormedla trafiken mellan ¨andnoderna. I syfte att ge systemet en s¨akerhetsh¨ojande funktion implementerades en IPS. Denna uppr¨attades transparent mel-lan klient och switch f¨or att trafiken som skickades fr˚an klienten till servern skulle passera igenom enheten, se.
7.2.3 Uppr¨attandet av IPS
IPS:en konfigurerades som tidigare specificerat mellan slutanv¨andaren/kontoret och swit-chen vilket tvingade trafiken genom enheten. F¨or att ge Snort m¨ojlighet att analysera den specifika trafiken utan n˚agon inverkan av de tidigare specificerade signaturerna togs de ur bruk f¨or att eliminera den felk¨allan. En enklare signatur skapades f¨or att belysa IPS:ens p˚averkan p˚a ett IT-system, se tabell 3 f¨or en ¨oversiktsbild ¨over IPS:ens default˚atg¨arder.
Tabell 2: Signaturens default ˚atg¨arder
Alert Alert-parametern instruerar Snort att alarmera och logga de specifika paketfl¨odena med den efters¨okta in-formationen.
Log Loggar paketet.
Pass Sl¨apper igenom paketet.
Activate Larmar och k¨or ytterligare en dynamisk regel. Dynamic Ligger latent och v¨antar p˚a att aktiveras av activate. Drop Kastar paketet och loggar det.
Reject Droppar, loggar och och skickar ett paket f¨or att ˚aterst¨alla TCP-sessionen
Sdrop Kastar endast paketet utan att logga n˚agon informa-tion om ˚atg¨arden.
Signaturen skapades genom att inledningsvis analysera trafikfl¨odets uppbyggnad f¨or att kunna utl¨asa vilka parametrar signaturen skulle efters¨oka. Signaturen skapades i enlighet med figur 15 och 16.
Figur 15: ¨Oversikt signatur
Figur 16: Signaturens upps¨attning
Signaturen som anv¨andes var sammansatt av en rad parametrar och variabler som har-moniserades enligt tabell 4.
Tabell 3: Signaturens upps¨attning
Alert Alert-parametern instruerar Snort att alarmera och logga de spe-cifika paketfl¨odena med den efters¨okta informationen.
TCP Specificerar vilket eller vilka protokoll som ¨ar av intresse.
Variabel (HOMENET) En variabel som h˚aller det lokala n¨atverket, detta f¨or att snabbt kunna delge Snort vilket/vilka n¨atverk som ska s¨akras upp. Port (Alla eller specifika
por-tar)
Specificerar vilka portar ofta protokollspecifika, som ska analyse-ras.
− > (<>, < −) Riktningstecknen klarg¨or vilken riktning som ¨ar intressant. MSG (Message) Specificerar vilket meddelande som ska visas i loggarna n¨ar en
h¨andelse intr¨affar.
Content Specificerar vilken nyttodata som efters¨oks.
Nocase Funktion som g¨or det m¨ojligt f¨or IPS:en att f˚anga alla kombinatio-ner av den efters¨okta str¨angen (Stor och liten bokstav behandlas lika).
SID Ett ID f¨or den skapade regeln.
7.3 Funktion
Det lokala n¨atverket byggdes upp med statisk adressering i adresspannet 192.168.1.0/24. Med detta menas att p˚a b˚ade server och klient applicerades IP-adressen manuellt. Vida-re implementerades IPS:en transpaVida-rent mellan klient/kontor och switch. F¨or att uppn˚a transparens skapades en brygga mellan tv˚a interface p˚a maskinen utan adress. F¨or att detta ska vara m¨ojligt installeras f¨orst bridge-utils p˚a maskinen, se tabell 5 f¨or konfigura-tionsexempel i uppr¨attandet av n¨atverksbrygga i linux.
Tabell 4: Uppr¨attandet av n¨atverksbrygga
brctl addbr br0 Kommando f¨or att uppr¨atta en brygga vid namn br0.
brctl addif br0 eth0 eth1 Specificerar vilka interface som ska vara en del av bryggan, i detta fall ska eth0 .
brctl stp br0 on/off Sl˚a p˚a eller sl˚a av STP p˚a bryggan.
V¨al implementerat kunde Snort k¨oras, detta med hj¨alp av kommandot nedan samt se tabell 6 f¨or en mer detaljerad bild av vad de olika parametrarna tillf¨or:
snort -A console -c /etc/snort/snort.conf -i eth0:eth1
Tabell 5: Snort parametrar
Snort Startar mjukvaran
-A console Specificerar att alerts skrivs ut i konsolen d¨ar mjukvaran initierats. -c /etc/snort/snort.conf Specificerar vilken konfigurationsfil som Snort ska k¨oras ifr˚an -i eth0:eth1 Specificerar vilka interface som ing˚ar i bryggan.
7.3.1 Scenario 2 brandv¨agg
Det teoretiska genomf¨orandet grundade sig i att bygga upp ytterligare barri¨arer som en form av s¨akerhetsh¨ojande ˚atg¨ard i IT-systemet. I detta fall valdes en brandv¨agg som even-tuell ˚atg¨ard. Grundid´en i detta scenario var att placera en brandv¨agg i anslutning till respektive kontor genom att segmentera brandv¨aggen till kontoren p˚a portbasis f¨or att nyttja hela resursspektrumet i brandv¨aggen ist¨allet f¨or att implementera en brandv¨agg f¨or respektive n¨atverkssegment.
Brandv¨aggen placeras i anslutning till respektive kontor i syfte att segmentera samt tillf¨ora autentisering och en form av auktorisation av r¨attigheterna f¨or respektive kon-tor/anv¨andare, detta i symbios med katalogtj¨ansten. Brandv¨aggen konfigureras med re-gister h¨amtade fr˚an AD f¨or att kunna kontrollera och godk¨anna f¨orfr˚agningar som ska vidare till eller kommer ifr˚an servern. Brandv¨aggen placeras transparent i trafikfl¨odet ut fr˚an ett visst n¨atverkssegment och konfigureras med en egen upps¨attning regler f¨or de konton som innefattas i organisationen. Genom att konfigurera de enligt ovanst˚aende krite-rier uppr¨attas en typ av utbyggd autentisering d¨ar brandv¨aggen ger tillg˚ang till n¨atverket och brandv¨aggen i symbios med AD ger anv¨andarna beh¨orighet till de avsedda resur-serna baserat p˚a anv¨andarnas beh¨orighetsprinciper, se figur 14 f¨or en ¨oversiktsbild ¨over brandv¨aggsfallet.
Figur 17: ¨Oversiktsbild f¨or scenario 2: Brandv¨agg
8
Resultat
Experimentet som utf¨ordes i de simuleringar med IPS:en som huvudkomponent gav i slut-skedet ett positivt resultat i det att det t¨ankta resultatet till viss del uppn˚addes. I testerna som utf¨ordes analyserades m¨ojligheten att uppt¨acka och blockera specifik trafik avsedd f¨or resurser som anv¨andaren inte hade tillg˚ang till utan f˚att det genom att servern svarat fel p˚a en f¨orfr˚agan. Trafiken matchades mot en signatur som efters¨okte en specifik parame-ter, denna var |A|00|r|00|b|00|e|00|t|00|e| (Arbete) som var en hemmapp skapad i testsyfte.
I testerna som utf¨ordes skickades f¨orfr˚agningar fr˚an en anv¨andare till resursen Arbete som anv¨andaren i praktiken inte skulle vara beh¨orig till. F¨orfr˚agningarna mellan klient och server f˚angades upp och alarmerade i Snort. I figur 18 g˚ar det att utl¨asa bland annat meddelandet som genereras vid ett eventuellt ¨overtramp samt mellan vilka enheter och vilka portar som anv¨ants. Port 445 ¨ar standardporten f¨or SMB-f¨orfr˚agningar som klient och server anv¨ander n¨ar klienten inh¨amtar information ur mappstrukturen.
Figur 18 f¨orevisar hur IPS:en betedde sig n¨ar filer skapades i mappen. I den h¨ogra de-len av bilden skapas filerna i mappen arbete p˚a en virtuell Windows 7 klient. Den v¨anstra delen av bilden f¨orevisar att IPS:en alarmerar vid skapandet av filerna, se ¨aven figur 19 f¨or en mer h¨oguppl¨ost bild ¨over utslagen i IPS:en.
Figur 18: Utslag p˚a beh¨orighets¨overtr¨adelse
Figur 19: Utslag p˚a beh¨orighets¨overtr¨adelse IPS
8.1 IT-systemets utformning
I och med experimentets utfall kunde fr˚agan om hur en IT-milj¨o kan utformas f¨or att skyd-da beh¨orighetsprinciperna besvaras. Genom att inledningsvis uppr¨atta ett robust n¨atverk och en logisk struktur i katalogtj¨ansten med tydliga beh¨origheter per anv¨andare samt f¨or grupper av anv¨andare kan det externa s¨akerhetsarbetet p˚ab¨orjas d¨ar IPS:en imple-menteras. IPS:en implementeras f¨orslagsvis i trafikfl¨odenas riktning och i inline-l¨aget f¨or att m¨ojligg¨ora optimala funktionsf¨orh˚allanden som ¨ar bland annat m¨ojligheten att styra ˚atg¨arderna till att blockera, till˚ata och alarmera de efters¨okta paketfl¨odena.
Beroende p˚a hur n¨atverket ser ut d¨ar IPS:en ska implementeras kr¨avs d¨arf¨or ett gediget f¨orarbete och planering kring hur milj¨on ser ut vilka som ska f˚a tillg˚ang till respektive resurs, hur signaturerna ska skrivas f¨or att g¨ora dem tillr¨ackligt inkluderande f¨or att ef-fektivt kunna analysera och ˚atg¨arda anomalierna i paketfl¨odena. Genom att implementera en s˚adan l¨osning kan vi effektivt bygga upp ytterligare en barri¨ar f¨or att motverka att katalogtj¨ansten svarar fel p˚a en f¨orfr˚agan.
8.2 S¨akerst¨allandet av s¨akerhets˚atg¨arden
Genom att implementera en s¨akerhets˚atg¨ard som kontrollerar beh¨origheterna fr˚an och till servern har vi effektivt byggt upp ytterligare en barri¨ar i systemet. Detta medf¨or att tv˚a av varandra oberoende skydds˚atg¨arder, vilka ¨ar skyddet som IPS:en tillf¨or samt katalog-tj¨anstens egna kontroller p˚a beh¨origheterna, ¨ar implementerade. Med de tv˚a ˚atg¨arderna mildras effekten av att katalogtj¨ansten svarar fel p˚a en f¨orfr˚agan. Om ett felsvar l¨amnar servern kommer det f˚angas upp i IPS:en som i sin tur utf¨or en f¨ordefinierad ˚atg¨ard. Om det tv¨artom ¨ar IPS:en som sl¨apper igenom ett fel kommer katalogtj¨ansten neka f¨orfr˚agan och p˚a s˚a s¨att kan systemet anses s¨akrare i det att b˚ada skyddsmekanismerna m˚aste fallera samtidigt f¨or att ett felsvar realiseras och p˚averka systemet som helhet.
8.3 Teoretiska scenariot
Det visade sig efter att ha unders¨okt funktionaliteten i brandv¨aggar med ¨oppen k¨allkod att st¨odet f¨or uppr¨attandet av en likv¨ardig enhet med den efters¨okta typen av funktio-nalitet inte fanns. De implementationer som var av intresse i arbetet var bland annat att installera en eller flera proxy brandv¨aggar d˚a den typen av brandv¨agg skiljer sig fr˚an m¨angden i det att till skillnad fr˚an exempelvis en Packet Filtering Firewall och Packet-inspection Firewall g¨or det m¨ojligt att initiera ett fl¨ode till brandv¨aggen som i sin tur initierar fl¨odet till den avsedda servern och rel¨aar informationen tillbaka till anv¨andaren. Detta hade i teorin gjort det m¨ojligt att utf¨ora autentisering- och auktoriseringskontroller p˚a fl¨odet i brandv¨aggen. Proxy brandv¨aggen var t¨ankt att konfigureras inline f¨or att seg-mentera upp kontoren, inneha autentiseringsuppgifter och husera anv¨andarnas r¨attigheter.
Uppr¨attandet av en s˚adan l¨osning hade gett systemet en form av autentisering samt auk-torisation vilken i teorin ¨ar en v¨aldigt intressant tanke i det att IPS-funktionalitet, auten-tisering och auktorisation samlas p˚a ett centraliserat eller distribuerat brandv¨aggssystem. Anv¨andaren hade i praktiken beh¨ovt autentisera sig mot katalogtj¨ansten samt att dennes beh¨origheter ¨aven kontrollerades p˚a nytt. V¨al autentiserad var tanken att b˚ade brandv¨aggen och katalogtj¨ansten ¨overvakar anv¨andarens f¨orfr˚agningar till de specifika resurserna. Om detta experimentet och den efters¨okta funktionalitet hade g˚att i l˚as skulle den efters¨okta barri¨aren kunna uppr¨attas och katalogtj¨anstens skydd hade varit mer robust. Till detta kan ¨aven RADIUS implementeras f¨or att motverka att en anv¨andare lyckas logga in i AD och nyttja n¨atverket utan att ha beh¨orighet till det.
9
Diskussion
Arbetet grundade sig i att ut¨oka katalogtj¨anstens skydd. Detta genom att med s¨ akerhets-h¨ojande ˚atg¨arder bygga upp en barri¨ar mot eventuella felsvar fr˚an en server. Som specifice-rat under resultatet visades utslag p˚a den efters¨okta trafiken vilket ger en stark indikation p˚a att en IPS absolut kan vara av v¨arde i att s¨akra upp ˚atkomstbeh¨origheterna i ett IT-system. Med experimenten som grund kan det ¨aven utl¨asas att genom implementatio-nen av en IPS skapas ytterligare ett skydd ut¨over katalogtj¨anstens egna kontroller och p˚a s˚a vis kr¨avs det att b˚ade IPS:en och katalogtj¨ansten samtidigt ska missf¨orst˚a en fr˚aga och godk¨anna en anv¨andare som inte ¨ar beh¨orig f¨or att ˚atkomstprinciperna ska brytas helt. Genom att ha uppn˚att ovanst˚aende har ¨aven fr˚agest¨allningen besvarats i det att om IT-milj¨on utformas med IPS kan vi bygga upp ett extra skydd f¨or ˚atkomstprinciperna samt s¨akerst¨alla och p˚avisa att dessa h˚aller det som lovats s˚a l¨ange inte b˚ada ˚atg¨ardernas funktionalitet bryts samtidigt, i ett s˚adant fall hade felsvaren realiserats trots de imple-menterade ˚atg¨arderna.
I experimentet som utf¨ordes visade det sig att de uppr¨attade signaturerna kan hitta och agera p˚a trafikfl¨oden hemmah¨orande i katalogtj¨ansten. D¨aremot kan dessa inte anses de-finitiva i det att experimentet modifierades d˚a problem uppstod i hur Snort betedde sig i inline-l¨aget. Beteendet som uppvisades var inte tillfredsst¨allande och st¨allde till med problem i hela milj¨ons funktionalitet. Det lokala n¨atverket fick en oregelbunden kontakt mellan enheterna som implementerades p˚a respektive sida av IPS:en. Genom att unders¨oka problematiken med hj¨alp av bland annat Wireshark gick det att utl¨asa att vissa paket som f¨ardades med samma protokoll gick igenom enheten medan andra inte gjorde det. Under analysen av beteendet kopplades alla f¨ordefinierade och egenskapade signaturer bort f¨or att utesluta signaturernas p˚averkan, detta med samma resultat som tidigare specificerat, vilket var att kontakten mellan enheterna fortfarande var oregelbunden. Detta tvingade scenariot att struktureras om n˚agot i det att IPS:en inte konfigurerades funktionsm¨assigt i inline-l¨aget. D¨aremot implementerades den inline i milj¨on och l¨at trafiken fl¨oda och av den anledningen kunde inte heller paketen behandlas med parametrar som att blockera och kasta trafik d˚a dessa endast ¨ar tillg¨angliga i inline-l¨aget. Alarm-funktionen kunde dock anv¨andas ist¨allet f¨or att p˚avisa vikten av en v¨alkonfigurerad IPS. Detta var en tyd-lig begr¨ansning i experimentfasen men det gav inte upphov till att f¨orkasta resultatet d˚a efters¨okt utslag gjorde sig synligt.
Vidare skapades endast en enklare signatur vilken bara efters¨okte f¨orfr˚agningar till den specifika mappen Arbete i trafikfl¨odet. Denna signatur fungerade bra f¨or att p˚avisa effekten men f¨or att implementera en liknande l¨osning i en produktionsmilj¨o kr¨avs st¨orre eftertanke i skapandet av signaturerna. De kan d˚a beh¨ova vara n˚agot mer inkluderande av anv¨andare, beh¨orighetsprinciper samt vilken typ av trafik som efters¨oks. Signaturen skapades medve-tet i det statiska genomf¨orandet f¨or att f¨orevisa den s¨akerhetsh¨ojande funktionen men det medf¨or ¨aven att den begr¨ansas d˚a den inte ¨ar redo f¨or att s¨attas i bruk i sin nuvarande form utan beh¨over mer eftertanke och modifikation f¨or det specifika scenariot den ska implementeras i.
IPS:en och signaturerna matchar till viss del baserat p˚a IP-adresser vilket medf¨or att det kan bli sv˚art att h˚alla signaturerna uppdaterade med de specifika adresserna som delas ut med hj¨alp av DHCP d˚a dessa ¨over tid f¨or¨andras kontinuerligt. Ytterligare en begr¨ansning som visade sig, var att det kan vara sv˚art att h˚alla is¨ar anv¨andare beroende p˚a hur milj¨on
ser ut samt hur klienter hanteras i IT-milj¨on. Detta om flera anv¨andare nyttjar samma enhet, vilket medf¨or att de ”nya” anv¨andarna som nyttjar h˚ardvaran kan ¨overta tidigare anv¨andares IP-adress. Detta hade d˚a genererat en false positive, vilket syftar till att en beh¨orig anv¨andare blir begr¨ansad ˚atkomst till en viss resurs. Genom att i symbios med servens riktlinjer p˚a hur IP-adresser delas ut till respektive anv¨andare, hur dess regler ser ut och god insyn i IT-milj¨on kan denna problematik i teorin motverkas.
En rekommendation om en IPS-l¨osning ska anv¨andas ¨ar att styra signaturerna baserat p˚a olika n¨atverkssegment ist¨allet f¨or per adress d˚a dessa f¨or¨andras ¨over tid. Med andra ord de olika adresspann som delas ut av DHCP som exempelvis guppen Ekonomi med ett definierat och statiskt adresspann konfigureras med specifika resurser och baserat p˚a r¨attigheterna och adresspannet uppr¨attar man en eller flera signaturer f¨or att s¨akerst¨alla att n¨atverkssegmentet inte f˚ar tillg˚ang till resursen om detta inte ¨ar ¨onskv¨art. Beroen-de p˚a var IPS:en implementeras kr¨avs det olika dimensionerad h˚ardvara d¨ar det i vissa fall kan r¨acka med att uppr¨atta en Raspberry Pi med Snort och i andra fall kan det kr¨avas enterprise-serverh˚ardvara, detta f¨or att IPS:en ska kunna analysera trafikfl¨oden och ˚atg¨arda dessa d¨ar behovet finns effektivt.
F¨or att kunna skapa en bra signatur kr¨avs ¨aven god insyn i systemet d¨ar denna ska imple-menteras, bland annat i vilka tj¨anster som anv¨ands, vilken trafik som fl¨odar samt god insyn i katalogtj¨ansten och beh¨origheterna. Vidare g¨aller ¨aven att informationen s¨akerhetsklassas f¨or att g¨ora det tydligt i vad som f¨orv¨antas skyddas.
Experimentet med brandv¨aggen visade sig vara ogenomf¨orbart p˚a grund av att st¨od f¨or den efters¨okta funktionaliteten inte var m¨ojlig att f˚a i de mjukvarorna med ¨oppen k¨allkod som kontrollerades. Varken pfSense eller Sophos hade n˚agot uttalat st¨od f¨or att kunna autentisera och auktorisera anv¨andarna mot katalogtj¨ansten enligt den t¨ankta metoden. Om m¨ojligheten fanns att kunna implementera brandv¨aggsregler, IPS-funktionalitet, au-tentisering och auktorisation av anv¨andare i en och samma enhet hade det medf¨ort att en mer komplett och robust s¨akerhetsh¨ojande ˚atg¨ard hade kunnat implementeras.
10
Slutsatser
Med fr˚agest¨allningarna som grund i arbetet var f¨orhoppningen att hitta metoder som gjor-de gjor-det m¨ojligt att mildra och/eller f¨orhindra en hypotetisk s˚arbarhet vilken var att servrar med katalogtj¨anster eventuellt svarar fel p˚a f¨orfr˚agningar och ger obeh¨origa anv¨andare el-ler organisationer tillg˚ang till resurser som de inte ¨ar beh¨origa till.
Vidare unders¨oktes det om en IPS kunde mildra och/eller motverka felsvar vilket visa-de sig vara m¨ojligt. Detta uppn˚addes genom att kontrollera trafikfl¨oden fr˚an olika k¨allor och analysera paketen f¨or att baserat p˚a upps¨attningen regler kunna ˚atg¨arda de eventuella beh¨orighets¨overtr¨adelserna. D¨aremot resulterade inte arbetet i en definitiv signatur som passar alla IT-milj¨oer utan p˚avisar funktionaliteten, vidare kr¨avs d¨arf¨or att signaturerna skapas i syfte att n˚a den avsedda IT-milj¨ons krav.
Grundid´en var att med hj¨alp av s¨akerhetsh¨ojande ˚atg¨arder bygga upp ytterligare bar-ri¨arer av skydd ut¨over serverns egna. En brandv¨agg var ¨aven t¨ankt att agera barri¨ar i IT-systemet men det visade sig att det inte fanns st¨od f¨or funktionalitet som bland annat autentisering och auktorisering av anv¨andare. IPS:en byggde effektivt upp ytterligare en
barri¨ar ut¨over katalogtj¨anstens egna s¨akerhet vilket gav den efters¨okta funktionaliteten. P˚a grund av att b˚ade IPS:en och katalogtj¨ansten samtidigt m˚aste ta fel p˚a f¨orfr˚agningarna f¨or att ett felsvar faktiskt ska realiseras kan vi baserat p˚a detta p˚avisa ˚atg¨ardens signifikans sett till s¨akerheten.
11
Framtida arbete
Vid framtida arbeten kring fr˚agan om ˚atkomstprinciper kan brytas p˚a grund av fel i servrars svar p˚a f¨orfr˚agor till specifika resurser kr¨avs ett gediget arbete kring signaturernas utformning baserat p˚a vilka IT-milj¨oer dessa ska implementeras i. Det b¨or ¨aven efterstr¨avas att uppn˚a ett stadie p˚a hur IPS:en behandlar f¨or¨andringar i n¨atverk och beh¨origheterna p˚a ett strukturerat s¨att. Vidare b¨or det ¨aven unders¨okas om det ¨ar m¨ojligt att med hj¨alp av dynamiska signaturer som skapas i symbios med Active Directory kan styra anv¨ andar-och beh¨orighetsregister. F¨or att kunna implementera brandv¨aggen i det genomf¨orande som beskrivs i arbetet kr¨avs f¨orst och fr¨amst st¨od f¨or funktionaliteten d¨arefter kan id´en utvecklas vidare samt praktiskt implementeras.
Referenser
[1] R. Blair and A. Durai, “Chapter 1: Types of firewalls,” [Online]. Available: https: //www.networkworld.com/article/2255950/lan-wan/chapter-1--types-of-firewalls. html?page=2, Date last accessed on 2018-04-23.
[2] Myndigheten f¨or samh¨allsskydd och beredskap (MSB), V¨agledning – in-formationss¨akerhet i upphandling. MSB, April,2013. [Online]. Available:
https://www.msb.se/RibData/Filer/pdf/26589.pdf
[3] F¨orsvarsmakten, “Ksf:krav p˚a it-s¨akerhetsf¨orm˚agor hos it-system,” [Online]. Availab-le: http://isd.fmv.se/Documents/krav-pa-godkanda-sakerhetsfunktioner-version-3-1. pdf, Date last accessed on 2018-03-06.
[4] Z. Rosander, S. Styrenius och A. Wiklund, S¨akerhetskrav p˚a IT - system som ¨ar avsed-da f¨or behandling av personuppgifter. F¨orsvarsmakten, 2013 - 06 -26. [Online]. Avai-lable:http://isd.fmv.se/Documents/HKV%202013-06-26%2010%20750.59802%20S% c3%a4kerhetskrav%20IT-system%20avsedda%20f%c3%b6r%20personuppgifter.pdf
[5] W. Panek and J. Chellis, MCTS Windows Server 2008 Active Directory Configuration Study Guide: Exam 70-640. Wiley, 2012.
[6] B. Desmond, J. Richards,R. Allen and A.G. Lowe-Norris, Active Directory: Designing, Deploying, and Running Active Directory. O’Reilly Media, 2013.
[7] D. Stiawan, M. Yazid Bin Idris, A. Hanan Abdullah, M. AlQurashi and R. Budiarto, “Penetration testing and mitigation of vulnerabilities windows server,” I. J. Network Security, vol. 18, no. 3, pp. 501–513, 2016.
[8] P. Tsai, “Server virtualization and os trends,” [Online]. Available:https://community. spiceworks.com/networking/articles/2462-server-virtualization-and-os-trends, Date last accessed on 2018-01-29.
[9] C. Metz, “Aaa protocols: authentication, authorization, and accounting for the inter-net,” IEEE Internet Computing, vol. 3, no. 6, pp. 75–79, Nov 1999.
[10] C. Rigney, S. Willens Livingston, A. Rubens Merit and W. Simpson Daydreamer, “Remote Authentication Dial In User Service (RADIUS),” Internet Requests for Comments, RFC Editor, RFC 2818, June 2000. [Online]. Available:
http://www.rfc-editor.org/rfc/rfc2865.txt
[11] S. Geri´c and ˇZ Hutinski, “Information system security threats classifications,” Journal of Information and organizational sciences, vol. 31, no. 1, pp. 51–61, 2007.
[12] D. Piscitello, “Threats, vulnerabilities and exploits – oh my!” [Online]. Available:
https://www.icann.org/news/blog/threats-vulnerabilities-and-exploits-oh-my, Date last accessed on 2018-02-26.
[13] M. E. Whitman, “Enemy at the gate: threats to information security,” Communica-tions of the ACM, vol. 46, no. 8, pp. 91–95, 2003.
[14] D. Kamal, M. Bassil and T. Ahmad Bisher, “A survey of risks, threats and vulnerabilities in cloud computing,” in Proceedings of the 2011 International Conference on Intelligent Semantic Web-Services and Applications, ser. ISWSA
’11. New York, NY, USA: ACM, 2011, pp. 12:1–12:6. [Online]. Available:
http://doi.acm.org/10.1145/1980822.1980834
[15] J. Stamp, A. McIntyre and B. Ricardson, “Reliability impacts from cyber attack on electric power systems,” in Power Systems Conference and Exposition, 2009. PSCE’09. IEEE/PES. IEEE, 2009, pp. 1–8.
[16] M. Portnoy, Virtualization essentials. John Wiley & Sons, 2012, vol. 19.
[17] R. Birke, A. Podzimek, L. Y. Chen and E. Smirni, “State-of-the-practice in data center virtualization: Toward a better understanding of vm usage,” in 2013 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), June 2013, pp. 1–12.
[18] Oracle, “Virtualbox manual ch01,” [Online]. Available:https://www.wireshark.org/ about.html, Date last accessed on 2017-04-10.
[19] D. Bombal and J. Duponchelle, “Getting started with gns3,” [Online]. Available:
https://docs.gns3.com/1PvtRW5eAb8RJZ11maEYD9 aLY8kkdhgaMB0wPCz8a38/ index.html, Date last accessed on 2018-02-26.
[20] J. C. Neumann, The Book of GNS3: Build Virtual Network Labs Using Cisco, Juniper, and More. No Starch Press, 2015.
[21] L. Chappell and G. Combs, Wireshark network analysis: the official Wireshark certi-fied network analyst study guide. Protocol Analysis Institute, Chappell University, 2010.
[22] A. Abdelkarim and H. Nasereddin, “Intrusion prevention system,” vol. 3, pp. 432–434, 01 2011.
[23] Palo Alto, “What is an intrusion prevention system?: Intrusion prevention and detection system basics,” [Online]. Available: https://www.paloaltonetworks.com/ cyberpedia/what-is-an-intrusion-prevention-system-ips, Date last accessed on 2018-03-16.
[24] D. Burns, O. Adesina and K. Barker, CCNP security IPS 642-627 official cert guide. Cisco Press, 2011.
[25] S. Jain, A. Vaibhav and L. Goyal, “Raspberry pi based interactive home automation system through e-mail,” in 2014 International Conference on Reliability Optimization and Information Technology (ICROIT), Feb 2014, pp. 277–280.
[26] M. R. DeLong, A. Ingham, R. Carter, R. Franke, M. Wehrle, R. Biever, and C. Kneifel, “Protecting sensitive research data and meeting researchers needs: Duke university’s protected network,” 1710.03317, 2017.
[27] C. H. Hsieh, C. M. Lai, C. H. Mao, T. C. Kao and K. C. Lee, “Ad2: Anomaly detection on active directory log data for insider threat monitoring,” in 2015 International Carnahan Conference on Security Technology (ICCST), Sept 2015, pp. 287–292.
[28] D. Chadwick, “Threat modelling for active directory,” in Communications and Mul-timedia Security. Springer, 2005, pp. 173–182.
[29] W. Claycomb and D. Shin, “Protecting sensitive information in directory services using virtual directories,” in International Conference on Collaborative Computing: Networking, Applications and Worksharing. Springer, 2008, pp. 244–257.
[30] The Snort Team, “Snortusers manual 2.9.11,” [Online]. Available: http:// manual-snort-org.s3-website-us-east-1.amazonaws.com/node1.html, Date last acces-sed on 2018-05-15.