Brandväggsarkitekturer

Transkript

1 Brandväggsarkitekturer Mikael Ericsson Johan Hedlund Uppsala Universitet Datakommunikation II 1 Inledning Datasäkerhet blir allt viktigare. Speciellt när företag ansluter sina nätverk till Internet bör säkerhetsaspekterna beaktas p g a t ex intrångsförsök, virusspridning, informationsstöld samt annan destruktiv verksamhet. Ett sätt att skydda sig är att använda en brandvägg. Alternativet är att ha ett privat nät där man bara tillåter intern kommunikation. Med tanke på kostnaderna är detta inte aktuellt för de flesta organisationer. Det kan även vara lämpligt med brandväggar i privata nät eftersom man kan skydda viktig information inom organisationen. Det finns tre olika huvudtyper av brandväggar, paketfiltrerande-, kretsnivå- och applikations- brandväggar. Vi har valt att titta på de två mest generella typerna, paketfiltrerande- och kretsnivå- brandväggar. 2 Paketfiltrerande brandväggar Ett sätt att ansluta ett subnätverk till Internet via en brandvägg är att använda en så kallad paketfiltrerande gateway. Eftersom man redan behöver en gateway för att kunna ansluta till Internet tillkommer ingen extra hårdvarukostnad för att få en brandvägg, vilket gör det till ett relativt billigt alternativ. Paketfiltrerande brandväggar fungerar på det sättet att gatewayen, som måste vara subnätverkets enda anslutning till Internet, filtrerar både inkommande och utgående paket beroende på en rad kriterier. Dessa kriterier är: avsändare IP-adress, destinations IP-adress, destination TCP-port samt destination UDP-port. TCP/UDP- avsändare port används inte som kriterium vilket kommer tas upp senare. Vidare kan också filtrering ske beroende på vilket interface som paketet kom ifrån och vilket interface det har som destination. Att man kan ha speciella filter för både inkommande och utgående paket gör att man bättre kan kontrollera trafiken och vid gateways med flera än två interface är det absolut nödvändigt. 1

2 Vad en filtrerande gateway gör är att för varje paket som kommer till den så går den igenom en tabell med kriterier och baserat på det så skickar den antingen vidare paketet till angiven destination eller så tar den bort paketet från nätet helt och hållet. Detta brukar refereras som route respektive drop. Om gatewayen finner ett kriterium i sin filtrerings tabell som säger att den ska ta bort ett visst paket har den efter att ha tagit bort paketet från nätverket ett antal möjligheter. 1. Den kan låtsas om som paketet aldrig existerat och bara fortsätta filtrera nya paket. 2. Den kan skicka tillbaka ett meddelande till användaren, via ICMP protokollet, och tala om att paketet har droppats. Utöver detta så kan också gatewayen logga paketet och vilken åtgärd som utfördes på det. 2.1 Filtreringstabeller Det är alltså filtreringstabeller som bestämmer hur en gateway ska behandla ett paket (route/drop). Detta kan göras på en rad olika sätt beroende på vilken gateway som används. Den kan till exempel utföra reglerna i sekventiell ordning tills den hittar en regel som säger om paketet ska droppas eller routas. Den kan också utföra reglerna i ordning av vad de filtrerar på (t.ex. IP destinationsadress eller TCP destinationsport) och inte beroende vilken ordning systemadministratören specificerade reglerna. Vidare kan filtreringen ske i samma ordning som routingtabellen gås igenom. Det vill säga, reglerna utförs på speciella adresser först och sedan på subnät och sist nät. Nedan visas hur en filtreringstabell skulle kunna byggas upp för en gateway tillhörande ett universitet med några olika kriterier för ingående och utgående trafik: Antag att universitetet är ett klass B nätverk *.* som generellt vill förbjuda trafik till Internet. Universitet har dock ett samarbete med ett annat universitet ( *.*) som gör att trafik mellan det andra universitet och ett subnät av det egna nätet ( *) måste tillåtas. Slutligen vet universitet om att på ett subnät ( *) av det andra universitet härstammar det många försök till dataintrång, så trafik från det subnätet måste förbjudas åtkomst till det egna universitetet. 2

3 En filtertabell för ovanstående situation skulle kunna se ut så här: Regel Avsändare Adress Destinations Adress Åtgärd A *.* * Route B * *.* Drop C *.*.*.* *.*.*.* Drop Betrakta nu följande exempel med paket kommande in till gatewayen, samt hur paketen behandlas beroende på om reglerna A-C är applicerade i ordningen de är skrivna (ABC), eller ordningen där signifikanta bitar i avsändare/destinations adressen avgör (BAC). Paket Avs. Adress Dest. Adress Önskad Åtgärd ABC Åtgärd BAC Åtgärd Drop Drop(B) Drop(B) Route Route(A) Drop(B) Route Route(A) Route(A) Drop Drop(C) Drop(C) Som tabellen visar så utför gatewayen önskad filtreringsåtgärder då reglerna utförs i ordning ABC. Men när reglerna utförs i ordning BAC så blir paket 2 felaktigt ej routat vidare. Detta exempel visar på flera av svårigheterna med filtreringstabeller. Först och främst måste man vara väl medveten om hur tabellen parsas i gatewayen, men även om man är det är det lätt att konstruera tabellen fel. Exemplet ovan har t.ex. ett fel som inte är helt uppenbart. Regel B, som till synes reglerar åtkomsten för hackersubnätverket är i själva verket överflödigt! Om man skulle ta bort regeln helt och hållet skulle båda gateway typerna i exemplet ovan parsa tabellen i ordning AC och allt skulle stämma. Det största problemet och säkerhetsriskerna med filtreringstabeller ligger alltså i själva konfigureringen. Tabellerna är lätta att tolka av gatewayen och går snabbt att utföra men de kräver alltid att en systemadministratör först skapat dem. Tabellerna är så pass svåra att konfigurera att de brukar jämföras med att skriva assembler, men de är också svåra är ändra i och framfört allt att testa. Exemplet ovan var ändå ett trivialt 3

4 exempel och man kan lätt föreställa sig svårigheterna i ett komplext system där route/drop beslut ska tas beroende på nät, subnätverk och enskilda IP adresser. 2.2 Problem med paket filtrering IP Fragment När en gateway stöter på paket som är fragmenterade kan den få problem eftersom det bara är det första av de fragmenterade paketen som innehåller information om port nummer. Sedan är det också så att om man t.ex. tunnlar ett protokoll med hjälp av IP fragment så kommer bara det första IP paketet innehålla headern till det tunnlade protokollet. Detta gör att det är väldigt svårt att göra filter beslut på paket som följer efter det första. Det finns ett flertal olika sätt att hantera IP fragment hos gateways. 1. Ta bort det första paketet och routa resten. Om första paketet är borttaget kommer det ändå inte att gå att sätta ihop de fragmenterade paketen till ett fullständigt paket av det tunnlade protokollet. 2. Ta bort alla paket som är fragmenterade. 3. Ha en cache i gatewayen som sätter ihop de fragmenterade paketen, gör ett filterbeslut baserat på det hopsatta paketet och sedan routar paketen fragmenterat eller droppar dem. De vanligaste metoderna är de två första eftersom de är enkla att implementera. Metod ett kan dock ej användas på utgående trafik om man är orolig för informationsläckage IP Source Routing I ett IP paket kan man inkludera så kallad source routing information. Vad det gör är att tala om för gatewayen exakt hur och var den ska routa paketet utan att låta gatewayen själv välja bästa vägen. En attack mot en brandvägg skulle kunna utnyttja source routing informationen för att tvinga ett paket att antingen bli routat in eller ut genom en brandvägg. Det är därför bäst att använda sig av en gateway där man kan ställa in att source routing information ignoreras Falska IP avsändare adress De flesta filterimplementationer är beroende av att IP avsändare adressen är korrekt för att kunna göra rätt filterbeslut på paketet. Det har dock visat sig att det inte alls är svårt att förfalska sin adress i IP paketen och skicka iväg på Internet. 4

