Php memória limit[MEGOLDVA]

 ( taxy | 2009. január 24., szombat - 15:26 )

"Sziasztok!

Mostanában DOS gyanús támadások érték az apache-ot(child process dos). Mióta frissítettem, azóta nem halt meg teljesen(lekopogom), de a swap használatban azért megjelennek a grafikonon néha tüskék. Arra gondoltam megpróbálok tűzfalas védelmet használni, hogy ne terhelődjön feleslegesen a szerver."

Korábban ezt gondoltam mert a processek valóban elszaporodnak, de valójában azért, mert a nagy memória foglalás miatt belassul a rendszer. Mint kiderült a php memory limit csak safe módban működik, így azt kivétel nélkül mindenhol be kell kapcsolni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Az sem kell feltétlenül hogy tűzfalas megoldás legyen, csak az lenne hatékony. Lehet apache modul-is. A lényeg hogy védelmet jelentsen az apache processek elszaporodása ellen.
Vagy érdemes lenne csak ezést megpróbálkozni a XEN kernel frissítéssel?
Az lenne jó ha csak be kéne oda másolni azt a xt_connlimit.ko-t, de gondolom ez nem így múködik :(

Itt egy kis segítség:
http://www.linuxquestions.org/questions/linux-enterprise-47/centos-5.0-x8664-need-help-adding-connlimit-module-to-iptables-655389/#post3213647

Úgy érzem hogy ez a szöveg mond valamit, ami nekem fontos lenne. Ez nekem megoldás lenne? Ha igen fogalmazzátok meg hogy én is értsem. Köszi.

A frissítés ellenére most megint haldoklik a server. A végletekig megtelik a swap, és ennek csak akkor van vége ha ujraindítom az apache-ot. Eleinte azt hittem a processek számának a megnövekedése az oka, de a maxClients-et levettem 150-ről, 50-re de így is csinálja. Frissítettem így is csinálja. Lehet hogy nem is DOS hanem egyszerűen túl nagy a forgalom, és rosszak a MPM prefork beállítások. Már nem tudom mi lehet ez! Tanácstalan vagyok.

mpm-prefork-ról mpm-event-re vagy mpm-worker-re váltás?
(mod_php helyett fastcgi kell, de talán még gyorsabb is).

Köszi a tippet!

A fastcgi-vel az a gondom, hogy igaz nagyon kényelmes dolog, hogy a szkriptek a felhasználó tulajdonosával futnak, mert kevesebbet kell bajlódni a jogok beállításával, de én egyelőre a felhasználóinkban jobban megbízom mint a felhasználó script-jeiben. A www-data egy kis mod_sec-el pedig egy jó módszer arra, hogy a felhasználót megvédjem a saját szkriptjeitől.

Ha a connlimit nem válik be, akkor megpróbálom.

- PHP estén valamilyen cache beállítása (eaccelerator, pecl-apc)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mindenképpen sort kerítek rá. Előbb utóbb úgyis kelleni fog. Csak most legalább éjszaka ne növekedjen a swap, :) érted. Általában nem akkor van ez amikor legnagyobb a forgalom, hanem teljesen kiszámíthatlan.

Ja és itt szerintem az IOWait a kritikus, mert (látszólag) , bár a XEN-nél nem lehet tudni, de a proci terhelés 5%-körül van.

Ezt az elsők között végezném el. Nem bonyolult. Ugyanakkor modulban kell lennie hozzá a php-nak, fastcgi nem jó.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

apt-get install xen-linux-system-2.6.26-1-xen-amd64 ?

Talán ez a megoldás?

Érdemes megpróbálni, lenny kernelt felrakni apt-vel?

Ért már valakit DOS támadás?

Ezt a szervert biztos, mert éjszaka is ugrált a swap szintje, pedig akkor alig van forgalom.

apt-get install munin munin-node
monitorozáshoz sokat segít...

Köszi!

