Názory k článku
Nebezpečné TCP?

Jeden doplnek ke clanku:

Cisco wants to patent TCP fix
http://news.zdnet.co.uk/business/0,39020645,39155257,00.htm

To je neuvěřitelná arogance, doufám, že SW patenty v Evropě neprosadí, jinak by to byla katastrofa.

Já nějak vůbec nechápu, proč se nepoužije (nepoužila) nejjedodušší zminovaná oprava, aby se porty generovaly náhodným číslem?
Realizaci této opravy brání co?
Anebo to je ve firmě Cisco tak jako v Cisco akademii, kde se učí o Internetu, jak vypadal někdy před 5-6 lety.

ale co kdyby ne?

A nedal by se dany router ochranit proste zasahem do jeho zpracovani TCP komunikace? Napsat filtr, ktery pro definovany lokalni port zahodi vsechny zadosti o reset, pokud se jich vyskytne vic s ruznymi sekvencnimi cisly kratce po sobe, by prece nemelo byt nic tak tezkeho.

Pripadne, vadilo by moc, kdyby router proste a jednoduse zahodil vsechny pozadavky na ukonceni tohoto konkretniho TCP spojeni? Predpokladam, ze BGP se zas tak casto nerozpojuje - a kdyby uz to bylo potreba, mohou si to zucastnene servery zajistit jinym zpusobem (treba specialnim TCP packetem, jehoz soucasti bude nahodne voleny a samozrejme silne sifrovany klic).

Vezmi zdrojove texty Cisco IOS, uprav, prekompiluj.

Pokud vím, na ochranu před tímto útokem na routery lze používat (a také se někdy používá) tzv. TTL hack (myslím, že o tom už byl tady na Lupě článek). Ten eliminuje pakety přicházející z příliš vzdálených míst.

no nechapu to - taky jsem nekde cetl clanek, ze konec internetu nehrozi protoze ttl..

ze by to nebylo na lupe?

http://www.pooh.cz/jirka/a.asp?a=2009477&db=
http://www.pooh.cz/jirka/a.asp?a=2009522&db=

TTL hack, tedy, ze router nastavi sve TTL na 255 a akceptuje pouze packety s TTL 255-254 je znacnym vylepsenim, ktere ISP castecne ochrani. Nicmene na sdilenych segmentech peeringovych center (jako je treba NIX.CZ) to 100% ochranu nezarucuje.

Ze by postupne odkryvani problemu CZ NIXu...;-)

Nicmene pokud neni ISP uplne padly na hlavu a nezacne pripojovat sve zakazniky primo na pater a jeho linka do NIXu jde skutecne pres realne viditelny router (tedy 1 hop, nikoli nejaky obskurtni tunel), pak pokud je TTL 255, musi se snizit prave o 1 (predpokladam, ze vice sekund to zpracovavat nebude) a zadny zaskodnik (pokud to neni primo dalsi ISP, coz lze jednoduse eliminovat) NEMA sanci tuto seanci ropzojit.

Na druhou stranu, s prihlednutim k infrastrukturam ISP si troufam tvrdit, ze je to jednak zamerne nadhonoceny problem (kdo to rozdmychava je jasne), jednak si za to mohou ISP sami a sami si kaleji do klina... - jako marketingovy nastroj se v CR obcas naprosto nemyslne pouziva - podivejte se, Vase pripojeni je tesne NIXu, nas server lezi 1 hop od NIXu, jsme primo v NIXu - ano vsechno toto jsem od ceskych slovutnych ISP jiz slysel. Zajimave je, ze opravdu velci ISP se nestydi cestu prohnat treba pres 5 hopu, kde delay je par ms (do deseti), zatimco cesti ISP na hopu naberou klidne 150ms, ale hlavne, ze maji 1 hop...

Takze si myslim, ze popsanemu problemu v souvislosti s BGP lze celit vcelku jednoduse - topologie site a TTL.

Hm ... Pokud ma nekdo za to, ze problemy ethernetove infrastruktury jsou ted postupne odhalovany, tak prave zjistil, o cem ethernet je :-)

Stejny problem maji vsecha peeringova centra, ktera na ethernetu bezi.

Ja samozrejme nevim, jak zpivaji (brnensti) obchodnici ISP pri lapani zakazniku, nicmene realita je, alespon u tech skutecne velkych (samozrejme vcetne ceskych) ISP, jina.

Mno ono kdyz se do firewallu da par pravidel:

mejme linku z A do B

u stroje A:

co prijde odjinud, nez linkou z B a ma IP adresu B, zahod.

u stroje B:

co prijde odkudkoliv a ma moji IP adresu, zahod

+ obdobne pravidlo pro obraceny smer (z B do A)

Tudiz pakety jdouci do A s ip adresou B budou prijimany jenom z interfacu, ktery vede primo k B. a B neposle Acku paket s jeho IP adresou, pokud ho nevygeneroval on sam. A jak ma ted nekdo sanci poslat Acku nejaky RST paket, kdyz ho Bcko hned zahodi?

Jestli nebude problem v tom, ze vetsina ISP pouziva smerovace ke smerovani a nikoliv k firewallovani ... Navic obvykle firewall ma nizsi propustnost (az o nekolik radu) nez smerovac na stejne HW a SW platforme.

Ale kdyby tyto podmínky byly zahrnuty v softwaru směrovače?
Jestli ono to nebude tím, že když začne mít někdo dominantní postavení, tak dělá, že "o hackerech a virech ještě neslyšel".
Takže tyto věci si musí každý (spíše amatérsky) nějak vyřešit sám. Potom ovšem vzniká otázka, jak se pozná profesionál? Asi hlavně tím, že se mu musí za software se známými nedodělky platit.

Proc? MD5 authenticated BGP session je reseni na urovni, bez bastleni a zadarmo (Cisco i Juniper).

Uz jsem slysel povidat o utoku prostrednictvim toho md5 :-)

Na zpracovani te md5 potrebujete cas na procesoru te masiny. Takze ji poslete "par" paketu s md5 a uvidite, jak se zadycha. Velke smerovace nejsou zadni procesorovi prebornici (predpokladam, ze u Juniperu to bude podobne jako u CISCO Systems).

Vzhledem k tomu, kolik je potreba procesoroveho casu na zpracovani ostatnich cinnosti, ktere takove zarizeni dela (hlavne process forwarding), tak je overhead MD5 relace celkem zanedbatelna zalezitost, pokud tech relaci pochopitelne nejsou tisice.

Nepredpokladate pocitam, ze DoS utok musi byt veden jednim paketem, ze? :-)

Ma to problem - spatne MD5 packety jsou zahozeny. Samozrejme zalezi na kvalite dotycne platformy, jak moc ji jde/nejde to zahazovani MD5 packetu. Mimochodem, stale casteji se mi potvrzuje skutecnost, ze s tim bordelem, ktery v soucasne dobe po Internetu putuje, si PC router s Linuxem nebo xxxBSD dokaze poradit lepe, nez proprietarni platformy. Ma samozrejme sve mouchy, ale vetsina problemu je resitelna prave procesorovym vykonem a ten prave tato platforma dokaze dodat ve velkem mnozstvi a velmi lacino.

Samozrejme, ze jsou zahozeny. Nicmene nekdo musi spocitat, ze ten paket neni validni (ci spise, ze neni validni jeho obsah). A ten utok je veden na procesorovy cas potrebny pro vypocet.

Verim tomu, ze mate dobre zkusenosti s PC smerovaci. Nicmene to nic nerika o tom, zda jsou to prave pro Internet :-)

Z hlediska toho, že Juniper je PC s *BSD bych se něčeho takového vůbec neobával.

Tohle je dlouho znama pravda, na kterou nekteri s oblibou zapominaji... mel bych ale otazku, ze svuj "RT OS" ma CISCO je zname (IOS), existuje takovych "OS" vice nebo je svym zpusobem unikat v tomto oboru? Ptam se, protoze o nikom jinem veru nevim... na stranu druhou bych prosil odlisovat OS a firmware (i CISCO ma oboji), i kdyz chapu, ze zrovna v teto oblasti se nemusime vubec shodnout.

Nebal byste se toho, ze nekolik stovek tisic paketu za vterinu, ke kterym je potreba dopocitat md5, dokaze zahltit PowerPC603 na 266 Mhz nebo PIII na 600 Mhz (bohuzel neznam architekturu Juniperu natolik, abych vedel, ktery z tech procesoru u rad M40-M160 to bude pocitat)?

Bohuzel nemam zadneho Junipera na hrani, abych to vyzkousel, ale budu vdecny komukoliv, kdo to udela.

není to jedno? Pokud to neupočítá PC, tak to neupočítá ani žádné Cisco nebo Juniper (včetně těch nejvýkonnějších). Vždycky to totiž musí počítat některý z centrálních procesorů. A nejsem si vědom toho, že by tyto stroje měly speciální koprocesor na počítání MD5 checksumů (tedy cisco má třeba hw čip na počítání kryptografických funkcí, jenomže není vždy osazen, takže bych se vsadil, že MD5 pro BGP se stejně počítá procesorem). A při vědomí toho, že pár hloupých SNMP dotazů dokáže složit sebesilnější cisco bych o nějakém výkonovém náskoku nemluvil.

