Názory k článku Postřehy z bezpečnosti: masivní DDoS útok na DNS nebyl úspěšný

Proc? Treba duveryhodnost partnera :) Verejnych prezentaci FENIXe je cela rada, muzete se na nejakou dostavit a zeptat se primo u zdroje. Uspesnost rozhodne neni 0% - je videt, ze se sitemi moc nedelate v nejakem sirsim meritku. Ja uz realne utoky, ktere implementace BCP38 spolehlive zarizla mnohokrat zazil - vysledkem byl utok, ktery nevysel, takze uspech.

To jsou dost obecná tvrzení – kdybyste napsal, že BCP38 zastavil zhruba X procent toku, bylo by to věrohodnější.

No a pak je samozřejmě otázka, co děláte s těmi útoky, které mají zdrojovou IP adresu, která projde přes BCP38.

To jsou neverejna data. Musite se spokojit s tvrzenim, ze to funguje... :D Nebo si to nekde sam zkusit. Realny utocnik se snazi v prvni rade sam skryt a podvrzeni zdrojove IP je pomerne casty jev.

Realne utoky, ktere maji validni zdrojovou adresu se zariznou jinak. Vyhoda BCP38 je jeho snadna realizovatelnost v HW aktivnich prvku - a daji se takto resit desitky gigabitu provozu a setri to vykon jinde - narozdil od sofistikovanejsich technik, ktere jsou narocnejsi, pokud jde o analyzu v realnem case. Takze hrubou silou HW se orizne na prvni pohled zjevny bordel a pro dalsi zpracovani v sofistikovanejsich zarizenich toho je hned mene...

Pokud reálný útočník útočí ze svých vlastních zařízení, aby měl důvod skrývat útočící zařízení, není to žádná extra třída a rozhodně nevygeneruje masivní DDoS útok na kořenové DNS servery.

Reálné útoky s validní zdrojovou IP adresou musí ten ISP, z jehož sítě se útočí, nejprve rozpoznat, aby je mohl zaříznout. Proč nejde stejný způsob detekce použít i na útoky s falešnou IP adresou? A co teprve útoky s podvrženou zdrojovou IP adresou z rozsahu ISP, ty nejde vůbec blokovat podle zdrojové IP adresy.

Ten „zjevný bordel“ pochází ze zařízení, které je součástí nějakého útoku – takže je to buď přímo zařízení útočníka, nebo nějaké napadené zařízení útočníkem ovládané. Dá se tedy předpokládat, že škodlivý nebude jenom ten „zjevný bordel“, ale i jiný provoz z daného zařízení, který přes BCP38 projde. Takže by mi připadalo rozumnější použít kontrolu zdrojových IP adres jenom jako signál, který označí veškerý provoz od daného klienta za podezřelý a určí ho k dalšímu zpracování. Ze kterého pak nejspíš vyplyne, že toho blokovaného provozu bude mnohem víc, než to co by ořízlo BCP38.

Na druhou stranu, jestli BCP38 na reálné útoky zatím stačí, byla by to vlastně dobrá správa, že útočníci jsou hlupáci, kterým ještě nedošlo, jak BCP38 prostřelit. Akorát nevěřím, že to tak je.

A co teprv sofistikovanejsi utoky na infrastrukturu, ktere ve skutecnosti ani nemaji cilovou IP infrastrukturnich prvku a vyuzivaji jinych slabin... :-)

Lokalni DDoS pracka nepomuze v situaci, kdy utok ucpe linku daneho ISP. Prosta capacity game - z pohledu ISP je to samozrejme dalsi nemaly naklad. Obrana je o penezich. Samozrejme - vzdy budou site, ktere na RFC budou z vysoka kaslat - ale to opet neni argument, proc je ignorovat ve vlastni siti.

Utocnik typicky vyuzije nejak jinak kompromitovany stroj (nejaka derava aplikace apod). Predstava o tom, ze utoci administrator z vlastniho serveru je hloupa ve sve podstate :)

Typicka implementace BCP38 funguje na urovni konkretniho L3 rozhrani. Samozrejme existuji dalsi techniky, jak podvrhu IP zamezit a to v granulare konkretni IP. To, ze ISP nemuze branit zneuziti svych IP ze svych vlastnich rozsahu je jen dalsi blabol - mate hluboke elementarni neznalosti, pane kolego. Prilis casu travite u spamovani v diskuzich a na studium Vam nezbyva cas :D

Predstava o tom, ze utoci administrator z vlastniho serveru je hloupa ve sve podstate :)
V tom případě mi není úplně jasné, proč jste sem tuhle představu zatáhl.

To, ze ISP nemuze branit zneuziti svych IP ze svych vlastnich rozsahu je jen dalsi blabol
Kdyby to tu někdo tvrdil, byl by to blábol.

mate hluboke elementarni neznalosti
To tvrzení by bylo věrohodnější, kdybyste popsal, jak se ISP brání útokům s chytře podvrženými IP adresami a s pravými IP adresami, a proč takovou obranu nelze použít pro podvržené náhodné IP adresy. Zatím to totiž vypadá, že budete psát v diskusi o všem možném, jenom abyste nemusel napsat, že ISP útoky z jeho sítě ani napadené počítači v jeho síti v zásadě nezajímají, a brání se pouze takovým, kde je obrana triviální (jako BCP38), aby mohl vykázat, že proti útokům také něco dělá.

Protože o tom, že útoky s podvrženou náhodnou zdrojovou IP adresou jsou jen podmnožinou DDoS útoků tu píšu celou dobu, a vám se nějakým záhadným způsobem přihodilo, že v té spoustě komentářů jste se s tímhle faktem nijak nevypořádal.

