PHP Hardening - Suhosin

[Tomoiaga]

Ce este Suhosin ?
Suhosin prin functiile disponibile vrea sa fie un inlocuitor al PHP Hardening-Patch.
Are avantajul disponibilitatii ca extensie si poate fi rulat in mod de simulare, astfel scutind recompilarea php si observarea problemelor existente fara a afecta functionarea site-urilor de pe server.

Sa aruncam o privire aici

Daca nu v-ati convins de ce ar trebui sa folositi Suhosin va astept cu
intrebari.

Pentru alte detalii accesati link-ul oficial

Instalarea am realizat-o pe un server cu CentOS 4.4, PHP 5.1.6 si Apache 1.3.37, instalare ca extensie, fara patch.
Teoretic ar trebui sa functioneze si cu alte versiuni PHP, Apache, Unix.
Pe site-ul oficial mai sunt prezentate metode de instalare pe Unix in general, Gentoo si FreeBSD

1. Pasi de instalare:

Download suhosin de aici: http://www.hardened-php.net/suhosin/download.html

Dupa dezarhivare (tar -zxvf [arhiva].tgz) intram in directorul nou creat
(suhosin) si executam urmatoarele comenzi (asemanator cu instalarea mod_security de exemplu):

Cod: [Selectează]


> phpize
> ./configure
> make
> make install

Dupa executarea acestor comenzi ar trebui sa avem suhosin.so (extensia) creata in directorul de extensii php. Recomand o verificare pentru siguranta. In cazul meu directorul php pentru extensii este /usr/local/lib/php/extensions.

Ne mai ramane sa adaugam in fisierul de configurare php, php.ini urmatoarele linii:

Cod: [Selectează]

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;

extension=suhosin.so

; alte extensii...

iar la sfarsitul fisierului, unde am de exemplu si configurarile
eaccelerator si Zend :

Cod: [Selectează]

suhosin.simulation=on
pentru a folosi doar modul de simulare pana ma asigur ca totul este in regula.

Dupa restart Apache suhosin ar trebui sa fie incarcat.
Pentru verificare se poate apela functia php, phpinfo().
Daca, dupa apelarea phpinfo() nu gasim nicaieri extensia suhosin atunci trebuie verificate logurile de eroare php, cel mai probabil calea catre extensie este gresita.
Daca suhosin s-a incarcat corect, la apelarea phpinfo() vom observa
setarile default iar modul de simulare activ.

2. Pasi de configurare

Pentru modificarea setarilor default este de ajuns sa adaugam in fisierul php.ini variabila pe care dorim sa o modificam cu valoarea dorita. De exemplu, pentru activarea protectiei e-mail am adaugat suhosin.mail.protect=1, sub suhosin.simulation=on setat mai sus, la pasul de instalare:

Cod: [Selectează]


suhosin.simulation=on
suhosin.mail.protect=1

Toate variabilele ce apar la extensia suhosin, la apelul phpinfo() se pot modifica in functie de nevoi. Nu uitati, daca ati urmat toti pasii corect ne aflam in modul de simulare si astfel se pot testa toate variabilele fara probleme.

3. Note

Pentru explicatii mai detaliate ale variabilelor avem site-ul oficial:
Configurare Suhosin

Modul de simulare "is a must" deoarece pot exista site-uri care includ fisiere php din alte domenii de exemplu, lucru pe care suhosin nu il permite decat daca scriptul se afla in whitelist

Este bine ca avem si un whitelist. Variabila suhosin.executor.include.whitelist ne poate ajuta destul de mult, astfel se pot adauga scripturile care stim sigur ca nu sunt vulnerabile la aceasta variabila, despartite prin ; (tot in php.ini). Exemplu:

Cod: [Selectează]

suhosin.executor.include.whitelist=http://www.exemplu.com/include.php;http://www.exemplu2.com/script.php;

In cazul meu suhosin logheaza default in /var/log/messages. Pentru alte optiuni se poate studia link-ul de configurare suhosin

Cel mai bine este sa-l lasam 2-3 zile in modul de simulare iar dupa verificarea alertelor (grep ALERT /var/log/messages) sa adaugam in whitelist scripturile care stim ca nu sunt vulnerabile.

Pentru alte detalii, nelamuriri si propuneri  legate de suhosin va stau la dispozitie.
Succes !

[Gupi]

cpanel tuseste la asa ceva ?

