Apache2 virtual userek

Debian GNU/Linux

Sziasztok!

Abban kérném a segítségeteket, hogy a napokban a szerverem igen nagy terhelés éri. Gondolom valakinek törik a weboldalát. Azt látom, hogy az apache bolond mód megy.

Most úgy működik a dolog, hogy az apache 1 user nevében fut. "web" (tudom ez nem jó így.)

A nyomozást a következő scripttel kezdtem:
for pid in `pgrep -u web`; do find /proc/${pid}/cwd -printf "%l\n" ; done

Ezzel valamelyest megközelítem, azokat a mappákat amiket a web user használ. Viszont ami érdekes, hogy a kimenet nagy része a / -re mutat. Ami azért is érdekes, mert oda nincs joga az web usernek. Ez a keresési módszer egyik előző fertőzött oldal elkapásánál segített. Most viszont valami más kell.

Rákerestem a virtualhostok külön userként futását lehetővé tevő apache2 kiegészítőre: apache2-mpm-itk.

Ez már biztatónak látszik.

A kérdésem az lenne, hogy ha virtual hostba beleírok egy usert annak ugye fizikailag is léteznie kell a szerveren? Sőt a home mappája jogosultságát is meg kell változtatni. Ez csak azért érdekes mert több mint 300 hostról van szó.

Aki esetleg használja, kérem írjon róla pár instrukciót. Ő hogy oldotta meg.

Előre is köszönöm.

Üdv.
TTSZ

( dannyboi | 2011. 06. 04., szo – 20:14 )

Kb. 1 éve mpm-itk-val használom, és igen, a vhostoknak külön létező usere van.

Nálam úgy van kiépítve, hogy pl. /home/hostgroup1/vhost1 , /home/hostgroup1/vhost2 alatt vannak a hostok (vannak még alkönyvtárak ezek alatt, nem a vhost1 a doc_root).

A user pedig hostgroup1 csoportban van, a /home/hostgroup1-en 0750-es jog van, a userekén pedig már csak 0700-ás.

Az apache vhost configban kell az itk-nak az

AssignUserId vhost1 hostgroup1

beállítás, és így eléri apache a kiszolgálandó fileokat.

Nálam a proftpd is úgy van beállítva, hogy mysql backendből megy, és ott meg van adva, hogy a userhez (ami viszont nem kell, hogy fizikai user legyen) a megfelelő uid, guid be van állítva, így a feltöltött fileok rögtön ugyanazon user tulajdonnal kerülnek fel. Ráadásul elég, ha mindenen csak user jog van (pl.: 0700, 0600).

Előny még, hogy továbbgondolva az egészet, még ssh, scp is használható.

A kvótázás is megoldva, file szintű quota-val, userenként.
Hátrány tud lenni viszont, hogy egy-egy usert mindenhol (apache config, home dir elkészítés, proftpd - ha mondjuk mysql authos, quota) élesíteni, beállítani elég macerás tud lenni, főleg akkor, ha már meglévő struktúrát akarsz így migrálni. Emiatt én írtam magamnak erre egy webes felületet gyorsan, hogy mindent megcsináljon, nekem csak a paramétereket kelljen megadni (usernév, kvóta, melyik domain lesz alatta, stb.)

Ha lenne kérdésed, akár privátban is segítek.

U.I.: Bocs, ha kicsit pongyola, vagy nem egyértlemű, nem vagyok fogalmazási képességeim csúcsán. :)

Lesz majd csodálkozás ha mondjuk egy Joomla hibán keresztül felpakolnak egy "carefully crafted" (igazából tetszőleges, de csak emiatt olvasom végig a biztonsági figyelmezetetéseket :) ) .htaccess file-t és mindenféle bohóságra irányítják a kedves felhasználókat. Ez megtörtént hagyományos prefork-os mpm-el, hogy a kedves vhost tulaj a vhost könyvtárra is adott (a csodálatos Joomla miatt) írási jogot "mertcsakígyműködik".

Így elnézve a leírását az sem tölt el boldogsággal, hogy rootként kell futnia a setuid() miatt és a setuid előtt kihasználható hibákra bazira oda kell figyelni. (Tudom, próbálnak mindenféle jogtól megszabadulni, írják ezt is.)

Ez a joomlás dolog megtörténhet gyakorlatilag bármelyik apache típus és php esetén is, mivel php-nak tudna kell fileokat létrehoznia. Illetve ugye elvárás. Sok useres hostingnál az pedig ugye nem annyira működik, hogy php csak bizonyos könyvtárat írhat a vhoston belül, mást meg nem. Vagy legalábbis elég körülményes lenne megoldani. Egyébként a joomláktól én is tartok.

