1 TCP hijacking Vladimír Kotal 30. července 2004 Zadání 1 TCP hijacking: Popište podrobně metodu útoku unesením TCP spojení. Uved te slabiny na kterýc...
TCP hijacking Vladim´ır Kotal 30. ˇcervence 2004 Zad´ an´ı 1 TCP hijacking: Popiˇste podrobnˇe metodu u ´toku unesen´ım TCP spojen´ı. Uved’te slabiny na kter´ych je u ´tok zaloˇzen a pˇr´ıklady realizace.
´ Uvod
1
TCP protokol jako jedna z hlavn´ıch souˇc´ ast´ı suity protokol˚ u TCP/IP slouˇz´ı pro pˇrenos informac´ı na Internetu jiˇz v´ıce neˇz 20 let. TCP tvoˇr´ı spolu s protokolem UDP 4. vrstvu modelu ISO/OSI. Dnes se protokol TCP pouˇz´ıv´a napˇr. k pˇrenosu dat pro aplikaˇcn´ı protokol HTTP, ale tak´e pro udrˇzov´an´ı BGP spojen´ı mezi p´ateˇrn´ımi smˇerovaˇci (routery), kter´e slouˇz´ı k v´ ymˇenˇe smˇerovac´ıch informac´ı. TCP tedy pˇredstavuje pˇrenosovou (neboli transportn´ı) platformu pro protokoly vyˇsˇs´ıch vrstev ISO/OSI modelu. Nˇekter´e z tˇechto protokol˚ u mohou m´ıt vyˇsˇs´ı n´aroky na bezpeˇcnost, coˇz jim TCP nemus´ı vˇzdy zaruˇcit. V tomto ˇcl´anku uvedu pˇrehled u ´tok˚ u na protokol TCP a rozeberu jeden z u ´tok˚ u-u ´tok TCP hijacking (”unesen´ı TCP spojen´ı”). D´ ale nast´ın´ım nˇekter´e metody ochrany proti podobn´ ym u ´tok˚ um.
´ Uvod do protokolu TCP
2
TCP je stavov´ y transportn´ı protokol, kter´ y byl navrˇzen pro spolehliv´ y pˇrenos dat po Internetu. TCP garantuje integritu a sekvenˇcn´ı doruˇcov´ an´ı dat mezi dvˇema entitami pot´e, co bylo ustaveno TCP spojen´ı. TCP velmi dobˇre ˇsk´aluje - pracuje uspokojivˇe i na link´ ach s vysokou latenc´ı nebo vysokou ztr´atovost´ı paket˚ u. TCP spojen´ı lze rozdˇelit do tˇr´ı f´ az´ı - ustaven´ı (synchronizace), pˇrenos dat, uzavˇren´ı spojen´ı.
2.1
Form´ at TCP hlaviˇ cky
Hlaviˇcka TCP paketu dle [4] je na obr. 1. TCP hlaviˇcka n´ asleduje v paketu typicky bezprostˇrednˇe za IP hlaviˇckou1 . Pro naˇse u ´ˇcely jsou d˚ uleˇzit´e zejm´ena n´ asleduj´ıc´ı poloˇzky: • Flags (URG, ACK, ...) - pole s pˇr´ıznaky nese informaci potˇrebnou pro detekci stavu druh´e strany. Lze je kombinovat, ale pouze nˇekter´e kombinace jsou dle RFC (viz. [4]) povolen´e. Paket obsahuj´ıc´ı flag ACK budeme naz´ yvat ACK paket. • Sequence number - 32-bitov´e ˇc´ıslo slouˇz´ıc´ı pro zaruˇcen´ı sekvenˇcn´ıho doruˇcov´an´ı dat. Kaˇzd´ y TCP segment poslan´ y po s´ıti obsahuje sekvenˇcn´ı ˇc´ıslo prvn´ıho bajtu dat v tomto segmentu. 1 v´ yjimkou
je napˇr. pouˇ zit´ı protokolu IPsec
1
Obr´azek 1: TCP hlaviˇcka. Pokud nen´ı d´elka pole ’Options’ n´asobkem osmi, je doplnˇena. Pˇrevzato z [5]. ´ eˇsnˇe pˇrijat´ • Acknowledgment number - 32-bitov´e ˇc´ıslo slouˇz´ıc´ı pro zajiˇstˇen´ı spolehlivosti doruˇcen´ı. Uspˇ y segment je odesilateli potvrzen posl´ an´ım ACK paketu, kter´ y m´a jako Acknowledgment number sekvenˇcn´ı ˇc´ıslo posledn´ıho bajtu pˇrijat´eho segmentu. • Window - ud´ av´ a velikost ”okna” - tj. maxim´alnˇe kolik dat m˚ uˇze druh´a strana poslat
2.2
Model TCP protokolu
TCP protokol je moˇzn´e modelovat jako koneˇcn´ y statov´ y automat (viz. obr. 2), ve kter´em se vyskytuj´ı stavy klienta i serveru. Celkem m´a stavov´ y automat 11 stav˚ u, pro naˇse u ´ˇcely2 ho m˚ uˇzeme zjednoduˇsit na automat se sedmi stavy: CLOSED, LISTEN, SYN RCVD, SYN SENT, ESTABLISHED, active close, passive close. Procesy uzavˇren´ı spojen´ı jsme kaˇzd´ y uzavˇreli do jednoho ”podautomatu” a provedli substituci.
2.3
3-way handshake
TCP je stavov´ y protokol. Pˇredt´ım, neˇz m˚ uˇze zaˇc´ıt v´ ymˇena dat mezi obˇema stranami, je potˇreba synchronizovat stavov´e automaty na obou stran´ ach. Jednak je tˇreba, aby se obˇe strany dostaly konzistentnˇe do stavu ESTABLISHED (tento pˇrechod mus´ı b´ yt odoln´ y v˚ uˇci v´ ypadk˚ um paket˚ u po cestˇe), d´ale tato synchronizaˇcn´ı f´aze slouˇz´ı k vz´ajemn´e v´ ymˇenˇe poˇc´ ateˇcn´ıch sekvenˇcn´ıch ˇc´ısel (ISN, Initial Sequence Number) a poˇc´ateˇcn´ıch velikost´ı oken TCP spojen´ı. Toto zajiˇst’uje pˇrechod nazvan´ y 3-way handshake. 2 zaj´ ım´ a
n´ as zejm´ ena ustaven´ e TCP spojen´ı, pro mechanismus ukonˇ cen´ı n´ am postaˇ c´ı vedˇ et, ˇ ze souvis´ı s pˇr´ıznakem RST
2
Na poˇc´atku je server ve stavu LISTEN, klient ve stavu CLOSED. 3-way handshake prob´ıh´a tak, ˇze klient zvol´ı poˇc´ateˇcn´ı sekvenˇcn´ı ˇc´ıslo (ISN)3 a poˇsle serveru TCP paket s pˇr´ıznakem SYN, ˇc´ımˇz pˇrejde do stavu SYN SENT. Server po obdrˇzen´ı tohoto paketu pˇrejde do stavu SYN RCVD a odpov´ı TCP paketem s pˇr´ıznaky SYN/ACK. Klient obdrˇz´ı tento paket a odpov´ı TCP paketem s pˇr´ıznakem ACK a oba pˇrejdou do stavu ESTABLISHED.
2.4
Implementace TCP
V souˇcasnosti se implementace TCP nach´ az´ı v ˇsirok´e ˇradˇe r˚ uzn´ ych zaˇr´ızen´ı, od poˇc´ıtaˇc˚ u pˇres pr˚ umyslov´e syst´emy aˇz po r˚ uzn´a tzv. embedded zaˇr´ızen´ı, kter´ a slouˇz´ı jenom u ´zk´emu oboru ˇcinnost´ı. V minulosti byl protokol TCP co se n´ avrhu t´ yˇce, minim´alnˇe upravov´an. Jeho implementace se nicm´enˇe celkem mezi jednotliv´ ymi operaˇcn´ımi syst´emy liˇs´ı. Odliˇsnosti spoˇc´ıvaj´ı zejm´ena v 1. generov´an´ı ˇc´ısel ISN 2. chov´an´ı pˇri pˇrijet´ı out-of-window TCP paket˚ u s r˚ uzn´ ymi volbami 3. chov´an´ı pˇri pˇrijet´ı TCP paket˚ u s r˚ uzn´ ymi volbami Nedostatky pˇri generov´ an´ı ˇc´ısel ISN umoˇzn ˇuj´ı tzv. blind-spoofing u ´toky (viz. d´ale), chov´an´ı pˇri pˇrijet´ı outof-window TCP paket˚ u m˚ uˇze umoˇznit TCP reset u ´toky nebo TCP hijacking (viz. d´ale). (podle voleb v TCP paketu) R˚ uzn´e chov´ an´ı operaˇcn´ıch syst´em˚ u pˇri pˇrijet´ı TCP paket˚ u s r˚ uzn´ ymi volbami je podkladem pro vzd´alenou detekci OS.
3
Slabiny protokolu TCP
Protokol TCP byl navrˇzen pro prostˇred´ı ARPANETu, kdy jeˇstˇe nebylo zˇrejm´e, jak nehostinn´e m´ısto m˚ uˇze b´ yt Internet. Z toho vypl´ yvaj´ı jeho slabiny, kter´e mohou b´ yt n´asobeny nespr´avnou implementac´ı.
3.1
Predikovateln´ aˇ c´ısla ISN
Generov´an´ı ˇc´ısel ISN (Initial Sequence Number) pro kaˇzdou instanci TCP spojen´ı vyˇzaduje, aby tato ˇc´ısla byla co nejm´enˇe predikovateln´ a. Toto nen´ı ani tak chyba n´avrhu (i kdyˇz v pˇr´ısluˇsn´em RFC (viz. [4]) to mohlo b´ yt l´epe zd˚ uraznˇeno), jako sp´ıˇse implementac´ı TCP. Pokud totiˇz dan´ y operaˇcn´ı syst´em implementuje gener´ator ˇc´ısel ISN tak, ˇze jeho v´ ysledky nejsou dostateˇcnˇe n´ahodnˇe rozpt´ yleny po stavov´em prostoru, je moˇzn´e prov´est snadno tzv. blind-spoofing u ´tok (viz. d´ale). Z pˇrehledn´e studie, o tom, jak si stoj´ı jednotliv´e operaˇcn´ı syst´emy (viz. [1]) vypl´ yv´a, ˇze implementace gener´ator˚ u ISN ˇc´ısel se postupnˇe zlepˇsuj´ı.
3.2
Chybˇ ej´ıc´ı autentizace
Jednotliv´e segmenty TCP protokolu nejsou mezi jednotliv´ ymi stranami nijak autentizov´any, takˇze pokud je moˇzn´e podvrhovat pakety, je z´ aroveˇ n moˇzn´e podvrhovat data v r´amci TCP spojen´ı. Kdyby toto nebylo moˇzn´e, u ´toky typu TCP hijacking by nebyly uskuteˇcniteln´e. Tento nedostatek lze ˇreˇsit na vyˇsˇs´ıch vrstv´ach ISO/OSI modelu nebo pomoc´ı technologie IPsec (viz. sekce ”Metody obrany”). 3 pro
kaˇ zd´ e nov´ e spojen´ı pokud moˇ zno n´ ahodn´ e
3
´ Utoky na TCP
4
Pˇredt´ım, neˇz podrobnˇe rozebereme TCP hijacking u ´tok, uvedeme nˇekolik nejzn´amˇejˇs´ıch u ´tok˚ u na protokol TCP pro lepˇs´ı kontext.
4.1
Spoofing
Spoofing neboli podvrhov´ an´ı paket˚ u je jednoduch´a technika, kter´a zkonstruuje paket s danou zdrojovou nebo c´ılovou adresu v IP hlaviˇcce, zdrojov´ y a c´ılov´ y port v TCP hlaviˇcce a dalˇs´ımi poli. Pokud jsou ˇc´ısla ISN predikovateln´ a, m˚ uˇze b´ yt proveden tzv. blind spoofing u ´tok, kdy u ´toˇcn´ık nemus´ı odposlouch´avat spojen´ı, protoˇze m˚ uˇze odhadnout (s jistou pravdˇepodobnost´ı), jak´e jsou aktu´aln´ı hodnoty sekvenˇcn´ıch ˇc´ısel obou stran. Spoofing s´am o sobˇe nepˇredstavuje typ u ´toku, je to jen komponenta vyuˇz´ıvan´a pˇri TCP hijacking u ´toku a dalˇs´ıch u ´toc´ıch.
4.2
TCP reset
TCP reset u ´tok vyuˇz´ıv´ a nedostateˇcnˇe striktn´ı implementace TCP protokolu, kde RST paket poslan´ y v r´amci okna m˚ uˇze resetovat cel´e TCP spojen´ı, nen´ı nutn´e, aby sekvenˇcn´ı ˇc´ıslo sˇedˇelo pˇresnˇe (viz. [9]). Protoˇze jsou dnes okna pro TCP spojen´ı nezˇr´ıdka velk´ a, nen´ı toto riziko tak mal´e, jak se p˚ uvodnˇe myslelo. Protoˇze touto chybou byla ohroˇzena stabilita p´ ateˇre Internetu4 , muselo b´ yt upgradov´ano v kr´atk´em ˇcas mnoˇzstv´ı smˇerovaˇc˚ u. Opˇet, spoofing je komponentou pro tento u ´tok.
4.3
SYN flooding
SYN flooding je u ´tok proti implementaci TCP protokolu vyuˇz´ıvaj´ıc´ı spoofingu. Na c´ıl jsou pos´ıl´any TCP SYN pakety s podvrˇzenou zdrojovou adresou, c´ıl alokuje pamˇet’ pro nov´e spojen´ı a odpov´ı SYN/ACK paketem. Pokud pos´ıl´a u ´toˇcn´ık pakety dostateˇcnˇe rychle, m˚ uˇze tak doj´ıt k vyˇcerp´an´ı syst´emov´ ych prostˇredk˚ u obˇeti.
4.4
Hijacking
Hijacking u ´toky obecnˇe jsou vˇsechny takov´e u ´toky, kdy u ´toˇcn´ık m˚ uˇze za urˇcit´ ych podm´ınek ovlivnit stav c´ıle pomoc´ı manipulace s protokoly, kter´e vyuˇz´ıv´ a jeho c´ıl ke komunikaci. Tyto u ´toky se mohou odehr´avat na r˚ uzn´ ych vrstv´ach ISO/OSI modelu, zn´ am´e jsou napˇr. hijacking na 2. vrstvˇe (ARP spoofing, ARP relaying) a na 3. a 4. vrstvˇe ISO/OSI modelu. (TCP hijacking, ICMP redirection) ´ Utok TCP hijacking (”unesen´ı TCP spojen´ı”) m´a za c´ıl ovl´adnut´ı existuj´ıc´ıho client-server nebo peer-to-peer spojen´ı na 4. vrstvˇe ISO/OSI modelu pomoc´ı vloˇzen´ı TCP paket˚ u. Tento u ´tok bude podrobnˇe pops´ an v n´ asleduj´ıc´ıch sekc´ıch.
5
Podstata TCP hijacking u ´ toku
TCP hijacking u ´tok vyuˇz´ıv´ a v podstatˇe jen jedn´e slabiny TCP protokolu: jednotliv´e segmenty TCP spojen´ı nejsou autentizov´any. K ”´ uspˇeˇsn´emu” proveden´ı u ´toku (tj. takov´emu, kdy ani jedna strana pokud moˇzno nepozn´a, ˇze byl u ´tok proveden) jsou nicm´enˇe tˇreba dalˇs´ı pˇredpoklady: 4 TCP
spojen´ı se pouˇ z´ıvaj´ı pro v´ ymˇ enu smˇ erovac´ıch informac´ı protokolu BGP
4
• moˇznost tzv. du´ aln´ı desynchronizace umoˇzn ˇuj´ıc´ı tzv. ACK storm • moˇznost u ´spˇeˇsn´e predikce ˇc´ısel ISN (Initial Sequence Number ) nebo pozice pro tzv. Man in the Middle attack 5
5.1
Du´ aln´ı desynchronizace a ACK storm
Podle [2] si m˚ uˇzeme pˇrenos dat v r´ amci ustaven´eho TCP spojen´ı (tj. po probˇehnut´ı 3-way handshake) pˇredstavovat jako klasickou poˇc´ıtaˇcovou hru PONG, kde paket ”na cestˇe” pˇredstavuje let´ıc´ı m´ıˇcek a posunuj´ıc´ı se okna TCP spojen´ı pˇredstavuj´ı p´ alky odr´ aˇzej´ıc´ı m´ıˇcek. Pokud m´ıˇcek spadne na p´alku (tedy TCP segment patˇr´ı do okna), odpov´ı tato strana paketem s nastaven´ ym pˇr´ıznakem ACK. Pokud je nav´ıc tento TCP segment posledn´ı v r´amci dan´eho okna, okno se posune o svou velikost dopˇredu. Pokud m´ıˇcek dopadne mimo p´alku (tzv. out-of-window segment), vyˇsle tato strana paket s pˇr´ıznakem ACK, kter´ y potvrzuje posledn´ı paket v r´amci okna. To umoˇzn ˇuje detekovat situaci, kdy se nˇejak´ y paket po cestˇe ztratil. Toto chov´an´ı je zneuˇziteln´e. V pˇr´ıpadˇe, kdy se podaˇr´ı dos´ahnout stavu, kdy si obˇe strany poˇslou out-ofwindow segment, bude se toto chov´ an´ı opakovat aˇz do chv´ıle, kdy se ztrat´ı jeden paket tohoto typu. To m˚ uˇze nastat z´ahy, protoˇze tyto pakety mohou zahltit linku. V pˇr´ıpadˇe TCP hijacking u ´toku je ˇz´ adouc´ı dos´ahnout posunut´ı oken obou stran (odtud dual desynchronization). Ve chv´ıli, kdy maj´ı obˇe strany umˇele posunut´a okna, staˇc´ı poslat podvrˇzen´e out-of-windows pakety na obˇe strany a tyto se zaˇcnou opakovat. Pokud se jeden z nich ztrat´ı (napˇr. v d˚ usledku ucp´an´ı linky), v´ ymˇena tˇechto paket˚ u se na chv´ıli zastav´ı. Opˇet se ale rozebˇehne, jakmile se jedna ze stran rozhodne poslat nˇejk´a data. Out-of-window pakety se pak budou opakovat tak dlouho, dokud jedna ze stran nepˇreruˇs´ı spojen´ı pomoc´ı paketu s pˇr´ıznakem RST. Tomuto chov´ an´ı se ˇr´ık´ a ACK storm. Chov´an´ı pˇri ACK storm m˚ uˇze b´ yt pouˇzito jako kryt´ı pro TCP hijacking u ´tok.
5.2
Vkl´ ad´ an´ı TCP segment˚ u
Nejjednoduˇsˇs´ı varianta TCP hijacking u ´toku (tzv. simplex hijacking) provede pouh´e vloˇzen´ı paketu s podvrˇzen´ ymi daty. K tomu je nejprve nutn´e dan´e spojen´ı sledovat, aby mohl b´ yt zkonstruov´an se spr´avn´ ymi Seq a Ack ˇc´ısly. V d˚ usledku posl´ an´ı podvrˇzen´eho paketu m˚ uˇze a nemus´ı nastat ACK storm6 .
6
Realizace u ´ toku
Pro realizaci TCP hijacking u ´toku je nejprve nutn´e vybrat spojen´ı, na kter´e m´a b´ yt u ´tok proveden. Pot´e je moˇzn´e vloˇzit jeden TCP segment (tzv. simplex hijack ). T´ım m˚ uˇze doj´ıt k ACK storm. Pˇred vloˇzen´ım TCP segmentu je vhodn´e prov´est du´ aln´ı desynchronizaci stran u ´ˇcastn´ıc´ıch se sledovan´eho spojen´ı. Lze prov´est i komplikovanˇejˇs´ı hijack u ´tok tak, ˇze neprovedeme du´aln´ı desynchronizaci a po vloˇzen´ı segmentu poˇck´ame, jestli se objev´ı ACK storm a pokud ne, m˚ uˇzeme vloˇzit dalˇs´ı segment, resetovat spojen´ı nebo jej synchronizovat. Pokud dojde k ACK storm, je dalˇs´ı pos´ıl´ an´ı podvrˇzen´ ych paket˚ u t´emˇeˇr nemoˇzn´e, protoˇze ACK pakety zahlt´ı dostupnou ˇs´ıˇrku p´ asma.
6.1
N´ astroje
Nejzn´amˇejˇs´ımi n´ astroji pro implementaci TCP hijacking u ´toku jsou Juggernaut [3] a Hunt [6]. 5
u ´toˇ cn´ık m´ a moˇ znost odposlouch´ avat a ovlivˇ novat s´ıt’ov´ y provoz obou stran spojen´ı v dokumentaci k [6] je uvedeno, ˇ ze ACK storm nenast´ av´ a u linuxov´ ych jader ˇrady 2.0
6 Napˇ r.
5
6.1.1
Juggernaut
Juggernaut je klasick´ y n´ astroj uveˇrejnˇen´ y v dobˇe, kdy byly hijacking u ´toky uˇz nˇejakou dobu ”popul´arn´ı”. Tento n´astroj um´ı prov´est z´ akladn´ı hijacking u ´tok vloˇzen´ım TCP segmentu do telnet spojen´ı. Pˇri simplex hijacking u ´toku neprovede nejprve desynchronizaci spojen´ı, takˇze v´ ysledn´ y ACK storm nemus´ı nastat. Toto sice m˚ uˇze zp˚ usobit ACK storm na mnoha klientech, ale nen´ı to opravdov´a du´aln´ı desynchronizace. Nav´ıc pˇr´ıkaz v podvrˇzen´em paketu je vyps´ an telnet serverem, takˇze jej prav´ y klient vid´ı. Autoˇri ˇcl´anku [2] modifikovali Juggernaut tak, ˇze nejdˇr´ıve provedl du´aln´ı desynchronizaci pomoc´ı zasl´an´ı podvrˇzen´ ych NOP (No operation) paket˚ u telnet protokolu (viz. [8]) na obˇe strany spojen´ı. To posune okna obou stran bez toho, ˇze by se zmˇenil stav aplikac´ı. Vloˇzen´ım podvrˇzen´ ych dat do ustaven´eho spojen´ı pak vyvol´a ACK storm, takˇze prav´ y klient nevid´ı, ˇze byla do spojen´ı vloˇzena data. Autor tohoto n´ astroje pracuje v souˇcasn´e dobˇe pro firmu Cisco systems7 . 6.1.2
Hunt
Hunt je modern´ı n´ astroj pro manipulaci se s´ıt’ov´ ym provozem od 2. vrstvy ISO/OSI v´ yˇse. Autor n´astroje Hunt pracoval ve firmˇe zab´ yvaj´ıc´ı se mj. v´ yvojem profesion´aln´ıch pr˚ umyslov´ ych pˇr´ıstroj˚ u pro anal´ yzu r˚ uzn´ ych protokol˚ u. Proto nen´ı divu, ˇze Hunt obsahuje komfortn´ı prostˇred´ı pro pr´aci se s´ıt’ov´ ym provozem. Hunt je program urˇcen´ y pro manipulaci s TCP spojen´ım. M˚ uˇze jej sledovat, naruˇsovat a resetovat. Um´ı filtrovat spojen´ı, detekovat spojen´ı, kter´e je uˇz ustaveno8 , aktivn´ı hijacking u ´tok s detekc´ı ACK storm, hijacking u ´tok s ARP spoofingem, resetovat spojen´ı. Je naps´an modul´ arnˇe, obsahuje d´emony9 pro sledov´an´ı MAC adres, sniffovac´ıho d´emona pro zaznamen´av´an´ı s´ıt’ov´eho provozu se schopnost´ı hledat v provozu urˇcit´ y ˇretˇezec znak˚ u atd. Co se t´ yˇce implementace TCP hijacking u ´toku, je Hunt pravdˇepodobnˇe nejvyspˇelejˇs´ım volnˇe dostupn´ ym n´astrojem. Um´ı simple hijack u ´tok s detekc´ı ACK storm i TCP hijacking u ´tok se synchronizac´ı obou stran.
7
Metody obrany
Proti hijacking u ´tok˚ um vˇseobecnˇe se lze br´ anit zaveden´ım autentizace jednotliv´ ych TCP segment˚ u, napˇr. pomoc´ı technologie IPsec. Riziko sniˇzuj´ı i tzv. best current practices neboli doporuˇcen´ı pro konfiguraci a spr´avu s´ıt’ov´ ych zaˇr´ızen´ı. Mezi tyto doporuˇcen´ı patˇr´ı napˇr´ıklad ochrana proti spoofing u ´tok˚ um zaveden´ım access list˚ u.
7.1
Pˇ rid´ an´ı stavu
Jedn´ım z ˇreˇsen´ım je u ´prava stavov´eho automatu TCP protokolu (viz. obr. 2) tak, aby obsahoval stav, kter´ y pom˚ uˇze detekovat du´ aln´ı desynchronizaci a provede pˇr´ıpadnou resynchronizaci obou stran. Du´aln´ı desynchronizaci lze detekovat tak, ˇze po pˇr´ıjmu out-of-window segmentu se poˇsle ACK paket bez dat a automat pˇrejde ze stavu ESTABLISHED do tohoto nov´eho stavu. Pokud nyn´ı pˇrijde dalˇs´ı out-of-window ACK paket bez dat, v´ıme, ˇze doˇslo k du´aln´ı desynchronizaci. Tento pˇr´ıstup (viz. [2]) ovˇsem nen´ı lehk´e zav´est do praxe. Prostˇredky k resynchronizaci (3-way handshake) jsou k dispozici, mus´ı b´ yt ovˇsem zachov´ ana zpˇetn´a kompatibilita s implementacemi TCP stacku, kter´e neum´ı 7 coˇ z
svˇ edˇ c´ı o tom, ˇ ze hry s protokoly mohou b´ yt uˇ ziteˇ cn´ e nejenom spojen´ı, u kter´ ych zaznamen´ a 3-way handshake 9 vlastnˇ e vl´ akna, protoˇ ze Hunt je aplikace napsan´ a pomoc´ı implementace POSIX threads 8 tedy
6
du´aln´ı desynchronizaci detekovat. Pokud jedna ze stran neobsahuje stack, kter´ y um´ı detekovat du´aln´ı desynchronizaci, mus´ı b´ yt spojen´ı zruˇseno10 . V praxi se tento pˇr´ıstup uk´ azal jako navyhovuj´ıc´ı, protoˇze nelze garantovat, ˇze pˇrijat´ y ACK paket bez dat byl vyvol´an urˇcit´ ym vyslan´ ym ACK paketem bez dat. V ˇcl´anku [2] byl pod´an d˚ ukaz, ˇze m˚ uˇze doj´ıt k tomu, kdy spojen´ı mezi dvˇema stranami (obˇema schopn´ ymi detekce du´aln´ı desynchronizace) m˚ uˇze b´ yt zresetov´ano ˇ sen´ı t´eto chyby by spoˇc´ıvalo v pouˇzit´ı pole ’Options’ (viz. obr. 1) pro d´ıky zpoˇzdˇen´ı pˇri doruˇcen´ı paketu. Reˇ rozpozn´an´ı ACK paketu n´ aleˇzej´ıc´ıho k vyslan´emu ACK paketu, to by s sebou ale neslo probl´emy v podobˇe sn´ıˇzen´eho v´ ykonu11 , nav´ıc nˇekter´e implementace nemus´ı pˇrijmout TCP paket s polem ’options’, kter´e nezn´a. Dalˇs´ı moˇznost´ı by bylo zjistit moˇznosti sv´eho protˇejˇsku pˇri sestavov´an´ı spojen´ı. To je cesta, kterou vyuˇz´ıv´a koncept SACK (Selective ACKnowledgments, viz. [7]).
7.2
Antispoof pravidla
Souˇcasn´e implementace firewall˚ u v r˚ uzn´ ych operaˇcn´ıch syst´emech dovoluj´ı pˇridat pravidla, kter´a zaruˇcuj´ı jist´ y stupˇen ˇ obrany proti podvrhov´ an´ı paket˚ u. M´ame-li napˇr. router s dvˇema s´ıt’ov´ ymi rozhran´ımi, kdy jedno z nich m´a pˇriˇrazeny routovateln´e adresy a druh´e je zapojeno do vnitˇrn´ı s´ıtˇe s priv´atn´ımi adresami, m˚ uˇzeme pomoc´ı pravidel firewallu zak´ azat pˇr´ıjem paket˚ u se zdrojovou adresou patˇr´ıc´ı do vnitˇrn´ı s´ıtˇe pˇrich´azej´ıc´ıch pˇres vnˇejˇs´ı rozhran´ı. N´asleduj´ıc´ıch nˇekolik pˇr´ıklad˚ u uv´ ad´ı pravidla pro obranu proti podvrhov´an´ı adres na nˇekolika implementac´ıch firewall˚ u. Tato pravidla pomohou v pˇr´ıpadˇe, ˇze u ´toˇcn´ık podvrhuje adresy patˇr´ıc´ı do vnitˇrn´ı s´ıtˇe a pˇritom do n´ı nem´a pˇr´ıstup12 . Pokud by se u ´toˇcn´ık nach´ azel ve vnitˇrn´ı s´ıti a neopr´avnˇenˇe by pouˇz´ıval adresy z t´eto s´ıtˇe, tato ochrana tomu nezabr´an´ı. Antispoof pravidla tedy sp´ıˇse slouˇz´ı jako jak´asi forma prevence. • PF PF je popul´ arn´ı implementace firewallu dostupn´a na OS OpenBSD, NetBSD a FreeBSD. K jeho vlastnostem patˇr´ı zejm´ena pˇrehlednost a snadnost konfigurace (oproti implementac´ım firewall˚ u v OS Linux), integrace s ALTQ mechanismy, ˇsk´ alovatelnost, integrovan´a podpora pro fail-over mechanismy a mnoho promyˇslen´ ych detail˚ u. Jedn´ım z tˇechto ne nev´ yznamn´ ych detail˚ u je i kl´ıˇcov´e slovo antispoof, kter´e zak´aˇze pˇr´ıchoz´ı provoz se zdrojov´ ymi adresami z neroutovateln´ ych blok˚ u (dle IANA). M´ame-li vnˇejˇs´ı (s adresou a pˇr´ıstupem do s´ıtˇe s routovateln´ ymi adresami) s´ıt’ov´e rozhran´ı fxp0, pak ochranu proti podvrˇzen´ı provedeme jednoduˇse pomoc´ı ExtIF="fxp0" antispoof for $ExtIF Pokud se za nˇejak´ ym dalˇs´ım rozhhran´ım nach´az´ı s´ıt’ s neveˇrejn´ ymi adresami, je t´ımto provedena z´akladn´ı ochrana. Pokud se naopak za dalˇs´ım s´ıt’ov´ ym rozhran´ım nach´az´ı s´ıt’ s routovateln´ ymi adresami, budeme muset pˇridat jeˇstˇe dalˇs´ı pravidla zakazuj´ıc´ı pouˇzit´ı tˇechto adres jako zdrojov´ ych v pˇr´ıchoz´ım provozu via vnˇejˇs´ı s´ıt’ov´e rozhran´ı a jin´ ych adres neˇz z tohoto bloku pro odchoz´ı provoz via toto s´ıt’ov´e rozhran´ı. 10 nam´ ısto
resynchronizace v pˇr´ıpadˇ e, kdy obˇ e strany detekci um´ı zpracov´ avaj´ı zpravidla pakety s nestanndardn´ımi ’options’ v procesoru nam´ısto v hardware 12 t´ ım se mysl´ı jak odes´ıl´ an´ı paket˚ u z Internetu do vnitˇrn´ı s´ıtˇ e se zdrojovou adresou z vnitˇrn´ı s´ıtˇ e, tak odes´ıl´ an´ı paket˚ u z vnitˇrn´ı s´ıtˇ e se zdrojovou adresou nepatˇr´ıc´ı do t´ eto s´ıtˇ e 11 routery
7
• IPF IPF je dalˇs´ı popul´ arn´ı implementac´ı firewallu, kterou lze naj´ıt v NetBSD a FreeBSD od BSD syst´emu je nutn´e ho ruˇcnˇe pˇridat) a dalˇs´ıch UNIXov´ ych syst´emech.
13
, IRIXu (narozd´ıl
IPF nem´ a makrojazyk, je tedy nutn´e vyjmenovat vˇsechny adresy/adresn´ı bloky, jichˇz se maj´ı antispoof pravidla t´ ykat. # fxp0 - external interface # don’t allow anyone to spoof non-routeable addresses block in log quick on fxp0 from 10.0.0.0/8 to any ... • Cisco extended ACL Smˇerovaˇce Cisco dnes pˇredstavuj´ı jednu z nejpouˇz´ıvanˇejˇs´ıch pˇrenosov´ ych platforem pro p´ateˇre a tzv. hraniˇcn´ı smˇerovaˇce (border routers) ISP (Internet Service Provider). Pr´avˇe tato zaˇr´ızen´ı by mˇela poskytovat ochranu proti podvrhov´ an´ı paket˚ u. Na kaˇzd´em rozhran´ı, za kter´ ym je pˇripojena s´ıt’ pˇrij´ımaj´ıc´ı nebo odes´ılaj´ıc´ı pakety ”zvˇejˇsku”, by mˇela m´ıt v access listu alespoˇ n pravidla pro ochranu proti podvrˇzen´ı paket˚ u. T´ım se mysl´ı jak ochrana proti paket˚ um pˇrich´azej´ıc´ı z tohoto rozhran´ı (ingress smˇer), tak paket˚ u vych´azej´ıc´ıch z t´eto s´ıtˇe (outgress smˇer). Mˇejme hypotetickou s´ıt’ 195.113.1.0/24, kter´a je souˇc´ast´ı virtu´aln´ı s´ıtˇe. Ochranu proti podvrˇzen´ı adres provedeme na routeru (zde layer-3 switchi), do kter´eho jsou zaˇr´ızen´ı s adresami z t´eto s´ıtˇe pˇripojena, pomoc´ı n´ asleduj´ıc´ıho kusu konfigurace tohoto routeru: interface Vlan150 description Vlan with routeable addresses ip address 195.113.1.1 255.255.255.0 ! extended ACLs for antispoof protection ip access-group 151 in ip access-group 150 out ! ! ingress filter for Vlan 150 access-list 150 remark ANTISPOOF-FOR-INGRESS-TRAFFIC access-list 150 deny ip 195.113.1.0 0.0.0.255 any log access-list 150 permit ip any any ! ! outgress filter for Vlan 150 access-list 151 remark ANTISPOOF-FOR-OUTGRESS-TRAFFIC access-list 151 deny ip 195.113.1.0 0.0.0.255 any log access-list 151 permit ip any any
7.3
Autentizace na vyˇ sˇ s´ıch vrstv´ ach ISO/OSI
Pouˇzit´ım autentizace (napˇr. pomoc´ı protokolu SSL) lze dos´ahnout docela dobr´eho stupnˇe ochrany. Pakety, kter´e nejsou autentizov´ any, jsou sice zpracov´ any operaˇcn´ım syst´emem a tud´ıˇz m˚ uˇze doj´ıt k ACK storm, ale nejsou d´ale pˇred´any aplikaci. 13 z
OpenBSD byl IPF odstranˇ en po neshod´ ach zp˚ usoben´ ych licenc´ı IPF
8
7.4
IPsec
IPsec je ochrana na niˇzˇs´ıch vrstv´ ach ISO/OSI - m˚ uˇze zapouzdˇrovat cel´ y TCP paket, a t´ım chr´anit proti cel´e ˇradˇe u ´tok˚ u veden´ ych proti TCP. IPsec nicm´enˇe nen´ı pˇr´ıliˇs rozˇs´ıˇren, masovˇeji se vyuˇz´ıv´a zejm´ena pro ochranu korpor´atn´ıch VPN s´ıt´ı, zejm´ena kv˚ uli n´ aroˇcnosti na v´ ykon smˇerovaˇc˚ u a konfiguraci, kter´a je sp´ıˇse statick´eho charakteru.
8
Z´ avˇ er
TCP hijacking u ´toky st´ ale pˇredstavuj´ı bezpeˇcnostn´ı riziko. Toto riziko je nutn´e v procesu realizace bezpeˇcnostn´ı politiky zv´aˇzit a podniknout pˇr´ısluˇsn´e kroky pro jeho omezen´ı resp. eliminaci.
Reference [1] M.Zalewski. Strange attractors and http://lcamtuf.coredump.cx/newtcp/, 2001
tcp/ip
sequence
number
analysis,
[2] David Anderson, Brian Teague. ACK Storms and TCP Hijacking [3] route. Juggernaut, Phrack 50, article 6 [4] J. Postel. RFC 793: Transmission control protocol, Sept. 1981 [5] W. R. Stevens. TCP/IP Illustrated, volume 1. Addison-Wesley, Jan. 1994 [6] Pavel Krauz. Hunt, http://packetstormsecurity.nl/sniffers/hunt/ [7] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., TCP Selective Acknowledgement Options. RFC 2018, April 1996. [8] J. Postel, J. Reynolds. Telnet protocol specification. RFC 854, May 1983. [9] Cisco Security Advisory. TCP Vulnerabilities in Multiple IOS-Based Cisco Products, April 2004.
9
ˇ arkovan´e ˇsipky zn´azorˇ Obr´azek 2: Stavov´ y automat TCP. C´ nuj´ı pˇrechody stav˚ u pro klienta, tuˇcn´e ˇc´ary pˇrechody ˇ stav˚ u serveru. C´ arkovan´ y r´ ameˇcek vlevo dole zn´azorˇ nuje aktivn´ı uzavˇren´ı spojen´ı (active close), r´ameˇcek vpravo dole pasivn´ı uzavˇren´ı spojen´ı (passive close). Pˇrevzato z [5].
