TCP/IP-baserade attacker och deras motmedel

NADA Numerisk analys och datalogi Department of Numerical Analysis Kungl Tekniska Högskolan and Computer Science 100 44 STOCKHOLM Royal Institute of Technology SE-100 44 Stockholm, SWEDEN TCP/IP-baserade attacker och deras motmedel Håkan Svensson TRITA- Examensarbete i Datalogi om 20 poäng vid Programmet för datateknik, Kungliga Tekniska Högskolan, maj 2003 Handledare på Nada var Stefan Nilsson Examinator var Stefan Arnborg

Sammanfattning TCP/IP är uppsättningen protokoll som används på Internet. Rapporten förklarar hur egenskaper i TCP/IP kan missbrukas för att slå ut värdar kopplade till TCP/IPnätverk. Därefter beskrivs och bedöms olika sätt att motverka detta. Till sist ges rekommendationer för vilka åtgärder klienter respektive operatörer bör vidta. Denial of Service Attacks in TCP/IP and Their Countermeasures Abstract TCP/IP is the protocol suite used on the Internet. This thesis explains how features of TCP/IP can be used to deny access to hosts connected to TCP/IP networks. Then, different ways of preventing this are described and evaluated. Finally, recommendations are given for what measures clients and Internet service providers should take. Jag vill tacka min handledare på KTHNoc, Fredrik Widell, för hans hjälp och insikter.

Innehåll 1 Till läsaren................................ 1 2 Denial of Service-attacker........................ 1 3 En översikt över attacker......................... 1 3.1 Fragmentattack.......................... 1 3.2 Fragmentattack med ogiltiga fragment............. 2 3.3 SYN-flooding........................... 2 3.4 Motmedlet mot motmedlet: Stream/raped........... 3 3.5 Om tekniken saknas, använd råstyrka............. 3 3.6 Reflektorsattacker (Smurf/fraggle)............... 4 3.7 Applikationsbuggar........................ 4 4 Motmedel................................. 5 4.1 SYN cookies........................... 5 4.2 Attackdetektion.......................... 6 4.3 Brandväggar och paketfiltrering................. 6 4.4 Varför paketfiltrering inte fungerar............... 7 4.5 Paketspårning........................... 8 4.6 Routing som motmedel..................... 9 5 Rekommendationer för klientnät.................... 10 5.1 Skydda mot allmänna dataintrång............... 10 5.2 Installera säkerhetsuppdateringar................ 10 5.3 Brandväggar botar inte allt................... 10 5.4 Stoppa förfalskade avsändaradresser.............. 11 5.5 Bli inte en attackreflektor.................... 11 5.6 Ha en heterogen datormiljö................... 11 6 Rekommendationer för operatörer.................... 11 6.1 Var redo.............................. 11 6.2 Motarbeta förfalskade avsändaradresser............ 11 6.3 Samarbeta om routing till tomma intet............. 12 6.4 Skydda era routingtabeller.................... 12 7 Slutsats.................................. 12 Referenser.................................... 13 A Förkortningsordlista........................... 15

1 Till läsaren Denna rapport behandlar säkerhet i datornätverk som använder protokolluppsättningen TCP/IP, i synnerhet Internet. Den är skriven för de som vill sätta sig in i de risker som finns inneboende i TCP/IP, främst på nätverkslagret, och förutsätter att läsaren redan är insatt i TCP/IP. Rapporten tar inte upp generell datasäkerhet, och säkerhetsproblem på applikationslagret tas bara upp om de orsakar nätverksstörningar. Sårbarheter som beror på den mänskliga faktorn ligger utanför denna rapports område. 2 Denial of Service-attacker Det vore en underdrift att säga att TCP/IP är en väl beprövad uppsätting protokoll. Det finns dock sätt att missbruka egenskaper i protokollen, så att en ensam anfallare kan orsaka störningar hos en värd som drabbar alla som försöker använda den. Att en värd på detta sätt görs obrukbar kallas för en Denial of Service-attack: den som attackerar nekar alla andra tillgång till de tjänster den attackerade värden erbjuder. Detta sker inte enbart genom att medvetet skapa paket som är ogiltiga enligt standarden och som är utformade för att en mottagare ska ha svårt att behandla dem. Det kan även ske genom att giltiga pakettyper används i mängder som är tusentals gånger större än i normal trafik. Det är svårt att säga hur stora riskerna att bli utsatt är. Det finns ingen tillförlitlig statistik att tillgå, och min åsikt är att mörkertalet är stort eftersom företag är ovilliga att erkänna brister i sin datasäkerhet. Attacker av denna typ sker dock, och mål har varit stora, vitt använda tjänster, till exempel servrar för chatnätverket IRC (Internet Relay Chat). Även webbens giganter Yahoo och Ebay har varit drabbade, vilket fick stor publicitet. En stor attack skedde i oktober 2002 mot Internets 13 rotnamnservrar, som om den hade fullbordats skulle ha slagit ut DNS totalt för hela världen. [5] 3 En översikt över attacker Följande är exempel på olika attacker. Jag har valt att ta upp de attacker som har varit allvarligast eller, som i fallet SYN-flooding, är allmänt intressanta för protokolldesign. Listan är ganska utförlig, men jag varnar läsaren för att tro att det här är allt som finns. 3.1 Fragmentattack I och med att paket i IPV4 kan fragmenteras, måste en mottagare behålla fragment av ofullständiga paket i väntan på att de övriga fragmenten anländer så att det fullständiga paketet kan behandlas. Detta kräver att mottagaren måste hålla paketfragment i minnet, och veta när ett annat IP-paket är ett nytt fragment av ett tidigare. 1

