EXAMENSARBETE. Nätverksanalys och separation av VLAN. Examensarbete på Atea Skellefteå. Henrik Grafström. Högskoleexamen Datornätverk

EXAMENSARBETE Nätverksanalys och separation av VLAN Examensarbete på Atea Skellefteå Henrik Grafström Högskoleexamen Datornätverk Luleå tekniska universitet Institutionen för system- och rymdteknik

Examensjobb vid Atea Skelleftea Nätverksanalys och separation av VLAN i föreningen Skellefteå AIKs nätverk Skrivet av: Henrik Grafström Datornätverk LTU

Abstract This report describes my thesis at Atea in Skellefteå. My mission was to familiarize myself with Skellefteå AIK's network and make some improvements such as to separate the cash register system of Skellefteå Kraft Arena into a separate VLAN. They have previously been problems with the function of the cash register system so my work would lead to greater security and a more reliable system. I created a separate VLAN to the cash register system with a separate pool of IP addresses and dynamic address assignment. In this report I describe how the network was constructed and what changes I made to perform my mission. Sammanfattning Denna rapport beskriver mitt examensarbete på Atea i Skellefteå. Mitt uppdrag var att sätta mig in i Skellefteå AIKs nätverk och göra en del förbättringar som t.ex. att separera kassasystemet på Skellefteå Kraft Arena till ett eget VLAN. De har tidigare varit problem med kassornas funktion så mitt arbete skulle leda till större säkerhet och ett pålitligare kassasystem. Jag skapade ett eget VLAN till kassasystemet med en separat pool av IP adresser och dynamisk adresstilldelning. I rapporten beskriver jag hur nätverket var uppbyggt och vilka förändringar som jag gjort för att utföra mitt uppdrag.

Innehållsförteckning 1. Inledning... 1 1.1 Syfte... 1 1.2 Metod... 1 2. Genomförandet... 3 2.1 Dokumentation... 3 2.2 Duplex och hastighet... 4 2.3 Skapande av VLAN... 4 2.4 Dynamisk IP adress tilldelning... 4 2.5 Trunk/ router on a stick implementation... 5 2.6 Migration av kassor... 7 2.7 Access... 8 3. Resultat... 8 4. Diskussion... 9 Bilaga 1. Cisco ASA Bilaga 2. Referenser till Bilaga 1

1. Inledning 1.1 Syfte Föreningen Skellefteå AIK som är en kund till Atea har haft problem med kassasystemen på Skellefteå Kraft Arena. Kassorna har varit av olika årsmodell både mjuk och hårdvarumässigt och har varit instabila och inte tillförlitliga. Atea har hjälpt Skellefteå AIK och leverantören av kassasystemen att hålla igång driften på kassorna och de har då upptäckt vissa brister och behov av förändringar för att få ett stabilare system. Lokalisering och lösning på det här problemet har skett i olika steg och några delar har redan åtgärdats. Alla kassor har tidigare uppdaterats till senaste mjukvaran, kassorna har märkts upp och namngets utifrån en gemensam namnstandard. Alla switchportar som haft statiskt ställd duplex har blivit ställda i automatiskt läge. Det har även installerats ett nytt antivirusprogram. Under hockeysäsongen så har Atea haft en genomgång av systemen innan varje match för att säkerställa att alla kassor är igång och fungerar. 1.2 Metod Mitt uppdrag var att sätta mig in i nätverksuppbyggnaden och konfigurationen för att se om det finns behov av utbyggnad eller ändringar. Jag skulle skapa ett eget VLAN för kassasystemet hos AIK/Rinkside med en egen DHCP för dynamisk tilldelning av IP adresser. Det fanns även önskemål om att det skulle skapas en dokumentation över switch och switchportanvändning som jag valde att göra i Microsoft Exel. Frågor jag ställde mig och sökte svar på i förarbetet var bland annat: Vilken åtkomst och vilka säkerhetsregler behövs? Vad behöver nya kassanätet tillgång till för andra nät? Behöver datorerna på administrationen åtkomst till kassorna? Hur vill de att DHCP skall implementeras? Skall den sättas upp i Cisco routern eller har de en separat DHCP server? Skall default-gateway delas ut med DHCP eller skall det sättas upp statiskt i kassorna? Vilka IP adresser skall användas till det nya VLAN:et och hur många IP adresser behövs? Namnstandard på VLAN? Hur skall VLAN:et trunkas? Två separata linor eller göra om befintliga linan till en trunk och skapa subinterface för VLAN:en på den ( router on a stick )? Ett problem jag kände med uppgiften var att det inte gick att laborera och testa i hårdvaran. Det är ett nät i drift där kontoret är bemannat dagtid och även servrar och 1

