Názory k článku
Jak Pákistán unesl YouTube

Diky za evangelizaci bezne populace Zbynku. Ne kazdy odebira NANOG list :-)

Hlavne ze ty jsi nam neopomnel sdelit, ze ty patris "mezi vyvolene".

Ktere vyvolene prosim? NANOG je verejna konference, kterou si muze subscribnout uplne kazdy.

Archív konference NANOG (u Merit network)

Tolik prispevku kvuli tak zbytecne veci? Priznam se ze jsem se ani neobtezoval podivat do logu svych BGP routeru jak na tom bylo nase AS.

Vy logujete BGP updates per prefix? To mate trvale zapnuty debug?

JIste, ale hlavne netusim, proc bysme to meli delat :)

Originál na http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml

Objev Ameriky. Ten odkaz je přímo v článku.

rip se podsunuje a i krade uzasne - kor kdyz v tom maj mirkotik

Zajímavý článek, ale mám jednu výtku. Některé části jsou pro laiky (tj. mě :-) ) jen málo srozumitelné. Doporučuji Vám, abyste nějdříve podobné články dal přečíst třeba své přítelkyni (pokud to je totální IT střevo, tak nějakému kamarádovi), aby Vám zatrhala čemu nerozumí a to jste mohl následně přepsat zjednodušeně.

Nejsme na TV NOVA, ale na Lupe. Takze od ctenaru lze predpokladat minimalni orientaci v problematice.

Pokud by se tu objevil 10strankovy clanek "step-by-step konfigurace TCP/IP ve windows" bude se rozcilovat daleko vic lidi.

Pak mi ale nesedí, že se autor snaží objasnit, mimochodem dosti neuměle, co je to prefix, ale zároveň úplně bez okolků a dalšího vysvětlování používá slovo peering :D

děkuji autorovi za kvalitní článek, ač jsem laik a všemu jsem neporozuměl. Myslim, že učit se musíme my laici, a ne aby se přizpůsobovali odborníci nám.
Díky

Jsme snad na Lupě a ne na Blesku :). Kdo tady neví, co je maska a router ať zvedne ruku a stydí se :D.

za neznalost se stydet nemusi, ale spis by mel klast dotazy opatrne a ne brat sebe jako etalon ctenare. Obvykle je lepsi, kdyz dotycny prizna, ze nevi, nez aby ostatni pul stranky zjistovali, ze je tomu tak.

v routovani zadny machr nejsem, nejaky odkaz na obecnejsi vyklad sitove problematiky by v clanku bodnul :) jinak ten clanek je zajimavy, s poznamkou o seskrtani nesouhlasim, ale budu si muset nektere veci dohledavat :)

Tak já o routování taky nic nevím, to ale neznamená, že nedokážu pochopit, o čem článek je, a v čem byl problém. A myslím, že podobná úroveň vzdělání se očekává od všech čtenářů Lupy, jednak je to poměrně odborný časopis.

Tak samozřejmě, když někdo neví, ať to napíše a my mu to vysvětlíme.

Já jsem se chtěl jen ohradit proti tomu, že podobný článek patří pod rubriku "pro znalce". To tu Lupu rovnou můžeme zavřít :)...

Ja vim co je maska a router, ale u velke casti clanku se stejne nechytam. A dle mnoha dalsich prispevku nejsem sam. Cili, muze mi to nekdo prelozit?
Btw pro ´jisty typ reagujicich´: taky se umim posklebovat a vytahovat s tim co vim a umim a ostatni ne ("haahaaa, vy nerozumite kdyz vam odepisu latinsky? looooseri!"), ale uz od skolky to nedelam.

Rád ti pomůžu, ale nebude to "zadarmo" :). Nevím, jestli by jsi pochopil přímé a jednoduché odpovědi a proto tě odkážu na "Počítačové sítě a "Rodina protokolů TCP/IP" od Peterky.

Počítačové sítě
http://www.earchiv.cz/l218/index.php3

Rodina protokolů TCP/IP
http://www.earchiv.cz/l217/index.php3

Na těchto dvou přednáškách začínal nejeden síťař (včetně mě).

Kdo to přečte, tak už na Lupě nebude nikdy tápat.