(musai tre' sa-mi fac drum cu niste beri la CJ)

[Tomoiaga]

Nu are treaba cpanelu cu Suhosin, cel putin nu am intampinat nici o problema pana acum (il folosesc de 1 saptamana).

[bassul]

Daca se poate public ce fel de alert-uri ai intalnit pana acum?
( ma intereseaza mai mult din care clasa de la features )

[Tomoiaga]

Sigur ca se poate.

Alerta la includerea unui fisier de pe un domeniu pe altul:

Cod: [Selectează]

suhosin[11789]: ALERT-SIMULATION - Include filename ('http://www.exemplu.ro/index.php') is an URL that is not allowed (attacker '123.234.12.34', file '/home/user/public_html/fisier.php', line 13)
Alerta la request GET prea mare:

Cod: [Selectează]

suhosin[10770]: ALERT-SIMULATION - configured GET variable value length limit exceeded - dropped referer (attacker '123.234.12.34', file '/home/user/public_html/fisier.php')
Alerta la "new line" in headere mail:

Cod: [Selectează]

suhosin[21397]: ALERT-SIMULATION - mail() - double newline in headers, possible injection, mail dropped (attacker '123.234.12.34', file '/home/user/public_html/fisier.php', line 53)
Alerta la POST prea mare (aici am avut 200 inregistrari de la acelasi IP):

Cod: [Selectează]

suhosin[17682]: ALERT-SIMULATION - configured POST variable limit exceeded - dropped cid[] (attacker '123.234.12.34', file '/home/user/public_html/fisier_ce_nu_exista.php')

Alerta caracter NULL in req. :

Cod: [Selectează]

suhosin[30527]: ALERT-SIMULATION - ASCII-NUL chars not allowed within request variables - dropped submit (attacker '123.234.12.34', file '/home/user/public_html/fisier.php')

Alerta incercari de a realiza nimic in viata:

Cod: [Selectează]

suhosin[11982]: ALERT-SIMULATION - tried to register forbidden variable '_REQUEST[option]' through GET variables (attacker '123.234.12.34', file '/home/user/public_html/index.php') (aici au fost _REQUEST si GLOBALS)

Cam acestea au fost cele mai multe pana acum. Motivul pentru care am insistat pe simulare mai intai e din cauza ca multe alerte au provenit si de la scripturi ce erau OK, de exemplu la mail "new line" in headere (scriptul avea linie noua in headere dar era pusa direct in script nu provenea de la request), de aceea le-am adaugat in whitelist iar clientii anuntati. In tot binele este si un mic rau. Trebuie urmarit cateodata sa nu suparam clientii cu blocari la sange.
Oricum consider ca Suhosin este excelent daca se configureaza corect.
Pe langa ce am intalnit eu mai exista multe filtre si cel mai probabil am sa le testez zilele urmatoare.

[dt]

Super topic-ul, felicitari!

O intrebare: Zend Optimizer mai functioneaza dupa ce incarci suhosin? Stiu ca de obicei refuza sa ruleze daca mai e incarcata alta extensie necunoscuta.

[Tomoiaga]

Am Zend-ul instalat, nu am intampinat probleme. O sa instalez suhosin pe inca un server unde mai am Zend si am sa te anunt daca apare ceva. Dar pana acum a mers bine si avand in vedere ca e viitorul PHP Hardening Patch nu cred ca o sa-i comenteze ceva lui Zend

[Gupi]

Odata cu instalarea, se simte ceva diferenta la incarcare de masina ?

[Tomoiaga]

Nu am observat mai nimic. Au si ei un benchmark
Eu am versiunea doar cu EXT fara Patch

[etp.ro]

cateva chestii in plus:

nu functioneste cu versiunile mai vechi de eaccelerator (puneti ultimu rc de la eaccelerator si va merge)

chiar si in simulation mode poate crea mici problemute. Scrie la ei pe site ca tot ce tine de transparent ecryption NU este simulat. Deci se face criptarea sesiunilor si a cookie-urilor. Nu am sapat prea mult la asta, dar lasate pe ON intra in conflict cu 2 reguli de baza din mod_security, adica alea care dau voi ca in sesiuni sa fie numai caractere a-z si cifre. Ca workaround ori dati disable in php.ini la tot ce tine de criptare facuta de suhosin, ori adaugati niste caractere la cele allowed in sessid. (am observat ca - (minus) apare in sessid)

[Tomoiaga]

Folosing Suhosin se pot restrictiona functi php ca "exec()" in functie de domeniu.
Astfel daca un client are neaparat nevoie de functia exec(), passthru() sau altele iar in php.ini aceste functii sunt restrictionate, suhosin este o solutie.

Pe scurt:
Adaugam in php.ini suhosin.executor.func.blacklist = "exec,passthru,shell_exec" si alte functii pe care dorim sa le restrictionam (se pot copia cele de la disable_functions) si stergem fara frica, daca exista, suhosin.executor.func.whitelist.
Tot din php.ini, disable_functions nu trebuie sa aiba nici o valoare si prin urmare stergem functiile existente.

Astfel avem functiile php adaugate la suhosin.executor.func.blacklist restrictionate. Daca dorim sa dam acces la o anumita functie unui client(pentru un domeniu sau subdomeniu), in httpd.conf unde avem definit VirtualHost pentru acel client in functie de versiunea php instalata adaugam php_admin_value suhosin.executor.func.blacklist = "passthru,shell_exec". In exemplul de mai jos presupunem ca avem instalat php5 pe server si dorim sa dam acces clientului la functia exec()

Cod: [Selectează]

<VirtualHost 127.0.0.1>
...........
...........
<IfModule mod_php4.c>
php_admin_value open_basedir "/usr/lib/php"
</IfModule>
<IfModule mod_php5.c>
php_admin_value open_basedir "/usr/lib/php"
 php_admin_value suhosin.executor.func.blacklist = "passthru,shell_exec"
</IfModule>
.......
......
</VirtualHost>

Mai sus am redefinit suhosin.executor.func.blacklist cu o valoare ce nu contine functia dorita de client !

[Tomoiaga]

Odata cu versiunea 0.9.20 se pare ca a aparut un bug astfel ca nu se mai poate suprascrie suhosin.executor.func.blacklist.
Solutia, pentru cei ce folosesc suhosin e sa ramana la 0.9.18.
Nu am testat 0.9.19, poate e ok.