system finns som behöver nätåtkomst. Det var därför viktigt för mig att planera ordentligt innan implementering av mina ändringar. Jag ville minimera tiden för driftavbrottet så jag samlade information om vad som skulle göras. Genomförandet planerades och delades upp så att det kunde göras vid några i förväg planerade tillfällen där Skellefteå AIK fick välja tidpunkt. Utrustningen jag hade till förfogande var en Lenovo 15 bärbar dator. Jag fick Inloggningsuppgifter till all hårdvara på arenan, användarnamn och lösenord för att kunna ansluta via telnet, SSH eller Remote desktop till Skellefteå AIKs servrar som finns i Ateas Drifthall. Figur 1 visar en topologi vy över nätverket på Skellefteå Kraft Arena. Skellefteå AIK Drifthall CA01 Teknikrum ATEA.239 Vakmästeri U-Hall HU01 SkekraftArena-HU01- sw1 INTERNET Alltele Pressläktare Statestiknät Alltele IPtel Alltele Trådlöst Cisco 1812 VLAN 486 G0/2 Vlan 200 F0/18 Vlan 467 F0/12 Vlan 201??? Vlan 202??? SkekraftArena-CA01-sw1.230 SkekraftArena-CA01-sw2.231 SkekraftArena-CA01-sw3.232 SkekraftArena-CB01- sw1.233.236.234 SkekraftArena-AB01- sw1.237.235 Elnisch korridor kontor, plan3 CB01 SkekraftArena-CB01- sw2 Elrum BV AB01 SkekraftArena-AB01- sw2 Elnisch Pl3, Loger CC01 SkekraftArena-CC01- sw1 Ställverk AA01.238 SkekraftArena-AA01- sw1 Figur 1. Topologisk vy över nätverket på Skellefteå kraft arena. 2

2. Genomförandet Mitt huvudsakliga uppdrag var att skapa ett eget VLAN (virtuellt lokalt nätverk) för kassasystemet på Skellefteå Kraft Arena och flytta över alla befintliga kassor till det nya VLAN:et. IP adresser till kassanätet skall tilldelas dynamiskt. En dokumentation över switchar, router och portanvändning skulle upprättas. Jag skulle även gå igenom befintlig konfiguration i hårdvaran för att se att sådant som skall vara åtgärdat enligt tidigare uppdrag blivit gjort och om jag kunde komma med ytterligare förslag på förbättringar. Jag började mitt uppdrag med att läsa igenom och sätta mig in i dokumentationen och nätverkstopologin över Skellefteå Kraft Arena. Jag fick tillgång till avtalet mellan Atea och Skellefteå AIK och dokumentation över tidigare arbeten och projekt på arenan. I nätverket så finns det 10st Cisco switchar och en Cisco 1812 router. 3 switchar var av modell C2960-24TT och 7st var av modell C2950-24. Från Skellefteå Kraft Arena så har Skellefteå AIK ett eget VLAN i en fiberlänk som ansluter mot Ateas drifthall. I drifthallen så finns en Core router och en ASA brandvägg. Core Routern och ASA brandväggen har även en backup hårdvara (failover) för att säkra driften. Konfigurationen har hämtats ut ifrån hårdvaran och sparats i ett textdokument för att enkelt kommas åt utan att behöva upprätta en telnet anslutning varje gång jag behövde få åtkomst till informationen. I konfigurationen så finns det flera VLAN för olika aktörer på arenan som t.ex. Ticnet, Dream Team statistik, Alltele pressläktare, Alltele IP telefoni och Alltele trådlöst. Det VLAN som Skellefteå AIK använder för sin trafik är VLAN 486 vilket är ett punkt till punkt VLAN som hyrs som en tjänst av Skellefteå Kraft. Det innebär att all trafik ifrån Skellefteå kraft arena transporteras på VLAN 486 i Skellefteå krafts fiber till Ateas drifthall. 2.1 Dokumentation Det fanns önskemål ifrån Atea att det skulle skapas en samlad dokumentation över switcharna och portanvändning där det om möjligt framgår när de senast användes. Informationen om portarnas senaste användning är intressant för att se om det finns portar anslutna och patchade till uttag som inte används. Jag skapade ett Exel dokument där jag ifrån switcharna hämtade ut beskrivningen för varje port, vilket VLAN de tillhör, om det är en access eller trunk port och senast det skickades trafik över porten. För att få fram information om senast då porten trafikerades så använde jag kommandot show interfaces i hårdvarans CLI (Command Line Interface). Jag ansåg även att placeringen av hårdvaran var av intresse. Jag skrev in fysisk placering på arenan och i vilket ställ den var monterad i dokumentationen. 3

