PHP a bezpečnost na serveru (diskuse)

[2012]

Co take ultra-security-needed prevadzkujes na servery? Homepage?

[vlastik]

Já se na open_basedir raději nespoléhám. Stránky umisťuji do domovských adresářů uživatelů (do podadresáře public_html) a PHP pak vždy běží pod daným uživatelem.

[roman]

A jak to delate, ze php bezi pod jinym uzivatelem podle vlastnika ? Jak to funguje v kombinaci s apachem, pouzivate PHP jako modul(asi ne) tedy jako fcgi/wscgi? Prozradte vice? Diky R.

[Jakub Lucký]

těch variant je... Na to popisované je myslím nejlepší suphp, které je ale spíše nevýkonné... Mně se osvědčilo fcgid + suexec

[trekker.dk]

Hledej mod_suexec

[Jendа]

Buď se to dá udělat jako CGI a suexec, což je trochu pomalejší, protože se to musí při každém požadavku naforkovat. Nebo se to dá udělat tak, že si spustíš víc FastCGI procesů, každý pod jiným uživatelem, což je sice rychlé, ale zase to při víc uživatelích může žrát paměť. Apache nepoužívám, ale oboje jsem dělal na LigHTTPd a nginxu.

[Erbureth]

apache2-mpm-itk, řeší problém tam, kde vznikl, tedy přímo na úrovni Apache.

[Jakub Lucký]

Open_basedir je v Debianu považováno za broken... Osobně jako rozumné zabezpečení vidím provozovat každý web pod jiným, velmi omezeným, uživatelem...

[Dragon Jake]

jak říká Jakub, nejlepší řešení je spolehnout se na OS. V případě omezeného uživatele už dokonce odpadá nutnost zakazovat funkce (btw. proč parse_ini_file a proč show_source, což je jen alias pro highlight_file?)

[Jakub Lucký]

#cat /usr/share/doc/php5/README.Debian.security

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 code written in the PHP language. Most specifically, the security team will not provide support for flaws in:

- vulnerabilities involving any kind of safe_mode or open_basedir violation, as these are security models flawed by design and no longer have upstream support either.

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

-- sean finney Tue, 10 Oct 2006 12:42:06 +0200

(redakčně kráceno)

[trekker.dk]

Musím říct, že přístup "i když budeme vědět, že v open_basedir je chyba, nebudeme ji opravovat" se mi teda moc nelíbí.

[Jakub Lucký]

Mně přijde výmluvné to "certain configurations known to be inherently insecure" a " no longer have upstream support either."

[trekker.dk]

Co se týče "no longer have upstream support either" - když už používám Debian stable, očekávám, že se vývojáři budou snažit opravovat chyby, dokud bude daná stable verze podporována. Bez ohledu na to, co si myslí upstream.

[Lol Phirae]

"Feature broken by design" není nic, v čem by se měl downstream vrtat.

[Mrkva]

No nevím, osobně mi přijde lepší to říct narovinu, než se snažit látat něco, co je deffective by design.

[trekker.dk]

No zrovna co se open_basedir týče, tak mi nepřijde, že by to bylo deffective by design. Jasně že spousta věcí se dá pořešit právy uživatele, pod kterým běží PHP, ale i tak jsou místa, kam ten uživatel potřebuje přístup (aby fungovalo PHP), ale přesto nechci, aby tam mohl hrabat skript.

[VSi]

Z mého pohledu je open_basedir v mnoha situacích velmi dobrá vlastnost PHP, a to i když se zároveň používá např. suexec. Nicméně je to skutečně defective, dokud se důsledně nezakážou všechny funkce typu exec, shell_exec, system atd. (je jich skutečně hodně), které umožňují spouštět externí kód, na který se open_basedir samozřejmě nevztahuje. Problém vidím v tom, že těch funkcí umožňujích spustit externí kód je skutečně hodně, pak k tomu lze zneužít některá php rozšíření, a neexistuje jedna volba, která by toto omezila.

Jistě je jedna z cest i použití věšcí jako selinux nebo apparmor. Jenže zatím jsem nenašel možnost nebo konfiguraci, která by umožnila snadné nasazení a správu na mass-hostingu (řekněme stovky izolovaných webů na jednom systému). Fastcgi+suexec s volitelným open_basedir (není-li třeba spouštět externí aplikace) je pak dobrá volba.

[phax7]

Hmm, tohle vypadá docela výmluvně... moc jste mě teda nepotěšili:)

[saly]

Na serveru používám apache-mpm-itk, takže podproces webserveru pustím celý pod konkrétním uživatelem, který patří k dané doméně a pak je mi zbytek celkem jedno

[Luk]

Každé řešení má své. mpm-itk přináší rizika v podobě běhu pod rootem (do zjištění, co je v hlavičce Host a následné změny uživatele). mpm-peruser je na tom podobně, liší se hlavně z hlediska výkonového (většinou je rychlejší, ale při velkém počtu uživatelů žere hodně paměti). Řešení založená na CGI jsou bezpečnější, ale vždy výrazně pomalejší.

[VSi]

Z měření, které jsem naposledy dělal (na reálné aplikaci, umělá zátěž) vyplynulo, že výkon mod_php a PHP+FASTCGI+SUEXEC je naprosto srovnatelný. CGI je samozřejmě nekolikanásobně pomalejší. Jako nevýhodu všech řešení s mod_php (mpm-peruser, mpm-itk) bych jmenoval vyšší spotřebu paměti (protože PHP knihovny jsou načteny i v procesech, které obsluhují statický obsah) a nutnost použít non-threaded Apache worker (PHP, resp. mnohá rozšíření, není thread-safe).

Riziko běhu pod rootem tam bude vždy, u suexecu je to riziko minimalizováno na jeden spustitelný soubor se silně ořezanými funkcemi. Je tu i možnost fastcgi procesy spustit "napřed" při startu serveru již pod cílovými uživateli. To se ale moc nehodí pro mass-hosting, spíš pro jednotlivé aplikace.

Jinak dost záleží na provozovaných aplikacích. Běh pod různými uživateli přináší nevýhodu v nemožnosti sdílet opcode cache (nebo aspoň nevím, jak to udělat), což se při desítkách webů, co načítají např. stejný Zend Framework, dost projeví na spotřebě paměti. Pak může být open_basedir a zakázání "nebezpečných" funkcí dobrá cesta.

[Luk]

Z měření, které jsem naposledy dělal (na reálné aplikaci, umělá zátěž) vyplynulo, že výkon mod_php a PHP+FASTCGI+SUEXEC je naprosto srovnatelný.

Asi bude záležet na konkrétní situaci.

[Zdeněk Burda]

Co takhle přidat do php suhosin a mod_security do apache?

[phax7]

Podívám se na ně, to bude asi cesta...

[Max]

Já používám fastcgi+suexec a žádný problém. Nicméně i tak se mi to moc nelíbí :-/. Sice je to pěkné systémové řešení (každý web běží pod jiným uživatelem a každý uživatel má svůj vlastní php.ini), ale radši bych tu bezpečnost ještě zvýšil. Tudíž se koukám pomalu po nějakých možnostech chrootu, popř. již zmíněné suhosin.
Zdar Max

[pht]

Jako obvykle se zapomnělo na mod_selinux resp. mod_apparmor.

[Josef Kufner]

Proč zakazuješ curl_exec, curl_multi_exec, parse_ini_file a show_source? Ani jedna z těch funkcí není nijak nebezpečná a navíc jsou nahraditelné spoustou jiných funkcí, jen to bude znamenat více práce pro programátora a větší zátěž serveru, případně i zhoršený zdravotní stav admina.

[phax7]

Já jsem programátor i admin v jedné osobě, když mi budou chybět tak si je povolím:)

[Josef Kufner]

Tím jsi ale nijak neodpověděl na otázku.

[phax7]

Já netuším k čemu ty funkce jsou:) Nějaký web co jsem vygoolil mi řekl ať je zakážu, nepotřebuju je, zakázal jsem je:)

[Josef Kufner]

Ach.

Tak ve zkratce takto: Jsou stejně nebezpečné jako file_get_contents().

[Dalibor Smolík]

egister_globals = Off to už je dneska všude default
Já jsem tak strašně líný člověk, že si dávám register_globals na ON .. ale moje aplikace je jen vnitřní, ven to nejde ..

[Josef Kufner]

Ono to ani nemusíš zapínat, stačí na začátku (nebo i jinde) udělat:

parse_str($_SERVER['QUERY_STRING']);

...a máš to samé. Ftip je v tom, že to můžeš udělat třeba uvnitř nějaké funkce, takže případný útočník má jen velmi omezené pole působnosti k ovlivnění neinicializovaných proměnných.