2008.04_Kryptografia_[Bezpieczenstwo].pdf

Bezpieczeństwo

Kryptograia – koniguracja serwerów WWW

Kryptograia

Radosław Podedworny

Mało kto zdaje sobie sprawę, iż najpopularniejsza usługa internetu, jaką niewątpliwie jest www, swoje

powstanie zawdzięcza izyce cząstek elementarnych. Na początku lat 90-tych pewien naukowiec -

Tim Bernes-Lee zapragnął podzielić się wynikami swoich badań z innymi. Aby tego dokonać stworzył

podstawy języka HTML. Dwa lata później powstała pierwsza przeglądarka internetowa Mosaic, kolejne

12 miesięcy trzeba było czekać na pierwszego Netscape Navigatora. Reszta potoczyła się już lawinowo.

cją serwerów, w szczególności tych, których za-

daniem jest przechowywanie i wyświetlanie za-

wartości witryn www, z pewnością spotkała się z

serwerem Apache. Według witryny netcraft.net jest to najbar-

dziej popularny serwer www na świecie. Według danych z lip-

ca 2007 roku, co drugi serwer www działa pod kontrolą ser-

wera Apache. Ma on również godnych przeciwników, do gru-

py których niewątpliwie należy microsoftowy IIS (jak podaje

Ben Laurie w książce Apache, przewodnik encyklopedyczny ,

lista pozostałych konkurentów wynosi około 80 serwerów).

Co ciekawe: przewaga Apache nadal jest duża, jednak patrząc

na ostatnie kilka lat można stwierdzić, iż IIS odrabia straty (Li-

piec 2007: Apache: 50%; IIS: 35%; Listopad 2005: Apache:

70%; IIS:20%).

Apache zawdzięcza swoją popularność platformie w

skrócie opisanej jako LAMP. Jest to akronim od Linux,

Apache, MySQL, Perl/Php. Platforma ta jest konkurencją

dla ASP.NETu. I chociaż w wyżej wymienionym skrócie na

pierwszej pozycji pojawia się Linux, to jednak istnieją wer-

sje serwera Apache dedykowane innym systemom opera-

cyjnym, w szczególności: FreeBSD, NetBSD, OpenBSD,

SunOS, UnixWare, AIX, IRIX, HPUX, SCO, Microsoft

Windows. Swoją popularność Apache zawdzięcza również

licencji freeware, na zasadzie której jest rozprowadzany.

Bardzo ciekawa jest również historia powstania samej

nazwy serwera. W skrócie wygląda ona tak: w chwili powsta-

wania serwera składał się on z pewnego ukończonego kodu,

Rysunek 1. Struktura katalogu domowego OpenSSL

kwiecień 2008

P raktycznie każda osoba stykająca się z konigura-

Bezpieczeństwo

Kryptograia – koniguracja serwerów WWW

a wszystkie modyikacje/ulepszenia dodawane

były za pomocą łat (ang: a patch ). Stąd powsta-

ła nazwa, opierająca się na grze słów. Jest rów-

nież spora część osób, która twierdzi, że nazwa

pochodzi od północnoamerykańskiego plemie-

nia Indian i takowa ma kojarzyć się z waleczno-

ścią i zaradnością przypisywaną Apaczom.

W chwili obecnej Apache rozwijany jest w

trzech wersjach: 1.3, 2.0 oraz 2.2 (konigurowa-

na w niniejszym artykule). Szczegółowe infor-

macje o każdej z nich znajdują się na stronie do-

mowej projektu: http://httpd.apache.org/docs/ .

Jeden z głównych problemów, na który na-

tknęli się developerzy związany był z faktem, iż

serwer mógł obsługiwać wiele różnych rozsze-

rzeń. Klasycznym przykładem jest wspomnia-

na powyżej obsługa języka skryptowego PHP.

Z jednej strony wiele serwerów korzysta z nie-

go, niemniej jednak nie jest on niezbędny i ist-

nieją takowe, które go nie potrzebują. Oczywi-

ście można wszystkie rozszerzenia zaaplikować

na stałe do głównego pliku serwera, ale jest to

rozwiązanie nieeleganckie oraz marnotrawiące