2.2 Duplex och hastighet I dokumentationen ifrån tidigare möten med Skellefteå AIK och åtgärdsförslag ifrån Atea så framgick bland annat att för att kassasystemet skall fungera optimalt så bör switchportarnas duplex vara i automatiskt läge och inte statiskt ställda i halv eller full duplex. Switchportarnas hastighet bör även den vara i automatiskt läge. Jag kontrollerade med hjälp av kommandot show interfaces status i switcharna att alla portar var i automatiskt duplex läge. Via samma kommando kan man se switchportarnas hastighet och där fanns det några switchar där hastigheten fortfarande var statiskt ställd på 10 Mbts. De portar som tillhörde klient nätet eller där kassor var anslutna ändrade jag till automatisk hastighet. De portar som används av andra aktörer på arenan lämnade jag utan åtgärd. 2.3 Skapande av VLAN En av delarna i uppdraget var att det skall skapas ett eget VLAN för kassasystemen. För att säkra ett stabilt kassanät så är en av delarna att kassornas trafik skall separeras ifrån annan trafik. Jag fick Ateas IP plan för drifthallen till hjälp där det är dokumenterat vilka interna nät som Ateas kunder använde idag eller hade avsatta för eventuellt framtida behov. Atea har lagt upp det så att varje kund initialt har tillgång till 10st klass C nät (/24) och där kunde jag välja ett som skulle användas för dynamisk tilldelning av IP adresser till kassorna. Efter samråd med min handledare valde jag 10.193.27.0 nätet för kassorna och VLAN nr 127. Innan jag skapade det nya VLAN:et så gick jag igenom switcharna för att kolla hur VTP (VLAN Trunking Protocol) statusen var konfigurerad och att alla tillhörde samma VTP domän. VTP är ett Cisco proprietärt protokoll som används för att förenkla hantering av VLAN så att man skapar, namnger eller ändrar i en switch som är satt som VTP server och sedan sprids informationen till alla switchar som är satta som VTP klienter i samma VTP domän. Då jag skapade ett nytt VLAN i VTP servern och namngav det så spreds den registreringen vidare till de andra switcharna som var satta som VTP klienter och det verifierades genom att se att alla VLAN fanns på alla switchar. För att det skall framgå av beskrivningen vad olika VLAN är avsedda för så döptes VLAN 127 till Kassa_AIK/Rinkside då det är kassorna och restaurangen Rinkside som skall tillhöra det VLANet. VLAN 486 döpte jag till SAIK_Client_Net och där skall klientdatorerna finnas. VLAN 486 hade tidigare bara haft VLAN 486 som namn men då det nu finns flera VLAN så döptes det om till ett mer beskrivande namn. 2.4 Dynamisk IP adress tilldelning Kassanätet skall ha dynamisk tilldelning av IP adresser. Skellefteå AIK har bland annat en Windows 2008 server där de har DHCP tjänsten aktiverad. Det lokala IP nät som avsatt till kassorna är 10.193.27.0 /24. Jag skapade ett nytt DHCP scoop (DHCP pool) där IP adresser ifrån 10.193.27.50/24 till 10.193.27.250/24 tilldelas på begäran ifrån kassorna. Jag hade hela /24 nätet att använda men sparade några adresser i början och slutet ifall det eventuellt tillkommer något som behöver statisk adress. I routern så anger man en IP-helper address som gör att DHCP förfrågningar 4

