LABORATIONSRAPPORT Säkerhet & Sårbarhet VPN

Transkript

1 LABORATIONSRAPPORT Säkerhet & Sårbarhet Laborant/er: Klass: Laborationsansvarig: Martin Andersson Robin Cedermark Erik Gylemo Jimmy Johansson Oskar Löwendahl Jakob Åberg DD12 Hans Ericson Utskriftsdatum: Godkänd / Ej Godkänd den Signatur: Ev anm:

2 1 Syfte Att få en inblick i hur man praktiskt sätter upp på brandväggar. 2 Förberedelser En genomgång av laborationen skedde under ett föreläsningstillfälle. och tunnlar har även nämnts i en tidigare kurs, Switching & WAN-teknik. I en tidigare laboration har vi bekantat oss med brandväggarna vi skulle använda i denna uppgift. 3 Genomförande Vi har använt oss utav utrustningen i skolans laborationssal. De brandväggar vi använt oss av är Cisco ASA 5505 och pfsense. 3.1 och IKE har till uppgift att upprätta och säkra en virtuell tunnel över internet som kan vara antingen från en site till en annan eller från en Remote host till en site. använder sig oftast av IPSec(Internet protocol security) för att kryptera och kapsulera IP-paket i IPsec-paket som skyddar paketet när det färdas i tunneln. I en site-till-site kan antingen IPSec eller GRE användas (Generic Routing Encapsulation), GRE gör ramen för hur ett Passenger protocol ska transporteras över Internet Protocol. Ramen innehåller information som till exempel vilken typ av paket du kapsulerar och kopplingen mellan skickare och mottagare. IPsec använder två sub-protokoll som instruerar till vad som behövs för att säkra dess paket: Encapsulated Security Payload (ESP) krypterar den data som finns i paketet med en symmetrisk nyckel. Authentication Header (AH) använder sig av en hashing operation på paket headern för att dölja olika slags information medan paketet är i tunneln, den här informationen kan vara till exempel skickarens identitet. Informationen låses upp när paketet nått sin destination. I ett Remote access använder oftast PPP som grund för tunneln. Remote access kan använda en av tre protokoll som är baserade på PPP. L2F (Layer 2 Forwarding): Cisco utvecklat, använder vilken autentisering som helst som stöds av PPP. PPTP (Point-to-point Tunneling Protocol): Stödjer 40-bit och 128-bit kryptering och vilken autentisering som helst som stöds av PPP. L2TP (Layer 2 Tunneling Protocol): Kombinerar delar av PPTP och L2F och har fullt stöd för IPSec. L2TP går också att använda i site-till-site s. Formatmall: Laborationsrapport.dot Sidan 2 av 17