Teli találat. :) Pont ezt használom én is.

ssh-ra csináltam ilyet valamikor:

# -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
# -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
# -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j ULOG --ulog-prefix "SSH_brute_force"
# -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH --rsource -j DROP
# -A SSH_WHITELIST -s 192.168.1.1 -m recent --remove --name SSH --rsource -j ACCEPT

Apache-hoz lehet nem lesz jó, de "iptables connection limit" -re rákeresve sok a hasznosnak tűnő találat...

+1

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nagyon köszönöm!

Ez azt hiszem ez telitalálat. Nem is reméltem hogy ilyen létezik.
Kár hogy a repositoryban a apache2-höz nincs benne.
Ha a mod_evasive nem válik be, ami direkt erre van kitalálva, akkor befordítom forrásból ezt.

Syn sütik bekapcsolása? netstat segít.

Ez egy jó ötlet.
Már korábban találtam neten egy adag sysctl-es beállítást DDOS ellen, és szerintem köztük volt ez is. Azért köszi. (bár fogalmam sincs hogy mit jelent, de beállítottam :) )

Mostmár egyre biztosabb vagyok benne hogy szó sincs itt semmiféle DOS-ról. Be van állítva hogy 16Mb a php-ban a memory limit, erre az apache2 process 41Mb-ot foglal. Attól tartok sokkal rosszabb a helyzet mint amire gondoltam, ez valami php memory leak lesz. De mit tudok ezzel kezdeni?

Egyáltalán hogyan deríthetném ki hogy melyik szript okozza?

Attól hogy a php-ban beállítod egy processz limitjét, még használhat apache többet. Ez nem leak.

Ja és természetesen a php memory limitje se egy olyan nagyon atombiztos dolog, most szaladt meg tesztkörnyezetben elég megbízhatóan az egyik PHP scriptünk memória fogyasztása 3.5 gigára. :)

Nem tudom mi de az biztos hogy akadályozza a szerver működését.
Miért nem szabadul fel akkor ha nem leak? (a php elvileg véges ideig fut)
Másképp treszem fel a kérdést:
Hogy hívják ezt akkor?
Hogyan lehet diagnosztizálni?
Hogyan lehet szabályozni?

mivel a php apacs modulkent fut, igy addig fut a php is, ameddig az apacs. (marmint addig foglal eroforrast)

t

Azt jelenti, hogy a rendszer nem akkor allokál socketet a kapcsolatnak, amikor beérkezik a syn, hanem csak akkor amikor a 3 way handshake lezárult, azaz ténylegesen fölépült a kapcsolat. Ennek vannak ugyan hátulütői, de sztem számodra per pillanat az előnyei sokat nyomnak a latba. (Bocs, válasz akart lenni a syn sütis threadre.)

Szerintem a connlimit nem lehet megoldas, mert azzal sajat magadato DOS-olod. Ha van egy szerver, ami DOS tamadas alatt all, es te lejebb viszed a maximalis kiszolgalt lekeresek szamat, akkor csak meg hamarabb jon el az a pont, ahol a valodi felhasznalokat "service unavailable" fogadja.

ConnLimit 50 mellett pedig meg egy asztali gepnek is ki kellene tudnia szolgalni azt a max. 50 klienst, fuggetlenul attol, hogy valodi-e vagy sem. (Ilyen nagysagrendnel nincs is nagyon ertelme DOS-rol beszelni.)

Itt valami massal van a baj, valamelyik program/script szimplan magaban zabalja az eroforrasokat.

--
The Net is indeed vast and infinite...
http://gablog.eu

Igen ezt már én is megértettem, de hogyan tudnám kideríteni hogy melyik? Egyenként tiltsam le a site-okat? A log-ban nem látok semmi olyat amiből követketetést tudnék levonni

