Apache'i veebiserver

Allikas: Kuutõrvaja

Veebiressursside kasutusõigus

Veebiserveri konfigureerimisel on väga oluline näidata, mida vastuseks külastaja päringule tohib teha või saata või kas üldse külastajat teenindada.

Direktiiv Option

Direktiivi Options abil saab määratleda, mida kataloogis leiduvate failidega lubatakse teha. Näiteks määrates minimaalsed õigused parameetriga None, saab kataloogis sisalduvate failide poole pöörduda vaid nimeliselt; failide nimekirja ei näidata. 

Options None

Muud võimalused:

  • FollowSymLinks - kui brauser esitatud päringus on failinimi viide, siis seda järgitakse vaatamata, kas viidatav fail kuulub samale kasutajale kui viide
  • SymLinksIfOwnerMatch - kui brauser esitatud päringus on failinimi viide, siis seda järgitakse juhul, kas viidatav fail kuulub samale kasutajale kellele viide
  • Indexes - näidatakse serveri kataloogi failide nimekirja kui DirectoryIndexis näidatud faile ei leitud
  • ExecCGI - CGI skriptide kasutamiseks
  • Includes - SSI failide kasutamiseks
  • IncludesNOEXEC - SSI failide kasutamiseks, va #exec ja CGI skriptide #include
  • All - kõik eelnimetatu on lubatud

Korraga võib määratleda ka mitu parameetrit, eraldades nad üksteisest tühikuga.

Kui konfiguratsioonifailis kasutada mitmel Options direktiivi, jääb kehtima viimane. Lisades parameetri algusesse + või - märgi, lisatakse või eemaldatakse vastav toime. Näiteks kasutades direktiive 

Options Indexes Includes FollowSymLinks
Options -FollowSymLinks

on toime samaväärne avaldisega 

Options Indexes Includes

Direktiivi Options vaikeväärtus on All.

Direktiivid Allow, Deny ja Order

Direktiividega Allow, Deny ning Order abil saab kehtestada, millistelt domeenidelt tulevaid päringuid teenidatakse. Orderi abil seatakse, millises järjekorras kontroll toimub, kusjuures rakendatakse viimast reeglit, millega külastaja domeeninimi klapib. Kui ükski reegel ei klapi, toimitakse vaikimisi nagu viimane Orderi parameeter näitab. Näiteks sellise sektsiooni puhul 

Order Deny,Allow
Deny from all
Allow from zoo.tartu.ee

Päringut domeenist zoo.tartu.ee teenindatakse, esimene reegel (Deny) keelab kõik, kuid teine (Allow) lubab domeeni zoo.tartu.ee. Kui Order oleks vastupidi, siis lubaks esimene reegel (Allow) zoo.tartu.ee, kuid kehtima jääks viimane reegel (Deny). Reeglite järjekord failis ei loe, kuna selle määrab Order.

Järgmises näites on lubatud päringud vaid tartu.ee domeenist, va alamdomeen zoo.tartu.ee 

Order Allow,Deny
Allow from tartu.ee
Deny from zoo.tartu.ee

Tõepoolest, päringut foo.tartu.ee domeenist teenindatakse kuna ta klapib esimese (Allow) reegliga, mis lubab ning teisega, mis keelab mitte. Päringuid muudest domeenidest keelatakse, kuna nad ei klapi kummagi reegliga ning vaikimisi rakendatakse viimast Orderi parameetrit - Deny.

Order, Deny ja Allow direktiive saab kasutada vaid direktiivi Directory sees ning Deny ja Allow tuleb eraldada ainult täpselt ühe komaga!

Veebiressursside grupeerimisvahendid

Veebiserveri kasutusõigust ning teisi omadusi reguleerivaid parameetreid saab grupeerida järgmiste direktiividega 

   * Directory - kataloogis ning selle alla jäävate alamkataloogides sisalduvate failide grupeerimiseks
   * Files - faili nimede järgi failide grupeerimiseks
   * Location - URLi ning selle alla jäävate URLide grupeerimiseks

Sellistele gruppidele saab rakendada korraga samu määratlusi, näiteks Option parameetriga.

Directory direktiiv

Directory abil saab määrata näidatud kataloogi alla jäävatele failidele ühesuguseid omadusi. Näiteks kehtestame, et kataloogi /html/veeb/kalamaja alla jäävates kataloogides käsitletakse DirectoryIndexina faile index.html ja index.htm 

<Directory /html/veeb/kalamaja>
DirectoryIndex index.html index.htm
</Directory>

Files direktiiv

Sarnaselt Directory'le saab kehtestada näidatud regulaaravaldisega klappivate failinimedega failidele ühesuguseid omadusi. Näiteks kehtestame, et failides, mille nimi algab tähtedega "e_" ja lõpeb .html-ga, tohivad sisaldada Embperli konstruktsioone 

<Files ~ "^e_.*\.html$">
Options +ExecCGI
SetHandler perl-script
PerlHandler HTML::Embperl
</Files>

Location direktiiv

Sarnaselt Directory direktiivile saab Locationiga kehtestada osale veebikohale samasuguseid omadusi. Location mõjub mitte kataloogistruktuuri, vaid URLi mõttes hulgale elementidele. Näiteks kehtestame, et URL'ist http://kalake.zoo.edu.ee/hobused edasi tohib näha kataloogide nimekirja 

<Location /hobused>
Options Indexes
</Location>

Tavaliselt piisab Directory kasutamisest, kuid kuna veebiserveri kataloogi-ja URLihierarhia ei pruugi alati kokku langeda, siis on sellest vahel abi.

Kataloogipõhine veebiserveri konfigureerimine

Veebiserveri põhikonfiguratsioonifailis näidatud väärtusi saab iga kataloogi jaoks täpsustavalt määrata kataloogis sisalduva konfiguratsiooni .htaccess faili abil. Selle faili nimi on määratud põhikonfiguratsioonifailis direktiiviga AccessFileName, mis peab esinema Directory sees. Faili süntaks on sama, mis põhikonfiguratsioonifailil. Seda, milliseid omadusi on ludatud .htaccess failiga täpsustada, näitab põhikonfiguratsioonifailis direktiiv AllowOverride; järgmistele parameeritele vastab voli muuta toodud parameetreid

  • AuthConfig - AuthGroupFile, AuthName, AuthType, AuthUserFile, Require jne
  • FileInfo - AddEncoding, AddLanguage, AddType, DefaultType, ErrorDocument jne
  • Indexes - DirectoryIndex, AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName jne
  • Limit - Order, Allow, Deny
  • Options - Options, XBitHack
  • None - mitte midagi
  • All - kõik nimetatud

Vaikimisi toimib parameeter All. Kui ei soovita lasta kasutajatel veebiserverit konfigureerida, siis kasutage peale veebiserveri põhiosa direktiivi 

AllowOverride None

.htaccess failis tohib kasutada direktiivi Files, aga ei saa kasutada Diectory või Location.

Tavaliselt on ohutu ning kasutajaile piisav 

AllowOverride Indexes AuthConfig

Alias

Direktiiv Alias võimaldab muuta veebi failile kataloogistruktuuri vastavust URLi struktuurile. Näiteks olgu kataloogis /html/veeb/hobused/2000/tyrinaitus/ehola_talu failid ning soovime neile ligi pääseda URLiga http://www.zoo.tartu.ee/ehola_talu. Kasutame sellist Aliast 

Alias /ehola_talu/ /html/veeb/hobused/2000/tyrinaitus/ehola_talu/

Antud juhul laheneb päring http://www.zoo.tartu.ee/ehola_talu/, kuid mitte http://www.zoo.tartu.ee/ehola_talu.

Lisaks saab Aliasega kaasata veebi faile ning katalooge, mis asuvad failisüsteemi mõttes väljaspool DocumentRootu. 

Alias /valdek/ /html/valdek/veeb/

Aliase süntaks on järgmine 

Alias URLi-tee kataloogi-tee

kus

Aliasi saab kasutada peakonfiguratsioonifailis või võrdväärsetes kohtades, näiteks VirtualHost sektsioonis. Aliaste kasutamisel tuleb tavaliselt kasutada kataloogi tee'le vastavaid Directory direktiive, muutmaks sobivaks veebiosa kasutusõigused. Aliased loetakse läbi enne Directory sektsioone.

Aliase kasutamisel tuleb tähele panna, et URLi tee asendatakse igal juhul kataloogiteega. Kas sel juhul, kui päring on pikem, kooskõlas kasutatud näitega päringu http://www.zoo.tartu.ee/ehola_talu/ratsahobused/piiker.html puhul esitatakse fail /html/veeb/hobused/2000/tyrinaitus/ehola_talu/ratsahobused/piiker.html.

Kui on vaja teha vaid ümbersuunamisi võib kasutada redirectPermanent näiteks 

redirectPermanent /URI/TO/OLD/REQUEST/ [url...]

Soovides teha paindlikumaid nö ümberkirjutusi, kasutage mod_rewrite'i võimalusi.

CGI

CGI kasutamiseks lisage konfiguratsioonifaili rida 

AddHandler cgi-script .cgi .pl

Tulemusena püüab veebiserver käivitada kõiki serveeritavaid .cgi ja .pl lõpuliste nimedega faile, eeldusel, et failile rakendub Optioni parameeter ExecCGI. Käivitamisel tekkiv programmiväljund saadetakse brauserisse, kusjuures see peab algama tuntud Content-type'iga, näiteks text/html. Seda võib teha näiteks Directory abil; kehtestame, et kõikjal veebi faile sisaldavas kataloogis /html/veeb/suhtleja ja selle all asuvad .cgi ja .pl lõpuliste nimedega failid on käivitatavad 

<Directory /suhtleja>
Options ExecCGI
</Directory>

Soovides näidata, et vaatamata failinimele tuleb käsitleda faili CGI skriptina, kasutage ScriptAlias direktiivi. Tüüpiliselt määratletakse URLi http://kalake.zoo.tartu.ee/cgi-bin/'le vastavad failid skriptideks 

ScriptAlias /cgi-bin/ /html/veeb/cgi-bin/

Tulemusena, näiteks päringu http://kalake.zoo.tartu.ee/cgi-bin/kasutajatenimikiri.sh puhul käivitatakse fail /html/veeb/cgi-bin/kasutajatenimekiri.sh.

SSI

SSI (Server Sides Includes) tehnika võimaldab sisestada brauseri päringus nõutud faili koosseisu muude failide sisu.

SSI kasutamiseks lisage konfiguratsioonifaili rida 

AddType text/html .shtml
AddHandler server-parsed .shtml

ning näidake näiteks direktiivide Directory ja Options parameetri Includes abil, milliseid faile tohib server käsitleda SSIdena. Näiteks kehtestame, et kataloogi /html/veeb/uudised all kasutatakse SSId 

<Directory /html/veeb/uudised<>
Options IncludesNOEXEC
</Directory>

Tulemusena saab failides, mille nime lõpus on .shtml, kasutada SSI konstruktsioone, va #exec ja CGI skriptide #include.

Embperl

Embperl on tehnika, mis võimaldab sisestada HTML koodi sisse Perli konstruktsioone. Selle võimaluse kasutamiseks lisage konfiguratsioonifaili 

<Files ~ "\.html$">
Options ExecCGI
SetHandler perl-script
PerlHandler HTML::Embperl
</Files>

Tulmusena lahendab veebiserver failides, mille nime lõpetab .html sisalduva Perli koodi.

Muuseas, Embperli rakendamisel on veebiserver ka tavalise HTML süntaksi osas oluliselt rangem. Tüüpiliselt ei meeldi talle [# jne järgnevused, mida kasutatakse Embperli skriptide tähistamiseks. Et neid sümboleid siiski kasutada saada, esitage neid a la &#kood;, näiteks <.

PHP

PHP on tehnika, mis võimaldab lisada HTML koodi sisse PHP keele konstruktsioone. Selle võimaluse kasutamiseks lisage konfiguratsioonifaili 

AddType application/x-httpd-php .php

Veebiserverisse konfigureeritud PHP omadusi saab näha PHP skriptiga 

<?
phpinfo();
?>

Serveri kasutajate kodulehed

Vaikimisi eeldab veebiserver, et näiteks URLile http://www.zoo.tartu.ee/~priit vastab süsteemi kasutaja priit kodukataloogis olev kataloog public_html. Selle kataloogi nime määrab direktiiv UserDir.

Veebi kaitsmine parooliga

Apache pakub vahendid veebistruktuuri kaitsmiseks parooliga. Konfiguratsioonifailis näidatakse ära, millist ressurssi kaitsta ning millist autentimissüsteemi kasutada.

Kõige lihtsamal juhul tuleb programmiga htpasswd genereerida lubatud külastajate paroolifail, milles on kirjas kasutajanimed ning vastavad paroolid. See fail on reeglina erinev süsteemi paroolifailist, kus veebiserver töötab. Kui külastaja püüab siseneda kaitstud veebi, avaneb dialoog ning küsitakse tema kasutajanime ning parooli. Sobiva paari sisestamisel lubatakse külastaja veebile ligi, kusjuures kõnealust veebi saab kasutada kuni brauseri sulgemiseni.

Näiteks kaitseme kataloogistruktuuri /html/salajane kirjeldatud paroolikontrolliga 

<Directory /html/salajane>
AuthUserFile /usr/local/apache/conf/salajane.paroolifail
AuthType Basic
AuthName Salajane
require valid-user
</Directory>

kus on kasutatud direktiive:

  • AuthUserFile - paroolifailinimi, /usr/local/apache/conf/salajane.paroolifail
  • AuthType - millist tüüpi autentimisega on tegemist, antud juhul Basic
  • AuthName - parameetri väärtust näidatakse aknas, kuhu kasutaja sisestab oma veebi kasutajanime ja parooli; sama veebi piires saab sama kasutajanimega seostada erinevaid paroole, mistõttu peab külastaja saama teada, millist parooli konkreetsel juhul tarvitada
  • require valid-user - sellele ressursile lastakse ligi vaid peale edukat autentimist

Sobiv paroolifail moodustatakse programmiga htpasswd 

bash$ htpasswd -b -c -m salajane.paroolifail priit priiduparool

kus

  1. -b kasutaja parooliks loetakse käsurea viimane sõna (priiduparool)
  2. -c seda võtit tuleb kasutada vaid siis, kui paroolifaili veel ei eksisteeri; edaspidi peab selle võtme ära jätma, sest muidu kustutatakse olemasoleva paroolifaili sisu
  3. -m kasutada MD5 krüptimist; jättes selle võtme kirjutamata tekitatakse CRYPT proolid
  4. järgnevad paroolifaili nimi (salajane.paroolifail) ja kasutajanimi (priit)

Lisaks direktiivile Directory saab autentimist kasutada ka Location sektsioonis, mis on veebi suhtes veelgi asjakohasem.

Paroolifail peab olema loetav sellele kasutajale, kelle õigustes veebiserver töötab (näiteks nobody) ning soovitavalt mitte olema veebiga samas kataloogistruktuuris.

Lisaks paroolifailile saab kasutajaid autentida nt LDAP kataloogi vastu. Selleks peavad olema laaditud moodulid mod_ldap.so ja mod_authnz_ldap.so (tulevad apache v 2.2 kaasa), olema kirjeldatud kataloog, talle üle võrgu ligi pääsema ning veebiserveris sobib kasutada seadistusfaili põhiosas 

 LDAPTrustedGlobalCert CA_BASE64 /etc/apache2/serdid/ldap-server-juur.pem
 LDAPCacheTTL 5
 LDAPOpCacheTTL 5

ja VirtualHostis sarnast sektsiooni 

 <Directory /html/salajane>
   AuthBasicProvider ldap
   AuthType Basic
   AuthName Salajane
   AuthLDAPURL "ldaps://ldap.loomaed.tartu.ee:636/dc=loomaaed"
   AuthLDAPGroupAttribute memberUid
   AuthLDAPGroupAttributeIsDN Off
   Require ldap-group cn=httpkasutajad, ou=group, dc=loomaaed
</Directory>

Antud näite puhul on LDAP kataloogi kasutaja sissekanne selline 

 dn: cn=mart,ou=user,dc=loomaaed
 givenName: Mart
 sn: mart
 cn: mart
 objectClass: inetOrgPerson
 objectClass: top
 objectClass: posixAccount
 gidNumber: 2003
 uidNumber: 2003
 structuralObjectClass: inetOrgPerson
 entryUUID: 5437c6e4-ed91-102b-938e-db2597f32702
 creatorsName: cn=admin,dc=loomaaed
 createTimestamp: 20070902111351Z
 uid: mart
 loginShell: /bin/bash
 homeDirectory: /home/mart
 userPassword:: e0NSWVBUfXV1Qnc2TTg5UmguSS5=
 entryCSN: 20071118172621Z#000000#00#000000
 modifiersName: cn=admin,dc=loomaaed
 modifyTimestamp: 20071118172621Z

ning grupp kuhu ta kuulub 

 dn: cn=httpkasutajad,ou=group,dc=loomaaed
 cn: httpkasutajad
 gidNumber: 2001
 objectClass: posixGroup
 objectClass: top
 structuralObjectClass: posixGroup
 entryUUID: f9a6b924-755e-102b-89bd-8f8581e3c38e
 creatorsName: cn=admin,dc=loomaaed
 createTimestamp: 20070402121104Z
 memberUid: priit
 memberUid: mart
 entryCSN: 20071118172843Z#000000#00#000000
 modifiersName: cn=admin,dc=sise
 modifyTimestamp: 20071118172843Z

Logi

Apache veebiserveriga saab logida tekstifaili erinevatel tingimustel toimunud päringuid ning neid logifaile automaatselt roteerida. Logida saab paraleelselt ka näidatud tingimustele erinevates formaatides erinevatesse failidesse.

Direktiiviga LogFormat kirjeldatakse mida logitakse. Tüüpiliselt defineeritakse formaat nimega tavaline 

LogFormat "%h %l %u %t \"%r\" %>s %b" tavaline

kus

  •  %h - maisinanimi, kust päring esitati
  •  %l - kasutajanimi, kes päringu esitas eeldusel, et IdentityCheck tomib; tavaliselt see väli jääb tühjaks, kuna IdentityCheck'i kasutamine võtab tublisti veebi kiirust alla
  •  %u - kui veebiserveri ressurss nõudis autentimist, siis kasutatud kasutajanimi
  •  %t - päringu esitamise aeg
  • \"%r\" - jutumärkides esitatud päringu esimene rida
  •  %>s - päringule vastuse olek (ingl. k. status)
  •  %b - päringu vastuse maht baitides
  • tavaline - logiformaadi nimi

Logimine ise toimub direktiiviga CustomLog, näiteks logime, kasutades logiformaati tavaline, faili /var/log/apache/tavaline.log 

CustomLog /var/log/apache/tavaline.log tavaline

Soovides logifaili automaatselt roteerida, kasutage veebiserveriga kaasas olevat programmi rotatelogs. Näiteks moodustame iga nädal uue logi 

CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/apache/tavaline.log 604800" common

Logi faili nimi moodustatakse lisades failinime lõppu aja sekundites, mis on möödunud UNIXi ajastu algusest, so 1970. 1. jaanuar kell 00:00 hommikul.

Vealogi

Vealogisse salvestatakse serveri töös toimunud vead, sh näiteks päringud puuduvatele failidele. Logitaset saab reguleerida direktiiviga LogLevel, soovitatakse taset warn 

LogLevel warn

Direktiiviga ErrorLog näidatakse, kuhu logi salvestada 

ErrorLog /var/log/apache/error.log

Logianalüsaatorid

Apache veebiserveri logi analüüsiks sobib kasutada näiteks programmi Webalizer.

Veebiserveri staatus ja info

Eeldusel, et veebiserverisse on sissekompilleeritud vastavad moodulid võtmetega --enable-module=status ja --enable-module=info, saab näha veebiserveri konfiguratsiooni (info) ning parasjagu olevat seisu (status).

Näidates konfiguratsioonifailis direktiivi ExtendedStatus parameetriks "On", esitatakse staatus põhjalikumalt.

Nende veebiserveri omaduste nägemiseks peab sisalduma konfiguratsioonifailis kaks sektsiooni

URLi http://www.zoo.tartu.ee/status-info jaoks 

<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from .zoo.tartu.ee
</Location>

URLi http://www.zoo.tartu.ee/server-info jaoks 

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from .zoo.tartu.ee
</Location>

Mõlemas sektsioonis on kasutatud Deny ja Allow direktiive, piiramaks nende URLide külastamise õigust. Kuigi sealt midagi väga salajast ei paista, on külastama lubatud vaid zoo.tart.ee domeeni masinastest.

Veebi-indekseerijad

Apache veebiserver ei sisalda indekseerimisvahendeid, so võimalusi luua serveeritavale veebile otsingumootorit. Küll aga sobib kasutada mõnda olemasolevat veebiindeksaatorit, näiteks Glimpse või HtDig.

Hoopis teine probleem on kuidas kontrollida, mida tohivad teha teised otsingumootorid (tuntud kui robotid või nuhid) teie veebi külastades. Tüüpiliselt tuleb neid kontrollida, kuna nad võivad täita avalikke andmebaase kiiresti vananeva infoga või ebasoovitavalt teie serverit koormata.

URLi ümberkirjutamine

Ümberkirjutamise kasutamiseks on vaja mod_rewrite'i toetus serverisse kompilleerida võtmega --enable-module=rewrite.

See tehnika võimaldab suunata serverisse tulevad päringud ümber, jäädes sama serveri piiridesse või välja. Ümbersuunamisi saab konfigureerida peakonfiguratsioonifailist või .htaccess failist.

Ümbersuunamisel saab kasutada tingimusi või teha seda juhuslikult.

Tõenäoliselt on võimalik järgnevalt näidetena toodud tegevusi korraldada ka muude vahenditega, URLi ümberkirjutamine mod_rewrite'ga on selleks üks käepärane vahend.

Ümberkirjutuste tegemiseks tuleb esmalt aktiviseerida ümberkirjutusmehhanism 

RewriteEngine On

Ümberkirjutust ennast teostab direktiiv RewriteRule. Näiteks suuname kõik veebiserverisse kasutajale priit tulevad päringud (http://www.zoo.tartu.ee/~priit) aadressile http://www.priit.ee 

RewriteRule ^/~priit.+ http://www.priit.ee

Direktiivi RewriteRule esimene argument on regulaaravaldis (^/~priit.+) ning kui sellega päring klapib, siis suunatakse brauser teise parameetriga näidatud URLile (http://www.priit.ee). Kasutaja brauseri Location real kirjutatakse URL paratamatult ümber.

Direktiivi süntaks on järmine 

RewriteRule regulaaravaldis asendus [võtmed]

kus

  • regulaararvaldisega kontrollitakse, kas URL klapib ümberkirjutamisreegliga, kusjuures URL on antud juhul see osa päringust, mis jääb paremale http://www.zoo.tartu.ee'st, näite puhul /~priit.
  • kui URL klappis, siis asendatakse URL asendusega 'asendus'
  • lisaks on mõnel juhul oluline kasutada võtmeid, mis kontrollivad ümberkirjutamise peensusi

^ tähistab, et / peab olema URLi esimene sümbol ning peale priit 't' tähte võib tulla kuitahes palju mistahes sümboleid (.+). Muuseas, antud juhul suunatakse ümber näiteks päring http://www.zoo.tartu.ee/~priit-onvastmees.

Lubatud on kasutada järjest mitmeid asendusi, mil neid rakendatakse järjest, tulemuseks on viimane tehtud ümberkirjutus. Järgmise asenduse regulaaravaldist klapitatakse eelmise ümberkirjutamisel tehtud tulemusega.

Esitame näite sisemise ning välimise ümberkirjutamise kohta. Soovides vastuseks päringule http://www.zoo.tartu.ee/vana.html brauserisse saata lehe uus.html, kusjuures jättes brauseri Location reale esialgse teksti, so http://www.zoo.tartu.ee/vana.html, kasutage ümberkirjutamisreeglit 

RewriteRule    ^vana\.html$  uus.html

Sama, kuid brauseri Location real kajastub ümberkirjutus 

RewriteRule    ^vana\.html$  uus.html [R]

^vana\.html$ tähendab, et asendus toimub, kui päring oli täpselt vana.html, so algas v-ga (^) ja lõppes l-ga ($); punkt on regulaaravaldise erisümbol ja tuleb põgeda (\).

Kirjutades järjest mitu ümberkirjutusreeglit ning soovides, et ümberkirjutamine lõppeks antud reegliga, tuleb reegli lõppu lisada võti L (last). 

RewriteRule ^/~priit.+ http://www.priit.ee [R,L]
RewriteRule ^/~nea.+   http://www.nea.ee   [R,L]
RewriteRule ^/~inna.+  http://www.inna.ee  [R,L]
RewriteRule ^/~mart.+  http://www.mart.ee  [R,L]

Kui aga veebiserverit tõstetakse ühest masinast teise, oletame, et uus töötab, kuid kasutajate kodud on vanas, siis lisage uue konfi selline rida 

RewriteRule   ^/~(.+)  http://vana.zoo.edu.ee/~$1  [R,L]

Siin on kasutatud regulaaravaldist koos asendamisega. $1 asendatakse tekstiga, mis klappis kasutatud regulaaravaldises avaldisega (.+). Praktiliselt näiteks

Jäigalt kogu veebisaidi juure ümber kirjutamiseks sobib 

RewriteRule .* https://uusveeb.zoo.tartu.ee/ [R,L]

Võime panna kaks erinevat reeglit kokku stiilis 

RewriteRule   ^/(.+)  https://uusveeb.zoo.tartu.ee/$1  [R,L]
RewriteRule .* https://uusveeb.zoo.tartu.ee/ [R,L]

Sellisel juhul kui pöördutakse aadressile http://vanaveeb.zoo.tartu.ee/mart suunatakse ta ümber http://uusveeb.zoo.tartu.ee/mart ja lõpetatakse reegel. Kui aga pole antud mingit parameetrit urli järele pöördutakse järgmise rea poole mis suunab otse antud saidile.

Lisatingimuste kasutamine

Direktiiv RewriteRule teostab ümberkirjutusi niikuinii tingimusi kasutades regulaaravaldise abil. Peale selle saab seada direktiiviga RewriteCond lisatingimusi. Näiteks sõltuvalt serveri kellaajast, saadetakse brauserile üks või teine veeb 

RewriteEngine on
RewriteCond   %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond   %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule   ^index\.html$             paev.html

RewriteRule   ^index\.html$             oo.html

%{TIME_HOUR} asendatakse päringu sooritamise kellaaja tunniväärtusega. Oluline on kirjutada < ja 0700 järjest, kusjuues toimub leksikograafiline stringide, mitte arvude võrdlus.

Kui brauser esitab veebiserverile päringu päeval, siis toimub ümberkirjutus index.html -> paev, kuna esimese direktiivi RewriteRule regulaaravaldis klappis URLiga ning kõik eelnenud lisatingimused olid täidetud. Seejärel klapitatakse teist RewriteRule'i eelmise väljundiga, so paev.html - ei klapi ning midagi ei kirjutata ümber.

Lisatingimusi on sobiv kasutada ka brauserite eristamiseks. 

RewriteCond  %{HTTP_USER_AGENT} Mozilla/4*
RewriteRule  ^leht.html$                leht.moz.html [L]

RewriteCond  %{HTTP_USER_AGENT} Lynx.*
RewriteRule  ^leht.html$                leht.lynx.html [L]

Sõltuvalt päringu tegija aadressist, saab esitada erinevat veebi. 

RewriteCond  %{REMOTE_ADDR}  ^192.168.1.3$ 
RewriteRule  ^leht.html$      192.168.1.3.html [L]

Ümberkirjutusalus

Kui te tegutsete sügavamal URLi-struktuuri sees, kasutage RewriteRule'i juurika ümbernimetamiseks direktiivi RewriteBase. Näiteks kirjutatakse URL http://www.zoo.tartu.ee/~priit/lemmikud/hobused.html ümber URLiks http://www.zoo.tartu.ee/~priit/lemmikud/kabjaksed.html 

RewriteBase   /~priit/lemmikud
RewriteRule   ^hobused.html$  kabjaksed.html

Ümberkirjutustabel

Esitatud päringu juhuslikult valitud URLile ümbersuunamiseks on sobiv kasutada direktiivi RewriteMap. RewriteMap pakub võimaluse salvestada tekstifaili hulga URLe, mille poole saab ümberkirjutusreeglist pöörduda. Näiteks loome olukorra, kus päringule http://www.zoo.tartu.ee/juhuslik vastatakse juhuslikult valitud veebilehega.

Kirjeldame tabelikirjeldusfailis vl.txt juhuslike veebilehtede nimed 

# cat /usr/local/apache/vl.txt
veebilehed 1.html|2.html|3.html|4.html|5.html|6.html|7.html

ning lisame veebiserveri konfiguratsioonifaili read 

RewriteMap vl rnd:/usr/local/apache/vl.txt
RewriteRule   ^/juhus$   /home/html/juhus/${vl:veebilehed|html.html}

Ümberkirjutustabeli süntaks on selline

RewriteMap tablelinimi tabelitüüp:tabelikirjeldusfail

kus

  • tabelinimi - on kooskõlas ümberkirjutusreeglis kasutatud nimega
  • tabelitüüp - rnd (random) näitab et
  • tabelikirjeldusfail - failis kirjeldatakse tabeli sisu, näiteks juhusliku puhul peab eraldama andmed |-ga (loogiline OR)

Ümberkirjutusreegli asenduses kasutatud muutujat ${vl:veebilehed|html.html} väärtustatakse ümberkirjutustabeli vl võtme veeblilehed abil. Kui sellist ümberkirjutustabelit mingil põhjusel pole, on muutuja väärtus html.html.

Ümberkirjutuslogi

Ümberkirjutamise tööleseadmisel ning toimuvate ümberkirjutuste jälgimiseks saab kasutada direktiive RewriteLog ja RewriteLogLevel 

RewriteLogLevel 3
RewriteLog /var/log/apache/rewrite.log

Veebiserveri konfiguratsioonifaili lugemine

Lihtsamatel juhtudel pole see oluline, millises järjekorras veebiserver direktiivides esitatud reegleid kehtestab. Näiteks, kui konfiguratsioonifailis ei sisaldugi Location ja Files sektsioone, kuid soovides kasutada veebiseverit paindlikumalt, tuleb järjekorraga arvestada.

Direktiivide puhul ei hooli Apache suurtest ja väikestest tähtedest, kuid parameetrite puhul on see tihti oluline.

Eeldusel, et te paigutate kogu konfiguratsiooni ühte faili, sisalduvad seal kaks osa

  • põhiosa - kirjeldatakse veebiserveri üldisi omadusi, näiteks millise kasutaja õigustes ta töötab
  • ressursside määrangud - kehtestatakse reeglid, kuidas veebiserver faile serveerib, näiteks käsitleb .php lõpulisi faile PHP skriptidena

Üldosa direktiivide järjekord pole oluline, kui sama direktiiv on väärtustatud mitu korda, jääb kehtima viimane väärtus.

Kui ressursside omadusi määratakse grupeerimisvahendite abil, siis sõltumata konfigureerimisfailis esinemise järjekorrast, loetakse neid sellises järjekorras: Directory, Files, Location

Directory sees võivad olla kirjeldatud omakorda Files sektsioonid.

Directory sees on lubatud kasutada järgmisi direktiive:

  • DirectoryIndex
  • Options
  • Order, Allow, Deny
  • AllowOverride
  • AddHandler
  • AddType

Files sektsioonis on lubatud kasutada praktiliselt samasid direktiive, mida sektsioonis Directory eeldusel, et neid on mõistlik rakendada failidele. Ilmselt ei saa kasutada näiteks direktiivi DirectoryIndex, küll aga näiteks Allow ja Deny.

Location sektsioonis on lubatud kasutada praktiliselt samasid direktiive, mida sektsioonis Directory. Kuna Locationit rakedatakse kõige viimasena, siis ei saa seal näiteks kasutada Options direktiivi, küll aga näiteks Allow ja Deny'id.

Virtuaalveebiserverid

Ühte ja sama Apache veebiserverit saab tööle seada nii, et ta serveerib erinevaid andmeid sõltuvalt sellest, millise nimega tema poole pöörduti. Asjakorraldust nimetatakse virtuaalseteks veebiserveriteks, kuna füüsiliselt on tegu ühe arvutiga, kuid külastajaile jäetakse mulje, et neid on mitu.

Virtuaalseid veebiservereid on kolme sorti:

  • pordipõhised - sõltuvalt külastaja poolt kastatud pordist serveeritakse erinevat veebi
  • IP-põhised - sõltuvalt külastaja poolt kasutatud IP-aadressist serveeritakse erinevat veebi
  • nimepõhised - sõltuvalt külastaja poolt kasutatud DNSi nimest serveeritakse erinevat veebi; reeglina vastavad erinevad nimed samale IP-aadressile, so on kirjeldatud CNAMEdena.

Põhimõtteliselt on võimalik kasutada neid virtuaalservereid ka kombineeritult korraga.

Erijuht virtuaalveebi serveerida, on käivitada mitu eksemplari httpd servereid, iga oma konfiguratsiooniga. Kuna see võimalus on suhteliselt ebaefektiivne ning ei paku olulisi täiendavaid võimalusi, siis seda me ei käsitle.

Virtuaalserveri sektsioonis (VirtualHost) saab kasutada paljusid direktiive, mida peaserveri puhul, sh direktiive Options, Alias, Directory, Location, Files. Samuti direktiive, mis reguleerivad SSI, CGI, PHP, Emperli, ümberkirjutamise ja logi kasutamist. Kui direktiivi ei näidata, kasutatakse põhikonfiguratsiooni väärtust, kui seal seda samuti pole, siis vaikeväärtust.

Pordipõhised virtuaalveebiserverid

Kasutamaks erinevaid veebiseveri konfiguratsioone sõltuvalt sellest, millisele pordile päring tuli, kasutage direktiive Listen ja VirtualHost. Näiteks teenindab veebiserveri konfiguratsioonifaili põhiosale vastav server kõiki päringuid, va neid, mis on suunatud aadressi 193.40.50.1 (www.zoo.edu.ee) pordile 8080 või pordile 8081. Viimast kahte teenindatakse vastavalt VirtualHosti sektsioonile. Näiteks seame lisaks põhiosale tööle kaks alternatiivset dokumendijuurikat ja logi

... 

Listen 80
Listen 193.40.50.1:8080
Listen 193.40.50.1:8081
<VirtualHost 193.40.50.1:8080>
   ServerAdmin mart@zoo.edu.ee
   DocumentRoot /www/mardizoo
   ErrorLog /var/logs/mardizoo.error.log
   CustomLog /var/logs/mardizoo.log common
 </VirtualHost>

<VirtualHost 193.40.50.1:8081>
   ServerAdmin priit@zoo.edu.ee
   DocumentRoot /www/priiduzoo
   ErrorLog /var/logs/priituzoo.error.log
   CustomLog /var/logs/priiduzoo.log common
</VirtualHost>

kusjuures peakonfiguratsiooni on lisatud vastavad Listen direktiivid.

Brauseris tuleb päringud esitada vastavalt http://www.zoo.edu.ee:8080 või http://www.zoo.edu.ee:8081.

IP-põhised virtuaalveebiserverid

IP-põhiste virtuaalveebiserverite kasutamisel on veebiserveril mitu IP-aadressi, st masinal on mitu võrgukaarti või on kasutatud IP-aliasingut.

IP-põhiste virtuaalveebiserverite kasutamisel näidake direktiivi VirtualHost juures ära IP-aadress ning samas sektsioonis kirjeldage kõnealuse veebiserveri omadused. Näiteks kui masinal on kaks võrgukaarti IP-aadressidega 193.40.10.1 ning 193.40.50.1, kasutage sektsioone 

<VirtualHost 193.40.50.1>
   ServerName www.zoo.tartu.ee
   ServerAdmin priit@zoo.tartu.ee
   DocumentRoot /www/tartuzoo
   ErrorLog /var/logs/tartuzoo.error.log
   CustomLog /var/logs/tartuzoo.log common
</VirtualHost>

<VirtualHost 193.40.10.1>
   ServerName www.zoo.edu.ee
   ServerAdmin mart@zoo.edu.ee
    DocumentRoot /www/eduzoo
    ErrorLog /var/logs/eduzoo.error.log
    CustomLog /var/logs/eduzoo.log common
</VirtualHost>

Peakonfiguratsiooni osa järgi teenindatakse neid päringuid, millel ei leidu sobivat virtuaalserverit. Näiteks kui masinal on veel kolmas võrguseade ning päring siseneb selle aadressile.

Virtuaalserveri direktiivi juurde võib kirjutada ka mitu IP-aadressi, mispuhul kasutatakse kõnealust serverit neile kõigile tulnud päringutele vastamisel.

Nimepõhised virtuaalveebiserverid

Nimepõhiste virtuaalveebiserverite kasutamine eeldab, et ühele IP-aadressile (193.40.50.1) on nimesüsteemis (DNS) seatud näiteks CNAMEiga vastavusse mitu domeeninime (www.zoo.tartu.ee, post.zoo.tartu.ee).

Kui soovite kasutada enam kui ühte veebiserverit, siis on soovitav kõik veebiserverid konfigureerida virtuaalseteks, kusjuures põhiserverile ei vastagi DocumentRoot'i.

Nimepõhiste virtuaalveebiserverite kasutamine deklareeritakse peakonfiguratsiooni osas direktiiviga NameVirtualHost. Direktiivi järel näidatakse IP-aadress, millele tulnud päringute teenindamisel kasutatakse sobivat VirtualHosti sektsiooni. Näiteks 

NameVirtualHost 193.40.50.1

puhul kasutatakse aadressile 193.40.50.1 saabunud päringute töötlemiseks sobiva domeeninimega (ServerName) VirtualHost sektsiooni.

Erinevad virtuaalserverid kirjeldatakse direktiiviga VirtualHost, näiteks sarnase sektsiooniga 

<VirtualHost 193.40.50.1>
    ServerName www.zoo.tartu.ee
    ServerAdmin priit@zoo.tartu.ee
    DocumentRoot /www
    ErrorLog /var/logs/www.error.log
    CustomLog /var/logs/www.log common
</VirtualHost>

<VirtualHost 193.40.50.1>
    ServerName post.zoo.tartu.ee
    ServerAdmin post@zoo.tartu.ee
    DocumentRoot /post
    ErrorLog /var/logs/post.error.log
    CustomLog /var/logs/post.log common
</VirtualHost>

Kui serveril on mitu võrguaadressi, siis võib kasutada direktiivi NameVirtualHost mitu korda ning lisada vastavad sektsioonid, kuid lühem on asendada IP-aadress tärniga (*) 

NameVirtualHost *

<VirtualHost *>
    ServerName www.zoo.tartu.ee
    ServerAdmin priit@zoo.tartu.ee
    DocumentRoot /www
    ErrorLog /var/logs/www.error.log
    CustomLog /var/logs/www.log common
</VirtualHost>

<VirtualHost *>
    ServerName post.zoo.tartu.ee
    ServerAdmin post@zoo.tartu.ee
    DocumentRoot /post
    ErrorLog /var/logs/post.error.log
    CustomLog /var/logs/post.log common
</VirtualHost>

Päringuid, mis saabuvad direktiiviga NameVirtualHost näidatud aadressile, ei teenindata IP-põhiste sektsioonide ega peaserveri konfiguratsiooni alusel.

Mod_proxy võimalused

Võimaldab näiteks suunata kasutaja päringud ümber mõnele teisele teenusele. Vahendamine seejuures on maskeeritud ning kasutaja näeb vaid põhisaiti/virtuaalhosti.

Laetud peavad olema moodulid

  • proxy_module
  • proxy_http_module

Suuname terve www.edu.ee domeeni ümber teisel serveri 8080 pordile 

<VirtualHost 193.40.0.10:80>
  ServerName www.edu.ee 
  ProxyPass         /  http://193.40.0.12:8080/
  ProxyPassReverse  /  http://193.40.0.12:8080/
        
</VirtualHost>

RPAF (Reverse proxy add forward) moodul

Kui veebiserveri ees kasutatakse nn kiirendavat proxy't, nt Squidi, siis paistavad veebiserveri logis läbi Squidi tehtud päringud olevat lähtunud Squidist ip aadressilt. Statistilist analüüsi saab küll teha ehk ka Squidi abil samuti, aga nt vigade otsimisel on otsekohesem kui veebiserveri logis esinevad külastajate õiged ip aadressid (mis üldiselt võivad olla ka mõned muud proxy'd, mida külastajad on otsustanud kasutada).

RPAF mooduli kasutamise tulemusena paistab veebiserverile päring lähtuvat kliendi ip aadressilt, st kliendi aadress esitatakse veebiserveri logis ja praktiliselt kõikjal, kus päringu lähte ip aadress veebiserveris mõju avaldada võiks. RPAF moodul saavutab sellise tulemuse Squidi poolt lisatava X-Forwarded-For päise kasutamisel, milles Squid ütleb kaasa tema poole pöördunud ip aadressi.

RPAF mooduli kasutamiseks tuleb veebiserverisse moodul laadida ning seadistada selliselt 

RPAFenable On
RPAFsethostname On    
RPAFproxy_ips 10.0.0.1

kus 10.0.0.1 aadress on Squidi proxy aadress. Arusaadavalt turvakaalutlustel tuleks olla tähelepanelik, milliseid Squid'e usaldatakse, oluline võiks see olla nt kui mõne veebiserveri ressursi kasutamist kontrollitakse ip aadressi põhiselt (kuigi siinkohal tasuks kaaluda hoopiski ligipääsu piiramist Squidi vahenditega).

SSL toe kasutamine

SSL toe kasutamine, mis paistab veebiserveri külastaja jaoks välja brauseri aadressrea alguses järgnevusena https://, nt 

 https://www.loomaaed.tartu.ee/cgi-bin/index.cgi

aitab kasutajal pidada üle avaliku interneti turvalist andmevahetust kõnealuse veebiserveriga. Praktiliselt tähendab see turvalisus seda, et

  • klient saab olla kindel, et ta suhtleb just selle serveriga, millega ta arvab end suhtlevat (muidugi mõningatel eeldusel, nt et kellegi kolmanda valduses ei ole serveri sertifikaati ja salajast võtit ning et lisaks ei trikita kliendi internetiühenduse ruutingu või nimelahendusega)
  • andmevahetus kliendi ja serveri vahel ei ole kolmandatele osapooltele sisulises osas jälgitav

See turvalisus põhineb asjaolul, et kaks osapoolt jagavad ühist saladust (nn sessioonivõtit, ingl. k. session key). Ühise saladuse kokkuleppimiseks kasutatakse avaliku võtme krüptograafiat, toimuvad järgmised sammud (põhimõtteliselt analoogiliselt SSH kliendi ja serveri vahelise ühise saladuse kokkuleppimsele)

  • veebiserver teab oma sertifikaati ja salajast võtit, tema sertifikaati võib lihtsustatult käsitleda avaliku võtmena
  • peale brauseri pöördumist veebiserveri poole saadab server talle oma sertifikaadi
  • brauser genereerib sessioonivõtme, krüptib selle serveri avaliku võtmega ning saadab serverile tagasi
  • server krüptib saadetise lahti ning tulemusena valdavad osapooled ühist saladust (nn sümmeetrilist võtit)

Siinjuures on oluline veel asjaolu, et brauser peab saama teha kindlaks, et veebiserveri sertifikaat ei ole võltsitud, nt mõne pahalase poolt talle ette sokutatud. Selleks tarbeks eksisteerivad PKI (Public Key Infrastructure) asutused (nt Sertifitseerimiskeskus, Thawte), mille ülesandeks on allkirjastada oma salajase võtmega veebiserveri sertifikaat. PKI salajasele võtmele vastav avalik võti (ehk sertifitseerija sertifikaat) on kõigile osalistele avalikult kättesaadav, paljud brauserid isegi vaikimisi sisaldavad neid. Niisiis, peale serveri sertifikaadi saamist kontrollib brauser sertifikaadi kehtivust ning seejärel jätkub sessiooni moodustamine.

Sõltuvalt vajadustest võib kasutada avalikku teenust pakkuva PKI asutuse teenuseid, moodustada ise oma PKI (nt tarkvara TinyCA abil, http://tinyca.sm-zone.net/) või lihtsalt genereerida sama veebiserveri sertifikaadile vastava salajase võtmega allkirjastatud veebiserveri sertifikaat - endasigneeritud sertifikaat (ingl. k. self-signed certificate) 

 $ openssl req -nodes -new -keyout www.loomaaed.tartu.ee.key -newkey rsa:1024 > www.loomaaed.tartu.ee.csr
 ...
 Country Name (2 letter code) [AU]: EE
 State or Province Name (full name) [Some-State]: Tartu
 Locality Name (eg, city) []:Tartu
 Organization Name (eg, company) [Internet Widgits Pty Ltd]: Tartu Loomaaed
 Organizational Unit Name (eg, section) []:
 Common Name (eg, YOUR name) []: www.loomaaed.tartu.ee
 Email Address []:

kus parooli küsimusele vastata Enteriga ning seejärel tekitada nn self-signed sertifikaat öeldes 

  $ openssl x509 -req -days 3650 -in www.loomaaed.tartu.ee.csr -signkey www.loomaaed.tartu.ee.key \ 
  -out www.loomaaed.tartu.ee.crt

Moodustatud sertifikaadi sisu saab esitada öeldes 

 $ openssl x509 -in www.loomaaed.tartu.ee.crt -noout -text

SSL-võimelise veebiserveri tööleseadmiseks on vajalikud kirjeldatud tegevuse tulemusena tekkinud endasigneeritud sertifikaat (www.loomaaed.tartu.ee.crt) ning vastav salajane võti (www.loomaaed.tartu.ee.key), mida allpool esitatud näites kasutatakse.

Apache 2.x veebiserverites sisaldub vaikimisi SSL tugi ja lisamooduleid pole vaja paigaldada (erinevalt Apache 1.3 veebiserveritest), sõltuvalt kasutatavast operatsioonisüsteemist on vajalik ühel või teisel moel tõenäoliselt SSL tugi sisse lülitada seadistusfaili abil. Näiteks Debian GNU/Linux 4.0 puhul tuleb teha kaks linki 

 bash# cd /etc/apache2/mods-enabled
 bash# ln -s ../mods-available/ssl.load
 bash# ln -s ../mods-available/ssl.conf

ning failis /etc/apache2/ports.conf peab sisalduma sarnane rida 

 Listen 192.168.1.23:443

Oluline on SSL-toega VirtualHosti sektsioonis näidata lisaks ära SSL direktiivid, näiteks võiks olle selline üks VirtualHost 

 <VirtualHost 192.168.1.23:443>
   ServerName  www.loomaaed.tartu.ee
   ServerAdmin admin@loomaaed.tartu.ee
   DocumentRoot /data/www
   ErrorLog     /var/log/apache2/www.loomaaed.tartu.ee-ssl-error.log
   TransferLog  /var/log/apache2/www.loomaaed.tartu.ee-ssl-access.log
 
   SSLEngine on
   SSLCertificateFile /etc/apache2/serdid/www.loomaaed.tartu.ee.crt
   SSLCertificateKeyFile /etc/apache2/serdid/www.loomaaed.tartu.ee.key
   SSLOptions +StdEnvVars
 
   <Directory /data/www/cgi-bin>
     DirectoryIndex index.cgi
     Options All   
     AllowOverRide All
     Order Allow,Deny 
     Allow from All   
     SetHandler cgi-script
  </Directory>
 
 </VirtualHost>

Olgu index.cgi sisu selline, mis kuvab keskkonnamuuja nimed ja väärtused 

 #!/usr/bin/perl
 print "Content-type: text/html\n\n";
 
 foreach $key (sort keys(%ENV)) {
  print "$key = $ENV{$key}\n";
 }

Kui seejärel külastada aadressi https://www.loomaaed.tartu.ee/cgi-bin/index.cgi, siis küsitakse esmalt kasutajalt, kas ta usaldab seda veebiserveri endasigneeritud sertifikaati ning peale jaatavat vastust kuvatakse lisaks tavalistele keskkonnamuutujatele SSL-ühendusele iseloomulikud keskkonnamuutujad, näiteks sellised 

 HTTPS = on
 ...
 SSL_SERVER_S_DN = /C=EE/ST=Tartu/L=Tartu/O=Tartu Loomaaed/CN=www.loomaaed.tartu.ee
 SSL_SERVER_S_DN_C = EE
 SSL_SERVER_S_DN_CN = www.loomaaed.tartu.ee
 SSL_SERVER_S_DN_L = Tartu
 SSL_SERVER_S_DN_O = Tartu Loomaaed
 SSL_SERVER_S_DN_ST = Tartu

Alternatiiviks Apache siseminse SSL toe kasutamisele oleks kasutada eraldi Stunnel tarkvara abil kliendi ja serveri vahel ühenduse krüptimist, tõenäoliselt on üldiselt mõttekas eelistada Apache sisemisi vahendeid, aga sõltub vajadustest. Mõnel juhul on justnimelt tark kasutada nn SSL-offloaderit, kas spetsiaalse riistvaralise seadme kujul või nö tavalises arvutis töötava tarkvaralise lahendusena, nt tarkvara Pound, http://www.apsis.ch/pound/.

Seda, millised chiperid on veebiserveris kasutusel saab küsida nt sslthing skritiga, http://blog.techstacks.com/2009/01/verifying-ssl-ciphers.html 

 $ ./sslthing.sh ssl.loomaaed.tartu.ee:443
 Testing SSL2...
 Testing TLS1...
 DHE-RSA-AES256-SHA - 256 bits
 AES256-SHA - 256 bits
 EDH-RSA-DES-CBC3-SHA - 168 bits
 DES-CBC3-SHA - 168 bits
 DHE-RSA-AES128-SHA - 128 bits
 AES128-SHA - 128 bits
 RC4-SHA - 128 bits
 RC4-MD5 - 128 bits

Mitme domeeninimega sertifikaadid

Uuemal ajal saab ühte ja sama sertifikaati kasutada seoses erinevate domeeninimedega. Selleks on levinud kaks tehnikat

  • CN - Common Name
  • SAN - Subject Alternate Name

Seejuures võib neid omavahel kombineerida.

ID kaardiga kasutaja autentimine

ID kaardiga kasutaja autentimine on erijuht kliendisertifikaadiga kasutaja autentimisest kusjuures kasutatakse ID kaardil olevast sertifikaadist ühte - isikutuvastuse sertifikaati. Selle protseduuri läbiviimiseks peab ühelt poolt kasutaja arvuti olema varustatud füüsilise ID kaardilugeja, ID kaardi tarkvara ja sobiva brauseriga ning teiselt poolt peab veebiserver ning veebiserveris töötav rakendus olema seadistatud kontrollima kasutaja isikutuvastuse sertifikaati.

Nii tööle seatud veebirakenduse kasutamisel küsib veebiserver brauserilt kliendisertifikaati, mis avaliku võtme krüptograafia mõttes on avalik võti ning seejärel peab kasutaja tõendama, et tema valduses on vastav salajane võti. Selle salajase võtme kasutamiseks küsib kasutaja arvutis töötav ID kaardi tarkvara isikutuvastuse sertifikaadi kasutamise puhul PIN1 väärtust. Tavaliselt töötab kasutaja arvutis ID kaardi tarkvara selliselt, et sama brauseri kasutamiskorra ajal st aeg alates brauseri käivitamisest sulgemiseni peab PIN1 koodi sisestama vaid kord. Kui edaspidi on vaja salajast võtit kasutada, siis tehakse seda automaatselt.

Reeglina moodustab ID kaardiga autentimine esimese osa veebiserveris töötava rakenduse sessioonihaldusest, mille eesmärk on esmalt kasutaja autentida. Peale edukat autentimist jagavad kasutaja (õigemini tema brauser) ning veebiserver saladust (nt. cookie't), kusjuures edasise rakenduse kasutamise ajal enam kasutajat ei autendita, piisab kasutaja identifitseerimisest, eesmärgiga eristada tema HTTP päringuid teiste veebirakendust samaaegselt kasutavate kasutajate päringute seast. Nt saab veebiserver identifitseerida kasutajat seansi algul kokkulepitud cookie alusel, mille brauser iga esitatud päringu päisesse lisab. Rakenduse kasutamise lõpul peab kasutaja saama sessioon lõpetada, st anda veebiserverile korralduse, et see kustutakse cookie enda poolelt. Praktiliselt tähendab selline asjakorraldus, et ID kaarti kasutatakse vaid autentimisel ja edasine usaldus põhineb cookie'l.

Veebirakenduse saab ka selliselt tööle seada, et kasutaja ainult identifitseerimist ei toimu ja selle asemel toimub iga esitatud päringuga kasutaja autentimine (mis iseenesest sisaldab endas ka identifitseerimist), kuid see ei ole praktiliselt efektiivne kuna iga veebiserverile esitatud päringu jooksul toimub ID kaardi protsessorkaardi kasutamine, mis omakorda teeb rakenduse kasutamise kasutaja jaoks aeglaseks.

Tõenäoliselt on mõistlik veebirakenduses olevate tundlike toimingute tegemisel kasutajat ID kaardi abil täiendavalt autentida, kuid üldiselt rakenduses navigeerimiseks piisab kui serveri ja kliendi usaldus põhineb cookie'l.

Lisaks toimub korrektselt käivitatud süsteemis veel kaks kontrolli, klient kontrollib veebiserveri sertifikaati nagu see toimub nö tavalise https:// teenuse puhul ning veebiserver kontrollib kasutades PKI'd (Public Key Infrastructure), kas kliendisertifikaat on kehtiv. PKI ülesannete hulka kuulub muu hulgas anda välja sertifikaate, neid vajadusel tühistada ning levitada infot sertifikaatide kehtivuse kohta, nt tühistusnimekirja või OCSP (Online Certificate Status Protocol) teenuse abil.

Võttes ülalõeldut arvesse võiks toimuda ühe aadressil https://www.loomaaed.tartu.ee/rakendus/ asuva infosüsteemi kasutamine selline, et sisselogimiseks pöördub kasutaja aadressile https://www.loomaaed.tartu.ee/rakendus/idlogin/ ning peale autentimist teatatakse talle, kas autentimine õnnestus või mitte ning vastavalt suunatakse ta edasi rakendust kasutama või esitatakse veateade.

URI'ile /rakendus/idlogin/ võiks vastata Apache v. 2.2 veebiserveris sellise sisuga VirtualHost 

 <VirtualHost 192.168.1.3:443>
   ServerName  www.loomaaed.tartu.ee
   ServerAdmin webmaster@www.loomaaed.tartu.ee
   DocumentRoot /data/www
   ErrorLog     /var/log/apache2/www.loomaaed.tartu.ee-ssl-error.log
   TransferLog  /var/log/apache2/www.loomaaed.tartu.ee-ssl-access.log
 
   SSLEngine on
   SSLCertificateFile /etc/apache2/serdid/www.loomaaed.tartu.ee-cert.pem
   SSLCertificateKeyFile /etc/apache2/serdid/www.loomaaed.tartu.ee-key.pem
   SSLCertificateChainFile /etc/apache2/serdid/server-sert-ca-chain.pem
   SSLCACertificatePath /etc/apache2/client-sert-ca
 
   <Directory /data/www/rakendus/idlogin>
     DirectoryIndex index.cgi
     Options All
     AllowOverRide All
     Order Allow,Deny 
     Allow from All
     SSLOptions +StdEnvVars +ExportCertData
     SSLVerifyClient optional
     SSLVerifyDepth 2
     SetHandler cgi-script
   </Directory>
 
 </VirtualHost>

Kataloogis /etc/apache2/client-sert-ca on ID kaardi sertifikaadi ahela temast üles poole jäävad sertifikaadid ning neist moodustatud lingid 

 bash:/etc/apache2/client-cert-ca# ls -l
 lrwxrwxrwx 1 root root   11 Aug 13 22:09 119afc2e.0 -> JUUR-SK.pem
 lrwxrwxrwx 1 root root   18 Aug 13 22:09 590f5e9e.0 -> ESTEID-SK-2007.pem 
 lrwxrwxrwx 1 root root   13 Aug 13 22:09 9834803d.0 -> ESTEID-SK.pem
 -rw-r--r-- 1 root root 1404 Feb 14  2007 ESTEID-SK-2007.pem
 -rw-r--r-- 1 root root 1826 Feb 14  2007 ESTEID-SK.pem
 -rw-r--r-- 1 root root 1790 Feb 14  2007 JUUR-SK.pem

Lingid moodustatakse käsuga 

 bash:/etc/apache2/client-cert-ca# c_rehash .

Ning fail /etc/apache2/serdid/server-sert-ca-chain.pem sisaldab veebiserveri sertifikaadi ahela temast üles poole jäävaid sertifikaate, juurikale lähemale jäävad serdid on faili lõpupoole ja juur kõige lõpus.

Selgituseks, et Sertifitseerimiskeskuse juursertifikaat JUUR-SK on nn self-signed sertifikaat, mille suhtes on väljastatud sertifikaardid ESTEID-SK ja ESTEID-SK-2007 ja mille suhtes omakorda vastavalt anti ja antakse praegu välja ID kaardi sertifikaate; SK juursertifikaadi suhtes väljastatud sertifikaadi KLASS3-SK suhtes antakse aga välja veebiserveri sertifikaate.

Alternatiiviks SSLCACertificatePath direktiivi kasutamisele on kasutada SSLCACertificateFile direktiivi, kusjuures argumentiks on siis fail, milles sisalduvad samas sertifikaadid 

# cat ESTEID-SK.pem ESTEID-SK-2007.pem JUUR-SK.pem > client-sert-ca-file.pem

Kasutaja arvutisse vajaliku tarkvara saab aga paigaldada aadressilt http://installer.id.ee/.

ID-kaardiga autentimise seisukohast ei ole oluline, et brauserisse oleks nö paigaldatud SK sertifikaate. Nt töötab juhtum, kui veebiserveris kasutatakse https:// tekitamisel Thawte sertifikaate ning autentimine käib ID-kaardilt pärit kliendi sertifikaadiga.

Lisaks saab piirata SSLCADNRequestFile direktiiviga, milliste issuerite serdid sobivad 

SSLCADNRequestFile /etc/apache2/serdid/id-dn-req.pem

Tundub, et Apache v. 2.2 -> 2.4 uuendamisel on rakendustele abiks selline rida, mis kasutab nö Legacy SSL parameetrite nimesid 

SSLOptions +StdEnvVars +ExportCertData +LegacyDNStringFormat

Kasulikud lisamaterjalid

Tühistusnimekirjade kasutamine

Tühistusnimekirju (ingl. k. CRL - Certificate Revocation Lists) kasutatakse veebiserveri juures selleks, et tühistatud sertifikaadiga kasutajad ei saaks süsteemi siseneda. Tühistusnimekirju jagab tavaliselt sama asutus, mis jagab sertifikaate.

Tühistusnimekirja sisu on nt selline 

 $ openssl crl -in esteid2007.pem -noout -text
 Certificate Revocation List (CRL):
       Version 2 (0x1)
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: /C=EE/O=AS Sertifitseerimiskeskus/OU=ESTEID/CN=ESTEID-SK 2007
       Last Update: Jan  8 06:20:16 2010 GMT
       Next Update: Jan  8 19:20:16 2010 GMT
       CRL extensions:
           X509v3 CRL Number: 
               6612
           X509v3 Authority Key Identifier: 
               keyid:48:06:DE:BE:8C:87:57:95:80:78:63:FA:9C:23:2B:2B:A0:3A:18:75
 
           X509v3 Issuing Distrubution Point: critical
               01./.-.+http://www.sk.ee/crls/esteid/esteid2007.crl
 Revoked Certificates:
     Serial Number: 45A2A260
         Revocation Date: Jan 22 08:58:45 2007 GMT
         CRL entry extensions:
             X509v3 CRL Reason Code: 
                 Unspecified
     Serial Number: 45A2A262
         Revocation Date: Jan 22 08:58:46 2007 GMT
         CRL entry extensions:
             X509v3 CRL Reason Code: 
                 Unspecified
 ...

kus

  • tühistusnimekirjal on kehtivuse alguse ja lõpu aeg
  • tühistusnimekirja Issuer on sama, mis vastavatel sertifikaatidel

Tühistusnimekirjade kasutamiseks sobib nt sooritada selline järgnevus

  • Kopeerida Sertifitseerimiskeskuse veebikohast tühistusnimekirjad
 $ wget http://www.sk.ee/crls/esteid/esteid2007.crl
 $ wget http://www.sk.ee/repository/crls/esteid2011.crl  
 $ wget http://www.sk.ee/crls/juur/crl.crl
  • Teisendada nad PEM kujule
 $ openssl crl -in esteid.crl -out esteid.crl.pem -inform DER
 $ openssl crl -in esteid2007.crl -out esteid2007.crl.pem -inform DER
 $ openssl crl -in crl.crl -out crl.crl.pem -inform DER
  • Genereerida veebiserveri jaoks hash-lingid, seda tuleb teha vaid kord eeldusel, et failinimed ei muutu
 $ cd /etc/apache2/ssl.crl
 $ c_rehash .
 Doing .
 esteid2007.crl.pem => 590f5e9e.r0
 esteid.crl.pem => 9834803d.r0

Universaalsem viis 

for f in *.pem; do ln -s $f `openssl crl -hash -noout -in $f`.r0; done
  • Lisada veebiserveri seadistusfaili muu ID-kaardiga autentimise osa juurde rida
 SSLCARevocationPath /etc/apache2/ssl.crl
  • Peale tühistusnimekirjade uuendamist tuleb veebiserver mitte reloadida vaid restartida
 # /etc/init.d/apache2 restart

Tühistusnimekirjade kasutamisel on oluline, et toimuks nende uuendamine, sest kui veebiserver on seadistatud kasutama tühistusnimekirja ning nimekiri on aegunud, siis ei saa ükski kasutaja sisse logida. Automaatseks uuendamiseks sobib kasutada nt MISP tarkvara komplektist pärit skripti Fail:Updatecrl.log (faili algusse tuleb lisada peale kopeerimist #!/bin/sh). NB! Uus versioon sellest skript on Fail:Updatecrl-20160109.txt, kusjuures skriptis viidatakse issuerite failile /etc/apache2/crls/crl-issuers.pem, selle saab moodustada selliselt 

# cat wget-crls.sh
wget https://sk.ee/crls/juur/crl.crl
wget https://sk.ee/crls/eeccrca/eeccrca.crl
wget https://sk.ee/crls/esteid/esteid2007.crl
wget https://sk.ee/repository/crls/esteid2011.crl
wget https://sk.ee/crls/esteid/esteid2015.crl
wget https://sk.ee/crls/klass3/klass3-2010.crl
wget https://sk.ee/repository/crls/eid2011.crl
wget https://sk.ee/crls/eid/eid2007.crl 

for i in crl.crl eeccrca.crl esteid2007.crl esteid2011.crl esteid2015.crl klass3-2010.crl eid2011.crl eid2007.crl; do
  openssl crl -in $i -out $i.pem -inform DER
  echo -n "CRL nimi $i: "
  openssl crl -in $i.pem -noout -issuer
done

mille käivitamisel öeldakse issuerite nimed 

#./wget-crls.sh 
CRL nimi crl.crl: issuer=/emailAddress=pki@sk.ee/C=EE/O=AS Sertifitseerimiskeskus/CN=Juur-SK
CRL nimi eeccrca.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root CA/emailAddress=pki@sk.ee
CRL nimi esteid2007.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/OU=ESTEID/CN=ESTEID-SK 2007
CRL nimi esteid2011.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/CN=ESTEID-SK 2011/emailAddress=pki@sk.ee
CRL nimi esteid2015.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/2.5.4.97=NTREE-10747013/CN=ESTEID-SK 2015
CRL nimi klass3-2010.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/OU=Sertifitseerimisteenused/CN=KLASS3-SK 2010
CRL nimi eid2011.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/CN=EID-SK 2011/emailAddress=pki@sk.ee
CRL nimi eid2007.crl: issuer=/C=EE/O=AS Sertifitseerimiskeskus/OU=Sertifitseerimisteenused/CN=EID-SK 2007

Seejärel tuleb vastavad issuerite sertifikaadid otsida aadressilt https://sk.ee/repositoorium/sk-sertifikaadid ja kopeerida kokku faili 

/etc/apache2/crls/crl-issuers.pem

Selle skripti kasutamisel on olulised selliste parameetrite väärtused

  • APACHECTL=/etc/init.d/apache2 - veebiserverit restartiva skripti nimi
  • CERTS=/etc/apache2/serdid/sk-ca.pem - tühistusnimekirja väljaandja kontrolliks vajalikud kõrgema taseme sertifikaadid
  • CRLPATH_MISP=/etc/apache2/ssl.crl - kataloog, kuhu tühistusnimekirjad paigutatakse
  • skript käivitab wget programmi -N võtmega, mis tähendab, et kui serveri pole tühistusnimekirja fail uuenenud, siis seda uuesti ei kopeerita (wget teeb esmalt HEAD päringu ja vajadusel seejärel GET)
  • CRLPATH_SK=http://www.sk.ee/crls/esteid - milliselt aadressilt tühistusnimekirju kopeeritakse
  • ADMIN=mart@loomaaed.tartu.ee - millisele aadressile saadetakse ebaõnnestusmiste kohta teateid

Skripti kasutamiseks tuleb

  • kopeerida süsteemi SK kõrgema taseme sertifikaadid faili /etc/apache2/serdid/sk-ca.pem
 $ wget http://www.sk.ee/files/JUUR-SK.PEM.cer
 $ wget http://www.sk.ee/files/ESTEID-SK.PEM.cer
 $ wget http://www.sk.ee/files/ESTEID-SK%202007.PEM.cer

ja ühendada kokku 

 $ cat "ESTEID-SK 2007.PEM.cer" ESTEID-SK.PEM.cer JUUR-SK.PEM.cer > /etc/apache2/serdid/sk-ca.pem
  • kontrollida et eelmainitud parameetrite väärtused on sobivad ja süsteemis leiduvad skriptis kasutatud utiliidid, nt openssl
  • lisada crontab vastav sissekanne, nt kasutades rida, kusjuures eelnevalt võiks skripti käsitsi käivitades veenduda, et ta töötab
 */10 * * * * /root/system/updatecrl.sh 1>/dev/null
  • Probleemide korral logitakse tulemusi mh faili /tmp/reason.PID
  • Testimiseks panna mõne crl faili aeg minevikku, skript peab kopeerima uuesti
# touch -t 199901012222 /etc/apache2/crls/crls_juur_crl.crl.der
  • Olemasolevate CRL failde aegumise aegu näeb nt
root@arvuti:/etc/apache2/crls# for i in *pem; do echo $i; openssl crl -in $i -noout -text | grep Next; done
crls_eeccrca_eeccrca.crl.pem
       Next Update: Oct 15 12:37:58 2016 GMT
crls_esteid_esteid2015.crl.pem
       Next Update: Sep 22 06:39:07 2016 GMT
crls_klass3_klass3-2010.crl.pem
       Next Update: Sep 22 07:22:58 2016 GMT
repository_crls_eid2011.crl.pem
       Next Update: Sep 21 23:22:36 2016 GMT
repository_crls_esteid2011.crl.pem
       Next Update: Sep 21 23:22:23 2016 GMT

Probleemide korral

  • vaatada, mis on apache jaoks oluliste .pem failide suurused, ei tohi olla null
 # ls -ld /etc/apache2/crls-20170201-katki/*pem
-rw-r--r-- 1 root root    1527 Dec  9 17:45 /etc/apache2/crls-20170201-katki/crls_eeccrca_eeccrca.crl.pem
-rw-r--r-- 1 root root 4164895 Feb  1 19:00 /etc/apache2/crls-20170201-katki/crls_esteid_esteid2015.crl.pem
-rw-r--r-- 1 root root   29136 Feb  1 19:00 /etc/apache2/crls-20170201-katki/crls_klass3_klass3-2010.crl.pem
-rw-r--r-- 1 root root 6504923 Feb  1 21:30 /etc/apache2/crls-20170201-katki/repository_crls_eid2011.crl.pem
-rw-r--r-- 1 root root       0 Feb  1 12:47 /etc/apache2/crls-20170201-katki/repository_crls_esteid2011.crl.pem
  • muuta kõigi asjassepuutuvate failide timestamp minevikku ja käivitada update skript käsitsi, nt
# touch -d 20150909 /etc/apache2/crls/repository_crls_e*
# /opt/updatecrl/bin/updatecrl.sh

Probleemide korral

  • vaatada, mis on apache jaoks oluliste .pem failide suurused, ei tohi olla null
 # ls -ld /etc/apache2/crls-20170201-katki/*pem
-rw-r--r-- 1 root root    1527 Dec  9 17:45 /etc/apache2/crls-20170201-katki/crls_eeccrca_eeccrca.crl.pem
-rw-r--r-- 1 root root 4164895 Feb  1 19:00 /etc/apache2/crls-20170201-katki/crls_esteid_esteid2015.crl.pem
-rw-r--r-- 1 root root   29136 Feb  1 19:00 /etc/apache2/crls-20170201-katki/crls_klass3_klass3-2010.crl.pem
-rw-r--r-- 1 root root 6504923 Feb  1 21:30 /etc/apache2/crls-20170201-katki/repository_crls_eid2011.crl.pem
-rw-r--r-- 1 root root       0 Feb  1 12:47 /etc/apache2/crls-20170201-katki/repository_crls_esteid2011.crl.pem
  • muuta kõigi asjassepuutuvate failide timestamp minevikku ja käivitada update skript käsitsi, nt
# touch -d 20150909 /etc/apache2/crls/repository_crls_e*
# /opt/updatecrl/bin/updatecrl.sh

Kasulikud lisamaterjalid

Kasutaja autentimine Kerberosega

Kerberose kasutaja autentimiseks peab olema kasutada Kerberose infrastruktuur, nt selline nagu kirjeldatud tekstis MIT Kerberose kasutamine Debianiga. Seejuures tuleb arvestada, et kuigi autentimine on iseenesest turvaline ei ole andmevahtus üle http:// turvaline. Kasutaja autentimiseks Kerberosega tuleb veebiserverisse lisada pakett libapache2-mod-auth-kerb http://modauthkerb.sourceforge.net/ 

# apt-get install libapache2-mod-auth-kerb

Kerberosega autentimist on võimalik korraldada kahel viisil

  • kasutajalt küsitakse tema Kerberose kasutajanime ja parooli, see on ebasoovitav viis, aga töötab kõigi brauseritega, millega töötab basic auth
  • kasutatakse Kerberose piletit, see on nö õige viis, kasutatakse 'Authorization: Negotiate' päist, nt 2010 aastal töötab see Firefox ja IE brauseritega

Ressursile saab rakendada Kerberosega ligipääsupiiranguga nt selliselt 

<Directory /var/www/krb>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbAuthRealms LOOMAAED
  KrbMethodNegotiate on
  KrbMethodK5Passwd off
  Krb5Keytab /etc/krb5.apache2.keytab
  require user priit@LOOMAAED
  Order Allow,Deny  
  Allow from All
</Directory>

kus

  • AuthType - peab olema kindlasti Kerberos
  • KrbAuthRealms -
  • KrbMethodNegotiate - piletiga saab autentida
  • KrbMethodK5Passwd - parooliga ei saa autentida
  • Krb5Keytab - keytab faili asukoht veebiserveri failisüsteemis

Lisaks on tuleb sisestada Kerberose andmebaasi sissekanne http teenuse kohta öeldes 

# kadmin -p root/admin -q "addprinc -randkey HTTP/www.loomaaed.tartu.ee"

ja tekitada veebiserveri failisüsteemi teenuse keytab ning teha veebiserveri kasutajale loetavaks 

# kadmin -p root/admin -q "ktadd -k /etc/krb5.apache2.keytab HTTP/www.loomaaed.tartu.ee"
# chown www-data:www-data /etc/krb5.apache2.keytab

Selleks, et sellist ressurssi saaks brauserist kasutada tuleb nt Firefoxis pöörduda aadressile 'about:config' ning määrata parameetri network.negotiate-auth.trusted-uris väärtuseks ligipääsupiiranguga domeeni nimi või nime osa, nt 'loomaaed.tartu.ee'.

Kasutamiseks peab kasutaja esmalt omale TGT võtme küsima ja seejärel juba peaks saama ligipääsupiiranguga ressurssi kasutada.

Kasulikud lisamaterjalid

Tagurpidi puhverdamine koormusjaoturis ja SSLi termineerimine (Reverse proxying in loadbalancer and SSL offloading)

Ülesande püstitus

  • SSL termineeritakse koormusjaoturis
  • Ühendused jagatakse erinevate backend serverite vahel
  • Võimalik logida ID kaardiga (smartcard)


Koormusjaoturi seadistamine

Aktiiveerida vajalikud moodulid

  • mod_proxy
  • mod_ssl
  • mod_headers
 # proxy 
 a2enmod proxy
 
 # ssl
 a2enmod ssl
 
 # sending SSL_* info to backend server using headers
 a2enmod headers

Seadistada

  • SSL_* keskkonna väärtuste edastamine tagumistele (ingl k. backend) serveritele
  • kliendilt tulevate SSL_* päiste (ingl k. headers) kustutamine (nimelt, kui Apache keskkonnas SSL poolt keskkonna väärtust ei panda, otsitakse ka päistest tulevaid - st kui klient teeb tavalise http päringu, milles ise saadab nt SSL_CLIENT_CERT päise, siis oleks tal võimalik võltsida enda identiteeti.)


 # /etc/apache2/mods-enabled/proxy.conf   
  
 <IfModule mod_proxy.c>
         #turning ProxyRequests on and allowing proxying from all may allow
         #spammers to use your proxy to send email.
  
  
         ProxyRequests Off
  
  
         <Proxy *>
                 AddDefaultCharset off
                 Order deny,allow
                 #Deny from all
                 Allow from all
         </Proxy>
  
  
         # Enable/disable the handling of HTTP/1.1 "Via:" headers.
         # ("Full" adds the server version; "Block" removes all outgoing Via: headers)
         # Set to one of: Off | On | Full | Block
  
  
         ProxyVia On
         ProxyPreserveHost On
  
  
         # + SSL OFFLOAD, SMARTCARD
         RequestHeader unset HTTPS
         RequestHeader unset SSL_PROTOCOL  
         RequestHeader unset SSL_SESSION_ID
         RequestHeader unset SSL_CIPHER
         RequestHeader unset SSL_CIPHER_EXPORT
         RequestHeader unset SSL_CIPHER_USEKEYSIZE
         RequestHeader unset SSL_CIPHER_ALGKEYSIZE
         RequestHeader unset SSL_VERSION_INTERFACE
         RequestHeader unset SSL_VERSION_LIBRARY 
         RequestHeader unset SSL_CLIENT_M_VERSION
         RequestHeader unset SSL_CLIENT_M_SERIAL
         RequestHeader unset SSL_CLIENT_S_DN
         RequestHeader unset SSL_CLIENT_S_DN_x509
         RequestHeader unset SSL_CLIENT_I_DN
         RequestHeader unset SSL_CLIENT_I_DN_x509
         RequestHeader unset SSL_CLIENT_V_START
         RequestHeader unset SSL_CLIENT_V_END
         RequestHeader unset SSL_CLIENT_A_SIG
         RequestHeader unset SSL_CLIENT_A_KEY
         RequestHeader unset SSL_CLIENT_CERT
         RequestHeader unset SSL_CLIENT_CERT_CHAINn
         RequestHeader unset SSL_CLIENT_VERIFY   
         RequestHeader unset SSL_SERVER_M_VERSION
         RequestHeader unset SSL_SERVER_M_SERIAL
         RequestHeader unset SSL_SERVER_S_DN
         RequestHeader unset SSL_SERVER_S_DN_x509
         RequestHeader unset SSL_SERVER_I_DN
         RequestHeader unset SSL_SERVER_I_DN_x509
         RequestHeader unset SSL_SERVER_V_START
         RequestHeader unset SSL_SERVER_V_END
         RequestHeader unset SSL_SERVER_A_SIG
         RequestHeader unset SSL_SERVER_A_KEY
         RequestHeader unset SSL_SERVER_CERT
  
  
         RequestHeader set HTTPS "%{HTTPS}s" env=HTTPS
         RequestHeader set SSL_PROTOCOL "%{SSL_PROTOCOL}s" env=SSL_PROTOCOL
         RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" env=SSL_SESSION_ID
         RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" env=SSL_CIPHER
         RequestHeader set SSL_CIPHER_EXPORT "%{SSL_CIPHER_EXPORT}s" env=SSL_CIPHER_EXPORT
         RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" env=SSL_CIPHER_USEKEYSIZE
         RequestHeader set SSL_CIPHER_ALGKEYSIZE "%{SSL_CIPHER_ALGKEYSIZE}s" env=SSL_CIPHER_ALGKEYSIZE
         RequestHeader set SSL_VERSION_INTERFACE "%{SSL_VERSION_INTERFACE}s" env=SSL_VERSION_INTERFACE
         RequestHeader set SSL_VERSION_LIBRARY "%{SSL_VERSION_LIBRARY}s" env=SSL_VERSION_LIBRARY   
         RequestHeader set SSL_CLIENT_M_VERSION "%{SSL_CLIENT_M_VERSION}s" env=SSL_CLIENT_M_VERSION
         RequestHeader set SSL_CLIENT_M_SERIAL "%{SSL_CLIENT_M_SERIAL}s" env=SSL_CLIENT_M_SERIAL
         RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s" env=SSL_CLIENT_S_DN
         RequestHeader set SSL_CLIENT_S_DN_x509 "%{SSL_CLIENT_S_DN_x509}s" env=SSL_CLIENT_S_DN_x509
         RequestHeader set SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s" env=SSL_CLIENT_I_DN
         RequestHeader set SSL_CLIENT_I_DN_x509 "%{SSL_CLIENT_I_DN_x509}s" env=SSL_CLIENT_I_DN_x509
         RequestHeader set SSL_CLIENT_V_START "%{SSL_CLIENT_V_START}s" env=SSL_CLIENT_V_START
         RequestHeader set SSL_CLIENT_V_END "%{SSL_CLIENT_V_END}s" env=SSL_CLIENT_V_END
         RequestHeader set SSL_CLIENT_A_SIG "%{SSL_CLIENT_A_SIG}s" env=SSL_CLIENT_A_SIG
         RequestHeader set SSL_CLIENT_A_KEY "%{SSL_CLIENT_A_KEY}s" env=SSL_CLIENT_A_KEY
         RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" env=SSL_CLIENT_CERT
         RequestHeader set SSL_CLIENT_CERT_CHAINn "%{SSL_CLIENT_CERT_CHAINn}s" env=SSL_CLIENT_CERT_CHAINn
         RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s" env=SSL_CLIENT_VERIFY
         RequestHeader set SSL_SERVER_M_VERSION "%{SSL_SERVER_M_VERSION}s" env=SSL_SERVER_M_VERSION
         RequestHeader set SSL_SERVER_M_SERIAL "%{SSL_SERVER_M_SERIAL}s" env=SSL_SERVER_M_SERIAL
         RequestHeader set SSL_SERVER_S_DN "%{SSL_SERVER_S_DN}s" env=SSL_SERVER_S_DN
         RequestHeader set SSL_SERVER_S_DN_x509 "%{SSL_SERVER_S_DN_x509}s" env=SSL_SERVER_S_DN_x509
         RequestHeader set SSL_SERVER_I_DN "%{SSL_SERVER_I_DN}s" env=SSL_SERVER_I_DN
         RequestHeader set SSL_SERVER_I_DN_x509 "%{SSL_SERVER_I_DN_x509}s" env=SSL_SERVER_I_DN_x509
         RequestHeader set SSL_SERVER_V_START "%{SSL_SERVER_V_START}s" env=SSL_SERVER_V_START
         RequestHeader set SSL_SERVER_V_END "%{SSL_SERVER_V_END}s" env=SSL_SERVER_V_END
         RequestHeader set SSL_SERVER_A_SIG "%{SSL_SERVER_A_SIG}s" env=SSL_SERVER_A_SIG
         RequestHeader set SSL_SERVER_A_KEY "%{SSL_SERVER_A_KEY}s" env=SSL_SERVER_A_KEY
         RequestHeader set SSL_SERVER_CERT "%{SSL_SERVER_CERT}s" env=SSL_SERVER_CERT
         
         # if url contains auth/smartcard then client auth is done
         <Location ~ "auth/smartcard">
                 SSLVerifyClient optional
                 SSLVerifyDepth 2
                 SSLOptions +StdEnvVars +ExportCertData	
         </Location>
         # - SSL OFFLOAD, SMARTCARD
  
  
         <Location /balancer-manager>
            SetHandler balancer-manager
            Order Allow,Deny
            Allow from 192.168.0.0/16
         </Location>
  
         # proxying with 10.0.5.
         <Proxy balancer://mycluster>
                 BalancerMember http://10.0.1.152:80
                 BalancerMember http://10.0.1.153:80
         </Proxy>
  
  
         ProxyPass       /balancer-manager       !
         ProxyPass       /server-status          !       
         ProxyPass       /                       balancer://mycluster/
  
  
 </IfModule>

Teenusele restart

 /etc/init.d/apache2 restart

Backend serveri seadistamine

Aktiiveerida vajalikud moodulid

  • mod_headers
  • mod_rpaf
 # killing SSL_* sent backend server using headers
 a2enmod headers
 
 # showing correct IP for clients
 a2enmod rpaf

Seadistada

  • päistega saadetud SSL_ väärtused koormusjaoturist on kättesaadavad SSL_ keskkonna muutujatest (vajab natukene trikitamist, sest vaikimisi lähevad päistega saadetud väärtused HTTP_* muutujatesse)
  • eemaldada HTTP_SSL_* väärtused
  • klientide IP-d kuvatakse õigesti
  • IP tabelsiga lubada ainult koormusejaoturist pordile 80 pöördumine (või siis hoida backend servereid selliselt, et keegi sinna ligi ei pääse - vastasel juhul on võimalik võltsida päiseid saates enda identiteeti)
 # /etc/apache2/conf.d/ssl_offload_fix
 
 # backend behind ssl offloader
 
 SetEnvIf HTTPS "(..*)" HTTPS=$1
 SetEnvIf SSL_PROTOCOL "(..*)" SSL_PROTOCOL=$1
 SetEnvIf SSL_SESSION_ID "(..*)" SSL_SESSION_ID=$1
 SetEnvIf SSL_CIPHER "(..*)" SSL_CIPHER=$1
 SetEnvIf SSL_CIPHER_EXPORT "(..*)" SSL_CIPHER_EXPORT=$1
 SetEnvIf SSL_CIPHER_USEKEYSIZE "(..*)" SSL_CIPHER_USEKEYSIZE=$1
 SetEnvIf SSL_CIPHER_ALGKEYSIZE "(..*)" SSL_CIPHER_ALGKEYSIZE=$1
 SetEnvIf SSL_VERSION_INTERFACE "(..*)" SSL_VERSION_INTERFACE=$1
 SetEnvIf SSL_VERSION_LIBRARY "(..*)" SSL_VERSION_LIBRARY=$1  
 SetEnvIf SSL_CLIENT_M_VERSION "(..*)" SSL_CLIENT_M_VERSION=$1
 SetEnvIf SSL_CLIENT_M_SERIAL "(..*)" SSL_CLIENT_M_SERIAL=$1
 SetEnvIf SSL_CLIENT_S_DN "(..*)" SSL_CLIENT_S_DN=$1
 SetEnvIf SSL_CLIENT_S_DN_x509 "(..*)" SSL_CLIENT_S_DN_x509=$1
 SetEnvIf SSL_CLIENT_I_DN "(..*)" SSL_CLIENT_I_DN=$1
 SetEnvIf SSL_CLIENT_I_DN_x509 "(..*)" SSL_CLIENT_I_DN_x509=$1
 SetEnvIf SSL_CLIENT_V_START "(..*)" SSL_CLIENT_V_START=$1
 SetEnvIf SSL_CLIENT_V_END "(..*)" SSL_CLIENT_V_END=$1
 SetEnvIf SSL_CLIENT_A_SIG "(..*)" SSL_CLIENT_A_SIG=$1
 SetEnvIf SSL_CLIENT_A_KEY "(..*)" SSL_CLIENT_A_KEY=$1
 SetEnvIf SSL_CLIENT_CERT "(..*)" SSL_CLIENT_CERT=$1
 SetEnvIf SSL_CLIENT_CERT_CHAINn "(..*)" SSL_CLIENT_CERT_CHAINn=$1
 SetEnvIf SSL_CLIENT_VERIFY "(..*)" SSL_CLIENT_VERIFY=$1
 SetEnvIf SSL_SERVER_M_VERSION "(..*)" SSL_SERVER_M_VERSION=$1
 SetEnvIf SSL_SERVER_M_SERIAL "(..*)" SSL_SERVER_M_SERIAL=$1
 SetEnvIf SSL_SERVER_S_DN "(..*)" SSL_SERVER_S_DN=$1
 SetEnvIf SSL_SERVER_S_DN_x509 "(..*)" SSL_SERVER_S_DN_x509=$1
 SetEnvIf SSL_SERVER_I_DN "(..*)" SSL_SERVER_I_DN=$1
 SetEnvIf SSL_SERVER_I_DN_x509 "(..*)" SSL_SERVER_I_DN_x509=$1
 SetEnvIf SSL_SERVER_V_START "(..*)" SSL_SERVER_V_START=$1
 SetEnvIf SSL_SERVER_V_END "(..*)" SSL_SERVER_V_END=$1
 SetEnvIf SSL_SERVER_A_SIG "(..*)" SSL_SERVER_A_SIG=$1
 SetEnvIf SSL_SERVER_A_KEY "(..*)" SSL_SERVER_A_KEY=$1
 SetEnvIf SSL_SERVER_CERT "(..*)" SSL_SERVER_CERT=$1
 
 # Remove headers so there would not be HTTP_SSL* things  
 RequestHeader unset HTTPS 
 RequestHeader unset SSL_PROTOCOL  
 RequestHeader unset SSL_SESSION_ID
 RequestHeader unset SSL_CIPHER
 RequestHeader unset SSL_CIPHER_EXPORT
 RequestHeader unset SSL_CIPHER_USEKEYSIZE
 RequestHeader unset SSL_CIPHER_ALGKEYSIZE
 RequestHeader unset SSL_VERSION_INTERFACE
 RequestHeader unset SSL_VERSION_LIBRARY 
 RequestHeader unset SSL_CLIENT_M_VERSION
 RequestHeader unset SSL_CLIENT_M_SERIAL
 RequestHeader unset SSL_CLIENT_S_DN
 RequestHeader unset SSL_CLIENT_S_DN_x509
 RequestHeader unset SSL_CLIENT_I_DN
 RequestHeader unset SSL_CLIENT_I_DN_x509
 RequestHeader unset SSL_CLIENT_V_START
 RequestHeader unset SSL_CLIENT_V_END
 RequestHeader unset SSL_CLIENT_A_SIG
 RequestHeader unset SSL_CLIENT_A_KEY      
 RequestHeader unset SSL_CLIENT_CERT       
 RequestHeader unset SSL_CLIENT_CERT_CHAINn
 RequestHeader unset SSL_CLIENT_VERIFY   
 RequestHeader unset SSL_SERVER_M_VERSION
 RequestHeader unset SSL_SERVER_M_SERIAL
 RequestHeader unset SSL_SERVER_S_DN
 RequestHeader unset SSL_SERVER_S_DN_x509
 RequestHeader unset SSL_SERVER_I_DN
 RequestHeader unset SSL_SERVER_I_DN_x509
 RequestHeader unset SSL_SERVER_V_START
 RequestHeader unset SSL_SERVER_V_END
 RequestHeader unset SSL_SERVER_A_SIG
 RequestHeader unset SSL_SERVER_A_KEY
 RequestHeader unset SSL_SERVER_CERT


Apache teenusele restart Linuxis

 # /etc/init.d/apache2 restart

Veebiserveri optimiseerimine

MaxClients muutuja arvutamiseks Apache seadistusfailis kasutamiseks sobib järgmine valem

MaxClients = arvutis olev mälu * 80% / maksimaalne Apache ühe protsessi mälukasutus veebirakenduse puhul mida serveris kasutatakse. Näiteks 

MaxClients = 16000 * 0,8 / 25 = 512

Koormustestide tegemiseks sobib Apache enda tarkvara nimega ab 

# ab2 -c 1000 -n 10000 http://www.test.ee/test.php
# ab2 -c 100 -n 1000 http://www.test.ee/test.php
# ab2 -c 10 -n 100 http://www.test.ee/test.php

http://httpd.apache.org/docs/2.2/programs/ab.html

Kasulikud lisamaterjalid

Pärit leheküljelt "https://kuutorvaja.eenet.ee/w/index.php?title=Apache%27i_veebiserver&oldid=30011"