En anfallare kan missbruka denna del i IP-protokollet genom att skicka fragmenterade paket där bara vissa av fragmenten någonsin skickas. Mottagaren kommer då att använda oproportionerligt mycket minne och processorkraft för att försöka sätta ihop paket som inte går att sätta ihop. En anfallare kan även förfalska avsändaradressen på de fragmenterade paket som skickas med en ny falsk avsändare för varje paket. Det försvårar ytterligare för mottagaren att försöka sätta ihop paketen och har som bieffekt att attacken blir svårare att stoppa. 3.2 Fragmentattack med ogiltiga fragment Fragmentering av IP-paket är en krånglig del av protokollet och har varit svår att skapa robusta implementationer av. Det finns flera exempel på attacker där fragmentering har använts för att skapa paket som TCP/IP-stackar inte har klarat av att hantera. Senare versioner av operativsystem är inte längre sårbara för just dessa attacker, men de är exempel på att fragmentering historiskt sett har varit en problematisk del av IP. Exempel 1: Teardrop (överlappande fragment) Teardrop-attacken består i att paket skickas med fragment som överlappar varandra. [7] Standarden förbjuder detta, och dessa paket har utnyttjat buggar i TCP/IPstackar där sådana paket har fått buffertar att överskridas. Detta har varit extra förödande eftersom paketen hanteras av operativsystemets kärna och koden körs med kärnans privilegier. Exempel 2: Ping of Death (fragmenterade paket större än 64 Kibyte) Smeknamnet som den här attacken fick är ganska missvisande, eftersom attacken kan tillämpas på alla typer av IP-paket och inte är specifik för pingpaket (ICMP ECHO). Ett IP-paket får vara högst 64 Kibyte stort, eftersom storleksfältet i IP-huvudet är 16 bitar långt. I Ping of Death-attacken skickas ett fragmenterat paket där sista delen är ogiltigt lång, så att paketet totalt blir över 64 Kibyte när det sätts samman. [2] Detta har fått buffertar i mottagarens TCP/IP-stack att överskridas, med samma ödesdigra resultat som för Teardrop-attacken. 3.3 SYN-flooding SYN-flooding är typexemplet på hur en anfallare med små medel kan orsaka att en tjänst på en attackerad värd blir helt onåbar. I en normal TCP-session inleder klienten med att skicka ett paket med SYN-biten satt, en särskild bit som indikerar ett uppkopplingsförlopp. Därpå svarar servern med att skicka ett svar med SYN- och ACK-bitarna satta, där ACK-biten tillsammans med ett ACK-nummer används för att bekräfta att ett paket tagits emot. Klienten 2

skickar ett svar med ACK-biten satt, vilket skapar en upprättad TCP-session. Alla ACK-nummer ska matcha de sekvensnummer som mottagits från andra sidan, så servern behöver komma ihåg sekvensnumret på den SYN/ACK den skickade för att jämföra med den ACK som kommer in. Under en SYN-flood-attack skickar en anfallare SYN-paket utan avsikt att någonsin etablera en uppkoppling. När den attackerade värden skickar sitt SYN/ACKsvar allokerar den resurser för att veta att en uppkoppling ska skapas när andra sidan skickar sin ACK. Dessa resurser är ändliga. Till slut kommer alla tillgängliga TCPsessioner den attackerade värdens operativsystem kan hantera att vara upptagna med att vänta på svaret på sin SYN/ACK, som aldrig kommer. Detta är en exploaterbar del i TCP-protokollet, och forskare varnade att den kunde missbrukas innan detta skedde i stor skala. TCP-standarden anger att en värd ska vänta två gånger maximala livstiden för ett segment efter att ha skickat sin SYN/ACK innan den ger upp. Denna tid varierar från operativsystem till operativsystem, men är alltid över en minut, vilket är gott om tid för den som attackerar att hinna skicka tillräckligt många SYN-paket för att uttömma resurserna hos det mottagande operativsystemet. [8] 3.4 Motmedlet mot motmedlet: Stream/raped Motmedel mot de attacker som här gås genom är en egen del av rapporten. Ett motmedel mot SYN flooding-attacken är så kallade SYN cookies, som behandlas utförligare i avsnitt 4.1. Kortfattat innebär SYN cookies att inga resurser används för att hålla reda på vilka ACK man väntar för att upprätta en uppkoppling. I stället läggs data in i den SYN/ACK man skickar så att man vet att den ACK man sedan får ska föra in TCP-sessionen i ett upprättat tillstånd. Detta innebär att för en ny ACK som värden tar emot som inte matchar en etablerad uppkoppling, utför den beräkningar för att veta vad som ska etableras. I och med att SYN cookies innefattar kryptografi (se avsnitt 4.1) kan dessa beräkningar vara processorkrävande. Stream och raped-attackerna utnyttjar detta genom att skicka stora mängder ACK-packet utan motsvarande TCP-session med förfalskade avsändaradresser och slumpmässiga sekvensnummer. [9] En betydande del av den attackerade datorns processorkraft kommer då att gå åt till att göra de beräkningar som krävs för SYN cookies. Detta orsakar en avsevärd prestandaförsämring hos den attackerade värden. 3.5 Om tekniken saknas, använd råstyrka Ett effektivt sätt att göra en dator onåbar är att helt enkelt använda hela den datorns tillgängliga bandbredd. Detta kräver inte några djupare kunskaper om TCP/IP, utan att den egna bandbredden är större än mottagarens. Attacken sker som regel med falska avsändaradresser i IP-paketen, vilket försvårar både spårning och hejdande av attacken. 3

Distribuerade attacker De mest omskrivna attackerna, de på Yahoo och Ebay som nämndes i inledningen, har varit distribuerade attacker. I sådana attacker har många datorer koordinerats för att utnyttja mer bandbredd. Detta har varit nog för att slå ut även några av webbens mest välbesökta platser, som har oerhört mycket mer kapacitet än en genomsnittlig Internetförbindelse. För att koordinera en samlad bandbreddsattack används ofta datorer som tagits över för att användas i attacker utan att datorns ägare är medveten om det. Detta kan ske på flera olika sätt. Vanligt är så kallade trojaner program som utger sig för att göra en sak, men egentligen installerar en klient som utför en attack på begäran. Det som skiljer en distribuerad attack från andra bandbreddsattacker är den enormt mycket högre trafiken. I och med att den kommer från många olika källor blir den även mycket svårare att spåra. Principen är dock densamma. 3.6 Reflektorsattacker (Smurf/fraggle) Det finns ett sätt att utnyttja förfalskade adresser på som kan få ett paket att generera många svar till en attackerad värd. Om ett paket skickas till broadcastadressen för ett nät med offret som förfalskad avsändare, kommer alla som sitter på detta nät att skicka ett svar till offret. Detta kan ske med såväl ICMP ECHO-paket (denna attack har fått smeknamnet Smurf ) som UDP-tjänsten echo (vilket kallas Fraggle). [10] Detta har en dubbel effekt. Dels kan ett enda paket på detta sätt mångfaldigas och skapa mer trafik än vad anfallaren själv klarar av. Dels är trafiken offret tar emot giltiga svarspaket från nätet som broadcastmeddelandet skickas till. Det senare gör attacken ytterst svår att spåra då det inte går att veta vad som skapade svaren. 3.7 Applikationsbuggar Det finns även exempel på hur buggar i applikationer har använts för att slå ut datorer. Detta ligger egentligen utanför denna rapports område, men man bör vara väl medveten om att ett paketfilter inte löser några problem om det är möjligt att göra skada genom att använda vad som synes vara en vanlig HTTP-förfrågan (som i fallet Code Red). Code Red/Nimda Code Red och Nimda är två maskar som spreds genom säkerhetshål i webbservern Internet Information Server. Enbart deras försök att sprida sig och hitta andra värdar var tillräckligt för att använda nog bandbredd för att skapa störningar. Code Redmasken förtjänar ett särskilt omnämnande eftersom den innehöll kod för att utföra en distribuerad attack på Vita Husets webbserver. [4] 4

Slammer Slammer-masken infekterade i slutet av Januari 2003 värdar som kör Microsoft SQL server och fick dem att konstant skicka nya SQL-frågor. Slammer var mycket aggressivare i sina försök att sprida sig än Code Red eller Nimda, och fortsatte kontinuerligt att skicka paket. Bandbredden som Slammerinfektionen använde var nog att slå ut 5 av världens 13 rotnamnservrar. [1] RTM-masken Masken som slog ut Internet 1988 utnyttjade huvudsakligen buggar i SMTPservern Sendmail och finger-servern i BSD 4.3. [14] Skadan den orsakade kom inte från trafiken den skapade i sina försök att sprida sig, utan berodde på att den infekterade sin egen värd flera gånger om och skapade flera processer tills operativsystemets minne tog slut eller gränsen för antalet processer överskreds. 4 Motmedel Det finns många olika sätt att försvara sig mot dessa attacker. Vissa är avsedda att stoppa en typ av attacker, andra är mer generella. 4.1 SYN cookies SYN cookies är ett motmedel specifikt mot SYN-flooding. Som nämndes i avsnitt 3.3 om denna attack, måste en lyssnare av en TCP-uppkoppling i normala fall reservera resurser för att hålla reda på vem den har skickat en SYN/ACK till. Antag att en lyssnare skulle ta emot den ACK som skulle föra TCP-sessionen i ett etablerat tillstånd utan att hålla reda på vilka SYN/ACK den har sänt. En anfallare skulle då kunna skicka ett ACK-paket med förfalskad avsändaradress. Detta skulle inleda en etablerad TCP-session utan att någon handskakning ägt rum. Med en normal TCP-session är man någorlunda säker på att avsändaradressen inte är förfalskad, i och med att man har fått ett paket tillbaka som stämmer med den SYN/ACK som sänts. Att hålla reda på vilka SYN/ACK-paket som sänts är alltså nödvändigt av säkerhetsskäl. SYN cookies går ut på att välja sekvensnumret på SYN/ACK-paketet som sänds så att den ACK man får räcker för att säkerställa att den verkligen är ett svar på något man skickat. Detta sker genom att port och IP-nummer för båda sidor av TCP-sessionen samt ett tidsberoende värde körs genom en kryptografiskt stark envägsfunktion, och detta bäddas in i sekvensnumret. De höga bitarna i sekvensnumret väljs för att tillfredsställa kravet att sekvensnummer ska öka långsamt för att undvika att de slår runt. [3] När ett ACK-paket sedan anländer beräknas denna funktion igen för att se om den stämmer med det inkommande ACK-numret. 1 1 ACK-numret är inkommande sekvensnummer plus ett. 5

Detta innebär att när en SYN tas emot, görs en beräkning utan att något lagras hos mottagaren. En SYN-flood kommer således inte att bygga upp någon lista över väntande uppkopplingar hos mottagaren som den annars skulle göra. Som tidigare nämnts är funktionen som SYN cookies använder för att beräkna sekvensnumret tidsberoende. Därför måste den beräknas flera gånger för olika tider för att bekräfta ett inkommande ACK-paket. Vad detta kan leda till beskrivs i avsnitt 3.4. 4.2 Attackdetektion IDS-program (Intrusion Detection System) avlyssnar det medium de sitter på för att känna av attacker. Alla de attacker som tidigare beskrevs har kännetecken. Exempelvis är en obetydlig del av normal IP-trafik fragmenterad. Dels sitter användare typiskt på Ethernet-nätverk eller modem, som har lägst MTU i kedjan. Dels utför senare versioner av operativsystem, till exempel Linux, Path MTU Discovery för att undvika att sända fragmenterade paket. En stor och plötslig ström av fragmenterade paket skulle således kunna vara en indikator på att någon håller på att utföra en attack. IDS-program är dock just detektorer och utför typiskt inte några motåtgärder själva annat än att meddela någon människa. En undersökning som gjorts [11] visar på att alla de IDS-program som testades gav så många falska varningar att de riktiga attackerna inte gick att urskilja. Vissa IDS-program kunde inte hantera de trafikmängder de testats med och kraschade flera gånger. Undersökningen testade många olika IDS-program, både kommersiella och fria, som använde såväl regelbaserade som statistiska metoder. Ett regelbaserat IDSprogram försöker finna kännetecken för specifika attacker, medan ett som arbetar statistiskt försöker hitta abnormt stora avvikelser från normal trafik. Undersökningen visade på att inget alternativ kunde identifiera verkliga attacker utan att ge en ohanterbar ström av falska alarm. Någonting man bör hålla i minnet är att osannolika saker sker oftare än man tror. Antag att ett program håller reda på många olika variabler (andel fragmenterade paket, andel TCP-paket med SYN-biten satt som exempel). Antag vidare att för varje enskild variabel, är gränsen för att ett alarm ska ges satt så att det är osannolikt att alarmet sätts igång av normal trafik. Problemet är att med många variabler kommer det att vara sannolikt att något av alarmen kommer att ges. Ett annat, om möjligt större, problem är: Vad är normal trafik? Nättrafik tenderar att komma i klumpar, att variera mellan dygnets timmar beroende på när användarna är vakna, och vara allmänt svår att analysera. Man ska också hålla i minnet den så kallade slashdoteffekten [13] att en populär webbplats länkar till något och skapar ett enormt uppsving av trafik som inte är menad som en attack. 4.3 Brandväggar och paketfiltrering Något som förekommer ofta är att man försöker ta bort de paket som är farliga. Detta är behäftat med flera problem som du kan läsa ovan är det inte alls lätt att 6

