Apache biztonsági kérdés

Fórumok

Sziasztok,

Egy Linux webszervert próbálok összerakni, hogy minél biztonságosabb legyen.
3 weboldal megy rajta, mindháromnak külön felhasználót készítettem, a fájlok jogosultságait feltöltés után beállítom és hozzárendeltem az adott felhasználót.
Apach-ban "SuexecUserGroup domain1 domain1" hozzárendelem a felhasználót.
PHP mindnél saját php.ini open_basedir beállítva csak oda mehet ahová engedem.
PHP kódból próbálok kimenni gyökérbe nem sikerül,ha open basedir kikapcsolva, akkor ki tudok lépni.
Belépek a domain1 mappájába, majd ln -s / proba.txt, itt csináltam egy symlinket a gyökérre.
Böngészőbe beírom, hogy domain1.hu/proba.txt/etc/network/interfaces
És kiírja, hogy mi van az interfaces fájlba, pedig az open basedir beállítva.
Így gyakorlatilag még a log fájlokat is lehet olvasni távolról.
Ha jól sejtem itt nem a php adja vissza az interfaces fájt hanem az apache.
Mit tudok tenni ellene? A ne hozz létre symlinket választ kerüljük.
Teljesen letiltani a symlinket nem szeretném az apache-ban, csak azokat, amik a web mappáján kívülre mutatnak.

Megtenné valaki, akinek van webszervere, kipróbálja nála lehet-e ilyet?

Köszi!
Joda

Hozzászólások

Ha nem egy PHP fájlt futtatsz, akkor a PHP nem mozdul meg, nem érvényesül semmilyen beállítás. El is távolíthatnád, akkor is menne az /etc/...

Amit Te keresel az a chroot (jail), ez bezár egy alkalmazást a saját könyvtárába. És ha van egy "gyorshivatkozás", virtuális mappa (=symlink), akkor sem fog tudni kilátni. Azt fogod tapasztani, mint ha sima userrel a /root-ba akarsz belépni. Az apache user-eket kell jail-be zárnod. Pont ahogy egy FTP szervernél is kötelező, hogy ne lásson "felfelé".

Ez így egy megoldás a problémára. Most érdekel, hogy miért kell a symlink.

Ha chroot-al nem akarok foglalkozni, akkor mi jöhet még szóba?
Symlinket használok a phpmyadmin, webmail, stb... dolgokhoz, melyet mindenki használ.
Érdekelne olyan hozzászólás, aki pl. tárhelyeket ad ügyfeleknek, hogy nála ez hogyan van védve?
A több száz ügyfelet chrootolja?

NE használj symlinket :)
Készíts egy webmail.domained.hu-t, mint vhost-ot, majd oda pakolod a roundcube-ot, vagy ugyan így a phpmyadmin-t.

Mi így is szoktuk webhostingos szervereken.

Igazából a leges legegyszerűbb dolog, amivel több vhost-ot lehet menedzselni, az virtualmin + webmin kombó, vagy ISPConfig3.
chroot-ot tudsz állítani mindenkire, minden vhost unix felhasználó alatt fut, így még a php process is látszik user szinten, ami monitorozható. Majdnem ugyan azt csinálja, amit te kézzel.

----------------------------------------
o.-

Tobb szaz ugyfelet siman tudsz chrootolni, a kerdes inkabb az, hogy a suexecet hogyan irod at olyanra, hogy neked jo legyen. Ha bindmountolni akarsz mappakat, akkor 5000 bindmount folott kicsit maceras lesz a dolog, lassan fog bootolni a gep, de egyebkent mukodik. Ezen felul a chroot karbantartasa kicsit maceras lesz, ha sok featuret akarsz beletenni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ilyesmi nem járható út?