Vase neznalost neni problem autora.

Ještě bych přivítal aspoň jeden malý odstavec, kde by se člověk dozvěděl jak k takovéhle události může vlastně dojít. To si všichni provideři navzájem věří? Respektive, to může kdokoli poslat do celého světa informaci "Prefix 212.71.0.0/16 teď patří mě a budete ho směrovat přes naše routery, neřádi!"?

Muze. Jsou jiste mechanismy, ktere tomu brani, ale jejich ucinnost je miziva.

tak to asi neni myslene uplne vazne, ze ....

Naprosto vazne. Nevim o nikom, kdo by pouzival SO-BGP, SBGP nebo PGBGP. Podle RADB ci RIPE databaze filtruje prefixy tak 1% operatoru (a par route-serveru v IXech, dobre). Ostatni se smiri s AS-path ACL, ktere by uvedenemu pripadu nezabranily. Je vhodne si uvedomit, ze filtrovani podle prefix-listu je sice ucinne, ale je pomerne pracne a provozne komplikovane ty prefix-listy udrzovat (s moznosti zavleceni chyb, samozrejme). I pres par excesu (ktere se staly uz v minulosti, ale stale to je za celou historii Internetu par pripadu, urcite spise jednotky, nezli desitky) si tedy myslim, ze je lepsi ona potencialni anarchie, co je ted, nez nejaky dirigismus, ktery tech problemu zpusobi daleko vic.

Zbynek ma pravdu. Navic se obavam, ze se zavedenim striktniho filtrovani podle RIR DB odriznete velkou cast Internetu od vlastni site. Pokud vim, tak RIPE DB je nejpecliveji vedena databaze, a presto vim o spouste operatoru, kteri tam prislusny route zaznam nemaji.

Internet je designovan tak, ze veskera inteligence ma byt na koncich. V pripade smerovani na koncovych smerovacich. Bohuzel dneska je ISP kazdy, kdo si koupil PC s mikrotikem a naklika tam nejake veci bez znalosti jak to funguje, hlavne, ze to funguje.

Kdyz se k tomu prida laxne udrzovany (nebo neexistujici) filtr u tranzitniho ISP, je na problem zadelano.

Chyby se stavaji vsude (pametnici mozna vzpomenou na IPv6 /32 UUNETu, ktery se povedlo vyexportovat v mnoha /64), bohuzel vsak dnesni Internet je nastaven tak, ze se jejich dusledky promitnou globalne.

Na sikovny dvouhodinovy DoS dnes nepotrebujete armadu botu, staci jeden smerovac :-) Bohuzel se to neda vyresit nakupem nejakeho krabicoveho software, proto zustava ten problem zcela mimo zajem medii.

Treba OpenSUSE se da koupit i v krabici a quaggu obsahuje. ;-)

Problem je spise s pristupem k siti, najit nejake BGP, ktere se bude ochotne bavit s neznamou IP adresou. Na zaskodnicke vypropagovani nejakeho prefixu neni potreba ani zadna extra implementace BGP.

Jenze nakup OpenSuse nic neresi.

Naopak, jiste bezi ve svete vic aplikacne bohatych Linuxu s Quaggou v roli hranicniho BGP smerovace nez podobnych boxu s napisem Juniper/CISCO Systems.

Mam trosku obavu, ze prave nasazovani PC v roli hranicnich smerovacu muze dobu, kdy budou podobne utoky na dennim poradku , priblizit.

At zije spravny low cost provider s linuxem v roli hranicniho smerovace, smtp serveru a webu pro zakazniky! Tisice dekovnych dopisu azbukou, skvele reference.

Ja jsem na to nechtel kupovat krabicovy SW, ale kdyz byl pozadovan, rad poradim.

Takovych utoku pribyvat bude s tim, jak postupne klesa rozsah znalosti prumerneho admina. Ale prece jen pokud budou podlehat hranicni smerovace, tak to nebude tak zle. Zle to zacne byt az zacnou podlehat tranzitni smerovace.

Prece jen jeste po nejakou dobu budou spravci na tranzitu dost paranoidni, aby nenakoupili od zakaznika prefix, ktery mu zjevne nepatri. On take maloktery zakaznik je pripraven na to, ze mu siti protece par gigabit jen proto, protoze jeho sit zakoncena ve dvou statech je levnejsi cestou pro zahranicni konektivitu.

Tento pripad byl proste drobnym vypadkem, vzdyt se nakonec nic nestalo. Porad lepsi nez 4 pretrzene optokabely ted nebo ty pretrhane zemetresenim loni v HK. Tam nesel inet cele dny.

Ano.
Je to trochu podobne LAN, kde taky muzu delat bordel, zde muzu delat bordel jenom velci provideri.
ISP se tomu branit mohou jenom vuci svym klientum, tedy odfiltruji jim jine IP, nez ktere skutecne maji a tim jim zabrani, si nastavovat IP mimo jeji rozsah.

mozna kecam, kdyz tak mne dementujte, ale neni to tak, ze svet se dozvi, ze ten prefix patri jemu, svet se jen dozvi, ze zrovna do te site umi paket dorucit.(to ze pakety konci v null uz neresi) A na tom principu je zalozena ochrana pred vypadky tras. Tedy jednoduse receno na tom je zalozena "spolehlivost" Internetu.

Pokud jsi managor, ktery chce smluvni zaruky absolutni funkcnosti spojeni, tak si objednej privatni linku k cili :-)

Díky, tohle byl pro mne poslední dílek skládanky, už chápu jak to bylo :).

PS: Pokud čtenář narazí na odborném magazínu něco, co ho zajímá, a nerozumí tomu, je to přece nejlepší příležitost se něco nového naučit, a ne nadávat!

Konecne to niekto objasnil aj z technickeho hladiska, nie len bleskove senzacie, ako po inych serveroch.
Dakujem.

len by som podotkol ze v piatok nepracuju aj zidia, nielen moslimovia

ja vzdy myslel ze zidovske nabozenstvi ma svatecni den sobotu

To jo, ale pracovat přestávají už v pátek nějak kolem západu Slunka. :-)

Tak to snad přestává pracovat každý, ne? :-)

Ne, je jista nemala skupina lidi, ktera nezapina soustruh v 6.20 a nevypina v 13.40. Muze se to zdat divne, ale je to tak :-)

Francouzi maji jeste prisnejsi nabozenstvi, ti prestavaji v patek pracovat uz nekde kolem poledniho. :-)

Francouzi nekdy pracuji? Vzdycky se mi zdalo, ze jenom stoluji...

Kdepak. Jeste i stavkuji.

Ja myslel ze napises ze v patek uz naprecuji i cesi :-D. Jinak diky za vyborny clanek. Tohle si predstavuji pod pojmem odborny clanek.

Toto je jen můj subjektivní názor: Pasáž o tom, že Youtube propaguje do světa nějaké prefixy, je pro mě naprosto nepochopitelná. Totiž: Znám význam slova prefix, ale nikdy by mě nenapadlo, že A.B.C.D/x může být prefixem pro A.B.E.F/y

Je s podivem, že zatímco ze všech těch IP adres děláte odkazy, nenapadlo vás udělat odkaz z některého z těch klíčových slov jako routa nebo prefix, aby si člověk mohl případně přečíst, o čem mluvíte.

Stejně tak jsem si vždycky myslel, že bitmaska je operand pro binární operaci (nejspíše XOR), který díky té operaci z druhého operandu udělá něco jiného (například bitmaska "11111111...." vytváří při použití XOR binární inverzi). Ale ve vašem článku najednou čtu, že bitmaska /24 (???) je považována za významnější než bitmaska /22 (přičemž jinde v článku se vyskytuje i bitmaska /32),... v této chvíli jsem se totálně ztratil.

Takže bohužel z celého článku jsem pochopil pouze to, že se Pakistáncům podařilo prosadit do cizích sítí informaci, aby, pokud chtějí "na youtube", posílali požadavky do Pákistánů, který ale veškeré tyto požadavky zahazoval do odpadkového koše (null).

Stejně tak jsem v závěru nepochopil onu pasáž o "půl adresách [xxx.0/25 a xxx.128/25]" -- protože čistě zdravým selským rozumem, je-li /24 prioritnější než /22, mělo by /25 být prioritnější než /24, jenže vy píšete, že "takto malé cosi už většina providerů filtruje".