Viszont ha ez megtörténik, a jogok miatt csak a saját könyvtárában tud kárt okozni, más userében nem.

A setuid félelem sokkal durvább, de sajnos valamit-valamiért. Jó lenne valami okosabb megoldás, sőt, én szívesen megszabadulnék akár apache-tól is, de ugye az egyre népszerűbb rewrite-olás egy lighttpd, vagy nginx esetén körülményesebb lenne (már hogy a userek által megírt/módosított szabályok config alá vétele).

( maszili | 2011. 06. 04., szo – 21:10 )

Az apache server-status alapján kinyomozhatod hogy melyik domain lehet az.

--
maszili

Nyomozgattam a szerveren és nem tudok rájönni egy valamire.

Megnézem a top -ban a zabáló process pid -jét. aztán lefuttatom ezt.
find /proc/{pid}/cwd -printf "%l\n"

ezzel ezt kapom /

Eszerint az apache a / -ben olvasgat, vagy irogat. Ez érdekes mert nincs joga hozzá. A home ból ki sem tud jönni.

Mi lehet ez szerintetek?

Köszönöm előre is.

Üdv.
TTSZ

( janoszen v | 2011. 06. 05., v – 00:39 )

Az ITK-val több bajom is van. Az egyik, hogy rootként fut a process, amíg egy adott userre nem vált. A másik, hogy úgy van megírva, hogy minden vhostra jövő kérés mindenhova beeshet, ha viszont már usert váltott, vagy terminál, vagy újraindítja a feldolgozást. (Erre nem emlékszem pontosan.) A PHP és hasonszőrű társai futtatásának támogatott módja a FastCGI használata, ami nem tartalmazza ezeket s tervezési gyengeségeket.

A fastcgi nálam is felmerült, sőt igazából én is jobbnak gondolom az itk-nál. A bajom az vele, hogy nagyon el tud szaladni a terhelés sok lekérés esetén, igaz a futtatott threadek sokkal gyorsabban kiszállnak a memóriából, és kevésbé robosztusak, mint a többi apache mod.

Aztán lehet, hogy meg kellene tanulni ügyesen konfigolni a fastcgi-t, és nem lenne semmi baj. Éles rendszeren nehezen szánom rá magam, hogy kísérletezzek, de szerintem meg fogom próbálni megint. Sokkal megnyugtatóbb lenne, mint az itk, az biztos.

Az MPM-ITK gyakorlatilag egy Prefork másolat setuid módosítással. Ahhoz, hogy setuidolni tudjon, rootként kell futnia. Ugyan eldobja a lehető legtöbb jogot, de ha pl. a mod_ssl-ben van valami code exec vuln, akkor rootig verik a gépet.

Ami a második problémát illeti, a prefork úgy lett megírva, hogy minden child egyformán csinál accept() hívásokat a listen socketre. Ergó egy olyan child is megteszi ezt, amelyik már beváltott egy adott userre. Ha viszont beváltott az adott userre, akkor már úgyis mindegy, mert más userre már nem tud átváltani. Őszintén bevallva, nem olvastam el az ITK egész forráskódját, de egy jó részét végignyálazva rábukkantam erre: 


        /* if we have already setuid(), die (we can't be used anyhow) */
        if (getuid())
            die_now = 1;

És ez úgy annyira nem tetszett. Persze az is lehet, hogy benéztem valamit és lehet érdemben használni, de az ITK a szerző bevallása szerint is experimental és valószínűleg az is fog maradni, ahogy elnézem a fejlesztési történetét. A FastCGI használata sokkal kevesebb rizikót és potenciális szűk keresztmetszetet hordoz, mint az ITK, úgyhogy én inkább abba az irányba indulnék el.

Igen, ez mar bennem is felmerult, de a FastCGI-nek meg az a hatranya, hogy minden egyes userhez kell egy FastCGI szervernek futnia, ha meg akarom azt valositani, amit ITK-val meg tudok (a PHP nem valt usert). Ez szerintem olyan 10-20 usernel meg elmegy, felette mar nyug, mert a FastCGI processzek akkor is eszik az eroforrast, ha epp senki nem kivancsi rajuk. Meg ha meg is mondom a FPM-nek, hogy egyszerre max 2-3 childdel dolgozhat, ez - alaphangon - egy 80 useres kornyezetben 160-240 konstansul ott levo FCGI processz, ami nem tunik el.

Ami meg felmerult bennem, az a suPHP, de ez meg - amennyire tudom - nem sokkal jobb, mint a sima CGI-s PHP, hosszu tavon teljesitmenyben ez is nyugos.

Hosszu tavon nekem az ITK a kisebbik rossznak tunik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal