pl.comp.www FAQ | ||||
---|---|---|---|---|
Następny | Następny rozdział | Rozdział 13. Bezpieczeństwo WWW | Poprzedni rozdział | Poprzedni |
Na zagrożenia bezpieczeństwa powodowane przez serwery HTTP (i generalnie oprogramowanie ,,z drugiej ręki'') nie ma mocnych. Serwery HTTP w swej podstawowej konfiguracji nie są zbyt skomplikowanymi systemami. Jednak po dołożeniu rozmaitych (nieraz potrzebnych;-)) usług okazuje się że poziom skomplikowania aplikacji (z jednej strony system operacyjny, z drugiej serwery, wspomagające oprogramowanie: dedykowane serwerowi WWW interpretatory, programy --- zwłaszcza CGI) wzrasta w sposób niekontrolowany... Śledzenie informacji dostępnych w sieci (na listach programistycznych dotyczący danego oprogramowania, na bugtraq i ntbugtraq) staje się szczególnie istotne, gdy posiadamy skomplikowany system bazujący w dużej mierze cudzym, a zarazem dość rozpowszechnionym oprogramowaniu (pojawiają się większe możliwość znalezienia ,,exploita'' na nasz system i serwer) Istotna jest poprawna konfiguracja oprogramowania. Poprawna to znaczy taka by zapewniała odpowiednie środowisko pracy przy zachowaniu porządanej funkcjonalności. Do takich podstawowych środków należy zaostrzenie praw dostępu do kluczowych plików konfiguracyjnych (tak by dla ,,normalnych'' użytkowników były dostępne co najwyżej w trybie readonly , albo zupełnie nieczytelne). Jeszcze wcześniej należy nałożyć potrzebne [1] łaty systemowe (pochodzące od producentów: systemu i używanego oprogramowania) --- przy czym często łata == wymiana danego komponentu na nowszy posiadający kolejny błąd. ;-(. Lecz z drugiej strony część serwerów bez nich jest niemal bezbronna: np. MS IIS 3.0. bez tzw. hotfixów bardzo łatwo może zostać doprowadzony do Denial of Service .
[1] niekiedy założenie wszystkich może się nieciekawie skończyć --- instalujemy wówczas poprawione pliki bez niezbędnego do działania środowiska.
Kolejnym krokiem może być ustawienie nie do końca typowych (i dostępnych na wszystkich systemach) rozszerzonych praw do pliku --- np. na Linuksie warto zapoznać się z podręcznikiem systemowym polecenia chattr i ustawić dla logów parametr -----a- , zaś dla plików konfiguracyjnych ----i-- .
Wydaje mi się, że warto
zabronić wyświetlania zawartości katalogów wobec braku pliku domyślnego (wiedza o rzeczywistych identyfikatorach użytkowników może być przydatna włamywaczom) |
zabronić wykonywania symbolic link (choć chyba lepiej zezwolić o ile właścicielem pliku do którego wiedzie odniesienie i odnośnika jest ten sam użytkownik (w wypadku Apache jest to dyrektywa SymLinksIfOwnerMatch |
Ewentualnie można dać użytkownikom prawo zmiany tych parametrów w niektórych katalogach, lub ustawić samemu w plikach konfiguracyjnych serwera dla pewnych katalogów --- wykorzystując dyrektywę <Directory ścieżka>
Patrz też:.
Następny | Spis treści | Poprzedni |
CGI, API serwerów | Początek rozdziału | SSL |