Php memória limit[MEGOLDVA]

Linux-security

"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.

  • 3482 megtekintés

( taxy | 2009. 01. 24., szo – 16:42 )

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-…

Ú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.

( taxy | 2009. 01. 24., szo – 18:30 )

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.

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.

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."

( taxy | 2009. 01. 25., v – 16:03 )

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.

( Mik v | 2009. 01. 25., v – 17:04 )

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...

( janoszen v | 2009. 01. 25., v – 19:35 )

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

( taxy | 2009. 01. 26., h – 09:55 )

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?

( janoszen v | 2009. 01. 26., h – 10:14 )

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.)

( sibidiba | 2009. 01. 26., h – 10:31 )

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

( taxy | 2009. 01. 26., h – 14:11 )

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.

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ő.

( taxy | 2009. 01. 28., sze – 19:11 )

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.

( Gergely | 2009. 01. 28., sze – 19:25 )

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.

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.