Sunteți pe pagina 1din 21

Configurarea unui server de WEB in Linux

Pentru nceput vom prezenta World Wide Web - o seciune din Internet, seciune extrem de important la ora aceasta: fr WWW nu ar fi avut loc dezvoltarea exploziv a Internetului aa cum l cunoatem azi. Internetul s-a nscut la sfritul anilor 70 din ARPANET, o reea experimental a Ministerului Aprrii a SUA. Pe la mijlocul anilor 80 a nceput perioada de dezvoltare accelerat a Internetului ca urmare a conectrii instituiilor guvernamentale, centrelor academice , laboratoarelor independente i, ntr-un final, a corporaiilor i persoanelor particulare ntr-o reea ce avea s aib o suprafa de acoperire global. Ca urmare utilizatorii doreau s foloseasc aceast nou reea pentru a partaja informaii. Din pcate, la momentul respectiv, nu exista un mod comod de a efectua schimbul de informaie: trebuiau s foloseasc telnet pentru conectarea la distan, ftp pentru transferul de fiiere, usenet - un serviciu imens de buletine de tiri, gopher - un sistem de partajare a informaiilor la nivel de campus i multe alte protocoale, fiecare destinat unei anumite categorii de informaie. Pentru a folosi oricare din aceste protocoale, utilizatorul trebuia s stpneasc cte un program pentru fiecare protocol. i, cum legile lui Murphy exista dinaintea calculatoarelor i a Internetului, aceste programe erau ct se poate de diferite, acest fapt nsemnnd c un utilizator trebuia s tie s foloseasc foarte multe programe diferite pentru a putea partaja/solicita informaii din reea. Pe lng toat aceast debandad de programe utilizatorul mai trebuia s depeasc un obstacol: acela al formatelor de fiiere existente! De exemplu, pentru documente existau (i nc mai exist!) o multitudine de formate: PDF, RTF, LaTeX, SGML, PostScript, text simplu, etc. Exist i o mare varietate de formate grafice: PNG, GIF, JPEG, BMP, PCX, etc. Aceeai problem exista i pentru bazele de date. Prin urmare, chiar dac utilizatorul gsea fiierul cerut el nu avea certitudinea ca va putea folosi acel fiier dect dup ce gsea aplicaia corespunztoare care putea deschide acel fiier! n acest moment intr n scen Tim Berners-Lee i asociaii si de la CERN, Centrul European de Cercetri Nucleare. El propune, n anul 1989, crearea unui sistem nou de informare denumit WorldWideWeb. Acest sistem a fost proiectat s-i ajute pe cercettorii CERN n gsirea informaiilor utile n masa tot mai mare de informaii existente n Internet. n esen, acest sistem propunea folosirea unui singur program, denumit browser, care s rezolve problema gsirii informaiei i a prezentrii ei, n locul folosirii perechilor [program|protocol]. Conceptul de baz era folosirea hypertextului: informaia s fie afiat sub forma unei succesiuni de documente. Documente nrudite putnd fi legate mpreun prin cuvinte speciale sau fraze. Prin selectarea unui astfel de cuvnt (sau fraz) utilizatorul era trimis la un alt document, document care putea fi, fizic, situat ntr-un server aflat la 5000 Km distan i accesat printr-un alt protocol dect cel al documentului iniial, fr ca utilizatorul s tie de fapt acest lucru. n februarie 1993 are loc o alt mare cotitur n dezvoltarea WWW: NCSA lanseaz browserul MOSAIC, o versiune de browser pentru mainile UNIX cu XWindows. Acest browser folosea meniuri popup, iconie, afia imagini i link-uri colorate. Mai mult, Mosaic putea ncorpora imagini n textul afiat pe o pagin. Expansiunea exploziv a Web-ului ncepea! La 8 luni dup lansarea Mosaic numrul Web serverelor nregistrat la CERN ara estimat la 500. Un an mai trziu acest numr era

estimat la 4600! Se emiteau ipoteze c acest numr ar crete exponenial! Iat, deci, cum o idee bine gndit i exploatat poate duce la o schimbare major i radical a unui sistem considerat de neschimbat. Toate informaiile necesare funcionrii corecte (configurri) a serverului Apache sunt stocate ntr-un fiier de tip text care se numete httpd.conf . Dup cum am menionate anterior acest fiier a fost constituit din 3 fiiere iniiale, existente n cazul serverului NCSA httpd, "strmoul" lui Apache. Aceste 3 fiiere erau:

fiierul de configurare pentru serverul principal, httpd.conf; fiierul de configurare pentru resurse, srm.conf; fiierul de configurare pentru permisiunile de acces, acces.conf;

Instructiuni de instalare nainte ca instalarea sa poata avea loc Apache trebuie sa fie informat despre mediul unde va fi instalat. Aceasta se face prin intermediul scriptului configure:

$ ./configure --prefix=/usr/local/apache Scriptul de configurare exploreaza sistemul de operare si creeaza Makefile pentru el, deci avem posibilitatea sa executam urmatoarele pentru a ncepe procesul real de compilare, copiem fisierele n cadrul directorului stabilit de catre prefixul de optiune si se va executa scriptul apachectl pentru a porni serverul Apache:

$ make # make install # /usr/local/apache/bin/apachectl start Desi aceasta se va instala Apache si a ncepe, avem nevoie, de asemenea, sa configuram operare sistemul sa porneasca atunci cnd porneste Apache. Procedura difera de la sistem la sistem, pe platforme Unix, dar este, de obicei, se face prin crearea unui link simbolic de la scriptul apachectl pentru nivelul de executie relevant:

# cd /etc/rc3.d

# ln -s /usr/local/apache/bin/apachectl S85httpd Testarea instalarii Pentru a verifica daca pornirea a reusit, ncercam sa accesam serverul de web folosind un client browser. Daca functioneaza, vom vedea pagina "Seeing this instead of the website you expected?". La momentul acestei scrieri, exista discutii pe lista Apache Developers' pentru a reduce mesajul de bun venit, pentru a se evita confuzia utilizatorilor. Folosind instrumentul ps, putem afla cte procese sunt in Apache: $ ps -Ao user,pid,ppid,cmd | grep httpd root 31738 1 /usr/local/apache/bin/httpd -k start httpd 31765 31738 /usr/local/apache/bin/httpd -k start httpd 31766 31738 /usr/local/apache/bin/httpd -k start httpd 31767 31738 /usr/local/apache/bin/httpd -k start httpd 31768 31738 /usr/local/apache/bin/httpd -k start httpd 31769 31738 /usr/local/apache/bin/httpd -k start

Utilizand comanda tail, putem vedea ce este nregistrat, cererile cer sunt prelucrate diferit. Introducem un nume de fisier inexistent n bara de locatie a browserului acesta trimite cererea pe serverul de web; apoi examineaza timpul de acces (log-urile se afla n folderul /var/www/logs).

192.168.2.3 - - [21/Jul/2004:17:12:22 +0100] "GET /manual/images/feather.gif HTTP/1.1" 200 6471 192.168.2.3 - - [21/Jul/2004:17:20:05 +0100] "GET /manual/not-here HTTP/1.1" 404 311

n httpd.conf sunt directive i containere de directive. Directivele conin informaii despre configurrile specifice serverului (autorizri, performan, parametri de reea, etc) pe cnd containerele de directive delimiteaz contextul n care sunt aplicate acele configurri. Spre exemplu putem configura accesul pe baz de parol la un singur fiier, la un director sau la ntregul server. Configurarea si securizarea Incepand cu gol un fisier de configurare este o buna practica, deoarece acesta mareste ntelegere a modului de lucrari de Apache. n plus, fisierul de configurare, fisier este mare, contine directivele pentru tot, inclusiv module pe care nu le vom folosi. Cel mai bine este sa pastram fisierele de configurare frumos. Deschidem fisierul de configurare (/usr/local/apache/conf/httpd.conf) cu cteva directive generale:

# location of the web server files ServerRoot /usr/local/apache # location of the web server tree DocumentRoot /var/www/htdocs # path to the process ID (PID) file, which # stores the PID of the main Apache process PidFile /var/www/logs/httpd.pid # which port to listen at Listen 80 # do not resolve client IP addresses to names HostNameLookups Off

Setarea serverului. Contul de utilizator. Dupa instalare, Apache ruleaza ca un utilizator "nobody" (nimeni). n timp ce acest lucru este convenabil (acest cont n mod normal exista n toate sistemele de operare Unix), este o idee buna de a crea un cont separat pentru fiecare sarcina. Cel mai frecvent folosit nume de utilizator pentru acest cont este httpd, si unii oameni utilizeaza apache. Pentru a crea o cont nou, executam urmatoarele doua comenzi n timp ce ruleaza ca root.

# groupadd httpd # useradd httpd -g httpd -d /dev/null -s /sbin/nologin

Aceste comenzi creaza un grup si unu cont de utilizator, stergere a contului de origine directorul/dev/null si shell/sbin/Nologin (n mod eficient pentru dezactivarea de login cont). Adaugam urmatoarele doua linii in fisierul de configurare Apache httpd.conf:

User httpd Group httpd Configurarea securitatii de valori prestabilite. Cu exceptia cazului n care altfel spus, Apache va servi orice fel de fisier-l poate accesa. Aceasta este, probabil, nu ceea ce majoritatea persoanelor doresc; o eroare de configurare ar putea expune accidental fisierele vitale de sistem pentru oricine. Pentru a schimba acest lucru, refuzam accesul complet la fisierele de sistem si apoi permitem accesul la documentul de root numai prin introducerea urmatoarelor directivele n fisierul de configurare httpd.conf:

<Directory /> Order Deny,Allow Deny from all </Directory> <Directory /var/www/htdocs>

