Obrana proti DoS, DDoS útoku + kolik času potřebuje útočník?

Joker:
„Tj. každý požadavek by šel jakoby v nové relaci nepřihlášeného uživatele.“
Jak by tu novou relaci vytvořil?

koumal:
„Jak počítač v síti pozná, že balík má přijít na k němu a ne k druhému počítači? Podle IP adresy, ne?“
Ještě jednou, viz NAT.
Stránce přijde požadavek pod IP adresou routeru, stránka pošle routeru odpověď a router už se postará, aby odpověď došla počítači, který ten požadavek skutečně poslal.
Routery se běžně používají tam, kde je místní počítačová síť (LAN), která se v jednom bodě připojuje k Internetu (např. školy, firmy, domácnosti s více počítači, dokonce někteří poskytovatelé připojení mají všechny své klienty pod jednou IP adresou).

„Takže načíst soubor se zakázanými IP adresami. Nejjednodušší cesta jak se vyhnout načítání těch věcí o kterých píšeš.“
Nejjednodušší pro čtení, ale složitější na ohlídání zápisu a „thread-safety“- speciálně u DoS útoku, kdyby teda někdy nastal, nejspíš to bude v jednu chvíli z více IP adres současně, takže bude nutné řešit, aby si jednotlivé instance skriptu ve snaze banovat různé IP adresy ten soubor nepřepisovaly navzájem.

„Pokud to bude jen deset odkazů za jednu vteřinu. Ale pokud by si pokračoval po dobu dalších dvou vteřin“
Ne deset odkazů za sekundu, deset odkazů rychlostí jeden odkaz za sekundu, čili každou sekundu kliknu na jeden odkaz (přibližně, samozřejmě- prostě kliknu na jeden, na liště v prohlížeči mi naskočí nový list/záložka, kliknu na další, atd.) a takhle jich proklikám deset.

„Pokud tomu správně rozumím, ten server tedy identifikuje uživatele pomocí IP a masky a podle toho vytváří sessid.“
Ne. Server se o identifikaci počítače vůbec nestará. Server vygeneruje klientovi session ID. Pokud klient v požadavku předá serveru session ID (typicky přes cookie, alternativně GET/POST), server ho bere jako vlastníka té dané relace.
Když mi server založí relaci, vygeneruje session ID, já (klient) ho zahodím (třeba neumím cookies) a v dalším požadavku serveru nepošlu, server mi založí další novou relaci a pošle ID a tak pořád dokola. Což je i odpověď na „Jak by tu novou relaci vytvořil?“

Joker:
„Ještě jednou, viz NAT.“
Já jsem to už četl, ale až poté co jsem to napsal. Router vím jak pracuje, mám ho doma. Na používání masek a vytváření podsítí jsem už zapomněl (dík za připomenutí).

„ohlídání zápisu a ‚thread-safety‘“
Tak to by asi byl problém při vytváření těch souborů pojmenovaných dle IP. Tedy pokud útočník má 65 počítačů v síti, je asi hodně vysoká pravděpodobnost, že dojde k přepisu toho souboru pojmenováného dle IP.

Pokud jde o soubor s bany, tak to by byl jen pomocný soubor pro rychlé načtení. Ale jinak by mohl existovat seznam blokovaných IP v databázi. Když zjistím, že ho musím zablokovat, zapíšu to do db a provedu zápis všech blokovaných ip z db do souboru.

„prostě kliknu na jeden, na liště v prohlížeči mi naskočí nový list/záložka, kliknu na další, atd.) a takhle jich proklikám deset.“
Tak to by byla malá pravděpodobnost. Hodně malá. Musel by se třikrát za sebou trefit do 1/12 . Nebo kolikrát si nastavím ten konečný limit. Ale úvaha je to zajímavá, protože teoreticky by to nastat mohlo :-(

Joker:

> Server se o identifikaci počítače vůbec nestará. Server vygeneruje klientovi session ID. Pokud klient v požadavku předá serveru session ID (typicky přes cookie, alternativně GET/POST), server ho bere jako vlastníka té dané relace.
> Když mi server založí relaci, vygeneruje session ID, já (klient) ho zahodím (třeba neumím cookies) a v dalším požadavku serveru nepošlu, server mi založí další novou relaci a pošle ID a tak pořád dokola.
Hmm. Tak to je blbé.

Chápu, že by se tohle asi mělo rozvádět někde jinde, ale s tím sessions mi to stále není úplně jasný. Už je to dost dlouho co jsem se tímto tématem zabýval. Přece je možné dělat identifikaci uživatele přes db a nepotřebuju aby uživatel měl nastavený parametr sessid, který bych posílal na server. Tady na těchto stránkách píšu jako anonymní uživatel, v adrese url nemám sessid. Nechápu teda podle čeho ho server identifikuje. A kdybych byl přihlášený, tak sessid musí být jedinečné a nemůže se jen tak samo vytvářet každou chvíli, to by tam vznikalo spousta duplicitních položek a jak pak má server vědět, kterou má updatovat, která je aktualní sezení.

koumal:
„Tady na těchto stránkách píšu jako anonymní uživatel, v adrese url nemám sessid.“
Však taky nemůžeš editovat své příspěvky, editovat svůj profil atd. Server tě prostě nepotřebuje identifikovat.

„A kdybych byl přihlášený, tak sessid musí být jedinečné a nemůže se jen tak samo vytvářet každou chvíli“
Nemáš pravdu, session id se může měnit klidně s každým požadavkem. Důležité je, aby server věděl, že se session_id mění. (Což v praxi funguje tak, že jej mění server.)

„a nemůže se jen tak samo vytvářet každou chvíli, to by tam vznikalo spousta duplicitních položek a jak pak má server vědět, kterou má updatovat, která je aktualní sezení“
Právě podle session_id, které se předává v URL nebo v cookie. Navíc tam funguje promázávání vypršených sessions (třeba po 15 minutách neaktivity).

nightfish:
„Server tě prostě nepotřebuje identifikovat.“
Ale mě to přijde, jako kdyby mě identifikoval. Server odděluje tlustou oranžovou čarou příspěvek, který jsem psal naposled. Jak ví, že je to můj příspěvek, když tu není sessid? Já prostě stále nechápu jak to, že si mě nesplete s jiným počítačem, kdybych byl v síti. Když se přihlásím tak nevidím sessid. Když se odhlašuji, podle čeho mě identifikuje, že se odhlašuji já a ne třeba pepa z druhého počítači v síti? Podle IP mě jednoznačně identifikovat nemůže a sid mu taky neposílám, abych se potvrdil.

Reaguji na koumala:
Ohledně tohoto diskusního fóra:
1) Základem je miniBB 1.7 a ta vůbec nepoužívá session. Ani u přihlášených uživatelů.
2) Oranžová čára nad příspěvkem značí cíl kotvy (#číslo v adrese). Vyrábí ji až JS na straně prohlížeče.
3) Odešleš-li příspěvek, jsi přesměrován na adresu s kotvou.
4) Předvyplněné jméno diskutujícího, které vidíš, se bere z cookie.

Zběžně sleduji toto vlákno již od jeho vzniku a i přes ta kvanta textu pořád příliš nechápu, co přesně a proč se vlastně snažíš (znovu)vynalézt.

Chamurappi:

Chtěl jsem zkusit takovou malou obranu proti DoS útokům na úrovni aplikace. Sice jsem na něco přišel, ale nevím no, jestli to je realizovatelné. Mám teď brouka v hlavě kvůli tomu, sessid.

Našel jsem session_id() a zjistil, že to generuju z ip adresy. Pak session_start().

Joker
Ten poslední odstavec co si odtučnil jsem chtěl zvýraznit. Nejde to napsat barevně?

koumal:
„Ten poslední odstavec co si odtučnil jsem chtěl zvýraznit.“
Aha, já myslel, že to byl omyl. Udělal jsem citaci kurzívou, ještě něco mám zvýraznit?

Joker:
Teď už tam jsou dvě tlusté čáry, takže je to nepřehlédnutelné. I to je řešení... No, chtěl jsem to nějak zvýraznit, aby mi to nesplývalo s okolními příspěvky. Ty kurzíva tomu moc nepomohli.

Takže když to shrnu. Kdybych opravil tu svou funkci a nechal tam náhodné session_id() tak to sice opravím, ale budu zranitelný proti DoS útokům, protože on si může vytvořit tolik relací, kolik jen chce. Zaplaví mi session tabulku těma relacema a mám problém. Kdyby z nějaké sítě přistupovalo více uživatelů (např. učebna) - neútočníků - tak se zvyšuje pravděpodobnost, že je identifikuji jako "škodnou" a zablokuju jim IP. Dále je tu problém s tím souborem IP, do kterého zapisuji počet přístupů, které následovali za sebou. Tam je riziko přepsání.

A nakonec problém s tím, že na stránky mají chodit i boty vyhledávačů. Tady mi schází informace o tom, jak moc tito roboty stránky vytěžují - dá se nějak odhadnout počet přístupů za vteřinu?

Jdeš na to špatným směrem. Hlavním úkolem webové aplikace by mělo být to, aby případnému útoku svou dostatečnou svižností odolala. Hlavní část obrany proti DoS a DDoS útokům by měla být tam, kde je nejefektivnější - to je práce pro směrovače/firewally, operační systém a u paranoiků pro webový server.

Na běžných webových stránkách má smysl omezovat pouze činnosti, které trvají příliš dlouho a nepředpokládá se jejich časté využití nebo pokud hrozí případné zneužití služby.