vidarebefordras till DHCP tjänsten som tillhör nätet där förfrågningen kommer ifrån. I DHCP tjänsten så registrerades uppgift på vilket IP VLAN:ets sub-interfacet har och genom det så känner DHCP servern av vilket nät DHCP requesten kommer ifrån och delar ut adresser ifrån det scoopet (DHCP poolen). 2.5 Trunk/ router on a stick implementation I ett lokalt nätverk där det finns flera olika VLAN som skall transporteras på samma medium så konfigurerar man den/de länkarna till trunkläge. De olika VLAN:en kan inte komma åt varandra utan att transporteras via en router och på så sätt kan man enkelt med hjälp av access-listor i routern styra vilka VLAN som skall komma åt varandra eller blockeras. Innan så har all IP trafik ifrån Skellefteå AIK tillhört samma VLAN och det har inte funnits behov av en trunk mellan core switch och router. IP trafiken skall nu separeras och delas upp i olika VLAN och då behöver det skapas en trunk för transport av VLAN trafik däremellan. De alternativ som finns är att antingen sätta upp en ny fysisk trunk lina mellan switchen och routern just för att transportera trafiken för det nya kassanätet eller så kan man skapa sub-interface på den befintliga länken och ställa in så att de olika sub-interfacen transporterar specifik VLAN trafik över samma fysiska länk. I samråd med min handledare på Atea så bestämde vi att det bästa alternativet här var att skapa sub-interface i routern och på så sätt spara portar i hårdvaran och även möjliggöra för ytterligare utbyggnad om det senare behöver tillkomma fler VLAN. Innan jag gjorde om länken ifrån accessport till trunk så dokumenterade jag vad som skulle göras och i vilken ordning för att minimera driftavbrottet och för att visa min handläggare på Atea att jag var klar och förbered. Då jag inte var på plats fysiskt på arenan för att göra ändringarna utan gjorde det via en telnet anslutning så började jag inifrån och arbetade mig utåt i topologin för att inte låsa ut mig själv ifrån nätverket. Trunken skulle upprättas mellan core switchen och routern, jag började med att göra ändringarna i switchen. Såhär gick min konfiguration till efter jag gått in i konfigurationsläge i switchen: Interface gigabitethernet 0/2 Switchport mode trunk Med de kommandona så var länken satt i trunk läge och var redo att transportera VLAN trafik. Vissa Switchar har stöd för flera olika trunking protokoll men den här switchen har endast stöd för dot1q så det blir automatiskt det då porten ändras till trunk. Det skrevs även in beskrivning så att det syns i konfigurationen att det är en trunkport som är ansluten mot Cisco 1812 routern men den informationen lades till i efterhand då det var viktigare att snabbt få upp länken igen. Jag lägger även in att endast VLAN 127 och 486 skall få trunkas (transporteras) där av säkerhetsskäl och för att porten i routern inte skall belastas av broadcast trafik ifrån de andra VLAN:en. Jag anslöt till routern via telnet och där gjordes följande kommandon efter att jag gått in i konfigurationsläge: 5

Interface fastethernet 1 No IP address (IP adressen som varit här skall vara på ett sub-interface för klientnätet nu) Interface fastethernet 1.486 (Punkten följt av ett nummer efter interface ID som i detta fall är 1 betyder att det är ett sub-interface och finns det inte redan så skapas det av kommandot). Encapsulation dot1q 486 (486 är det VLAN id som skall transporteras där) Ip address 192.168.11.1 255.255.255.0 Ip helper-address 10.193.23.51 Description AIK_Client_Net IP-helper är en funktion i routern som gör att DHCP requests (DHCP förfrågningar) vidarebefordras till DHCP servern som i detta fall har IP address 10.193.23.51 Efter jag gjort de här ändringarna så är kommunikationen på arenan uppe igen och alla där har åtkomst till servrarna och internet. Nästa steg var att skapa ett sub-interface i routern för kassanätet och det gjorde jag på följande sätt (även här utgår jag ifrån konfigurationsläge i CLI) : Interface fastethernet 1.127 Encapsulation dot1q 127 (127 är det VLAN id som skall transporteras där) Ip address 10.193.27.1 255.255.255.0 Description KASSA_AIK/Rinkside Efter det här är gjort så är det förberet för att trafik som tillhör kassornas VLAN skall kunna transporteras i trunk linan. Efter konfigurationen av sub-interfacen så ser router konfigurationen ut enligt utklippen nedan. interface FastEthernet1.127 description KASSA_AIK/Rinksside encapsulation dot1q 127 ip address 10.193.27.1 255.255.255.0 ip helper-address 10.193.23.51 interface FastEthernet1.486 description AIK_Client_Net encapsulation dot1q 486 ip address 192.168.11.1 255.255.255.0 ip helper-address 10.193.23.51 6

2.6 Migration av kassor Nästa del i projektet är att flytta över kassorna till det nya VLANet. Innan överflytt av kassorna så ville jag testa på några som inte används nu under lågsäsong för att se att allt fungerar som det ska. Kassorna i sportbaren används inte kontinuerligt nu under lågsäsong så jag valde att flytta över 4 stycken som var placerade där först. För att verifiera resultatet ifrån kontoret utan att fysiskt vara på plats på arenan så anslöt jag via "Remote desktop" till en server på arenan och där via en Tight VNC klient som de har för att internt kunna fjäransluta till kassorna. För att verifiera resultatet så kontrollerade jag vilken IP adress som kassorna fått tilldelade och de var de första adresserna i adresspoolen. Däremot så saknade de internet åtkomst. Då de fått adresser som tillhör rätt VLAN så kom jag och min handledare fram till att orsaken måste vara någon regel eller begränsning i Ateas ASA brandvägg eller Core router. Jag gick igenom konfigurationen i ASA brandäggen och la till nya 10.193.27.0 /24 nätet i en access regel som styr vilka nät Skellefte AIK får passera med igenom brandväggen och även i den acceslista som anger vilka av deras nät som skall NATas (översättas ifrån internt IP till externt) då de skall ut igenom brandväggen men kassorna saknade fortfarande internet åtkomst. Då jag kände att det här var utanför min kompetens så fick jag vända mig till Niklas Westerlund på Atea. Han är den som är mest insatt i Ateas kund nät och specialiserad på kommunikationsbiten i nätverken. Det visade sig att det var i core routern orsaken fanns. Nya kassanätet skulle även där läggas in som statisk route. Efter det så hade kassorna i sportbaren internet åtkomst. Nästa steg nu då det var verifierat att konfigurationen var korrekt var att flytta över resterande kassor men då det innefattar restaurangkassorna som används dagligen så fick vi i samråd med Skellefteå AIK besluta en lämplig tidpunkt. Innan överflytten av resterande kassor så gick jag igenom dokumenteringen igen och såg att portarnas beskrivning som jag utgått ifrån inte stämde överens med dokument ifrån tidigare projekt på Arenan. För att vara säker på att rätt uttag i switcharna flyttas över till kassanätet så kände jag att jag var tvungen att fysiskt kontrollera varje uttag och var det var anslutet. Det visade sig att några av kassorna hade blivit flyttade och några hade tidigare delat uttag men nu fått egna så portanslutningarna stämde inte överrens med beskrivningen. I samband med överflyttningen till nya VLAN:et så uppdaterade jag beskrivningen på portarna med namnet på ansluten kassa t.ex. AIKREB01 som är det nya namnet på kassa 1 enligt bestämd namnstandard. Jag upprättade även ett Excel dokument där det framgick vilket uttag varje kassa var ansluten till, vilket ställ den var placerat i och till vilken port och switch den var ansluten. Efter att kassorna var överflyttade till det nya VLAN:et så kontrollerades det att de hade internet åtkomst och att de fick IP adresser som tillhörde rätt VLAN och adress pool. En av kassorna flyttades inte över på grund av att det inte fanns något märkt uttag vid kassan utan det var en direktansluten kabel som gick upp i taket och kom ut någonstans bland de andra kablarna i patchskåpet. Jag kunde inte följa den och 7

verifiera vilken port det var ansluten mot. Kassan fungerar dock och har internet åtkomst fast den är ansluten till klientnätet. Jag har meddelat min handledare vilken kassa som inte är överflyttad och orsaken till det. Det framgår även av dokumentationen jag överlämnat till Atea. 2.7 Access För att säkerställa att ingen kan komma åt kassorna från klienterna eller deras VLAN så har jag skapat en access-lista och placerat på det sub-interfacet i routern som tillhör klientnätet. Accesslistan är av typen Extended access-list och har namngivits till CLIENT_NET_IN för att beskriva placeringen av den. Så här ser accesslistan ut: Deny IP (source)192.168.11.0 0.0.0.255 (destination)10.193.27.0 0.0.0.255 Permit IP any any Detta gör att inga anslutningar ifrån klientnätet tillåts att komma åt kassanätet men rad två säger att all annan trafik vart som helst är tillåten. För att stoppa oönskad trafik så tidigt som möjligt så placerades accesslistan på sub-interfacet där trafiken från klinterna kommer in och stoppar inkommande trafik som har kassanätet som destination. 3. Resultat Resultatet blev som önskat och målet med projektet känns uppfyllt. Dock så skulle jag önskat att den sista kassan blivit överflyttad innan jag avslutat mitt projekt. Det kommer att monteras ett uttag där den kassan är placerad och även märkas upp. Då det är åtgärdat så kommer Atea att flytta över även den kassan till rätt VLAN. Det är svårt att verifiera om funktionaliteten har blivit bättre efter mitt arbete då det här varit en av flera åtgärder i ett projekt för att åtgärda kassornas stabilitetsproblem. Det är dock inte bara att kassorna fungerat ostabilt som är orsaken till separationen av kassasystemet utan även säkerhetsaspekter är inräknade i det. Säkerheten har blivit bättre då det inte längre finns möjlighet att komma åt kassorna eller det nätet de är anslutna till ifrån det VLAN klienterna och administrationen är anslutna. Jag har även genom skapande av trunk och sub-interface förberetts så att det kan läggas till nya VLAN utan att ha driftstopp på befintliga om behov skulle uppstå i framtiden. 8