Prosím, neberte tento komentář nějak agresivně, snažím se spíše vyjádřit svůj smutek nad tím, že ačkoliv bych tomu rád porozuměl, nezadařilo se. Je naprosto jasné, že kdybych byl "T3H N3RD", tak by mi to připadalo zcela srozumitelné, ale to není můj případ.

Myslim, ze vase rekace je zbytecne agresivni. Odborne clanky mivaji odkazy na dolnujici nebo vysvetlujici literaturu a v popularne-odbornych mediich (mezi ktere radim i Lupu) mivaji ve zvyku hlavni pojmy aspon zbezne definovat nebo vysvetlit v postrannim sloupku nebo boxu. U clanku jako je tento by se to vylozene hodilo, protoze (a to se mnou doufam budete souhlasit) je jeho odbornost rozhodne nad beznym prumerem Lupy.

Článek hodnotím velmi kladně.

pro neznalce kalkulačka:
http://www.subnetmask.info/

1. Pákistánský operátor pustil do světa informaci typu "všechno pro youtube směřujte přese mě". Bohužel cílem takto nasměrovaných paketů nebyl YouTube, ale černá díra :)

2. Maska /22 umožňuje naadresovat až 1022 (2^(32-22))-2 počítačů. Maska /24 umožňuje naadresovat až 254 (2^(32-24))-2 počítačů. /32 zabere jen a pouze jeden počítač. Zjednodušeně řečeno, čím "užší" (vyšší číslo) maska, tím méně počítačů naadresujete.

3. Když se router rozhoduje, kudy má poslat paket, bere v úvahu nejprve "užší" masky a proto plně ignoroval správnou YouTube síť s maskou /22 a dal přednost té /24.

4. "A.B.C.D/x může být prefixem pro A.B.E.F/y" - tady spíš narážíme na omezenost zápisu v desítkové soustavě. Ještě pro upřesnění, zápis A.B.C.D/22 a A.B.E.F/24 znamená, že A.B.C.D/22 pojme A.B.E.F/24 a další tři /24 podsítě, které zde nebyly uvedeny.

5. Filtrace /25 je problémem, protože takto malý rozsah už nepojme ani jeden "C" rozsah (http://en.wikipedia.org/wiki/Classful_network) a tudíž může na opravdu velkých sítích vypadat nedůvěryhodně. Pravděpodobně proto jsou takovéto "úzké" rozsahy ignorovány.

Pokud se mýlím, prosím o opravu a doplnění. Přiznám se, že i já jsem se ve článku občas ztrácel - hlavně kvůli dlouhým souvětím :-)

Vetsina ISP filtruje podle delky site predevsim proto, ze kazdy zaznam zabira cenne misto v RAM smerovacu.

Sveho casu byl nejproflaknutejsi SPRINT, ktery filtroval vse, co bylo mensi nez /22 (tj. cislo bylo vetsi nez 22). Zda je v soucasne dobe jeho praxe jina, to nevim.

Pojem duveryhodnost v globalni infrastrukture muzete vztahnout na sveho nejblizsiho partnera - coz je obvykle nekdo, s kym mate primy kontakt. Jedno z mala rizik ucasti ve verejnych multilateralnich propojovacich centrech je ten, ze partnerum "verite" i pres to, ze s nimi nemate zadny realny vztah. V narodnich propojovacich centrech (jako je NIX.CZ) mate tu vyhodu, ze vidite, jak se partner na trhu chova (a tomu se muzete prizpusobit), v glogalnich (AMS-IX, LINX, DE-CIX) uz nemate sanci.

Mimochodem - i tento vazny incident pravdepodobne (dle meho nazoru) nebude mit dopad na best current practices.

Nebo - otazka na autora, rozvazali jste s pakistancema propojeni v DE-CIXu?

Pakistan Telecom tam primo neni, takze s nim nebylo mozno rozpeerovat. Porad nejake prefixy originovane z AS17557 vidime, PCCW je rozhodne komplet neodrizl (prisel by ostatne o penize). Kazdopadne Pakistanci asi jeste neslyseli o agregovani rout, takze od nich mimo jine prichazi hromada velmi snadno agregovatelnych /24.

Jak kdysi trefne poznamenal Geoff Huston, celosvetovou routovaci tabulku postihla "tragedie obecni pastviny"... ;-)

Aha ...

Copak agregovani rout, ale take filtrovani na vstupu od zakaznika :-)

Oni maji jiste spoustu "dobrych" duvodu, proc to mit neagregovane. Stejne duvody se muzeme dozvedet i u nekterych ceskych ISP. Oblibeny duvod pro neagregaci je to, ze tim u malych multihomed zakazniku prichazi agregujici ISP o provoz (coz je pravda).

Obecně IP adresa (v protokolu IPv4) jsou 4 bajty, obvykle se píše každý bajt vyjádřen v desítkové soustavě a oddělují se tečkou. Takže třeba 192.168.0.1 se dá napsat ve dvojkové soustavě jako

1100 0000.1010 1000.0000 0000.0000 0001

(odděluju číslice po 4, aby to bylo čitelnější). Bitová maska /24 znamená, že významných je jenom prvních 24 bitů (nejvýznamnější bit, tj. bit, který nejvíce změní hodnotu, je první vlevo), zbývajícíh 8 nehraje roli – je to jako kdyby ste udělal logické AND mezi bity IP adresy a masky.
Tím se dostáváme k prefixu IP adres – když si to napíšete binárně, pak třeba

192.168.0.0/16 = 1100 0000.1010 1000.xxxx xxxx.xxxx xxxx
192.168.1.0/24 = 1100 0000.1010 1000.0000 0001.xxxx xxxx

(co je na místě x, na tom nezáleží) – první je tedy prefix druhého.
/24 je prioritnější než /22 proto, že je specifičtější, obsahuje menší množství adres. Používá se to tak proto, že pak můžete dobře definovat výjimky – nadefinujete pravidlo pro větší rozsah IP adres, a z něj pak uděláte výjimku tím, že určíte pravidlo pro menší rozsah, který má přednost. /25 není prioritnější proto, že už je to příliš malý rozsah IP adres (128), takže se jím ISP ve vzájemné komunikaci nezabývají (nemůžou mít v routovacích tabulkách každou síť s pár počítači, potřebují velké celky, aby routování bylo rychlé). /25 jsou dvě půlky rozsahu /24, protože vezmete rozsah /24, kde je 256 IP adres, které se navzájem liší v bitech 25–32, a ten rozdělíte na dva rozsahy – jeden má bit 25 nastaven na 0, druhý na 1.

moc zajímavé čtení, jen se přiznám, už jsem byl trochu na vodě, zase tak tomu nerozumím. Nechce autor napsat článek, ve kterém by problematiku propojování velkých sítí a podobně, trochu přiblížil lidem, kteří sice tuší, ale takhle do podrobna se v tom neorientují? Mne třeba by to velmi zajímalo...

Mozna zkuste poridit a precist http://www.abclinuxu.cz/clanky/recenze/velky-pruvodce-protokoly-tcp-ip-a-systemem-dns . Misty narocnejsi, ale velmi zajimave.

1) Pokud to chapu dobre, tak pakistansky telekom siril ven lzivou informaci, ze umi routovat do Youtube, ale ve skutecnosti neumel. Cekal bych, ze jako reakce zacnou ostatni ISP odmitat jeho routovaci informace. Jak se takovehle pripady resi?

2) Jak moc funguje v dnesnich sitich moznost zadat do IP paketu uzel, pres ktery paket pujde jako prvni? Tim by slo podobne defektni site obejit, jenze sam vim, ze se v mnoha pripadech doporucuje takovehle informace na routeru ignorovat, protoze se tim da routovat treba za NAT. Je to u velkych siti podobne?

ad 1 - resi se to case by case. Prestat akceptovat neci prefixy je osemetna zalezitost - tim poskodim nejen dotycnou firmu, ale i sve zakazniky (nebot na Internetu vzdy komunikuje nekdo s nekym, na obou koncich je vzdycky nejaky zakaznik)