koumal:
Myslim že se snažíš řešit neco bys vůbec řešit neměl. Ochrana proti DoS útokům je starost hostingu, starostí klientů by zase mělo být nevytěžovat server nesmyslnými ochranami. Správce hostingu má daleko účinější nástroje - iptables (firewall) a hosts.deny. První zajistí že se spojení s útočníkem ani otevře a to druhé, že je zavřeno dřív, než se výrazněji zatíží server (pokud to daná serverová aplikace podporuje).
Proti DDoS útokům není spolehlivá žádná ochrana. Třeba červ CodeRed DDoS útokem složil servery Bílého domu (jeden z mnoha cílů) a myslím že tamní admini už nějaké zkušenosti s (D)DoS útoky mají.

Tvoje aplikace se zdá být dobrý terč pro složení webserveru zároveň s SQL serverem.

Davex:
„Jdeš na to špatným směrem. Hlavním úkolem webové aplikace by mělo být to, aby případnému útoku svou dostatečnou svižností odolala.“
Svižnost aplikace. Vždycky jsem si myslel, že udělat sessions přes databázi je nejlepší řešení. Zajímalo by mě tedy vaše definitivní stanovisko k této problematice - odsuzujete to jako nebezpečné nebo ne? Dalo by se říct, že zrovna toto řešení nepatří mezi ty svižné? Ba k rizikovým? Proč jsem chtěl používat sessions tabulku. Důvod je ten, že abych nemusel načítat informace z profilu uživatele a prohledávat kvantum registrovaných uživatelů, bylo by jednodušší to uložit přímo do sessions. Když vezmu v úvahu, že v jednom čase mi přijde na stránky maximálně deset lidí, tak je lepší procházet tabulku sessions, která má dejme tomu 20-40 záznamů, než procházet tabulku users. Jenže ta zranitelnost proti DoS tu je. Jak jinak zabránit aby si někdo neměnil sessid 100x za vteřinu? Jedině tím, že dokážu rozpoznat, že z nějaké IP přišlo 100 přístupů a vteřinu. A můžete říct, že nejjednodušší by bylo použít cookies, ale tam nemohu ukládat informace, které by uživatel mohl měnit.

koumal:
„Vždycky jsem si myslel, že udělat sessions přes databázi je nejlepší řešení.“
Teď se tu myslím motáme ve více věcech.
Databázová „session“ tabulka se nepoužívá kvůli rychlosti, ale kvůli bezpečnosti, jako obrana proti tzv. session stealing.
O čem mluví Davex a ostatně snad i všichni ostatní diskutující, je ochrana proti DoS útoku na úrovni webové aplikace- že bude tu aplikaci zbytečně zpomalovat.

„Proč jsem chtěl používat sessions tabulku. Důvod je ten, že abych nemusel načítat informace z profilu uživatele a prohledávat kvantum registrovaných uživatelů“
To je přece zbytečné, přesně k tomu je ta session, aby se do ní takové informace ukládaly. Než si při přihlášení údaje přesypat v databázi do jiné tabulky a pak je číst odtamtud, to je lepší si je rovnou uložit do session.

„Jenže ta zranitelnost proti DoS tu je.“
Co se tu snad všichni snaží říct je, že řešit tohle v aplikaci je moc pozdě. Když už řešit ochranu proti DoS útoku, měla by zajistit, že se ten útok k aplikaci vůbec nedostane.

Joker:
„To je přece zbytečné, přesně k tomu je ta session, aby se do ní takové informace ukládaly. Než si při přihlášení údaje přesypat v databázi do jiné tabulky a pak je číst odtamtud, to je lepší si je rovnou uložit do session.“
Tak rozumíme, si. Přesně to jsem se od počátku snažil.

Já vím, že to tu už ze všech stran zaznělo. Takže mi prostě nezbývá než doufat, že ochrana poskytovatele je/bude dostatečně spolehlivá. A pokud k útoku dojde, tak se to bude řešit až pak. Případný pokus o kterém jsem psal, že bych zkusil vytvořit to ověřování, to by ale mohla být ta poslední pojistka, kdyby HW řešení serveru selhalo. Ale budiž, říkáte, že to nemá smysl, že když už by nějaký borec prolomil ochranu routeru, tak by mohl snadno shodit i to řešení na straně aplikace. OK. Jsem ale rád, že jste mě tu upozornili na tu chybu, generování sessid před IP. Tu věc opravím.

Poslední příspěvek - oprava: generování sessid z IP adresy

koumal:
„Takže mi prostě nezbývá než doufat, že ochrana poskytovatele je/bude dostatečně spolehlivá.“
Slušný webhoster servery nepřetržitě monitoruje a pokud by některý web způsobil přetížení serveru, tak ho jednoduše vypnou. Při DDoS útoku se zpravidla zahltí datová linka, kterou je server připojený a řeší se to různými sofistikovanými metodami na úrovni ISP. Pochybuji, že někdo povede DDoS útok na tvůj globálně bezvýznamný web, protože je k tomu potřeba vynaložit určité nadstandardní úsilí.