3 IKE (Internet Key Exchange) används i samband med att man bygger upp en Security association (SA). En SA används för att man vill skydda informationen som delas mellan två datorer. IKE genererar och hanterar delade, hemliga nycklar som används för att säkra information. Det används även för att centralisera ledningen för SA vilket minskar tiden det tar att ansluta. En security association är en kombination av förhandlade nycklar, säkerhetsprotokoll och säkerhetsparametrar vilka tillsammans används för att skydda kommunikationen mellan avsändare och mottagare. För att bilda en säker kommunikation så använder IKE två faser. I dessa används krypterings- och autentiseringsalgoritmer som de två datorerna har kommit överens om. Under första fasen lägger avsändaren fram ett förslag på en SA som mottagaren inte kan ändra på. Mottagaren skickar tillbaka ett accept eller ett nytt förslag. För att etablerar en säker autentiseringskanal används olika algoritmer. En krypteringsalgoritm (DES eller 3DES), en integritetsalgoritm (MD5 eller SHA1) och Diffie-Hellman key exchange -modellen. Under den andra fasen så förhandlas det om säkerhetsinställningar och nycklar genom att använda den säkra kanalen som etablerades i första fasen. 3.2 och kommersiella WAN-lösningar Fördelar med att använda sig av -tunnlar istället för andra lösningar så som Frame Relay, och andra kommersiella WAN-lösningar är saker som en stor flexibilitet, där du kan koppla upp dig mot ditt lokala nät vart du än är, så länge du har tillgång till internet. Detta innebär alltså att man kan arbeta globalt till relativt låga kostnader. Det är också väldigt smidigt att utöka verksamheten, t.ex. koppla in ett nytt kontor, eller öppna upp för nya medarbetare. Kostnadsmässigt kan det också vara en stor vinst då du bara betalar en engångskostnad för utrustningen, men själva driften inte kostar extra utöver din internetuppkoppling. Jämförelsevis så kan en hyrd WAN-lösning vara väldigt dyr i drift, och inte alls lika flexibel. Nackdelar med att välja en lösning kan vara att det antagligen inte är lika säkert som tjänster du köper i form av dedikerade WAN-lösningar. Även om man vid användandet av försöker att begränsa tillgången till dataströmmen med hjälp av Inkapsling och kryptering i tunneln, så färdas data fortfarande över ett publikt nätverk i form av Internet. Använder man en -lösning så ligger också allt ansvar från startpunkt till slutpunkt på den egna personalen. Vid kommersiella lösningar övergår ansvaret för länken vid demarcation-point. Detta gör att felsökning kan vara mer komplicerat vid användande av. Då medarbetare kopplar upp sig via från mobila enheter, kanske på öppna publika WIFInätverk, så kan detta innebära en säkerhetsrisk. Därför är det viktigt att företag vid implementation av -tjänster, instruerar och utbildar sina medarbetare. Summering Fördelarna med väger i de flesta fall tyngre än nackdelarna, och vi tror att tekniken absolut är någonting som skall övervägas i valet av WAN och transmissions-tekniker. Givetvis får man väga för och nackdelar mot kraven för att från fall till fall avgöra vilken teknik som passar bäst. Formatmall: Laborationsrapport.dot Sidan 3 av 17

4 4 Resultat 4.1 ASA och ASA Uppgiften var att ansluta två stycken Cisco ASA 5505 och med hjälp av en -tunnel initiera kontakt mellan Rysslands subnät och Sveriges subnät i ett hopp. Vi kopplade upp brandväggarna enligt den här ritningen: Vi började med att konfigurera ett management-vlan och interface i brandväggarna via CLI för att senare kunna konfigurera dem med hjälp av ASDM. Vi går inte in så djupt i den delen då det togs upp i en tidigare laboration. Väl inne i ASDM satte vi upp interfaces med IP-adresser för outside och inside: Interface på Ryssland (övre) och Sverige (undre) Formatmall: Laborationsrapport.dot Sidan 4 av 17

5 Innan vi började med -konfigureringen så skapade vi varandras nätverk i form av två olika network objects. I Ryssland la vi till IP-adresserna för Sveriges brandvägg ( ) och inside-subnätet ( ): På Sverige ser det likadant ut fast med Rysslands IP-adresser och när detta var gjort så återstod endast konfigureringen av en -tunnel. För att ställa in så använde vi oss av IPsec Wizard i ASDM. Det går även att göra detta i CLI men vår uppgift var att använda oss utav ASDM. Värt att notera är att Cisco är känt för att göra saker på sitt eget sätt och strular ofta till det med sina egna standarder, den här gången briljerar de med sin wizard. I den fick vi specificera vilken typ av kryptering som skulle användas för Phase 1 och Phase 2. Enligt uppgiften skulle Phase 1 använda 3DES och Phase 2 AES-128. Vi fick också skriva en preshared key som skulle var samma på båda sidorna. Formatmall: Laborationsrapport.dot Sidan 5 av 17

6 Det här är summeringen av -konfigureringen på Rysslands sida enligt Wizard: Sveriges sida: Som ni kan se är konfigurationerna snarlika, där den enda skillnaden är IP-adresserna. För att testa tunneln så körde vi en tracert från Rysslands subnät till Sveriges, för att försäkra oss om att den inte går via Internet: Formatmall: Laborationsrapport.dot Sidan 6 av 17

7 Det funkade! I bakgrunden ser ni reglerna i NAT som säger att trafik från insidan som ska till Site-B-Subnet (Sveriges inside-nät) inte ska NAT:as. Övrig trafik till internet ska NAT:as för att få tillgång. NAT-regler på Sverige-sidan visar samma sak: Formatmall: Laborationsrapport.dot Sidan 7 av 17

8 4.2 pfsense och pfsense Denna del av laborationen gick ut på att upprätta en -tunnel mellan två stycken pfsense- Brandväggar. För att åstadkomma detta så valde vi att installera två virtuella pfsense maskiner på en server. Ovan är en logisk skiss på hur vi kopplade vårt system för laborationen. Det första steget var att sätta upp -tunneln. Först skapade vi en Phase 1-entry vilket innebär kopplingen mellan de två yttre adresserna. Formatmall: Laborationsrapport.dot Sidan 8 av 17

9 Där valde vi vilken adress som skall vara vår Remote gateway alltså vart tunneln skall sluta. Här valde vi också vilken typ av kryptering som skulle användas för inkapslingen av paketen (3DES), och lösenordet HEJROBIN. Vi valde också en Hash-algorithm detta innebär vilken teknik som används för att kontrollera att paket är intakta när de kommer fram. Efter det skapade vi en Phase 2 entry som i sin tur innebär själva tunnelkopplingen mellan de interna nätverken på respektive sida. Alltså specificerar vilka lokala nät som tunnlas. Formatmall: Laborationsrapport.dot Sidan 9 av 17

10 Vi valde också vilken typ av krypteringsteknik som skulle användas för krypteringen av data som skickas via tunneln (AES 128bits). Här skapade vi nyckeln som används vid autentisering för inkapslingen och kopplade den till den adress som skulle autentiseras. För att släppa igenom trafik genom tunneln skapade vi en regel som släppte igenom all inkommande trafik via IPsec. Formatmall: Laborationsrapport.dot Sidan 10 av 17

11 När detta är klart ändras statusen på tunneln och den är aktiv. För att verifiera att den fungerade körde vi en tracert mellan klienter bakom de båda brandväggarna. Av någon anledning försöker den först gå via default gateway -> Internet, men efter ett tag så går den via tunneln, och då i ett hopp. Handledarna (Hans, Martin) har tittat på detta och anledningen är oklar. Formatmall: Laborationsrapport.dot Sidan 11 av 17

12 4.3 ASA och pfsense Uppgiften var att ansluta en Cisco ASA (Ryssland) och en Pfsense-brandvägg (Sverige) med hjälp av en -tunnel och via ett hopp kunna nå till andra inside-nätet. Nätverket är uppkopplat enligt den här ritningen: Cisco ASA Vi började med att konfigurera http server och IP-adress via CLI på ASA för att kunna ansluta och konfigurera med ASDM. Därefter konfigurerade vi IP-adresser på alla interface som skulle användas. Vi skapade nätverksobjekt till Sveriges brandvägg och inside-nät Formatmall: Laborationsrapport.dot Sidan 12 av 17

13 Därefter var det dags att konfigurera -tunneln. Vi använde oss av Wizard för att konfigurera tunneln och här är summeringen: Vi var tvungna att göra lite ändringar efter att vi kört Wizard för att få det att funka. Det vi gjorde var att ändra IKE Negotiation Mode från Main till Aggressive. För att göra det så går man in i Site-to-Site i ASDM, väljer profilen man skapat och trycker på edit. Formatmall: Laborationsrapport.dot Sidan 13 av 17

14 Vanligtvis är Main satt som negotiation mode men vi stötte på problem som löste sig först när vi ändrade det till Aggressive. Formatmall: Laborationsrapport.dot Sidan 14 av 17

15 Pfsense Alla interface var konfigurerade med rätt IP-adress i Pfsense så det vi gjorde var att skapa en tunnel mellan de båda brandväggarna. Vi började med Phase 1: Bilden visar vilka inställningar vi valde. Aggressive var det vi fick igång mot ASA:n. Formatmall: Laborationsrapport.dot Sidan 15 av 17

16 Alla inställningar stämmer överens med andra sidan bortsett från IP-adresserna. Det här är summeringen av våra inställningar på Pfsense-sidan. Formatmall: Laborationsrapport.dot Sidan 16 av 17

17 Under status ser vi att länken är uppe och fungerar, men det enda sättet att vara säker är att testa anslutningen med hjälp av en tracert. Det funkar! Vad man kan läsa ut ur denna tracert är att den först går till subnätets gateway, sen är det raka vägen till hosten via tunneln. Formatmall: Laborationsrapport.dot Sidan 17 av 17