Levettem a MaxClients-t 10-re így csak 200Mb memóriát eszik az apache a 256Mb-ből, ha egy processre 20Mb-ot számolunk. És akkor még ott a mysql ami megeszik 25Mb-ot.
Szóval meglátjuk erre mit lép.

És ha veszel bele 2-4G RAM-ot az nem érvényes megoldás?

Nem rajtam múlik hanem a "cégen".
Ha megnézed az árakat, rájössz hogy miért próbálom kerülni ezt a megoldást, amilyen eszközzel csak lehet: http://www.slicehost.com/

Upsz. Nem szóltam.

rlimitmem ?

Téged az ég küldött!

Már be is állítottam, és várom a fejleményeket. Abban reménykedem hogy valami sokat eláruló hibaüzenet is jön, ha esetleg bekövetkezik a határátlépés. Ha jól értem ez megöli a processet a hard limitnél.
A soft limitnél történik valami vagy az csak dísznek van?

Hasonló problémába egyszer én is belefutottam egy kis VPS-en. A megoldás az lett, hogy a

http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxrequestsperchild

direktívát a default 10000-ről valami 200-ra (prefork esetről volt szó). Így aztán nem volt sok ideje elhízni a processzeknek, mert még idejében kihaltak. Féltem, hogy ez majd megdobja a processzorterhelést, de szerencsére nem ez történt, persze kis kihasználtságról volt csak szó. Persze meg kell gondolni az értéket, ez a 200 nagyon kevés is lehet, ha olyan weboldalaid vannak amik tele vannak mondjuk kis képekkel vagy ilyesmi. Ilyenkor 500-1000 lehet a jó.

Ha ezt beállítod, érdemes nézegetni, hogy mennyi időt éldegélnek a processzek átlagosan, illetve az élettartam és memóriafoglalás közötti összefüggést:

ps -eo comm,etime,rss |grep 'httpd'

és ez alapján finomhangolni az értéket.

Ha csak a MaxClients-et állítod, attól még elég jól el tud hízni a httpd néhány memóriazabáló alkalmazástól (tipikusan ilyen pl. az eGroupware).

Van még a MaxMemFree kapcsoló is amivel érdemes lehet játszogatni, ezt még nem próbáltam.

Most 1000-re van állítva, ez szerintem jó lesz az RLimitMEM-mel kombinálva.
Köszi, végre megértettem hogy hogyan működik ez a dolog. Tudat alatt sejtegettem hogy valami ilyesmi lehet a maxrequestsperchild, de nem is feltételeztem hogy ez a memória felszabadítás módja. Elég meglepő.

Egy nap teszt után egyértelmú: az rlimitmem-nek semmi hatása nem volt. 31Mb-ot adtam hard limitnek, és az apache process simán túllépte ezt, és a memória grafikon teljesen ugyan az volt mint tegnap. Mivel ezt a memory limitelést elvileg a kernel kéne hogy végezze, nem lehet hogy kéne valami modult aktiválni? Quota-val még nem foglalkozetam egyáltalán.

javasolnam ezekre a problemakra a kovetkezoket:

  • apache modul: mod_security
  • apache modul: mod_evasive kifejezetten dos
  • php safe mode es suhosin patch - hardened php.

remelem segitett :)
---
Tévedni mindenkinek szabad, csak a mérnöknek észre kell vennie.

Köszi, azt hiszem segítettél. A safe mód memória limitje hívta fel magára a figyelmemet, és már tudom is kit kell seggbe rúgni ezért.(a safe mód kikapcsolásáért a fájlrendszer bizonyos kritikus részeiben) :)

A safe mód csak egyetlen egy helyen volt kikapcsolva, de mióta ott visszakapcsoltam, eltűntek a hirtelen memória foglalások. Pedig hibaüzeneteket sem látok. A safe mód ezek szerint nem csak hogy memória limitet ad, de a memória leak-eket is jobban kezeli.

Köszönöm mindenkinek aki segített, azt hiszem megoldódott.