Administrare server open source

Platforma de hosting cu software liber, gratuit, open source.

Comentariile sunt închise pentru De ce NU folosesc mod_userdir

De fiecare data cand am de pregatit un server web pentru un client stau cu el la o discutie sa pregatim prima data pe hartie feature-urile serverului care urmeaza sa fie lansat. De foarte multe ori intra in discutie mod_userdir, un modul apache care permite oricarei persoane care are un cont pe server web sa isi tina propriul site in public_html fara a fi necesara crearea unei zone virtuale. Daca pe un server cu adresa IP 12.34.56.78 e instalat mod_userdir, un utilizator care are numele de utilizator lamp va putea sa isi acceseze siteul introducand in browser adresa:

http://12.34.56.78/~lamp

Rezultatul va fi continutul directorului public_html din directorul de baza (homedir) al utilizatorului. Util, nu-i asa?

Instalarea mod_userdir nu e complicata si pe langa liniile LoadModule si AddModule singura setare o reprezinta urmatoarele trei linii:

<ifmodule mod_userdir.c>
    UserDir public_html
</ifmodule>

Simplitatea configurarii ii determina pe multi sysadmini sa instaleze modulul si sa il foloseasca. Este util in diverse situatii din care amintesc doar doua. Prima situatie in care e util e existenta unui cont in sistem care nu are asociat niciun domeniu sau subdomeniu dar care poate fi folosit pentru a rula diverse aplicatii pentru statistici (ex. http://12.34.56.78/~sysadmin/server-load.php). Este un truc util care poate fi folosit pentru a evita crearea unui subdomeniu care poate fi aflat cu usurinta folosind comanda „dig„. A doua situatie in care mod_userdir poate fi util e cazul clientilor care vor sa isi verifice siteurile inainte sa schimbe nameserverele domeniului sau sa le verifice inainte ca propagarea inregistrarii domeniului nou sa fie finalizata. Astfel, utilizatorul va putea sa isi verifice siteul accesand adresa http://12.34.56.78/~utilizator/ si va putea sa vada daca aplicatia instalata functioneaza corect. Ca alternativa la mod_userdir in aceasta situatie ar fi editarea fisierului /etc/hosts pe Linux sau C:\Windows\system32\drivers\etc\hosts pe Windows in care se pot face modificari pentru a forta asocierea unui domeniu cu un anumit IP.

Pe langa cele doua exemple utile ale mod_userdir exista cateva motive pentru care modulul nu e recomandat. Un exemplu ar fi imposibilitatea de a monitoriza traficul web creat de un anumit cont. Daca un utilizator isi va introduce in site imaginile folosind ca si adresa IP-ul serverului (ex. http://12.34.56.78/~utilizator/rezolutie-mare.png), traficul facut de acel utilizator nu va fi contorizat. Implicit va putea face foarte mult trafic fara ca administratorul serverului sa observe asta si fara ca cPanel sa ii suspende contul pentru depasire de trafic. Presupunand ca un astfel de utilizator are un spatiu mare alocat, va putea intr-un timp foarte scurt sa consume intreaga banda alocata serverului fara ca administratorul acelui server web sa poata face ceva. Problema traficului este deranjanta dar in comparatie cu problema securitatii care o ridica instalarea mod_userdir, problema traficului nu este altceva decat un moft.

Sa presupunem ca pe site exista 500 de conturi iar o persoana rau intentionata intentioneaza sa sparga unul din siteuri. Sa presupunem ca va incerca sa injecteze diferite valori in fisierul de autentificare a siteului, autentificare.php. Administratorul siteului sau a serverului pot observa acest atac urmarind logurile. In cazul in care atacul reuseste iar o investigatie este lansata se pot afla cu usurinta datele atacatorului. Totusi, in cazul in care serverul are instalat mod_userdir problema se complica. Sa presupunem ca siteul atacat este exemplu.ro care este gazduit in contul utilizatorului „exemplu” iar pe acelasi server web e gazduit si siteul exempluproxy.ro. Raufacatorul va putea accesa fisierul autentificare.php din siteul exemplu.ro accesand fisierul cu prin cadrul siteului exempluproxy.ro pentru ca mod_userdir functioneaza la nivel de server. Astfel fisierul autentificare.php in loc sa fie accesat ca http://exemplu.ro/autentificare.php va fi accesat ca http://exempluproxy.ro/~exemplu/autentificare.php. Acum atacatorul poate incerca oricate combinatii de variabile si valori fara ca cineva sa-i poata da de urma pentru ca logurile nu vor mai fi salvate in fisierul corespunzator domeniului exemplu.ro ci in fisierul domeniului exempluproxy.ro care in cazul de fata nu va prezenta niciun interes pentru administratorul serverului.

O situatie mai grava o reprezinta atacurile de tip XSS. Se stie ca o vulnerabilitate de tip XSS intr-un site poate fi exploatata pentru ca un raufacator sa aiba acces la datele de conectare ale unui utilizator legitim, de obicei furand cookie-urile victimei. Daca pe server exista un site, exemplu.ro gazduit in contul utilizatorului „exemplu„, care este vulnerabil la XSS iar serverul are instalat mod_userdir site-ul exemplu.ro va putea fi folosit ca platforma de atac pentru oricare din siteurile gazduite. Daca siteul exemplu.ro are fisierul afisare.php vulnerabil XSS, acesta poate fi accesat din cadrul oricarui alt site folosind mod_userdir. Astfel putem accesa siteul http://exemplusecurizat.ro/~exemplu/afisare.php care ne va permite sa rulam un cod malitios care fura cookieurile unui utilizator in cadrul unui site in cadrul caruia s-au facut toate eforturile pentru a pastra securitatea. Cand browserul primeste cererea, observa domeniul care corespunde cookie-ului si ofera datele existente. Astfel, datorita instalarii mod_userdir, toate siteurile gazduite pe server devin vulnerabile datorita unui singur fisier dintr-un cont de hosting.

Exemple de exploatare ale modulului mod_userdir sunt multe, dar cel putin momentan cred ca am subliniat gravitatea instalarii acestui modul pe un server aflat in productie. Concluzia finala ar fi „Daca nu aveti neaparata nevoie de mod_userdir, nu il instalati sub niciun pretext!„.

Apache

Comments are closed.