cxx.php shell protectie? cum?

[ionut_pe_net]

Salut,

Ce posibilitati de protejare a unui server exista impotriva rularii shelurilor de genul c99 .php ?

[Gupi]

Primul pas ar fi sa dezactivezi o serie de functii PHP: exec(), shell_exec(), popen(), passthru()
 

[ionut_pe_net]

disable_functions   show_source, system, shell_exec, passthru, exec, popen, proc_open, allow_url_fopen

c99 functioneaza in continuare fara probleme...

[Tomoiaga]

ce a scris gupi e ok, era pentru inceput. c99 shell cu functiile blocate nu are cum sa ruleze fara probleme decat anumite parti din el. In plus, sa nu blochezi functiile din htaccess, trebuie direct din php.ini sau conf apache.
Plus, open_basedir, plus suhosin care blocheaza tot scriptul daca exista exec sau alta functie plus multe alte setari.
Unele lucruri nu pot sa fie blocate pentru ca "strica" restul site-urilor.
As continua prin aruncarea cu noroi in php si programatorii ce se ocupa de intretinerea php-ului (cati au mai ramas din ei, multi buni au cam plecat, aia ce au mai ramas se ocupa de bloguri in loc sa-si dreaga problemele puerile).
As lovi si in Linux care sunt convins ca o sa ajunga la limita curand (pentru ca nu poate sa mai mearga asa) dar aici am ajunge la un thread de zeci de pagini.
E o discutie lunga si probabil fara sens, blocheaza functiile si pune open_basedir.

[ionut_pe_net]

Pare destul de stufoasa treaba asta...

Personal inca nu am vazut la nimeni in phpinfo restrictiile necesare.

Mai este si alta posibilitate de restrictionare? sau ma bazez doar pe backupuri zilnice, loguri multe si spirit de observatie.. ?

[dt]

Personal inca nu am vazut la nimeni in phpinfo restrictiile necesare.

Poate era blocata si functia phpinfo?

[petrescs]

O parere personala, usor offtopic: "hosting" face si un motel sordid care inchiriaza camere cu ora si apoi isi astupa ochii/urechile la orice s-ar auzi din spatele usilor; tot hosting face si un hotel reputabil care verifica mai intai niste carduri sau pasapoarte si care are ochi si urechi peste tot sa nu se intample nimic dubios care i-ar stirbi reputatia.

Vorbesc din punctul de vedere al unui client al vostru care ar vrea sa fie sigur ca in "hotelul" unde sta nu sunt gazduiti si indivizi dubiosi care au prin geamantane ceva root-kituri, webshelluri si alte jucarii periculoase.

Si acum de-a dreptul off-topic (poate mutam asta in alt thread):

As lovi si in Linux care sunt convins ca o sa ajunga la limita curand (pentru ca nu poate sa mai mearga asa) dar aici am ajunge la un thread de zeci de pagini.

WTF ?!? Care limita ?!? Departe de mine sa incep un flame-war, chiar sunt curios care ar fi argumentele unui hoster pentru aceasta afirmatie.

Si macar 2-3 randuri on-topic: Daca nu se poate securiza eficient un shared fara a incapacita partial sau total posibilele aplicatii gazduite, poate macar exista ceva utilitare de monitorizare (pasiva sau activa) a incercarilor de apelare a unor functii periculoase, cum ar fi includerea de cod de la un url extern. Poate un IDS ca Snort, sau macar un logcheck care sa trimita zilnic la sysadmin un rezumat cu accesarile dubioase. Gasit probe clare -> inchis contul fara avertisment.

[ionut_pe_net]

Poate un IDS ca Snort, sau macar un logcheck care sa trimita zilnic la sysadmin un rezumat cu accesarile dubioase. Gasit probe clare -> inchis contul fara avertisment.

Problema este ca nu mai apuci sa primesti nici un log cu nimic si nici vreun cont de blocat daca ai ghinionul sa ai un client pus pe fapte rele...

[Tomoiaga]