ad 2 - forwarduje se podle cilove adresy (jen naprosto vyjimecne podle zdrojove a jeste vyjimecneji podle neceho jineho, snad vyjma MPLS tagu)

Jinak směrovač = router, to jen nějaký komik zase vymýšlí novočeštinu ("nosočistoplena").

Přesně tak. Naopak ze slov jako "originovaný" mi vstávají vlasy hrůzou na hlavě.

To mate tak. Slovo "originovany" je jednoznacne. V cestine se tomu v danem vyznamu nejvice blizi "oznamovany z", ale to se da bohuzel v danem pripade vylozit dvema moznymi zpusoby.

amici tu sit /24 stale nesundali a je zajimave, ze ji vidim pres jineho mezinarodniho operatora nez tu /22.

Predejit podobnym udalostem by slo jednoduse - dusledne provadet filtraci prijimanych prefixu od koncovych AS. To by slo navic zjednodusit a zautomatizovat generovanim filtru z RIPE databaze. Cili podle me selhal i PCCW Global jakozto poskytovatel tranzitni konektivity Pakistan Telecom a ktery si mel hlidat a filtrovat sve koncove zakazniky. (Pokud ma Pakistan Telecom zakazniky s vlastnim AS, mel by samozrejme taky hlidat a filtrovat jejich prefixy a v RIPE databazi by mohl mit objekt as-set, ktery by obsahoval jejich vlastni AS plus AS jejich zakazniku a PCCW Global by mohl jednoduse filtrovat na zaklade toho as-set.)

Sediva teorie, zeleny strom zivota. Pakistan uz nespada pod RIPE, ale pod APNIC. ARIN nic takoveho nema, co vim, vubec. Ano, existuje RADB, ale ten mimoevropsti operatori prilis neupdatuji (evropsti diky exportu dat z RIPE DB ano). Mimochodem, od ktere verse podporuje IOS to, co jste prave popsal? :-)

Pokud ma PCCW Global smlouvu s Pakistan Telecomem, jiste muze mit seznam propagovanych siti jako prilohu te smlouvy. Nove prefixy se nepridavaji desetkrat denne.

Na RIR DB bych v tomto pripade nespolehal. Mnohem jednodussi je nejaky extranet pro zakazniky PCCW, ktery jim umozni vkladat propagovane prefixy s exportem do filtru.

Problem je, ze automaticky krmit filtry povazuji nekteri administratori za problem a navic novy system znamena nove investice/provozni penize a dneska je modni na strane zakaznika vykrikovat, ze cena je draha.

Cena nemuze byt draha. Ta muze byt jen vysoka nebo nizka. Sluzba ovsem draha byt muze :o)

Pozdni hodina budiz mi mirnou vymluvou :-)

Každý středně zdatný administrátor sítě podle mě dusledně provádět filtraci přijímaných prefixu od koncových AS musí.

Problém je pokud sám tranzitní AS(rozumějte ISP) začne propagovat routu, kterou vůbec nemá právo propagovat, jinam (tranzitní AS mezi sebou asi nebudou filtrovat to by bylo neudržitelné ;) )

Největší problém je pustit k takto důležité činnosti člověka co neví jak zabránit propagaci, řekněme vnitřní routy, peerů :/

Pak Internet provozuje vetsina mene nez stredne zdatnych administratoru. Muze se nam to nelibit, muzeme proti tomu protestovat, ale to je tak vsechno, co s tim muzeme delat.

Vezmenes to tak, ze BGPku v CR opravdu rozumi tak 10-20 lidi. Ti jsou vetsinou zavreni v kancelari u tranzitnich operatoru vetsina nas je nezna.

Nic ve zlem, ale lidi v zamestnani v CR u tranzitnich operatoru funguji spise jako podpurne sily :-(

Tim nechci rict, ze by BGP nerozumeli, nicmene vice prace maji cesti ISP, kteri maji nejake tranzitni zakazniky.

Priznejmez, ze BGP neni nikterak slozity protokol a v CR mame dokonce lidi, kteri napsali jeho implementaci do smerovaciho demona (a AFAIK nejsou zavreni v kancelari u tranzitnich operatoru - pokud nezmenili v posldeni dobe job).