Oldal: 2 / 2 ElsőElső 12
Eredmény: 11 - 17 (17) összesen

Téma: Honlap leállás domain ellen irányuló támadás miatt?

  1. #11
    Rubyist Geri logója
    Csatlakozott
    07-12-15
    Hely
    \x90
    Hozzászólás
    5.744
    Begyűjtött 1.428 köszönetet
    892 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    Idézet Hunor eredeti hozzászólása Hozzászólás megtekintése
    A fórum valami tízéves phpbb fórum, m.a.g.y.ar.r.online.n.net/f.o.r.u.m
    Ez siman lehet a problema forrasa. Egy 10 eves phpbb a mai php verzioval nem biztos hogy hibatlanul mukodik.



  2. #12
    Törzsvendég
    Csatlakozott
    13-02-04
    Hozzászólás
    156
    Begyűjtött 46 köszönetet
    39 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    Idézet Hunor eredeti hozzászólása Hozzászólás megtekintése
    lekorlátozzuk az egyidejű
    kapcsolatok számát 40-re.
    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?



  3. #13
    Bölcs rendszergazda logója
    Csatlakozott
    09-07-25
    Hozzászólás
    565
    Begyűjtött 108 köszönetet
    65 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    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

  4. The Following 2 Users Say Thank You to rendszergazda For This Useful Post:

    Hunor (2013-02-27), viacomkft (2013-02-27)

  5. #14
    Bölcs
    Csatlakozott
    09-12-19
    Hely
    Budapest
    Hozzászólás
    697
    Begyűjtött 102 köszönetet
    64 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    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)

    Idézet rendszergazda eredeti hozzászólása Hozzászólás megtekintése
    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.




  6. #15
    Törzsvendég
    Csatlakozott
    13-02-04
    Hozzászólás
    156
    Begyűjtött 46 köszönetet
    39 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    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.



  7. #16
    Mentor
    Csatlakozott
    10-05-30
    Hozzászólás
    413
    Thanked 1 Time in 1 Post

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    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



  8. #17
    Bölcs
    Csatlakozott
    09-12-19
    Hely
    Budapest
    Hozzászólás
    697
    Begyűjtött 102 köszönetet
    64 hozzászólásával

    Alapbeállítás re: Honlap leállás domain ellen irányuló támadás miatt?

    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.

    Idézet kepgp eredeti hozzászólása Hozzászólás megtekintése
    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.




Oldal: 2 / 2 ElsőElső 12

Könyvjelzők

Hozzászólás szabályai

  • Új témákat nem hozhatsz létre
  • Válaszokat nem küldhetsz
  • Fájlokat nem csatolhatsz
  • A hozzászólásaidat nem módosíthatod
  •