ATELIER

SYSADMIN

Administrarea serverelor Web

mbuntirea securitii serverului Apache
Sabin Corneliu Buraga, Drago Acostchioaie

n cadrul acestui articol vom descrie o serie de metode pentru a mbunti securitatea serverelor Web, n special a celui mai folosit server Web din lume Apache, care potrivit statisticilor realizate de Netscraft Inc. (http://www.netcraft.com/survey) ocup n prezent peste 55% din pia.

Serverele Web i securitatea

Serverele Web au ca funcionalitate de baz recepionarea de cereri anonime de la clieni i furnizarea de informaii ntr-o manier dorit a fi eficient i rapid. n fapt, un server Web este un daemon care accept conexiuni conforme protocolului HTTP, rspunznd cererilor recepionate de la clieni. Ca i alte protocoale utilizate n Internet, protocolul HTTP (HyperText Transfer Protocol) este un protocol de tip cerere-rspuns, bazat pe TCP/IP, destinat transferurilor informaiilor hipermedia. n ordinea importanei, problemele de securitate pot fi mprite astfel: Un atacator poate exploata bug-urile (deficienele) existente ntr-un server Web sau din script-uri, obinnd acces neautorizat la fiiere vitale din sistem (fiiere de parole, fiiere coninnd surse de script-uri executate pe server i altele) sau pentru a deine controlul total asupra sistemului; Informaiile confideniale stocate pe serverul Web (e.g. baze de date, aplicaii etc.) pot fi distribuite unor persoane neautorizate; Punctele vulnerabile necunoscute ale navigatorului pot permite accesarea de informaii private stocate pe maina clientului. Din pcate, soluiile utilizate n mod curent nu pot rezolva toate problemele i, deseori, sunt contradictorii. De exemplu, pentru reducerea riscurilor de interceptare, multe organizaii achiziioneaz servere Web considerate sigure, implementnd o pleiad de protocoale de criptare, dar aceste servere necesit certificate de autentificare semnate digital care trebuie actualizate periodic.

(6) Script-urile CGI trebuie plasate ntr-un singur director (de obicei cgi-bin) i modificrile lor trebuie monitorizate. (7) n cadrul directorului cgi-bin nu se permite accesul nelimitat. Utilizatorii locali nu trebuie s poat instala, edita, terge sau chiar vizualiza script-uri sau fiiere de configurare. (8) Autorii scripturilor (CGI, PHP, ASP sau altele) nu trebuie s fac publice sursele programelor lor, mai ales dac nu sunt n variante finale, deoarece ele pot conine puncte vulnerabile nebnuite sau bug-uri periculoase. (9) Script-urile nu trebuie s poat fi preluate prin FTP anonim i nici fiierele de configurare ale serverului FTP nu trebuie accesate via WWW. (10) Se va interzice plasarea de la distan pe serverul Web a fiierelor de configurare (e.g. .htaccess n cazul Apache). Fiierele jurnal (log-urile) nu trebuie s poat fi accesate de utilizatorii ordinari sau de intrui. Hackerii pot altera sau distruge informaiile din aceste fiiere. (11) Alte msuri, mai extreme, pot fi: tergerea tuturor conturilor care nu sunt necesare; inhibarea execuiei sau tergerea compilatoarelor; tergerea programelor utilitare care nu sunt necesare pentru rularea sistemului de operare sau a serverului Web.

Configurarea serverului Apache

Pentru a asigura servicii HTTP, serverul Apache trebuie s fie instalat n sistem (n mod uzual, fiind vorba de un pachet RPM n Linux sau de un program executabil .exe n Windows), iar daemon-ul httpd pornit. Apache este un sistem modular, alctuit dintr-un server de baz i mai multe module, care sunt ncrcate dinamic ntr-un mod similar cu funcionarea modulelor din nucleul Linux. Ne vom referi n continuare la modalitile de configurare ale serverului Apache n Linux. Apache poate fi configurat cu ajutorul interfeei grafice apacheconf (vezi meniul System::Apache Configuration Tool din managerul de ferestre favorit). Fiierul de configurare principal este httpd.conf i este localizat de obicei n directorul /etc/httpd. Mai exist dou fiiere de configurare, access.conf i srm.conf, care au fost ns nlturate ncepnd cu versiunea 1.3.4. Fiierul de configurare conine cte o directiv pe fiecare linie, acestea putnd fi continuate pe linia urmtoare adugnd la sfritul acesteia caracterul \. Comentariile ncep cu caracterul # (ca n shell-urile Unix). Directivele din fiierul principal de configurare se refer la configurri globale ale serverului. Pentru a aplica anumite aspecte ale serverului doar unei zone din server, directivele trebuie incluse n cadrul seciunilor <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location> sau <LocationMatch>. Acest lucru poate fi realizat i prin plasarea unui fiier denumit .htaccess n directorul n care se dorete modificarea comportamentului serverului, coninnd directivele dorite. De asemenea, Apache ofer posibilitatea de a servi mai multe situri Web simultan, altfel spus, gzduire virtual (virtual hosting).

Sfaturi generale
Furnizm n continuare o serie de sfaturi pentru creterea nivelului de securitate a unui server Web (oricare ar fi acesta): (1) Pe ct posibil, un server Web nu trebuie s ruleze alte servicii i s nu accepte conexiuni de la distan (dac deservete un Intranet); preferabil ar fi ca daemon-ul de pot electronic s nu fie operaional; (2) Serverul Web nu trebuie s ruleze sub auspicii de super-utilizator (root n Unix/Linux). La fel, script-urile CGI (Common Gateway Interface) nu trebuie executate ca root. (3) Fiierele de configurare i modulele serverului nu trebuie stocate pe o partiie care poate fi exportat prin NFS ctre alte maini. (4) Permisiunile ataate fiierelor de configurare ale serverului Web trebuie setate i monitorizate cu atenie. (5) Se va limita sau chiar inhiba execuia directivelor SSI (Server Side Includes). 61 NET REPORT iulie 2002

ATELIER
SYSADMIN
Directivele pot fi specificate n cadrul seciunii <VirtualHost>, caz n care se vor referi doar la un anumit sit. Pentru alte detalii privind directivele Apache, cititorul interesat poate consulta referinele bibliografice. Administratorul de sistem are, de asemenea, posibilitatea de a configura fiierele jurnal Apache. Serverul genereaz dou jurnale: primul, localizat n genere n /var/log/httpd/access_conf, nregistreaz cererile de accesare primite de ctre server, iar al doilea, localizat de obicei n /var/log/httpd/error_log, memoreaz erorile aprute n decursul rezolvrii cererilor (pagini inexistente, erori de conexiune etc.). Aceast linie ne permite s asignm sau s modificm parola unui utilizator, parola fiind solicitat de la intrarea standard. Configurarea serverului se poate realiza fie prin fiierul httpd.conf, fie prin .htaccess, indicnd o zon protejat, de obicei n funcie de directoarele dorite a fi accesate pe baz de autentificare. Fiierul .htaccess va fi stocat n directorul asupra cruia dorim s modificm comportamentul implicit al serverului Web (plasarea lui ntr-un anumit director va avea efect asupra tuturor sub-directoarelor acestuia). nainte de a modifica maniera de autentificare prin fiierul .htaccess, administratorul serverului Apache va specifica n httpd.conf ca autentificrile s se realizeze via .htaccess. Pentru aceasta, vom insera directiva AllowOverride AuthConfig, iar fiierul .htaccess poate avea liniile de mai jos:
AuthName "zon restrictiv" AuthType Basic AuthUserFile /etc/httpd/users require valid-user

Configurarea accesului la paginile Web

n anumite cazuri, este necesar s se restricioneze accesul la anumite documente, prin intermediul autentificrii prin nume de utilizator i parol sau n funcie de adresa calculatorului clientului Web. Autentificarea. Pentru a realiza autentificarea utilizatorilor, vom parcurge doi pai: (1) Se creeaz un fiier coninnd numele i parolele utilizatorilor care vor avea acces la anumite date de pe serverul Web (n particular Apache); (2) Se configureaz serverul pentru a seta care resurse vor fi protejate i care sunt utilizatorii avnd permisiunea accesrii lor, dup introducerea unei parole valide. Lista utilizatorilor i parolelor asociate va fi memorat ntr-o manier similar fiierului /etc/passwd din Unix. Din raiuni de securitate, fiierul coninnd aceast list nu va fi stocat n directoarele compuse din documente HTML, ci la o locaie mai sigur (e.g. n directoarele /usr/local/etc/httpd sau /etc/httpd). n exemplele urmtoare, vom numi acest fiier users, iar pentru a-l manipula vom folosi comanda htpasswd prin care vom aduga/terge utilizatorii dorii. Dei parolele sunt criptate, fiierul de autentificare este unul text, care poate fi uor exploatat de persoane ru-voitoare. Rmne n responsabilitatea administratorului sistemului s seteze permisiunile de rigoare asupra fiierului i directorului unde rezid. Crearea unui fiier de autentificare se realizeaz prin apelul de mai jos (putem stabili i modul de criptare, de exemplu MD5 cu opiunea -m sau SHA cu opiunea -s):
htpasswd -c /etc/httpd/users busaco

Autentificarea unui utilizator pentru a accesa o zona protejat

unde: AuthName specific zona dorit a fi protejat i oricare resurs din aceast zon va fi accesat prin intermediul unui nume de utilizator permis i o parol (putem crea mai multe zone partajnd aceleai nume i parole). AuthType desemneaz metoda de autentificare folosit de protocolul HTTP (Basic sau metoda, mai sigur, Digest; serverul Apache suport metoda Digest prin adugarea unui modul special). AuthUserFile indic fiierul de autentificare generat de htpasswd. Autentificarea se poate institui i pe baza grupurilor de utilizatori, folosindu-se AuthGroupFile (vezi mai jos). Utilizatorii permii vor fi dai dup directiva require. Parametrul valid-user indic faptul c orice nume de utilizator prezent n fiierul furnizat de AuthUserFile poate accesa resursele protejate, dar putem scrie o serie de nume de utilizatori permii (e.g. require user busaco dragos care va permite accesul numai utilizatorilor busaco sau dragos, desigur dup ce s-au introdus parolele corecte). De exemplu, pentru a permite accesul n directorul /Web pe baza autentificrii, vom plasa fiierul .htaccess urmtor (n /home/httpd/ html/Web presupunnd c directorul rdcin al sitului Web este localizat n /home/httpd/html/):
AuthName "Numai pentru autorul cursului" AuthType Basic AuthUserFile /etc/httpd/users require valid-user

Atunci cnd un utilizator va dori s viziteze o pagin stocat n acel director, va trebui s furnizeze un nume i o parol de acces (dac numele sau parola nu coincid cu cele din fiierul /etc/httpd/users, autentificarea va eua). Vezi i figura Autentificarea unui utilizator pentru a accesa o zon protejat. Mecanismul general este urmtorul: la primul acces al unei resurse necesitnd o autentificare, serverul va returna codul 401 (Unauthorized) i va include n antetul HTTP un cmp WWW-Authenticate care va conine schema de autentificare ce trebuie utilizat (de exemplu, Basic) i numele zonei protejate (aa-numitul realm). Navigatorul va cere utilizatorului introducerea unui nume i a unei parole i va realiza o cerere ctre server, incluznd i cmpul Authorization care va conine numele schemei de autentificare (Basic), plus numele i parola furnizate. Serverul va realiza verificarea pe baza fiierului de configuraie sau a fiierului .htaccess i n caz de succes va expedia resursa cerut browserului. Altfel, va fi trimis din nou codul 401. iulie 2002 NET REPORT 62

ATELIER
SYSADMIN
n situaia n care autentificarea s-a soldat cu succes, iar utilizatorul va dori s vizualizeze o alt resurs aparinnd aceleai zone protejate, atunci serverul va rspunde cu codul 401 i navigatorul va retrimite, de fiecare dat, cmpul Authorization. Grupuri de autentificare. Atunci cnd trebuie autentificai mai muli utilizatori, se poate folosi un fiier specificnd autentificarea pe baza unui grup de utilizatori (concept similar grupurilor din Unix). Iat un exemplu:
require group webgroup admin require user webadmin

Se va permite accesul oricrui utilizator din grupul webgroup sau admin ori utilizatorului cu numele webadmin. Un fiier de grup const din linii desemnnd grupurile i membrii acestora, sintaxa general fiind:
grup: utiliz1 utiliz2 ... utilizN

Numai utilizatorii dragos sau socrate vor putea realiza o cerere prin metoda POST, ali utilizatori (neautentificai) vor utiliza alte metode (i.e. GET). Aceast manier poate fi adoptat la restricionarea accesului la un script CGI (se permite metoda GET, dar numai anumii utilizatori pot folosi POST). Restricionarea pe baza adresei clientului. Accesul la resurse (directoare sau fiiere) se poate face pe baza adresei IP sau a domeniului clientului care a formulat cererea de acces. n acest caz, se poate include ntre <Limit> i </Limit> (n .htaccess sau n fiierul de configuraie a serverului Apache) intervalul de valori ale adreselor IP permise. Cererile de la alte adrese vor fi rejectate. Un exemplu:
<Limit GET POST PUT> order deny, allow deny from all allow from 193.231.30.0/24 192.168.0.0/16 </Limit>

De exemplu, putem avea:

webgroup: busaco dragos mihaela stanasa stefan admin: diablo socrate

O linie nu poate avea mai mult de 8 KB lungime. n .htaccess fiierul de grupuri de utilizatori va fi dat prin GroupFile. De exemplu, .htaccess ar putea conine:
AuthName "Numai pentru membrii WebGroup-ului" AuthType Basic AuthUserFile /etc/httpd/users AuthGroupFile /etc/httpd/webgroup require group webgroup require user busaco

Auth-

Directiva deny stabilete adresele sau domeniile care nu au permisiunea de acces la resurse, iar allow definete adresele sau domeniile de la care clienii pot accesa resursele Web. n exemplu, am specificat un set de adrese IP permise. Ordinea de verificare a restriciilor de acces este dictat de directiva order. Pentru a permite accesul clienilor Web care nu fac parte din domeniul .infoiasi.ro, dar care pot proveni din oricare alt domeniu, vom introduce urmtoarele:
<Limit GET> order allow, deny allow from all deny from .infoiasi.ro </Limit>

Dac se furnizeaz numele unui utilizator care exist n cadrul unui grup, dar cruia nu i s-a asociat nici o parol n fiierul de autentificare a utilizatorilor, atunci acel utilizator nu va avea acces n zona restrictiv. n situaia n care numrul de utilizatori crete destul de mult, se pot utiliza metode complementare, precum stocarea informaiilor de autentificare n baze de date: fiiere DBM (modulul mod_auth_dbm), DB (mod_auth_db), mSQL (prin mod_auth_msql) etc. Autentificrile se pot realiza via Kerberos prin utilizarea unor module adiionale n cadrul serverului Apache. Limitarea accesului. Putem restriciona folosirea metodelor de interogare HTTP prin intermediul seciunii <Limit>:
<Limit GET POST PUT> require valid-user </Limit>

Astfel, autentificarea se poate realiza n funcie de metodele de acces HTTP. Dac require nu apare ntre <Limit> i </Limit>, protecia se va aplica la toate metodele. n cazul n care dorim s limitm restricia doar la metoda POST, vom putea scrie n .htaccess urmtoarele:
AuthName "POST restrictiv" AuthType Basic AuthUserFile /etc/httpd/users <Limit POST> require user dragos socrate </Limit>

Restricionarea combinat. Dup cum am vzut mai sus, accesul poate fi restricionat i pe baza adresei IP sau domeniului calculatorului client. Putem utiliza, n mod combinat, ambele metode. Dac dorim ca accesul s se realizeze fie pe baza domeniilor permise, fie folosind autentificarea prin nume i parol, vom include directiva Satisfy any n fiierul .htaccess sau n seciunile <Directory>, <Location> ori <Files> ale fiierului de configurare. Dac apar ambele metode de restricionare (pe baza adreselor clienilor i pe baza autentificrii), n mod implicit serverul Web impune s fie ndeplinite amndou. Redirectri. n unele cazuri ar fi dorit ca, la apariia unor erori HTTP, vizitatorii s fie redirectai spre anumite documente particulare. Implicit, la o eroare, serverul Web va transmite navigatorului o pagin descriind codul i mesajul de eroare. Putem specifica s fie transmise alte documente clientului, atunci cnd survin erori de genul 401 (Unauthorized), 403 (Forbidden), 404 (Not found) sau 500 (Server Error). Pentru aceasta, se pot include n .htaccess liniile de mai jos:
ErrorDocument 401 /Web/not_auth.html ErrorDocument 404 /Web/not_found.html

Astfel, atunci cnd un anumit utilizator va cere o resurs inexistent, serverul va trimite documentul not_found.html din directorul /Web. Putem folosi, n locul unui document local, un anumit URI (Uniform Resource Identifier) spre care s fie redirectat navigatorul. Aceasta ne permite s redirectm automat navigatorul atunci cnd am mutat definitiv o resurs la alt URI (sau n alt director, aflat pe acelai server). Va trebui s introducem n vechiul director un fiier .htaccess care s cuprind urmtoarele:

63 NET REPORT iulie 2002

ATELIER
SYSADMIN
<Limit GET POST> deny from all ErrorDocument 403 /un_alt_director/index.html </Limit> DocumentRoot /usr/web/dragos </VirtualHost>

De asemenea, n httpd.conf putem utiliza directiva RedirectPermanent pentru a redirecta navigatorul spre un nou URI:
RedirectPermanent /~catam http://www.infoiasi.ro/~catam/

De asemenea, pentru fiecare main virtual pot fi stabilite mai multe nume, utiliznd directiva ServerAlias. Astfel, dac se introduce declaraia:
ServerAlias dragos.ro *.dragos.ro

Pentru crearea alias-urilor, se va folosi directiva alias:

Alias /webgroup /home/others/webgr/html

Alias /webgroup/ /home/others/webgr/html

n exemplul urmtor putem urmri utilizarea alias-urilor mpreun cu directivele de restricionare a accesului pe baza adreselor IP:
Alias /books /home/ftp/pub/books <Directory /home/ftp/pub/books> Options Indexes SymLinksIfOwnerMatch AllowOverride none order deny, allow deny from all allow from 193.231.30.0/24 192.168.0.0/16 </Directory>

cererile pentru mainile din domeniul dragos.ro vor fi rezolvate de maina virtual www.dragos.ro. Pot fi folosite caracterele wildcard * i ?. Evident, i nregistrrile DNS (Domain Name System) pentru serviciul named trebuie s fie corect configurate pentru ca adresele *.dragos.ro s poat fi rezolvate. Gzduirea virtual bazat pe adresa IP. Pentru utilizarea acestui tip de gzduire, maina trebuie configurat fie pentru a avea mai multe conexiuni fizice la reea, fie pentru a avea mai multe interfee virtuale, avnd adrese IP diferite. Serverul Apache poate fi configurat n dou moduri: s execute cte un daemon pentru fiecare main virtual. Pentru aceasta, se utilizeaz directiva Listen pentru a stabili ce adres IP va fi asociat daemonului; s execute un singur daemon pentru toate mainile virtuale. Pentru aceasta, se utilizeaz directiva VirtualHost descris mai sus. Sabin-Corneliu Buraga este doctorand n Computer Science la Facultatea de Informatic, Universitatea Al.I.Cuza din Iai i poate fi contactat la busaco@infoiasi.ro. Drago Acostchioaie este programator de sistem i aplicaii Linux, administrator de reea la firma BIOSFARM din Iai, putnd fi contactat la adresa dragos@biosfarm.ro. n 98

Astfel, resursele din directorul /home/ftp/pub/books vor putea fi accesate prin intermediul URI-ului http://nume_server/books numai de mainile de la adresele IP specificate n exemplu.

Gzduirea virtual
Exist dou metode de implementare a gzduirii virtuale: prima bazat pe nume i a doua bazat pe adrese IP. Mainile virtuale bazate pe adres utilizeaz adresa IP a conexiunii pentru a determina maina virtual corect. Astfel, pentru fiecare main trebuie alocat o adres IP separat. n cazul gzduirii virtuale bazate pe nume, determinarea mainii virtuale se face pe baza numelui acesteia. Astfel, mai multe maini pot utiliza aceeai adres IP. Gzduirea virtual bazat pe nume este mai simplu de implementat, i este recomandat utilizarea acesteia. Gzduirea bazaz pe adres trebuie utilizat doar ntr-una din situaiile: trebuie suportai clieni HTTP vechi, care nu recunosc mainile virtuale; sunt necesare conexiuni sigure de tip SSL (Secure Socket Layer); sunt utilizate sisteme de operare care nu pot diferenia mainile dect dac au adrese IP diferite. Gzduirea bazat pe nume. Pentru a utiliza serviciul de gzduire virtual, trebuie mai nti stabilite adresa IP i portul pentru serverul care va accepta cereri pentru respectiva main virtual, cu ajutorul directivei NameVirtualHost. n mod normal, se utilizeaz toate adresele IP pe care le utilizeaz httpd (vezi directivele BindAddress i Listen), precum i toate porturile pe care serverul ateapt cereri (vezi directiva Port), folosind valoarea *. Se stabilete apoi un bloc <VirtualHost> </VirtualHost>. Ca parametru, <VirtualHost> trebuie s primeasc aceeai valoare utilizat la directiva NameVirtualHost. Blocul astfel declarat trebuie s conin cel puin directivele ServerName, care s primeasc drept parametru numele mainii virtuale, i DocumentRoot, care s specifice n ce director se afl coninutul respectivei maini. Iat un exemplu:
NameVirtualHost * <VirtualHost *> ServerName www.dragos.ro

Referine bibliografice
! D. Acostchioaie, Administrarea i configurarea sistemelor Linux, Editura Polirom, Iai, 2002:
http://www.biosfarm.ro/~dragos/admin

! S. Buraga, Tehnologii Web, Editura Matrix Rom, Bucureti, 2001: http://www.infoiasi.ro/~busaco/books/web.html ! R. Fielding et al. (eds.), Hypertext Transfer Protocol HTTP/1.1, RFC 2068, IETF, 1997: http://www.ietf.org/rfc/rfc2068.txt ! J. Franks et al., HTTP Authentication: Basic and Digest Access Authentication, RFC 2617, IETF, 1999:
http://www.ietf.org/rfc/rfc2617.txt

! G. Holden, N. Wells, M. Keller, Apache Server Commentary, The Coriolis Group, 1999 ! G. Mourani, Securing and Optimizing Linux: Red Hat Edition, OpenDocs Publishing, 2000: http://www.openna.com ! V.V.Patriciu et al., Securitatea informatic n UNIX i Internet, Ed.Tehnic, Bucureti, 1998 ! * * *, Apache HTTP Server Documentation:
http://httpd.apache.org/docs

! * * *, Apache Week: http://www.apacheweek.com ! * * *, The Official Red Hat Linux Reference Guide, Red Hat Inc., Durham, 2001 iulie 2002 NET REPORT 64