Pokud je sit zabezpecena poradne, pak zadny "chytry" podvrh IP adresy mozny neni.

Klasifikace utoku z pohledu ISP je slozita vec - jak chcete na urovni ISP rozpoznavat, kdy jde o legitimni provoz (byt treba atypicky) a kdy o realny utok? Predstavujete si to jak hurvinek valku. Oproti tomu pouziti jinych nez pridelenych (nebo vzajemne dohodnutych) IP adres na vstupu se klasifikuje pomerne snadno. Akceptovani libovolne IP jen proto, ze panacek ma zrovna kabelovku, vedle mobil a ma nejakou ujetou potrebu to provozovat asymetricky - je v praxi nesmysl.

Absence ochran ve smyslu BCP38 utocnikovi umoznuje odeslat (relativne maly) dotaz s podvrzenou zdrojovou IP adresou na sluzby, ktere nestavove na tento paket reaguje (vyrazne vetsi - 30-500x) odpovedi. Ta zdrojova IP je samozrejme cil, na ktery se utoci. A realny utocnik je samozrejme skryt - utoci "hloupe" sluzby.

A v tomto konkretnim pripade rizika zneuziti prevazuji svymi dopady nad legitimnim pouzitim jine nez pridelene/dohodnute IP na rozhrani ISP. Tedy je dost dobry duvod, proc bordel obecne zahazovat. Nelze krecovite lpet na postupech obvyklych na konci minuleho stoleti jen proto, ze staricke RFC predpokladalo vsude kolem jen lidi s cistymi umysly. Doba se meni a je treba se prizpusobovat. Navic v tomto pripade ani ISP zadne RFC neporusi, kdyz paket zahodi - pokud nema z jeho pohledu validni zdrojovou IP.

Pokud je sit zabezpecena poradne, pak zadny "chytry" podvrh IP adresy mozny neni.
Pak je ovšem zbytečné filtrovat provoz podle BCP 38, protože vše zachytí už předtím to „zabezpečena pořádně“.

Klasifikace utoku z pohledu ISP je slozita vec - jak chcete na urovni ISP rozpoznavat, kdy jde o legitimni provoz (byt treba atypicky) a kdy o realny utok? Predstavujete si to jak hurvinek valku. Oproti tomu pouziti jinych nez pridelenych (nebo vzajemne dohodnutych) IP adres na vstupu se klasifikuje pomerne snadno.
Přičemž z použití jiných než přidělených IP adres také nepoznáte, zda jde o legitimní provoz a kdy o reálný útok. Je zajímavé, že vám to jednou vadí a jindy ne.

Akceptovani libovolne IP jen proto, ze panacek ma zrovna kabelovku, vedle mobil a ma nejakou ujetou potrebu to provozovat asymetricky - je v praxi nesmysl.
No jo, s klienty jsou jenom problémy. Místo toho, aby jako každý normální člověk používali jenom Facebook a Google, přinejhorším jiné weby, chtějí připojení k internetu. A oni ti zatracení klienti chtějí mít veřejné IP adresy, používat IPv6 nebo Mobile IP.

Absence ochran ve smyslu BCP38 utocnikovi umoznuje odeslat (relativne maly) dotaz s podvrzenou zdrojovou IP adresou na sluzby, ktere nestavove na tento paket reaguje (vyrazne vetsi - 30-500x) odpovedi. Ta zdrojova IP je samozrejme cil, na ktery se utoci. A realny utocnik je samozrejme skryt - utoci "hloupe" sluzby.
Přičemž přítomnost obrany BCP38 na tom nic nemění, akorát útočník může použít pro útok menší počet sítí.

A v tomto konkretnim pripade rizika zneuziti prevazuji svymi dopady nad legitimnim pouzitim jine nez pridelene/dohodnute IP na rozhrani ISP.
Zvláštní je, že obdobná rizika se stejnými dopady nikoho netrápí. Jestli ono to není spíš tak, že pro ISP je snadné BCP38 implementovat, a dopady moc neřeší.

Tedy je dost dobry duvod, proc bordel obecne zahazovat.
Ano, zahazování bordelu je dobrý důvod. Akorát je potřeba zahazovat opravdu bordel, a ne nějaká náhodně vybraná data.

Nelze krecovite lpet na postupech obvyklych na konci minuleho stoleti jen proto, ze staricke RFC predpokladalo vsude kolem jen lidi s cistymi umysly. Doba se meni a je treba se prizpusobovat.
Hlavně že jste měl plná ústa RFC ignorantů. Obecně s tím souhlasím, akorát si myslím, že triangular routing je legitimní věc a měli bychom se snažit, aby to fungovalo. BCP38 je obdoba NATu – je to technická obezlička na omezenou dobu, než se daný problém podaří vyřešit pořádně. Na což bychom měli neustále myslet, a ne se tvářit, že NAT nebo BCP38 je nějaký výdobytek doby a internet s nimi je lepší než internet bez nich.

Navic v tomto pripade ani ISP zadne RFC neporusi, kdyz paket zahodi
Nevím, zda je na síťovou neutralitu nějaké RFC. Ani bych se nedivil, kdyby nebylo, protože dříve nejspíš každému bylo jasné, že ISP má pakety doručovat. Nevím, jestli někoho napadlo psát na to RFC a specifikovat, že zahazovat bezdůvodně náhodně vybrané pakety je špatně.

