ID kaardiga autentimine Apache2 veebiserveriga: Difference between revisions
Line 155: | Line 155: | ||
Server peaks nüüd sellele kataloogile ligi lubama AINULT eesti ID-kaardiga. | Server peaks nüüd sellele kataloogile ligi lubama AINULT eesti ID-kaardiga. | ||
'''Veendu, et ligipääsu ei ole lubatud mõne teise virtuaalsaidi kaudu n. http://www.firma.ee/secure/ ja http://firma.ee/www/secure/ !''' | |||
=Tühistusnimekirjade uuendamine= | =Tühistusnimekirjade uuendamine= |
Revision as of 17:52, 29 December 2009
Legend
Meil on firma avalik veebileht www.firma.ee mida serveeritakse nii tavalise kui ka SSL-iga turvatud HTTP protokolli kaudu.
Sellel lehel on meil ka kataloog /secure privaatsema informatsiooniga kuhu laseme kasutaja ligi ainult ID-kaardiga edukalt autentides ning ainult SSL protokolli kasutades.
Üldinformatsioon
Käesolev juhend on testitud Ubuntu 9.10, Apache 2.2.12-1ubuntu2.1, mod_ssl 2.2.11 ja OpenSSL 0.9.8g versioonidega. Tõenäoliselt sobib see juhend kasutamiseks ka eelnimetatud tarkvara paljude vanemate ja uuemate versioonidega.
Sertifikaatide kehtivuse kontroll ei toimu online OCSP (Online Certificate Status Protocol) teenuse abil (tasuline), selle asemel kontrollitakse igat kliendi sertifikaati vastu kehtetute sertifikaatide nimekirja, mida omakorda aegajalt uuendatakse.
Töö käik
Kuna enamus järgnevaist toimingutest vajavad root kasutaja privileege, on 2 võimalust:
1. Käivitada iga säherdune käsk root kasutaja õigustes sudo abil näiteks:
sudo apt-get update sudo nano /etc/hosts
2. Logime ennast root kasutajaks ning käivitame vajalikud toimingud. Kuna sudo-t sel juhul enam vaja ei lähe, hoiad selle arvelt pisut aega kokku. Samas on aga tunduvalt lihtsam midagi ära rikkuda, sest KÕIK käsud käivitatakse root kasutaja õigustes!
sudo -i apt-get update vi /etc/hosts
Kuidas keegi jätkab on igaühe enda valida. Järgnevas juhendis on root kasutaja õigustes käivitatavatel käskudel ees sudo. Kui otsustad ennast kohe root kasutajaks keerata, siis edaspidistes toimingutes võid (aga ei pea) sudo eest ära jätta. Kuna enamus konfiguratsioonifaile on root kasutaja omad, pead nende muutmiseks omama ka root kasutaja privileege - tekstieditor tuleb käivitada root kasutaja õigustes nagu ülal näidatud.
Eeldused
Selle juhendi kasutajalt eeldatakse linuxi käsurea mõningast tundmist ning oskust kasutada käsurealt tekstieditori n. vi või nano.
Eelduseks on korrektselt sooritatud Veebiserveri labor v.2, st. veebiserver on labori juhendi järgi seadistatud ning www.firma.ee lehekülje SSL osa toimib vigadeta.
Installeerimine
Lae alla Eesti ID kaardi juursertifikaadid ning paiguta need /etc/apache2 kataloogi:
cd /etc/apache2 sudo wget http://www.sk.ee/files/JUUR-SK.PEM.cer sudo wget http://www.sk.ee/files/ESTEID-SK.PEM.cer sudo wget http://www.sk.ee/files/ESTEID-SK%202007.PEM.cer
Lae alla kehtetute sertifikaatide nimekiri ning paiguta see /etc/apache2/crl kataloogi:
sudo mkdir /etc/apache2/crl cd /etc/apache2/crl sudo wget http://www.sk.ee/crls/esteid/esteid.crl sudo wget http://www.sk.ee/crls/esteid/esteid2007.crl sudo wget http://www.sk.ee/crls/juur/crl.crl
Seadistamine
ID kaardi juursertifikaatide seadistamine
Pane kõik 3 juursertifikaati kokku ühte faili, et veebiserveril oleks lihtsam neid lugeda:
sudo -i cd /etc/apache2 cat JUUR-SK.PEM.cer ESTEID-SK.PEM.cer ESTEID-SK\ 2007.PEM.cer > juur.crt
Sertifikaatide tühistusnimekirjade seadistamine
Kuna allalaetavad tühistusnimekirjad on apache jaoks loetamatul kujul, siis on vaja need konverteerida PEM formaati:
cd /etc/apache2/crl sudo openssl crl -in esteid.crl -out esteid.crl -inform DER sudo openssl crl -in esteid2007.crl -out esteid2007.crl -inform DER sudo openssl crl -in crl.crl -out crl.crl -inform DER
Apache dokumentatsioonis nõutakse ka räsi-linkide loomist. Genereerime need käsuga:
sudo -i cd /etc/apache2/crl rm *.r? n="0";for f in `ls *.crl`;do ln -s $f `openssl crl -hash -noout -in $f`.r$n ;let n=n+1;done
Kuna tühistusnimekirju on vaja pidevalt uuendada, siis on selle artikli lõpus kirjeldatud ka sobiva skripti tegemine ning käivitamine.
SSL keskkonna seadistamine
Lisa apache konfiguratsioonifaili /etc/apache2/sites-enabled/www , SSL virtuaalsaidi osasse, read:
SSLCACertificateFile /etc/apache2/juur.crt SSLCARevocationPath /etc/apache2/crl
Lisa SSL virtuaalsaidi <Directory> sektsioonide juurde järgmine directory sektsioon:
<Directory /var/www/www/secure> Options Indexes FollowSymLinks MultiViews AllowOverride AuthConfig Options Order allow,deny allow from all </Directory>
Ülaltoodud sektsioonis määratakse ära kataloog, kuhu sisenedes nõutakse ID kaardiga autentimist. Antud juhul siis /var/www/www/secure Loome selle kataloogi ning nõuame secure kataloogi sisenedes ID-kaarti, luues sinna .htaccess faili:
sudo mkdir /var/www/www/secure sudo vi /var/www/www/secure/.htaccess
Ja lisame .htaccess faili järgmised read:
SSLVerifyClient require SSLVerifyDepth 2
Põhimõtteliselt on nüüd kõik seadistatud AGA kui sul on tõesti kõik nii seadistatud nagu Veebiserveri labor v.2-s nõutud, siis on võimalik /var/www/www/secure kataloogile siiski ligi pääseda kasutades http protokolli ning järgmist URL-i: http://<serverinimi>/www/secure/ . Selle vältimiseks lisa kõikide, väljaarvatud HTTPS (443 port), virtuaalsaitide konfiguratsioonidesse, <VirtualHost> sektsioonidesse, teiste kataloogiõiguste juurde järgmised read:
<Directory "/var/www/www/secure"> Order allow,deny deny from all </Directory>
Arvesta, et ligipääs on vaikimisi lubatud kõikide lubatud (enabled) virtuaalsaitide kaudu. Veebiserveri labor v.2-s seadistati www ja sales ning lisaks on ka vaikimisi sait nimega default. Käi kindlasti kõik konfid üle.
Kõige lõpuks restardime veebiserveri:
/etc/init.d/apache2 restart
Nüüdseks peaks SSL ja ID-kaardi osa olema seadistatud.
Tulemuse kontroll
Loome index.php lehe, mida peaks kuvatama peale edukat autentimist.
Piisab näiteks phpinfo funktsiooni väljundist:
sudo echo "<?php phpinfo(); ?>" > /var/www/www/secure/index.php
- Istu nüüd mõne arvuti taha, kus on kiipkaardilugeja ja brauser, millele on ID-kaardi asi selgeks tehtud ning katseta ligipääsu.
Võta ühendust oma serveriga: https://ip_aadress/secure või https://www.firma.ee/secure
(eelnevalt on vaja serveri nimi defineerida kas oma arvuti hosts failis või enda võrgu nimeserveris)
Server peaks nüüd sellele kataloogile ligi lubama AINULT eesti ID-kaardiga.
Veendu, et ligipääsu ei ole lubatud mõne teise virtuaalsaidi kaudu n. http://www.firma.ee/secure/ ja http://firma.ee/www/secure/ !
Tühistusnimekirjade uuendamine
Tühistusnimekirju tuleb uuendada regulaarselt, kuna neid täiendatakse pidevalt.
Vastasel juhul võib juhtuda, et kasutaja sertifikaat enam ei kehti, kuid sinu server aksepteerib seda jätkuvalt.
Järgnevalt loome lihtsa skripti ning laseme süsteemil seda regulaarselt ise jooksutada.
Tähelepanu! Skript luuakse alloleva näite põhjal root kasutaja kodukataloogi ning käivitatakse hiljem root kasutaja õigustes!
Keerame ennast root kasutajaks ning loome skripti:
sudo -i vi uuenda.sh
Skripti lisa järgmised käsud:
#!/bin/bash cd /etc/apache2/crl/ rename -vf 's/\.crl$/\.old/' *.crl wget http://www.sk.ee/crls/esteid/esteid.crl wget http://www.sk.ee/crls/esteid/esteid2007.crl wget http://www.sk.ee/crls/juur/crl.crl openssl crl -in esteid.crl -out esteid.crl -inform DER openssl crl -in esteid2007.crl -out esteid2007.crl -inform DER openssl crl -in crl.crl -out crl.crl -inform DER rm -f *.r? n="0";for f in `ls *.crl`;do ln -s $f `openssl crl -hash -noout -in $f`.r$n ;let n=n+1;done /etc/init.d/apache2 restart
Peale skripti tekitamist ära unusta sellele käivitusõigust anda:
chmod 700 uuenda.sh
Sagedamini, kui kord ööpäevas, ei ole mõtet tühistusnimekirju alla laadida, kuna need ei pruugi sagedamini uueneda.
Arvestama peab ka sellega, et peale igat uuendamist taaskäivitatakse veebiserver. Seadete uuesti laadimine (kill -HUP) ei aita!
Taaskäivituse tõttu lähevad kaotsi kõik kasutajate sessioonid.
Loome root kasutajale uue cron-i töö ning paneme selle käivituma igal öösel kell 3:
Avame cron-i tööde nimekirja:
crontab -e
Cron-i tööde avamisel võidakse küsida kasutajale sobivat editori:
Select an editor. To change later, run 'select-editor'. 1. /bin/ed 2. /bin/nano <---- easiest 3. /usr/bin/vim.tiny Choose 1-3 [2]:
Vali endale sobiv editor ning lisa tööde nimekirja järgmine rida:
0 3 * * * /root/uuenda.sh
Töö käivitamise kella ja päeva saad vajadusel ise mudida, cron-i formaat on järgmine:
minut<0-59> tund<0-23> kuupäev<1-31> kuu<1-12> nädalapäev<0-6> käsk
Salvesta ära ja kontrolli järgmise käsuga:
crontab -l
Sertifikaatide info edasine kasutus
kui tahta, et server sertifikaatide andmed muutujatesse kannaks (et need oleks skriptides kasutatavad), võiks lisada .htaccess faili midagi sellist:
<Files ~ "\.(cgi|shtml|php)$"> SSLOptions +StdEnvVars +ExportCertData </Files>
Varundus ja taastamine
Varundamiseks kopeeri allolevates kataloogides asuvad failid alternatiivsele andmekandjale.
Taastamiseks toimi vastupidiselt.
Failiõiguste säilitamiseks ja andmete tihendamiseks kasuta tar käsku.
Andmete asukohad
Veebilehekülje failid: /var/www/www/secure
Apache2 konfiguratsioon: /etc/apache2
Veebiserveri logifailid: /var/log/apache2
Varundamise ja taastamise näited
Varundame secure kataloogi sisu juurkataloogis asuvasse faili secure.tar.gz
sudo tar -cvzf /secure.tar.gz /var/www/www/secure/*
Taastame secure kataloogi sisu juurkataloogis olevast failist secure.tar.gz endisesse asukohta:
sudo tar -xvzf /secure.tar.gz
Mis saab edasi?
- Kui sinu veebirakendus ei tohi mitte mingil juhul tühistatud sertifikaatidega autentijaid ligi lubada, siis seadista Sertifikaadi kehtivuse kontroll OCSP-ga
Juhendist
Juhendi koostasid:
- Andres Pelešev
- Argo Ellisson
Juhendi versioon 1.0
Versioon | Kuupäev | Muudatused |
---|---|---|
1.0 | 16:31, 26 December 2009 (EET) | Algne versioon |
1.1 | 17:17, 29 December 2009 (EET) | Lisatud secure kataloogile http kaudu ligipääsu keelamine |
viimati muudetud