zasoby. W zamian za to opracowano mechani-

zmy modułów, które w razie potrzeby mogą być

dynamicznie ładowane w czasie działania Apa-

che. Generalnie są dwie metody zarządzania i ła-

dowania modułów Apache: DSO oraz APXS,

przy czym druga jest wygodniejsza a przez to

i częściej stosowana. Więcej informacji na te-

mat poszczególnych metod można znaleźć w

dokumentacji.

Listing 1. OpenSSL – główny plik koniguracyjny:

[ ca ]

default_ca = CA_default # domyślna sekcja CA

[ CA_default ]

dir = ./ mojadomena . pl # Katalog główny

certs = $ dir / certs # Podkatalog z certyikatami

crl_dir = $ dir / crl # Podaktalog z listami

odwołanych certyikatów

database = $ dir / index . txt # Plik indeksu

new_certs_dir = $ dir / newcerts # Domyślny podkatalog dla

nowych certyikatów

certiicate = $ dir / cacert . pem # Certyikat CA

serial = $ dir / serial # Aktualnu numer seryjny

crl = $ dir / crl . pem # Akutalna lista CRL

private_key = $ dir / private / cakey . pem # Prywatny klucz CA

[ policy_anything ]

countryName = optional

stateOrProvinceName = optional

localityName = optional

organizationName = optional

organizationalUnitName = optional

commonName = supplied

emailAddress = optional

Obsługa SSL w Apache

Obsługa protokołu SSL ( Secure Socket Layer )

jest jednym z dobrych przykładów na pokazanie

różnic pomiędzy poszczególnymi wersjami ser-

wera Apache. Kod źródłowy wersji 1.3 nie posia-

dał żadnych mechanizmów SSL. Po części by-

ło to związane z polityką Stanów Zjednoczonych

dotyczącą ograniczeń eksportowych mechani-

zmów kryptograicznych. Zamiast tego obsługa

SSL dostępna była w osobnym pakiecie o nazwie

Apache-SSL będącym zbiorem łat, aplikowanych

do standardowych źródeł Apache 1.3. W chwili

pisania niniejszego artykułu najnowsza stabilna

wersja Apache-SSL to apache_1.3.34+ssl_1.57

wydana 21 grudnia 2005 roku. Należy również

wspomnieć, iż istnieje alternatywne rozwiązanie

obsługi SSL dla wersji 1.3 bazujące na module

mod_ssl . W wersji 2.x zrezygnowano z łat Apa-

che-SSL na korzyść modułu mod_ssl . Rozbudo-

wano również listę zmiennych środowiskowych

oraz zmodyikowano składnię koniguracji ser-

werów wirtualnych.

Rysunek 2. Generowanie kluczy dla nowego CA

Koniguracja serwera Apache

Niniejszy artykuł nie będzie opisywał, jak skon-

igurować serwer www od podstaw. Zakładam

Rysunek 3. Uruchomienie serwera Apache z modułem mod_ssl

www.lpmagazine.org

Bezpieczeństwo

Kryptograia – koniguracja serwerów WWW

więc, że nie obce są Ci mechanizmy działania

serwera www, miejsce przechowywania oraz

składnia głównych plików koniguracyjnych, de-

inicja wirtualnych hostów. W poprzednim arty-

kule z serii praktycznej kryptograii przedstawio-

ne zostały podstawy kryptograii symetrycznej/

asymetrycznej oraz praktyczne przykłady koni-

guracji popularnych serwerów poczty. Niniejsza

część zostanie w całości poświęcona koniguracji

serwerów oraz programów klienckich korzysta-

jących z usługi www. Tak jak napisałem wcze-

śniej – poniższej koniguracji sami staniemy się

CA i będziemy podpisywać własne (a może nie

tylko?) certyikaty. Zanim jednak do tego przej-

dziemy, zmodyikujmy plik openssl.cnf tak, aby

znalazły się w nim następujące wpisy (Listing 1).

Kolejnym krokiem będzie stworzenie w kata-

logu /etc/pki/tls następującej struktury (Rysu-

nek 1). Uwaga! - plik index.txt powinien być

plikiem pustym. W pliku serial oraz crlnum-