avgöra vilka paket som är farliga! Ofta försöker man se till att trafik utifrån enbart når de tjänster man explicit vill göra tillgängliga. Detta är vad konventionella brandväggar ofta gör. Det kan vara en god del i ett allmänt säkerhetstänkande, eftersom många operativsystem i en normal installation kör tjänster användarna kanske inte själva är medvetna om. Denial of Service-attacker är dock så gott som alltid ämnade att slå ut en allmänt tillgänglig tjänst, vilket gör denna typ av brandvägg irrelevant. En maskin som står bakom NAT (Network Address Translation, ett sätt att låta flera datorer dela på en IP-adress) är visserligen svår att attackera, men det är för att den inte går att nå överhuvudtaget utan specialåtgärder i NAT-routern. Vissa brandväggar saluförs med löften om att de kan stoppa attacker. Dessa löften går inte att bekräfta på grund av produkternas slutna natur. Vi vet helt enkelt inte vad de egentligen gör, och som syntes i förra avsnittet finns det inga produkter som ens kan upptäcka attacker tillfredsställande. Något som är alltför vanligt förekommande är att de flesta ICMP-paket, inklusive ICMP ECHO, rensas av en brandvägg. Detta gör att de datorer som står bakom den brandväggen bryter mot kravet i standarden 2 att en värd måste svara på ICMP ECHO. Trafikbegränsning (Rate Limit) Vissa routrar stöder att gränser sätts för hur ofta vissa paket, till exempel pingar, får förekomma per tidsintervall. Detta stöds dock inte i alla routrar, och även om det stöds är frågan hur gränserna ska sättas. Som tidigare nämnts kommer trafik ofta klumpvis. Dessutom finns risken att till exempel en SYN-flood gör att ingen överhuvudtaget kan koppla upp sig mot någon som sitter bakom routern, eftersom gränsen för antalet SYN-paket nåtts. 4.4 Varför paketfiltrering inte fungerar Det största problemet med paketfiltrering är att om du som ISP-kund filtrerar paket på din sida, hjälper det överhuvudtaget inte mot bandbreddsattacker. Din bandbredd är redan uppäten av attacken, och hur många paket du än slänger på din sida kommer ingen annan igenom. Som mottagare kan du heller inte gardera dig mot förfalskade paket. Paket med förfalskad avsändare kan bara filtreras av nätet som släpper ut dem. Det är god sed att se till att paket bara lämnar ditt nät om de har en avsändaradress inom det, men du kan inte förlita dig på att resten av Internet gör det. Ett annat, mer praktiskt problem är att många vanliga Cisco-routrar har prestandaproblem med paketfilter. Den filtrering som man vill göra för att motverka förfalskade avsändaradresser, Reverse Path Forwarding, går ut på att routern slår upp vilket gränssnitt hos routern avsändaradressen motsvarar. Detta kontrolleras så att det stämmer med vilket gränssnitt paketet egentligen kom från. Problemet 2 STD0003, Requirements for Internet Hosts Communication Layers, före detta RFC1122 7

med detta är att två routeuppslagningar görs för varje paket, en för avsändar- och en för mottagaradressen. Detta fördubblar alltså belastningen på routern om inte huvudprocessorn kan delegera ut denna kontroll till gränssnittskorten, vilket enbart är möjligt i vissa routrar. Många attacker sker dessutom som nämnts i avsnitt 3.7 genom att utnyttja sårbarheter i applikationer. För att upptäcka dessa räcker det inte att bara inspektera pakethuvudet, utan själva innehållet måste också undersökas. Detta är dyrt i processorkraft att göra. Dessutom är det svårt att hålla sig a jour med alla nya sårbarheter som upptäcks i applikationer. Slammer- och Code Red-maskarna (se avsnitt 3.7) utnyttjade sårbarheter som hade varit kända i åtminstone sex månader och där säkerhetsuppdateringar fanns tillgängliga. 4.5 Paketspårning Vid en bandbreddsattack måste paketen filtreras tidigare än hos mottagaren. Här är problemet att mottagaren typiskt inte har någon kontroll över några routrar andra än sina egna. Det finns flera förslag på hur routrar uppströms kan hjälpa till att spåra eller motarbeta en attack. Traceback[6] För varje paket en router som stöder Traceback vidarebefordrar, finns det en liten sannolikhet att den skickar mottagaren ett tillhörande paket med ytterligare information om hur paketet vidarebefordrades. Detta hjälper att spåra en attack, men gör i sig ingenting för att motverka den. Pushback[12] Föreslår att routrar som upptäcker att de måste kasta många paket med en viss mottagare kan signalera till andra routrar att även de bör göra detta. Centertrack[15] Föreslår att routingen inom ett system i attackens väg ändras till att gå genom speciella routrar som kan hantera spårning. Gemensamt för dessa är att ingen är någon etablerad standard, utan bara förslag. Det finns dock testimplementationer av Traceback. Ett problem är att en router, i synnerhet en som hanterar stora volymer trafik, där man skulle vilja filtrera attackerna, är en mycket specialiserad maskin. En sådan router har typiskt specifikt konstruerade kretsar för att routa paket. Att lägga till en server för ett eventuellt protokoll för att begära filtrering låter sig inte enkelt göras. Om någon kan begära av en router att den ska stänga av vissa paket så är det potentiellt en enorm risk att någon gör detta till en attack. Därför måste det finnas ett säkert sätt att se till att bara de som ska få strypa ett paketflöde verkligen får det. Här finns ett eventuellt problem: om för stark kryptografi byggs in i ett protokoll, kan en anfallare orsaka stora prestandaförluster genom att översvämma servern med hopplösa försök att autentisera sig. (Se avsnitt 3.4 för ett exempel.) Ett intressant sätt att spåra bandbreddsattacker i ett nät man kontrollerar är genom att använda en karta över trafiken på nätet. En attack kan då visualiseras 8

A B C 1 2 3 4 D E Figur 1. En karta över nyttjandegraden i ett påhittat transitnät, mörkare färg betyder mera trafik. som ett mörkt streck av hårt belastade länkar. I figur 1 kan man se att nät E är hårt belastat av trafik från nät B genom router 2 och 4. För distribuerade attacker med många källor finns det dock inga enkla spår att följa. 4.6 Routing som motmedel Det finns dock ett sätt att tala om för en router att den ska kasta paket till en viss destination och som inte orsakar större belastning på routern än normal routing. Idén är att använda det befintliga routingprotokollet som används för routing inom nätet man kontrollerar, exempelvis OSPF. Med detta kan man inom nätet tala om för alla routrar att de inte ska vidarebefordra paket till en attackerad värd, genom att routa det till en destination som inte leder någonstans. Nackdelen med detta är att det är ett grovt verktyg och all trafik till värden kommer att slängas. Målet med en Denial of Service-attack, att slå ut en viss tjänst, kommer därmed att förbli uppnått. Fördelen är att länkarna till nätet den attackerade värden sitter på kommer att avlastas, och trafik till andra värdar på nätet kommer då igenom. Detta är fortfarande något som måste göras i ett operatörsnät som trafiken passerar genom, och inte kan göras hos den attackerade klienten. Teoretiskt skulle man kunna använda BGP, routingprotokollet som används för att annonsera ut rutter till omvärlden, för att begära av andra nät att de inte ska vidarebefordra trafik till värden. Problemet är att det inte finns något standardsätt att annonsera att trafik till ett visst prefix ska slängas i stället för att routas. Rutter kan annonseras med tillhörande flaggor, däribland en community-flagga. Närliggande operatörer som ofta utbyter trafik med varandra kan komma överens om att en viss community betyder att trafik ska kastas, men det finns ingen gemensam standard 9

för detta. Hur som helst är det fortfarande operatören och inte klienten som pratar BGP. Som tidigare nämnts finns det en risk i att någon kan begära att paket slängs på detta sätt. Tidigare routingprotokoll, som första versionen av RIP, hade inget sätt att autentisera paket på och skickade routinginformation som datagram. Detta gjorde dem sårbara för förfalskade routingpaket. Senare routingprotokoll, exempelvis version 2 av OSPF, har stöd för kryptografisk signering av paket med routinginformation. BGP, routingprotokollet som används mot omvärlden (till skillnad mot RIP och OSPF som används inom ett nät man kontrollerar), skickar information över TCP. Detta gör att det finns en viss kontroll av avsändaradressen. Värdar som pratar BGP med varandra är ofta närliggande, vilket även gör det möjligt att använda TTL-fältet i IP-huvudet för att bekräfta källan på ett paket. Om ett paket har gått genom för många routrar, kommer det troligtvis utifrån. Dessutom kan BGP-sessioner skyddas med lösenord. 5 Rekommendationer för klientnät Följande är förslag på vad man kan göra som slutanvändare på Internet eller som administratör för ett mindre nät kopplat till en Internetleverantör. Det är omöjligt att helt skydda sig, men dessa förslag kan om de följs minska risken att bli utsatt och lindra en eventuell attack. 5.1 Skydda mot allmänna dataintrång Den största faran är den som kommer inifrån. Om någon har tagit kontoll över en maskin på det egna nätet, finns det ytterst lite på hela nätet som går att lita på. En sådan övertagen dator kan skicka paket som kommer inifrån ens eget nät och som går förbi varje brandvägg eftersom datorn sitter innanför brandväggen. Den kan även om den sitter på ett LAN attackera en server med en intensitet som inte kan jämföras med den hos en attack utifrån. Förutom risken för det egna nätet, löper en övertagen maskin risk att bli delaktig i en distribuerad attack. 5.2 Installera säkerhetsuppdateringar Vikten av att hålla både operativsystem och servermjukvara uppdaterade kan inte underskattas. Så gott som alla attacker som har beskrivits, förutom bandbreddsattacker, är nyare versioner av operativsystem mindre sårbara för. 5.3 Brandväggar botar inte allt Var medveten om de begränsningar brandväggar och IDS-program har. En brandvägg kan vara en del av säkerheten, men kan inte skydda mot bandbreddsattacker och i regel inte mot sårbara applikationer. 10

5.4 Stoppa förfalskade avsändaradresser Det är god sed att inte släppa paket ur sitt nät om det inte har en avsändaradress inom det. Många attacker som nämnts går inte att utföra utan att anfallaren använder förfalskade avsändaradresser. Dessutom blir en eventuell attack enklare att spåra tillbaka till en övertagen maskin. 5.5 Bli inte en attackreflektor Filtrera bort inkommande paket med en broadcastadress som destination, eller se till att dina värdar inte svarar på dem. Annars riskerar du att bli delaktig i en Smurf-attack. (Se avsnitt 3.6.) 5.6 Ha en heterogen datormiljö Många av de attacker som har nämnts har varit specifika för ett visst operativsystem. Exempelvis Teardrop-attacken (se avsnitt 3.2) drabbade vissa versioner av Linux. Eftersom den utnyttjade att inskickat data exekverades som kod, var den även tvungen att specialskrivas för varje processorarkitektur Linux kan köras på. Genom att ha en heterogen datormiljö undviker man att samtliga datorer blir sårbara för en nyupptäckt attack. Detta kan göra det svårare att hålla ordning på säkerhetsuppdateringar, men jag rekommenderar starkt att åtminstone en server och dess backup kör olika operativsytem. 6 Rekommendationer för operatörer Följande är förslag på vad man som operatör kan göra för att hjälpa sina klienter vid en eventuell attack, och vad man kan göra för att förebygga attacker. 6.1 Var redo Ha utarbetade rutiner för vad som ska göras vid en attack och se vilka möjligheter som finns för att stoppa trafiken till en attackerad värd. Se vilka nätövervakningsverktyg som finns och hur de kan användas för att spåra en attack. 6.2 Motarbeta förfalskade avsändaradresser Gör det så svårt som möjligt att sända paket med förfalskade avsändaradresser. Även om det inte är möjligt att göra en full Reverse Path Forwarding-kontroll på grund av trafikvolymen eller att routern inte stöder detta, bör man överväga att göra stickprovskontroller av paket för att se vilka nät som sänder förfalskade paket. 11

6.3 Samarbeta om routing till tomma intet Se om de operatörer man peerar med har en konvention för att annonsera en rutt som leder till tomma intet. Detta är det effektivaste motmedlet mot en bandbreddsattack, som bör stoppas så nära källan som möjligt. (Se avsnitt 4.6.) 6.4 Skydda era routingtabeller Om någon lyckas annonsera en falsk rutt till ett nät, kan detta orsaka enorm skada, eftersom inga paket överhuvudtaget kommer att gå fram till det nätet. Därför bör en operatör vidta alla tillgängliga åtgärder för att förhindra att falsk routinginformation skapas eller sprids. Skydda era BGP-sessioner med lösenord för att försvåra att de tas över. Kontrollera annonserade prefix från andra nät så att de stämmer med de allmänna databaser som finns, som RIPE. Detta förhindrar att ett prefix tas emot som egentligen tillhör någon annan. PGP-signera det som ni själva lägger in i dessa routedatabaser. 7 Slutsats Denna rapport må ha redogjort för en diger lista med faror, men som synes i listan över rekommendationer klarar man sig långt med ett sunt säkerhetstänkande. Genom att hålla sina system uppdaterade säkrar man sig mot många attacker. Det finns även enkla åtgärder för att vara en god granne på Internet och undvika att bli delaktig i någon annans attack. Dock är den simplaste attacken, bandbreddsattacken, svårast att skydda sig mot och måste lösas i samarbete med Internetoperatörer. 12