4. Diskussion De områden jag berört i mitt examensarbete är till större delen sådant som jag tidigare testat i labbmiljö i min utbildning. Vissa delar som till exempel att implementera ett DHCP scoop i Windows miljö var helt nytt för mig men visade sig vara väldigt enkelt då jag satte mig och försökte. Jag jämförde med det andra DHCP scoopet som redan fanns på klientnätet för att se vilka uppgifter som ska finnas och löste den uppgiften på så vis. Vissa saker där jag var osäker på hur Atea ville att det skulle göras var jag tvungen att kontrollera med min handledare Jens Hunnesjö eller Niklas Westerlund på Atea. Eftersom Jens och Niklas inte alltid var på kontoret så blev det en del väntetid då jag sysselsatte mig med att utforska Ateas ASA brandvägg och försöka förstå hur den är konfigurerad och hur den fungerar eller hjälpa till med något annat uppdrag som fanns. Jag har bland annat fått sätta upp en Easy VPN tjänst till en av Ateas kunder och konfigurera en accesspunkt som skall anslutas. Sista veckan då jag var klar med uppdraget och skrev på min rapport så fick jag ett samtal av min handledare där han förklarade att en annan av Ateas kunder blivit av med sin mail tvätt tjänst. Han bad mig kolla i Ateas ASA brandväg om jag kunde hitta och ändra i access reglerna på kunden så så att de kunde ta emot inkommande mail igen. Riktigt roligt att känna att jag fick förtroende fast jag var helt ny på det området och jag lyckades även hitta IP numret till kundens Exchange server och öppna så att mail trafik (smtp) utifrån kom in. Orsaken till vad som hänt med tjänsten de hade för mail tvätt är för mig okänd men företaget upptäckte felet genom att de inte fick några mail och inte heller kunde skicka något. Min lösning var att ändra i Ateas ASA brandvägg och tillåta smtp trafik utifrån som försökte ansluta till kundens Exchange server. Jag kunde efteråt även verifiera att min lösning fungerade genom att kolla i ASAn att smtp anlutningar upprättades och avslutades. Lösningen för att tillåta trafik ut var inte lika kritiskt så det fick någon annan på Atea ordna då jag var upptagen med rapportskrivning. Kan tillägga att den tjänsten inte var genom Atea utan det var en tjänst som de hade kvar hos de som tidigare haft hand om driften av kundens servrar och nätverk. För mig har det varit fem lärorika veckor och jag har blivit bra bemött och fått bra stöd ifrån min handledare och de andra på Atea kontoret här i Skellefteå. De har fått svara på en hel del frågor och funderingar som dykt upp under projektets gång. Det är en helt ny känsla att vara inne och konfigurera i hårdvara där jag vet att det finns flera företag och många personer som kan påverkas om jag gör någonting som inte blir rätt så jag har tänkt till både en och två gånger extra innan jag genomfört ändringar. 9