Order Allow,Deny Allow from all </Directory> Logging (jurnalizarea). Avand o copie a activitatii serverului de web este de o importanta deosebita. Rapoartele ne spun care continut este popular si daca server-ul este utilizat gresit sau incorect. Exista doua tipuri de inregistrari. - access log este o evidenta a tuturor cererilor trimise la un anumit server de web sau site-ul web. Pentru a crea un acces log, avem nevoie de doi pasi. n primul rnd, utilizarea directivei LogFormat pentru a defini un format de logare. Apoi, folosim directiva CustomLog pentru a creati un timp de acces n acest format:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%i\" \"%i\"" combined CustomLog /var/www/logs/access_log combined - error log contine o evidenta a tuturor evenimentelor de sistem (cum ar fi pornirea de nchiderea serverului de web) si o iregistrare a erorilor care au aparut n timpul procesarii cererii. De exemplu, o cerere pentru o resursa care nu exista genereaza o eroare HTTP 404 ca raspuns pentru client, Doua directive au obligatia de a nfiinta eroare de timp, doar pentru ca timp de acces. Urmatoarea directiva log level creste detaliile de logare de la o valoare implicita la informatii. Directiva error log creeaza fisierele actuale de log:

LogLevel info ErrorLog /var/www/logs/error_log Prevenirea pierderilor de informatii. n mod implicit, Apache ofera mai multe informatii de biti, pentru oricine este interesat. Orice informatie obtinuta de catre atacatori, ii ajuta sa construiasca o mai buna vizualizare a sistemului si pot strica mai usor sistemul. De exemplu, procesul de instalare pune automat adresa de email a utilizatorului n fisierul de configurare. Aceasta arata

contul pentru public, care sunt nedorite. Urmatoarele directive nlocuiesc adresa de e-mail generata de Apache cu o adresa generic:

ServerAdmin webmaster@apachesecurity.net

n mod implicit, adresa de e-mail definitea cu aceasta directiva apare pe paginile generate server. Deoarece aceasta este, probabil, ceea ce nu doriti, aveti posibilitatea sa dezactivati aceasta caracteristica complet prin urmatoarele directive: ServerSignature Off Protocolul HTTP defineste un antet de raspuns domeniului Server, al caror scop este de a identifica ca software-ul raspunde cererii. n mod implicit, Apache ocupa acest antet cu numele, numarul de versiune, ca si numele si numerele de versiune din toate modulele dispus sa se identifice ei nsisi. Putem vedea cum arata aceasta prin trimiterea unei cereri test la server nou instalat:

$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Fri, Fri, 25 Apr 2008 22:05:35 GMT Server: Apache/1.3.29 (Unix) Content-Location: index.html.en Vary: negotiate,accept-language,accept-charset TCN: choice Last-Modified: Fri, 18 Apr 2008 00:00:38 GMT ETag: "4002c7-5b0-3af1f126;405a21d7"

Accept-Ranges: bytes Content-Length: 1456 Connection: close Content-Type: text/html Content-Language: en Expires: Fri, 25 Apr 2008 22:05:35 GMT

Acest cmp arata specificatiile si valorile informatiilor pentru un atacator. Nu se pot ascunde complet dar putem spune serverului Apache sa dezvaluie doar numele serverului ("Apache").

Directivele Sintaxa directivelor:


numele directivelor sunt urmate de argumente; argumentele sunt separate prin spaii; argumentele pot fi n numr variabil, n funcie de directive; unele directive nu necesit argumente; dac o directiv necesit mai mult de un rnd atunci trecerea pe rndul urmtor se face prin terminarea rndului curent cu caracterul backslash \; semnul diez # precede directiva i trebuie s fie pe propria sa linie;

Containerele Se mai numesc i seciuni (sections) delimiteaz domeniul n care se aplic directivele. Aceste directive container sunt ncadrate n paranteze unghiulare. O directiv container conine alte directive i specific domeniul pentru care se aplic directivele coninute. Spre exemplu, dac directivele nu sunt cuprinse ntr-un container atunci acele directive aparin domeniului general al serverului i se vor aplica ntregului server. Mai jos sunt listate toate directivele acceptate de serverul Apache. n seciunea Configurare de baz vor fi explicate directivele necesare configurrii minimale a serverului, iar n seciunea Configurare avansat vor fi tratate aspecte mai detaliate. Protocolul TCP/IP

De fapt, sunt dou protocoale legate unul de altul, Transmission Control Protocol (Protocolul de control al transmisiei) i Internet Protocol. Acest protocol este protocolul aflat pe nivelul cel mai de jos, folosit n Internet. Acest protocol reglementeaz felul n care dou programe, aflate pe calculatoare diferite conectate la Internet, se vor gsi unul pe altul, vor stabili parametri conexiunii i vor ncepe s transmit date. De asemenea, asigur livrarea fiecrui pachet de date n ordinea corect i fr erori. Pentru acest protocol datele transmise nu au nici o relevan. Toate datele sunt fluxuri de 8 bii; nu conteaz c un flux reprezint o imagine, un altul reprezint un videoclip sau o baz de date. TCP/IP utilizeaz o schem de adresare cu adrese statice, n care fiecare calculator conectat la Internet are asignat o adres unic. Aceste adrese sunt formate din 32 de bii, grupai n 4 grupuri a 8 bii, separate prin puncte. De exemplu 25.158.11.6 sau 192.168.0.154; prin urmare exist puin peste 4 miliarde de adrese unice. Pare o cifr imens, nu-i aa? i totui, aceste adrese ncep s se termine, drept urmare este deja n lucru noua generaie de adrese, aa numitul IPv6. Aceste adrese IP sunt foarte greu de reinut, aa c a fost implementat un serviciu care execut traducerea acestor cifre n nume, mult mai uor de reinut. Acest serviciu se numete Domain Name System (DNS), Serviciul numelor de domeniu, care folosete un sistem ierarhic distribuit de nume. Fiecare calculator va avea un nume unic format din mai multe pri, separate prin puncte. Prima parte este numele calculatorului, urmat de o list de domenii. Primul domeniu este, de obicei, domeniul organizaiei din care face parte calculatorul, urmat de alte organizaii, daca e cazul i n final, numele domeniului de pe ultimul nivel. Acest ultim nivel poate fi .com .net .org .ro .fr .jp, etc. Impreun, aceste elemente formeaz un nume de domeniu calificat care identific n mod unic un calculator n Internet. Tehnologia Client/Server n momentul n care dou programe vor s comunice ntre ele (n cadrul aceluiai calculator sau prin internet) trebuie s stabileasc un canal de comunicaie. Acest canal de comunicaie se stabilete astfel: unul dintre programe trebuie s iniieze comunicarea iar cellalt s accepte. Acest lucru se realizeaz folosind tehnologia client/server. Serverul ruleaz ateptnd cererile de conectare. Cnd un client dorete s acceseze informaia de pe calculatorul server, acest stabilete un canal de comunicare cu clientul, i trimite informaia apoi nchide conexiunea. Multe din serverele actuale pot accespta conexiuni multiple simultane. Acest lucru este realizat fie prin duplicarea serverului n memorie pe parcursul conexiunii, fie prin ntreeserea acestor conexiuni n mod controlat. Prin urmare diferena dintre un client i un server este : cine iniiaz conexiunea i cine o accept? Revenind la cele dou programe de mai sus: cunoaterea adreselor IP ale celor dou calculatoare implicate ntr-un schimb de informaii nu este suficient pentru a realiza conctarea celor dou programe. Mai este nevoie s se identifice unul pe cellalt din multitudinea de procese ce ruleaz pe cele dou calculatoare. De exemplu, pe un calculator poate s ruleze un proces care ofer ftp anonim, un alt proces ofer telnet, un altul ofer pagini web i aa mai departe. Cum va ti programul care iniiaz conexiunea c se conecteaz la programul dorit, dup stabilirea conexiunii cu calculatorul destinaie? Prin folosirea porturilor! Prin comparaie: dac asimilm adresa IP cu adresa unui bloc cu apartamente, atunci portul va fi numrul apartamentului dorit. Porturile sunt identificate

prin numere de la 0 la 65535. Porturile de la 0 la 1024 sunt, de obicei, porturi privilegiate i pot fi accesate de procese cu drept de root(superuser) pe calculatoarele cu UNIX. Fiecare serviciu are repartizat un anumit numr de port: 21 pentru ftp, 80 pentru HTTP, 23 pentru telnet, etc. Deci, cnd un server Web pornete va rezerva portul 80 (HTTP), pentru uz exclusiv. Conexiunile de intrare la acest server trebuie s fie efectuate pe portul 80 i adresa IP a calculatorului gazd. Daemon sau Inetd Pe sistemele UNIX serverele ruleaz n unul din urmtoarele moduri: standalone sau sub controlul unui program numit inetd. Serverele standalone sau daemon sunt servere care pornesc, ateapt conexiuni pe un anumit port, deservesc conexiunea apoi trec napoi n modul ascultare. Acest tip de servere vor putea servi mai multe conexiuni pri metoda descris anterior: se automultiplic n memorie, servesc cererea elibernd originalul de aceast sarcin, apoi i nceteaz existena. Un dezavantaj major al acestui tip de server este faptul c, de multe ori, se gsesc n memorie cteva servere care ascult fiecare pe porturi diferite i, n lipsa conexiunilor, consum resurse degeaba. Alternativa la serverul standalone este inetd. Acest inetd este un Super daemon care ruleaz n fundal pe mainile UNIX. inetd , la pornire, citete un fiier de configurare n care se specific o list de porturi i serverele de pornit ca urmare a activitii pe acele porturi. Cnd inetd sesizeaz activitate pe un port din list, verific care server trebuie s deserveasc portul respectiv, lanseaz acel server n execuie i i pred conexiunea la portul repectiv. Cnd cererea este rezolvat serverul i nceteaz execuia, elibernd astfel resursele sistem folosite. El va fi relansat de ctre inetd cnd va fi nevoie. Alegerea unui mod de funcionare sau altul este la latitudinea celui care configureaz serverul. Majoritatea serverelor (FTP, Telnet, Gopher, etc.) funcioneaz sub inetd. Serverul WEB poate funciona i el n acest mod, dar nu este recomandat. Serverele WEB sunt programe mari consumatoare de resurse i cu fiiere de configurare relativ mari i stufoase, care necesit timp, la pornire, pentru parcurgerea lor. Lansarea acestor servere de ctre inetd duce la o degradare semnificativ a performanei. Acesta este motivul pentru care serverele WEB sunt lansate n execuie ca servere standalone. Sistemul de tipuri MIME MIME (Multipurpose Internet Mail Extension) este un sistem extensibil care a fost dezvoltat pentru trimiterea de coninut multimedia (sunet, imagine, video) prin pota electronic. WWW a adoptat acest sistem, ca parte a protocolului http, pentru simplul fapt c are de transmis acelai tip de informaii: coninut multimedia! MIME este un mod de a descrie coninutul unui document prin referirea la o list standard de tipuri de documente organizat pe tipuri i subtipuri. Spre exemplu tipul text/plain este folosit pentru fiierele text neformatat, pe cnd text/html este folosit pentru a descrie un fiier text scris n limbajul HTML. La fel, video/mpeg descrie un videoclip n format MPEG. Un mod destul de rspndit de a distinge tipul unui fiier este dup extensia lui. Astfel, .gif va indica un fiier grafic pe cnd .html va indica spre un fiier text scris n limbaj HTML. Protocolul HTTP

Protocolul HTTP este, de fapt, o scurt conversaie ntre browser i serverul WEB. Aceast conversaie se compune din dou faze:

request, (cererea) n care browserul lanseaz o cerere, format din tipul de metod dorit, calea sau URL spre fiierul dorit i numrul de versiune al protocolului HTTP dorit. response, (rspunsul) n care serverul va rspunde cu numrul de versiune al protocolului HTTP, un cod de stare, putin text i zero sau mai multe linii de antet, terminate printr-o linie goal. Urmeaz apoi datele solicitate.

Faza request tipul de cerere dorit de ctre browser:


GET returneaz coninutul documentului indicat; HEAD returneaz antetul documentului indicat; PUT nlocuiete coninutul documentului indicat cu datele care urmeaz

Exist mai multe metode dect cele prezentate, pentru o documentare mai detaliat se poate consulta documentaia existent pe site-ul CERN. Cea mai folosit metod este GET, care instructeaz serverul s pun la dispoziia browserului coninutul documentului indicat. Urmeaz trimiterea antetului, prin trimiterea campurilor de antet, care pot fi de tipul: Antet From User-Agent Accept Referer Pragma Content-Length Antet Server Date MIME-version Content-Length Content-Type Title Allowed Descriere Adresa de pot electronic a solicitantului Denumirea i versiunea browserului Tipuri de fiiere acceptate (pot fi mai multe astfel de linii) Ultimul document vizitat Directive specifice pentru serverul WEB Lungimea datelor care urmeaz, n octei Descriere Numele i versiunea serverului Data curent n format GMT Versiunea MIME folosit Lungimea date ce urmeaz a fi trimise, n octei Tipul MIME al documentului indicat Titlul documentului indicat Tipurile de metode care pot fi folosite (de exemplu GET)

Dup trimiterea antetului urmeaz o linie goal, dup care se pot trimite datele, dac browserul a fcut o cerere de tip PUT, sau ateapt rspunsul serverului.

Faza reponse n acest moment ntrm n faza de rspuns a serverului. El va trimite, n primul rnd, o linie coninnd numrul versiunii protocolului folosit, un cod de stare format din 3 cifre i un text care explic codul de stare. Acest cod de stare este imprit n patru mari categorii:

ntre 200-299: indic o tranzacie corect ntre 300-399: indic faptul c documentul specificat n URL nu a fost gsit din cauz c a fost mutat n alt locaie ntre 400-499: sunt folosite cnd clientul a fcut o greeal, ca de exemplu a fcut o cerere neautorizat de la 500 : serverul nu poate satisface cererea din cauza unei erori interne

Dup trimiterea liniei de stare, serverul trimite un antet rspuns, care este format din informaii despre server nsui precum i diferite informaii despre documentul solicitat. Aceste informaii sunt, majoritatea, opionale. Antet Server Date MIME-version Content-Length Content-Type Title Allowed Descriere Numele i versiunea serverului Data curent n format GMT Versiunea MIME folosit Lungimea date ce urmeaz a fi trimise, n octei Tipul MIME al documentului indicat Titlul documentului indicat Tipurile de metode care pot fi folosite (de exemplu GET)

Aceste cmpuri nu sunt singurele cmpuri disponibile. Exist o mulime de cmpuri posibile, utilizatorul urmnd s stabileasc ce tipuri de cmp are nevoie. Urmeaz, n sfrit, trimiterea datelor propriu zise. Dup trimiterea antetului serverul trimite o linie goala. Dac browserul a solicitat doar antetul unui document aici se ncheie transmiterea. Altfel, serverul trimite coninutul documentului solicitat, dup care ncheie conexiunea. Dup configurarea de baz a serverului s ncercm s modificm aceast configurare pentru a acoperi cteva puncte de interes pentru un server web. S ncepem cu modalitile de limitare a serverului la ascultarea unei singure interfee de reea, pe mai multe porturi sau a mai multor interfee pe mai multe porturi. Directiva Descriere Exemple

BindAdress

Port

Listen

Options

Va limita serverul la ascultarea cererilor BindAdress 192.168.1.1 clienilor doar pe o singur adres IP. Poate fi folosit doar o singur dat n cadrul unui fiier httpd.conf. Nu poate specifica un port anume sau adrese IP multiple. Va specifica portul de reea TCP pe care Port 8080 Apache trebuie s-l asculte pentru a rspunde cererilor clienilor. Limitat la un singur port TCP, unic n cadrul unei configurri. Nu poate defini mai multe valor de port pentru mai multe intefee de reea. Aceast directiv specific adresele IP i Listen porturile pe care serverul ascult cererile 192.168.1.1:8080 clienilor. Are toate funcionalitile Listen directivelor BindAdress i Port ns are 192.168.1.50:80 mai multe avantaje smnificative fa de Listen 8080 acestea. Se pot folosi mai multe directive Listen pentru a specificate combinaii de adrese IP i porturi pe care serverul va asculta cererile. Controleaz facilitile serverului pentru un #Activeaz doar anumit director. Valori posibile: FollowSymLinks

ExecCGI va permite executarea <Directory /help> scripturilor CGI Options FollowSymLinks serverul va FollowSymLinks urma legturile simbolice din </Directory> directorul respectiv. Includes permite SSI includerile din partea serverului IncludesNOEXEC permite SSI dar comezile #exec i #include sunt dezactivate Indexes va furniza un index formatat pentru directoarele care nu au un fiier index stabilit MultiViews permite folosirea MultiViews pentru negocierea coninutului All include toate opiunile, mai puin MultiViews. SymLinksIfOwnerMatch serverul va urma legturile

simbolice doar dac destinaia este n proprietatea aceluiai utilizator ca i legtura

Directivele container Directiva container <VirtualHost> Descriere Exemple

Specific un host virtual (o gazd virtual). <VirtualHost Apache permite gzduirea mai multor site- 192.168.1.25> uri pe un singur server. Aceast directiv se DocumentRoot aplic unuia din aceste site-uri virtuale. /home/www/site1 Argumentele ei sunt un nume de domeniu ServerName www.site1.ro sau o adresa IP i un numr de port </VirtualHost> (opional) <Directory> Directivele cuprinse n aceste containere se #va gsi toate directoarele aplic doar asupra unui director sau grup de care au numele format din <DirectoryMatch> directoare din sistemul de fiiere. Accept 6 cifre din cadrul ca argumete un nume de director sau o directorului /www expresie echivalent unor nume de directoare. <DirectoryMatch> are ca <DirectoryMatch "/www/ argumente i expresii regulate [0-9]{6}">

<Files> <FilesMatch>

#va gsi toate fiierele audio <FilesMatch "\.(wav|mp3| au|mid)$"> Directive </FilesMatch> <Location> Acest container seamn foarte mult cu #solicit o pagin de stare <Directory> cu deosebirea c nu intr n a serverului <LocationMatch> sistemul de fiiere ci folosete doar URL-ul <Location /status> din cerere. Opiunile, aceleai ca i n cazul SetHandler server-status <Directory>, ce nu sunt valabile pentru un </Location> URL sunt ignorate. Se folosete, de regul, cu directiva SetHandler. <LocationMatch> are acceai funcionalitate ca i <Loaction> cu diferena c accept URL-uri definite prin expresii regulate. <Limit> Limiteaz efectul directivelor ce le conine <Limit <LimitExcept doar la metodele HTTP specificate. POST> GET> Require Require valid<LimitExcept> valid-user user <LimitExcept> conine directivele ce se </Limit> </Limit> refer la metodele HTTP excluznd metodele specificate. Fiierul .htaccess Configurarea complet a unui server Apache se realizeaz prin fiierul de configurare httpd.conf. Totui, exist anumite cazuri n care, se pot configura directoarele n mod independent de acest fiier de configurare. Acest mod este folosirea fiierelor .htaccess. n aceste fiiere se pot grupa directive specifice directoarelor (de exemplu cele referitoare la accesul n directoare). Aceste fiiere se plaseaz n fiecare director care se dorete configurat independent i va fi citit de server de fiecare dat cnd are loc o cerere pentru directorul respectiv. Avantajele acestui mod de configurare este posibilitatea de a acorda drepturi de acces pentru modificarea fiierelor .htaccess utilizatorilor de ncredere. Un alt avantaj este faptul c aceste fiiere sunt citite la fiecare acces n directorul care le conine, deci directivele specificate n ele sunt funcionale imediat (spre deosebire de cele specificate n httpd.conf care devin funcionale numai dup restartarea serverului). Directiva AllowOverride

Ca i containerul <Directory>, <Files>poate fi folosit pentru cutri de fiiere dup numele de fiier sau dup modele cu expresii regulate. Pentru cutri dup modele regulate a fost introdus <FilesMatch>, care are ca argumente doar expresii regulate pentru identificarea fiierelor dorite.

#va gsi toate fiierele cu extensia .ext <Files *.ext> Directive </Files>

Directivele coninute n fiierele .htaccess sunt comasate, dup citirea fiierului, cu cele activate deja pentru directorul respectiv (n httpd.conf). Aceasta este aciunea standard (prestabilit) a serverului Apache, aciune ce poate fi modificat folosind directiva AllowOverride . Aceast directiv specific dac directivele coninute ntr-un fiier .htaccess au dreptul sau nu de a anula directivele care sunt deja activate i care intr n conflict. Cu alte cuvinte, aceast directiv specific ce directive pot fi ignorate din fiierul .htaccess. Argumentele pentru aceast directiv sunt urmtoarele:

All activeaz toate anulrile din .htaccess, prin urmare, toate directivele disponibile pentru un fiier .htaccess pot fi folosite pentru anularea celor directivelor stabilite n httpd.conf; None Dezactiveaz toate anulrile din .htaccess. Dac acest argument este prezent fiierul .htaccess nu va fi citit din directorul respectiv, chiar dac exist acest fiier. Argumentul None specificat pentru directorul-rdcin va mpiedica serverul s citeasc fiierele .htaccess! Authconfig va permite folosire directivelor de autorizare (utilizator/grup) FileInfo va permite folosirea directivelor referitoare la tipurile de documente Indexes permite folosirea directivelor referitoare la indexarea directoarelor Limit va permite directivele ce controleaz accesul pe baza numelui de gazd sau adresei IP Options va permite folosirea directivelor speciale.

Securitatea unui server Web Prin definiie serverele Web sunt n prima linie n rzboiul cu persoanele ru intenionate. Furtul de informaii, afectarea securitii sistemelor sau nlocuirea coninutului unui site sunt doar cteva dintre aciunile preferate n ceea ce privete serverul Web. Acest subiect, securitatea serverului Web (a oricrui tip de server, de fapt) a fost tratat n nenumrate cri de-a lungul existenei Internetului. Seciunea aceasta se va concentra pe msurile de securitate ce pot fi foarte uor implementate pe un server Apache. Exist mai multe modaliti de a proteja un server Web. Cea mai simpl i eficace este plasarea lui n spatele unui firewall. Din pcate aceast metod contrazice tocmai scopul unui server Web: accesarea lui din Internet. Urmtoarea variant de protecie este separarea serverului n dou pri: o parte destinat utilizatorilor din interiorul organizaiei(Intranet) care este plasat n spatele firewall-ului, iar a doua parte destinat utilizatorilor din Internet, care este plasat n afara firewall-ului. O soluie bun de protecie este i varianta protejrii resurselor sensibile (private) cu ajutorul unui mecanism de legitimare a utilizatorilor pentru identificarea sigur a acestora. O soluie avansat este implementarea Secure Sockets Layer (SSL), care merge ceva mai departe de simpla autentificare i creeaz o legtur securizat cu browserul Web, ceea ce permite schimbul securizat de informaii confideniale. Instrumente de securitate din Apache

Controlul accesului la resursele serverului Apache este implementat n module. Fiecare modul (complex sau simplu) va avea o singur sarcin final: aceea de a decide, n legtur cu o singur cerere HTTP, care din urmtoarele dou valori va fi returnat:

OK, dac cererea trebuie acceptat FORBIDDEN, dac cererea trebuie refuzat

Aceste module sunt activate n cele trei faze ale prelucrrii cererii:

Controlul accesului - n aceast faz un modul poate refuza accesul la o resurs pe baza informaiilor din cererea HTTP sau a celor din pachetul IP ce conine cererea. Autentificarea - un modul apelat n aceast faz va verifica identitatea solicitantului pe baza acreditrilor prezentate de utilizator. Aceste acreditri pot fi foarte complexe (certificat digital) sau simple(perechi nume utilizator-parol) Autorizarea - la apelului unui modul n aceast faz se presupune identitatea utilizatorului ca fiind cunoscut prin urmare, modului va verifica informaiile pentru controlul accesului i va decide dac utilizatorul are permisiunea de acces la resursa solicitat.

Cea mai simpl metod restricie a accesului este cea oferit de modulul mod_acces, care acioneaz n faza de control a accesului. n timpul acestei faze mod_acces va stabili dac cererea va fi onorat, numai pe baza numelui gazdei sau a adresei IP a solicitantului. Iat cum, ntr-un mod foarte simplu, se poate implementa deja la nivel timpuriu, un nceput de securitate. Directivele acestui modul trebuie plasate ntr-un context de director (container <Directory> sau fiier .htaccess). Restricionarea accesului pe baza acestui modul se refer la toate resursele din directorul specificat. Nu poate fi folosit pentru restricionarea accesului la nivel de fiier. S vedem, prin exemple, cum putem limita accesul la resursele dintr-un director. Se folosesc dou directive care vor reglementa accesul gazdelor la resurse:

allow - specific gazdele care vor avea acces deny - specific gazdele care nu vor avea acces

Aceste directive vor folosi una din urmtoarele metode de descriere a accesului:

cuvntul cheie all, care nseamn toate gazdele: ex.: deny from all adrese IP (pariale sau complete): ex: allow from 192.168.1.15 192.168.1.22 192.168.2 nume de domeniu: ex: deny from nume.domeniu.ro perechi adres IP-masc de subreea: ex: allow from 192.168.1 deny from 192.168.1.0/255.255.255.0

Directiva order va specifica ordinea n care sunt aplicate directivele allow i deny. Ex: order deny, allow - va aplica directivele de refuz naintea celor de aprobare; order allow, deny - va aplica directivele de permitere a accesului apoi va interzice accesul pentru gazdele specificate cu deny Restricii pe baza autentificrii utilizatorului Protocolul HTTP ofer dou tipuri de autentificare care trebuie s fie recunoscute de toate serverele i clienii de Web.

Autentificarea HTTP simpl - este cea mai folosit form de autentificare la ora actual. Se efectueaz un schimb neprotejat de informaii coninnd un nume de utilizator i o parol. Autentificarea clasificat - folosete un principiu asemntor cu autentificarea simpl dar codific acreditrile prilor naintea transmiterii lor, asigurnd astfel, teoretic, posibilitatea interceptrii parolelor pe timpul tranzitului.

Autentificarea HTTP simpl .La primirea unei cereri de resurse cu antet Authorization serverul va ncerca s verifice valabilitatea informaiilor furnizate.

Dup identificarea utilizatorului, va verifica drepturile lui de acces la resursele precizate. Dac numele utilizatorului sau parola nu pot fi gsite sau nu sunt valabile sau utilizatorul nu are drept de acces la resurs serverul va returna un rspuns cu codul 401 Unauthorized.

Modulul mod_auth execut autentificarea cu ajutorul unui fiier text care este creat de htpasswd, un utilitar care este accesoriu standard n Apache i poate fi gsit n directorul /bin din directorul de instalare a serverului Apache. n cazul apelrii htpasswd fr nici un argument va fi afiat o list cu toate opiunile asociate scriptului. De exemplu, pentru crearea unui fiier de utilizator nou i crearea utilizatorului proiectweb, se va folosi comanda: htpasswd -c /www/apache/auth/userfile proiectweb Dup crearea fiierului htpasswd va cere parola pentru utilizatorul specificat apoi va cere confirmarea ei. Adugarea de utilizatori la acest fiier se va face folosind aceeai comand, omind argumentul -c i folosind numele noi de utilizatori. Dei se folosete un fiier text, care conine text vizibil pentru oricine, parolele sunt stocate n mod codificat pentru fiecare utilizator folosind unul din multitudinea de sisteme de codificare existente. (n particular, sistemul de codificare implicit folosete funcia UNIX crypt pentru a codifica parola). Pentru a activa funcia de autorizare pentru, de exemplu, un director trebuie creat un fiier .htaccess n directorul care trebuie restricionat, care s conin minim urmtoarele: AuthName mod_auth proiectweb AuthType Basic AuthUserFile /www/apache/auth/userfile require valid user AuthName definete domeniul de autorizare, AuthType specific tipul autorizrii dorit (Basic sau Digest). AuthUserFile indic spre fiierul de utilizatori generat cu htpasswd, iar require specific lista utilizatorilor cu drept de acces (n exemplu se permite accesul oricrui utilizator valid din fiierul userfile). Autentificarea prin baz de date n cazul sistemelor cu un numr de utilizatori relativ mic autentificarea simpl este absolut suficient. Problema apare n cazul sistemelor cu foarte muli utilizatori. Deoarece folosete fiiere text neindexate pentru stocarea datelor despre utilizatori i parole, n cazul unui numr mare de utilizatori, la fiecare autentificare trebuie deschis acel fiier text, executat o comparaie ntre fiecare nume de utilizator i rndurile din fiier pn la gsirea utilizatorului sau pn la sfritul fiierului.Aceast operaie este mare consumatoare de timp! Prin urmare, n cazul unui numr mre de utilizatori trebuie folosit alt metod de stocare i gsire ulterioar a informaiei: baza de date. n funcie de baza de date folosit se vor folosi modulele de autentificare prin baze de date aferente:

MODULUL mod_auth_db mod_auth_dbm mod_auth_mysql mod_auth_ora7 mod_auth_ora8 mod_auth_pgsql mod_auth_tds mod_auth_solid Berkeley DB Unix DBM MySQL

Baza de date aferent modulului

Oracle versiunea 7 Oracle versiunea 8 PostgreSQL Microsoft SQL Server i Sybase Solid

Configuraia implicit a serverului Apache include modulul mod_auth_db. Pentru a crea o baz de date cu datele utilizatorilor se folosete un script, aflat, n mod implicit, n directorul /usr/bin/dbmmanage. Acest script este asemntor scriptului htpasswd folosit n cazul autentificrii simple. Apelarea dbmmanage fr nici un argument determin listarea tuturor opiunilor disponibile. De exemplu, pentru crearea unei baze de date i adugarea utilizatorului proiectweb se va folosi urmtoarea comand: #dbmmanage /www/apache/auth/dbpasswds add user proiectweb New password: Re-type new password User proiectweb added with password encrypted to hFdc5CfzT.3Phg Autorizarea prin baza de date este uor de activat, funcionnd la fel ca i autentificarea simpl: AuthName DB auth proiectweb AuthType Basic AuthDBUserFile /www/apache/auth/dbpasswds require valid-user AuthDBAuthoritative Off

Fa de directivele de la autentificarea simpl intervine directiva AuthDBAuthoritative Off care specific faptul c acreditrile utilizatorului trebuie trimise modulelor de autentificare de nivel inferior din lista modulelor Apache.(Aceast list este specificat n fiierul de configurare naintea directivei AddModule mod_auth_dbm).

Bibliografie: Charles Aulds - Linux, Administrarea serverului Apache, 2002, ed. Teora Julie C. Meloni - nva singur PHP, MySQL si Apache, 2005, ed. Corint Apache Site - Apache HTTP Server Version 2.0 OnLine Documentation Christopher Negus Red Hat Linux 8, ed. Teora