Programowanie

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

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

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ą

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

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

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,

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

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

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ć

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

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

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

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

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

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

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

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