cand am spus ca nu mai poate sa mearga asa ma refeream la modul general. Prin limita ma refer la limita de timp in care o sa mai fie foarte folosit. Argumente cred ca am mai avut si mai demult cand am avut discutii de cateva pagini. Oricum este o parere si nu am timpul necesar sa intru in toate detaliile acum. Ca sa nu mai intram la securitate. Rapid si din avion Apache si php ca si tema de gandire unde Apache arunca cu noroi in php si php in Apache. Am mai avut odata discutiile acestea.

[petrescs]

@Ionut_pe_net: Asta ar insemna ca majoritatea shared-urilor erau desfiintate pana acum de "teroristi"; inteleg ca nu exista un silver-bullet in cazurile astea, dar niste best practices pentru o securizare decenta a unui shared trebuie sa existe (m-ar interesa si pe mine, cu toate ca am inceput usor-usor sa migrez pe vps si dedicat).

@TC: Agree - apache si php nu prea coopereaza decat daca le rogi frumos (mai ales pe un shared banuiesc ca trebuie adevarate jonglerii ca sa nu ti le dea jos primul user mai hotarat). Stiu si ca IIS a facut progrese mai ales de la v6 si ii cam sufla in ceafa indianului. Nu intelesesem insa de ce e Linuxul vinovat, ma gandeam ca poate i s-a anuntat EOL si mi-a scapat :-)

[ionut_pe_net]

Daca aveam un cont shared " ma durea in cot " de ce se intampla... problema am testato pe 3 conturi shared + un cont reseller pe servere din state (firme diferite),fara a cauza daune, doar de curiozitatea de a vedea ce "masuri de siguranta" si-au luat altii.
Peste tot a fost exact asa cum m-am si asteptat.. adica nici o masura de siguranta .

In Ro. nu am conturi de gazduire, deci nu pot sa imi dau cu parerea despre nimeni.

[dt]

.. doar de curiozitatea de a vedea ce "masuri de siguranta" si-au luat altii.
Peste tot a fost exact asa cum m-am si asteptat.. adica nici o masura de siguranta .

Nimeni nu e perfect .. totusi faptul ca a rulat un shellscript in php nu inseamna ca nu erau luate masuri de siguranta. Ce scria la user? (whoami) E posibil sa fi rulat PHP-ul ca cgi si atunci restrictiile erau altele (user fara prea multe drepturi, evential jailshell). Orium, prefer varianta descrisa de Gupi si Tomoiaga.

[Andrei G.]

c99.php ajunge in server de obicei prin inconstienta utilizatorului care nu are grija de userul si parola sa.

[Marian]

disable_functions = "dl,passthru,proc_get_status,proc_nice,proc_open,proc_terminate,proc_close,popen,exec,shell_exec,system"

si fopen wrappers:

allow_url_fopen = Off
allow_url_include = Off

Asta in caz ca nu le folosesti (functiile sau wrapperele)

Ar fi indicat sa instalezi mod_security pe httpd ; cu siguranta stie sa faca deny la scripturile acelea facute de idioti.

Ca masura de securitate in plus, faci remount la partitii cu acl si poti seta reguli stricte cu setfacl pentru userul sub care ruleaza httpd-ul. (binare, etc)

[Andrei G.]

disable_functions = "dl,passthru,proc_get_status,proc_nice,proc_open,proc_terminate,proc_close,popen,exec,shell_exec,system"

si fopen wrappers:

allow_url_fopen = Off
allow_url_include = Off

Asta in caz ca nu le folosesti (functiile sau wrapperele)

Ar fi indicat sa instalezi mod_security pe httpd ; cu siguranta stie sa faca deny la scripturile acelea facute de idioti.

Ca masura de securitate in plus, faci remount la partitii cu acl si poti seta reguli stricte cu setfacl pentru userul sub care ruleaza httpd-ul. (binare, etc)

Daca dai disable la allow_url_fopen moare tot ce tine de include() si require() can nasol pentru mediul ca hosting ca lumea foloseste aceste 2 functii.

Daca dai disable la proc_get_status,proc_nice,proc_open,proc_terminate,proc_close nu mai merge Web Shell pentru cai care il folosesc.

nasole sunt internetele astea.