Bezpieczeństwo serwera Apache

Bezpieczeństwo serwera Apache

Jednym z aspektów funkcjonowania serwera WWW jest bezpieczeństwo udostępnianych danych i informacji.

Udostępnianie komputera osobom postronnym jest bardzo niebezpieczne i można to porównać do otwartych drzwi i wpuszczeniu nieznajomych do mieszkania. Przeciętny komputer stojący na biurku zapewnia pewien poziom bezpieczeństwa wykradzenie danych czy innych informacji oraz uszkodzenie wymaga po prostu fizycznego dostępu czyli włamania się na ten komputer. Sytuacja zmienia się diametralnie kiedy ten komputer podłączony jest do sieci Internet za pomocą linii telefonicznej lub innego medium. Jeśli komputer nie zostanie odpowiednio zabezpieczony skutki takiej nierozwagi mogą być poważne.

Dyskusja na temat bezpieczeństwa systemów i serwerów praktycznie nie ma końca i można by na ten temat długo dyskutować.

Jednym z ważniejszych zagadnień funkcjonowania serwera Apache jest problem bezpieczeństwa. Oprócz wszystkich normalnych zagrożeń, takich jak włamania, serwery WWW są odpowiedzialne za chronienie integralności zarówno informacji rozsyłanej przez serwer, jak i informacji wysyłanej przez klienta do serwera.

Główne zagrożenia spowodowane bezpieczeństwem to:

  • wykorzystanie błędów programowych serwera WWW i skryptów CGI do uzyskania nielegalnego dostępu do plików systemu czy nawet przejęcia kontroli nad całym komputerem
  • przedostanie się ważnych informacji z serwera do nieupoważnionych użytkowników
  • przechwycenie danych przesyłanych między serwerem i przeglądarką
  • przedostanie się ważnych informacji z komputera, na którym działa przeglądarka WWW do fałszywego serwera prowadzonego potajemnie przez przestępców.

Podstawowym zadaniem dobrego zarządzania serwerem jest uniemożliwienie udostępnienia poufnych informacji. Z drugiej jednak strony serwer ma służyć do szybkiego udostępniania dużej ilości informacji. Co za tym idzie wzrasta poziom niebezpieczeństwa.

Jednakże tak jak i każde udostępnienie czegokolwiek pociąga za sobą ryzyko, że udostępnione zasoby mogą być nadmiernie wykorzystywane lub też sposób ich udostępniania może być co najmniej niewłaściwy. Dlatego też przy prowadzeniu serwisów administratorzy powinni zwrócić szczególną uwagę na prawidłowe ich zabezpieczenie.

Jakie środki podejmiemy w celu zabezpieczenia serwera zależeć będzie przede wszystkim jakiego typu będzie nasz serwis. Inaczej będzie to wyglądało w przypadku serwera na którym testujemy swoje strony, a inaczej w przypadku serwera w intranecie czy też udostępnionego publicznie.

W przypadku bezpiecznego serwera użytkownicy i projektanci aplikacji muszą dokładnie rozważyć, które z certyfikatów i urzędów certyfikacji można uznać za wiarygodne. Jakiekolwiek błędy spowodowane nieodpowiednim wybraniem mogą spowodować duże straty.

Zabezpieczenie serwera Apache w systemach Windows jest dyskusyjne nie oznacza to ze systemy te nie posiadają żadnych zabezpieczeń a raczej są one słabo udokumentowana i zrozumiałe dla wąskiej grupy ludzi. Dlatego też dla poważnych czy tez komercyjnych serwisów zaleca się instalowania serwera Apache na którejś z odmian systemów operacyjnych Unika.

Zabezpieczenie Apache w tych systemach ogranicza się do odpowiedniej przemyślanej konfiguracji serwera:

  • ograniczenie wykonywania skryptów CGI w ogóle lub tylko w obrębie katalogu użytkownika
  • ograniczeni wykonywania skryptów PHP, JAVA, ActiveX
  • zabezpieczenie plików czy katalogów na hasło za pomocą pliku .htacces
  • używanie dyrektyw deny i allow dla określenia lub zablokowania komputera lub grupy komputerów
  • serwery WWW pozwalają na przechodzenie do miejsc docelowych wskazywanych przez łącza symboliczne, które znajdują się poza strukturą drzewa katalogów przeznaczonych na dokumenty serwera. W ramach bezpieczeństwa powinniśmy zabronić przechodzenia do linków wskazujących na łącza symboliczne lub umożliwić tylko przechodzenie do łącz, takich gdzie dowiązanie i wskazywany przez nie plik lub katalog należą do tego samego użytkownika. Łącza symboliczne mogą być niebezpieczne ze względu na możliwość stworzenia przez lokalnych userów dowiązań do plików systemowych co może spowodować ominięcie zabezpieczeń. Stosowanie łącz symbolicznych umożliwia opcja FollowSymLinks dyrektywy Options
  • dużą porcję informacji mogą nam dostarczyć pliki dzienników. Wszystkie błędy wykryte przez serwer zapisywane są w pliku wskazanym przez dyrektywę ErrorLog. Zaleca się więc wyłączeni modułu mod_status i mod_info (domyślnie są wyłaczone)
  • ograniczenie działania komputera jedynie do prowadzenia serwera WWW
  • ustalenie maksymalnej wielkości plików przesyłanych na serwer co zabezpieczy przed nadmiernych zapełnieniem buforów pamięci
  • uruchamiamy jedynie te usługi, które są niezbędne dla działania serwera WWW
  • przeprowadzanie regularnie wykonywanych kopii zapasowych
  • śledzenie na bieżąco informacji na temat wykrytych przez producenta i użytkowników luk w bezpieczeństwie w używanym systemie operacyjnym

Powyższe zagadnienia obejmują bezpieczeństwo po stronie serwera ale oprócz samego bezpieczeństwa serwera, bardzo ważne jest bezpieczeństwo po stronie klienta. Jeżeli chcemy prowadzić biznes e-commerce, możemy skorzystać z bezpiecznego serwera, który korzysta z bezpiecznego protokołu.

Wszystkie dane przesyłane są w formie czystego tekstu. Na dodatek jest to robione na otwartym kanale. Każdy kto ma dostęp do któregokolwiek z serwerów, przez które przechodzą informacje od użytkownika, może bez problemów przechwycić te dane. Jedynym wyjściem z tej sytuacji jest zastosowanie systemu szyfrującego. Obecnie, wszystkie bardziej liczące się przeglądarki (Internet Explorer, Netscape czy Opera), umożliwiają obsługę standardów kodowania, lecz każda robi to w inny sposób.

Protokół TCP/IP nie zawiera w budowanych mechanizmów ochrony danych w komunikacji klient – serwer, co umożliwiłoby bezpieczną wymianę danych. Może to stanowić zagrożenie, że dane zostaną przechwycone przez osoby trzecie. Dla spełnienia wymagań bezpieczeństwa na rynku internetowym zostało opracowanych wiele protokołów pośredniczących pomiędzy warstwą transportu – TCP/IP a warstwą aplikacyjną – np. HTTP (protokół przesyłania danych w WWW).

Do najważniejszych z nich zaliczamy:

  • S-HTTP (Secure-HTTP) jest modyfikacją HTTP umożliwiającą bezpieczne przesyłanie informacji zgodnych z protokołem HTTP. S-HTTP nie jest standardem. Został zgłoszony do World Wide Web Consortium (W3C) w celu poddania procesowi standaryzacyjnemu. Zapewnia poufność, integralność i autoryzację danych, a jednocześnie możliwość negocjowania algorytmów, zarządzania kluczami oraz metod szyfrowania.
  • SSL (Secure Socket Layer) jest to protokół opracowany przez firmę Netscape Communications, stanowi „nakładkę” na TCP/IP i jako taki umożliwia zarówno przesyłanie wiadomości w protokole HTTP jak i innych.
  • SST (Secure Transaction Technology) opracowany został przez Microsoft i firmę VISA. Protokół jest przeznaczony do prowadzenia bezpiecznych zakupów w Internecie przy pomocy kart kredytowych.

Najbardziej rozpowszechnionym z wyżej wymienionych protokołów jest protokół SSL i używa się go w przypadku, gdy istnieje potrzeba zestawienia bezpiecznego połączenia, aby dane wymieniane między klientem a serwerem nie mogły być przechwycone przez niepowołane osoby. Zapewnia szyfrowanie i integralność danych serwera oraz opcjonalnie klienta. Bezpieczny serwer stosujemy przy prowadzeniu m.in. sklepów internetowych, w których korzystamy z numerów kont czy kart kredytowych. Protokół SSL dopuszcza trzy warianty uwierzytelniania porozumiewających się stron: uwierzytelnienie obustronne (serwer i klient), uwierzytelnienie jednostronne (serwer, klient zostaje anonimowy) i komunikację całkowicie anonimową.

Jeśli chcemy korzystać z bezpiecznego uwierzytelnienie musimy zaopatrzyć się w moduł mod_ssl, który dla opisywanego serwera nie jest aktualnie dostępny.

Dokumentacja opisująca bezpieczeństwo serwera Apache w systemie Windows praktycznie nie istnieje nawet w dokumentacji dostarczanej razem z serwerem, jednak przeanalizowanie dostępnych dyrektyw i zdrowy rozsadek może uczynić z serwera Apache w miarę bezpieczny serwer stron WWW.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *