Banner

Banner är en funktion som tillåter att olika typer av meddelanden presenteras när en administrator ansluter och konfigurerar en nätverksenhet på distans. Enligt standard skall de olika meddelandena innehålla information om att samtlig aktivitet kommer loggas samt eventuella lokala lagar och regler. Vad som däremot bör utelämnas är privat information om exempelvis ägare, företagsnamn, telefonnummer, IP-adresser och liknande [CISCO2, s.598]. Detta för att skydda sig mot rekognosering eller medvetet riktade attacker mot ägaren av enheterna. De olika banner som finns tillgängliga är enligt nedan:

MOTD är en banner som används för att annonsera publika meddelanden som kan komma att påverka samtliga berörda användare. Meddelandet visas när en administratör ombeds autentisera sig för vidare tillträde [CISCO4].

Loginbanner används i syfte att tala om vilka lagar och regler som måste följas och därtill även att all aktivitet kommer att loggas [CISCO4].

EXCEC banner är en banner som kommer till att visas när en administratör autentiserat sig och ges tillträdde till att vidare konfigurera enheten [CISCO4].

Figur 2-14: Aktuell banner MOTD på enheter i VMKF:s nätverk

VMKF använder idag en MOTD banner när administratörerna ansluter mot nätverksenheter via telnet (Se kapitel 2.3.2 ”Distanskonfigurering” för vidare förklaring av telnet). I bannern exponeras företagsnamnet, att det är en säkrad sida samt att samtlig aktivitet kommer att loggas. Denna banner återfinns på samtliga enheter genom nätverket och är också den enda bannern som finns konfigurerad.

För att optimera användningen av banners och ta vara på de möjligheter som finns att annonsera om viktiga och i många fall nödvändiga meddelanden är det rekommenderat att implementera dessa enligt standard. I enlighet med detta skulle det innebära en optimering att dels flytta den befintliga bannern och konfigurera denna som loginbanner och i och med detta även censurera välkomsttexten med företagsnamnet då det kan vara en säkerhetsrisk att exponera detta. MOTD används lämpligast för meddelanden som är sporadiskt förekommande eller dagligen upprepade såsom omstarter, driftuppehåll eller liknande. EXCEC bannern bör slutligen användas för att bekräfta, verifiera och välkomna den inloggade administratorn. För konfigurationsexempel hänvisas till konfigurationerna i bilaga 5.9 till och med bilaga 5.12. Exempel på optimerad loginbanner respektive EXEC banner återfinns i Figur 2-15 samt Figur 2-16.

Figur 2-15: Exempel på loginbanner

Figur 2-16: Exempel på EXEC banner

2.3.2 Distanskonfigurering

Distanskonfigurering hänvisar till metoden att ansluta och konfigurera enheter på distans. För att uppnå detta finns det två huvudsakliga protokoll, telnet och SSH. Telnet är en del av application- lagret enligt TCP/IP-modellen och ett protokoll som tillhandahåller en textbaserad envägskommunikation mellan en klient och en server. I detta fall benämns en dator som klient och en nätverksenhet som server.

Telnet utvecklades tidigt och kan härledas redan till RFC15 [RFC15] publicerad år 1969 då tekniken för första gången offentliggjordes och standardiserades senare av IETF år 1983 [WIK34]. Dock har telnets tidiga utveckling dessvärre inte lyckats följa utvecklingen inom nätverksteknik och är idag en ganska sällan använd metod i större privata och publika nätverk, detta eftersom kommunikationen via telnet är helt okrypterad vilket medför en mängd säkerhetsbrister då bland annat lösenord inte krypteras. Emellertid har nya teknologier utvecklats i samband med den ökade efterfrågan på säkerhet. En av dessa teknologier är SSH, som tillåter likvärdig kommunikation som telnet, fast krypterad. SSH anses idag som en ny industristandard för att konfigurera nätverksenheter på distans. Tekniken bygger på ett asymmetriskt nyckelpar för att etablera en säkrad anslutning mellan klient och server. Dessa nyckelpar är kalkylerade utifrån RSA-algoritmen som var en av de första säkra algoritmerna. En SSH-säkrad förbindelse mellan nätverksenhet och klient uppnås genom följande konfiguration på en switch och är integrerad i den optimerade nätversstrukturen [WIK04] [WIK05] [WIK10]:

switch(config)# crypto key generate rsa switch(config)# ip ssh time-out 60

switch(config)# ip ssh authentication-retries 2 switch(config)# ip ssh version 2

switch(config)# username vmkfadmin password k4tl401 switch(config)# line vty 0 4

switch(config-line)# transport input ssh

switch(config-line)# login authentication default

I konfigurationen ovan tillåts endast två anslutningsförsök under samma anslutningsförsök innan anslutningen bryts och klienten måste ansluta till servern på nytt. Detta skyddar mot så kallade brute force-attacker. Om användaren förblir oinloggad kommer anslutningen brytas inom sextio sekunder. Dessutom specificeras användarnamn och lösenord i en lokal databas på enheten för personen som ska tillåtas att ansluta [CISCO5]. Eftersom telnet endast kräver åtkomst mellan två fysiska kommunikationsgränssnitt samt ett konfigurerat lösenord presenteras ingen utförlig beskrivning om tillvägagångssättet.

Före optimering sköttes all avlägsen konfigurering via telnet vilket kan anses vara en säkerhetsrisk i den aktuella miljön då framförallt lösenord och konfiguration via nätverksenheter skett helt okrypterat. Detta skulle kunna ge mycket allvarliga konsekvenser framförallt för nätverkets driftsäkerhet. Emellertid minimeras riskerna drastiskt med användningen av SSH.

2.3.3 TACACS+

TACACS+ står för Terminal Access Controller Admission Control Plus och är ett AAA-protokoll som används i egenskap av tillträdeskontroll mellan nätverkshårdvara såsom servrar, switchar och routrar och är en centraliserad server för åtkomsträttighet. Protokollet är utvecklat länge och härstammar från TACACS eller ”An Access Control Protocol”, som den första RFC1492 [RFC1492] kallade funktionen. Mycket har skett sedan dess och idag är ett par bland många uppdateringar att samtliga funktioner skyddade med kryptering samt att man separerat på funktionerna vilket gör protokollet mycket flexibelt då man inte behöver integrera hela AAA-uppbyggnaden utan endast de funktioner man eftersöker [CARGRA].

I dagsläget används TACACS+ som tillträdeskontroll mellan nätverksenheter, TACACS+ klienter, och en centraliserad server. Administratörer kontaktar klienterna och autentiserar sig med användarnamn och lösenord. Klienterna kontaktar sedan den centrala servern via TACACS+ som kontrollerar ifall uppgifterna stämmer och returnerar i sådana fall vilken grad av tillträde användaren skall berättigas. Skulle dock användarnamn och lösenord vara felaktiga så nekas tillträde.

TACACS+ och dess implementering gör det säkert att förhandla om tillträdeskontroll mellan server och nätverksenheter och som en del av denna rapports omfattning har funktionen endast granskats men inte anses behöva någon ytterligare optimering.

TACACS+ konfigureras enligt följande på samtliga enheter i nätverket:

switch(config)# aaa new-model

switch(config)# aaa authentication login default group tacacs+ local switch(config)# username vmkfadmin password k4tl401

switch(config)# tacacs-server host 10.1.1.23 switch(config)# tacacs-server key 7 k4tl401

Vad ovanstående kommandon förtäljer är att i första hand konsultera en TACACS+-server med IP- adress 10.1.1.23 för autentisering av användarnamn och lösenord. Själva kommunikationen med TACACS+-servern är i sig skyddad med ett lösenord. Skulle enheten i nödläge inte få kontakt med TACACS+-servern kommer en lokal autentiseringsdatabas konfigurerad på enheten konsulteras, enligt kommandona med användarnamn vmkfadmin och password k4tl401 [FREA].

2.3.4 IEEE802.1x

802.1x, eller Dot1x som det ofta kallas, är en del av IEEE 802-standardiseringen och tillhandahåller, likt tidigare nämnda TACACS+, med tillträdes- och säkerhetskontroll för klienter. Detta genom att sammanfoga samtliga deltagare till ett och samma ramverk. Bland deltagarna finner vi klienter, nätverksenheter som i detta fall kallas autentiseringsenheter, och en autentiseringsserver med installerad mjukvara som tillåts kommunicera via RADIUS- och EAP-protokollen. Dot1x är uppdelat i ett par porttillstånd där en port alltid i utgångsläget är begränsad, kallad för oauktoriserad, till att enbart prata 802.1x trafik såsom EAP-meddelanden över LAN även kallat EAPOL. Det andra porttillståndet, auktoriserad, innebär att porten tillåts skicka och ta emot vanlig datatrafik. För att få en port i auktoriserat läge krävs att klienten eller mjukvaran kan autentisera sig mot servern. Ur en pedagogisk synvinkel skulle man kunna lika det till en passkontroll där klienten är passinnehavaren, vakten är autentiseringsenheten och personregistret autentiseringsservern. Passinnehavaren måste kunna visa upp en eller flera giltiga handlingar för att tillåtas igenom passkontrollen. På samma sätt förhandlar klienten med autentiseringsservern med nätverksenheten som kontrollant [WIK06] [CISCO6].

Figur 2-17: Autentiseringsförlopp för IEEE802.1x

I början av en Dot1x autentisering skickar nätverksenheten ut EAP-förfrågan, likt en vakt frågar efter en giltig ID-handling. Klienten svarar sedan med ett EAP-svar vilken innehåller ID-information om vem klienten är. Autentiseringsenheten vidarebefordrar sedan ID-informationen för kontroll mot autentiseringsservern via RADIUS-protokollet. Servern svarar sedan med information som klienten måste komplettera för att tillåtas åtkomst till nätverket. Klienten svarar sedan med den begärda informationen och om all information är korrekt tillåts klienten tillträde till nätverket. Bland den kompletterade informationen finner man bland annat funktioner som att bekräfta att antivirus och operativsystem är uppdaterade, eller en begäran att skicka ett lösenord över en tunnel [WIK06] [CISCO6].

För närvarande används Dot1x i samråd med en NAP-server för att verifiera klienter och dess mjukvara i nätverket både över LAN och WLAN och tillhandahåller därmed med säkerhet och kontroll för att förebygga att skadliga eller illasinnade klienter ansluter till nätverket. Eftersom uppdragsgivaren inte specifikt eftersökt en optimering av klientspecifika områden i nätverket har ingen optimering av Dot1x genomförts. Dock har förekomsten av Dot1x i nätverket bekräftats och diskuterats då ökad förståelse för dess roll i nätverket ändå var nödvändig för ökad insikt och vidareutveckling av QoS.

2.4 Routing

När ett paket förflyttas från avsändare till sin destination görs en rad beslut hur paketet skall anvisas till sitt mål. Processen för detta vägvalsbeslut kallas för routing och att routa datapaket är routerenheternas främsta uppgift. Därför brukar teknologier som avgör detta vägvalsbeslut inkluderas under den övergripande termen routing [CISCO12] [CISCO13, s.162ff].

Figur 2-18: Modell för routing

För att kortfattat förklara hur routing fungerar hänvisas till Figur 2-18 där en router ska bestämma färdväg för ett paket skickat från klienten med IP-adress 10.4.4.14 /24 ämnat för klienten med IP- adress 10.1.1.23 /24. Det första som sker när ett paket skickas till en klient inom samma subnät är att genom ARP skaffa sig kunskap om destinationsklientens MAC-adress. Om klienten inte finns inom samma subnät kommer klienten konsultera sin Default Gateway. Även här skickar klienten en ARP för att finna sin Default Gateways MAC-adress. IP-paketet som ska skickas inkapslas i en ethernetframe från klienten med mottagarens IP-adress samt Routerns MAC-adress varpå den skickas till routern [CISCO13, s.162ff].

Destination MAC Source MAC

Frame Type

CRC

Figur 2-19: Uppbyggnad av ett IP-paket samt ethernetinkapsling [CISCO11]

I IP-paketet finns information rörande från vilken IP-adress paketet skickats och vart det ska (Se Figur 2-19 för hur ett IP-paket är uppbyggt. Se sedan samma figur för hur inkapslingen av IP-paketet teoretiskt ser ut i en ethernetframe [CISCO14] [CISCO12]).

IP-paket (Ehternet Data)

Det routern gör när paketet anländer på gränssnittet eth2 enligt Figur 2-18 är att skala bort ethernetframe-informationen och titta på mottagaradressen i IP-paketet och därefter konsultera sin routingtabell. I routingtabellen finns routerns lista vart utefter vägvalsbeslut fastställs. Denna routingtabell konfigureras antingen statiskt av en administratör eller byggs upp dynamiskt av routingprotokoll. I routingtabellen finner routern att mottagaradressens nät 10.1.1.0 /24 kan hittas om paketet skickas vidare på kommunikationsgränssnittet eth0. Routern fastställer då MAC-adressen som används för att skicka paketet till next-hop router varpå IP-paketet ånyo inkapslas och skickas vidare. Denna procedur kan upprepas enligt samma teori av flera routrar till dess det når mottagaren. Om mottagaren svarar kommer den skicka ett paket till nätet 10.4.4.0 och routrarna får upprepa samma procedur i omvänd ordning [CISCO12] [CISCO13, s. 162ff].

Denna beskrivning gäller i stora drag för all typ av routing såväl på lokal nätverksnivå som över hela Internet och därför är routing ett viktigt verktyg i att förstå nätverksteknik i stort. Själva skickandet av paketet är en enkel procedur när väl routingtabellen finns att konsultera medan det är betydligt mer komplext att konstruera själva routingtabellerna [CISCO12].

2.4.1 InterVLAN routing

Figur 2-20: Princip för InterVLAN routing

VLAN är till för att segregera ett fysiskt nät till flera virtuella nätverk. För att en klient på ett unikt VLAN ska kunna kommunicera med klienter på ett annat VLAN krävs att trafiken routas däremellan, eftersom de olika subnäten IP-adresseras. Som Figur 2-20 visar sitter två klienter, Klient 2 och Klient 3 inkopplade på VLAN20. Om Klient 2 önskar kommunicera med Klient 3 räcker det med att trafik skickas över switchen A1. För utförligare beskrivning av hur dessa två klienter kommunicerar finns beskrivet under kapitel 2.5 ”Switching”. Om Klient 2 däremot vill skicka trafik till VLAN 10 är detta inte möjligt utan att routa trafiken via R1. Det som förloras i nätverkseffektivitet i och med den extra routingen återvinns istället i säkerhet, skalbarhet, administrationsgynnsamhet och det faktum att denna form av routing begränsar broadcastdomäner per VLAN-basis. Tekniken som beskrivits kallas för interVLAN routing och används för att routa trafik från det ena VLAN:et och dess separata IP- subnät till ett annat VLAN med ett annat unikt IP-subnät. Genom att konfigurera interVLAN routing på routrar eller MLS:ar tillåts klienterna inom olika VLAN kommunicera med varandra, men kan också konfigureras att isoleras eller enbart komma åt vissa VLAN [CISCO10].

Figur 2-21: Princip för interVLAN routing på MLS

Betrakta Figur 2-21 som en exempeltopologi liknande den i Figur 2-20. InterVLAN routing konfigureras nu på D1 i stället enligt följande:

switch(config)# ip routing

switch(config)# interface vlan 10

switch(config-if)# ip address 192.168.10.1 255.255.255.0 switch(config)# interface vlan 20

switch(config-if)# ip address 192.168.20.1 255.255.255.0

De fördelar som nu uppnåtts är att resurser på R1 enligt Figur 2-21 frigörs samtidigt som länkbelastningen mellan D1 och R1 minskas. Dessutom har broadcastdomänen reducerats vidare. Den granskning av VMKF:s nätverk som genomförts påvisade interVLAN routing i distributionslagret vilket är en förändring som gjorts av VMKF:s nätverkstekniker på inrådan av Cisco Systems. Tidigare var interVLAN routingen stationerad i corelagret och det kom till kännedom att en eventuell övergång till tidigare implementering hade övervägts.

I en optimerad nätverksversion skall interVLAN routing fördelaktigt placeras på distributionslagret i enlighet med hur det ser ut i nätverket i dagsläget. Den övergång till interVLAN routing i core avråds därför på grund av i kapitlet föregående orsaker.

2.4.2 Statiska routes

Routrar använder tre metoder för att addera routes till sin routingtabell; direktanslutna nät, administrativt statiska routes samt dynamiskt lärda routes via routingprotokoll. Direktanslutna routes är nät som är konfigurerade på routerns gränssnitt och läggs automatiskt till då kommunikationsgränssnittet konfigureras. Administrativt statiska routes konfigureras av en tekniker och instruerar därmed routern att alltid skicka datapaket i en viss riktning. Statiska routes är att föredra på enheter som har en eller högst ett par vägar ut ur nätet då annars statiska routes är administrativt ohållbart i stora nätverksmiljöer [CISCO18, s.75ff].

Figur 2-22: Modell över Köping LAN

Om KPD1 enligt Figur 2-22 ska skicka trafik från bakomvarande accessnätverk till något annat segment såväl lokalt som mot Internet har enheten två vägar att välja på, antingen genom KPC1 eller KPC2. Om en klient i KPD1:s bakomvarande accessnätverk önskar skicka trafik till accessnätverket bakom KPD2 kommer trafiken ändå att skickas via KPC1 eller KPC2, därmed är det resursbesparande att begränsa KPD1:s, samt de andra distributionsswitcharna KPD2 till och med KPD5:s och deras routingtabeller.

Om en statisk route konfigureras för alla nät, benämnd quad-zero-route, 0.0.0.0/0, kallas detta för en Default route och kommer inkludera sådant som inte finns med i routerns routingtabell. Detta möjliggör att routern inte kommer kasta paketen eftersom detta är ursprungsbeteendet för okända nät [CISCO18, s.87-89] [DADA2].

Konfiguration för Default route [CISCO18, s.88]:

switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/0

En optimering kan innebära att minska distributionsswitcharnas routingtabeller till att endast inkludera direktanslutna nätverk och en Default route. I VMKF:s nätverk som innefattar ytterst få nät kommer inte mycket stora routingtabeller bidra till någon direkt hårdvarubelastning. En optimering enligt dessa premisser medför en försumbar hårdvarufrigörelse men förenklar förståelsen för nätverkstekniker då routingtabeller överensstämmer med den logiska nätverksstrukturen [SHDEB]. Som den optimerade nätverkstopologin beskriver i analogi med Figur 2-22 innebär det att Köping LAN har två vägar ut mot Internet, via KPC1 respektive KPC2. På dessa enheter konfigureras en Default route mot Internet. Fel uppstår dock om en förbindelse från enheterna mot Internet upphör genom att en länk bryts. Då kommer den konfigurerade Default route ej längre uppfylla sin funktion utan routern kommer villkorslöst kasta alla datapaket ämnade för obekanta nät, det vill säga trafik

För att skapa feltoleranta Default route kan en så kallad Floating Default route skapas. Genom att introducera två eller flera Default route med olika prioritet kan man primärt styra all trafik över önskad länk tills dess denna länk upphör att fungera varvid den andra Default route med lägre prioritet fortsätter att genomföra samma procedur för trafik ämnad för okända nät och styra dessa över en annan fortfarande fungerande länk. Prioriteten som styr vilken Default route som är primär kallas för cost eller metric och konfigureras enligt följande [CISCO18, s.92-93]:

Konfiguration för Floating Gateway of last resort:

switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/9 switch(config)# ip route 0.0.0.0 0.0.0.0 fastethernet0/6 100

Genom att specificera cost till 100 för en Default route kommer fastethernet0/6 bli sekundär, då standardvärde cost 0 anvisas då värde helt utelämnas som för fastethernet0/9 [CISCO18, s.93].

Figur 2-23: Modell för Floating Default route

Genom att betrakta Figur 2-23 kan ökad förståelse uppnås för hur en Floating Default route i praktiken bör praktiseras. KPC1 har en primär Default route mot Internet samt en sekundär Default route mot KPC2. Vid händelse av länkproblem mot Internet i Figur 2-23 markerat med ett kryss kommer KPC1:s primära Default route, markerat med A, tas bort ur routingtabellen och ersättas med den sekundära mot KPC2, markerad med B. KPC2 har förhoppningsvis en obruten länk mot Internet varvid all trafik som är Internetadresserad skickas ut via dess primära Default route, i figuren beskriven med ett C.

2.4.3 OSPF

Förutom de direktanslutna och statiskt konfigurerade näten som kan förekomma i en routingtabell kan även routinginformation fyllas i dynamiskt genom att enheter som ingår i ett litet eller större nätverk kommunicerar med varandra för att informera om vilken enhet som är konfigurerad med vilket nät. Detta för att drastiskt underlätta administrativ belastning i konfiguration av routes [DADA3].

Figur 2-24: Modell över dynamiska routingprotokoll

Betrakta grundprincipen för hur ett dynamiskt routingprotokoll fungerar genom Figur 2-24. R2 kommer med hjälp av ett dynamiskt routingprotokoll att skicka en uppdatering till alla adresserade routrar där R2 annonserar om att nät 10.20.20.0 /24 finnas att hitta samma väg som uppdateringen kom ifrån. Alla andra routrar lägger då till detta nät i sin routingtabell. Detsamma gäller R1 som annonserar om sitt nät 10.30.30.0 /24. På så vis kan nu näten 10.20.20.0 /24 och 10.30.30.0 /24 routas genom alla routrar mellan R1 och R2, det med mycket liten administrativ insats [DADA3]. OSPF är ett dynamiskt routingprotokoll av så kallad link-state-variant där varje OSPF-aktiverad enhet skickar kontrollmeddelanden, kallade Hello, till de routrar betraktade som grannar för att bygga upp en relation till dessa, nämligen en relation titulerat neighbour. Hello-meddelanden skickas via multicast-adressen 224.0.0.5. När denna relation är etablerad skickar routrarna LSA:er till alla sina neighbours. En LSA är ett meddelande innehållandes information om routerns Router-ID, routerns kommunikationsgränssnitt med IP-adresser och subnätmask, länkarnas tillstånd och den metric som är associerad till länken. Denna relation och informationsutbyte sker medelst hela nätet igenom som resultat av att routern som tar emot en LSA kopierar den och skickar den vidare till sina neighbour förutom till den enhet som LSA:n ursprungligen kom ifrån [CISCO13, s.333ff].

Cost, eller metric som det också kan kallas, är en indikator för hur hög prioritet en länk har för att primärt skicka trafik. Om två länkar leder till samma mål är det länken med lägst cost som blir primär länk vilken trafik routas efter. Cost styrs utefter bandbredd på det fysiska kommunikationsgränssnittet enligt formeln 100000000/bandbredd mätt i bitar per sekund. Således är värdet för cost på ett FastEthernet-gränssnitt 100000000/100000000=1. Problem uppstår vid länkar snabbare än 100Mbps eftersom OSPF då rundar av alla värden för cost till 1. Cost kan statiskt ändras administrativt per kommunikationsgränssnitt-basis eller enligt premisser konfigurerat i OSPF- uppdateringar [CISCO13, s.369-370].

OSPF grupperas i en eller flera instanser kallade areor. Areorna identifieras av ett nummer där area 0 är standardarean och om fler areor än area 0 förekommer kallas area 0 för backbone area. Alla andra areor ansluter sedan till backbone area 0. Grupperingen av OSPF i areor innebär att varje area kommer ha sin egen LSDB. Routrar som sammanbinder flera OSPF-areor med area 0 kallas för ABR:er varvid de som endast tillhör en OSPF-area kallas för IR. Routes inom samma area kommer i