5 Som administratör av en brandvägg finns det dock några saker man kan göra för att förhindra det. Det viktigaste är något som redan nämnts tidigare i detta dokument, nämligen kontrollera på vilket interface paketet kom ifrån. Om t.ex. ett paket med en intern avsändare adress och en intern destinations adress kommer in till gatewayen från interfacet som är anslutet till Internet bör detta paket droppas. Vidare måste det tas ställning till om det är värt att ha en del av Internet som har rättighet att skicka paket in genom brandväggen eftersom detta kan utnyttjas av hackers med falska avsändare adresser. Avsändare port kan förfalskas lika lätt och därför brukar den information ej användas i filterna Följder av att TCP/UDP avsändare port ej används Att inte TCP/UDP avsändare porten används som filterkriterium leder till att det är omöjligt att tillåta både ingående och utgående trafik för en viss service utan att öppna upp ett hål för alla andra services. Ta till exempel SMTP. Det går inte att tillåta SMTP trafik till en intern maskin (för inkommande ) och utgående SMTP trafik till vilken adress som helst (för utgående ) utan att det blir så att man tillåter all trafik mellan interna och externa adresser för portnummer större än För att visa detta, betrakta följande filtertabell för ovanstående SMTP situation: Regel In/Ut Trafik Avs. Adress Dest. Adress Dest. Port Åtgärd A Inkommande Extern Intern 25 Route B Utgående Intern Extern >=1024 Route C Utgående Intern Extern 25 Route D Inkommande Extern Intern >=1024 Route E * * * * Drop Regel A och B tillåter tillsammans inkommande SMTP trafik för en extern adress till den interna mailservern på port 25. Regel C och D tillåter tillsammans utgående SMTP trafik på portnummer större än 1023 till portnummer 25. Dessvärre leder detta filter till att trafik från ett internt portnummer >1023 till ett externt portnummer >1023 också tillåtes. Problemet ligger i att även om regel A och B samt C och D gör vad det ska så leder kombinationen B och D till ej önskvärda följder 5

6 Ovanstående problem kan åtgärdas vid TCP trafik genom användande av SYN flaggan som är satt i alla paket som initierar en förbindelse. Vad man gör är alltså då att i filtret specificera att paket med SYN flaggan satt ej routas. Detta fungerar dock inte för UDP eftersom datagram inte har något initieringspaket. 3 Brandväggar på kretsnivå. Brandväggar på kretsnivå förmedlar TCP- och UDP- anslutningar. Användaren ansluter till en TCP- eller UDPport på bandväggen som i sin tur ansluter till en värddator på utsidan av brandväggen. Under anslutningens tid så fungerar brandväggen som ett relä som skickar bytes med information fram och tillbaka. Ofta vill man ansluta till en viss specifik adress. Då måste ett protokoll användas mellan användaren och brandväggen. Detta protokoll beskriver vilken dator och tjänst man vill ansluta till. I socks, som jag kommer att beskriva mer ingående nedan, så används IP-numret för att beskriva vilken dator man vill ansluta till. Om allt går bra vid anslutningen så kommer trafiken därefter flöda fritt genom brandväggen. Normalt så bryr denna typ av gateway inte sig om vad som passerar igenom den när väl en anslutning är upprättad. Varje allmän lösning med en brandvägg på kretsnivå kommer att innebära att brandväggen måste ha en port som den lyssnar efter inkommande trafik på. Det måste därför finnas vissa säkerhetskontroller för brandväggen. Detta kan inkludera tidsbegränsningar på hur länge en port kan användas, specifikationer för en lista över datorer som tillåts ansluta från utsidan av brandväggen och även autentisering av användare med hjälp av användarnamn och lösenord. Ett annat problem med en brandvägg på kretsnivå är att det behövs nya klientprogram för att kunna utnyttja dessa. Fastän det inte är stora ändringar i koden som behövs blir det ett stort arbete när många program skall gås igenom och modifieras. Det kan också vara svårt att få tag i källkod till applikationerna för de olika plattformar som används. 3.1 Socks Det finns olika implementationer av brandväggar på kretsnivå. Den jag har tittat närmare på är socks vilket är den i dag vanligaste lösningen. Socks arbetar på OSI:s sessionslager. 6

7 OSI lager Applikation Brandväggstjänst Applikationsbrandvägg Presentation Session Transport Nätverk SOCKS Paketfiltrerande brandvägg Paketfiltrerande brandvägg Datalänk Fysiskt Socks består av en serverimplementation och ett ersättningsbibliotek för de vanliga nätverksfunktionerna. Om man vill konvertera en applikation behöver man bara byta ut de vanliga socketfunktionsanropen mot de motsvarande socksanropen. För närvarande existerar det två versioner av socksprotokollet, version 4 och version 5. Den största skillnaden mellan de olika versionerna är att version 5 innehåller användarautentisering. För en användare på nätet bakom brandväggen så är det ingen större skillnad att använda programmen med socks, skillnaden är att all trafik passerar genom sockd (socksdaemonen) på brandväggsdatorn. Denna transparens är möjliggjord genom socksfunktionerna som programmen använder i stället för de vanliga socketfunktionerna. 3.2 Socksbiblioteket Socksbibliotekets anrop skapar en anslutning till sockd på brandväggsdatorn och överför information så att daemonen kan utföra nätverks operationerna som om det vore den som var ursprunget för anropen. All data som sedan daemonen tar emot skickar den vidare till den som ursprungligen begärde datan. Socksbibliotekets funktioner är designade för att vidarebefordra nätverksanslutningar till socksdaemonen som körs på brandväggen. Funktionsnamnen inleds med ett begynnande R framför de normala C-funktionerna som de ersätter. Funktionerna som finns är: Rconnect, Rbind, Rlisten, Rgetsockname och Raccept. Om man har applikationer som använder dynamiskt länkade bibliotek så kan man addera socksstöd transparent genom att byta ut biblioteken till nya bibliotek som använder socks. Denna möjlighet att addera socks till existerande applikationer är enkelt och tillförlitligt. Ju mer transparent ett säkerhetssystem är desto bättre är det. 7

8 3.3 Socksdaemonen - sockd Socksdaemonen sockd startas av inetd och tillåter endast anslutningar från betrodda datorer. Konfigurationsfilen för sockd används för att avgöra om man skall tillåta eller avvisa anslutningar som görs till brandväggen, den innehåller information om tillåtna adresser, användarnamn och lösenord.. Samtliga anslutningsförsök loggas med användarnamn och ursprungsdatorns adress. Sockd sparar informationen via UNIX sysloggränssnitt, information som sparas är: Obehörig anslutning Lyckad anslutning Resursfel 3.4 Socksprotokollet Protokollet som används mellan socksrutinerna och brandväggen betstår av tre stycken kommandon: CONNECT, BIND och UDP ASSOCIATE. Daemonen utför de önskade operationerna i socksprotokollet; CONNECT, BIND och UDP ASSOCIATE och uppför sig sedan som en överföringspunkt för socketanslutningar. CONNECT anslutningar börjar med ett anrop till Rconnect funktionen från datorn innaför brandväggen och gör så att daemonen skapar en anslutning till fjärrdatorn och returnerar status. Nu kan applikationen skriva och läsa ifrån socketanslutningen på brandväggen som om den inte fanns där, socketen tillsammans med brandväggen kommer att fungera som en brygga som för trafiken vidare. Ett BIND-anrop är mer komplicerat. Det börjar med ett Rbind anrop som skapar en ny serversocket på en ledig port på brandväggen. Om allt går bra så returernar sockdporten på brandväggen lyckad status. Daemonen antar sedan att bind-anropet följs av ett listen kommando och accept och utför sedan dessa operationer. Klienten anropar sedan Rlisten som fungerar som en stub-funktion vilken alltid returnerar sant. Nästa anrop till Raccept väntar på ett andra paket från daemonen och innehåller värdadressen till fjärrdatorn och portnumret som anslutningen kom ifrån. Detta andra paket kan också returnera ett felmeddelande som kan bero på antingen ett resursfel eller en anslutning olik den som angavs i bindanropet. Nu är anslutningen etablerad och all kommunikation genom socketen kommer att gå igenom brandväggen. Vid UDP ASSOCIATE så skapas en TCPanslutning mellan klienten och brandväggen. Denna TCP anslutning kommer sedan att vara kvar så länge som UDPassociationen används och UDP associationen avslutas när TCPanslutningen stängs. Via denna TCPanslutning så returneras det portnummer på brandväggen som skall 8

9 användas för UDPtrafiken. Klienten kapslar sedan in varje paket med en extra UDPheader som sedan sockd tar bort innan den skickar vidare paketet till destinations datorn. Sockd kommer inte att vidarebefordra några datagram om de inte har samma destinations- adress och port samt samma avsändar- posrt och adress som angavs vid UDP ASSOCIATE kommandot. 3.5 Problem med socks ICMP Eftersom socks arbetar på OSI:s sessionslager innebär detta att socks inte vidarebefodrar Internet Control Message Protocol Messages (ICMP). Detta leder till två saker: Ping kommer inte att fungera genom en socks brandvägg. Felmeddelanden kommer inte att skickas tillbaka till applikationer. Eftersom ping är en sådan grundläggande tjänst och vanligt använd för att bedöma nätverksanslutningar kan detta ses som ett allvarligt problem. I IP-protokollet står ICMP för status och felmeddelanden. Dessa vidarebefordras genom TCP/IP stacken och rapporteras genom ett socketfel till applikationen. Därför är det viktigt att låta applikationerna få veta när det sker fel som genererar ICMPmeddelanden. Den enda gången en applikation kan få ett ICMP fel är när socksbrandväggen försöker ansluta till fjärrservern för första gången. Det finns inget sätt att meddela ett fel när kommunikation satts i gång mellan klienten och servern. Som tur är så är många brandväggar en kombination av flera komponenter och där ingår ofta en ICMP proxy som släpper igenom ping och andra ICMPmeddelanden transparent. 3.6 Prestanda Socks arbetar som bekant på sessionsnivå. Detta gör att när en klient ansluter till en värd utanför brandväggen så kommer den att autentisera varje TCP- och UDP- socket individuellt. Detta innebär bra säkerhet och kontroll men det har också sina baksidor. För varje anslutning som görs måste autentiseringen göras om och detta medför extra trafik, det finns ingen möjlighet att öppna en anslutning mellan en klient och brandväggen och sedan använda denna för all trafik som skall skickas. Socks skall fungera på detta sätt och om man istället vill ha en permanentförbindelse så bör L2TP/PPTP eller IPSec användas. 9

10 3.7 Nästa generation av SOCKS Socks har redan nu en stor marknadsandel och ökar med snabb takt. Ett antal företag arbetar med IETF Secure Transport Proxy arbetsgrupp för att utveckla nästa generation av socks. Detta arbete pågår just nu. En jämförelse av de olika socks versionerna görs i nedanstående tabell: Version Viktiga funktioner Vinster SOCKS v4 IP adress maskering Säkerhet Det interna nätverkets struktur döljs för yttervärlden Administration Icke-registrerade IP-adresser kan anslutas till internet genom att man översätter privata adresser i det interna nätverket till riktiga adresser innan paket skickas ut på internet. Generellt brandväggsstöd för TCP applikationer Säkerhet Alla TCPapplikationer kan passera brandväggar oavsett om applikations proxybrandväggar stödjer applikationerna eller inte. SOCKS v5 Generellt brandväggsstöd för UDPapplikationer Alla TCP- och UDP- applikationer kan nu passera säkert genom brandväggar. Stark användarautentisering Möjligt med autentisering, kryptering, tunnling och nyckelhantering/utbyten. Applikationsoberoende autentisering på användarnivå är en unik möjlighet. Applikation-proxy och paketfiltrerande brandväggar erbjuder inte detta. Flexibilitet och frihet att välja från olika industristandarder beroende på kraven. OBS: Om man adderar kryptering så kan socks användas som en VPN teknologi. Policyhantering på användarnivå, flexibel åtkomst kontroll (ACL:s) Möjliggör policyhantering för olika individer till specifika resurser vissa tider. Intern/Extern DNS eller DNS proxy. Enklare konfiguration (kompatibel med intern DNSkonfiguration) Tillåter klienter att ansluta utan att veta om eller från om destinations IP-adressen. Denna möjlighet är speciellt användbar när man vill göra end-to-end anslutningar över internet mellan två nät som använder privata eller icke globala adresser. Samlad access hantering Central bevakning i form av loggning, filtrering, notifiering och cachning SOCKS v6 IP Multicast Olika nivåer av åtkomst för olika deltagare i IP Multicast grupper. IPSEC Integrering SOCKS erbjuder stark användar/applikations-nivå autentisering för IPSec baserade nätverk, medan IPSec är inriktat på att säkra varje IP-anslutning. Både SOCKS och IPSec kan arbeta nära tillsammans för att erbjuda både effektivt och flexibel nätverkspolicyhantering. IPSec möjligheter till integration med IP v6 hänvisar till inbyggd intelligens i SOCKS för att stänga av kryptering för IPSecanslutningar. Kedjad autentisering (vilken server som helst i kedjan kan autentisera klienten) Ger en end-to-end autentiserings model. Tillåter flexiblare hantering av åtkomstkontrollen. Generell bind (acceptera multipla anslutningar från en klient) Fjärrstyrd klient installation och konfiguration Multiplexar alla sessioner mellan klienten och servern Tillåter server applikationerna som befinner sig bakom SOCKS servern att erbjuda sina tjänster utan att avslöja sina adresser Förbättrad administration av klienter. Ökad prestanda 10

11 4 Slutsats Brandväggar är nödvändigt. Det har vi insett, problemet är bara hur man skall implementera dem för att få god säkerhet. Fördelar med paketfiltrerande brandväggar är att hårdvaran är billig och att de är relativt snabba. Den största nackdelen med paketfiltrerande brandväggar är filtreringstabeller är svåra att konfigurera och testa. Detta kan leda till säkerhetsbrister trots att man tror sig ha en fungerande brandvägg. En ytterligare nackdel är att man inte döljer strukturen på det egna subnätverket vilket gör det möjligt för en eventuell inkräktare att samla information om hur nätverket är uppbyggt. Fördelen med en brandvägg på kretsnivå är att de är mycket flexibla när det gäller att erbjuda tjänster som kryptering och autentisering. Den största nackdelen är att program måste anpassas för att utnyttja brandväggen som arbetar på kretsnivå. Detta problem kommer dock minska med tiden då fler och fler program designas med tanke på säkerhet från början. Redan i dag har bland annat Internet Explorer, Netscape Navigator och Mirabilis ICQ stöd för SOCKS. Det finns även en lösning som kallas SOCKScap som tar hand om all inkommande och utgående trafik genom IP-stacken och ser till att dessa går genom SOCKS tjänsten på brandväggen. Att välja brandvägg kan därför vara svårt. Det sker en snabb utveckling inom området och man vet inte vilka hot som väntar i framtiden. Ofta kan en kombination av olika typer, s k hybridbrandväggar, ge ett fullgott skydd samt bra funktionalitet för de applikationer man vill använda. Om vi skulle bli tvungna att välja mellan en paketfiltrerande brandvägg eller en kretsnivå brandvägg för vårt eget nät så skulle vi välja en brandvägg baserad på SOCKS teknologin. 11

12 5 Källhänvisningar Firewalls and Internet Securtiy Repelling the Willy Hacker William R. Cheswick, Steven M. Bellovin Addison-Wesley 1994 Network (In)Security Through IP Packet Filtering D. Brent Chapman Tillgänglig på adressen: SOCKS David Koblas, Michelle Koblas 1992 Tillgänglig på adressen: I underkatalogen [Koblas and Koblas 1992] SOCKS The Border Service Enabler A technology Backgrounder SOCKS Summit 1998 September 15-18, 1998 Unified Policy Management and Border Control Tillgänglig på adressen: RFC 1928 Socks protocol version 5, RFC 1928 M. Leech, M. Ganis, Y. Lee, R. Kurtis, D. Koblas, L. Jones, mars 1996 Tillgänglig på adressen: 12