Hlavní výhodou hardwarových směrovačů je to, že většinu provozu dokážou směrovat pomocí specializovaných obvodů (třeba Juniper tomu říká PFE - packet forwarding engine). Jediný drobný detail je v tom, že existují výjimky, které tyto PFE nedokážou zpracovat a musí je předat hlavnímu procesoru. Pokud tedy bude většina provozu složena z takových paketů, pak výkon tohoto stroje degradujeme na hodně mizerné PC. Proti útokům na BGP tedy nejsou odolné ani tyto stroje.

A tak nezbyva nez filtrovat prichozi data na port 179 (povolit pouze ostatni hosty, s nimiz mame BGP relaci) a jeste pridat nejaka anti-spoofing filtrovaci pravidla. Coz muze degradovat router, nicmene konkretne u platformy PC/Linux jsme po merenich dosli k tomu, ze zahazovat packety zvlada prave tato platforma v daleko vetsim mnozstvi, nez je forwardovat (coz nemusi byt u vsech platforem pravidlem).

Ad PFE - u Cisca hledejte CEF, dCEF a PXF.

Prectete si prosim tu diskusi od zacatku a zjistite, ze nejsme v zadnem sporu :-) Proste kus vlakna diskuse, ktery jste zacal tvrzenim, ze Juniper je PC s BSDckem, nema s predchozim kusem vlakna, ktery jsem zacal tvrzenim, ze jsem slysel o utoku prave na md5 BGP sessions, moc spolecneho :-)

To, ze HW smerovace jsou odolne proti vyse uvedenemu utoku, jsem, troufam si tvrdit, nikdy netvrdil :-)

Napoprve jsem napsal dost dlouhy elaborat. Bohuzel provozovatele LUPY(.cz) ji nejsou schopni udrzet bezici, takze cely ten text zahucel do /dev/null. Takze to vezmu kratce.

V software smerovace je samozrejme funkcionalita filtru zahrnuta. Nicmene problem je v tom, ze cim vic podminek, tim vic klesa smerovaci vykon (prosim nechytat za slovo, vim, ze to neplati vzdy). Navic cim vic podminek, tim vetsi moznost chyby.

Samozrejme namitnete, ze tu mame skvele, levne a flexibilni PC smerovace. Takove PCcko, na kterem bezi Linux nebo *BSD s BIRDem, gatedem nebo Zebrou je sice moc hezke a levne, ale take velmi nebezpecne. Ono vcera mohlo delat nekde web/mail/sql server. Nojo, ale co kdyz admin toho stroje zapomel vyhodit nejakeho toho demona? Vsichni jsme omylni a kdo nikdy neudelal chybu v konfiguraci, at hodi kamenem. A cim vic takovych PC mate na spolecnem segmentu, tim vic stoupa pravdepodobnost, ze se nekdo dostane k mediu (a pak zatopi vsem).

Jojo, co kdyz admin toho cisco routeru si nastavil heslo pro telnet 12345 a enable password ten samy a nema omezeni pristupu na telnet k tomu routeru podle IP adres? Co bezpecnostni diry v IOS? Nebezpecnost obou platforem je velmi podobna. Zbytek je ukazka typicke krskovske demagogie.

Nebezpecnost platforem NENI podobna. Je naopak zcela rozdilna (spociva ve zcela jinych vecech).

Mozna jste chtel rict, ze mira nebezpecnosti je podobna, v tom s Vami musim souhlasit. Problem jednoucelovych smerovacu spociva hlavne v tom, ze nemate pristup k uplnym datum o architekture tech systemu a velmi obtizne budete hledat slaba mista (jak ve vykonu systemu, tak chyby v HW/SW).

Jinak blahopreji k vynalezu spojeni "typicke krskovske demagogie". Vyridim to clovekovi, jehoz jsem citoval - Stevenovi Bellovinovi (verim, ze Vam to jmeno cosi rika).

To je ten pan, co z byvalych webovych/mailovych/sql serveru dela paterni routery? ;-)

Nikolivek.

Co se myslí tím, že "admin toho stroje zapomnel vyhodit nejakeho toho demona"?
I když možná Michal K. žije mezi lidmi, kteří při instalaci nového softwaru také zapomenou zkopírovat uživatelům část dat. Nemělo to tedy znít: "Máte-li za admina takového blbce jako my, tak PC s Linuxem je nebezpečné."

Dobry den,
znamena to presne to, co jsem napsal. Predpokladam, ze jste jeste zadnou chybu v konfiguraci zadneho systemu neudelal. Zkuste se zamyslet nad svoji dokonalosti. Treba nakonec nebude tak dokonala.

MK

Kdyby mi právě dnes dopoledna manželka netelefonovala, že jí jeden blbec při re-instalaci nového systému smazal odesílanou poštu, kde měla všechny adresy, tak bych asi neodpovídal.
Ale ona je chyba a chyba. A pokud se někdo standardně vymlouvá, že chybu dělá každý, tak to je typická reakce správce, který "rychleji instaluje než přemýšlí".
U nás jsme kdysi měli také takového experta. Ten se nikdy nenaučil ladit (snad jste o slovu ladění již někdy slyšel), takže vykládal, že všechny změny se musí dělat za provozu, aby mu totiž hned lidi (po telefonu) sdělili, na co zapomněl. - A skutečně to nakonec bylo, jak říkáte. že když on přestal routovat na SUNu a koupilo se Cisco, přestaly i problémy. Ale na mnoha místech mají i mnohem pečlivější správce, kteří prostě nachápou, kdo by mohl zrovna na směrovači mít delší dobu zapomenutého démona.

Vite, ale ja nerikal, ze VSUDE jsou hloupi spravci. Rikam to, ze pruser na sdilene infrastrukture muze udelat jeden z padesati, ktery jednou udela chybu. A pravdepodobnost je pekna mrcha, hraje proti nam. Takze nam nepomuze MNOHO firem, ktere zemestnavaji spolehlive adminy, k prusvihu staci JEDNA, ktera treba resi personalni krizi.

Michale, netroufam si za boha tvrdit, ze jsem nikdy pri konfiguraci neudelal chybu, ale co na zaver zasadne udelam je ze zgomnu, co mi fyzicky po standardnim nabehu za procesy nastartuje a jake komunikacni porty (tim nemyslim pouze TCP) to kde otevira pro komunikaci.

Chapu, ze jine OS (treba IOS:-)) mohou mit se sdelenim techto udaju vetsi problem a treba neexistuji nastroje, jak se techto udaju dopidit (pak tu mame externi nastroje a pruzkum), to ovsem neni problem blbosti ci chyby admina... A ze bych zapomnel nekde bezet daemona, tak to se mi veru za ty roky (nebude tomu uz deset let?) jeste nestalo, naopak, obcas nebezelo (cti: na portech neposlouchalo) i to, co bylo zamysleno...:-)

Das ruku do ohne za to, ze stejny postup delaji vsichni admini vsech ISP? Tohle neni diskuse, kde mi sdelujes, jak jsi dobry. Tohle je diskuse o tom, ze NE VSICHNI jsou tak dobri.

Nebo spise ze ne vsichni delaji svoji praci v adekvatni kvalite, coz je bohuzel pravda, o ktere se rozezleni zakaznici dnes a denne presvedcuji...

BTW, i vykon takove PC smerovace pomerne silne klesa s poctem pripadnych filtrovacich pravidel. Na druhou stranu, pravidla typu "ma-li to direct network adresu, ale prislo-li to ze spatneho smeru tak to zahod" se, prave kvuli vykonu, casto "zadratovavaji" misto toho, aby se nechavala implementovat generickymi mechanismy.

no a co brani mit tech pcsmerovacu vic? ano asi tezko se budou nasazovat na patere ale jako ty okrajove body kdete by znemoznili paketum co dovnitr nepatri se jiste pouzit daji.

Vic aktivnich prvku => vetsi sance, ze udelate chybu v konfiguraci.

Ostatne je tu otazka, co myslite temi pristupovymi smerovaci. Pristupovy smerovac muze byt krabice, ve ktere konci kanalovana STM-4, ve ktere jede nejakych 500 zakazniku. A STM-4 karty se do PC spatne shaneji :-) Nebo to muze byt smerovac, kde se schazi DSL provoz z cele oblasti. A to nikoliv provoz mistni parodie na DSL, ale skutecne nejakych 1.000 useru se skutecnym broadbandem.

PC smerovace maji urcite sve misto na slunci, ale mam dojem, ze spise pri resenich ve firmach nebo nejakych ISP, kteri se zabyvaji spise provozem serverhostingu nez v klasickych telco sitich.

Samozrejme bude spousta lidi, kteri budou mit jine nazory a spoustu success stories. Kazdy ISP ma nejak rozlozene naklady a nekdo treba riskne vetsi pravdepodobnost chyby nebo vice techniku, kdyz ho to bude stat mene investic.

Mozna uspech metro ethernetu je duvodem rustu obliby PC-based routeru. Mozna naopak pouzivani PC-based routeru urychluje rust obliby metro ethernetu. Patrne oboji. Samozrejme svuj podil ma i CPE.

lip bych to nerekl ;-)

... a co z toho plyne? Tedy krome toho, ze PC routery lze nasadit v metropolitnich sitich zalozenych na ethernetu.

Napriklad to, ze mene zakazniku si koupi proprietarni router s kanalovanou STM-4 kartou, tim se onen router i ona STM-4 karta stanou o neco drazsimi (hure se rozpousteji naklady na vyvoj a vyrobu do mene kusu), tim se zvedne cena techto reseni -> vice uzivatelu bude mit zajem na vyuzivani levnejsich sluzeb zalozenych na metro ethernetu atd., opet se proda mene routeru s kanalovanou STM-4 a uz je tu jenom spirala pozitivni zpetne vazby.

V tom pripade nezbyva nez blahoprat vsem priznivcum placatych siti s PC smerovaci (a taky utocnikum na tyto site) :-)

Neni to primarne zavisle na poctu pravidel, ale spise na strukture pravidel... Se stejnym mnozstvim pravidel se zmenou jejich struktury (poradi a zarazeni do stromu) da dosahnout nekolikanasobneho zvyseni propustnosti. Krome toho, BGP relace obvykle na dotycnem routeru konci a tedy chain INPUT, kde tolik pravidel nebyva.

Mozna jsem to nerekl protoze jsem to povazoval za zcela samozrejme, ale tim poctem pravidel jsem myslel pocty pravidel vyhodnocovanych. Ze zajimavosti jsme na to kouknul - u me se 80% paketu se vyhodnoti behem prvnich osmi pravidel. Byvaly to prvni tri. Budu se nad tim muset zase zamyslet. V praxi mam vyzkouseno, ze uz deset pravidel ma za nasledek viditelne snizeni pruchodnosti (pri zdejsich tocich v radu 30Mbps).

Mimochodem, z toho, jak automaticky pocitate s tim, ze dotcenem pocitaci je "chain INPUT" se pozna Linuxak. Jen uzivatele Windows a Linuxu jsou prosluli tim, ze si mysli, ze vsichni ostatni take pouzivaji Windows/Linux. Tedy, abych nekrivdil - okenici si mysli, ze jediny OS na svete jsou Windows, kdezto Linuxnici vedi, ze krome Linuxu jsou tu jeste Windows ... ;-).

Na mem oblibenem open-source OS je nativne jiny filtr takze neco takoveho jako "chain INPUT" ja vubec neznam. Ale nic ve zlem ...

Hmmm, nerozumime si. "Chain INPUT" je zjednodusene oznaceni filtrace packetu, ktere konci na localhostu, pouze vychazejici z linuxove terminologie. Oproti tomu FORWARD je filtrace pruchozich packetu. V nekterych pripadech je to rozliseni mezi pruchozimi a terminovanymi packety pomerne prakticke. Je mozne, ze jine systemy toto deleni neznaji (ipfw z neznam, bohuzel). Na Ciscu to deleni neni (access-list na interface je jednotny a jeho platnost u napr. vty linek se vztahuje jen na dotycnou sluzbu). Nemyslim si, ze vsichni ostatni pouzivaji Windows/Linux a vas narek mi pripomina narky na Cehunov od lidi kolem Matice slovenske ;-)

Mimochodem, jisty kolega je velky priznivec vsech moznych BSD, tak jsme delali testy, ktery system je vhodnejsi na routovani (takove veci, jako je non-blocking throughput na stejnem zeleze apod.), dosli jsme k zaveru, ze to je v podstate stejne, takze jde uz jen o to, komu se s cim lepe pracuje.

To nebyl narek, spise pobavene pripodotknuti. ipfw (spravne jste odhadl o ktery jde) ma rozlisovani podle interface, kterym paket do systemu vstupuje i podle interface vystupniho, ale nema nic, co by se dalo vhodne oznacit slovem "chain". Nicmene, nechme popichovani.

Jinak, naprosto souhlasim s tim, ze primarni rozdil je v tom "na co je clovek zvykly". Rozdily ve vlastnostech sice jsou, ale obema smery.

Kazdopadne by bylo k takovemu clanku i pridat jak to maji ostatni vetsi hraci (Juniper, Extreme...).

Jinak dik, na lupu docela prijemne poctenicko :-)