Clanek nekolikrat zminuje zmenu IP odesilatele. Mam dojem, ze dnes (alspon v CR) uz vetsina provideru nepropusti paket se zfalsovanou adresou odesilatele. Mate podobne zkusenosti?
To by slo, pokud by byla sit dusledne stromova. Pak by kazdy uzel vedel, z jakych IP muze odkud co priteci. U provideru obycejnych pripojeni to vetsinou jde. Pokud ale utocnik sedi na nejake kruznici, pres kterou mohou data tect tam i zpatky podle okolnosti (stavu jinych casti site), tak uz muze falsovat, jak chce.
vyrvat kabel ;) - proti zaplavovym utokum se blbe chrani, aby to alespon trochu slo, musely by mit prichazejici data nejakou spolecnou vlastnost ruznou od legitimniho provozu.
to rozhodne je. velice pekne a jednoduse podano. pritom velmi presne. pozoruhodna kombinace.
pouze by tu melo jeste zaznit: ethereal je v zasade mrtev (jako nazev programu si jej privlastnila jakasi spolecnost ke komercnim ucelum). z posledni volne verze vznikl fork jmenem Wireshark blizici se k verzi 1.0.
Velci ISP provajderi, maji urcite techniky jak branit zaplavovym utokum. Ovsem jedna se o veci do kterych uplne nevidim a nemam s nimi takove zkusenosti abych o nich mohl psat.
Ohledne clanku o obrane Vas musim zklamat, jelikoz zadne nebudou (viz. duvod prvni odstavec).
Na druhou stranu snad Vas potesim tim, ze o jednom DoS utoku vyjde do mesice clanek. Jedna se o FTP bounce-scanning (scanning protoze se tento utok pouziva primarne ke skenovani portu).
Na Cisco Routerech existuje prikaz: >> ip verify unicast reverse-path <<. Pokud je prikaz zapnuty na interface, kontroluje podle routovaci tabulky, zda paket s touhle zdrojovou adresou muze prijit zkrz tento interface. Ale jestli to maji vsude zapnute ...
Nejlepsi obrana proti probihajicimu utoku je skutecne vytahnout kabel.. "najdi to co nevic blika a to vytrhni"
Prevence spociva v zatrhnuti tech nejhorsich zesilovacu, napriklad si zkuste zadat rekurzivni dotaz nejakemu cizimu nameserveru. Donedavna to slo, dneska uz vas s tim vsude vyhodi (nebo by aspon meli).
Toto je samozrejme nesmysl, flooding spociva v zahlceni linky, a tomu vy nemuzete jako uzivatel predejit. I kdyz nastavite iptables, tak bude vase linka zahlcena. Jedina obrana je u poskytovatele pripojeni. On musi tyto data zahazovat aby nesla linkou k vam. Takove technologie jiz nini jsou, ale tato problematika je dosti slozita.
nesmysl to v zadnem pripade neni, pokud bych byl ISP tak si timto zpusobem IPTABLES nastavim a je po floodingu, tato problematika je dosti jednoducha. Viz root.cz kde je detailne probirana konfigurace IPTABLES
Jenomze ty ISP nejsi a neni to tak jednoduchy. Floodovani neni jenom pomoci ICMP ale muzes posialt i TCP nebo UDP, a ISP ma na svi siti takovej fofr ze nema moznosti sledovat jestli jsou ty TCP pakety regulerni. A kdyz by mel tak tu je potom UDP u kteryho nema moznost posouzeni.
Tak te muzu floodovat pomoci UDP :-D. Jinak ja ti porad rikam ze pomoci filtrovani se tomu samozrejme brani ale musi te branit nekdo pred tebou, aby ty data nesli do ty pomali lajny jakou jsi pripojenej k netu. Kdyz si to budes filtrovat az sam , tak uz je pozde.
Ochrana proti temer libovolnemu floodingu spociva ve vhodnem nastaveni iptables, dela se to pomoci limitu.
Napriklad si nastavim, ze mi mohou dorazit maximalne 3 icmp echo-reply packety za sekundu a ze zbytek se bude dropovat, bez zpetne odpovedi, ktera se standardne zasila a upozornuje server o nedoruceni. Tim umoznim korektni cinnost i v pripade, ze nekdo zacne floodovat z ruznych IP adres. Neni to samozrejme 100%ni, ale o nicem lepsim jsem zatim nezaslechl.
Takze vychozi politika IPTABLES bude DROP, co neni povolene, to je zakazane + limity na nejcasteji zneuzivane typy packetu, to je absolutni zaklad zabezpeceni serveru.
1. Nikde jsem nenapsal, ze flooding je pouze o ICMP, samozrejme ze neni !
2. Hned v prvnim komentari jsem napsal, ze ochrana pred floodingem neni 100%ni, kazdopadne kontrolovat regulernost TCP packetu do urcite miry lze a to pomoci kernelu.
3. zcela jiste vim, ze to, co jsem vyse napsal je pravdive, vyzkousene a v praxi pouzivane. Snazis se mi to vsak za kazdou cenu vyvratit, abys zde vypadal jako nejaky "master".
Mel by sis priznat, ze nevis vsechno, shodou nahod jsem si zrovna o ochrane pred DoS a floodingem nedavno precetl mnoho desitek stranek, jednak na hysteria.sk/prielom a druhak google.com -> linux kernel extensions
1. Nikde jsem nenapsal, ze flooding je pouze o ICMP, samozrejme ze neni !
2. Hned v prvnim komentari jsem napsal, ze ochrana pred floodingem neni 100%ni, kazdopadne kontrolovat regulernost TCP packetu do urcite miry lze a to pomoci kernelu.
3. zcela jiste vim, ze to, co jsem vyse napsal je pravdive, vyzkousene a v praxi pouzivane. Snazis se mi to vsak za kazdou cenu vyvratit, abys zde vypadal jako nejaky "master".
Mel by sis priznat, ze nevis vsechno, shodou nahod jsem si zrovna o ochrane pred DoS a floodingem nedavno precetl mnoho desitek stranek, jednak na hysteria.sk/prielom a druhak google.com -> linux kernel extensions