Rozdział 30.

Bezpieczeństwo serwera WWW i kontrola dostępu

Bezpieczeństwo w Internecie jest bardzo istotnym i szeroko dyskutowanym zagadnieniem. Wielki postrach wzbudzili ludzie zwani hackerami, którzy włamują się do różnych syste­mów za pomocą telefonu i kilku oporników, siejąc spustoszenie w przechowywanych tam plikach. Ponieważ Twój serwer WWW jest uruchomiony w sieci Internet, jest on potencjal­nym obiek­tem takiego ataku i powinieneś w związku z tym zatroszczyć się o jego bezpie­czeństwo.

Przesadny rozgłos, jaki zyskała sobie tematyka włamań do systemów w sieci Internet, jest w dużej mierze zasługą mediów, które muszą przecież mieć o czym pisać. Niebezpieczeń­stwo zniszczenia danych w systemie komputerowym przez kogoś, kto nielegalnie dostanie się do niego przez sieć istnieje i należy brać je pod uwagę, ale nie zdarza się to tak często, jak mog­łoby wynikać z niektórych publikacji. Zagrożenie ze strony hackerów, którzy zech­cą dobrać się do systemu poprzez serwer WWW jest bardzo małe. HTTP to prosty proto­kół, mający jedynie kilka powszechnie znanych luk, pozwalających na dostęp z zew­nątrz. Tak naprawdę to administrator serwera WWW powinien dużo bardziej obawiać się użytkowników, mających bezpośredni dostęp do komputera, na którym serwer jest uru­cho­miony, bowiem zdecydowanie więcej szkody może wyrządzić instalowanie nieznanego oprogramowania lub dopuszczenie do maszyny kogoś nieupoważnionego.

W mojej książce nie ma na tyle miejsca, abym mógła pozwolić sobie na pełny opis zabezpie­czeń stosowanych w sieci Internet, ale sądzę, że osoby zainteresowane bez problemów znaj­dą jakąś pozycję na ten temat, jest ich bowiem dość dużo. Pragnę opisać kilka podstawowych technik zabezpieczania serwera WWW przed zagrożeniami zewnętrzny­mi i wewnętrznymi. Omówię też tematykę kontroli dostępu oraz autoryzację, które stanowią najprostszy mechanizm ochrony stron WWW przed ingerencją niepowoła­nych osób.

Notatka

Jeśli chcesz znaleźć bardziej wyczerpujące informacje dotyczące bezpieczeństwa w Internecie, to poszukaj następujących książek: Maximum Security: A Hacker's Guide to Protecting Your Internet Site wydanej przez wydawnictwo Sams Publishing, Internet Firewalls and Network Security wydanej przez wydawnictwo New Riders Publishing, Practical UNIX Security autorstwa Garfinkela i Spafforda i wydanej przez wydawnictwo O'Reilly & Associates, bądź Firewalls and Internet Security napisanej przez Cheswicka i Bellaviona i wydanej przez wydawnictwo Addison Wesley.

W rozdziale tym poruszone zostaną następujące tematy.

• Kilka wskazówek na temat tego, jak skutecznie zabezpieczyć serwer przed nieodpowiednimi użytkownikami z zewnątrz (oraz przed nieodpowiedzialnymi ludźmi we własnym gnieździe).

• Parę sugestii na temat pisania bezpiecznych skryptów CGI (a przynajmniej skryptów bez oczywistych luk).

• Kontrola dostępu do serwera WWW i autoryzacja użytkowników: co to jest, jak działa i do czego może się przydać.

• Ustawianie kontroli dostępu i autoryzacji na serwerze WWW.

• Opcje serwerów NSCA, ograniczające dostęp do niebezpiecznych opcji dla określonych użytkowników i katalogów.

	Posiadam wprawdzie podstawową wiedzę na temat bezpieczeństwa w sieciach komputerowych, jednakże nie mógłabym w żadnym razie nazwać siebie ekspertem w tej dziedzinie. W pracy nad tym rozdziałem pomagał mi Eric Murray, który od lat zajmuje się projektowaniem i programowaniem rozwiązań, zapewniających bezpieczeństwo w Internecie.

Jak lepiej zabezpieczyć serwer WWW?

Tak więc pragniesz zabezpieczyć swój serwer przed tym, co może go spotkać pod osłoną ciemności? Jeżeli tak, to dobrze trafiłeś, bowiem porady, które za chwilę przeczytasz, po­mogą ochronić system i pliki nie tylko przed intruzami z zewnątrz, ale także przed lo­kalnymi użytkownikami, którzy, celowo lub nie, przygotowując publikację swoich pre­zentacji, mogą wyrządzić naprawdę duże szkody.

Pamiętaj jednak, że im bezpieczniejszy będzie Twój serwer, tym mniej możliwości da się z niego wydobyć. Dwie najpoważniejsze luki, dzięki którym można dobrać się do danych na serwerze WWW to skrypty CGI oraz mechanizm SSI. Umożliwiają one zamieszczanie formularzy oraz stron WWW tworzonych „w locie”. W zależności od przyjętych założeń bezpieczeństwa danych na serwerze i tego, jakie możliwości powinien on udostępniać użyt­kownikom, możesz skorzystać ze wszystkich wskazówek zamieszczonych w tym roz­dziale lub też zastosować je tylko do pewnej grupy użytkowników.

Uruchom serwer jako użytkownik nobody

Standardowo większość UNIX-owych serwerów jest zdefiniowanych tak, aby program HTTPD uruchamiany był przez użytkownika nobody, należącego do grupy nogroup. Nobody i nogroup mają ograniczony dostęp do systemu operacyjnego, mają prawo zapisu tylko w kil­ku katalogach, co oznacza, że nie mogą zmieniać i kasować plików bez uzyskania spe­cjalnych uprawnień.

Uruchamianie serwera WWW przez użytkownika o ograniczonych uprawnieniach jest bar­dzo dobrym pomysłem. W ten sposób nikt z tych, którym uda się uzyskać dostęp do syste­mu za poś­rednictwem serwera, nie będzie mógł wyrządzić żadnych szkód poza wydzielo­nym obsza­rem. Jeżeli natomiast serwer zostanie uruchomiony przez użytkownika root, wła­my­wacz będzie mógł zrobić dokładnie wszystko to, co zechce, tak więc potencjalne straty mogą być ogromne.

Takie rozwiązanie ma oczywiście również swoje wady. Jeżeli zechcesz, aby serwer, mający uprawnienia użytkownika nobody sam zmienił treść skryptu CGI, będziesz musiał udostęp­nić mu ten plik w pełnym zakresie, tak aby cały świat miał do niego prawo zapisu. W ten sposób każdy będzie mógł zmienić jego treść, w tym momencie musisz wybrać, którą metodę zabez­pieczania danych chcesz zastosować.

Istnieją dwa rozwiązania tego problemu. Pierwszy z nich polega na tym, że należy użytkow­nika nobody uczynić właścicielem wszystkich plików przeznaczonych do zapisu, służy do tego polecenie chown (nie będziesz po nim w stanie nic do nich zapisać, tak więc musisz na pewno wiedzieć co robisz). Drugi sposób to utworzenie specjalnej grupy składającej się z ograni­czonej liczby użytkowników, w tym nobody i uruchomienie serwera HTTPD spod tej grupy (grupę można zmienić w plikach konfiguracyjnych). W ten sposób prawo do zapisu plików bę­dą mieli wszyscy członkowie grupy, a serwer również będzie miał do nich odpo­wiedni dostęp.

Ogranicz dostęp do skryptów CGI

Skrypty CGI pozwalają każdemu użytkownikowi sieci WWW na uruchamianie programów, które oparte są o wprowadzone przez niego dane, w systemie operacyjnym serwera. Mecha­nizm ten jest zdecydowanie najbardziej niebezpieczny z punktu widzenia bezpieczeństwa danych, przechowywanych na serwerze WWW. Umożliwiając wykonywanie skryptów CGI, na­rażasz serwer na potencjalne włamanie, uszkodzenie danych lub zwykłe przeciążenie systemu poprzez wywołanie zbyt wielu skryptów jednocześnie.

Najlepszym sposobem zabezpieczenia się przed takim ryzykiem jest wyłączenie mechaniz­mu CGI, a przynajmniej ograniczenie jego wykorzystania do kilku dobrze przetestowanych, bez­piecznych skryptów, które na pewno nie wyrządzą żadnej szkody. Z drugiej jednak strony, CGI oraz SSI dają tak wiele ciekawych możliwości, że trudno jest podjąć decyzję o całkowitym pozbyciu się tych mechanizmów.

Wobec tego najlepiej będzie ograniczyć wykorzystanie skryptów w systemie. Powinny się one znajdować w jednym miejscu, na przykład, w katalogu cgi-bin, i powinny mieć możli­wość jednoczesnego uruchamiania przez wielu użytkowników. Jeżeli pozwalasz twórcom stron na zamieszczanie własnych skryptów, sprawdź uprzednio każdy z nich pod kątem luk w zabezpie­czeniach, które mogą się tam znaleźć, w sposób zamierzony lub nie.

W dalszej części rozdziału „Jak pisać bezpieczne skrypty CGI” znajdziesz więcej infor­macji na temat pisania skryptów, tak aby nie stanowiły one potencjalnego zagrożenia dla bezpieczeń­stwa systemu.

Ogranicz zastosowanie połączeń symbolicznych

Połączenia symboliczne to coś w rodzaju aliasów, kolejnych wystąpień tego samego pliku w in­nym miejscu drzewa katalogów. Jeżeli w systemie operacyjnym połączenie tego typu zostanie utworzone do strony HTML, może ono zostać wykorzystane w adresie URL i ser­wer bez żadnych problemów odczyta taki plik.

Jeżeli wykorzystujesz serwer CERN HTTPD, nic nie stoi na przeszkodzie, aby twórcy pre­zentacji prowadzili połączenia symboliczne ze swoich stron do plików, które mogą znajdo­wać się w dowolnych miejscach drzewa katalogów, przez co są one dostępne praktycznie dla każ­dego użytkownika WWW. W zależności od Twojego podejścia do sprawy udostęp­niania plików na zewnątrz, możesz traktować to jako wadę lub jako kolejną opcję programu.

W serwerze NSCA istnieje możliwość wyłączenia przetwarzania połączeń symbolicznych. Nie oznacza to, że połączenia te zostaną usunięte, będą one dalej istniały, są bowiem zdefinio­wane w systemie operacyjnym, lecz serwer WWW nie będzie ich odczytywał. Aby to zrobić, należy usunąć zapis FollowSymLinks z pliku access.conf (więcej na temat tej opcji dowiesz się z dalszej treści tego rozdziału). Inna opcja, SymLinksOwnerMatch, pozwa­la na przetwarza­nie połączeń symbolicznych tylko wtedy, gdy właścicielem pliku i połącze­nia jest ten sam użyt­kownik. Jest to bezpieczniejsza metoda, która ogranicza wykorzystanie połączeń symbolicz­nych w obrębie drzewa katalogów jednego użytkownika.

Wyłącz SSI

Mechanizm SSI ze względu na swoje możliwości stanowi jedną z największych luk w bez­pieczeństwie serwerów WWW (szczególnie chodzi tu o polecenie exec, pozwalające na uru­chamianie skryptów). W ten sposób bardzo różne dane są przekazywane „w locie” na zew­nątrz przez serwer WWW, a Ty możesz łatwo stracić kontrolę nad tym procesem, nie możesz także przewidzieć, jaki będzie skutek takiej operacji dla systemu.

	Wyłączenie SSI oprócz zwiększenia bezpieczeństwa poprawia także szybkość, z jaką pliki są wysyłane przez serwer, bowiem nie muszą być za każdym razem przez niego przetwarzane.

Jeżeli jednak zdecydujesz się na korzystanie z SSI, możesz ograniczyć wykorzystanie tego mechanizmu, zabraniając wykonywania polecenia #exec, służy do tego opcja IncludesNoExec. Pozwala to wciąż na wykonywanie prostych poleceń, takich jak #include lub #echo, uniemożliwia jednak uruchamianie skryptów, co wydatnie zwiększa bezpieczeń­stwo, nie ograniczając przy tym zupełnie możliwości SSI.

Wyłącz wyświetlanie zawartości katalogów

Większość serwerów WWW ustawionych jest tak, że po nadejściu żądania URL kończą­cego się katalogiem, a nie plikiem, przyjmują pewną standardową nazwę pliku (z reguły jest to index.html) i dołączają ją do całości adresu. Ale co się stanie, jeżeli we wskazanym ka­talogu nie będzie pliku index.html? Standardową odpowiedzią serwera WWW jest w takim przypadku przesłanie listy plików, znajdujących się w danym katalogu, wyświetlanej w spo­sób przypominający zawartość serwera.

Ale czy stanowi to jakieś zagrożenie? Jeżeli nie przeszkadza Ci, że czytelnicy mogą prze­glądać zawartość katalogów, odpowiedź brzmi: nie. Jeżeli jednak w swoim katalogu prze­chowujesz jakieś prywatne dane lub nie do końca gotowe strony WWW, będzie to stanowi­ło pewien problem, bowiem każdy będzie mógł podejrzeć ich zawartość.

Istnieją dwa sposoby rozwiązania tego problemu.

• Umieszczaj w każdym katalogu plik index.html. W szczególnym przypadku może być to plik pusty (choć kilka słów wyjaśnienia będzie zawsze mile widziane przez czytelników).

• W przypadku serwera NSCA HTTPD mechanizm wyświetlania zawartości katalogów jest standardowo wyłączony. Jednakże w przykładowym pliku access.conf znajduje się następująca linia:

Options Indexes FollowSymLinks

Jeżeli zechcesz wykorzystać ten plik, to usunięcie z linii słowa Indexes spowodu­je włączenie omawianego mechanizmu.

Odetnij robotom sieciowym dostęp
do swojego serwera

		Roboty sieciowe (czasami określane po prostu jako roboty) to programy, które zajmują się automatycznym przeglądaniem zawartości stron WWW. Podążają one zgodnie z kolejnymi połączeniami i zapisują w swoich bazach da­nych nazwy plików, ich adresy URL, a czasami nawet całą zawartość. Utworzone w ten spo­sób zbiory danych służą następnie do wyszukiwania słów kluczowych, dzięki czemu użytkow­nicy mogą szybko odnaleźć strony, zawierające interesujące ich wyrażenia.
		Pomysł wygląda fantastycznie, nieprawdaż? Niestety, prawda jest taka, że sieć rozrasta się zbyt gwałtownie i roboty nie nadążają z indeksowaniem wszystkich nowych stron. Najlepsze z tych programów, funkcjonujące na bardzo szybkich i kosztownych komputerach, potrzebują aż sześciu miesięcy na przejrzenie całej sieci. Jednakże stron w sieci przybywa znacznie szybciej i żaden robot nie jest w stanie dotrzymać kroku temu rozwojowi. Należy stwierdzić, że programy, takie jak WebCrawler (http://www.webcrawler.com/) czy AltaVista (http://www.altavista.com/), obejmują swoim zasięgiem sporą część światowych zasobów WWW i wyszukiwanie za ich pomocą przynosi całkiem przyzwoite efekty.

Problem z robotami polega na tym, że kiepski program może przeciążyć serwer ciągłymi żądaniami przesyłania kolejnych stron. Może się to też skończyć próbą odczytania z ser­wera takich plików, które nigdy nie powinny być odczytywane. Z tych powodów producenci robo­tów wyszli z inicjatywą wprowadzenia opcji, która uniemożliwiałaby ich programom przeszu­kiwanie całości lub części plików na serwerach WWW.

Aby odciąć roboty sieciowe od plików na swoim serwerze, musisz utworzyć plik o nazwie robots.txt i umieścić go na najwyższym poziomie drzewa katalogów, tak aby jego URL wyglądał następująco: http://nazwa.serwera/robots.txt.

W pliku tym powinna znaleźć się jedna lub kilka linii, które zabraniają lub zezwalają okreś­lonym programom (user-agents) na dostęp do stron na Twoim serwerze oraz jedna lub kil­ka linii opisujących katalogi, do których dostęp ma zostać odcięty (disallowed). Naj­pros­tsza postać pliku robots.txt („żadnych robotów na moim serwerze!”) wygląda następują­co:

User-agent: *Disallow: /

Jeżeli nie chcesz, aby jakikolwiek robot przeglądał pliki znajdujące się w katalogu /data i we wszystkich jego podkatalogach (mogą się tam znajdować pliki, przeznaczone tylko i wy­łącznie do użytku wewnętrznego), plik robots.txt powinien wyglądać tak:

User-agent: *Disallow: /data/

Dodając kolejne linie, rozpoczynające się od wyrażenia User-agent oraz Disallow, możesz dopuszczać przeglądanie stron serwera przez określone programy, co do których działania nie masz żadnych wątpliwości. Poniższy przykład odcina dostęp do plików serwera wszyst­kim robotom z wyjątkiem WebCrawlera:

User-agent: *Disallow: /

#let webcrawler in /user

User-agent: WebCrawler/0.00000001

Disallow:

Należy pamiętać, że plik robots.txt jest sprawdzany tylko przez te roboty, których produ­cenci stosują się do przyjętych reguł. Każdy program, którego autor nie podporządkował się zasadom, może wciąż narobić sporego zamieszania w Twoim systemie, niemniej jednak umieszczenie tego zbioru „unieszkodliwia” większość standardowych robotów, przeszuku­jących sieć WWW. Więcej informacji na temat robotów, wykorzystania pliku robots.txt (również wskazówki, jak radzić sobie z „nieposłusznymi” programami) oraz nazwy progra­mów, które można umieszczać w liniach User-agent znajdziesz pod adresem http://web.nexor.co.uk/mak/doc/robots/robots.html.

Jak pisać bezpieczne skrypty CGI

Poprzednio wspomniałam, że pierwszą rzeczą, którą należałoby zrobić, aby zapewnić pełne bezpieczeństwo serwera WWW, jest rezygnacja z używania skryptów CGI. Bez tego nie można jednak korzystać z takich mechanizmów, jak formularze, przeszukiwanie stron, ak­tywne obrazki czy SSI. Wyłączenie CGI oznacza rezygnację z wielu bardzo atrakcyjnych możliwości, tak więc warto zastanowić się nad innym rozwiązaniem.

Sposobem tym może być pełniejsza kontrola skryptów. Upewnij się, że jesteś jedyną osobą, która umieszcza skrypty w katalogu CGI na Twoim serwerze, a najlepiej pisz wszystkie skrypty samodzielnie. Jest to najlepszy sposób na uzyskanie pewności, że nie będą one po­wodowały żadnych problemów. Pamiętaj, że jeżeli ktoś będzie bardzo chciał zaatakować Twój system, będzie próbował różnych sposobów, przy czym niekoniecznie będzie robił to tylko za pośred­nictwem luk w serwerze WWW. Ale nawet pobieżna kontrola wszystkich uruchamianych skryptów może powstrzymać niektórych hackerów.

Aby pisać bezpieczne skrypty, dobrze jest cierpieć na lekką paranoję i zakładać, że każdy jest potencjalnym złoczyńcą i będzie próbował różnych, przeważnie nieczystych sposobów, aby dobrać się do Twoich danych. Postaraj się jak najwięcej eksperymentować ze swoimi skrypta­mi i spróbuj przewidzieć, jakie dziwne argumenty mogą zostać przekazane z formu­larzy.

Dziwne argumenty? Niby jakie? Mogą to być polecenia przekazywane do skryptu, które zo­staną następnie przez niego wykonane. Oto część oryginalnej wersji skryptu pinggeneric, który opisywałam w rozdziale 18.:

#!/bin/sh

ison='who | grep $1'

Jak zapewne sobie przypominasz skrypt ten pobiera argument w postaci nazwy użytkownika i sprawdza, czy jest on w danej chwili obecny w systemie. Jeżeli jako argument podany zos­ta­nie identyfikator użytkownika, wszystko będzie w porządku, ale przecież nic nie stoi na przesz­kodzie, aby wpisać następującą linię:

foo; mail [e-mail] </etc/passwd

Nie jest to oczywiście nazwa użytkownika, oznacza to, że ktoś próbuje bawić się naszym skryptem. A co się stanie, gdy argument ten zostanie przekazany do skryptu? Ponieważ zos­tał on napisany tak, a nie inaczej, ostateczna postać wykonywanej linii będzie następująca:

who | grep foo; mail [e-mail] </etc/passwd

A co to oznacza? Jeżeli shell UNIX-a nie jest Ci zbyt dobrze znany, powiem, że średnik słu­ży do oddzielania od siebie kolejnych poleceń. Tak więc skrypt, oprócz sprawdzenia czy użyt­kownik foo jest aktualnie zalogowany w systemie, przesyła dodatkowo zawartość pliku /etc/passwd (plik z hasłami) na adres e-mail [e-mail]. Teraz, w wolnym czasie, intruz może spróbować rozszyfrować hasło i włamanie gotowe!

Co więc można zrobić, aby uszczelnić tę i podobne luki w zabezpieczeniach? Oto kilka wska­zówek.

• Zawsze umieszczaj argumenty skryptów w nawiasach i w cudzysłowie, tak aby $1 wyglądało jak ”${1}”. Ta prosta sztuczka w pewien sposób izoluje argumenty i nie pozwala, aby polecenia przemycone tą drogą były wykonywane, tak jak w przykładzie ze średnikiem.

• Szukaj w argumentach specjalnych znaków, takich jak średnik. Upewnij się, że dane przekazane do skryptu przynajmniej w ogólnym zarysie przypominają to, czego się spodziewasz.

• Używaj języka programowania, w którym przemycenie argumentów nie jest takie banalne, jak w przypadku shella (Perl, C).

• Jeżeli wykorzystujesz formularze, nigdy nie zaszywaj ważnych danych w postaci ukrytych pól formularza lub jako danych przekazywanych do skryptu, który jest określony argumentem ACTION. Pamiętaj, że treść formularza może podejrzeć dokładnie każdy, wystarczy tylko wybrać opcję podglądu pliku źródłowego w dowolnej przeglądarce. Tak więc czytelnik może zmienić dane i przesłać je do Twojego skryptu, który nie potrafi przecież stwierdzić, czy otrzymał je z oryginalnego, czy zmienionego formularza.

Kontrola dostępu do serwera WWW i autoryzacja — wprowadzenie

Gdy uruchomisz serwer WWW i opublikujesz za jego pomocą jakieś prezentacje, będą one dostępne dla każdego użytkownika przeglądarki, mającego dostęp do Internetu. W końcu o to przecież chodzi, prawda? Publikacja w sieci WWW oznacza ogólną dostępność.

Jednakże może się zdarzyć, że zechcesz opublikować pewne pliki, które nie powinny być oglądane przez wszystkich. Mogą to być nie do końca dopracowane strony, które zechcesz po­kazać tylko kilku wybranym osobom. Może to być prezentacja, która nie powinna być dostęp­na dla nikogo, kto znajduje się poza Twoją lokalną siecią komputerową (popularnie zwaną „intranetem”).

Do takich właśnie celów opracowane zostały mechanizmy kontroli dostępu i autoryzacji, które można uruchamiać i przypisywać konkretnym katalogom i plikom, znajdującym się na serwerze WWW. Takie chronione dane mogą bez problemów współistnieć z prezentacjami, które są powszechnie dostępne. Gdy ktoś nieuprawniony spróbuje je odczytać, serwer po prostu mu na to nie pozwoli.

W tej części dowiesz się wszystkiego na temat mechanizmów kontroli dostępu i autoryzacji serwerów NCSA oraz pochodnych: jak działają, jak dalece są bezpieczne i na czym polega ich ustawianie.

Zauważ, że nawet jeżeli nie używasz serwera WWW z rodziny NCSA, przedstawione tu koncepcje będą miały dla Ciebie pewną wartość. Autoryzacja funkcjonuje tak samo na każ­dym serwerze, inne są tylko pliki konfiguracyjne, które należy odpowiednio zmienić. Ze zdobytą tu wiedzą będziesz mógł bez problemów znaleźć odpowiednie miejsce w konfigu­racji dowolnego programu.

	Kontrola dostępu i autoryzacja to czysto techniczne tematy. Jeżeli tak naprawdę nie jesteś nimi zainteresowany, po dobrnięciu do końca tego rozdziału będziesz śmiertelnie znudzony. Wcale się nie obrażę, jeżeli zamiast się męczyć, przejdziesz się do kina lub na spacer. Baw się dobrze!

Co oznacza kontrola dostępu i autoryzacja?

Na początek parę słów na temat tego, co to właściwie jest kontrola dostępu i autoryzacja, i jak te mechanizmy funkcjonują w świecie serwerów oraz przeglądarek WWW.

Kontrola dostępu oznacza, że dostęp do plików i katalogów znajdujących się na serwerze WWW jest w jakiś sposób ograniczony. Można więc ograniczyć dostęp do plików z kon­kretnych komputerów w Internecie (pliki mogą być odczytywane tylko z sieci lokalnej), można też utworzyć zbiór użytkowników, którzy będą mieli swoje hasła i tylko po ich poda­niu uzyskają dostęp do określonych zasobów.

Jeżeli do ochrony plików zostanie wykorzystany pierwszy z wymienionych sposobów, opar­ty na nazwie komputera, to w wypadku próby odczytania któregoś z plików przez nie­odpo­wiedni komputer, serwer prześle przeglądarce błąd Access denied (ang. brak dostępu, a tak na­prawdę będzie to błąd serwera nr 403). Oznacza to, że w żadnym wypadku zastrze­żone pliki nie zostaną wysłane w nieodpowiednie miejsce (patrz rys. 30.1).

Rysunek 30.1 Brak dostępu

Autoryzacja pozwala na kontrolę dostępu do zbioru plików polegającą na tym, że użytkow­nik musi podać nazwę i hasło, aby uzyskać prawo do ich przeglądania. Gdy serwer stwier­dzi, że użytkownik przeglądarki podał właściwe dane, oznacza to, że pomyślnie przeszedł proces autoryzacji i żądane pliki mogą być do niego przesyłane.

Autoryzacja wymaga nawiązania dwóch kolejnych połączeń pomiędzy przeglądarką a ser­werem. Cały proces przedstawiony został na rys. 30.2.

W szczegółach, kolejne kroki tej procedury przedstawiają się następująco:

1. użytkownik przeglądarki wysyła żądanie przesłania pliku z zastrzeżonego katalogu,

2. serwer odczytuje przesłany URL i stwierdza, że odnosi się on do katalogu zastrzeżonego,

3. serwer przesyła przeglądarce żądanie autoryzacji (a konkretnie błąd 401 Unauthorized),

4. przeglądarka wyświetla okno dialogowe, w którym użytkownik może podać nazwę i hasło (rys. 30.3),

1. przeglądarka ponownie wysyła żądanie przesłania pliku, tym razem rozszerzone o podaną nazwę i hasło,

2. serwer porównuje dane użytkownika z danymi w swoich plikach kontroli dostępu,

3. jeżeli dane są poprawne, serwer przesyła żądany plik i udostępnia cały zastrzeżony katalog.

Rysunek 30.2 Autoryzacja
Rysunek 30.3 Żądanie podania nazwy użytkownika i hasła

Zwróć uwagę na to, że użytkownik, który raz zostanie poprawnie zidentyfikowany uzyskuje dostęp do wszystkich stron, znajdujących się w danym katalogu, bez konieczności ponow­nego wpisywania nazwy i hasła. Jego nazwa zapisywana jest oprócz tego w specjalnym logu za każdym razem, kiedy odczytuje jakiś plik lub przesyła formularz. Nazwa ta jest dostępna dla skryptów CGI w zmiennej środowiskowej REMOTE_USER.

	W środowisku WWW wykorzystywanie informacji uzyskiwanych drogą autoryzacji do celów innych niż informacyjne, traktowane jest, delikatnie mówiąc, jako nietakt. Nigdy nie nadużywaj tych danych.

Rodzaje kontroli dostępu

Aby włączyć kontrolę dostępu należy specjalnie skonfigurować serwer WWW. Po raz kolejny w tym rozdziale skupię się głównie na serwerach NCSA i CERN działających pod kontrolą systemów UNIX-owych — Twój serwer może okazać się do nich bardzo podobny pod tym względem. Serwer NCSA pozwala na ustanawianie kontroli dostępu do plików na różnych poziomach, możesz określić co chcesz zastrzec i komu chcesz to udostępnić.

NSCA pozwala na ochronę pojedynczych katalogów oraz całych ich zbiorów. Możesz zastrzec wszystkie pliki znajdujące się w określonym katalogu i jego podkatalo­gach, ale możesz rów­nież ograniczyć dostęp do wszystkich katalogów o nazwie public_html (znajdujących się w katalogach użytkowników).

NCSA nie oferuje ochrony dostępu na poziomie pojedynczego pliku. Można jednak obejść to ograniczenie, umieszczając ów plik w zastrzeżonym podkatalogu.

Ponadto serwer ten oferuje kontrolę dostępu w oparciu o nazwę komputera, nazwę domeny oraz całego lub tylko części adresu IP komputera, na którym uruchomiona jest przeglądar­ka. Możesz, na przykład, akceptować tylko połączenia z tego samego systemu, w którym znaj­duje się serwer lub też odrzucać wszystkie żądania, nadchodzące z konkretnej domeny.

Jeżeli chodzi o ochronę na poziomie użytkownika, NSCA udostępnia mechanizmy autory­zacji pojedynczych osób lub członków grup (można wtedy dopuszczać do pewnych danych tylko członków grupy o nazwie, powiedzmy Administracja). Owi użytkownicy oraz grupy są zupeł­nie niezależne od użytkowników i grup zdefiniowanych w systemie operacyjnym.

Oprócz tego można na tym samym komputerze definiować wiele plików haseł i grup, należą­cych do różnych schematów dostępu. Na przykład, możesz opublikować witrynę dostępną na zasadzie sub­skrypcji, dla której zdefiniujesz jeden zestaw grup, użytkow­ników i haseł, a także inną, zawierającą tajemnice przemysło­we, która będzie posiadała włas­ny, odrębny zestaw odbiorców. NSCA umożliwia tworze­nie różnych dziedzin haseł, dzięki cze­mu dostęp do poszczególnych katalogów może być kontrolowany na różnych pozio­mach.

Na ile bezpieczny jest serwer WWW?

Kontrola dostępu i autoryzacja to bardzo proste metody ochrony danych przed ciekawskimi użytkownikami. Naprawdę zatwardziali poszukiwacze informacji wciąż będą mogli znaleźć sposoby na obejście tego typu zabezpieczeń.

I tak ochrona na podstawie adresu IP oznacza tylko tyle, że komputer, który sam twierdzi, że jego adres jest odpowiedni, może uzyskać dostęp do określonych danych. Nie ma żadne­go sposobu, aby sprawdzić, czy rzeczywiście pochodzi on z systemu obdarzonego przez nas zaufaniem.

Jeżeli chodzi o bezpieczeństwo autoryzacji, to większość serwerów obsługuje metodę zwa­ną autoryzacją prostą. Jest to proces opisany w punkcie „Co oznacza kontrola dostępu i autory­zacja?”, w którym to procesie przeglądarka i serwer przeprowadzają ze sobą coś w rodzaju dialogu, którego celem jest ustalenie nazwy i hasła użytkownika.

Wprowadzane po stronie przeglądarki hasło jest przesyłane przez sieć w wersji zakodo­wanej (za pomocą systemu kodowania Base64), ale nie jest zaszyfrowane. Oznacza to, że każdy, kto odczyta odpowiedni pakiet lub przechwyci w jakiś sposób żądanie przeglądarki, może je łatwo rozkodować i uzyskać w ten sposób dostęp do zastrzeżonych plików na serwerze WWW.

Bezpieczniejsze formy autoryzacji bazują na wykorzystaniu prze­glądarek z opcją szyfrowania hasła lub też wykorzystują autoryzację prostą, w połączeniu z szyfrowanym połączeniem, jak, na przykład, mechanizm Netscape SSL. Więcej informacji na temat tej techniki znajdziesz w dalszej części tego rozdziału.

Kontrola dostępu i autoryzacja na serwerze NCSA HTTPD

Niniejszy punkt jest opisem ustawień kontroli dostępu i autoryzacji na serwe­rze NCSA HTTPD (oraz innych serwerach, działających w oparciu o niego, jak, na przykład, Apache czy WinHTTPD). Znajdą się tu ogólne instrukcje tworzenia plików kontroli dostępu dla ca­łego serwera oraz dla katalogów, opis kontroli dostępu według numeru IP oraz nazwy kompute­ra, jak również metody dodawania nowych użytkowników i grup. Po prze­czytaniu tego fragmentu będziesz także wiedział, jak serwer NCSA wykorzystuje kontrolę dostępu do sprawowania szerszego nadzoru nad różnymi swoimi mechanizmami (na przykład, skryptami CGI).

Globalna i lokalna kontrola dostępu

Metoda kontroli dostępu, wykorzystywana przez serwer NCSA umożliwia działanie global­ne, wpływające na wszystkie pliki znajdujące się na serwerze oraz lokalne, wykorzystujące specjalne pliki w poszczególnych katalogach. Ustawienia lokalne brane są pod uwagę w pierwszej kolejności, unieważniając jednocześnie ustawienia globalne oraz lokalne dla katalogów nadrzędnych (patrz rys. 30.4).

Rysunek 30.4 Schemat kontroli dostępu na serwerze NCSA

Standardowym plikiem kontroli dostępu dla całego serwera jest access.conf, znajdujący się w katalogu conf wraz z httpd.conf oraz srm.conf. Prawo do zapisu w tym pliku ma zwykle tylko użytkownik root, tak więc jako administrator możesz sprawować nad nim wy­łączną kontrolę. W nowszych wersjach serwera Apache wszystkie informacje konfiguracyjne zostały przeniesione do pliku httpd.conf. Oczywiście, wciąż można korzystać z pliku access.conf, jednak preferowanym rozwiązaniem jest umieszczenie wszystkich dyrektyw konfiguracyjnych w jednym pliku.

Pliki służące do sprawowania lokalnej kontroli dostępu noszą nazwę .htaccess (nazwę tę można zmienić w pliku srm.conf — jest to opcja AccessFileName). Ponieważ zmian w tych plikach może dokonywać każdy, użytkownicy serwera mogą samodzielnie zadbać o dostęp do swoich prezentacji, nie muszą w tym celu fatygować administratora, ani ponownie uru­chamiać serwera.

	Plik .htaccess może utworzyć każdy. Jednakże administrator określa w pliku access.conf, do czego może on zostać wykorzystany. Ustawienia w tych plikach nie będą unieważniały ustawień globalnych, jeżeli na to nie pozwolisz. Odpowiedź na pytanie, jak to zrobić, znajdziesz w dalszej części rozdziału.

Zapisy stosowane w plikach access.conf i .htaccess są do siebie bardzo podobne. Roz­pocznę od opisu pliku .htaccess, jest on bowiem częściej wykorzystywany i odrobinę łat­wiejszy.

Plik ten może zawierać w sobie kilka ogólnych dyrektyw oraz sekcję <LIMIT>. Mógłby on wyglądać, na przykład, tak:

Options Includes

AuthType Basic

AuthName „Subscribers Only”

AuthUserFile /home/www/magazine/.htpasswd

AuthGroupFile /home/www/magazine/.htgroup

<LIMIT GET>

require subscribers

</LIMIT>

Znaczenie wszystkich linii poznasz, czytając kolejne punkty tego rozdziału. Ważne jest, aby uś­wiadomić sobie, że ustawienia zapisane w pliku .htaccess dotyczą wszystkich plików w bie­żącym katalogu oraz w jego podkatalogach. Aby wprowadzić inne ustawienia dla któ­regoś z podkatalogów, należy umieścić w nim osobny plik .htaccess.

Format pliku globalnego access.conf jest bardzo podobny. Jedyna różnica polega na tym, że należy określić, którego katalogu dotyczą dyrektywy oraz sekcja <LIMIT>. Odbywa się to po­przez zamknięcie wszystkich linii wewnątrz sekcji <DIRECTORY>, jak w tym przykładzie:

<DIRECTORY /home/www/magazine>

Options Includes

AuthType Basic

AuthName „Subscribers Only”

AuthUserFile /home/www/magazine/.htpasswd

AuthGroupFile /home/www/magazine/.htgroup

<LIMIT GET>

require subscribers

</LIMIT>

</DIRECTORY>

Zauważ, że katalog, który zostanie objęty ustawieniami z tej sekcji, podany jest w pełnej postaci, tak jak w systemie operacyjnym. Aby określić ustawienia dla podkatalogów, należy utworzyć dla nich oddzielne sekcje <DIRECTORY> (nie wolno ich wzajemnie zagnieżdżać!), ich liczba może być dowolna.

	<DIRECTORY> oraz <LIMIT> przypominają nieco znaczniki HTML, ale nimi nie są. Próżno szukać ich w jakiejkolwiek specyfikacji języka, służą tylko i wyłącznie do ustawiania kontroli dostępu po stronie serwera.

Nic nie stoi na przeszkodzie, aby wykorzystywać zarówno standardowe ustawienia kontroli dostępu w pliku access.conf, jak i ustawienia indywidualne w plikach .htaccess. Takie rozwiązanie daje Tobie, jako administratorowi serwera WWW oraz użytkownikowi dużą elastyczność w tworzeniu ustawień dla poszczególnych prezentacji.

Kontrola dostępu ze względu na nazwę komputera

Najprostszą formą kontroli dostępu do katalogu jest zastrzeżenie go dla komputerów o ok­reś­lonej nazwie, a gwoli ścisłości, dla określonej nazwy, domeny, całości lub tylko części adresu IP. Chronione w ten sposób pliki będą przesyłane tylko przeglądarkom pracującym na komputerze, którego nazwa (domena, IP) odpowiada określonemu wzorcowi.

NSCA udostępnia kilka sposobów zastrzegania kontroli dostępu ze względu na nazwę komputera. Tak więc można wymieniać komputery, które będą miały dostęp do plików, jak również te, dla których dostęp będzie zabroniony. Oprócz tego istnieje możliwość łączenia tych dwóch metod. Oto prosty przykład odcięcia dostępu dla pewnej grupy komputerów. (Jest to fragment pliku .htaccess. Jeżeli zechcesz umieścić podobne wyrażenie w pliku access.conf, pamiętaj o wstawieniu go do sekcji <DIRECTORY>.)

<LIMIT GET>

deny from .netcom.com

</LIMIT>

Wyrażenie <LIMIT> mówi serwerowi, że nie może udostępniać plików z danego katalogu komputerom z domeny netcom.com. Aby z kolei zezwolić określonym komputerom na od­czyt plików z katalogu, należy posłużyć się następującym kodem:

<LIMIT GET>

deny from .netcom.com

allow from netcom16.netcom.com

</LIMIT>

Komputery, którym przyznajesz lub odbierasz prawo dostępu do katalogów na serwerze WWW, mogą być określane na kilka różnych sposobów.

• Pełne nazwy komputerów w postaci: komputer.domena.com (nazwa.szkola.edu). Pozwala to na kontrolę dostępu ściśle określonych, pojedynczych komputerów. Częściowe nazwy domen, jak, na przykład, .sun.com lub .ix.netcom.com, które odcinają lub przyznają dostęp komputerom z danej domeny (należy pamiętać o kropce przed nazwą domeny!).

• Pełne adresy IP, np. 194.56.23.12 — dają one taki sam efekt, jak pełne nazwy komputerów.

• Częściowe adresy IP, np. 194.194.45 lub 194.45.231 — pozwala to na kontrolę dostępu komputerów z sieci o numerze rozpoczynającym się od podanych liczb (w prak­tyce może to dać taki sam efekt, jak posługiwanie się nazwami domen). Maksymalnie można w ten sposób określić pierwsze trzy człony (bajty) adresu IP.

• All — pozwala na zastrzeżenie lub przyznanie dostępu wszystkim komputerom (jest to użyteczne, gdy stosujesz jednocześnie polecenia allow i deny).

Jeżeli polecenia allow i deny pojawiają się jednocześnie, jako pierwsze wykonuje się deny, a allow może definiować wyjątki, którym dostęp zostanie przyznany pomimo tego, iż znaj­dują się w grupie wcześniej wykluczonej. I tak, aby odciąć dostęp do pewnego katalogu wszystkim, z wyjątkiem użytkowników swojej sieci lokalnej, możesz napisać:

<LIMIT GET>

deny from all

allow from detah.lne.com

</LIMIT>

Aby odwrócić kolejność wykonywania poleceń allow i deny, należy użyć polecenia order, jak w poniższym przykładzie:

<LIMIT GET>

order allow,deny

deny from .netcom.com

allow from netcom17.netcom.com

</LIMIT>

Dobrze jest zawsze posługiwać się poleceniem order. W ten sposób nie musisz pamiętać, jaka kolejność jest przyjmowana standardowo, nie popełnisz więc z tego tytułu niepotrzeb­nych błędów. Zauważ, że kolejność ułożenia linii zawierających polecenia allow i deny nie ma żadnego znaczenia. Dopiero polecenie order wpływa na kolejność odczytywania ich przez serwer.

Standardowo serwer przyjmuje, że wszystkie komputery, które nie zostały wykluczone za pomocą polecenia deny mają dostęp do wszystkich katalogów. Jeżeli stanowi to problem, można rozwiązać go na dwa sposoby.

Użyj polecenia deny from all, a następnie allow dla komputerów, którym chcesz przyz­nać prawo dostępu do danych

Wprowadź polecenie order w następującej postaci:

<LIMIT GET>

order mutual-failure

allow from .lne.com

</LIMIT>

Oznacza to, że należy dopuścić wszystkie komputery, podane po allow, a zabronić dostępu wszystkim podanym po deny, i całej reszcie.

Ustawianie pliku haseł

Druga forma kontroli dostępu oparta jest na specjalnie utworzonych zbiorach użytkowni­ków. Aby udostępniać zastrzeżone pliki tylko określonym użytkownikom, należy utworzyć specjalny plik, w którym znajdą się ich nazwy wraz z hasłami. Plik ten nie ma nic wspólne­go z plikiem haseł systemu operacyjnego, choć obydwa wykorzystują tę samą metodę szyf­rowania i odszyf­rowywania.

Na jednym serwerze WWW można utworzyć dowolną liczbę plików haseł, w zależności od tego, jaki schemat kontroli dostępu pragniesz wykorzystać. W przypadku prostego serwera może być to tylko jeden plik, a dla większego, gdzie każda prezentacja wymaga innego rodzaju autoryzacji, może być ich kilka.

Pliki haseł można umieszczać w dowolnym miejscu. Ja osobiście zawsze tworzę centralny katalog admin, w którym znajdują się wszystkie pliki haseł, a ich nazwy odpowiadają wyko­rzystywanemu schematowi autoryzacji. Jednakże standardowo plik haseł nazywa się .htpasswd i powinien znajdować się w tym samym katalogu, w którym jest już .htaccess. W ten sposób łatwo jest wprowadzać zmiany w obydwu tych plikach i nie pogubić się w tym, który plik haseł przypisany jest którym katalogom.

Do rejestracji użytkowników w pliku haseł służy program htpasswd (źródło tego programu znajduje się w katalogu support). Posiada on dwa argumenty: pełną ścieżkę dostępu do pli­ku haseł oraz nazwę użytkownika. Jeżeli jest to pierwszy użytkownik wpisywany do dane­go pli­ku, należy dodać jeszcze opcję -c, która spowoduje utworzenie pliku:

htpasswd -c /home/www/protected/.htpasswd webmaster

Przytoczone polecenie spowoduje powstanie w katalogu /home/www/protected pliku haseł o nazwie .htpasswd, w którym jako pierwszy zostanie zarejestrowany użytkownik o nazwie webmaster. Program poprosi o wpisanie hasła dla tego użytkownika, po czym zaszyfruje je i również dopisze do pliku .htpasswd:

webmaster:kJQ9igMlauL7k

Za pomocą polecenia htpasswd można zarejestrować w pliku haseł dowolną liczbę użyt­kowników (pamiętaj jednak, że opcji -c należy użyć wyłącznie w momencie tworzenia nowego pliku haseł, podczas dodawania do niego kolejnych użytkowników opcji tej nie należy używać).

	Jeżeli spróbujesz dodać użytkownika do pliku haseł i okaże się, że taka nazwa została już wcześniej zarejestrowana, program htpasswd założy automatycznie, że jest to polecenie zmiany hasła tego użytkownika. Jeżeli zaś zechcesz usunąć jakiegoś użytkownika, usuń odpowiednią linię z pliku haseł.

Kontrola dostępu na poziomie użytkownika

Jeżeli przygotowałeś już plik haseł, przejdź do edycji pliku kontroli dostępu (.htaccess dla katalogu lub access.conf dla całego serwera). Będziesz tu musiał dodać kilka dyrektyw odnoszących się do autoryzacji oraz specjalne polecenie. Zmodyfikowany plik kontroli dos­tępu może wyglądać następująco:

AuthType Basic

AuthName Webmaster Only

AuthUserFile /home/www/webmaster/.htpasswd

<LIMIT GET>

require user webmaster

</LIMIT>

Podany przykład ogranicza prawo dostępu do katalogu /home/www/webmaster/ tak, że dos­tęp do niego może uzyskać tylko użytkownik webmaster.

Dyrektywa AuthType mówi, że do pobrania od przeglądarki nazwy użytkownika i hasła zo­stanie wykorzystana autoryzacja prosta. Tak naprawdę to nie ma tu wielkiego wyboru, jest to bowiem jedyna metoda autoryzacji zaimplementowana w większości serwerów WWW. W związku z tym nie ma potrzeby umieszczania linii w pliku kontroli dostępu, ale dobrze jest wyrobić sobie taki nawyk, bowiem nowe mechanizmy na pewno wkrótce się pojawią.

Dyrektywa AuthName jest wykorzystywana przez przeglądarkę w oknie dialogowym, służą­cym do wpisania nazwy użytkownika i hasła. W ten sposób można określić, jakiej części danych, znajdujących się na serwerze, dotyczy przeprowadzana autoryzacja. Jeżeli na jednym serwerze obsługiwanych jest kilka schematów kontroli dostępu, musi istnieć jakiś sposób rozróżnienia ich z punktu widzenia użytkownika przeglądarki. AuthName pozwala na określenie, do jakiego serwisu można uzyskać dostęp, przeszedłszy pomyślnie procedurę autoryzacji. Jeżeli dyrekty­wa ta nie zostanie zamieszczona w pliku kontroli dostępu, w ok­nie dialogowym pojawi się słowo unknown (nieznany), co może nieco zdezoriento­wać użytkownika.

Z kolei dyrektywa AuthUserFile podpowiada serwerowi, którego pliku haseł należy użyć po uzyskaniu nazwy i hasła od przeglądarki. Ścieżka dostępu musi być pełną ścieżką w drzewie plików systemu operacyjnego.

Na koniec przechodzimy do sekcji <LIMIT>. W tym miejscu można dokładnie określić, którzy użytkownicy mają dostęp do zastrzeżonych katalogów, służy do tego polecenie require user. Za jego pomocą można określić jedną lub kilka nazw, oddzielonych prze­cinkiem:

require user jill,bob,fred,susan

Oprócz tego, można udostępnić katalog wszystkim użytkownikom, wpisanym do pliku haseł. Aby to zrobić, zamiast słowa user należy wpisać wyrażenie valid-user:

require valid-user

Wyrażenie to można potraktować jako swego rodzaju skrót, równie dobrze zamiast niego można by wypisać wszystkie nazwy użytkowników, zarejestrowanych w pliku haseł.

Aby poszerzyć możliwości kontroli dostępu poszczególnych użytkowników, możesz stoso­wać kolejne polecenia require, jak również deny i allow. W ten sposób skontro­lujesz dostęp nie tylko konkretnych użytkowników, ale również użytkowników określonych kompute­rów. Poniższy przykład pozwala na dostęp do danych użytkownikowi o nazwie maria, pracu­jącemu na komputerze znajdującym się w domenie home.com.

<LIMIT GET>

require user maria

deny from all

allow from .home.com

</LIMIT>

Kontrola dostępu na poziomie nazwy komputera ma zawsze pierwszeństwo przed autory­zacją użytkownika. Żadna Maria nie uzyska dostępu do plików, jeżeli będzie próbowała się do nich dostać z niewłaściwego systemu. Serwer prześle jej komunikat o braku dostępu, zanim będzie miała okazję podać nazwę i hasło.

Ustawienia pliku grupy

Wykorzystanie grup jest prostym sposobem tworzenia zbiorczej nazwy dla pewnej liczby użytkowników, która następnie może być wykorzystywana w poleceniu require, zamiast listy nazw wszystkich jej członków. Grupy mogą nosić nazwy, takie jak Inzynierowie, Pisarze, Administratorzy. Kiedy już zdecydujesz się na wykorzystanie tego mechanizmu, dostęp będzie przyznawany tylko tym autoryzowanym użytkownikom, którzy będą jedno­cześnie człon­kami odpowiedniej grupy.

Aby utworzyć grupę, należy w specjalnym pliku zdefiniować jej nazwę oraz listę członków. Plik ten może znaleźć się w dowolnym miejscu systemu plików (zwykle nazywa się on .htgroup i umieszczany jest w katalogu, do którego się odnosi), a wygląda mniej więcej tak:

mygroup: me, tom, fred, jill

anothergroup: webmaster, mygroup

	Podobnie jak w przypadku plików haseł, pliki grup również nie mają nic wspólnego z systemem UNIX, choć składnia zapisów jest podobna.

Każda linia stanowi definicję grupy i składa się z nazwy, po której następuje lista użytkow­ników, będących jej członkami.

Na liście członków grupy mogą się oczywiście znajdować nazwy użytkowników (zdefinio­wane uprzednio w pliku haseł), ale można tam również wpisać nazwę innej grupy, zdefinio­wanej w tym samym pliku, lecz znajdującej się powyżej bieżącej linii.

Ograniczanie dostępu dla grupy

Gdy plik grupy jest już gotowy, można wykorzystać go do ograniczenia prawa dostępu członkom poszczególnych grup. Odbywa się to w taki sam sposób, jak w przypadku ogra­nicza­nia dostępu pojedynczym użytkownikom, a więc w pliku kontroli dostępu. Nowym elementem jest dyrektywa AuthGroupFile, która określa ścieżkę dostępu do używanego pliku grupy.

AuthType Basic

AuthName Web Online!

AuthUserFile /home/www/web-online/.htpasswd

AuthGroupFile /home/www/web-online/.htgroup

<LIMIT GET>

require group hosts,general

</LIMIT>

Aby umożliwić dostęp do katalogu tylko członkom pewnej grupy, należy posłużyć się po­lece­niem require group, po którym należy podać nazwę jednej lub wielu grup (oddzielone przecinkiem). Jeżeli jednocześnie wykorzystasz polecenia require user i require group, prawo dostępu zostanie przyznane wszystkim użytkownikom, objętym zdefiniowanym za­kresem (czyli pojedynczym użytkownikom, wymienionym po require user oraz członkom grup, wymienionych po require group).

Podobnie jak przy require user, tak i tu można posunąć się dalej i jednocześnie wprowa­dzić ograniczenia ze względu na nazwę komputera, umieszczając odpowiednie polecenia allow i deny. Poniższy przykład zezwala na dostęp do katalogu tylko członkom grupy managers, pracującym w domenie work.com:

<LIMIT GET>

require group managers

deny from all

allow from .work.com

</LIMIT>

Opcje NCSA

Mechanizm kontroli dostępu serwera NCSA nie ogranicza się tylko do zezwalania użytkow­nikom na dostęp do określonych plików. Oprócz tego pozwala on na kontrolę tego, które mechanizmy będą aktywne w poszczególnych katalogach, mam tu na myśli SSI, wyświet­lanie zawartości katalogów oraz skrypty CGI.

W każdym pliku konfiguracyjnym, w tym w każdej sekcji <DIRECTORIES> pliku access.conf oraz w plikach .htaccess, istnieje możliwość umieszczenia polecenia options, które określa, jakie mechanizmy mogą być w danym katalogu wykorzystywane. Standardowo, jeżeli polece­nie options nie pojawia się wcale, dostępne są wszystkie mechanizmy zdefiniowane w kata­logu nadrzędnym (lub w pliku access.conf). Oto przykładowa linia polecenia options:

Options Indexes IncludesNoExec

Pojedyncza linia może zawierać wszystkie możliwe opcje. Jeżeli options znajdzie się już w pliku konfiguracyjnym, dozwolone będą tylko te mechanizmy, które zostaną w tym miej­scu wymienione. Podobnie jednak, jak w przypadku kontroli dostępu, tak i tu odpowiedni zapis w pliku .access.conf lub plik .htaccess umieszczony w podkatalogu, wprowadza własne ustawienia jako obowiązujące w tym miejscu, unieważniając jednocześnie wszystko, co zostało włączone lub wyłączone na wyższym poziomie. Jako administrator masz możli­wość przejęcia kontroli nad unieważnianiem bardziej ogólnych ustawień, służy do tego dyrektywa AllowOverride, którą możesz umieścić w pliku access.conf (i tylko w nim). Pozwala ona na określenie, które ustawienia mogą być unieważniane przez zapisy w plikach .htaccess. Więcej informacji na temat tej dyrektywy znajdziesz w następnym punkcie „Unieważnianie ustawień opcji i kontroli dostępu”.

Tabela 30.1 przedstawia wszystkie możliwe wartości polecenia options.

Tabela 30.1: Możliwe wartości polecenia options

Opcja		Znaczenie
None		Żaden mechanizm nie jest aktywny w danym katalogu.
All		Wszystkie mechanizmy są aktywne w danym katalogu.
FollowSymLinks		Jeżeli w katalogu znajdują się połączenia symboliczne, przeglądarki mogą odczytywać umieszczone w ten sposób pliki. Jeżeli połączenia symboliczne prowadzą do prywatnych katalogów użytkowników syste­mu operacyjnego, włączenie tej opcji może stanowić poważne zagrożenie bezpieczeństwa.
SymLinksIfOwnerMatch		Przeglądarki mogą odczytywać pliki, będące połączeniami symbolicz­nymi tylko wtedy, gdy właściciel połączenia jest jednocześnie właści­cielem pliku. Opcja ta jest nieco bardziej bezpieczna, ogranicza bo­wiem obszar dostępny za pomocą połączeń symbolicznych do drzewa katalogów konkretnego użytkownika.
ExecCgi		Opcja ta umożliwia wykonywanie skryptów CGI w danym katalogu. Oprócz tego, aby mechanizm zadziałał, w pliku srm.cnf (lub .htaccess) musi znaleźć się dyrektywa AddType. Udostępniaj tę opcję tylko zaufanym użytkownikom.
Includes		Opcja ta włącza mechanizm SSI w danym katalogu. Oprócz niej w pliku srm.conf lub .htaccess musi znaleźć się dyrektywa AddType, pozwalająca na przetwarzanie plików HTML przez serwer WWW (patrz rozdział 29. „Porady i wskazówki na temat serwera WWW”).
IncludesNoExec		Opcja ta umożliwia wykonywanie tylko tych poleceń SSI, które nie są związane z uruchamianiem skryptów CGI (czyli wszystkich oprócz #exec). Jest to opcja zdecydowanie bezpieczniej­sza od opisanej powyżej, wyłącza bowiem z użycia najbardziej niepewny punkt SSI, nie blokując jednocześnie dostępu do prostszych i mniej groźnych poleceń.
Indexes		Opcja ta umożliwia przeglądarkom wyświetlanie zawartości danego katalogu.
		Wiele z wymienionych powyżej opcji NCSA stanowi poważne zagrożenie bezpieczeństwa całego systemu operacyjnego serwera. W zależności od wagi, jaką przykładasz do kwestii odporności systemu na ataki intruzów z zewnątrz, mo­żesz zechcieć wyłączyć większość lub nawet wszystkie te opcje w globalnym pliku access.conf. Pamiętaj przy tym, że standardowo wszystkie one są dostęp­ne. Jeżeli więc nie utworzyłeś do tej pory pliku access.conf lub też nie zawie­ra on linii options, każdy użytkownik serwera ma dostęp do wszystkich potencjalnie groźnych mechanizmów.

Unieważnianie ustawień opcji
i kontroli dostępu

Serwer NSCA pozwala na określenie, które z opcji ustawionych dla całego serwera (w pliku access.conf) lub pewnego drzewa katalogów mogą zostać unieważnione w podkatalogu poprzez umieszczenie w nim odpowiednio skonfigurowanego pliku .htaccess. Standardo­wo możliwe jest unieważnianie wszystkich ustawień, co oznacza, że każdy użytkownik ser­wera może utworzyć swój plik .htaccess i za jego pomocą całkowicie przejąć kontrolę nad swo­imi katalogami. Przy pomocy dyrektywy AllowOverrides możesz pozbawić wszystkich użyt­kowników możliwości unieważniania Twoich ustawień. Wygląda to mniej więcej tak:

AllowOverrides Options AuthConfig

Dyrektywę tę można umieścić w pliku access.conf tylko raz i oczywiście nie może się ona znaleźć w żadnym pliku .htaccess.

Z punktu widzenia bezpieczeństwa najlepszym rozwiązaniem jest wprowadzenie globalnych ustawień wszelkich opcji i kontroli dostępu w pliku access.conf oraz całkowite wyłączenie możliwości ich unieważniania (AllowOverrides None). W ten sposób użytkownicy nie będą mogli nic zmienić za pomocą swoich plików .htaccess. Być może zechcesz jednak dać im trochę swobody i oddać w ich ręce przynajmniej część kontroli nad własnymi plikami.

W tabeli 30.2 przedstawiam możliwe wartości dyrektywy AllowOverrides.

Tabela 30.2: Wartości dyrektywy AllowOverrides

Opcja	Znaczenie
None	Żadne ustawienia nie mogą zostać unieważnione w plikach .htaccess.
All	Umożliwia unieważnianie wszystkich ustawień.
Options	Umożliwia unieważnianie w plikach .htaccess ustawień polecenia Options.
FileInfo	W plikach .htaccess mogą znaleźć się dyrektywy AddType i AddEncoding, służące do definiowania dodatkowych kontekstów.
AuthConfig	Umożliwia unieważnianie w plikach .htaccess wartości dyrektyw AuthName, AuthType, AuthUserFile i AuthGroupFile, które służą do ustawiania parametrów autoryzacji dostępu.
Limit	W plikach .htaccess można umieścić sekcję <LIMIT>.

Kontrola dostępu w serwerze Microsoft Internet Information Server

Podejście do zagadnień kontroli dostępu wykorzystywane w serwerze Microsoft Internet Information Server całkowicie odróżnia się od metod używanych przez niemal wszystkie pozostałe serwery WWW. Zamiast przechowywania niezależnych informacji dotyczących praw dostępu użytkowników i grup oraz praw dostępu do plików i folderów, w serwerze firmy Microsoft informacje te zostały zintegrowane z systemem autoryzacji i kontroli dostępu systemu Windows NT. Każdy użytkownik dysponujący kontem na serwerze WWW i dysponujący prawem do odczytu żądanego pliku, będzie mógł obejrzeć jego zawartość za pośrednictwem WWW (zakładając, że plik znajduje się w folderze dostępnym dla serwera WWW).

Nie istnieją żadne konta użytkowników ani specjalne prawa dostępu do plików, definiowane i używane wyłącznie przez serwer WWW. Użytkownicy nawiązujący połączenie z serwerem za pośrednictwem WWW, są do niego podłączani jako użytkownicy zdefiniowani w konfiguracji IIS. Jeśli użytkownik dysponuje prawem odczytu żądanego pliku, nie jest wymagana żadna autoryzacja. Jeśli jednak użytkownik IIS nie posiada uprawnień koniecznych do odczytania pliku, trzeba wykonać jego autoryzację. W takim przypadku, aby wyświetlić plik, użytkownik będzie musiał podać nazwę konta dysponującego prawem odczytu danego pliku oraz odpowiednie hasło.

A zatem, aby zabezpieczyć dostęp do wybranej części serwera WWW, w pierwszej kolejności powinieneś określić prawa dostępu do folderu, tak aby anonimowi użytkownicy WWW korzystający z serwera nie mieli dostępu do zawartości folderu. Kolejnym krokiem będzie stworzenie konta użytkownika systemu Windows NT i ustawienie praw dostępu do tego folderu w taki sposób, aby nowy użytkownik mógł odczytywać jego zawartość. Zapewne będziesz także chciał zdefiniować konto użytkownika w taki sposób, aby nie mógł się on zalogować za pośrednictwem konsoli Windows NT, gdyż jest ona używana do kontroli dostępu z poziomu WWW.

Jak widzisz wykorzystana metoda autoryzacji i kontroli dostępu całkowicie różni się od tej, stosowanej w serwerze NCSA oraz serwerach wzorowanych na nim. Przyjęte rozwiązanie nie przysporzy najmniejszych problemów osobom przyzwyczajonym do zarządzania systemem Windows NT, choć może być nieco trudniejsze dla osób przyzwyczajonych do zarządzania innymi serwerami WWW.

Bezpieczne połączenia i SSL

Internet jest siecią niezbyt bezpieczną, szczególnie, jeżeli jest wykorzystywany do przesy­łania poufnych informacji, które nie powinny wpaść w ręce nikogo niepowołanego. Proste metody autoryzacji dostępu, które zapewniają serwery WWW nie są w żadnym wypadku wystarczają­ce, aby zmienić ten stan rzeczy.

Aby zapewnić rzeczywiste bezpieczeństwo danych, należy wykorzystać techniki szyfrowa­nia oraz autoryzacji informacji przesyłanych pomiędzy serwerem a przeglądarką, tak aby nie mogły one zostać przechwycone lub, co gorsza, zmienione przez jakiegoś intruza. Najpo­pu­larniejszym mechanizmem, który zapewnia tego typu ochronę jest niewątpliwie SSL, au­tor­stwa formy Netscape.

SSL (skrót od ang. Secure Socket Layer — bezpieczna warstwa gniazda) szyfruje połączenia sieciowe pomiędzy przeglądarką a serwerem WWW. Ponieważ właściwe szyfrowanie odby­wa się w warstwie sieciowej, technika ta może być wykorzystywana nie tylko do tworzenia bezpiecznych połączeń WWW, ale również innych usług sieciowych (np. Telnet lub Gopher).

W tym punkcie zamierzam szczegółowo zająć się techniką SSL. Opiszę wykorzystywane w niej zasady szyfrowania danych, komunikację pomiędzy serwerami i przeglądarką oraz usta­wienia, które należy wykonać po stronie serwera.

Jak działa SSL

SSL skonstruowany jest w oparciu o podstawowe zasady kryptografii: szyfrowanie za po­mocą klucza publicznego oraz cyfrowy certyfikat, który stanowi coś w rodzaju przywitania i pozwala stwierdzić, czy serwer jest rzeczywiście tym komputerem, za który się podaje. Na koniec wyko­rzystywane są jeszcze specjalne klucze dla poszczególnych sesji, które służą do właściwego szyfrowania danych przesyłanych po łączach internetowych.

	Wszystkie informacje, które znajdziesz w tym rozdziale, podawane są w dużym uproszczeniu. Kryptografia to bardzo ciekawa, ale i bardzo skomplikowana dziedzina matematyki i trudno streścić jej zasady na kilku stronach książki, takiej ja ta, którą trzymasz w ręku. Jeżeli chciałbyś jednak nieco bardziej zagłębić się w świat szyfrowania danych, powinieneś bez trudu znaleźć co najmniej kilka pozycji poświęconych temu tematowi.

Szyfrowanie kluczem publicznym

Szyfrowanie kluczem publicznym to mechanizm, zapewniający poprawność danych oraz umożliwiający stwierdzenie, skąd dane pochodzą. Idea polega na tym, że każda strona zaan­gażowana w transakcję przesyłania danych posiada dwa klucze: publiczny i prywatny. Infor­macja zaszyfrowana za pomocą klucza publicznego może zostać odszyfrowana tylko kluczem prywatnym i odwrotnie, klucz publiczny umożliwia odczytanie danych zaszyfro­wanych klu­czem prywatnym.

Klucz publiczny, jak wskazuje jego nazwa, jest powszechnie dostępny, ale klucz prywatny utrzymywany jest w ścisłej tajemnicy, lokalnie, przez każdą ze stron. Mając do dyspozycji dwa klucze, strona może zastosować szyfrowanie klucza publicznego na jeden z dwóch spo­sobów.

• Jeżeli do zaszyfrowania danych użyty zostanie klucz prywatny, każdy posiadacz klucza publicznego będzie mógł je odczytać. W ten sposób można z całą pewnością stwierdzić, że dane pochodzą od określonej osoby, ponieważ nikt inny nie dysponuje takim kluczem pry­watnym i nie mógłby ich wygenerować.

• Jeżeli dane są przeznaczone tylko dla drugiej stro­ny, można zaszyfrować je kluczem publicznym tej osoby. Wtedy będzie można je odczytać tylko za pomocą jej klucza prywatnego, co oznacza, że dane będzie mógł odszyfrować tylko i wyłącznie adresat wiadomości.

Certyfikaty cyfrowe

Podstawowy problem dotyczący techniki klucza publicznego w sieci Internet polega na tym, że trudno jest stwierdzić, czy klucz publiczny przesyłany wraz z wiadomością jest rzeczy­wiście kluczem publicznym osoby wysyłającej dane. Jeżeli firma X przesyła Ci swój klucz publiczny, nie możesz mieć pewności, że ktoś się pod nich nie podszywa i nie podsta­wia w to miejsce własnego klucza.

W tym momencie na scenę wkraczają cyfrowe certyfikaty. To nic innego, jak klucz pub­liczny jakiejś firmy czy też osoby, zaszyfrowany za pomocą klucza prywatnego centralnej orga­nizacji, zajmującej się wydawaniem owych certyfikatów. CA (skrót od ang. certificate authority) jest centralną, godną zaufania instytucją, powołaną specjalnie do tworze­nia i roz­prowadzania cyfrowych certyfikatów. Jeżeli otrzymasz od nich swój własny certyfi­kat, każ­dy będzie mógł stwierdzić z całą pewnością, że należy on właśnie do Ciebie, spraw­dzając poprawność podpisu CA.

Ale jak sprawdzić, czy podpis CA jest prawidłowy? Istnieje grupa organizacji CA, o których wiadomo w stu procentach, że są pewne (z reguły udostępniają one swoje klucze publiczne w sposób, który czyni je godnymi zaufania). Jeżeli więc otrzymasz od kogoś certyfikat podpi­sany przez CA, której ufasz, możesz odczytać klucz publiczny tej osoby za pomocą klucza publicznego owej CA.

Struktura wystawiania podpisów jest hierarchiczna: centralna CA może upoważniać podleg­łe sobie organizacje do wydawania kolejnych certyfikatów, te z kolei mogą upoważniać kolejne itd. Tak więc każdy pojedynczy certyfikat posiada całą serię podpisów. Można się za ich pomocą wycofać aż do poziomu CA, znajdującej się na samym szczycie, a która jest Ci znana. Tak przynajmniej głosi teoria. W praktyce większość certyfikatów, wykorzysty­wanych przez SSL wystawia firma o nazwie Verisign, która jest zdecydowane najpopular­niejszym usługo­dawcą w tej dziedzinie.

Klucze sesji

Technika klucza publicznego jest bardzo bezpieczna, jednak bardzo wolna, jeżeli przesyłane informacje szyfrowane są właśnie za pomocą klucza publicz­nego. Dlatego też większość systemów wykorzystujących tę metodę korzysta z klucza pub­licznego tylko do początkowej weryfikacji pochodzenia danych, natomiast do właściwego szyfrowania służy tzw. klucz sesji.

Jest to stosunkowo duża liczba, z reguły 40- lub nawet 128-bitowa (co daje 2⁴⁰ lub 2¹²⁸ mo­żliwych kombinacji). Zależy to od tego, czy wykorzystujesz oprogramowanie w wersji mię­dzynarodowej czy amerykańskiej.

Dlaczego właściwie funkcjonują dwie wielkości klucza? Odpowiedzi należy szukać w świe­cie polityki, a nie kryptografii. Prawo eksportowe Stanów Zjednoczonych zabrania firmom rozpowszechniania poza granicami kraju oprogramowania szyfrującego, wykorzystującego klucze większe niż 40 bitów. Dlatego też firmy, takie jak Netscape tworzą dwie wersje pro­gramów — międzynarodową, z kluczem 40-bitowym oraz amerykańską, gdzie takie ograni­czenie już nie obowiązuje i klucz może swobodnie składać się ze 128 bitów. W zależności od tego, skąd pochodzi Twoje oprogramowanie, taki klucz został w nim wykorzystany. Wszystko, co zostanie skopiowane z Internetu, okaże się wersją międzynarodową, a więc 40-bitową. Aby zdobyć wersję 128-bitową trzeba będzie najprawdopodobniej pojechać do USA i nabyć program osobiście.

No dobrze, ale dlaczego prawo eksportowe reguluje kwestię wielkości klucza w oprogramo­waniu eksportowanym poza granice USA? Rząd tego kraju pragnie zachować sobie możli­wość łamania kodów, używanych przez wszelkiego rodzaju organizacje terrorystyczne, dlatego też rozpowszechniane przez firmy amerykańskie programy nie mogą generować zbyt bezpiecz­nych kluczy. Z punktu widzenia kryptografii trudno sobie wyobrazić kod bezpieczniejszy od 128-bitowego, Przy założeniu, że najszybszy obecnie superkomputer potrafiłby analizować milion kluczy na sekundę, potrzebowałby on 10²⁵ lat, aby znaleźć właściwą kombinację (dla porównania przypominam, że nasz wszechświat istnieje od 10¹⁰ lat). W przypadku 40 bitów poszukiwania musiałyby zakończyć się sukcesem najpóźniej po trzynastu dniach, co oznacza, że taki klucz jest teoretycznie możliwy do odczytania.

Niepożądanym efektem tych działań jest fakt, że klucz 40-bitowy może zostać względnie łatwo rozszyfrowany przez organizacje pozarządowe. Kryptografowie są zgodni, że opro­gramowa­nie operujące na takich kluczach jest niedoskonałe i przede wszystkim nie zapew­nia właści­wego poziomu bezpieczeństwa. Ale w zastosowaniach internetowych powinno to w zupeł­ności wystarczyć, nawet w przypadku transakcji z użyciem numerów kart kredyto­wych.

Jak powstają połączenia SSL

Jeżeli pojąłeś już, jakie znacznie mają klucze publiczne, prywatne, klucze sesji oraz certyfi­katy cyfrowe, możesz spokojnie przejść dalej, do części związanej z nawiązywaniem połą­czenia SSL (przeznaczonej tylko dla tych, którzy jeszcze nie przysnęli).

Aby bezpieczne połączenie mogło zostać nawiązane, zarówno serwer, jak i przeglądarka mu­szą obsługiwać standard SSL. Połączenie takie wykorzystuje specjalny sposób zapisu ad­resów URL (zamiast http na początku pojawia się https), a przeglądarka łączy się z serwe­rem, wykorzystując inny port, a nie standardowy protokół HTTPD. Oto co dzieje się, gdy przeglądar­ka zażąda od serwera nawiązania bezpiecznego połączenia.

1. Przeglądarka łączy się z serwerem za pomocą protokołu HTTPS. Serwer przesyła jej swój cyfrowy certyfikat.

2. Przeglądarka sprawdza prawidłowość certyfikatu za pomocą klucza zaufanego CA. Jeżeli podpis okaże się nieprawidłowy lub coś innego nie będzie w porządku, może ona całkowicie zrezygnować z połączenia bądź też poinformować użytkownika, że wystąpiły problemy i zapytać go, czy pomimo tego pragnie kontynuować pracę z tym serwerem (tylko kilka przeglądarek, w tym Netscape, podejmie takie działanie).

3. Przeglądarka generuje klucz główny w oparciu o liczbę losową, szyfruje go za pomocą klucza publicznego serwera i przesyła mu tak przygotowane dane.

4. Serwer odczytuje klucz główny przeglądarki za pomocą swojego klucza prywatnego. Klucz główny znany jest w tej chwili obu stronom transakcji.

5. Serwer i przeglądarka generują klucze sesji na podstawie klucza głównego i wymienio­nych wcześniej losowych liczb. Powstałe w ten sposób klucze są identyczne.

6. Od tej chwili wszystkie dane, które wymieniają między sobą serwer i przeglądarka, szyf­rowane są za pomocą klucza sesji. Dopóki klucz ten nie zostanie rozszyfrowany przez kogoś z zewnątrz, połączenie pozostaje całkowicie bezpieczne.

Ustawienia SSL na serwerze

Aby móc korzystać z bezpiecznych transakcji SSL, musisz bezwzględnie zaopatrzyć się w serwer, który obsługuje ten mechanizm. Wiele komercyjnych serwerów dostępnych na rynku amerykańskim potrafi obsłużyć połączenia SSL.W grupie tej znajdują się wszystkie serwery Netscape'a (z wyjątkiem Communications Server) oraz programy, takie jak O'Reilly's WebSite czy WebStar firmy StarNine. (W dwóch ostatnich przypadkach SSL jest oferowany jako dodatkowa opcja do wersji podstawowej.) Oprócz tego serwer Apache z grupy Public Domain obsługuje swoją własną wersję — ApacheSSL — obsługującą SSL (choć do jego uruchomienia potrzebny jest pakiet kryptograficzny RSARef, który nie należy już do Public Domain ani też nie jest darmowy dla większości użytkowników).

	Wszelkie podawane przeze mnie dane dotyczą tylko i wyłącznie serwerów sprzedawanych w Stanach Zjednoczonych. W związku z ograniczeniami eksportowymi, firmy nie mogą sprzedawać za granicę produktów związanych z kryptografią, chyba że możliwości w tym zakresie zostaną ograniczone (wspomniane wcześniej 40 bitów na klucz).

Każdy serwer SSL powinien posiadać wbudowany mechanizm generowania kluczy i rejes­trowania ich w organizacji typu CA (z reguły jest to Verisign, pod adresem http:// www.verisign.com/ znajdziesz szczegółowe informacje na temat cyfrowych podpisów). Kie­dy tylko certyfikat zostanie podpisany przez CA i zainstalowany, przeglądarki będą mogły nawiązywać bezpieczne połączenia z tym serwerem.

Niektóre serwery udostępniają mechanizm samodzielnego podpisywania certyfikatów, co oznacza tworzenie bezpiecznych połączeń bez udziału podpisu CA. Takie połączenie bę­dzie jednakże zdecydowanie mniej pewne i jak dotąd jedyną przeglądarką, akceptującą sa­modzielnie podpisywane certyfikaty jest Netscape (robi to jednak dopiero po wyświetleniu serii komunikatów ostrzegających użytkownika). Microsoft Internet Explorer 4 odmawia nawiązywania połączeń z serwerami, które przesyłają tego typu certyfikaty. Aby zapewnić naprawdę bezpieczne połączenia w komercyjnych zastosowaniach Internetu i WWW, nale­ży trzymać się idei wykorzystania certyfikatów, podpisywanych przez godne zaufania firmy i organizacje typu CA.

Więcej informacji o SSL

Najlepszym punktem wyjściowym do rozpoczęcia poszukiwań szerszych informacji na temat SSL i bezpieczeństwa w Internecie są strony Netscape'a, jest to w końcu twórca tego standardu. Strona http://www.netscape.com/info/security-doc.html jest prawdziwą kopalnią wiedzy na temat SSL (szczegółowa specyfikacja techniczna), jak również szeroko pojętego bezpieczeństwa sieci komputerowych.

Verisign jest czołową firmą w USA, zajmującą się podpisywaniem certyfikatów. Aby ot­rzy­mać podpis swojego certyfikatu, należy z reguły osobiście pofatygować się do ich siedziby. Szczegóły znajdziesz na stronie http://www.verisign.com/.

Więcej informacji na temat bezpieczeństwa w sieciach komputerowych znajdziesz także na stronach W3 Consortium (http://www.w3.org/Security/Overview.html)

Podsumowanie

Bezpieczeństwo danych w sieci Internet staje się coraz ważniejszym problemem, a Ty, jako administrator serwera WWW, powinieneś również poświęcić temu zagadnieniu odrobinę uwagi. Szkody, które mogą zostać wyrządzone za pośrednictwem „nieszczelnego” serwera WWW są wprawdzie niewielkie w porównaniu z zagrożeniami, jakie niosą ze sobą inne usługi internetowe, ale dobrze jest przedsięwziąć pewne środki ostrożności, które zabezpie­czą system przed potencjalnymi atakami z zewnątrz i z wewnątrz lokalnej sieci komputero­wej.

W tym rozdziale zapoznałeś się z niektórym środkami, za­pewniającymi Tobie i użytkowni­kom serwera bezpieczny sen. Dowiedziałeś się jak:

• w sposób ogólny zwiększyć bezpieczeństwo serwera,

• pisać skrypty CGI, które nie zawierają łatwych do wykrycia luk w bezpieczeństwie systemu,

• ustanawiać autoryzowaną kontrolę dostępu do określonych plików i katalogów,

• za pomocą opcji NSCA kontrolować wykorzystanie różnych możliwości serwera na poziomie katalogów.

Warsztat

Ta część rozdziału zawiera pytania i odpowiedzi, quiz oraz ćwiczenia dotyczące bezpieczeństwa serwerów WWW.

Pytania i odpowiedzi

P. Umieściłem plik .htaccess w moim katalogu, ale mam wrażenie, że nie dało to żad­nego efektu. Dlaczego?

O. Najprawdopodobniej administrator serwera ustawił standardową konfigurację i wyłączył możliwość unieważniania jego ustawień. Dowiedz się od niego (niej), czy możesz w ogó­le wykorzystywać plik .htaccess, a jeżeli tak, to do jakich celów.

P. Próbowałem ograniczyć dostęp do mojego katalogu za pomocą sekcji <LIMIT> w połączeniu z poleceniem deny, ale teraz, za każdym razem, kiedy próbuję od­czytać pliki za pomocą przeglądarki, serwer zwraca komunikat 500 Server Error. Co zrobiłem nie tak?

O. Sprawdź, czy pierwsza części sekcji <LIMIT> ma postać <LIMIT GET>. Brak słowa GET skutkuje takim właśnie komunikatem błędu.

Pamiętaj, że większość błędów w ustawieniach kontroli dostępu jest zapisywanych w lo­gach błędów serwera. W ten sposób dość łatwo można wykryć przyczyny wszelkich zaburzeń jego pracy.

P. Jakiś czas temu widziałem wielki nagłówek w jakiejś gazecie, mówiący o tym, jak to pewien Francuz w ciągu 8 dni rozpracował zabezpieczenia Netscape'a. Co na­prawdę się wydarzyło?

O. Jeżeli uważnie przeczytałeś część rozdziału poświęconą SSL, pamiętasz zapewne infor­mację, że komputer sprawdzający milion 40-bitowych kombinacji na sekundę potrzebo­wałby do 13 dni na stuprocentowe jej rozszyfrowanie. Złamany kod został wygenerowa­ny przez międzynarodową wersję Netscape'a, która podlega ograniczeniom eksporto­wym. Wspomniany Francuz miał dostęp do kilkuset komputerów, które nie zaj­mowały się ni­czym innym, jak tylko próbą rozszyfrowania pojedynczego klucza sesji, co zajęło im 8 dni. Ale przecież nie każdy hacker, próbujący przechwycić numer czyjejś karty kredytowej będzie miał dostęp do takiej liczby komputerów i to w dodatku przez 8 dni. Można więc uznać, że klucz 40-bitowy jest bezpieczny. Jeżeli jednak Cię to nie przeko­nuje i dalej uważasz, że 40 bitów to za mało, zakup oprogramowanie w wersji 128-bito­wej. Wtedy nawet nasz Francuz nie poradzi sobie tak łatwo.

P. Słyszałem o jeszcze jednym skandalu, związanym z zabezpieczeniami Netscape'a i liczbami losowymi. O co chodziło w tym przypadku?

O. To była prawdziwa wpadka. Jeżeli czytałeś sekcję, w której znalazł się opis sposobu ge­nerowania przez przeglądarkę klucza głównego, musisz pamiętać, że jednym z wyko­rzystywanych w tym procesie elementów była liczba losowa. Klucz główny służy nas­tępnie do wygenerowania 40- lub 128-bitowego klucza sesji.

Problem polegał na tym, że wykorzystywany przez Netscape'a generator liczb losowych nie był tak naprawdę losowy i bardzo łatwo było odgadnąć, jaka liczba została użyta do utworzenia klucza głównego. Znając go, można było bez problemu wygenerować klucz sesji identyczny z tymi, które serwer i przeglądarka wykorzystywały do szyfrowania przesy­łanych danych.

Na szczęście firma Netscape błyskawicznie poprawiła swoje oprogramowanie i alarm zos­tał odwołany.

Quiz

1. Jakie są dwie największe luki systemów zabezpieczeń serwerów WWW?

2. Co się dzieje, gdy użytkownik zażąda adresu URL odpowiadającego katalogowi, w którym nie ma pliku o nazwie index.html? W jaki sposób można rozwiązać ten potencjalny błąd w systemie zabezpieczeń?

3. Jak można zabronić dostępu do witryny programom automatycznie przeszukującym zasoby WWW (tak zwanym robotom)?

4. Co oznaczają pojęcia kontrola dostępu oraz autoryzacja?

5. Jaka jest najpopularniejsza technologia tworzenia bezpiecznych połączeń na WWW? Na czym polega jej działanie?

Odpowiedzi

1. Dwie największe luki w systemie zabezpieczeń to skrypty CGI oraz mechanizm SSI, umożliwiające tworzenie i obsługę formularzy oraz automatyczne generowanie stron WWW w momencie zgłoszenia żądania.

2. Gdy użytkownik prześle żądanie odpowiadające katalogowi, to do adresu URL dodawana jest domyślna nazwa pliku (zazwyczaj jest to index.html). Jeśli w katalogu nie będzie pliku index.html, to serwer prześle do przeglądarki listing całej zawartości danego katalogu (niemal taki sam jak listingi katalogów generowane przez serwery FTP). Problem ten można rozwiązać na dwa sposoby: umieszczając pliki index.html w każdym katalogu serwera lub całkowicie wyłączając możliwość generowania listingów zawartości katalogów.

3. Aby uniemożliwić dostęp do serwera robotom, należy stworzyć plik o nazwie robots.txt i umieścić go na głównym poziomie witryny WWW, tak aby jego adres URL miał postać http://twoja_witryna.com/robots.txt. W tym pliku możesz zablokować dostęp do całej witryny lub wyłącznie do jej wybranych części.

4. Kontrola dostępu oznacza, że dostęp do plików i podkartotek w głównej kartotece serwera WWW został nieco ograniczony. Autoryzacja zmusza użytkowników, przekazujących żądania dostępu do plików za pośrednictwem przeglądarki, do podania nazwy i hasła.

5. Aktualnie najpopularniejszym sposobem tworzenia bezpiecznych połączeń WWW jest protokół SSL — Secure Socket Layer. Umożliwia on szyfrowanie połączeń sieciowych pomiędzy przeglądarką i serwerem WWW.

Ćwiczenia

1. Sprawdź, czy będziesz w stanie zabezpieczyć dostęp do wybranego katalogu przy użyciu pliku .htaccess.

2. Stwórz plik .htpsswd tak, aby każdy użytkownik mógł uzyskać dostęp do wybranego katalogu wyłącznie po podaniu odpowiedniego hasła. Rozszerz prawa dostępu do całej grupy użytkowników.

780

HTML 4 - Vademecum profesjonalisty

757

Bezpieczeństwo i kontrola dostępu do serwera WWW

28

---