Vazne? Uz RFC 1812 v sekci 5.3.8 pripousti validaci zdrojove IP adresy a zahozeni paketu v pripade, ze validace selze. A explicitne se tam pise o tichem zahozeni. RFC 2827 to jen dale rozviji. Takze jestli chcete tvrdit, ze v IETF jsou chore hlavy, prosim... ale jinak tu verejne priznavate, ze RFC vlastne poradne neznate ;-)
Smirte se s tim, ze ISP validujicich zdrojove IP bude postupne pribyvat. A reklamace u z jejich pohledu spoofnuteho source Vam uznavat nebudou.

Vim o cele rade ISP, ktere to implementovane maji a pred krachem skutecne nejsou ;-) Par hykalu vaseho typu jejich byznys vazne neohrozi.

Může použít všechny sítě, které nepoužívají BCP38. Síť vašeho zákazníka použít nemůže, takže už víme, že může použít maximálně n-1 sítí, kde n je celkový počet sítí zapojených v internetu. Cíl DDoS útoku bude z takové informace jistě nadšen…

v takovem pripade budu vzdy vedet, odkud prislusny provoz tece
Vědět to nebudete, a i kdybyste to věděl, je vám to k ničemu.

Pletete si totiž význam BCP38. To nezajišťuje, že když k vám dorazí paket s nějakou zdrojovou IP adresou, je ta adresa pravá. Zajišťuje jenom to, že paket odcházející ze sítě má zdrojovou IP adresu z dané sítě. To první by z toho (skoro) plynulo teprve tehd,y pokud by BCP38 implementovali úplně všichni – což se nikdy nestane.

Pokud je vaší síti a útočí na vaši síť, je to celkem váš problém. Já jsem to samozřejmě psal z pohledu někoho, kdo je cílem útoku a není ve vaší síti.

Jsem-li cilem utoku, pak samozrejme nema cenu na BCP38 spolehat a tato debata je bezpredmetna.
Tato debata vznikla na základě popisu v článku, který byl psán z pohledu cíle útoku a zároveň zmiňoval BCP38.

Implementace BCP38 je tu prave proto, aby ISP chranil okolni pred chybami *svych* zakazniku
K čemuž právě BCP38 nestačí, jak tvrdím celou dobu. A když máte řešení, které opravdu okolní sítě chránit před chybami vlastních zákazníků, to řešení pokryje i ty chyby, které by pokrylo BCP38. Což jsem psal v úplně prvním komentáři tohoto vlákna.

Pointou je, ze ochrana proti spoofingu probiha uz na rozhrani proti zakaznikovi, nikoli az na odchozim smeru na hranicich autonomniho systemu.
To je podle mne lepší řešení, ale asi to tak nemají všichni, když argumentují desítky gigabitů provozu. Nicméně ani v tomhle místě by se nemělo spoléhat na to, že škodlivý provoz <=> podvržené odchozí IP adresy, protože ty implikace neplatí ani v jednom směru.

BCP38 (neboli RFC 2827) je o ingress filtering v naprosto obecne rovine a RFC pouze rika, co by clovek na vstupu nemel prijimat. Neresi se konkretni zpusob implementace jak to udelat. Verify-unicast source je jedna z moznych praktickych implentaci - v tomto pripade u Cisca a funguje i na 10+G rozhranich - je to snadno realizovatelne v HW, stejne tak to jde resit treba za pomoci ACL (opet HW). V Linuxovem kernelu je ekvivalentem rp_filter.

Mobile IP se s BCP38 bez problemu vyporadava - viz RFC 5944, sekce 5.6. Puvodni RFC 3344 je uz pet let obsolete... racej si vsimnout ;-) Je videt, ze ty RFC moc nactene nemate, kdyz tvrdite, jak BCP38 brani Mobile IP - ne nebrani, a RFC vam explicitne rika, jak to delat...

BCP38 zabrani tomu, ze pripojeny klient bude zneuzit coby generator dotazu na sluzby uzivane treba k reflection utokum (jejichz podstatou je, ze odpoved ma jit nekam uplne jinam nez k realnemu tazateli).

Ano, jste RFC ignorant. Vas argument kolem Mobile IP je toho primym dukazem ;-) BCP38 je take jen dalsi RFC. A ze Vam se nelibi je podruzne - je to RFC, ktere komunita schvalila. NAT je v dnesni dobe nutnost - verejna routovatelna IPv4 adresa je stale vetsi luxus - ostatne na tech mobilech mate dnes obvykle adresu privatni a verejna je... za priplatek :-)

A BCP38 s se sitovou neutralitou nema spolecneho zhola nic - matlate hrusky s vejci - a implementaci BCP38 sitova nautralita nijak narusena neni.

Mobile IP se s BCP38 bez problemu vyporadava
Ne, nevypořádává se s tím bez problémů. Jenom na vohejbák na rovnák na vohejbák přidává další rovnák.

kdyz tvrdite, jak BCP38 brani Mobile IP
Kde jsem něco takového tvrdil?

treba k reflection utokum (jejichz podstatou je, ze odpoved ma jit nekam uplne jinam nez k realnemu tazateli).
A nebo že odpověď má jít k reálnému tazateli (pokud je cílem zahltit někomu infrastrukturu, vůbec nevadí, že ten útok povedete z té infrastruktury samotné). Čemuž BCP38 nijak nezabrání.

NAT je v dnesni dobe nutnost - verejna routovatelna IPv4 adresa je stale vetsi luxus
NAT je především způsob, jak obejít nějaký problém. A místo vymýšlení, jak udělat ještě lepší NAT, bychom se měli snažit vyřešit ten problém – tj. přejít na IPv6. S BCP38 je to úplně stejné – snaží se to ne moc dobře obejít nějaký problém, místo aby se ten problém řešil.

A BCP38 s se sitovou neutralitou nema spolecneho zhola nic - matlate hrusky s vejci - a implementaci BCP38 sitova nautralita nijak narusena neni.
Síťová neutralita znamená, že ISP přepravuje pakety bez ohledu na jejich obsah. Takže to s BCP38 má společného hodně.

Ono i na samotne Mobile IP jde koukat jako na rovnak na vohejbak, zalezi ciste na uhlu pohledu. Pro bezne uzivatelske use-case je vazne fuk, jakou IP klient zrovna ma.

Stale nechapete, ze neexistuje jedno univerzalni ultimatni reseni. Je to skladacka - a BCP38 je jen kostickou v cele mozaice, ktera sice neresi vse - ale dopady nekterych problemu omezuje. A to proste smysl ma. BCP38 je jinak platne i v IPv6 svete ;-) A standardy jdou jeste dal, viz treba SAVI/RFC 7039. A jinak RFC 6204 v section 4.4. -S2 vam tu BCP 38 na customer edge zarizeni odkazuje explicitne - dokonce to tam je jako MUST have... kdyz uz jste teda nakousnul tu IPv6, tak by nebylo od veci se do tech RFC zacist - prilis se ohanite vlastnimi dojmy ;-)

A k cemu je vam ta mobilita, kdyz 99% koncaku na mobilu ma stejne privatni (RFC1918) adresu? :D Jako teorie dobry, ale ty adresy proste nejsou. Mimoto, mobility RFC s BCP38 filtry pocita (a predpoklada, ze v takovem pripade se navaze tunel mezi mobilnim zarizenim a siti operatora podporujici mobilitu) - to uz jsme si tu rekli, ze? :-) Zkuste si ty RFC k mobilite prosim precist poradne.

Pro běžné use-case je jedno, jakou IP adresu zařízení má, důležité je, aby pod ní bylo dostupné. Třeba když chci navázat komunikaci s mobilem (což je dnes spousta use-case, akorát se to obchází přes různé cloudy a persistentní spojení), je mi jedno, jakou IP adresu v aktuální WiFi síti, ale potřebuju se na něj dostat pod jeho stálou IP adresou.

O žádném univerzálním ultimátním řešení jsem nepsal. Problém je, že z té takzvané skládačky máte jen BCP38, a když se zeptám na ty ostatní dílky, tak se dozvím, že vlastně neexistují a mám být rád alespoň za ten jeden dílek. Ano, v situaci, kdy ta skládačka chybí, je aspoň ten jeden nepovedený dílek jistém smyslu úspěch. Pokud teda moc neškodí a ISP dokáže alespoň na požadavek bez řečí přidat výjimku. Akorát je nesmysl tvrdit, že „kdyby všichni ISP implementovali BCP38…“ Všichni ISP to nikdy neimplementují, takže nemá smysl na něco takového čekat. Stejně jako nemá smysl čekat, že BCP38 něčemu pomůže, protože jsou jen dvě možné situace – buď BCP38 implementuje nezajímavé množství ISP, pak se tím útočník vůbec nebude zabývat, nebo BCP38 implementuje takové množství ISP, aby se útočníkovi vyplatilo se tím zabývat a útok upravit tak, aby ho BCP38 neovlivnilo. V obou případech je cíli útoku existence BCP38 k ničemu, ale ti, kdo BCP38 implementovali, si aspoň můžou udělat čárku.

Tolik IPv4 adres, aby mohl kazdy navazovat komunikaci se svym mobilem holt neni. Tez neni pravidlem, ze zarizeni ma stale tu samou IP (a to pomijim fakt, ze je z 99% neverejna). Stala IP adresa na mobilnim zarizeni je Vase chimera naprosto odtrzena od reality bezneho fungovani retail mobilnich siti.

Nikdo nerekl, ze ostatni dilky neexistuji. Bylo receno, ze to je o penezich. A to je rozdil. Zkuste nekdy predstoupit treba v plenu treba na CSIRT.CZ ci jine odborne konferenci a tam sve blaboly o nesmyslnosti BCP38 obhajit ;-)

To, že mobily mají neveřejné IPv4 adresy, je problém způsobený pozdním přechodem na IPv6. Není to tak správně a není to věc, se kterou bychom se měli smířit a pokládat jí za přednost.

Nikdo nerekl, ze ostatni dilky neexistuji.
Ano, nikdo to nechce říct nahlas. Ale z vašich komentářů to plyne dost zřetelně.

Zkuste nekdy predstoupit treba v plenu treba na CSIRT.CZ ci jine odborne konferenci a tam sve blaboly o nesmyslnosti BCP38 obhajit ;-)
Mně úplně postačí, že jako potenciální oběť útoku nespoléhám na „kdyby všichni ISP implementovali BCP38“. Ty konferenční příspěvky o tom, jak někdo spoléhal na ochranu BCP38 v jiných sítích, a vyplatilo se mi to, si rád poslechnu.

Hlavne ze Vase prezentace bezi na IPv6 :-) Hlasate, jak se maji kovat kobyly - a pritom vase kobyla chodi bosa - a to presto, ze jako provozovatel jednoho umouneneho serveru to mate vyrazne jednodussi, nez protozovatel site s miliony zakazniku. Zactete se do RFC 6459 - ktere se problematice povrchne venuje.

Tak znovu - BCP38 je z pohledu ISP o tom, ze jeho zakaznici nebudou alespon k nekterym typum utokum zneuzitelni. A nic to nerozbiji - ani tu mobilitu, kterou se soustavne ohanite (za predpokladu, ze je implementovana plne dle RFC).

Kdybych měl nějakou prezentaci, tak třeba na IPv6 poběží. Jenže ne všechno, co najdete na webu, hned musí být nějaká prezentace a ještě navíc určená pro vás. ISP je právě něco jiného, protože má miliony zákazníků. Můj web má pět a půl uživatele, a všichni jsou spokojení s tím, jak to je.

BCP38 je z pohledu ISP o tom, ze jeho zakaznici nebudou alespon k nekterym typum utokum zneuzitelni
Jenže ISP má zajistit, aby jeho síť nebyla zneužitelná k žádnému typu útoku. Což implementace BCP38 a odškrtnutí kolonky „síť je zabezpečena“ neřeší.

A nic to nerozbiji
Rozbíjí. Když já odešlu ze zařízení se dvěma veřejnými IP adresami paket, a odešlu ho přes druhou síť, než která tuto IP adresu routuje na mé zařízení, je to legitimní a neporušuje to žádné RFC. BCP38 tohle rozbíjí.

A podle ktereho RFC ma ISP zajistit, aby jeho sit nebyla zneuzita k zadnemu utoku? Dokonce ani platna legislativa toto neuklada - ta pouze uklada definovanou reakci na vznikle incidenty - ale narozdil od Vas byl zakonodarce natolik pricetny, ze nerealnou povinnost neulozil. Vy jste vazne pomatenec ;-)

BCP38 nic nerozbiji - blokace na vstupu je v souladu s RFC zrovnatak - viz treba citovane RFC 1812 nebo RFC 2827. A jak jsme si ukazali na RFC 6204 - u IPv6 jde naopak naopak o mandatory zalezitost (u IPv4 byla volitelna). To, ze to rozbiji nejake pokoutne bastly skutecne neni bug - je to pozadovane chovani. Na "mobilitu" mate RFC 5944 - to vam dost jasne rika, jak mate v pripade pouziti z pohledu daneho ISP "cizi" IP adresy postupovat.

Podle zdravého rozumu. Legislativa to zatím neukládá, protože právo je vždy pozadu za realitou. Ale vzhledem k tomu, že je to jediná reálná možnost, do zákonů se to dříve či později dostane. Sice pak bude problém to vysvětlit ajťákům, kteří uvažují jen v binární logice a ustanovení jako „pokud je možné spravedlivě požadovat“ je děsí, ale to nevadí.

Nepropustit vůbec žádný paket je také v souladu s RFC, ale drtivá většina lidí o takové přípojce do internetu prohlásí, že je rozbitá.

Zdravy rozum je odrazen v RFC - a ta filtrovani dle zdrojove IP adresy explicitne pripousti - v pripade IPv6 to dokonce vyzaduji. To ze vas chory mozek neco povazuje za spravne reseni o nicem doopravdy nevypovida. A pochybuji, ze reklamaci technicky spravneho chovani vam nekde uznaji. Ale klidne si myslete opak :-D

Ano, vim, jak vypadaji realne DDoS. A ne, scriptik s wgetem z 10k masin to typicky neni. Ucpat infrastrukturu na TCP je vyrazne slozitejsi - narozdil od UDP, ktere je u 99% DDoS utoku v realu pouzite.

Tím se ale zablokuje legitimní provoz se zdrojovými IP adresami mimo rozsah toho ISP. Já jsem se ptal na to, jak vypadá konfigurace, která ten legitimní provoz neblokuje.

Jiné adresy jsou legitimní. Podstatné je, zda ta odchozí IP adresa patří mně, ne jestli je ze sítě daného ISP. Podstatou internetu je, že pakety mohou být mezi zdrojem a cílem doručovány různými cestami, dokonce i pakety z jednoho spojení stejným směrem mohou jít každý jinou cestou.

Já nepíšu jen o tranzitním provozu. Dneska má kde kdo doma konektivitu od více ISP (pevné připojení a mobilní), a je zcela legitimní posílat uplink jinudy než downlink – třeba každou část spojením, které je v daném směru rychlejší, takže uplink mobilní sítí a downlink pevnou. To, že s tím leckde budou problémy, protože ISP často nenabízejí připojení k internetu, ale různé napodobeniny, neznamená, že ty napodobeniny máme schvalovat a dokonce tvrdit, že je to správně.

Moje úvaha popisuje jednoduchou situaci, která je na opravdovém internetu úplně normální.

jak bys v takovém případě řešil to, aby tvá síť nebyla zdrojem paketů s podvrženou adresou?
Řešil bych skutečné problémy, ne ty virtuální. Podvržená adresa paketu není problém, problém je třeba podíl na DDoS útoku.

Vždyť jsem v předchozím komentáři popisoval příklad, kdy uživatel posílá správnou zdrojovou IP adresu, přesto je tato IP adresa mimo rozsah IP adres příslušného ISP.

Nechapu, kde berete to presvedceni, ze bych jako ISP mel od bezneho zakaznika pustit skrz svou sit libovolny provoz (co se tyce SRC IP).
Protože je to legitimní provoz a ISP do něj nemá co zasahovat. ISP je od toho, aby přepravoval pakety, ne od toho, aby posuzoval, jestli se mu líbí nebo nelíbí. ISP má právo zasáhnout, pokud nějaký provoz poškozuje jeho, jeho zákazníky nebo někoho jiného – ale to nejsou pakety se zdrojovou IP adresou, která patří jeho klientovi ale nepatří do rozsahu daného ISP.

Kdyby se nahodou nekdo takovy u nas vyskytl, tak budu ochoten maximalne uvazovat o tom, ze mi preda rozumne maly seznam IP, kterym povolim prolezt.
Z mého pohledu je tohle zase maximální ústupek ze strany toho klienta. Protože správně by to mělo fungovat rovnou, bez toho, abych něco s ISP musel řešit.

Protože blokování komunikace na základě zdrojových IP adres není nic jiného, než že si ISP zjednodušuje práci a místo skutečného škodlivého provozu vyhledává takový, u kterého je z historických zkušeností známo, že u něj byla vyšší pravděpodobnost, že je škodlivý. Jenže když něco blokujete podle vedlejších příznaků, vždy tím zablokujete i oprávněné uživatele, navíc útočníci se přizpůsobí a začnou ty vedlejší příznaky simulovat „správně“. Nebylo by lepší rovnou to na straně ISP dělat pořádně? Zvlášť když je jasné, že BCP38 nikdy fungovat nebude, protože aby to k něčemu bylo, museli by to dodržovat úplně všichni.

Z pohledu ISP posilate nevalidni zdrojovou IP adresu kdykoliv, kdy se s nim nedomluvite na necem jinem. ISP nejakou adresu ci jejich blok prideli a je naprosto legitimni ocekavat, ze Vas provoz prichazi jen z tech zdrojovych adres, na kterych jste se vzajemne dohodli. Rozhodne neni povinnosti ISP akceptovat na svem vstupu libovolnou IP odkudkoliv - pochybuji, ze mate ve smlouve se svym ISP prepravu jakychkoliv paketu - naopak typicky je v podminkach (zvlast u retail sluzeb), ze pouzivate vyhradne adresu od ISP pridelenou.

BCP38 funguje - a kupodivu dobre. Je to velmi jednoducha obrana daneho ISP pred tim, ze jeho vlastni sit nebude zneuzitelna k nekterym typum utoku. Bezpecnost je cela mozaika opatreni a BCP38 je pouze casti teto slozite mozaiky. Techniky definovane v BCP38 jde dokonce pouzit pro validaci na vstupu - mate-li poradny HW. A pak se nemuze stat, ze do site prijde paket, ktery ma zdrojovou adresu, ktera neni nikde realne routovana. A takovych adres je pomerne dost...

Nepamatuji se, že bych někde takové smluvní ustanovení viděl. Přeprava jakýchkoli paketů je úloha ISP.

Je to velmi jednoducha obrana daneho ISP pred tim, ze jeho vlastni sit nebude zneuzitelna k nekterym typum utoku.
Přičemž k jiným typům útoků ji bude možné zneužít i nadále. A když ISP udělá opatření i proti nim, pokryje tím i útoky pokrývané BCP 38. Není pak lepší udělat rovnou a jenom ta jiná opatření?

Bezpecnost je cela mozaika opatreni a BCP38 je pouze casti teto slozite mozaiky.
Občas je dobré se na tu mozaiku podívat s odstupem a zjistit, že dílek zvaný BCP38 je plně pokryt jinými dílky, a když jej z mozaiky odstraníme, vůbec nic se nestane.

Tak schvalne zkuste u O2 ci UPC reklamovat pouziti jimi nepridelene adresy ;-) Ze neuspeje a omlati vam smlouvu o hlavu je 100% jiste. O2 u nekterych sluzeb i natvrdo shazovalo navazanou PPP relaci...

Jaky jiny dilek zajisti podle Vas stejnou funkci jako implementace BCP38 v siti? A na pricetnych rychlostech - bavime se o desitkach gigabitu provozu v infrastrukture typickeho vetsiho ISP. A samozrejme ekonomicky realna reseni (tzn. takova, kdy zakaznik to take bude schopen v cene sluzby zaplatit).

Když se bavíme o desítkách gigabitů provozu, znamená to koncentraci provozu z velké sítě do jednoho místa. Takže se tam zdrojové IP adresy mohou kontrolovat nanejvýš způsobem, zda patří do rozsahů přidělených ISP. Nebo-li útočník může generovat zdrojové IP adresy z celého rozsahu ISP a ISP to bude úplně jedno.

Škodlivý provoz provoz vždy pochází z konkrétních uživatelských přípojek, takže je potřeba ho detekovat co nejblíž uživateli a tam ho také zastavit a uživatele informovat. Protože pro cíl bude stejně škodlivé, ať od vašeho ISP budou odcházet pakety z podvrženou libovolnou zdrojovou IP adresou, s podvrženou IP adresou z rozsahu daného ISP, nebo s pravou zdrojovou IP adresou. Takže jediný způsob, jak může ISP zabránit, aby se jeho síť podílela na útoku, je zastavit ten útok z jeho sítě bez ohledu na zdrojové IP adresy.

Problém je, že zákazník, který to platí, je někdo jiný, než ten, kdo je postižen útokem. Řešením je jedině zodpovědnost za provoz pocházející z dané sítě, ať už dané zákonem, nebo smluvně („zajistíme, aby na vás nikdo z naší sítě neútočil, když vy zajistíte totéž opačně“ – projekty typu FENIX). A v takovém případě samozřejmě ISP musí být schopen garantovat to, co jsem psal v předchozím odstavci – tj. žádné útoky bez ohledu na zdrojové IP adresy. (Resp. ISP asi nedokáže garantovat žádné útoky, ale musí být schopen je včas rozpoznat a eliminovat je.)

Teorie to je hezka ;-) Muzu se zeptat, u ktereho ISP jste toto v praxi nasazoval? Ono i CPE schopne v realnem case rozpoznat, co je utok nebude zrovna levne. A pak chybi ten zakaznik, co to zaplati.

FENIX nezarucuje, ze nikdo na nikoho nezaruci, prectete si pozorneji, o cem to je.

Takže je to tak,jak už jsem psal několikrát – proti chytřejším DDoS útokům, jejichž část teče z jejich sítě, se ISP nebrání. Aby předvedli, že dělají alespoň něco, a omezili alespoň ty hloupé útoky, implementují alespoň BCP38. Takže věta z článku, že by implementace BCP38 předešla tomu útoku na kořenové DNS servery, je mylná – protože takhle masivní útok na kořenové servery asi nedělal úplný nedouk, takže kdyby bylo BCP38 častěji implementováno, jednoduše by jako odchozí IP adresy použil takové, které přes BCP38 projdou.

Delaji to, co delat muzou. Problematika je vyrazne komplexnejsi a jen dokazujete, ze jste to v praxi nikdy neresil. Ve clanku se nepise, ze by BCP 38 utoku predesla. Pise se o omezeni utoku - a to je rozdil. V pripade pouziti realnych adres je samozrejme puvodce odhalitelny - podstatou spoofingu je "nebyt zjisten".

V případě použití reálných adres jsou odhalitelná zařízení, která generují příslušný tok, což je něco úplně jiného než to, kdo je původcem toho útoku. Odhalitelnost zdrojů je pro cíl útoku k ničemu, protože to stejně nemůže řešit s majiteli stovek, tisíců nebo deseti tisíců zařízení po celém světě. Pomoci by mu to mohlo nanejvýš tak, že by ten tok dokázal včas odklonit, což ale není řešení problému, nýbrž jen řešení následků. A hlavně by to vyžadovalo, aby BCP 38 implementovali úplně všichni, což je nereálné.

Odhalitelnost zdrojů útoku je důležitá pro sítě, ve kterých se ty zdroje vyskytují – aby majitel sítě mohl požadovat nápravu, a pokud k ní nedojde, příslušného klienta odpojil. A pro to, aby dohledal útočníka ve své vlastní síti, nepotřebuje ISP BCP 38.

Jasne, opet argument v rovine "vzdycky se najde nekdo, kdo na to kasle". Ne to opravdu neni duvod pro to nedelat nic na svem piskovisti.

Když to musí implementovat všichni, aby to k něčemu bylo, je „vždycky se najde někdo, kdo na to kašle“ docela pádný argument.

I kdyz to implementuje treba "jen" polovina, porad to eliminuje citelnou cast zdroje problemu. Svet neni dokonaly - ale to neni argument te nedokonalosti sam napomahat. Think globally, act locally...

Neeliminuje. I kdyby to implementovala celá polovina, útočník se tomu přizpůsobí a nebude používat útoky závislé na možnosti zfalšovat zdrojovou IP adresu. Když máte dvě díry do baráku a na jednu namontujete bezpečnostní dveře, nesnížíte tím počet krádeží na polovinu – zloději prostě budou chodit jenom tou jednou dírou, ale bude jich pořád stejně. Dokonalosti se tedy nepřiblížíte tak, že na jednu díru namontujete bezpečnostní dveře a druhou necháte otevřenou, ale tak, že na obě díry pro začátek namontujete alespoň obyčejné dveře s fabkou.

V ten moment bude utocnik o neco snadneji odhalitelny. That's point. Kdyz chcete prirovnani ke dverim, tak ano - FENIX je o bezpecnych dverich alespon z jedne strany. S moznosti ty druhe eventuelne proste zrusit (zazdit) i za cenu, ze do baraku neprojde nekdo "legitimni". Porad i to malo ma smysl.

To, že jsou útočící zařízení snadno odhalitelná, je úplně k ničemu, když takových zařízení máte tisíce po celém světě a nemáte jak přímo kontaktovat jejich majitele a už vůbec je nemůžete nijak postihnout.

Ten váš příklad s dveřmi a zazděním je přesný, a přesně ukazuje tu nesmyslnost. Když v případě potřeby umíte tu jednu díru zazdít, umíte to samé udělat i s tou druhou, kde jsou bezpečné dveře. Takže dokud je ta jedna díra otevřená, jsou ty dveře zbytečné, a když ji potřebujete zavřít, můžete totéž udělat i na straně těch dveří.

Nesmyslne je to mozna pro Vas.... :-) Pro celou radu vcelku velkych hracu na trhu to nesmyslne neni.

Again and again. RFC 1812, section 5.3.8.

K tomu jde napsat jedine. RFC ignorant :) Ale jo, vitejte v Ceske republice - mi tu vime lepe, co je a neni potreba. Jenom se divim, ze nezasedate v IETF...

Pravdepodobne pujde o ISP nezajimajici se o bezpecnost. A ti se nesoustreduji jen kolem ceskeho FENIXe, treba v AMSIXu to je Trusted Networks Initiative - a jsou i dalsi a ten napad se postupne ujima i jinde ve svete... takze se casem muze stat, ze se k velkym sitim od toho sveho ISP v nekterych situacich vubec nedostanete - kdyz treba Seznam prejde do ostrovniho rezimu a bude odbavovat provoz jen skrze FENIX (tedy se sitemi, kterym BCP38 u prdele neni) - ano, je to krajni moznost, ale stat se to v krizove situaci muze.

Google je hodne spatny priklad. Zrovna ten na bezpecnost nekasle.

S tím RFC ignorant jste to moc netrefil. To, že nesouhlasím s jedním BCP neznamená, že tak přistupuju ke všem RFC. Zvlášť když BCP 38 je v rozporu třeba s RFC 1812. Jinak BCP 38 úplně nezavrhuju – může to být rychlý fix, než ISP implementuje lepší kontrolu provozu. Akorát bych očekával, že tyhle rychlé fixy už budeme mít za sebou. Případně se dá monitoring zdrojových IP adres použít jako signál, na které uživatele se v danou chvíli zaměřit. Ale má to být jen signál, protože když útočník použije IP adresy ze správného rozsahu nebo dokonce pravé zdrojové IP adresy, nebude ten útok o nic menší. Ostatně z toho, že útočníci volí zdrojové IP adresy náhodně a ne z příslušného přiděleného bloku, ve kterém je skutečná IP adresa zombie počítače, je vidět, že se BCP 38 moc neujala.

Tak si to RFC 1812 prectete poradne, ocividne jste prestal pri cteni nekde v puli. Specielne sekci 5.3.8 tohoto RFC. A pak ten svuj blabol o rozporu RFC 2827 s textem RFC 1812 opravte. Sirite bludy...zkuste mene psat a vice (a pozorneji) cist ;-)

Právě sekci 5.3.8 jsem myslel:

If this feature is implemented, it MUST be disabled by default.

DISCUSSION: This feature can provide useful security improvements in some situations, but can erroneously discard valid packets in situations where paths are asymmetric.

Nic opravovat nebudu, protože já jsem – zřejmě na rozdíl od vás – dočetl až do konce.

Z "must be disabled by default" v sekci 5.3.8 ale nijak nevyplyva, ze to ISP nemuze zapnout - nevim, kde jste k tomu bludu dosel :D Je to ciste na uvazeni administratora konkretniho routeru. Jsou zde zminena mozna rizika, ale filtrace dle zdrojove IP adresy na vstupu je v kontextu RFC 1812, clanek 5.3.8 validni a legitimni reseni.

O BGP jste nekdy neco slysel? :-) Asi ne. Ano, to je presne ten protokol, na zaklade ktereho se ISP dozvi, koho ma kde pripojeneho a ktery je zakladnim stavebnim kamenem internetu. V soucasnem zneni RFC 4271, kdyby vas to zajimalo :-)

Jasne. A tvuj poskytovatel akceptuje skrze BGP libovolny prefix, ktery mu posles a dopredu nema paru o tom, co to bude. A ted bych poprosil jeste tu O Cervene Karkulce.
Omyl, kazdy pricetny upstream provider ma na BGP peeru k zakaznikovi nejake filtry - takze vi, co mu od jeho zakazniku muze prijit - a z toho se uz BCP38 filtry generuji pomerne snadno. A skutecne neni zadny duvod akceptovat od zakaznika pakety z jinych rozsahu nez tech, ktere jsou vzajemne ad predchozi veta domluvene. Dost casto byva tez smerovaci politika popsana ve verejne databazi - nekde je to primo podminka nutna - napr. akceptace prefixu na route-serverech v nekterych internet exchange ci ze strany nekterych upstream provideru, kteri na zaklade toho filtry generuji automatizovane. Ale jasne, ja o tom nemam paru... uz dlouho me nikdo tak nepobavil :D

Vazne - a kteryze ISP u nas na BGP od zakaznika akceptuje jakykoliv prefix? ;-) Placate nesmysly - vetsina nejake filtry ma. Internet skutecne nefunguje tak, ze si kdokoliv posle cokoliv a kamkoliv (i kdyz par pitomcu se najde, a pak z toho jsou akorat problemy). Napriklad route-servery (a nejen ty) v NIX.CZ vam rozhodne "cokoliv" akceptovat nebudou - akceptovano na Vasi relaci bude toliko to, co mate korektne registrovano v IRR databazi. A treba takovy Cogent vam akceptuje jen definovane a predem domluvene prefixy (nikoliv cokoliv, co si poslete). Vse ostatni se zahodi a je hranicnim routerem upstream providera proste ignorovane.
Ve finale jen dokazujete, ze prakticky sam netusite nic o tom, jak internet po prakticke strance funguje :D Jaky ze to spravujete autonomni system...?

Odjakziva. Pro vymenu techto informaci se na internetu pouziva smerovaci protokol BGP. A bude se muset smirit s tim, ze ISP respektujicich RFC 2827 v case bude pribyvat. To je realita ;-)

A propo - pri vhodne konfiguraci smerovace jde docilit stavu, kdy paket z jakoukoliv realne neroutovanou zdrojovou IP do site proste neprojde. Tam, kde to z HW duvodu neni mozne se casto pouzivaji bogon listy obsahujici ruzne privatni a dalsi specialni rozsahy, ktere nejsou globalne routovane (tedy nejen RFC 1918 adresy).

Pakety se zdrojovou IP 192.168.... vidam... v counteru u ACL na vstupu, ktery to natvrdo zahodi ;-)

Ano, jako ISP resim sve problemy. Treba paket prichozi v necekanem smeru (cinska zdrojova IP od zakaznika v Brne) je vcelku velky problem i pro me - coby ISP ;-) A ano, je bezne ze vim, jake adresy zakaznici pouzivaji. A nepamatuji si, ze by si nekdo stezoval, ac to nasazuji pomerne striktne.

Resit situace, kdy proste dojdou zdroje na serveru je bezpredmetne - obvykle to chcipne na aplikacni urovni, ne ze by to ucpalo linky. Muze to byt vnimano jako druh DDoS, ale ty dnes obvykle (a nejvic pali) jsou trosku o necem jinem a toci se tam provoz klidne v desitkach Gbit/sec.