ali IPv6 promet predstavlja varnostno grožnjo?
Seveda jo predstavlja, če je nekontroliran. Leta in leta se že opozarja, da IPv4 firewalli niso prav uspešni pri identifikaciji in odkrivanju IPv6 tunelov iz internih mrež na tunnelbrokerje…
Carolyn Duffy Marsan iz Network Worlda je to zaprašeno tematiko spet privlekla na dan, kar pa ni nič narobe. Saj se vsi zavedamo, da legacy IPv4 firewalli ne detektirajo 6to4 tunelov, Teredo paketov (IPv6 enkapsuliran v legalne IPv4 pakete) in sorodnih tranzicijskih IPv6 mehanizmov, kajneda?
Kako se pred tem zaščititi? Najboljša zaščita je vpeljava IPv6 na lokalno omrežje (in tudi vsa ostala). S tem v veliki večini primerov preprečimo nekontrolirano tuneliranje, saj zvedavi nadebudneži znotraj našega omrežja, ki bi radi testirali IPv6 nimajo potrebe po tunelu, če je ta protokol že prisoten na omrežju. S tem pridobimo to, da prevzamemo kontrolo nad prometom na firewallu, pa čeprav od tam naprej mi delamo tunel na tunnelbroker. Ponavadi se eksperimentiranje s tuneli konča pri ugotovitvi “glej, kako mi dela IPv6”, po možnosti se na interni mašini, kjer se problematični tunel zaključuje vklopi še “packet forwarding”, za hec se postavi tudi Router advertisement daemon, seveda brez IPv6 firewalla za vsaj osnovno obrambo in naše lokalno omrežje je kar naenkrat skoraj v celoti brez zaščite izpostavljeno zunanjemu svetu.
Poleg tega imamo tu še Teredo protokol, ki je po defaultu omogočen na MS Windows OS-ih. Teredo server je pa anycastan, tako da vsa zadeva čisto avtomatsko deluje, samo če host najde pot do anycasted Teredo serverja. Kakšna krasna varnostna luknja, odprta na dolgo in široko…
Ne glejte tako zaprepadeno – tako to je. Denial je najslabša varianta zagotavljanja varnosti.
Poleg vpeljave IPv6 v naša omreža se lahko zaščitimo tudi z layer7 deep-packet inspection firewalli, ki razkopavajo promet in ga analizirajo. Kolikor vem je PaloAlto Networks v verziji 3.x PanOS-a že implementiral razpoznavanje IPv6 prometa, stestirati pa moram še, ali razkopava tudi 6to4 tunele. Moral bi jih, saj niso enkriptirani.
Predvidevam, da bo tudi Andrej iz Astec-a na to tematiko sem napisal kaj iz prakse, saj se je Astec s to problematiko najverjetneje že srečal v obstoječih omrežjih in verjetnu tudi uspešno odpravil.
Pa še zgodbica za konec: V ponedeljek smo za 1 uro priklopili PAN firewall v interno omrežje enega velikega slovenskega podjetja, ki naj ostane anonimno. 1 uro je škatla prejemala promet iz “mirror” porta na routerju, ga analizirala in na koncu postregla na pladnju nekaj podatkov, ob katerih je network managerju spolzelo par kapljic potu iz čela. Niti v najhujših in najbolj morastih sanjah si ne bi želel rezultatov analize, kakršno je zagledal.
Verjamem, da bi bil pogled kateregakoli network managerja zelo podoben, če/ko bodo odkrili, kaj vse se pretaka čez tunele, katerih ne vidijo, ne zaznavajo in se jih sploh ne zavedajo – kar pa nikakor ne pomeni, da jih ni.
Dobro jutro, bi mogoče kavico? 😉
Jan Žorž
P.S: Če ima kdo kakšna vprašanja na to tematiko in bi jih rad zastavil mimo tega bloga -> <jan@go6.si> . Razumem, da so te zadeve lahko zelo delikatne in včasih niso ravno za vso javnost 🙂
Vaš IP naslov (ali ste na IPv6 ?):
3.128.226.128
V minuti našel dva junaka, ki uporabljata TEREDO na IPv4 omrežju. Sled:
x0060 0000 0000 0000 0000 00 ………
09:22:15.389234 x.y.w.z.1953 > 213.199.162.215.3544: [udp sum ok] udp 77 0x000..0x003f prikril
0x0030 fffe 8000 0000 0000 0000 0054 4552 4544 ………..TERED
0x0040 4fff 0200 0000 0000 0000 0000 0000 0000 O……………
0x0050 0285 0091 4b00 0000 0001 0200 0000 0000 ….K………..
0x0060 0000 0000 0000 0000 00 ………
Bravo 🙂
Sedaj rabiš še tool, ki bo vse te junake lovil in firewallu dinamično insertiral rule, ki jih bodo blokirali. Tranzicijskih mehanizmov kot so Teredo in 6to4 imas pa kar precej 🙂