Bilaga 1. Cisco ASA Cisco ASA brandvägg Cisco ASA(Adaptive Security Appliance) brandvägg är en vidareutveckling av den populära PIX(Private Internet exchange) brandväggen. År 2005 introducerade Cisco ASA som har funktionerna ifrån PIX men också en mängd nya funktioner för säkerhet och funktion. ASA tillhör gruppen tillståndsbaserade brandväggar (statefull) som inte bara kontrollerar vilken typ av trafik och var trafiken kommer ifrån utan går även igenom dataströmen och på så sätt minskar risken för att oönskade program skall kunna släppas igenom. PIX brandväggar används fortfarande men byts med fördel ut mot ASA då ASAn inte bara fungerar som en brandvägg utan även innehåller bland annat anti-malware funktioner för att förhindra virus, phishing, maskar och applikationslager attacker. Cisco ASA fungerar även som en VPN koncentrator som gör det möjligt att ansluta till ett företagsnät varsomhelst ifrån och det antingen via en VPN client(ipsec) eller en webläsare(ssl). I de enklare modellerna för små företag och hemanvändare så finns det möjlighet att ha 10 IPsec och 2 SSL VPN användare men det går att utöka i efterhand. ASA stödjer både siteto-site och remote user VPN[1]. Cisco ASA hjälper till att skydda mot 3 kategorier av attacker. Reconnaissance Attacks (spanings attacker)- är en typ av attacker där avsikten är att dokumentera ett nätverks infrastruktur och säkerhets brister. Access attacks är attacker där avsikten är att komma åt data eller system för de som saknar åtkomst. Denial of Service (DOS) Attacks- som är attacker där man stör tillgången till tjänster och system genom att överbelasta systemet. ASA innehåller bland annat nedanstående säkerhetsfunktioner: Packet Filtering tillåter eller nekar trafik beroende på källa/destinations ip adresser eller TCP/UDP portnummer med hjälp av accesslistor (Access Control Lists- ACL) Statefull Packet Inspection Spårar och söker igenom TCP och UDP data sessioner i ett flöde genom användande av Adaptive Security Algorithm. Proxy - Fungerar som mellanhand för kommunikation genom att autentisera användare innan kommunikation tillåts ske. AIP SSM (Advanced Inspection and Prevention Security Service Module) djup avanserad genomgång av data trafiken [4]. CSC SSM(Content Security and Control Security Service Module) Funktion för skydd mot hot som virus, spionprogram (spyware), spam och phishing. [3] 1(2)

Bilaga 1. Cisco ASA Andra användbara funktioner som finns i ASA är: NAT (Statisk/dynamisk) Möjliggör användandet av privata IP adresser på interna nätverket som översätts till en eller flera externa IP adresser. Internet och FTP adress filter Enkla funktioner för att spärra åtkomst till specifika internet sidor eller FTP servrar. Denna funktion är inte så funktionell med bara ASAn men är skalbar och kan anslutas till tredje parts lösningar för internet filtrering för att få ut bra funktioner och användbarhet.[1,2] VPN (IPsec/SSL) som nämnts i texten ovan så stödjer ASA både remote-access för clienter som skall komma åt interna nätverket och site-to-site där man sammankopplar tex 2 olika kontor inom ett företag. QoS (Quality of Service) möjliggör att man har olika policys och prioriteringar för olika typer av nätverkstrafik. Tex så att VoIP(IP telefoni) prioriteras före vanligt surfande(http). KONFIGURATION Cisco ASA kan konfigureras antingen genom CLI(command line interface) eller GUI (graphical user interface). Fjäråtkomst kan tillåtas antingen genom Telnet, SSH eller ASDM. Med Telnet och SSH får man åtkomst till ASAns CLI interface och för att få en grafisk överblick och möjlighet till konfigurering i ett grafiskt interface kan man använda sig av ASDM(Adaptive Security Device Manager). Default så kan man inte ansluta med Telnet eller SSH ifrån utsidan utan det måste konfigureras först. Telnet rekommenderas inte att använda ifrån utsidan då Telnet trafiken är okypterad, vill man ändå använda Telnet bör man ansluta via en krypterad tunnel som till exempel IPsec. I ASDM så kan man konfigurera allt man kan via CLI men ger i många fall en mer förståelig bild medan CLI ger enklare överblick i vissa lägen. 2(2)

Bilaga 2. Referenser till bilaga 1 REFERENSER (1) http://www.cisco.com/en/us/prod/collateral/vpndevc/ps6032/ps6094/ps6120/prod_broch ure0900aecd80402e36.html (2) http://fengnet.com/book/firewallfundamentals/ch06lev1sec4.html (3) http://www.cisco.com/en/us/docs/security/csc/csc62/administration/guide/csc1.html (4) http://www.cisco.com/en/us/docs/security/asa/asa71/configuration/guide/ssm.html 1(1)