Tehát ha jön 40 látogató keep-alive, akkor a többi bukta? Ez szerintem viccnek is rossz. Azért 40 kapcsolat ne fogjon már meg egy oldalt. Lehet támadás is, de én is inkább a kódban néznék szét előbb vagy a beállításokban.
Egyébként a hirtelen több millió csak találgatás, vagy van valami alapja is?
Nem egészen tiszta számomra az eset, ezért csak általánosságokban:
DoS vagy DDoS támadásra gyanakszotok? DoS esetében egyetlen vagy csupán néhány IP címről érkezik a támadás, az jól kezelhető tűzfalszabályakkal, elosztott DDoS támadás esetében több ezer, durvább esetekben több tízezer helyről támadják a szervert, ez már nehezebb eset.
Ha a web szerver felé érkezik sok kérés, és ezek nem záródnak le, és ez okozza a gondot, akkor meg kellene nézni, hogy nincs-e engedélyezve a webszerveren a kapcsolatok fenntartása (KeepAlive). Ezt célszerű kikapcsolni (Apache esetében erre a "KeepAlive off" konfig opció szolgál), így a kapcsolatok a kérés kiszolgálása után rögtön lebomlanak, nem várakoznak újabb kérésre.
Ez eddig szép is, csak sajnos a támadások egy nagy része nem valid http kérést küld a szervernek, amit kiszolgál aztán lebont, hanem csak megnyitja a 80-as portot, és ott vár a kérésre a webszerver, amég el nem timeout-ol, ezen a KeepAlive tiltása önmagában nem segít sajnos. Persze a timeout-okat is lehet hangolgatni, de sajnos az apache (feltéve hogy azt használ a szolgáltatód) elég nehézkes ebből a szempontból, ill. a végtelenségig nem is csökkenthetők a timeout-ok, ezért ilyen esetekre praktikus valami multithread, a kapcsolatokat masszívan kezelni tudó előtét proxy-t, pl HAproxy-t vagy Nginx-et esetleg Varnish-t betenni az apache elé, ezek sokkal nagyobb mennyiségű kapcsolatot képes lekezelni, mint az apache, és az apache-hoz már csak a valid(nak tűnő) kérések jutnak el, így kevesebb kapcsolódást kellene kezelnie (ha a webszervwer reboot orvosolja a gondot, akkor ez ilyesmi jellegű túlterhelésre utalhat).
De ezt sajnos csak a szolgáltatód tudja orvosolni, te, mint felhasználó nem sokat tehetsz ez ügyben.
x
Szia!
Jelen esetben én voltam pontatlan, mármint a beszélgetésbe bevittem a DoS esetét is, nem tudjuk, hogy maga
a támadás, he egyáltalán volt is, milyen jellegű volt, legalábbis a post iró elmondása alpján ez nem tiszta.
Alapvetően az eredmény a DoS, hiszen a szolgáltatást megtagadja a szerver, azt, hogy ezt milyen technikával
érték el már más kérdés.
FONTOS: Ne keverjük viszont a kapcsolatok korlátozását a kérések korlátozásával!!
Abból adódóan, hogy a problémás időszak esetén a fenti hibát kapja a látogato, nem kapcsolati korlát
eléréséről van szó, hiszen a szerver tudott válaszolni. Apache esetén van egy modul, ami adott vhost-ra
lebontva nem enged több kérést, ami viszont teljesen valós adat lehet! Mivel az egyszerre futó kérések,
ha elérik egy átlagos oldal esetén a 40 darabot gyanítható, hogy előbb utobb ez elérhetné a jóval többet
is, ok: ha gyorsabban jönnek be a kérések, mint ahogy ki lehet őket szolgálni, torlódás lesz, egyre több
script fog futni, egyre kevesebb lesz a memória, illetve minél több szál fut, annál lassabb lesz a kiszolgálás.
Végeredményben korlát nélkül megfut a tehelés és nem rántható vissza a rendszer normál üzemi állapotba.
Apache esetén a keepalive KAPCSOLATOK nem minősülnek KÉRÉSNEK!!
A 2.4es apache eseten az event mpm használatával egyébként a statikusan csücsülő kérések, valamint
a statikus fileok kiszolgálása is az nginx-hez hasonló módon történik, ezért jóval több kérést tud
egyszerre kiszolgálni. Mindamellett egyébként mi évek óta használunk haproxy frontendet, ami az egyik
legjobb választás volt a fejlesztéseink során, stabil, jól beállítható, rugalmas kis proxy!
(a varnish inkább cache, mint proxy, persze használható a célra)
----> Tárhely, domain
Mit veszünk kérésnek (mert elég nagy a szórás úgy látom)? A kapcsolódástól az utolsó byte elküldéséig eltelt időt? Mert ott van ám a hálózati sebesség is. Hiába állítod elő gyorsan az oldalt, ha a kliens lassú. Ha így korlátozol 40-re, akkor még csak különösebben támadni sem kell az oldalt és leáll (persze van cache meg egyebek, amiről szintén semmit nem tudni és megoldás lehet). Nyilván nem tudjuk mennyi erőforrás áll rendelkezésre és mennyit fogyaszt az oldal, így bármit is írunk, az csak találgatás lesz jó nagy szórással, mint az látszik is.
Írtam már webszervert és tudom, hogy a probléma sokkal bonyolultabb, mint itt elférne. Viszont az esetek többségében nem is webszerverben van a hiba, hanem pl. a tűzfalban/kernel beállításokban stb.. Nekem a leírtak alapján úgy tűnik, nem hozzáértő támogatás van a szolgáltatónál, hanem csak találgatás, amiből vagy lesz valami, vagy nem. Sokadik alkalomra már illő lett volna kiszűrni egy kicsit pontosabban, hogy mi a gond és nem elintézni annyival, hogy lekorlátozták a kéréseket.
Köszönöm Mindenkinek a választ, és az időt! Laikusként nem tudok hozzászólni, viszont a linket továbbítottam a fejlesztőknek!
Hunor
Szia!
Oldalakat tudnék teleírni a webszerverek működésével, de sajnos időhiányában mostanság nem tehetem!
Fiatalabb koromban én is sokmindennel próbálkoztam, mitöbb írtam web és ftp szervert is. Elég jól megismertem,
az akkoriban divatos roxen webszerert is, egészen megkedveltem a pike programnyelvet is, stb. stb., no de most nem ez
most a lényeg. Egy egyszerű webes kérés esetén, leszámítva a dns-t és egyéb dolgokat a következő állapotokat
különböztetném meg (sima http, nem https, stb stb):
1. adatkapcsolat felépítése - szerver oldalról várakozás
2. kérés beérkeztetése fejlécekkel együtt
3. amennyiben a kérés teljes egészében beérkezett, annak elemzése
4. kiszolgálás előkészétése, .htaccess feldolgozása, jogosultságok ellenőrzése stb.
5. kiszolgálás - statikus file esetén a meglvő adatok alapján a file küldésre előkészítése, dinamikus
tartalom esetén a szükséges interpreter indítása, kérés paramétereinek átadása
6. kimenet utófeldolgozás, pl gzip, filterek
7. adatok küldése
8. napló írása
9. keepalive esetén ugrás a második pontra
10. kapcsolat bontása
A fentiek webszervertől függően más-más elgondolással kerülnek kiszolgálásra.
Apache 2.2 prefork mpm esetén a webszerver keres, vagy indít egy teljesen külön processzt, ami az
adott kéréssel foglalkozik. A második lépéstől az utolsóig tehát dedikált processz fog foglalkozni a
kliens teljes kiszolgálásával. Ennek a megoldásnak hátránya az, hogy ahány kapcsolat, az annyi
processz szálat és így memóriát, illetve más erőforrást igényel. Normál esetben a kapcsolatok száma
tehát erősen korlátozott, általában pár száz, maximum pár ezer egy webszerver esetén. (kernel korlát
is beavatkozik itt, például a nyitott file handle/socket szám)
A fentiek alapjánt tehát érthető, hogy nagy terhelés esetén a 2.2-es apache nem feltétlenül nyújt jó
szolgálatot.
Az nginx webszerver annyiban különbözik, hogy nem dedikál processzt minden egyes kapcsolatnak, hanem
a kapcsolatokkal egyszerre foglalkozik, tehát minden kapcsolatot nyilván tart és adott pillanatban egy adott
műveletet hajt végre. Ebből adódóan az nginx korlátai és memória igénye jóval kevesebb, mint az apache
webszerveré. Ugyanakkor nem alkalmas mindenre, mert amint dinamikus tartalom kiszolgálására van szükség
ugyan úgy viselkedik, mint az apache.
A fenti két működést igyekszik a 2.4-es verziókban egyesíteni az apache az event mpm működésével. A kiszolgálás
nagy részét igyekszik egy bizonyos processzel végeztetni, ahogy az nginx, illetve a kapcsolat felépülésekor, vagy
keepalive várásakor nem foglal egyáltalán memóriát, akárcsak az nginx esetén sem, ebből adódoan a webszerver
egyik legnyagobb korlátját sikerült kiküszöbölniük.
Apache esetén tehát korlátok tekintetében a kiszolgálás idejét kell figyelembe vennünk ez a 4,5,6,7-es pontok során
kap értelmet. Valóban felmerül az a probléma, hogy egy támadó még így is megteheti azt, hogy egy bizonyos kérést
igen lassú kapcsolatot szimulálva épít fel, ezzel gyakorlatilag a konkurens kérések számát szaporítja, ugyanakkor statikus
fileok esetén az apache is képes már dedikált processz nélkül működni. A lassú kérések kiszűrésére létezik modul, amivel
a minimális sebesség vagy összességében a timeout beállítható, tehát lehet édekezni ellene.
Abban az esetben, ha az adatokat lassan fogadó támadó php kérések ellen indítja nagyobb a gond, ugyanis az adott
interpreter nagyon sok memóriát fogyaszthat, ezzel komoly problémát okoz a webszerveren, kívánatos tehát az összes
futó php/cgi interpreterek számának korlázotása!
Huhh, remélem nem hagytram ki semmit a gyorsan összedobott összefoglalómban.
Könyvjelzők