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

Zdravím Vás,
snažím se vymyslet nějaký způsob jak se alespoň částečně bránit proti takovým útokům, které mají za cíl přetížit systém a způsobit zhroucení. Napadlo mě sledovat u některých akcí výkon, respektive, já tomu říkám trafik. Dejme tomu, že mám v databázi tabulku session s IP adresama aktivních uživatelů, tam si zapisuji datum poslední aktivity (+/- 5 minut) + informaci "trafik". Ještě to nemám úplně domyšlené, ale mělo by to být číslo vyjadřující průměr vytížení. Předpokládám, že 100 by byla hraniční hodnota. Je tu ale ještě druhý faktor a to chci vysvětlit.

Předpokládejme, že jde o redakční systém například něco podobného jako aktualne.cz nebo njaká diskuse jako na root.cz .

mám několik typů akce jako insert (vkládání článku nebo komentáře), update (editace u přihlášeného uživatele), list (výpis diskusí nebo komentářů), open (otevření článku).

Nejdříve bych vyhodnotil o jak závažnou činnost jde, jak moc je vytěžující. V procentech řekněme:

insert (80), update (70), list (95), open (70).

Udělám si funkci, která mi bude kontrolovat trafik tak často, jak náročná je ta operace. Tzn. list (90) - když uživatel provede pokud o načtení výpisu, zkontroluji jaký byl jeho předchozí trafik. Zkusím vypočítat průměr nebo to nějak ještě matematicky ošetřím. Ve výsledku pokud zjistím, že během 10 vteřin se pokusil tuto operaci provést asi 10x, tak ho zastavím. Vše to jsou jen odhadované čísla a vycházel bych jen z toho průměru.

Pro mě je důležitá otázka an kterou neznám odpověď:

Kolik času potřebuje jeden nebo více útočníků na to, aby zhroutili server. Předpokládejme, že online je 200 uživatelů a bavíme se teď o root.cz nebo podobných stránkách s diskusemi.

Brute Force - tak to by byla maličkost.
Dos a DDos - takže pro mě nemá smysl se tím zabývat? Mám spoléhat na poskytovatele? Ale co když třeba někdo přijde a spustí nějakého bota. To ten router umí sám rozpoznat a odříznout? Je to na 100% spolehlivé? Fakt nemá smysl se tím po stránce aplikace zabývat? Protože já jsem se už těšil jak to bude řešit...

DoubleThink:
No ale přesto - by se jednalo několik stovek požadavků za sekundu, pak by mi stačilo vypočítat limit např. 20 požadavků za sekundu. Problém je ale že nevím co se myslí těma požadavkama. Jestli by se počítal pouze požadavek na soubor php (?) tak v pohodě. Ale jestli tam je požadavek i na .css a .js a obrazové soubory, pak bych to musel zvýšit.

No možná je to zbytečné, ale zas tak moc asi ne. Na jedněch nejmenovanych strankach ktere jsou umistene na pipni.cz ted meli problemy s tim DoS (a možná ještě maj). Takže ten firewall jim tam asi nefunguje. Možná je to o tom vybrat lepšího poskytovatele, nevím.

No ale právě proto jsou zranitelné

Mě to přišla jako dobrá myšlenka udělat funkci, která se bude aktivovat pokud zaznamenám, že uživatel podezřele vytěžuje systém. Je možnost ho varovat nebo rovnou odříznout. Mohl by jsi mi odpovědět na tu otázku ohledně požadavků na server? Znamená to pouze požadavky na zpracování php souboru (nebo jiných scriptů pro server) nebo se tam počítají i požadavky na obdržení těch obrázků, videjí, stylesheetů atd.?

Pravda, na to jsem nemyslel. Když musím ukládat každý přístup kvůli sčítání, asi by to zpomalilo. Původní myšlenka byla nastavit limit na devět přístupů za vteřinu během přihlašování. Dvacet čtyři přístupů během pokusu o otevření diskuse a devět přístupů při pokusu o výpis diskusí. Možná by se to dalo spasit tím, že bych pro tyto případy prováděl kontrolu jen v časově omezeném limitu. Pro první případ by mohlo platit, že pokud je aktuální čas v rozsahu x.00-x.022 pak by se spustila akce db_select/db_update. Tím pádem bych pracoval s tabulkou jenom pokud by opravdu významně stoupla zátěž. Jen si teď nejsem jistý, zda je možné do db uložit hodnotu času s přesností na setiny. Ale snad jo. Běžný uživatel se pokouší o přihlášení maximálně tak 1x-3x za vteřinu. U otevírání diskusí bych ten rozsah číslo nastavil například na dvanáctinu vteřiny. Sotva kdy člověk udělá dvanáct požadavků na otevření za vteřinu. Od počátku jsem myslel na to, že by se neměla kontrolovat úplně každá akce, ale jen ty, které by mohli významně omezit výkon. Cílem není sledovat výkon jako takový, ale sledovat ho, jen pokud má dojít k podezřelému vytížení klientem. Tak co ještě myslíte, že je to blbý nápad?

A s tím přetížením, se asi pletete. Stovky procent asi ne. Vždyď vždycky když uživatel provede jakoukoliv akci, kontroluji zda je přihlášen nebo ne a tak do té tabulky přistupuju tak či tak. Akorád update k potvrzení přihlášení provádím co pět minut.

Joker:
No, jo jenže mě ta myšlenka nedá klidu.

„Když se při akci uživatele nejdřív spustí kód kontrolující zda se kód monitorující počet akcí neprovádí příliš často, pak se spustí kód monitorující počet akcí a potom samotná akce,“
Myslím, že zas tak složité by to nemělo být. Když spouštíš jakýkoliv php script tak se v něm provádí hodně výpočtů, takže jeden výpočet ho už nezabije. Ale ráno jsem tu uvedl něco co prakticky znamená změnit přístup. Počítat to tak jak jsem to počítal nemá smysl. Protože pokud si řeknu, že budu spouštět monitoring jenom při při 1/12 sekundy, pak nemohu počítat ty ostatní přístupy. Spíš bych tu myšlenku mohl založit na předpokladu, že jestliže někdo vytěžuje opravdu výrazně, pak zcela určitě bude onen interval vteřiny naplněn nějakým přístupem pravidelně. Tedy když budu monitorovat jen během zlomku vteřiny při každém jednom spouštění scriptu, pak nehraje roli množství přístupů za vteřinu ale to, jestli tento zlomek je při každém přístupu naplněn. A je li naplněn třikrát za sebou, už bych mohl říct že mám jistotu že se jedná o podezřelé chování (záleží ale na velikosti zlomku).

Jediný problém, který jsem dnes ráno ještě řešil, byl jak ukládat tu hodnotu, aniž by to server citelně poznal. Napadlo mě vytvořit dočasný soubor na ftp serveru. Dal bych mu název podle IP adresy. Soubor se vytvoří pokud je splněna podmínka přístupu v okamžiku 1/12 s. Pokud by během následující vteřiny byl volaný podruhé za sebou, tak do něj provedu zápis s časem. Když ne, tak ho vymažu. Znamenalo by to tedy vždy provést kontrolu zda existuje onen soubor. Tento úkon mi nepřijde nějak dramaticky náročný. Podobný postup jsem dříve používal na svých prvních stránkách, které ještě nepoužívali db a měl jsem tímto způsobem udělaný monitoring návštěvnosti u jednotlivých diskusí. Stránky fungovali úplně normálně, i když návštěvnost taky nebyla větší než pět až deset uživatelů za den, ale zase to bylo na WZ.

Mě osobně tento útok právě teď netrpí, ale vypadá to že někoho jiného ano, tak vymýšlím nějakou prevenci. Já nemám přístup k logům, ty má poskytovatel. Asi zkusím to co jsem popsal ve svém posledním příspěvku. Za zkoušku člověk nic nedá.

Joker:
Mno, aby to nějak fungovalo, musí skript alespoň:
1. Předpokládám načíst nějaké obecné konfigurační údaje
2. Připojit se k databázi

Tak tohle dělám vždy i bez ochrany proti DoS.

3. Zjistit, jestli IP není blokovaná- jelikož seznam blokovaných by bylo potřeba aktualizovat dynamicky, nejspíš taky SELECT do databáze

To taky považuji za standardní krok. Jsou zde dvě řešení: a) přes databázi b) přes soubor uložený na ftp serveru. Až doposud jsem na menších webovkách používal to b. Teď ale budu dělat větší projekt, kde bych využil db.

K tomu ale musím upřesnit následující. Co se týče selectu. Tak ten se provádí v podstatě provádí jenom z tabulky se sessions. To jsem už psal, že celé stránky při každé operaci zkoumají tabulku session. Najdu sessid a načtu informace o klientovi. Takže žádné hledání navíc. Je jen jedna tabulka, která se musí načíst poprvé a to v době, kdy buď záznam v tabulce sessions neexistuje nebo záznam ukazuje na nepřihlášeného uživatele.

4. Tady může bloknout někoho, kdo už má ban
5. Vytáhnout z databáze počet přístupů z dané IP za časový interval - SELECT
Ne to už jsem ptal, že tuto metodu používat nebudu (to by bylo to nesmyslné přetěžování jak mě varoval DoubleThink). Jediné co musím pokud se zrovna trefí do té 1/12 musím zkontrolovat zda existuje soubor. Pokud existuje musím načíst datum uložení souboru, porovnat čas a podle toho buď smazat nebo editovat. Editace připadá v úvahu jen že by se uživatel během dvou vteřin trefil do toho stejného intervalu 1/12. Jak malá je to pravděpodobnost? Takže pokud se trefí edituju - zkontroluju počet přístupů a buď ho banuju nebo navýším počet ++n.

6. Ověřit, že z dané IP nepřišlo nadměrné množství dotazů - tady může skončit v případě DoS útoku
Tuhle činnost provádí pouze pokud byl přástup dvakrát za sebou v intervalu 1/12 . Ten interval to není nic co by bylo někde uloženo, je to pevně nastavená časová délka ve scriptu.
7. Vložit do databáze nový přístup z dané IP - INSERT
taky ne

Pokud už bych to měl počítat o kolik operací by výkon narostl, tak bych to nepočítal od 'select from sessions', protože tuto akci provádí tak či tak. Spíše tam hraje roli kolik je uživatelů on-line. Zatím na staré stránky, moc lidí nechodí, ale s tím novým systémem snad bude návštěvnost větší. Já bych to ale víc jak na 12 lidí v jednom čase neviděl. Ale i kdyby to bylo 4x12 lidí on-line, tak by se nic nedělo. Pokud mluvíme o lidech pak se návštěvník musí trefit do intervalu zlomku dvanáctiny vteřiny (který je předem nastaven). A pravděpodobnost nutnosti ověřovat existenci souboru + zjistit datum vytvoření/editace souboru se rovná 4 kontroly za vteřinu (nebo za větší časový rozsah). Záleží jak často by uživatel přecházel mezi odkazama).

Navíc někteří uživatele z oněch 12 nebo 4x12ti, budou mít trvalé účty a budou mít status osoby, které lze důvěřovat a není nutné u ní provádět kontrolu. Např. admin, redaktoři a správci diskusí a jiní ověření uživatelé, budou moci získat status "Důvěryhodný". Tím odpadne část uživatelů, které by bylo nutné ověřovat.