Referenser [1] MS SQL Server Worm Wreaking Havoc. http://slashdot.org/article.pl?sid=03/ 01/25/1245206. Besökt 21 februari 2003. [2] Ping of Death. http://www.insecure.org/sploits/ping-o-death.html. Besökt 28 februari 2003. [3] D. J. Bernstein. SYN cookies. http://cr.yp.to/syncookies.html. Besökt 6 mars 2003. [4] Eric Chien. CodeRed Worm. http://securityresponse.symantec.com/avcenter/ venc/data/codered.worm.html, 2003. Besökt 4 april 2003. [5] David McGuire och Brian Krebs. Attack On Internet Called Largest Ever. http://www.washingtonpost.com/ac2/wp-dyn/a828-2002oct22? language=printer, 2002. Besökt 22 april 2003. [6] Stefan Savage och David Wetherall och Anna Karlin och Tom Anderson. Practical network support for ip traceback. I Proceedings of the 2000 ACM SIGCOMM Conference, ss 295 306, 2000. [7] Stuart McClure och Joel Scambray och George Kurtz. Hacking Exposed, ss 514 515. Osborne/McGraw Hill, 3 utgåva, 2001. ISBN 0-07-219381-6. [8] Stuart McClure och Joel Scambray och George Kurtz. Hacking Exposed, ss 510 512. Osborne/McGraw Hill, 3 utgåva, 2001. ISBN 0-07-219381-6. [9] Stuart McClure och Joel Scambray och George Kurtz. Hacking Exposed, ss 516 517. Osborne/McGraw Hill, 3 utgåva, 2001. ISBN 0-07-219381-6. [10] Stuart McClure och Joel Scambray och George Kurtz. Hacking Exposed, ss 508 510. Osborne/McGraw Hill, 3 utgåva, 2001. ISBN 0-07-219381-6. [11] David Newman och Joel Snyder och Rodney Thayer. Crying Wolf: False Alarms Hide Attacks. http://www.nwfusion.com/techinsider/2002/0624security1.html, 2002. Besökt 7 mars 2003. [12] Steven M. Bellovin och Ratul Mahajan och Vern Paxson och Sally Floyd och Scott Shenker. DDoS Attacks and Pushback. http://www.research.att.com/ ~smb/talks/pushback-dodcert.pdf, 2000. Besökt 7 mars 2003. [13] Eric S. Raymond. The Jargon File. http://www.catb.org/~esr/jargon/, 2002. Besökt 13 mars 2003. [14] Joyce Reynolds. RFC 1135: The Helminthiasis of the Internet. ftp://ftp.sunet. se/pub/internet-documents/rfc/rfc1135.txt, 1989. [15] Robert Stone. CenterTrack. http://www.nanog.org/mtg-9910/ppt/robert/ index.htm, 1999. Besökt 7 mars 2003. 13

14

A Förkortningsordlista ACK ACKnowledgment: Se avsnitt 3.3. BGP Border Gateway Protocol: routingprotokollet som används mot omvärlden. DoS Denial of Service: Att störa eller slå ut en tjänst. DNS Domain Name System: Tjänsten som omvandlar namn som www.foobar.com till numeriska IP-adresser. HTTP HyperText Transfer Protocol: Protokollet som är grundstenen för World Wide Web. ICMP Internet Control Message Protocol. Används för information om paketleverans, till exempel felmeddelanden. IDS Intrusion Detection System: Se avsnitt 4.2. IP Internet Protocol. IPV4 Internet Protocol Version 4, den som nu används. LAN Local Area Network: Lokalt nätverk. MTU Maximum Transfer Unit: Gränsen för hur stort ett paket får vara. OSPF Open Shortest Path First: Routingprotokoll avsett för ett nät man själv kontrollerar. PGP Pretty Good Privacy: Ett program för kryptografi. RIP Routing Information Protocol: Routingprotokoll avsett för ett nät man själv kontrollerar. SQL Structured Query Language: Språk som används för att hämta information ur databaser. SYN SYNchronize: Se avsnitt 3.3. TCP Transport Control Protocol: Protokoll för pålitlig överföring av data, med uppkoppling och nedkoppling. TTL Time To Live: Fält i huvudet på ett IP-paket som anger hur många routrar det får gå genom. Varje router som vidarebefordrar paketet minskar detta värde med ett. UDP User Datagram Protocol: Protokoll för överföring av data utan bekräftelser, är uppkopplingsfritt. 15