« 1 2 »
Autor Zpráva
Koumal
Profil *
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.
tiso
Profil
Koumal:
DoS = jeden user pošle v skripte niekoľko stoviek requestov/sekundu na server, až kým ten prestane stíhať odpovedať a spadne.
DDoS = to isté, ale útočí nie jeden user ale sieť počítačov, ktorú ten user ovláda.
Týmto útokom musíš zabrániť o úroveň vyššie (firewall, router, ...)
Druhá vec sú Brute Force útoky na lámanie hesiel či sťahovanie nejakého obsahu (obrázky userov s id 1-1000), tomu sa dá zabrániť na úrovni aplikácie (PHP, MySQL), s tým, že napríklad nastavíš limit na počet akcií jedného usera, alebo timeout pre ďalšiu rovnakú akciu s danej IP adresy (prípadne použiješ inú identifikáciu).
Koumal
Profil *
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
Profil *
tiso:
DoS = jeden user pošle v skripte niekoľko stoviek requestov/sekundu na server, až kým ten prestane stíhať odpovedať a spadne.
To není úplně správná definice. Denial of Service znamená, že zvolím požadavek, který je pro server výpočetně náročný. Těchto požadavků odešlu tolik, aby nebyl server schopen vykonávat své běžné služby (service) a začal z důvodu svého vytížení odmítat běžné klienty (denial).
Uvažovat DoS na úrovni skriptu má význam u náročných operací. Například nepovolím vygenerování nesmyslně velkého obrazového pozadí.

Koumal:
Pokud neděláš burzovní server, pravděpodobně ztrácíš čas nad pitomostmi.
Koumal
Profil *
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.
DoubleThink
Profil *
Koumal:
No možná je to zbytečné, ale zas tak moc asi ne.
Je to zbytečné. Ochranu proti DoS běžné servery nepoužívají žádnou. Vůbec žádnou.
Koumal
Profil *
No ale právě proto jsou zranitelné
DoubleThink
Profil *
Ty jsi taky zranitelný. Ale nikdo tě dneska na ulici nezastřelil.
Koumal
Profil *
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.?
tiso
Profil
DoubleThink: vďaka za upresnenie.
koumal
Profil *
Tak už to mám celé vymyšlené. Vypočítal jsem to tak, že když někdo bude volat např. funkci pro výpis diskusí, tak se bude přičítat určitá hodnota. Když ta hodnota přesáhne strop, dostane varování nebo ban. Aby to nebylo tak jednoduché, tak si zapíšu kdy naposled se dožadoval tohoto úkonu. Ještě než provedu zápis hodnoty do tabulky, tak to vydělím uplynulou dobou [s]. Výsledek je tedy zátěž na sekundu. Mohu sečíst traffic všech aktivních návštěvníků a zjistit jejich celkový aktuální výkon. Možná to vypadá složitě, ale fakticky je to jednodušší než udělat samotné přihlašování/odhlašování.
DoubleThink
Profil *
Brilantní. Kontrola zátěže ji samu zvýší o stovky procent.
Koumal
Profil *
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?
Koumal
Profil *
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
Profil
koumal:
Si tak říkám, že ještě chvíli a nebude žádný DoS útok ani potřeba. 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, třeba na odstavení serveru bude stačit běžná aktivita uživatelů :-)

Souhlasím s DoubleThinkem, dělat takovéhle monitorování asi nemá cenu. Možná u akcí trvajících výrazně déle než ty ostatní omezit jejich použití na nějaký časový limit (třeba to bývá u vyhledávání, například jedno hledání za 30 sekund), ale na úrovni milisekund bych to ve skriptu nesledoval.

