302

SECURITATEA SERVERELOR WEB prep.univ.ing. Antoniu Nicula Universitatea din Oradea, Facultatea de Electrotehnic i Informatic, Str. Armatei

Romne nr.5, Oradea, telefon: 0744-671345, e-mail: tony@maxiq.ro

prep.univ. Adrian Nicula Universitatea din Oradea, Facultatea de tiine Economice, Str. Armatei Romne nr.5,

Oradea, telefon: 0740-158724, e-mail: anicula@uoradea.ro

In this paper we tried to explain how web servers are working, as well as some problems that has to be

looked for in order to know the way that clients can access the data from the server.

Fcnd o descriere metaforic, un server web poate fi comparat cu un chelner dintr-

un restaurant. Chelnerul va fi serverul web, restaurantul va fi mediul n care acesta lucreaz (in special sistemul de operare), buctria restaurantului va fi sistemul de fiiere din care serverul web va alege fiierele cerute de clieni. Aceast comparaie este posibil deoarece i serverul web i chelnerul au aceeai funcie principal: aceea de a servi.

Un server web este un program care ruleaz pe un calculator, ateapt pe un port o conexiune TCP venit de la un client i servete acestuia pagini web folosind protocolul HTTP.

Schema de principiu a funcionrii unui server web

Aceast definiie este foarte principial i specific toate caracteristicile obligatorii ale

unui web server. Serverul web este un software, un program de sine stttor, un executabil cu o

funcie bine stabilit: acea de a servi la cerere pagini de Internet ntr-un mod bine determinat. Acest software poate fi: Apache HTTP Server, Microsoft Internet Information Services (IIS), iPlanet Web Server, Roxen WebServer, Zeus WebServer, s.a. Exist numeroase alte implementri de web server, cele numite mai sus ocupnd primele locuri n topul celor mai folosite servere web. Intern, procesul de funcionare al acestor programe este foarte complex, ele urmrind n special performan, securitatea i scalabilitatea. Trebuie menionat ca o aplicaie de tip web server poate fi scris n mai puin de 500 linii de cod C. Bineneles aceasta va avea o funcionare foarte limitat, dar va corespunde definiiei

303

de mai sus, aceea de a transmite pagini web (pagini HTML i imagini) ctre clieni. Aplicaiile mature, ca cele enumerate mai sus, dispun de o multitudine de funcionaliti extinse, n jurul lor opernd tehnologii precum codurile externe de generare de pagini PHP, JSP sau ASP, administrarea sesiunilor de utilizator de ctre un server de aplicaii care folosete Enterprise Java Beans (EJBs) sau Microsoft Component Object Model (COM+), extensii Microsoft FrontPage, interogri Lightweight Directory Access Protocol (LDAP) sau Microsoft Active Directory.

Fiecare server web dispune de un set caracteristic de astfel de tehnologii, care alturi de capacitatea i scalabilitatea s l individualizeaz printre celelalte produse. Alegerea unui server este de aceea puternic influenat de tehnologia pe care acesta o suport, ctig de cauza avnd de aceea probabil servere proiectate modular cum ar fi Apache, lider consacrat pe piaa serverelor web. Acest succes se bazeaz n mare parte pe faptul ca crearea de aplicaii suplimentare este influenat de ntreaga comunitate Open Source precum i datorit gratuitii i extensibilitii sale. Printre criteriile de difereniere ntre produsele existente pe pia se mai numr i instalarea, configurarea i administrarea procesului general de web-serving.

Un server web ruleaz pe un calculator. Prin calculator trebuie s nelegem platforma pe care va rula programul descris anterior. Platforma este caracterizat de hardware-l i de sistemul de operare pe care va fi instalat serverul web. Platforma hardware este n general un calculator ale crui performane ncep de la cele mai minimale pn la servere de tip mainframe. Acest calculator va fi cel mai probabil un server dedicat, conectat permanent la o reea (Intranet sau Internet). Pentru alegerea tipului de hardware dispunem de o gama foarte larg de sisteme, nsa un criteriu necesar alegerii este compatibilitatea cu softul ales ca web server. Asta deoarece serverele web sunt dependente de arhitectura pe care vor rula i mai ales de sistemul de operare instalat pe acea arhitectur. De exemplu, IIS ruleaz numai pe Windows, Zeus necesit Unix, Roxen i iPlanet ruleaz fie pe Unix, fie pe Windows, Apache se gsete ca open-source, putnd fi compilat pe o larg varietate de versiuni Unix/Linux, dar se gsete i n versiuni precompilate pentru Windows sau Mac OS X. Capacitatea de a rula pe mai multe tipuri de sisteme de operare le confer acestora o rspndire mai larg, cu toate c performanele sunt superioare n cazul rulrii pe Unix.

Aadar, ntre serverul web i sistemul de operare folosit este o legtura strnsa, alegerea unei configuraii rmnnd o problema comercial.

Un server web ateapt pe un port o conexiune TCP. Serverul web - ca orice aplicaie server - va asculta un port. Acest port este n mod standard portul 80, acesta fiind cel folosit implicit la introducerea unei adrese normale de web. Dac serverul web a fost configurat s asculte alt port, de exemplu 8080, atunci adresa va trebui s conin i numrul portului la care trebuie s se fac conexiunea (exemplu: http://www.niculaantoniu.tk:8080/). Folosirea altui port dect 80 poate fi datorat rulrii simultane pe aceeai main a mai multor servere web: de exemplu, Apache poate fi instalat pentru teste pe portul 8080, pe cnd portul 80 s fie folosit de IIS. Odat stabilit portul i pornit serverul, un client se poate conecta la serverul web folosind adresa mainii n cauza. Aceast adres se numete URL (Uniform Resource Locator) i este folosit exclusiv pentru a localiza i determina maina gazd, protocolul folosit i fiierul dorit. De exemplu, orice adres din spaiul de adrese romnesc are forma:

[http[s]://]subdomeniu.domeniu.ro [:n][/localizare/fisier] De asemenea, se poate folosi adresa IP a mainii gazd n mod direct sau aliasul

localhost dac conexiunea se face direct de pe maina gazd. Datorit folosirii protocolului TCP - protocol orientat pe conexiuni, n care o conexiune se creeaz la cerere i se nchide de ndat ce nu mai este nevoie de ea - conexiunea ntre client i serverul web se va termina de ndat ce fiierul a fost trimis de ctre web-server. Starea conexiunii, n cazul fiierelor mai mari dect un pachet TCP, se pstreaz activat att de ctre client, ct i de ctre server.

Exemple de accesare a web-serverelor: http://www.niculaantoniu.tk/ : cel mai simplu mod de adresare

304

http://www.niculaantoniu.tk/index.htm: adresarea fiierului index.htm aparinnd subdomeniului niculaantoniu

http://localhost:8080/test/test1.htm: pentru a accesa fiierul test1.htm din directorul test de pe maina local prin intermediul serverului care ascult pe portul 8080

https://80.97.33.1/test.php: adresarea securizat a fiierului test.php folosind IP-ul mainii gazd

Clientul folosit pentru accesarea serverului web este cel mai probabil un browser (sau "navigator") web, dar poate fi i alt program capabil s se conecteze la un port TCP (de exemplu: telnet). Browserul web este programul folosit la afiarea de coninut web. Trebuie deci s tie s interpreteze pagini HTML, s afieze imagini i alte forme de coninut multimedia, s foloseasc referine (linkuri) etc. Cea mai important caracteristic a s este probabil capacitatea de a se conecta prin protocolul TCP la un server web. Metoda de conectare am prezentat-o anterior. Mai trebuie menionat c introducerea unei adrese web (de exemplu: http://www.niculaantoniut.tk/fisier.htm) n browser, produce urmtorul lan de aciuni:

Browserul determin protocolul pe care l va folosi n dialogul cu serverul web (http:// = HTTP - HyperText Transfer Protocol).

Browserul determin adresa web a serverului (www.niculaantoniu.tk). Browserul determin ce anume trebuie s cear de la serverul web (fisier.htm). Pe baza adresei web, browserul determin adresa IP a mainii pe care ruleaz

serverul web prin interogri DNS (Domain Name Service). Pe baza adresei IP determinat anterior, browserul instaureaz o conexiune TCP pe

portul specificat n URL sau implicit pe portul 80. Browserul trimite o cerere GET ctre server specificnd fiierul dorit: GET /fisier.htm. Serverul web rspunde trimind fiierul dorit sau o eroare corespunztoare n cazul

n care trimiterea nu este posibil (lipsa fiierului, drepturi de acces insuficiente etc.). Aici conexiunea dintre client i server se ncheie.

Browserul analizeaz fiierul primit i l afieaz corespunztor. Un server web serverte pagini web. Dup cum am mai spus, rolul dedicat al

serverului web este acela de a servi fiiere. n principal aceste fiiere sunt fiiere n format HTML, dar nu numai. Serverul web poate s serveasc i alte fiiere: imagini, sunete, animaii, arhive etc. Fiierele care sunt puse la dispoziia navigatorului se afl stocate ntr-un director vzut ca rdcin de ctre web server (exemplu: C:\Inetpub\wwwroot pentru IIS sau /var/www/html/ pentru Apache). Acest director se specific n configuraia serverului i n el se vor stoca fiierele i structura de subdirectoare pe care le va folosi serverul web n cutarea unui fiier cerut de ctre un client ("buctria restaurantului"). Servirea unui fiier se efectueaz dac fiierul specificat exist, dac este accesibil de ctre serverul web i dac drepturile de acces nu interzic acest lucru. n cazul nendeplinirii uneia dintre aceste condiii, serverul va trimite un cod de eroare sau o pagin predefinit care s informeze despre eroarea aprut.

De multe ori, fiierele pe care trebuie s le serveasc depind de alte programe externe de generare de cod (PHP, ASP, JSP, PHP). Fiierele care necesit astfel de prelucrri vor fi generate de programul extern, a crui rezultat va fi un fiier HTML nou creat. Acest fiier va fi transferat serverului web, pe care acesta poate s-l serveasc ca pe orice alt fiier. Acest proces st la baza tuturor siturilor dinamice i este absolut necesar pentru pagini al cror coninut necesit modificri n funcie de anumite criterii.

Un server web folosete protocolul HTTP. "Dialogul" dintre client i server se efectueaz prin protocolul HTTP, care este un protocol la nivel de aplicaie. "Transportul" comunicaiei dintre client i server se efectueaz folosind protocolul TCP, protocol la nivel de reea. Protocolul HTTP defineste modul prin care se neleg clientul i serverul. Clientul va trimite o cerere (o comand HTTP n mod text simplu, (exemplu: GET, POST, HEAD, PUT) prin care informeaz serverul despre aciunea pe care vrea s o ntreprind. Dac, spre exemplu, serverul va primi o cerere de tip GET /index.htm, el va rspunde cu un status code prin care informeaz browserul despre succesul cererii sau eventualele erori aprute (de exemplu: codul 404 indica faptul ca fiierul specificat n URL nu exist, codul 200 indica

305

succesul cererii). n caz de succes, serverul va transmite un antet (header) ctre browser, cu informaii ca: tipul i versiunea protocolului folosit, limba coninutului, dac este necesar salvarea n cache-ul browserului sau nu, tipul coninutului transmis (MIME type), data serverului, numele serverului etc. Dup antet, va fi transmis coninutul fiierului cerut (in cazul unei cereri HEAD, doar antetul va fi trimis, nu i coninutul fiierului). Un exemplu de dialog intre server i client :

>telnet localhost 80 Conectare la serverul web local prin

telnet GET /test.html HTTP/1.0 Cerere HTTP GET de preluare a

fiierului test. html din directorul rdcin. Se specifica i versiunea

protocolului folosit. HTTP/1.1 200 OK Server: Apache

Date: Wed, 26 Feb 2003 12:50:00 GMT Content-type: text/html Accept-Ranges: bytes

Last-Modified: Wed, 26 Feb 2003 12:00:00 GMT Content-Length: 75

Headerul transmis de ctre server. Conine informaii utile pentru browser:

tipul fiierului (text/html), lungimea fiierului (75 bytes), data la care a fost

modificat, etc.

Un mic fiier de test

Dup o linie blank urmeaz coninutul fiierului cerut.

Conection closed by foreign host. Conexiunea se ncheie dup transmiterea fiierului.

2. Securitatea serverelor web Datorit faptului c serverul web are acces direct la fiiere din sistemul pe care

ruleaz, securitatea este un punct de maxim interes i a necesitat multe versiuni ale serverelor web pentru a ajunge la un anumit nivel de sigurana.

Securitatea serverelor web presupune o cunoatere a modului de accesare al clienilor la datele de pe server. Unele din problemele care trebuie avute n vedere sunt:

2.1. Amplasarea datelor

O problem major este aplasarea datelor private n directoarele publice ale serverului de web. Muli dintre cei care ofer servicii internet ofer doar spaiu pe web. Soluia lor de gzduire mapeaz directorul de root al serverului ftp pe directorul de root al serverului web, n comcluzie directorul /home/www/servers/www.customer.com/" va fi accesibil clienilor folosind ftp-ul cu /, directorul rdcin, deasemenea este accesibil folosind URL-ul http: //www.customer.com/.

Multe dintre site-urile comerciale i inregistreaz comenzile i informaiile pentru depanarea aplicaiei n unul sau mai multe fiiere de log, sau au fiiere de configuraii parolate. Dac aceste date sunt salvate n fiiere care se afl mai jos de directorul de root al serverului web, atunci automat vor avea un URL asociat, deci utilizatorul va avea acces la date. Treaba unui atacator este doar de a ghici care este numele fisierului , acest lucru putnduse realiza prin folosirea de aplicaii care scaneaz serverul web.

Aceste lucruri nu se ntmpl pentru soluii de gzduire care au fost proiectate pentru a oferi stocare privat a datelor. Aici serverul de web i cel de ftp se afl n directoare separate aflate sub directorul clientului. De exemplu directorul principal este "/home/www/servers/www.customer.com/", directorul de ftp este

306

"/home/www/servers/www.customer.com/public_ftp" iar directorul pentru documente html este "/home/www/servers/www.customer.com/public_html". Folosind aceast configurare se pot creea directoare care nu vor fi accesibile publicului.

O modalitate de a combate accesul la directoare , dei sunt amplasate n directoare public, este restricionarea accesului prin folosirea fiierelor .htaccess. De exeemplu pentru serverul Apache pentru a limita accesul la directorul /shop se poate folosi:

$ cat /shop/.htaccess order deny, allow deny from all

2.2. Accesul la servicii private

Muli dintre cei care ofer servicii de gzduire nu au avut niciodat curiozitatea de a-i privi sistemul din afar, de a folosi un program pentru scanarea porturilor accesibile de la o adres IP. Un exemplu este serverul celor de la Heise. Acesta nu folosea un firewall (din motive de performan), lucru ce a dus la posibilitatea accesrii serviciilor private de ctre oricine. n consecin exista posibilitatea accesrii serverului bazelor de date Oracle. Parolele pentru conexiunea cu acest server erau stocate in scripturi aflate in directoare care erau accesibile publicului.

Aceasta greeal este combinat cu folosirea serviciilor nesecurizate. De exemplu muli dintre cei care ofer servicii de gzduire ofer i servicii POP3 precum i access FTP sau access la baze de date, pentru upload-are. Aceste protocoale pot oferi autentificare securizat sau transmisie securizat (de exemplu versiunea SSL a protocolului POP sau FTP), dar muli folosesc versiuni nesecurizate. Unele protocoale, cum ar fi serverul de baze de date MySQL, nu ofer nici ometod de autentificare.

2.3. Securizarea conexiunii

Pentru a oferi o comunicare securizat ntre client i serverul web se poat folosi module de criptare. Unul dintre aceste module este mod_ssl folosit petru serverul Apache. S presupunem c dorim s facem un transfer de bani, comunicarea cu banc s se realizeze ntr-un mod privat, doarece inlcud informaii private.

2.3.1. Criptarea datelor

Un mod de a realiza acest lucru este criptarea mesajului care urmeaz a fi trimis la banc. Exist 2 categorii de algoritmi de criptare:

criptare convenional aceast metod presupune schimbarea de chei ntre client i server. Dac aceast cheie este privat nimeni nu poate citi mesajul. Modul de alegere al acestor chei poate fi o problem.

criptare folosindu-se o cheie public rezolv problema trimiterii de chei prin definirea unui algoritm care folosete 2 chei; dac o cheie este folosit pentru a crista mesajul, cea de a 2-a cheie este folosit petru a decripta mesajul. Oricine poate cripta un mesaj folosind o cheie public, ns doar acela care deine cheia privat poate citi mesajul.

2.3.2. Semntura digital.

Cnd se dorete trimiterea unui mesaj la o banc, aceasta trebuie s se asigure c mesajul este trimis de ctre persoana care sunsine c la trimis. Pentru acest lucru se folosete semntura digital. Aceasta trebuie inclus n mesajul trimis serverului.

2.3.3 Certificate

Pricipalul obiectiv al certificatelor este acela de a garanta ca o anumit cheie publica aparine unei anumite identiti. (persoana, organizaie, server/serviciu). Certificatele sunt eliberate (issued) sau au semntura digital a unei autoriti numite Certificate Authority (CA).

307

Dac clientul recunoate certificatul primit de la server atunci are loc validarea certificatului. Dac clientul nu recunoate certificatul verific de cine a fost semnat acesta. Acest ciclu se repet pn se ajunge la un certifica care este recunoscut. Dac nu s-a gsit nici un certifica recunoscut atunci conexiunea este anulat.

Pentru verificarea certificatelor clientul trebuie s dein o list cu certificate CA.

Bibliografie 1. Mang Ioan, Securitatea datelor 2. Ralf S. Engelschall, User manual mod_ssl 3. Andrew S. Tanenbaum, Reele de calculatoare 4. http://www.experts-exchange.com 5. http://www.phpbuilder.com 6. http://www.borland.com/delphi 7. http://www.w3.org 8. http://www.w3schools.com 9. http://www.apache.org 10. http://www.hotscripts.com 11. http://www.edevcafe.com 12. http://www.about.com 13. http://www.netreport.ro