ls -dZ /var/www/*
system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/cgi-bin
    system_u:object_r:httpd_sys_content_t:s0 /var/www/html

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> Jó, mondjuk weblaponként egy-egy virtuális gépet nem lehet indítani. :)

Miert nem? Ha nem filleres hosting, akkor adott esetben megerheti. Legrosszabb esetben docker container, akkor meg nagyon managelni sem kell. Belemountolod a weboldalt es csa'.

Webhosting teren biztonsagi szempontbol ez a legtisztabb, igaz, nemileg eroforrasigenyes.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ha minden domainhoz külön felhasználó van hozzárendelve, akkor a "SymLinksIfOwnerMatch" megoldja ezt a problémát.

nem lehet h a fő apache configból hiányik egy Directory rész ami csak a www könyvtárat tartalmazza?
http://serverfault.com/questions/267440/apache2-how-to-restrict-access-…
szóval szerintem állíts be ezt:

DocumentRoot "/var/www/html"
..Directory /var/www/html..
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
../Directory..

és a /var/www/html alatt hozz létre különálló vdomain-et.

u.i. a kettő pont az igazából kisebb és nagyobb jel, csak nem jeleníti meg a code blokkban.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Ha a usereid ellen akarsz védeni, akkor komolyabban bele kelle mélyedned ebbe.
A legtöbb tárhelyszolágltó is elvérzik egy ilyene 'teszten'.

Ha gyakorlatilag Te vagy mindhárom user, az megint más eset.

Ez a cikkem ugyan a wordpress-re fokuszál, de van benne sok általános webszerver security dolog is:
http://zrubi.hu/2011/wordpress-background/

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

Az Apache a symlinkek szempontjabol versenyhelyzetekkel rendelkezik, a PHP open_basedir beallitasaban pedig nem lehet bizni. Mindketto ismert, dokumentalt teny. Ha elolvasod a forraskodot, ra is jossz, hogy miert.

Ha tenyleg biztonsagos rendszert akarsz, akkor az a minimum, hogy a PHP-d chrootban fut, es be van korlatozva network namespacebe. Az Apache problemait ezzel sem vedted ki, ahhoz az kell, hogy mindenkinek sajat Apache fusson, vagy kikapcsolod a symlinkek koveteset es a .htaccess tamogatast.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Nem muszaj feltetlenul teljes virtgepet inditani, eleg lehet neki a kivant namespacek beallitasa. Pl. csinalhat olyat, hogy a PHP-FPM a megfelelo nevterben fut, az nginx meg kivulrol csatlakozik, stb. De egyebkent igen.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A legtöbb disztro alatt elérhető már az Apparmor, aminek van az Apache-hoz külön modulja (Debian alatt: libapache2-mod-apparmor). Ezzel meg tudod csinálni, hogy

* az Apache globál mihez férhessen hozzá (írás, olvasás, mmap, stb...)
* az egyes vhosztok külön-külön mihez férhetnek hozzá, akár felülírva a globál konfigot

Mindez futhat chroot vagy LXC kombinációjában.

Hasonlót keresek már egy ideje.
Pedig már elér rég van mindenhol, sok disztro alapértelmezetten bekapcsolva szállítja.

Mennyire megbízható?
Erre most nem tudom, mit írjak. Miben mérik a megbízhatóságot? :)

Milyen buktatók merülhetnek fel, ha az ember bevezet egy ilyet?
Nem tudom, milyen buktatók merülhetnek fel. De szerintem buktató lehet, ha nem tudod mit akarsz, és úgy belevágsz. Vagy nem tudod, mire jó ez az eszköz, vagy hogy hogy működik. Ezeket egy teszt projekttel egy virtuális gépen ki lehet próbálni. (A chroot és paravirtualizációs megoldás kicsit spec eset, de ott is megoldható - én pl így használom sok helyen). Mindenképp érdemes éles bevezetés előtt "játszani" vele pár napot. Aztán lehet olyan, hogy már csuklóból megy a profil írás, de véletlen elírsz egy könyvtárat/flag-et, és valamihez nem férsz hozzá, amihez szeretnél, vagy ami súlyosabb, ha fordítva történik mindez (és azt meg ugye észre sem veszed). (Természetesen ezek megtörténhetnek más alkalmazásnál is, egy Postfix-ot is ugyanúgy félre lehet konfolni véletlen, hogy a fél világ azt használja relaynek.)

Csodákat ne várj tőle, de önmagában is egy jó eszköz. Egy open_basedir-nél többet ér szerintem, és a megfelelő használat mellett (megintcsak szerintem) elég tiszta és átlátható rendszert tudhatsz a magadénak. A joomlát ezzel is megtör(het)ik (értsd: a hülyeség ellen ez sem véd), de ha nagyon luzer csinálja, akkor tovább nem nagyon jut.

Emiatt szakma az informatika (is). Lepesek
- iskola
- onkepzes
- junior
- senior

...majd onallo munka. Miert gondolja azt valaki, hogy komplett megoldasokat kap, amihez nrem kell eloelet?
Kezd el kicsiben a webszerver epitest, majd 2-4 ev mulva tudsz onalloan is donteni. A megrendelod miert nem egy ezzel foglalkozo ceget keresett meg? Te miert nem azzal foglalkozol amihez ertesz?

...kijott belolem...

Gondolom a kerdezo osszerakta a maga kis rendszeret altala velt legbiztonsagosabb modon. Viszont nincs a kozvetlen kornyezetben olyan ember(nem is ismer), aki nala profibb, igy nem tudja eldonteni amit csinalt az jo vagy rossz. Vagy netalantan ahol uzemeltet ott ezek a hibak csak evek, evtizedek mulva jonnenek elo.

Egyszer mondta egy itegrator ceg alkalmazottja. "Mi uj technologia ismereteben es bevezetesben biztosa jobbak vagyunk, mint a napi helyi uzemeltetesben."