Dotaz: Zabezpecenie zdielaneho webhostingu

[maros]

Zdielany webhosting: Apache, PHP, MySQL, FTP resp. SCP.
Co pouzit na minimalizaciu dopadu hacku vhostu na ostatne vhosty a cely server?

- OpenVZ vs FreeBSD jaily?
- grsecurity vs SElinux?
- nginx reverse proxy + Apache MPM-ITK?
- vhodne domovske adresare pre pouzivatelov pod ktorymi budu vhosty bezat?
- separatny filesystem /tmp pripadne definicia vlastnych tempov pre kazdy vhost?
- separatny filesystem /srv/www, noexec?
- ako zakazat, aby pouzivatel, pod ktorym bezi web nemohol spustat programy (wget, curl, telnet, ssh)?
- lahka identifikacia vhostu, ktory generuje bordel (sietova prevadzka do Azie pripadne Afriky)

Odpovědi

[maros]

- vhodne nastavene PHP: open_basedir, zakazane rozne funkcie (dl, system, shell_exec, ...)? - vhodne nastaveny nginx + Apache?

[Jakub Lucký]

open_basedir je děravé... Asi to zastaví lamky, ale možností to obejít je spousta...

[AraxoN]

Môžeš pre nás pre lamky dať aspoň jednu z možností, ako v PHP obísť open_basedir? Shell_exec(), passthru(), dl(), popen() a spol nerátam - tie hádam vypne každý, kto sa spolieha na open_basedir...

[Jakub Lucký]

Tak postupně:

• Obejítí pomocí compress.bzip2://
• pomocí MySQL

Vyjádření RedHatu k bezpečnosti open_basedir a Debian

Popis na wiki.apache.org

A nakonec co říká samotné PHP

Ani jedno z toho ve mě nevzbuzuje důvěru "Ano, toto použiju"

A jako bonus Debian:

The Debian stable security team does not provide security support for
certain configurations known to be inherently insecure. This includes
the interpreter itself, extensions, and user scripts written in the PHP
language. Most specifically, but not exclusively, the security team will
not provide support for the following.

 * Security issues which are caused by careless programming, such as:
   - extracting a tar file without first checking the contents;
   - using unserialize() on untrusted data;
   - relying on a specific value of short_open_tag.

 * Vulnerabilities involving any kind of open_basedir violation, as
   this feature is not considered a security model either by us or by
   PHP upstream.

 * Any "works as expected" vulnerabilities, such as "user can cause
   PHP to crash by writing a malicious PHP script", unless such
   vulnerabilities involve some kind of higher-level DoS or privilege
   escalation that would not otherwise be available.

PHP upstream has published a statement regarding their view on security
and the PHP interpreter:
http://www.php.net/security-note.php

[AraxoN]

Ďakujem, je to tak ako som si myslel... To prvé (bzip2) je zjavný bug a je to už dávno opravené. To druhé je známa vlastnosť databázy MySQL a s PHP nijako nesúvisí - rovnako sa prejaví aj pri prístupe z iných jazykov. Všetky ďalšie odkazy len varujú, že open_basedir nie je žiaden svätý grál zabezpečenia webového servera a je potrebné myslieť aj na ďalšie súvislosti (ako napr. to MySQL). To tam píšu veľmi správne a nedá sa s tým než súhlasiť.

Open_basedir nie je vôbec deravé. Robí presne to čo má (a nič viac).

[trekker.dk]

To obejití pomocí MySQL není chyba open_basedir, ale chyba nastavení systému, který uživateli mysql umožňuje přístup k souborům, které mu nepatří.

[Jakub Lucký]

Ano, není to přímá chyba open_basedir, ale je to ukázka toho, jak z principu open_basedir není zabezpečení (kromě nějakého jakoby omezení pro přímé PHP fce)

Pokud chci mít bezpečno, musím na to jinak

[Jendа]

Osobně spouštím php-cgi nebo fastcgi pod různými unixovými uživateli (každý web nebo skupina webů má jednoho) a doufám, že to systém vyřeší.

Pak můžeš používat ulimit, identifikaci paměti a trafficu podlu UID atd.

[maros]

To by chcelo trosku rozpisat...
ulimit - pouzivate?
identifikaci paměti - k comu je to dobre?

[Jendа]

- ne, mám hodné uživatele (respektive mám jich málo)

- můžeš zjistit, kdo kolik žere

- ako zakazat, aby pouzivatel, pod ktorym bezi web nemohol spustat programy (wget, curl, telnet, ssh)?

Sehnal bych si seznam „nebezpečných“ PHP funkcí (shell exec atd.) a prošel bych je a pozakazoval.

[maros]

Velmi nebezpecne je eval + base64_decode, ktore sa pouziva na obchadzanie zakaznych funkcii. Zakazanim eval vsak nebude fungovat skoro ziadny CMS.

[AraxoN]

Direktíva disable_functions sa vzťahuje aj na funkcie vykonané vo vnútri eval(), či nie?

[student]

OpenVZ / FreeBSD jaily / Solaris containery su takmer idealne riesenie, co do bezpecnosti - akurat sa to zle udrzuje.

U mna jednoznacne grsec, rozumne nastavit (obmedzit vsetko, co ide). Ano, Apache MPM-ITK, ale odporucam nebezat hlavny proces po rootom (spustat pod velmi obmedzenym uzivatelom; pouzit capabilities).

Zvlast tmp pre kazdy vhost je samozrejmost (u mna mal kazdy uzivatel v roote po pripojeni cez SFTP zlozky www, sub, log, tmp - www bola hlavna stranka, sub boli subdomeny, log boli logy (readonly pre uzivatela; naviac chattr na append only), tmp bol temp.

Zakaz spustania programov spravis v grsecu; mozes to spravit aj v PHP (nech je to na viac urovniach).

Identifikacia vhostu by mohla ist cez grsec; vo vseobecnosti je to dost narocne.

[Peter Šantavý]

Ahoj, tiez pridam svoje riesenie: - SELinux - MPM-ITK - vlastne tempy pre kazdy vhost - open_basedir + vypnutie funkcii - ulimit - pri pouziti mpm-itk je identifikacia problematickeho vhostu pomerne jednoducha

[pavlix]

mpm-itk jsem měl vždycky v oblibě.

[maros]

Co konkretne riesite SELinuxom?