Rozdział 30. u Bezpieczeństwo serwera WWW i kontrola dostępu 855
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 systemó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 potencjalnym obiektem takiego ataku i powinieneś w związku z tym zatroszczyć się o jego bezpieczeń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 zechcą dobrać się do systemu poprzez serwer WWW jest bardzo małe. HTTP to prosty protokół, mający jedynie kilka powszechnie znanych luk, pozwalających na dostęp z zewną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 uruchomiony, 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 zabezpieczeń stosowanych w sieci Internet, ale sądzę, że osoby zainteresowane bez problemów znajdą jakąś pozycję na ten temat, jest ich bowiem dość dużo. Pragnę opisać kilka podstawowych technik zabezpieczania serwera WWW przed zagrożeniami zewnętrznymi i wewnętrznymi. Omówię też tematykę kontroli dostępu oraz autoryzację, które stanowią najprostszy mechanizm ochrony stron WWW przed ingerencją niepowołanych osób.
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:
n 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),
n parę sugestii na temat pisania bezpiecznych skryptów CGI (a przynajmniej skryptów bez oczywistych luk),
n kontrola dostępu do serwera WWW i autoryzacja użytkowników: co to jest, jak działa i do czego może się przydać,
n ustawianie kontroli dostępu i autoryzacji na serwerze WWW,
n 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.
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, pomogą ochronić system i pliki nie tylko przed intruzami z zewnątrz, ale także przed lokalnymi użytkownikami, którzy, celowo lub nie, przygotowując publikację swoich prezentacji, 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żytkownikom, możesz skorzystać ze wszystkich wskazówek zamieszczonych w tym rozdziale lub też zastosować je tylko do pewnej grupy użytkowników.
Standardowo większość uniksowych 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 kilku katalogach, co oznacza, że nie mogą zmieniać i kasować plików bez uzyskania specjalnych uprawnień.
Uruchamianie serwera WWW przez użytkownika o ograniczonych uprawnieniach jest bardzo dobrym pomysłem. W ten sposób nikt z tych, którym uda się uzyskać dostęp do systemu za pośrednictwem serwera, nie będzie mógł wyrządzić żadnych szkód poza wydzielonym obszarem. Jeżeli natomiast serwer zostanie uruchomiony przez użytkownika root, włamywacz 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ępnić 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ę zabezpieczania danych chcesz zastosować.
Istnieją dwa rozwiązania tego problemu. Pierwszy z nich polega na tym, że należy użytkownika 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 ograniczonej 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 odpowiedni dostęp.
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. Mechanizm ten jest zdecydowanie najbardziej niebezpieczny z punktu widzenia bezpieczeństwa danych, przechowywanych na serwerze WWW. Umożliwiając wykonywanie skryptów CGI, naraż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 mechanizmu CGI, a przynajmniej ograniczenie jego wykorzystania do kilku dobrze przetestowanych, bezpiecznych 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żliwość 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 zabezpieczeniach, 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 informacji na temat pisania skryptów, tak aby nie stanowiły one potencjalnego zagrożenia dla bezpieczeństwa systemu.
Połączenia symboliczne to coś w rodzaju aliasów, kolejnych wystąpień tego samego pliku w innym 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 serwer bez żadnych problemów odczyta taki plik.
Jeżeli wykorzystujesz serwer CERN HTTPD, nic nie stoi na przeszkodzie, aby twórcy prezentacji prowadzili połączenia symboliczne ze swoich stron do plików, które mogą znajdować 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ępniania 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 zdefiniowane 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, pozwala na przetwarzanie połączeń symbolicznych tylko wtedy, gdy właścicielem pliku i połączenia jest ten sam użytkownik. Jest to bezpieczniejsza metoda, która ogranicza wykorzystanie połączeń symbolicznych w obrębie drzewa katalogów jednego użytkownika.
Mechanizm SSI ze względu na swoje możliwości stanowi jedną z największych luk w bezpieczeństwie serwerów WWW (szczególnie chodzi tu o polecenie exec, pozwalające na uruchamianie skryptów). W ten sposób bardzo różne dane są przekazywane „w locie” na zewną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.
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 katalogu 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 sposób przypominający zawartość serwera.
Ale czy stanowi to jakieś zagrożenie? Jeżeli nie przeszkadza Ci, że czytelnicy mogą przeglądać zawartość katalogów, odpowiedź brzmi: nie. Jeżeli jednak w swoim katalogu przechowujesz 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:
n 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).
n 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 spowoduje włączenie omawianego mechanizmu.
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 danych nazwy plików, ich adresy URL, a czasami nawet całą zawartość. Utworzone w ten sposób zbiory danych służą następnie do wyszukiwania słów kluczowych, dzięki czemu użytkownicy 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 serwera takich plików, które nigdy nie powinny być odczytywane. Z tych powodów producenci robotów wyszli z inicjatywą wprowadzenia opcji, która uniemożliwiałaby ich programom przeszukiwanie 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 kilka linii opisujących katalogi, do których dostęp ma zostać odcięty (disallowed). Najprostsza 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 wszystkim robotom z wyjątkiem WebCrawlera:
#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 producenci 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, przeszukujących sieć WWW. Więcej informacji na temat robotów, wykorzy...
PannaZWilka