ber należy wpisać wartość 01 (np. za pomocą

polecenia: echo 01 > ./serial )

Podczas tworzenia kluczy zostaniemy po-

proszeni o hasło, zgodnie z Rysunkiem 2.

Kolejnym krokiem będzie wygenerowanie

pliku csr :

openssl req -new -out mojadomena.pl/

ca-csr.pem -key mojadomena.pl/

private/cakey.pem

Tworzymy swoje własne CA

Czas przystąpić do stworzenia kluczy i cer-

tyikatu naszego CA. Najpierw wygeneruje-

my klucze:

Teraz można już przystąpić do tworzenia cer-

tyikatu naszego CA oraz pliku zawierające-

go listy crl (Listing 3).

CA zostało przez nas stworzone! Teraz

zajmijmy się wygenerowaniem certyikatu dla

naszej witryny www. Załóżmy, iż będzie ona

znajdować się pod adresem https://www.mojab

ezpiecznadomena.pl . Najpierw jednak wygene-

rujmy parę kluczy:

openssl genrsa -des3 -out

mojadomena.pl/private/cakey.pem 2048

Listing 2. Koniguracja hosta wirtualnego, plik ssl.conf

LoadModule ssl_module modules / mod_ssl . so

Listen 443

AddType application / x - x509 - ca - cert . crt

AddType application / x - pkcs7 - crl . crl

SSLPassPhraseDialog builtin

SSLSessionCache shmcb : / var / cache / mod_ssl / scache ( 512000 )

SSLSessionCacheTimeout 300

SSLMutex default

SSLRandomSeed startup ile : / dev / urandom 256

SSLRandomSeed connect builtin

SSLCryptoDevice builtin

openssl genrsa -des3 -out

mojadomena.pl/private/wwwserwer-

key.pem 2048

Jak poprzednio, tak i teraz zostaniemy popro-

szeni o podanie hasła zabezpieczającego do-

stęp do nowo wygenerowanej pary kluczy.

Uwaga ! Hasło powinno mieć minimum 4

znaki. W screenie pokazano nieudaną próbę

ustalenia hasła składającego się z 3 znaków.

Teraz wygenerujmy plik csr:

< VirtualHost 10.0 . 0.201 : 443 >

DocumentRoot "/var/www/html/bezpiecznadomena.pl"

ServerName www . mojabezpiecznadomena . pl : 443

ErrorLog logs / bezpiecznadomena - ssl_error_log

TransferLog logs / bezpiecznadomena - ssl_access_log

LogLevel warn

SSLEngine on

SSLProtocol all - SSLv2

SSLCipherSuite ALL :! ADH :! EXPORT :! SSLv2 : RC4 + RSA :+ HIGH :+ MEDIUM :+ LOW

openssl req -new -out wwwserwer-

csr.pem -key mojadomena.pl/private/

wwwserwer-key.pem

Listing 3. Tworzenie pliku crl

# openssl req -in mojadomena.pl/

ca-csr.pem -out mojadomena.pl/

cacrt.pem -key mojadomena.pl/

private/CA-key.pem -x509 -days 3652

# openssl ca -gencrl -out

mojadomena.pl/crl.pem

SSLCertiicateFile / etc / pki / tls / wwwserwer - crt . pem

SSLCertiicateKeyFile / etc / pki / tls / mojadomena . pl / private / wwwserwer - key . pem

SSLCACertiicateFile / etc / pki / tls / mojadomena . pl / cacert . pem

< Files ~ " \. (cgi|shtml|phtml|php3?)$" >

SSLOptions + StdEnvVars

< / Files >

< Directory "/var/www/cgi-bin" >

SSLOptions + StdEnvVars

< / Directory >

Listing 4. Eksport certyikatu klienckiego do

pliku *.p12

openssl pkcs12 -export -in klient1-

crt.pem -out klient1.p12 -name

"Certyikat kliencki"

-inkey ./mojadomena.pl/private/

klient1.pem

SetEnvIf User - Agent ".*MSIE.*" \

nokeepalive ssl - unclean - shutdown \

downgrade - 1.0 force - response - 1.0

Listing 5. Wpisy w koniguracji serwera Apache

dotyczące certyikatów klienckich:

SSLOptions +OptRenegotiate

SSLVerifyClient require

SSLVerifyDepth 2

</Location>

CustomLog logs / ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \" %r \" %b"

< / VirtualHost >

kwiecień 2008

Bezpieczeństwo

Kryptograia – koniguracja serwerów WWW

Uwaga - w polu Common Name należy wpisać

adres, pod którym będzie się znajdować domena.

Ostatnim krokiem będzie podpisanie pliku

csr za pomocą stworzonego wcześniej CA.

Wynikiem tego powinien być gotowy certy-

ikat (w poniższym przykładzie ważność na-

szego certyikatu ustaliliśmy na 100 dni).

łączyła się tylko i wyłącznie osoba zajmu-

jąca się bazami danych. Oczywiście może-

my tak skonfigurować ścianę ogniową, aby

połączenia na port 443 przepuszczane by-

ły tylko z konkretnego adresu IP. Rozwią-

zanie proste, niemniej jednak nasz admini-

strator łączy się z internetem np. za pomo-

cą Neostrady, która za każdym razem przy-

dziela mi inny adres IP. W tym przypadku

rozwiązanie z konfiguracją ściany ognio-

# openssl ca -in wwwserwer-csr.pem

-out wwwserwer-crt.pem -days 100 -

policy policy_anything

Teraz, możemy zająć się ostatnim krokiem

– koniguracją serwera www. W przypadku

CentOSa edycji poddamy plik /etc/httpd/

conf.d/ssl.conf (Listing 2). Teraz wystarczy

już tylko uruchomić serwer Apache. Pod-

czas uruchomienia zostaniemy poinformo-

wani o tym, iż dostęp do kluczy jest chro-

niony hasłem i należy je podać aby urucho-

mić serwer http (Rysunek 3). Pytanie o ha-

sło będzie się pojawiać za każdym razem

kiedy usługa będzie uruchamiana. W niektó-

rych przypadkach może to być utrudnieniem

– zwłaszcza, gdy będziemy chcieli aby usłu-

ga uruchamiała się automatycznie. Możemy

temu zaradzić wykonując na naszym kluczu

następujące polecenia:

Rysunek 4. Zaimportowany certyikat CA do Firefoxa

# cp wwwserwer-key.pem wwwserwer-

key.pem_oryginal

# openssl rsa -in wwwserwer-key.pem_

oryginal -out wwwserwer-key.pem

Teraz możemy wejść na naszą stronę za po-

mocą szyfrowanego połączenia. Oczywi-

ście za każdym razem kiedy będziemy na

nią wchodzić dostaniemy komunikat o tym,

iż organ certyikacji podpisujący certyikat

strony nie jest zaufany. Rozwiązaniem jest

import do magazynu Organów certyikacji

pliku cacert.pem . Poniższe screeny pokazują

zaimportowany certyikat w przeglądarkach

IE oraz Firefox (Rysunek 4 i 5).

Certyikaty klienckie

Czasami sam fakt, iż połączenie z witry-

ną jest szyfrowane nie wystarcza. Rozważ-

my następującą sytuację: firma X zajmuje

się tworzeniem stron www. Strony te opar-

te są na bazach MySQL (dla ułatwienia za-

łóżmy, iż praca na bazach danych odbywa

się za pomocą przeglądarki www oraz pa-

kietu phpmyadmin). Osoba konfigurująca

bazy danych pracuje zdalnie. Chcielibyśmy

dać jej dostęp do serwera witryny z zain-

stalowanym phpmyadminem, zabezpie-

czyć go szyfrowanym kanałem i dodatko-

wo mieć pewność, iż z w/w. witryną będzie

Rysunek 5. Zaimportowany certyikat CA do IE

Rysunek 6. Próba połączenia bez ważnego certyikatu klienckiego (Firefox)

www.lpmagazine.org

Bezpieczeństwo

Kryptograia – koniguracja serwerów WWW

wej bądź jakiekolwiek inne bazujące na autoryza-

cji na podstawie adresu IP wydaje się błędne. Do

tematu podejdziemy więc inaczej: wygenerujemy

certyikat, który nasz administrator baz danych

będzie musiał zaimportować do swojej przeglą-

darki, a serwer skonigurujemy tak, że połącze-

nia z witryną w której znajduje się phpadmin bę-

dą możliwe tylko dla tych klientów, którzy przed-

stawią się wystawionym przez nas certyikatem.

Sposób ten niesie ze sobą dodatkowe plusy: w

chwili gdy zechcemy dać kolejnemu pracowniko-

wi dostęp do wspomnianej witryny, wystarczy że

wygenerujemy kolejny certyikat. Z drugiej stro-

ny w każdej chwili będziemy mogli odwołać ist-

niejący certyikat a co za tym idzie odebrać da-

nej osobie prawo do łączenia się z naszą witry-

ną. Wróćmy więc do konsoli naszego serwera i

wygenerujmy kolejną parę kluczy oraz plik csr :

Jak widać robimy to w analogiczny sposób jak

w przypadku certyikatów dla naszego serwera

www. W kolejnym kroku należy podpisać plik

csr poleceniem:

W kolejnym kroku wyeksportujemy certyi-

kat kliencki do pliku *.p12. Wykonamy to za

pomocą następującego polecenia (Listing 4).

Najpierw zostaniemy poproszeni o hasło do-

stępu do kluczy, później o hasło eksportu. Je-

śli wszystko poszło ok, powinniśmy otrzymać

certyikat kliencki: klient1.p12 Teraz zmody-

ikujmy konigurację naszego serwera http.

Modyikacja ta polegać będzie na dodaniu na-

stępujących wpisów w pliku ssl.conf (w mo-

im przypadku wpisy te dodałem zaraz za linią

deiniującą SSLCACertyicateFile ) (Listing 5).

Po restarcie spróbujmy ponownie wejść na na-

szą stronę. Tym razem (w zależności od prze-

glądarki) pojawi się następujący komunikat:

(Rysunek 6 i 7). Aby strona była dostępna nie-

zbędna jest instalacja certyikatu klienckie-

go. Zaimportujmy go więc do obydwu prze-

glądarek i spróbujmy wejść na stronę ponow-

nie. Tym razem Firefox nie wyświetli żadnych

komunikatów, po prostu wyświetli zawartość

strony. IE natomiast pokaże okno z certyika-

tami, w którym należy wskazać ten zaimpor-

towany (Rysunek 8).

# openssl ca -in klient1-csr.pem

-out klient1-crt.pem -days 100 -

policy policy_anything

Rysunek 7. Próba połączenia bez ważnego certyikatu klienckiego (IE)

Zamiast zakończenia

Tradycyjnie pod koniec artykułu przypominam

i zachęcam do zapoznania się z dokumentacją

– przede wszystkim dotyczącą OpenSSLa. Go-

rąco polecam również książkę Kryptograia w

praktyce autorstwa N. Fergusona i B. Schneiera

oraz wspomniany na początku Podręcznik En-

cyklopedyczny do Apache autorstwa Bena Lau-

rie. Mam nadzieję, że udało mi się wprowadzić

i zainteresować Szanownych Czytelników te-

matyką kryptograii w aspekcie zabezpieczania

usług www. Chciałbym jednak, abyśmy zda-

wali sobie sprawę, iż mechanizmy te powinny

być tylko jednym z klocków budujących cało-

kształt bezpieczeństwa naszych serwerów – cy-

tując wspomnianego wyżej Fergusona: Zbyt

wielu informatyków traktuje kryptograię jako

magiczny pył bezpieczeństwa, którym wystar-

czy oprószyć system, aby natychmiast stał sie

bezpieczny (...) O pewności systemów zabezpie-

czeń decyduje zawsze jego najsłabsze ogniwo .

Powodzenia.

O autorze

Rysunek 8. Próba połączenia z ważnym certyikatem klienckim

Autor od 9 lat pracuje jako admini-

strator systemów, aktualnie w jednej

z dużych trójmiejskich irm informa-

tycznych. Preferowane przez niego

systemy to Linux oraz OpenBSD.

Kontakt z autorem: radoslaw.podedwor-

ny@gmail.com

kwiecień 2008

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: