ID kaardiga autentimine Apache2 veebiserveriga

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://sk.ee/upload/files/JUUR-SK.PEM.cer
sudo wget http://sk.ee/upload/files/EECCRCA.pem.cer
sudo wget http://sk.ee/upload/files/ESTEID-SK.PEM.cer
sudo wget http://sk.ee/upload/files/ESTEID-SK%202007.PEM.cer
sudo wget http://sk.ee/upload/files/ESTEID-SK%202011.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/juur/crl.crl
sudo wget http://www.sk.ee/crls/esteid/esteid2007.crl
sudo wget http://www.sk.ee/crls/eeccrca/eeccrca.crl
sudo wget http://www.sk.ee/repository/crls/esteid2011.crl

Seadistamine

ID kaardi juursertifikaatide seadistamine

Pane kõik 3 juursertifikaati kokku ühte faili, et veebiserveril oleks lihtsam neid lugeda:

cd /etc/apache2
sudo cat JUUR-SK.PEM.cer EECCRCA.pem.cer ESTEID-SK.PEM.cer ESTEID-SK\ 2007.PEM.cer ESTEID-SK\ 2011.pem.cer > juur.crt

Sertifikaatide tühistusnimekirjade seadistamine

Kuna allalaetavad tühistusnimekirjad on apache jaoks loetamatul kujul, siis on vaja need konverteerida PEM formaati:

sudo -i
cd /etc/apache2/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
openssl crl -in eeccrca.crl -out eeccrca.crl -inform DER
openssl crl -in esteid2011.crl -out esteid2011.crl -inform DER

Apache dokumentatsioonis nõutakse ka räsi-linkide loomist. Genereerime need käsuga:

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:

mkdir /var/www/www/secure
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
wget http://www.sk.ee/crls/eeccrca/eeccrca.crl
wget http://www.sk.ee/repository/crls/esteid2011.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
openssl crl -in eeccrca.crl -out eeccrca.crl -inform DER
openssl crl -in esteid2011.crl -out esteid2011.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
• Loe ka http://www.arvutikaitse.ee/?p=2772

Chromiumile autentimine

sudo apt-get install libnss3-tools 
modutil  -dbdir sql:$HOME/.pki/nssdb -delete opensc-pkcs11 
modutil  -dbdir sql:$HOME/.pki/nssdb -add opensc-pkcs11 -libfile /usr/lib/onepin-opensc-pkcs11.so -mechanisms FRIENDLY

Juhendist

Juhendi koostasid:

• Andres Pelešev
• Argo Ellisson

Versioonide ajalugu:

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
1.2	Apelesev 04:40, 17 January 2010 (EET)	Eemaldatud üleliigsed sudo käsud
1.3	Kkalder 13:34, 11 September 2011 (EET)	Sertifikaatide asukoht on muutnud ja sertifikaate on juurde tulnud