Hlavně u většiny projektů to nemá smysl z toho důvodu, že pravděpodobnost DoS útoku bude minimální a potenciální škoda nebude taková, aby to ospravedlnilo ta opatření proti němu.
Když už by to u nějakého projektu bylo nutné řešit, asi bych to řešil už na úrovni webového serveru, ne ve skriptu.
Mastodont
Profil
asi bych to řešil už na úrovni webového serveru
Přesně tak, je blbost to řešit na úrovni aplikace.
Koumal
Profil *
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.
Alphard
Profil
Koumal:
A máte teď s tímto útokem problémy, nebo jen moc času a nevíte, co s ním? :-)
Měl byste mít k dispozici log přístupů, myslím, že je i na této diskusi (nebo byl když se řešila zátěž od indexovacích robotů). Zapisují se do něj http požadavky, IP adresy apod. Vše se ukládá do souboru, takže je to docela rychlé. V případě problému se zpětně kouknete do logu a provedete preventivní opatření.
Koumal
Profil *
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
Profil
Koumal:
Myslím, že zas tak složité by to nemělo být.
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
3. Zjistit, jestli IP není blokovaná- jelikož seznam blokovaných by bylo potřeba aktualizovat dynamicky, nejspíš taky SELECT do databáze
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
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
7. Vložit do databáze nový přístup z dané IP - INSERT

Všechny tyhle kroky bude nutné dělat při každém přístupu na stránky, čili to je 2x SELECT a 1x INSERT navíc pro každou zobrazenou stránku.

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ě.
Nějak nechápu cíl tohohle přístupu. Podle mě když už, tak smysluplný přístup by byl si logovat každý přístup a blokovat ty, kdo za časový interval jich mají příliš.

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.
Už jsem to psal o pár příspěvků dřív:
Si tak říkám, že ještě chvíli a nebude žádný DoS útok ani potřeba.“ :-)
Chápu tohle řešení správně, že kdyby na stránkách bylo současně 60 „legitimních“ diskutujících a každý načetl v průměru jednu stránku za půl minuty, udělá server za minutu v průměru 480 souborových operací (120x vytvoření souboru, 120x kontrola existence souboru, 120x ověření času souboru a 120x smazání souboru)?
Koumal
Profil *
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.
Joker
Profil
Koumal:
Tak tohle dělám vždy i bez ochrany proti DoS.
bych to nepočítal od 'select from sessions', protože tuto akci provádí tak či tak.
Jasně, právěže se ty operace dělají tak jako tak- k čemu ale je ochrana proti DoS útoku, pokud se před vyblokováním útočníka stejně zpracuje podstatná část stránky?
Útočníkovi je celkem jedno, jestli server padne na neustálém zobrazování stránek nebo na neustálém vyhodnocování oprávněnosti požadavků.
Proto mi taky jako jediné smysluplné řešení přijde v případě zjištění útoku ty požadavky zahazovat už během přijetí na webovém serveru, tj. ještě předtím, než se dostanou k nějakému skriptu.

Najdu sessid a načtu informace o klientovi.
Kdybych dělal DoS útok, asi bych se neobtěžoval s tím, aby se ten skript přihlašoval nebo posílal cookies. Tj. každý požadavek by šel jakoby v nové relaci nepřihlášeného uživatele.
Což by ještě pomohlo tomu útoku, protože už session_start na začátku skriptu by generovalo tuny session ID a „session souborů“.

Editace připadá v úvahu jen že by se uživatel během dvou vteřin trefil do toho stejného intervalu 1/12.
Takže uživatel, který by si otevřel seznam vláken, pročetl si je, našel třeba 10 zajímavých a proklikal si je prostředním tlačítkem (otevřít do nové záložky/listu) by měl docela slušnou šanci na ban :-)
koumal
Profil *
Joker:
Jasně, právěže se ty operace dělají tak jako tak- k čemu ale je ochrana proti DoS útoku, pokud se před vyblokováním útočníka stejně zpracuje podstatná část stránky?

Teď ti nějak nerozumím. Zjednodušeně řečeno struktura příkazů by byla asi taková:
session(); ct(12) && list(15);

pozn. sesssion - funkce pracující se sessions; ct (max. přístupů) - control traffic fnc; list(počet záznamů).

Zcela jistě se vždy provede funkce session(). Tam je buď zavedení session, update nebo zrušení, kontrola povolení přístupu. Možná bych tu informaci o banu přidal do tabulky sessions. Pak následuje ct(12), tady může být uživatel zablokován a dál se nedostane.

Což by ještě pomohlo tomu útoku, protože už session_start na začátku skriptu by generovalo tuny session ID a ‚session souborů‘.
Tak tomu taky moc nerozumím. Používám session_start ale jak by se mohly ty tuny sessid vygenerovat? Navíc myslím, že před zápisem do sessions tabulky kontroluji zda tam už není sessid se stejnou IP. Tohle jsem řešil, když jsem vytvářel přihlašování, aby se nevytvářeli vícenásobné sessid při stejné ip adrese. Session soubory - co tím myslíš? Používám jen tabulku.

Jak bys to udělal, aby server padl na "neustálém vyhodnocování oprávněnosti požadavků". Vždyď pokud začne útočit tím stylem, že použije 12 přístupů za vteřinu, tak je za dvě nebo tři vteřiny zablokovaný a už nemůže nic dělat. Za tu dobu se pouze třikrát provádí test existence souboru s IP a jeho načtení. To mi nepřijde náročné. Pořád nechápu kde vidíš to vytěžování před tím než rozpoznám, že jde o útočníka.

„Editace připadá v úvahu jen že by se uživatel během dvou vteřin trefil do toho stejného intervalu 1/12.“
Takže uživatel, který by si otevřel seznam vláken, pročetl si je, našel třeba 10 zajímavých a proklikal si je prostředním tlačítkem (otevřít do nové záložky/listu) by měl docela slušnou šanci na ban :-)
Tak jsem to neřekl dost jasně. Tak znovu:
„Editace připadá v úvahu jen že by se uživatel během dvou vteřin OPAKOVANĚ trefil do toho stejného intervalu 1/12.“
nightfish
Profil
koumal:
Navíc myslím, že před zápisem do sessions tabulky kontroluji zda tam už není sessid se stejnou IP. Tohle jsem řešil, když jsem vytvářel přihlašování, aby se nevytvářeli vícenásobné sessid při stejné ip adrese.
Takže když se k tobě připojí dva různí uživatelé se stejnou IP adresou, tak sdílí jednu session (přihlášení, oprávnění atd.)?

Session soubory - co tím myslíš?
PHP si ukládá obsah session v souborech (např. v /tmp/sess_cvverjjfa52jtao8v7hs4cbnf3) - pro každou session jeden soubor

Vždyď pokud začne útočit tím stylem, že použije 12 přístupů za vteřinu, tak je za dvě nebo tři vteřiny zablokovaný a už nemůže nic dělat
Pokud budeš schopen poznat, že jde o jednoho útočníka. Chytrý útočník použije proxy servery, takže se ti to bude jevit jako víc útočníků. (A každý bude mít 12 přístupů za sekundu).
koumal
Profil *
nightfish:
Takže když se k tobě připojí dva různí uživatelé se stejnou IP adresou, tak sdílí jednu session (přihlášení, oprávnění atd.)?
Tohle jsem nezkoušel. Budu to muset vyzkoušet. Předpokládal jsem, že každý počítač má vlastní IP. S těmi soubory jsem se u sebe na localhostu nesetkal. Těmi proxy servery myslíš, to že uživatel změní pokaždé svou IP? Nebo, že může útočit z několika IP adres najednou?
Joker
Profil
koumal:
Teď ti nějak nerozumím.
Říkal jsem, že v případě DoS útoku to nestačí jenom zjistit- je potřeba požadavky zahodit ve chvíli, kdy se ještě ušetří drtivá většina zpracování stránky.
Když se mi povede požadavek zahodit, ale stejně to bude stát třeba 50% času oproti prostému zobrazení stránky bez kontrol, nemá to moc smysl.

Navíc myslím, že před zápisem do sessions tabulky kontroluji zda tam už není sessid se stejnou IP.
Čili je dovolena jen jedna relace na jednu IP adresu? A když se připojí více lidí ze stejné IP, stane se co?

je za dvě nebo tři vteřiny zablokovaný a už nemůže nic dělat
A co znamená, že je zablokovaný?
Že zpracování požadavku bude vypadat asi takhle: Inicializuje session, načte se společná konfigurace, připojí se k databázi, zkontroluje, jestli IP není blokovaná, zjistí se že je, případně se ještě udělá nějaké logování o zablokovaném požadavku a zpracování skončí.
Tohle taky bude mít nenulovou náročnost a při dostatečném počtu požadavků může server slušně zaměstnat.

Tak jsem to neřekl dost jasně. Tak znovu:
„Editace připadá v úvahu jen že by se uživatel během dvou vteřin OPAKOVANĚ trefil do toho stejného intervalu 1/12.“
Ne, je to dost jasné: Když na webu proklikám 10 odkazů rychlostí jeden odkaz zhruba za sekundu, jaká je pravděpodobnost, že mě to zablokuje? :-)
Podle mě to, že uživatel během 3 sekund udělá 3 monitorované akce není tak nemožné, jak se zdá.
A krom toho je myslím jen otázka času, kdy by se do seznamu blokovaných dostala většina vyhledávacích robotů.
Joker
Profil
koumal:
Předpokládal jsem, že každý počítač má vlastní IP.
Viz NAT

Nebo, že může útočit z několika IP adres najednou?
Třeba DDoS je už z principu vedený z mnoha různých IP adres.
nightfish
Profil
koumal:
Předpokládal jsem, že každý počítač má vlastní IP.
Není tomu tak.

S těmi soubory jsem se u sebe na localhostu nesetkal.
Podívej se do php.ini na nastavení session.save_path.

Těmi proxy servery myslíš, to že uživatel změní pokaždé svou IP?
Proxy server zprostředkovává spojení mezi uživatelem a tvojí stránkou s tím, že pro tebe to vypadá, jako by požadavek nevytvořil ten uživatel, nýbrž proxy server. Pokud bude používat pořád stejný proxy server, budou to pro tebe požadavky z jedné IP adresy (proxy serveru).

Nebo, že může útočit z několika IP adres najednou?
Pokud použije více proxy serverů zároveň, může útočit "z několika IP adres" najednou.
koumal
Profil *
Joker:
Říkal jsem, že v případě DoS útoku to nestačí jenom zjistit- je potřeba požadavky zahodit ve chvíli, kdy se ještě ušetří drtivá většina zpracování stránky.
Jo tak. Myslíš zastavit zpracování kódu/scriptu. No, ano samozřejmě :-) Ale vážně si myyslím, že to zjištění je prosté.

Čili je dovolena jen jedna relace na jednu IP adresu?

Myslím že jo. Já jsem s těma stránkama už nějakou dobu nedělal, tak až se zas do toho pustím tak to ověřím.

To budu muset ověřit co se stane, když se připojí více lidí z jedné adresy. Trochu jste mě zaskočili. 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?

A co znamená, že je zablokovaný?
Banovaný. Uživatel by existoval v souboru na ftp. 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š.

Ne, je to dost jasné: Když na webu proklikám 10 odkazů rychlostí jeden odkaz zhruba za sekundu, jaká je pravděpodobnost, že mě to zablokuje? :-)
Žádná. Pokud to bude jen deset odkazů za jednu vteřinu. Ale pokud by si pokračoval po dobu dalších dvou vteřin.... máš problém. Ale ty stihneš naklikat deset odkazů za jednu vteřinu??? :-D

Ti vyhledávací roboti posílají své požadavky tak rychle? Tak to by byl problém.
koumal
Profil *
nightfish:
session.save_path
OK tak jsem se díval a je to tam.

Pokud tomu správně rozumím, ten server tedy identifikuje uživatele pomocí IP a masky a podle toho vytváří sessid. Ale jak to, že nemohu přes php zjistit masku? Proč PHP pracuje jen s IP a ne s maskou?

Takže útočník by mohl spustit bota ze sítě (např. 65 počítačů) a z jedné adresy by se mi mělo správně vytvořit 65 sessions. Vytvořilo by se 65 dočasných session souborů + záznam do db.
« 1 2 »

Vaše odpověď

Mohlo by se hodit

Příspěvky nesouvisející s webem budou odstraněny.

Odkud se sem odkazuje


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: