Ke spoofingu - predpokladam, ze bezny zakaznik bezneho ISP prakticky neni schopen zmenit svoji adresu (resp odeslat takovy packet siti ISP). Natoz na ji zmenit na IP adresu, ktera ani neni z rozsahu daneho ISP.
Nebo na antispoof pravidla vetsina ISP kasle? IMHO i kdyz je ISP jedno, ze mu zakaznik obejde accounting (podle IP) mel by si dat pozor, aby ven z jeho site nechodilo co nema.
No u nas na antispoof ci nejaky IP accounting nebo logovani u ADSL linek kasleme zvysoka. Nevyplati se to. U hostovanych serveru pocitame trafik podle portu a nikoliv podle IP, takze tam predpokladam antispoof pravidla asi taky nebudeme pouzivat.
My jsme tranzitni uzel, takze z nasi site ven muze chodit cokoliv a nema cenu to filtrovat, protoze to snizuje propustnost a zvysuje administrativni naklady. Mame snad jen par filtru na vstupu. Je to ale asi 5 let co jsem se o tohle detailneji zajimal.
Pro vetsinu aplikaci se nejaka security vubec nevyplati implementovat. Rozhodne ne pro dedicated server hosting. Je vec zakaznika, kdyz si chce nastavit firewall, tak at si to tam u sebe nastavi. Kdyz dela bordel tim, ze si zmeni IP adresu na nejakou co neni jeho a pak to nekomu jinymu nejde tak az se na to prijde tak se mu posle mail at si to opravi. V pripade ze ne, tak ho vykopnem.
ISP to neni zadnej hightech. To se dnes dela uz v podstate za naklady (tedy zadarmo). Proc investovat penize nekam kde nemaji navratnost?
ISP, které znám, řeší spoofing na hraničních routerech pomocí reverse-path filtru. Takže adresu změnit může, ale jenom na adresu z rozsahu onoho routeru. Silnější pravidla se nepoužívají, protože přidaná hodnota se rozhodně nevyrovná nákladům.
Accounting se řeší počítáním provozu na jednotlivých portech a IP adresy se při tom nijak nekontrolují.
No, nemyslím si, že je obrana tak jednoduchá. Útočník může vždy spoofovat zdrojové IP adresy a vzhledem k mizivému používání BCP38 se mu to pravděpodobně bude dařit. Jako hlavní problém takového útoku bych považoval vysokou diverzitu prostředí a nutnost "zahlcení" linky na tak dlouhou dobu, aby došlo k přerušení BGP linky. Podle mě je o fous zajímavější na přečtení ten paper od pánů Zhanga, Maoa a Wanga.
Ten původní článek to popisuje.
Jestli ho dobře chápu, pak se nesnaží přímo ovlivnit spojení směrovacího protokolu mezi BGP peery, ale pomocí krátkodobých špiček zahltit routery tak, aby se ztratila část TCP segmentů a došlo k rozpadu spojení.
Když to dobře rozvrhnou, trefí se do backoff algoritmu u TCP a koncové uzly můžou vyhodnotit po nějakém timeoutu, že spojení je "mrtvé". V tu chvíli nastupují korekční mechanismy BGP.
Důležité je, že pokud budou směrovače nastavovat nejvyšší třídu QoS pro BGP spojení, ukládat do front podle tříd priority a uměle snižovat prioritu ostatního provozu tak, aby v této třídě nebyl, tak by útok neměl mít příliš šance na úspěch (bohužel to asi nedělají...).
Druhou věcí je ten Graceful restart timer, který by měl pomoct.
Třetím hlediskem, zmíněným v článku na rootu je problém "v laboratoři" vs. "v reálném světě". Celý útok musí být dobře časován. V původním článku je v grafech max. doba "špičky" (burst) do cca 500 ms. Bude obtížné zajistit, aby TCP segmenty z jednotlivých uzlů botnetu dorazily +/- 250 ms přes všemožné "běžné" směrovače na BGP router v rámci oné plánované špičky a netrefily se do "mezery" (u toho grafu 600 ms). Velká část toho článku popisuje, jak toho dosáhnout, ale bude to dost složité.
BTW, v článku je odkaz na starší článek, má někdo odkaz na ten současný?
Presne tak, dnesni slusne aktivni prvky na pateri maji QoS a implicitne v nem 5% s nejvyssi prioritou pro tuto komunikaci .. tech 5% staci. Takze jakykoli jiny provoz nemuze zahltit cele pasmo. Urcite je tomu tak na Juniper (coz je mimochodem vetsina core patere v USA). Jestli tohle ma vsude implicitne i Cisco to nevim.