apache. zabezpieczenia aplikacji i serwerów www

Wydawnictwo Helionul. Koœciuszki 1c44-100 Gliwicetel. 032 230 98 63e-mail: [email protected]

PRZYK£ADOWY ROZDZIA£PRZYK£ADOWY ROZDZIA£

IDZ DOIDZ DO

ZAMÓW DRUKOWANY KATALOGZAMÓW DRUKOWANY KATALOG

KATALOG KSI¥¯EKKATALOG KSI¥¯EK

TWÓJ KOSZYKTWÓJ KOSZYK

CENNIK I INFORMACJECENNIK I INFORMACJE

ZAMÓW INFORMACJEO NOWOœCIACH

ZAMÓW INFORMACJEO NOWOœCIACH

ZAMÓW CENNIKZAMÓW CENNIK

CZYTELNIACZYTELNIAFRAGMENTY KSI¥¯EK ONLINEFRAGMENTY KSI¥¯EK ONLINE

SPIS TREœCISPIS TREœCI

DODAJ DO KOSZYKADODAJ DO KOSZYKA

KATALOG ONLINEKATALOG ONLINE

Apache. Zabezpieczeniaaplikacji i serwerów WWWAutor: Ryan C. BarnettT³umaczenie: Marek Pa³czyñskISBN: 83-246-0505-3Tytu³ orygina³u: Preventing Web Attacks with ApacheFormat: B5, stron: 544

Internet to nie tylko niezmierzone Ÿród³o informacji. To tak¿e zagro¿enie dla serwerów WWW, aplikacji internetowych i baz danych, które codziennie s¹ atakowane przez komputerowych przestêpców, korzystaj¹cych z dziesi¹tek technik. Publikowane regularnie raporty o cyberprzestêpczoœci s¹ zatrwa¿aj¹ce. Liczba ataków na serwery internetowe wzrasta corocznie œrednio o 30%. Wœród atakowanych serwerów przewa¿aj¹ te, na których utrzymywane s¹ witryny WWW i aplikacje. Wed³ug raportu firmy Symantec, „aplikacje WWW s¹ popularnymi celami ataków z uwagi na ich rozpowszechnienie i fakt, ¿e pozwalaj¹ w³amywaczom na pominiêcie tradycyjnych mechanizmów zabezpieczaj¹cych, takich jak firewalle”. W tym samym raporcie mo¿na równie¿ przeczytaæ, ¿e prawie 50% luk w zabezpieczeniach serwerów wi¹¿e siê w³aœnie z aplikacjami WWW.

W ksi¹¿ce „Apache. Zabezpieczenia aplikacji i serwerów WWW” znajdziesz informacje o tym, w jaki sposób uchroniæ przed atakami hakerów aplikacje i witryny WWW kontrolowane przez najpopularniejszy obecnie serwer WWW — Apache. Przeczytaszo tym, jak poprawnie zainstalowaæ i skonfigurowaæ Apache’a i w jaki sposób uruchomiæ w nim modu³y zabezpieczeñ. Poznasz techniki ataków hakerskich i dowiesz siê, jak im zapobiegaæ. Znajdziesz sposoby testowania zabezpieczeñ swojego serwera za pomoc¹ odpowiednich narzêdzi. Nauczysz siê tak¿e wykrywaæ próby ataków i reagowaæ na nie odpowiednio wczeœnie.

• Czynniki wp³ywaj¹ce na bezpieczeñstwo sieci• Instalacja serwera Apache• Plik httpd.conf — konfiguracja Apache’a• Instalowanie i konfigurowanie modu³ów zabezpieczeñ• Klasyfikacja zagro¿eñ sieciowych WASC• Metody zabezpieczania aplikacji sieciowych• Ochrona przed atakami• Tworzenie serwerów-pu³apek

Dziêki tej ksi¹¿ce ka¿dy administrator bêdzie móg³ spokojnie spaæ

http://helion.pl/view/2547w



http://helion.pl/add/2547w/apazab




mailto:[email protected]

http://helion.pl/view/2547w/apazab.htm

http://www.amazon.com/exec/obidos/ASIN/0321321286/eboinf-20

O autorze ...................................................................................... 13

Przedmowa ................................................................................... 15

Wprowadzenie ............................................................................... 17

Rozdział 1. Czynniki wpływające na obniżenie bezpieczeństwa sieci ................. 29Typowy poranek ............................................................................................................. 29Dlaczego bezpieczeństwo sieciowe jest istotne? ............................................................ 31Czynniki wpływające na obniżenie bezpieczeństwa sieci .............................................. 32Zarządzanie i procedury ................................................................................................. 32

Zarządzanie i nieprzekraczalne terminy ................................................................... 32Sprzedaż załadowanego pistoletu ............................................................................. 33Dwuminutowa zmiana .............................................................................................. 34Środowisko projektowe a środowisko pracy ............................................................ 34Zdarzeniowa koncepcja utrzymania bezpieczeństwa sieci ...................................... 35

Błędy techniczne w zabezpieczeniach sieciowych ......................................................... 36Mamy serwer w strefie zdemilitaryzowanej ............................................................ 36Mamy firewalla ........................................................................................................ 37Mamy sieciowy system wykrywania włamań .......................................................... 38Mamy jednostkowy system wykrywania włamań ................................................... 39Wykorzystujemy protokół SSL ................................................................................ 39

Podsumowanie ................................................................................................................ 40

Rozdział 2. Raporty CIS dotyczące serwera Apache ......................................... 41Raporty CIS dotyczące serwera Apache dla systemu Unix

— zagadnienia związane z systemem operacyjnym .................................................... 41Zabezpieczenie usług innych niż HTTP ................................................................... 41Przykład ataku na usługę — wykorzystanie serwera FTP (7350wu) ....................... 46Wpływ błędów w usługach na bezpieczeństwo serwera Apache ............................ 49Uaktualnienia dostawców systemów operacyjnych ................................................. 49Dostosowanie stosu IP ............................................................................................. 50Odmowa obsługi ...................................................................................................... 51Grupy i konta użytkowników sieciowych ................................................................ 53Zablokowanie konta serwera WWW ....................................................................... 56Wprowadzenie limitów dyskowych ......................................................................... 57Dostęp do poleceń systemowych ............................................................................. 59Zmiana właściciela i praw dostępu do poleceń systemu .......................................... 64

6 Apache. Zabezpieczenia aplikacji i serwerów www

Tradycyjny mechanizm chroot ................................................................................. 65Wady mechanizmu chroot ........................................................................................ 65Moduł chroot mod_security ..................................................................................... 66Konfiguracja mechanizmu chroot ............................................................................ 66

Podsumowanie ................................................................................................................ 73

Rozdział 3. Instalacja serwera Apache ............................................................. 75Wybór wersji .................................................................................................................. 75Pakiety binarne czy kod źródłowy? ................................................................................ 76Pobranie kodu źródłowego ............................................................................................. 78

Czy potrzebna jest weryfikacja MD5 i PGP? ........................................................... 78Rozpakowanie archiwum ............................................................................................... 84

Nakładki ................................................................................................................... 85Śledzenie komunikatów o błędach i nakładkach ...................................................... 86Które moduły uwzględnić? ...................................................................................... 89

Podsumowanie ................................................................................................................ 98

Rozdział 4. Konfiguracja — plik httpd.conf ...................................................... 99Ustawienia uwzględnione w raporcie CIS .................................................................... 102Plik httpd.conf .............................................................................................................. 102Wyłączenie niepotrzebnych modułów .......................................................................... 103Dyrektywy .................................................................................................................... 104Dyrektywy związane z serwerem ................................................................................. 105

Moduły pracy wieloprocesorowej (MPM) ............................................................. 105Dyrektywa Listen ................................................................................................... 105Dyrektywa ServerName ......................................................................................... 106Dyrektywa ServerRoot ........................................................................................... 106Dyrektywa DocumentRoot ..................................................................................... 106Dyrektywa HostnameLookups ............................................................................... 106

Dyrektywy związane z kontami użytkowników ........................................................... 108Dyrektywa User ...................................................................................................... 108Dyrektywa Group ................................................................................................... 109Dyrektywa ServerAdmin ........................................................................................ 109

Dyrektywy związane z ochroną przed atakami DoS .................................................... 109Test domyślnej konfiguracji ................................................................................... 110Dyrektywa Timeout ................................................................................................ 111Dyrektywa KeepAlive ............................................................................................ 112Dyrektywa KeepAliveTimeout .............................................................................. 112Dyrektywa MaxKeepAliveRequests ...................................................................... 112Dyrektywa StartServers .......................................................................................... 113Dyrektywy MinSpareServers i MaxSpareServers .................................................. 113Dyrektywa ListenBacklog ...................................................................................... 113Dyrektywy MaxClients i ServerLimit .................................................................... 114Test serwera po zamianie konfiguracji ................................................................... 114Zapowiedź .............................................................................................................. 115

Dyrektywy utajniające oprogramowanie ...................................................................... 116Dyrektywa ServerTokens ....................................................................................... 116Dyrektywa ServerSignature ................................................................................... 117Dyrektywa ErrorDocument .................................................................................... 117

Dyrektywy katalogów ................................................................................................... 121Parametr All ........................................................................................................... 121Parametr ExecCGI .................................................................................................. 121Parametry FollowSymLinks i SymLinksIfOwnerMatch ....................................... 121Parametry Includes i IncludesNoExec ................................................................... 122

Spis treści 7

Parametr Indexes .................................................................................................... 122Dyrektywa AllowOverride ..................................................................................... 123Parametr Multiviews .............................................................................................. 123

Dyrektywy kontroli dostępu ......................................................................................... 123Uwierzytelnianie ........................................................................................................... 124Autoryzacja ................................................................................................................... 125

Dyrektywa Order .................................................................................................... 126Kontrola dostępu — informacje o kliencie ................................................................... 127

Nazwa komputera lub domeny ............................................................................... 127Adres IP lub zakres adresów IP .............................................................................. 128Zmienne środowiskowe żądania ............................................................................ 128Ochrona katalogu głównego ................................................................................... 128

Zmniejszenie liczby metod HTTP ................................................................................ 129Ogólne dyrektywy rejestracji zdarzeń .......................................................................... 130

Dyrektywa LogLevel .............................................................................................. 130Dyrektywa ErrorLog .............................................................................................. 130Dyrektywa LogFormat ........................................................................................... 131Dyrektywa CustomLog .......................................................................................... 131

Usunięcie domyślnych i przykładowych plików .......................................................... 132Pliki kodu źródłowego Apache .............................................................................. 132Domyślne pliki HTML ........................................................................................... 132Przykładowe skrypty CGI ...................................................................................... 133Pliki użytkownika webserv .................................................................................... 134

Zmiana praw dostępu .................................................................................................... 134Pliki konfiguracyjne serwera .................................................................................. 134Pliki katalogu dokumentów .................................................................................... 134Katalog cgi-bin ....................................................................................................... 135Katalog logs ............................................................................................................ 135Katalog bin ............................................................................................................. 135

Modyfikacja skryptu apachectl ..................................................................................... 136Test Nikto po zmianach konfiguracji ........................................................................... 137Podsumowanie .............................................................................................................. 137

Rozdział 5. Najważniejsze moduły zabezpieczeń ............................................. 139Protokół SSL ................................................................................................................. 139

Dlaczego należy korzystać z protokołu SSL? ........................................................ 140Jak działa mechanizm SSL? ................................................................................... 142Wymagane oprogramowanie .................................................................................. 144Instalacja oprogramowania SSL ............................................................................. 145Tworzenie certyfikatów SSL .................................................................................. 146Sprawdzenie wstępnej konfiguracji ....................................................................... 147Konfiguracja modułu mod_ssl ............................................................................... 149Podsumowanie mechanizmu SSL .......................................................................... 155

Moduł mod_rewrite ...................................................................................................... 155Włączenie modułu mod_rewrite ............................................................................ 156Podsumowanie modułu mod_rewrite ..................................................................... 158

Moduł mod_log_forensic ............................................................................................. 158Moduł mod_evasive ..................................................................................................... 159

Do czego służy moduł mod_evasive? .................................................................... 159Instalacja modułu mod_evasive ............................................................................. 160Jak działa moduł mod_evasive? ............................................................................. 160Konfiguracja ........................................................................................................... 161Podsumowanie modułu mod_evasive .................................................................... 165


Moduł mod_security ..................................................................................................... 165Instalacja modułu mod_security ............................................................................. 166Ogólne informacje na temat modułu ...................................................................... 166Opcje i możliwości modułu mod_security ............................................................. 167Techniki przeciwdziałania maskowaniu ataków .................................................... 168Specjalne wbudowane procedury sprawdzające .................................................... 169Reguły filtrowania .................................................................................................. 172Akcje ...................................................................................................................... 173Pozostałe funkcje .................................................................................................... 176

Podsumowanie .............................................................................................................. 177

Rozdział 6. Test konfiguracji— narzędzie CIS Apache Benchmark Scoring Tool .......................... 179Pobranie, rozpakowanie i uruchomienie aplikacji ........................................................ 180

Rozpakowanie archiwum ....................................................................................... 181Uruchomienie programu ........................................................................................ 182

Podsumowanie .............................................................................................................. 186

Rozdział 7. Klasyfikacja zagrożeń sieciowych WASC ...................................... 187Współautorzy dokumentu ............................................................................................. 188Charakterystyka dokumentu WASC ............................................................................ 188

Cele ......................................................................................................................... 189Wykorzystanie dokumentacji ................................................................................. 189Przegląd .................................................................................................................. 189Tło .......................................................................................................................... 190

Klasy ataków ................................................................................................................ 190Format podrozdziałów ............................................................................................ 191

Uwierzytelnianie ........................................................................................................... 192Metoda siłowa ........................................................................................................ 192Niedostateczne uwierzytelnienie ............................................................................ 196Niedoskonały mechanizm odzyskiwania haseł ...................................................... 198

Autoryzacja ................................................................................................................... 200Predykcja danych uwierzytelniających (danych sesji) ........................................... 200Niedostateczna autoryzacja .................................................................................... 202Niewłaściwe wygasanie sesji ................................................................................. 204Ustawienie sesji ...................................................................................................... 205

Ataki na jednostki klienckie ......................................................................................... 209Podmiana treści ...................................................................................................... 209Wykonywanie kodu w ramach witryny ................................................................. 211

Wykonywanie poleceń ................................................................................................. 213Przepełnienie bufora ............................................................................................... 213Atak z wykorzystaniem ciągu formatującego ........................................................ 218Wstrzyknięcie danych LDAP ................................................................................. 220Wykonanie poleceń systemu operacyjnego ........................................................... 222Wstrzyknięcie instrukcji SQL ................................................................................ 224Wstrzyknięcie instrukcji SSI .................................................................................. 229Wstrzyknięcie instrukcji XPath .............................................................................. 230

Ujawnienie informacji .................................................................................................. 231Indeksowanie katalogu ........................................................................................... 232Wyciek informacji .................................................................................................. 235Manipulacja ścieżkami ........................................................................................... 237Przewidywanie położenia zasobów ........................................................................ 240

Ataki logiczne ............................................................................................................... 241Zakłócenie funkcjonowania ................................................................................... 241Odmowa obsługi .................................................................................................... 244

Spis treści 9

Niedostateczne zabezpieczenie przed automatyzacją ............................................ 247Niedostateczna walidacja procesu .......................................................................... 248

Podsumowanie .............................................................................................................. 250

Rozdział 8. Zabezpieczenie aplikacji sieciowej Buggy Bank ............................ 251Instalacja serwisu Buggy Bank ..................................................................................... 252

Pliki witryny Buggy Bank ...................................................................................... 253Wyłączenie zabezpieczeń ....................................................................................... 253Testowanie instalacji .............................................................................................. 254

Funkcje ......................................................................................................................... 255Konta użytkowników ............................................................................................. 256

Metodologia działań ..................................................................................................... 257Ogólne zagadnienia ................................................................................................ 257Wykorzystane narzędzia ........................................................................................ 257Konfiguracja programu Burp Proxy ....................................................................... 258

Luki w zabezpieczeniach serwisu Buggy Bank ........................................................... 260Komentarze w kodzie HTML ................................................................................ 260Ustalenie numerów kont ......................................................................................... 261Jaka jest wartość entropii? ...................................................................................... 262Ustalenie numerów kont metodą siłową ................................................................ 263Wyznaczenie identyfikatorów PIN ........................................................................ 266Odblokowane konto ............................................................................................... 266Zablokowane konto ................................................................................................ 266Ustalenie identyfikatorów PIN metodą siłową ....................................................... 267Wstrzykiwanie poleceń .......................................................................................... 269Wykonanie polecenia netstat .................................................................................. 269

Wstrzyknięcie instrukcji SQL ...................................................................................... 273Zapobieganie wstrzykiwaniu instrukcji SQL ......................................................... 275

Wykonywanie skryptów w ramach witryny (XSS) ...................................................... 277Zapobieganie .......................................................................................................... 280

Zakłócenie działania funkcji przelewu ......................................................................... 280Zapobieganie .......................................................................................................... 282

Podsumowanie .............................................................................................................. 283

Rozdział 9. Ochrona i przeciwdziałanie ........................................................... 285Dlaczego firewalle nie chronią w dostateczny sposób serwerów i aplikacji? .............. 286Dlaczego systemy wykrywania włamań są również nieskuteczne................................ 288Szczegółowa analiza pakietów, wtrącone systemy IDS i firewalle aplikacji WWW .. 292

Firewalle z funkcją szczegółowej analizy pakietów .............................................. 293Wtrącone systemy IDS ........................................................................................... 294Firewalle aplikacji WWW ...................................................................................... 295

Rozwiązania systemów wykrywania włamań .............................................................. 297Metoda sygnaturowa .............................................................................................. 298Polityka zdarzeń pozytywnych (białe listy) ........................................................... 301Analiza nagłówków ................................................................................................ 311Analiza protokołów ................................................................................................ 314Analiza identyfikatora zasobu URI ........................................................................ 320Analiza heurystyczna ............................................................................................. 322Wykrywanie anomalii ............................................................................................ 323

Techniki oszukiwania systemów IDS i ochrona przed maskowaniem ataków ............ 325Możliwości oszukania systemu IDS ...................................................................... 325Mechanizmy zapobiegania maskowaniu żądań ..................................................... 328Oszukiwanie przez zakłócenie działania serwera Apache ..................................... 330


Wykrywanie sondowania i blokowanie niebezpiecznych stacji ................................... 333Sondowanie za pomocą programów robaków ....................................................... 333Blokowanie znanych niebezpiecznych stacji ......................................................... 334Aplikacja nmap — identyfikacja właściciela procesu ........................................... 337Aplikacja nmap — sprawdzenie wersji oprogramowania ...................................... 338W jakim celu zmienia się baner informacyjny serwera? ........................................ 340Ukrywanie baneru informacyjnego serwera .......................................................... 341

Rozpoznanie serwera WWW ........................................................................................ 343Różnice w implementacji protokołu HTTP ........................................................... 344Zbieranie informacji z banerów ............................................................................. 348Zaawansowane procedury rozpoznawania serwerów WWW ................................ 348Aplikacja HTTPrint ................................................................................................ 349Obrona przed procedurą rozpoznawania serwerów WWW ................................... 351

Niebezpieczne roboty, ciekawscy klienci i superskanery ............................................ 356Niebezpieczne roboty i ciekawscy klienci ............................................................. 357Superskanery .......................................................................................................... 359

Reagowanie na ataki DoS, wykorzystanie metod siłowych i modyfikacja stron ......... 365Ataki DoS ............................................................................................................... 365Wykorzystanie metod siłowych ............................................................................. 366Modyfikacja stron .................................................................................................. 368Zapobieganie modyfikowaniu stron ....................................................................... 373

Alarmy i śledzenie działań włamywaczy ..................................................................... 374Powołanie zmiennych ............................................................................................ 377Rejestrowanie danych do późniejszej analizy ........................................................ 377Filtracja nieistotnych żądań i sprawdzenie liczby wysłanych powiadomień ......... 378Rejestracja żądania i odsyłacze do aplikacji śledzenia włamywacza ..................... 378Wysłanie powiadomienia na pager ........................................................................ 379Wstrzymanie działania skryptu .............................................................................. 379Przesłanie dokumentu HTML ................................................................................ 379Przykładowe powiadomienia e-mail ...................................................................... 379

Monitorowanie dzienników pracy serwera i analiza ich zawartości ............................ 386Ciągły monitoring za pomocą programu SWATCH .............................................. 387Sgrep — analiza dziennika modułu mod_security ................................................. 391

Systemy-pułapki ........................................................................................................... 394Wabiące systemy-pułapki ...................................................................................... 395Fałszywy skrypt PHF ............................................................................................. 396Identyfikacja i śledzenie przypadków wykonywania poleceń systemowych ........ 397Moduł mod_rewrite 2.1 — ostatnia deska ratunku ................................................ 398

Podsumowanie .............................................................................................................. 399

Rozdział 10. Otwarty serwer proxy jako system-pułapka .................................. 401Po co instalować otwarty serwer proxy w roli systemu-pułapki? ................................ 401

Brak informacji o wystąpieniu ataku ..................................................................... 402Brak szczegółowych (dostatecznych) informacji o transakcjach HTTP ................ 402Brak zainteresowania ujawnieniem informacji o ataku ......................................... 402

Czym są serwery proxy? ............................................................................................... 403Podstawowe informacje na temat otwartych serwerów proxy ..................................... 404Otwarty serwer proxy jako system-pułapka ................................................................. 405

Router-firewall firmy Linksys ................................................................................ 405Wyłączenie niepotrzebnych usług sieciowych ....................................................... 406Konfiguracja serwera Apache jako jednostki proxy .............................................. 406

Sterowanie danymi ....................................................................................................... 408Moduł mod_evasive ............................................................................................... 409Moduł mod_security .............................................................................................. 409

Spis treści 11

Wykorzystanie sygnatur systemu Snort ................................................................. 410Ataki z wykorzystaniem metod siłowych .............................................................. 411

Przechwytywanie danych ............................................................................................. 412Ciągłe monitorowanie za pomocą programu Web spy .......................................... 413

Skan miesiąca — wyzwanie nr 31 w projekcie Honeynet ........................................... 414Wyzwanie ............................................................................................................... 414Czynności przygotowawcze ................................................................................... 415

Pytanie:W jaki sposób włamywacze odnaleźli proxy-pułapkę? ............................................. 416

Pytanie:Jakiego rodzaju ataki można zidentyfikować? Dla każdej kategorii atakupodaj przynajmniej jeden przykład wpisu i dołącz jak najwięcej informacjina temat samego ataku (np. identyfikatory CERT, CVE i sygnatur wirusów).Ile kategorii ataków można wyróżnić? ...................................................................... 417

Wyszukiwanie ciągu mod_security-message ......................................................... 418Wykorzystanie funkcji przekazywania AllowCONNECT .................................... 419Wyszukiwanie niestandardowych kodów statusowych HTTP .............................. 420Niestandardowe metody żądań HTTP .................................................................... 422Żądania niezgodne z protokołem HTTP ................................................................ 423Kategoria ataku — spam ........................................................................................ 425Kategoria ataku — uwierzytelnianie metodą siłową .............................................. 426Kategoria ataku — skanowanie luk w zabezpieczeniach ....................................... 427Kategoria ataku — robaki internetowe .................................................................. 432Kategoria ataku — pozorne kliknięcie baneru reklamowego ................................ 435Kategoria ataku — połączenia IRC ........................................................................ 436

Pytanie:Czy włamywacze wybierali jako cele ataków serwery WWW obsługująceprotokół SSL? ............................................................................................................ 437

Czy celem była również usługa SSL proxy-pułapki? ............................................ 438Dlaczego chcieli korzystać z protokołu SSL? ........................................................ 439Dlaczego nie korzystali wyłącznie z usług SSL? ................................................... 439

Pytanie:Czy są jakiekolwiek oznaki, że w ataku pośredniczyły inne serwery proxy?Opisz, w jaki sposób można wykryć takie działanie. Wymień inne zidentyfikowaneserwery proxy. Czy można potwierdzić, że dane jednostki są rzeczywiścieserwerami proxy? ....................................................................................................... 439

Identyfikacja aktywności ........................................................................................ 440Potwierdzenie informacji o serwerach proxy ......................................................... 442Wykorzystanie określonych otwartych serwerów proxy ....................................... 445Wykorzystanie określonych serwerów docelowych .............................................. 445

Pytanie:Wyodrębnij przypadki zastosowania metod siłowych do uwierzytelnienia.Czy można pozyskać dane uwierzytelniające (nazwę użytkownika i hasło)w formie otwartego tekstu? Opisz metody analizy .................................................... 447

Żądania HTTP GET ............................................................................................... 447Żądania HTTP POST ............................................................................................. 447Uwierzytelnienie HTTP typu Basic ....................................................................... 448Uzyskanie danych uwierzytelniających w formie otwartego tekstu ...................... 450Rozproszone skanowanie metodą siłową kont serwisu Yahoo! ............................. 451Skanowanie w przód i odwrotne ............................................................................ 452

Pytanie:Co oznacza komunikat modułu mod_security o treściInvalid Character Detected? Jaki był cel działania włamywacza? ............................. 457

Dyrektywa SecFilterCheckURLEncoding — sprawdzenie kodowania URL ........ 457


Dyrektywa SecFilterCheckUnicodeEncoding— sprawdzenie kodowania Unicode ................................................................... 457

Dyrektywa SecFilterForceByteRange— sprawdzenie zakresu wartości bajtowych ....................................................... 458

Sprawdzenie dostępności usługi SOCKS ............................................................... 458Ataki robaków internetowych Code Red i NIMDA ............................................... 459

Pytanie:Zarejestrowano kilka prób przesłania spamu, o czym świadczą próbywykorzystania adresu URL: http://mail.sina.com.cn/cgi-bin/sendmsg.cgi.List zawierał załącznik HTML (pliki wymienione w katalogu /upload).Jaka była treść strony WWW spamu? Kim byli odbiorcy spamu? .............................. 460

Odbiorcy spamu ..................................................................................................... 461Pytanie:

Opracuj kilka statystyk ............................................................................................... 461Dziesięciu najaktywniejszych włamywaczy .......................................................... 461Dziesięć najczęściej atakowanych jednostek ......................................................... 462Dziesięć najczęściej wykorzystywanych przeglądarek

(wraz z fałszowanymi nazwami) ......................................................................... 462Powiązanie włamywaczy z danymi serwisu DShield

i innymi źródłami informacji ............................................................................... 464Pytanie dodatkowe:

Dlaczego włamywacze wybierali witryny pornograficzne jako cel atakówz wykorzystaniem metod siłowych (poza oczywistą fizyczną gratyfikacją)? ........... 464

Czy mimo że adres IP i nazwa proxy-pułapki zostały zamaskowanewe wpisach dziennika, można wskazać prawdopodobnegowłaściciela segmentu sieci? ................................................................................. 466

Podsumowanie .............................................................................................................. 468

Rozdział 11. Podsumowanie prezentowanych rozwiązań ................................... 471Przykładowe ostrzeżenie o błędzie systemu zabezpieczeń .......................................... 471Sprawdzenie wersji oprogramowania ........................................................................... 472Sprawdzenie dostępności nakładki ............................................................................... 472Szczegółowe informacje o błędzie w zabezpieczeniach .............................................. 473

Utworzenie filtru mod_security ............................................................................. 476Test filtru ................................................................................................................ 476Pierwsza pomoc czy szpital .................................................................................... 477

Bezpieczeństwo sieci — zagadnienia niezwiązane z serwerem WWW ...................... 478Przejęcie domeny ................................................................................................... 478Zatrucie pamięci podręcznej DNS ......................................................................... 478Zakłócenie pracy buforującego serwera proxy ...................................................... 479Podmiana baneru reklamowego ............................................................................. 481Zakłócenie działania serwisu informacyjnego ....................................................... 481Podmiana czy nie? .................................................................................................. 482

Podsumowanie .............................................................................................................. 482

Dodatek A Słownik WASC ............................................................................ 485

Dodatek B Wykaz modułów Apache .............................................................. 495

Dodatek C Przykładowy plik httpd.conf ......................................................... 511

Skorowidz ................................................................................... 521

Rozdział 5.

W poprzednim rozdziale zostały przedstawione dyrektywy Apache, które mają wpływna bezpieczeństwo serwera. Ten rozdział jest poświęcony dodatkowym modułom, prze-znaczonym do zabezpieczenia aplikacji. Mogą one odgrywać istotną rolę w ogólnym za-bezpieczeniu serwera Apache, a ich złożoność i zakres działań są znacznie większe niżopisywanych wcześniej dyrektyw. W treści niniejszego rozdziału zostały zamieszczoneopisy zarówno procedur instalacyjnych, jak i ogólnych funkcji każdego z modułów. Niezostały natomiast przedstawione wszystkie dyrektywy modułów, ponieważ będą oneomawiane w dalszej części książki, w rozdziałach dotyczących konkretnych sposobówzapobiegania atakom sieciowym.

Protokół SSL

Omawianie najważniejszych modułów zabezpieczeń musi się rozpocząć od prezenta-cji modułu mod_ssl z pewnego szczególnego względu. Istnieje bowiem wielka rozbież-ność między jego rzeczywistymi funkcjami a oczekiwaniami wielu użytkowników. Gdy-by trzeba było podać motto tego podrozdziału, mogłoby nim być zdanie „Szyfrowanienie jest równoznaczne z bezpieczeństwem”. Chociaż protokół SSL odgrywa bardzoważną rolę w zabezpieczaniu komunikacji sieciowej, nie jest panaceum na wszystkieproblemy związane z bezpieczeństwem. O prawdziwości tego twierdzenia przekonał sięautor książki podczas dokonywania zakupów internetowych. Szczegółowy opis zdarze-nia został zamieszczony w części pt. „Jesteśmy bezpieczni, ponieważ stosujemy SSL —błędne rozumowanie”.


Dlaczego należy korzystać z protokołu SSL?

Stosowanie protokołu SSL pozwala na realizację trzech zadań.

� Szyfrowanie danych przesyłanych między serwerem i klientem

(tj. przeglądarką). Cecha ta jest najczęściej wykorzystywaną funkcją protokołuSSL. Po zainstalowaniu serwera WWW obsługującego mechanizm SSLadministratorzy nie mają większych problemów z wygenerowaniem certyfikatówpotrzebnych w komunikacji SSL. Rozwiązanie to natomiast zapewnia poufnośćwymiany informacji.

� Weryfikacja tożsamości serwera. Przeglądarki internetowe analizują certyfikatySSL przesyłane przez serwer WWW, sprawdzając, czy zostały one podpisaneprzez zewnętrzne urzędy certyfikacji (ang. Certificate Authority — CA), takiejak VeriSign lub Entrust. Jeżeli certyfikat nie jest podpisany, przeglądarkawyświetla okno dialogowe z informacją o błędzie. Prowadzenie serwisu handluelektronicznego niemal zawsze wiąże się z koniecznością uzyskania podpisanegocertyfikatu. Certyfikat ten uwiarygodnia witrynę i eliminuje niedogodnościzwiązane z wyświetlaniem komunikatów o błędach.

� Weryfikacja tożsamości klienta. Wiadomo, że klient może przeglądaćcertyfikat SSL serwera. Podobnie istnieje możliwość uwierzytelnienia klienta,o ile w jego przeglądarce został zainstalowany prywatny certyfikat. Mimoiż rozwiązanie to jest znane od wielu lat i ma więcej zalet w porównaniuze standardowymi mechanizmami uwierzytelniania (wymagającymi podanianazwy użytkownika i hasła), nie jest stosowane na szerszą skalę ze względuna koszty i trudności w zarządzaniu certyfikatami.

Jesteśmy bezpieczni, ponieważ stosujemy SSL — błędne rozumowanie

W lutym 2004 roku zdecydowałem się na zakup przez internet zestawu ziół, które podgrzanew kuchence mikrofalowej pomagają zwalczyć ból mięśni. Gdy wyświetliłem stronę producenta,od razu zostałem przywitany komunikatem „Ta witryna jest bezpieczna! Używamy 128-bitowegoszyfrowania SSL”. Miał on rozproszyć ewentualne wątpliwości użytkowników. Podczas finali-zowania zamówienia postanowiłem sprawdzić parametry SSL połączenia. Kliknąłem dwukrotnieikonę „kłódki” w prawym dolnym rogu okna przeglądarki i upewniłem się, że nazwa dome-nowa certyfikatu SSL odpowiada nazwie zawartej w adresie URL. Ponadto certyfikat zostałpodpisany przez zaufany urząd certyfikacji, jakim jest VeriSign, i nadal był ważny. Ponieważ nicnie budziło moich podejrzeń, przeszedłem do strony płatności i wpisałem dane karty kredytowej.Nacisnąłem przycisk przesłania formularza i zobaczyłem komunikat, który wywołał u mnieskurcz żołądka. Był to komunikat przesłany listem elektronicznym. Jego treść znajduje się po-niżej. Zmieniłem jedynie dane firmowe i informacje o karcie kredytowej.

Otrzymałem e-mail o następującej treści:

Od:[email protected]: [email protected]:ONLINE HERBPACK!!!nazwisko: Ryan Barnettadres: Nieznana 1234miejscowość: Gdzieśstan: Stan

Rozdział 5. � Najważniejsze moduły zabezpieczeń 141

kod pocztowy: 12345telefon#:rodzaj karty : American Expressnazwisko na karcie: Ryan Barnettnumer karty: 123456789012345data ważności: 11/d5liczba zestawów podstawowych:liczba poduszek na oczy:liczba usztywniaczy karku: 1liczba pasów: 1liczba zestawów jumbo:liczba ogrzewaczy stóp: 1liczba opasek na kolano:liczba opasek na nadgarstek:liczba zestawów klawiaturowych:liczba opasek barkowych:liczba kapeluszy czarnych: liczba kapelusz szarych:liczba kapeluszy niebieskich: liczba kapeluszy czerwonych:liczba kapeluszy beżowych: liczba kapeluszy pomarańczowych:czy chcesz przesłać paczkę do przyjaciela:nazwisko:jego adres:jego miejscowość:jego stan:jego kod pocztowy:

cgiemail 1.6

Nie mogłem uwierzyć własnym oczom. Numer mojej karty kredytowej został przesłany otwar-tym tekstem na konto pocztowe w AOL. Jak to możliwe? Administratorzy witryny byli najwy-raźniej dostatecznie zaznajomieni z technologią, żeby wiedzieć, że należy szyfrować daneklienta przesyłane do serwera. Dlaczego zatem nie wykazali się taką samą inteligencją, pro-jektując końcową fazę procedury?

Uznałem, że to zwykła pomyłka. Przeczytałem reklamę zamieszczoną u dołu ekranu, która in-formowała, że do przetwarzania zamówień wykorzystywane jest oprogramowanie cgiemail 1.6.Otworzyłem stronę Google i zacząłem szukać informacji na temat tego produktu. W serwisieGoogle znalazłem odsyłacz do poradnika administratora programu cgiemail. Szybko przejrza-łem jego treść i odszukałem interesujący rozdział pt. „Jakie zabezpieczenia zostały zaimple-mentowane?”.

Istnieje zagrożenie przechwycenia danych przesyłanych przez sieć z przeglądarki do ser-wera i z serwera do przeglądarki. Do podsłuchu informacji może dojść w każdym punkcietrasy między przeglądarką a serwerem.

Ryzyko: Aplikacja cgiemail, jak każdy program przekazujący dane z formularza na pocztę,jest podatna na podsłuch w dowolnym punkcie trasy między serwerem WWW a odbiorcąpoczty elektronicznej. Z uwagi na brak mechanizmów szyfrujących nie zaleca się przeka-zywania poufnych informacji, na przykład numerów kart kredytowych.

Tak jak przypuszczałem. Resztę dnia spędziłem, próbując poinformować wystawcę karty kre-dytowej o możliwym ujawnieniu danych karty oraz obserwując saldo rachunku bankowego. Prze-słałem również list do firmy prowadzącej sklep internetowy (na adres AOL). Opisałem w nimproblemy związane z bezpieczeństwem operacji. Całą sprawę można podsumować jednym zda-niem. Wykorzystanie protokołu SSL nie stanowi o bezpieczeństwie witryny.


Jak działa mechanizm SSL?

Mechanizm SSL działa na pograniczu warstwy trzeciej i czwartej modelu TCP/IP(tabela 5.1). Zapewnia funkcje szyfrowania dla wielu usług, wśród których jest rów-nież usługa HTTP. W praktyce algorytm SSL może być zaimplementowany w aplikacjiosłonowej, tworzącej tzw. tunel SSL, który zapewnia szyfrowany kanał transmisyjnydla dowolnej usługi TCP/IP.

Tabela 5.1. Sieciowy model odniesienia TCP/IP

Warstwa aplikacji (warstwa 4.) HTTP

SSL Szyfrowanie wszystkich danych warstwy 4.

Warstwa transportowa (warstwa 3.) TCP

Warstwa internetowa (warstwa 2.) IP

Warstwa sieciowa (warstwa 1.) Ethernet

W systemie Solaris jest dostępny monitor sieci snoop, za pomocą którego możnawizualnie wyróżnić poszczególne warstwy komunikacji sieciowej w standardowej tran-sakcji HTTP. W przykładzie listingu wynikowego programu snoop są widoczne danewszystkich warstw, choć ich kolejność jest odwrotna w porównaniu z wykazem przed-stawionym w tabeli 5.1. Wynika to z faktu demultipleksacji pakietu.

ETHER: ----- Ether Header -----ETHER:ETHER: Packet 4 arrived at 1d:47:44.5dETHER: Packet size = 411 bytesETHER: Destination = d:3:ba:8:1d:d,ETHER: Source = d:8:e2:42:b1:fc,ETHER: Ethertype = d8dd (IP)ETHER:IP: ----- IP Header -----IP:IP: Iersion = 4IP: Header length = 2d bytesIP: Type of service = dxddIP: xxx. .... = d (precedence)IP: ...d .... = normal delayIP: .... d... = normal throughputIP: .... .d.. = normal reliabilityIP: Total length = 397 bytesIP: Identification = 5914IP: Flags = dx4IP: .1.. .... = do not fragmentIP: ..d. .... = last fragmentIP: Fragment offset = d bytesIP: Time to live = 125 seconds/hopsIP: Protocol = 6 (TCP)IP: Header checksum = 1bd5IP: Source address = 192.168.1.1dd, 192.168.1.1ddIP: Destination address = 192.168.1.1d1, 192.168.1.1d1IP: No optionsIP:


TCP: ----- TCP Header -----TCP:TCP: Source port = 126dTCP: Destination port = 8d (HTTP)TCP: Sequence number = 2934191179TCP: Acknowledgement number = 3769986d61TCP: Data offset = 2d bytesTCP: Flags = dx18TCP: ..d. .... = No urgent pointerTCP: ...1 .... = AcknowledgementTCP: .... 1... = PushTCP: .... .d.. = No resetTCP: .... ..d. = No SynTCP: .... ...d = No FinTCP: Tindow = 6552dTCP: Checksum = dx4bb9TCP: Urgent pointer = dTCP: No optionsTCP:HTTP: ----- HyperText Transfer Protocol -----HTTP:HTTP: GET / HTTP/1.1HTTP: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword,application/x-shockwave-flash, */*HTTP: Accept-Language: en-usHTTP: Accept-Encoding: gzip, deflateHTTP: User-Agent: Hozilla/4.0 gcompatiblel H4.E 5.5l aindows MT 5.0.HTTP: Host: 192.168.1.101HTTP: Connection: Keep-Alive

Program snoop rejestruje dane wszystkich czterech warstw: sieciowej, IP, TCP i HTTP.W sekcji protokołu HTTP jest widoczne całe żądanie przesłane przez jednostkę kliencką,włącznie ze wszystkimi nagłówkami klienckimi. Dla porównania drugi listing wyni-kowy programu snoop został sporządzony podczas przekazywania żądania do serweraWWW z włączoną opcją SSL. Dane czwartej warstwy nie są widoczne, ponieważ apli-kacja snoop nie mogła rozszyfrować informacji.

ETHER: ----- Ether Header -----ETHER:ETHER: Packet 4 arrived at 13:d4:27.94ETHER: Packet size = 156 bytesETHER: Destination = d:3:ba:8:1d:d,ETHER: Source = d:8:e2:42:b1:fc,ETHER: Ethertype = d8dd (IP)ETHER:IP: ----- IP Header -----IP:IP: Iersion = 4IP: Header length = 2d bytesIP: Type of service = dxddIP: xxx. .... = d (precedence)IP: ...d .... = normal delayIP: .... d... = normal throughputIP: .... .d.. = normal reliabilityIP: Total length = 142 bytes


IP: Identification = 44235IP: Flags = dx4IP: .1.. .... = do not fragmentIP: ..d. .... = last fragmentIP: Fragment offset = d bytesIP: Time to live = 125 seconds/hopsIP: Protocol = 6 (TCP)IP: Header checksum = 8652IP: Source address = 192.168.1.1dd, 192.168.1.1ddIP: Destination address = 192.168.1.1d1, 192.168.1.1d1IP: No optionsIP:TCP: ----- TCP Header -----TCP:TCP: Source port = 1516TCP: Destination port = 443 (HTTPS)TCP: Sequence number = 69478725dTCP: Acknowledgement number = 1952824342TCP: Data offset = 2d bytesTCP: Flags = dx18TCP: ..d. .... = No urgent pointerTCP: ...1 .... = AcknowledgementTCP: .... 1... = PushTCP: .... .d.. = No resetTCP: .... ..d. = No SynTCP: .... ...d = No FinTCP: Tindow = 6552dTCP: Checksum = dxf26cTCP: Urgent pointer = dTCP: No optionsTCP:HTTP4: ----- HTTP4: -----HTTP4:HTTP4: ""HTTP4:

Do szyfrowania kanału komunikacyjnego mechanizm SSL wykorzystuje algorytm kryp-tograficzny bazujący na kluczu publicznym. Z tego względu ustanowienie połączeniaSSL wiąże się z pewnym narzutem komunikacyjnym. Przed przesłaniem jakichkolwiekdanych HTTP klient i serwer muszą wymienić klucze publiczne, zaakceptować zbióralgorytmów szyfrujących itd. Na rysunku 5.1 została przedstawiona przykładowa trans-akcja SSL ustanawiająca połączenie między serwerem i klientem, zarejestrowana przeznarzędzie monitorujące Ethereal.

Wymagane oprogramowanie

Aby zaimplementować mechanizm SSL w działaniu serwera Apache, trzeba najpierwzainstalować pakiet OpenSSL. Ostatnią wersję oprogramowania OpenSSL można pobraćze strony www.openssl.org. W czasie pisania książki była to wersja 0.9.8b. BibliotekaOpenSSL jest niezbędna podczas kompilowania modułu mod_ssl, w którym są wyko-rzystywane różne jej funkcje kryptograficzne.


Rysunek 5.1. Wymiana danych protokołu SSL

Poza pakietem oprogramowania OpenSSL system operacyjny musi obsługiwać urzą-dzenie przeznaczone do generowania wartości pseudolosowych. Większość systemówUnix jest wyposażona domyślnie w urządzenie /dev/random, odpowiednie dla modułumod_ssl. Z kolei aby takie urządzenie było dostępne w systemie Solaris, należy zainsta-lować odpowiednią nakładkę. W przypadku braku generatora liczb losowych programApache nie zostanie uruchomiony i spowoduje wygenerowanie komunikatów o błędach.

Instalacja oprogramowania SSL

Osoby korzystające z serwera Apache w wersji 1.3 muszą pobrać kod modułu mod_sslze strony www.modssl.org. Oprogramowanie serwera w wersji 2.0 jest rozpowszechnianewraz z odpowiednią wersją biblioteki mod_ssl. Zatem procedura włączenia modułupodczas kompilacji kodu serwera sprowadza się do zastosowania opcji --enable-ssl.Niestety podczas kompilowania biblioteki mod_ssl jako obiektu DSO (dla Apache 2.0.52)występuje pewien błąd. Sama kompilacja przebiega co prawda poprawnie, ale procespotomny SSL nie obsługuje żadnych żądań i przedwcześnie kończy swoją pracę. Z in-formacji dostępnych w internecie wynika, że ten problem został zauważony przez wieluadministratorów, którzy próbowali wykorzystać moduł mod_ssl jako obiekt DSO w po-łączeniu ze statycznie skompilowanym pakietem OpenSSL. Aby instalacja przebiegłaprawidłowo, należy wykonać procedurę opisaną w rozdziale 3.


Tworzenie certyfikatów SSL

W opisywanej procedurze instalacyjnej został wykorzystany moduł mod_ssl rozpo-wszechniany z oprogramowaniem Apache 2.0.52. Do utworzenia certyfikatów nie możnazatem wykorzystać tej samej metody, która jest stosowana w odniesieniu do kodu po-branego z witryny modssl.org. Choć trzeba przyznać, że procedura generowania certyfi-katów dla modułu dostępnego w witrynie modssl.org jest znacznie mniej nużąca. Sprowa-dza się do wykonania poniższego polecenia (w pliku Makefile znajduje się odpowiedniareguła).

# make certificate TYPE=custom

Wykonanie instrukcji powoduje wyświetlenie niewielkiego menu, które prowadzi użyt-kownika przez całą procedurę konfiguracyjną, związaną z definiowaniem nazwy orga-nizacji, określeniem umiejscowienia serwera, nazwy domeny i wszystkich parametrówzapisywanych w certyfikacie SSL. Niestety wersja oprogramowania mod_ssl dostarczanawraz z kodem Apache 2.0.52 nie zawiera interfejsu dla programu make. Administrato-rowi pozostaje więc jedynie wykorzystanie biblioteki OpenSSL. Wynik końcowy jestoczywiście taki sam jak w przypadku zastosowania oprogramowania pobranego ze stronymodssl.org — tworzony jest certyfikat SSL oraz żądanie podpisania certyfikatu (ang.Certificate Signing Request — CSR), przesyłane później do urzędu certyfikującego(ang. Certificate Authority — CA), takiego jak VeriSign czy Entrust. Niestety dojście dotego etapu nie jest wcale łatwe. Na kolejnym listingu są przedstawione polecenia, któretworzą katalogi potrzebne do przechowywania plików SSL oraz instrukcje odpowie-dzialne za wygenerowanie samego certyfikatu.

# mkdir /usr/local/apache/conf/ssl.key# mkdir /usr/local/apache/conf/ssl.crt# mkdir /usr/local/apache/conf/ssl.crl# /usr/local/ssl/bin/openssl req \ -new \ -x509 \ -days 60 \ –keyout/usr/local/apache/conf/ssl.key/server.key \ -out/usr/local/apache/conf/ssl.crt/server.crtUsing configuration from /usr/share/ssl/openssl.cnfGenerating a 1d24 bit RSA private key...............++++++..............++++++writing new private key to '/tmp/server.key'Enter PEM pass phrase:******Ierifying password - Enter PEM pass phrase:******-----You are about to be asked to enter information that will be incorporatedinto your certificate request.That you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) lAUt:PLState or Province Name (full name) lSome-Statet:slaskieLocality Name (eg, city) lt:GliwiceOrganization Name (eg, company) lInternet Tidgits Pty Ltdt:Zabezpieczenia ApacheOrganizational Unit Name (eg, section) lt:Zabezpieczenia aaaCommon Name (eg, your name or your server's hostname) lt:www.moja_nazwa.plEmail Address lt:webmaster@moja_nazwa.pl


Sprawdzenie wstępnej konfiguracji

Na tym etapie prac warto sprawdzić, czy moduł mod_ssl będzie poprawnie działał przydomyślnej konfiguracji. Do uruchomienia serwera należy wykorzystać standardowyskrypt apachectl, ale tym razem z opcją startssl.

# /usr/local/apache/bin/apachectl startsslApache/2.d.52 mod_ssl/2.d.52 (Pass Phrase Dialog)Some of your private key files are encrypted for security reasons.In order to read them you have to provide us with the pass phrases.

Server www.example.com:443 (RSA)Enter pass phrase:

Ok: Pass Phrase Dialog successful.

# ps -ef | grep httpdroot 38d6 1 d 14:23 r dd:dd:dd /usr/local/apache/bin/httpd -k start

-DSSLwebserv 38d7 38d6 d 14:23 r dd:dd:dd /usr/local/apache/bin/httpd -k start



-DSSLwebserv 381d 38d6 d 14:23 r dd:dd:dd /usr/local/apache/bin/httpd -k start

-DSSLwebserv 3811 38d6 d 14:23 r dd:dd:dd /usr/local/apache/bin/httpd -k start

-DSSL

Z analizy listingu wynika, że serwer obsługuje mechanizm SSL, co można stwierdzićna podstawie opcji –DSSL. Ostatni etap procedury obejmuje próbę połączenia się z ser-werem WWW i sprawdzenie, czy rzeczywiście obsługuje on żądania klienckie. Jeżelido testu zostanie wykorzystana aplikacja s_client pakietu OpenSSL, administrator będziemógł zweryfikować dane certyfikatów SSL, które sam wcześniej wprowadził. Po usta-nowieniu połączenia wystarczy wpisać standardowe polecenie HTTP HEAD. Serwer odeślewówczas typowe nagłówki odpowiedzi HTTP. Przykład zastosowania opisywanej apli-kacji znajduje się poniżej.

# openssl s_client -connect 192.168.2.248:443CONNECTED(ddddddd3)depth=0 /C=PL/4T=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=Zabezpieczeniaaaa/CM=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.plverify error:num=18:self signed certificateverify return:1depth=d /C=PL/ST=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=ZabezpieczeniaTTT/CN=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.plverify return:1---Certificate chain d s:/C=PL/ST=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=ZabezpieczeniaTTT/CN=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.pl i:/C=PL/ST=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=ZabezpieczeniaTTT/CN=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.pl---


Server certificate-----BEGIN CERTIFICATE-----MIID8TCCA1qgAwIBAgIBADANBgkqhkiG9wdBATTFADCBsjELMAkGA1UEBhMCUEwxEDAOBgNIBAgTB3NsYXNraTUxEDAOBgNIBAcTBddsaXdpY2UxHjAcBgNIBAoTFIphYmI6cGllY3plbmlhIEFwYTNoZTEbMBkGA1UECxMSTmFiZXpwaTIjemIuaTEgI1dXMRowGAYDITTDFBF3d3cubT9qYI9uYXp3YS5wbDEmMCTGCSqGSIb3DTEYARYXd2IibTFzdGIyTG1vamFfbmF6d2EucGwwHhcNMDYwNjIxMTIyMzEyThcNMDYwODIwMTIyMzEyTjCBsjELMAkGA1UEBhMCUEwxEDAOBgNIBAgTB3NsYXNraTUxEDAOBgNIBAcTBddsaXdpY2UxHjAcBgNIBAoTFIphYmI6cGllY3plbmlhIEFwYTNoZTEbMBkGA1UECxMSTmFiZXpwaTIjemIuaTEgI1dXMRowGAYDITTDFBF3d3cubT9qYI9uYXp3YS5wbDEmMCTGCSqGSIb3DTEYARYXd2IibTFzdGIyTG1vamFfbmF6d2EucGwwgZ8wDTYYKoZIhvcNATEBBTADgYdAMIGYAoGBANDGhsIGjya95LkwrMoS4Ukyq4T2XTd7Ksy52xa7bpOqwU9NSyiImESIXNn8ozy+j/udilCqf4Ney8+vyH5YLsvpNq321meKIrdyHIvN5SIqYrhYSRjIogTk5vRs79l29TcT3Y2Kc6UcGfFbtuIEob2n2gnfvY4b+qgu/+smCpn5AgMBAAGjggETMIIBDzAdBgNIHT4EFgTUpv+7RTs7O9n+DByidrLsb7NHacgwgd8GA1UdIwSB1zCB1IAUpv+7RTs7O9n+DByidrLsb7NHacihgbikgbUwgbIxCzAYBgNIBAYTAlBMMRAwDgYDITTIEwdzbGFza2llMRAwDgYDITTHEwdHbGl3aTNlMR4wHAYDITTKExIaYTYlenBpZTN6ZT5pYSBBcGFjaGUxGzAZBgNIBAsTElphYmI6cGllY3plbmlhIFdXIzEaMBgGA1UEAxTRd3d3Lm1vamFfbmF6d2EucGwxYjAkBgkqhkiG9wdBCTETF3dlYm1hc3RlckBtb2phX25hendhLnBsggEAMAwGA1UdEwTFMAMBAf8wDTYYKoZIhvcNATEEBTADgYEARHdTGAo23vluFths2pIAdG+L1p+ts2TATh6B9E6xKUXAICT62Bh6yFcfc8KkefrEr188pT92SZ+N7kPYcO4enl6STPfvY7BXm/YOSs1RzCvT5/f5rmIDb5d2YhgL3LAHDvjLMs5A51D4RotdbYjZE/ImfGIxCIqbhtwbCrzXl24=-----END CERTIFICATE-----subject=/C=PL/ST=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=ZabezpieczeniaTTT/CN=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.plissuer=/C=PL/ST=slaskie/L=Gliwice/O=Zabezpieczenia Apache/OU=ZabezpieczeniaTTT/CN=www.moja_nazwa.pl/emailAddress=webmaster@moja_nazwa.pl---No client certificate CA names sent---SSL handshake has read 1577 bytes and written 34d bytes---New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHAServer public key is 1d24 bitSSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: EB22d7ddd74951F9D6F874Ad6D3dC6DFC6dEF8B8Ed7D8d5C1d981D89B3dBCdC5 Session-ID-ctx: Master-Key:2E5dd87D58325FF259F87DF6C9B8FBFDA44dA2EA39F96E955Ad1C72dBCBdd5A9C522863DFA1dAEd4E4C8EFACC73D5695 Key-Arg : None Krb5 Principal: None Start Time: 115d893428 Timeout : 3dd (sec) Ierify return code: 18 (self signed certificate)---HEAD / HTTP/1.0

HTTP/1.1 200 OKDate: aed, 21 Jun 2006 12:38:33 GHT4erver: ApacheLast-Hodified: 4at, 17 Jun 2006 12:51:49 GHTETag: "5b1a6-7-ff18c340"Accept-Ranges: bytes


Content-Length: 7Connection: closeContent-Type: text/htmll charset=.4O-8859-1

Closed

Doskonale! Aplikacja kliencka OpenSSL pokazuje przebieg negocjacji SSL. Możnawięc dzięki niej przeanalizować dane zawarte w utworzonym wcześniej certyfikacie SSL(np. określić nazwę domenową itp.) oraz parametry mechanizmu SSL (w tym wersjęprotokołu i rodzaj algorytmu szyfrującego). Mimo iż nowo uruchomiony serwer HTTPSmoże już obsługiwać żądania klientów, konieczne jest jeszcze wprowadzenie pewnychzmian w jego domyślnej konfiguracji — podobnie jak w przypadku modyfikacji plikuhttpd.conf.

Konfiguracja modułu mod_ssl

Moduł mod_ssl udostępnia administratorowi wiele dyrektyw konfiguracyjnych. Niewszystkie jednak zostaną tu opisane. Celem niniejszego punktu jest przedstawienie je-dynie tych ustawień, które mają bezpośredni związek z zabezpieczeniami i które służąrozwiązaniu najczęściej występujących problemów. Szczegółowe informacje na tematdyrektyw modułu mod_ssl są zamieszczone na stronach dokumentacji Apache 2.0 (http://

httpd.apache.org/docs-2.0/mod/mod_ssl.html) oraz w witrynie modssl.org (www.modssl.

org/docs/2.8).

Dyrektywa SSLEngine

Dyrektywa SSLEngine włącza lub wyłącza pracę mechanizmu SSL/TLS. Zazwyczaj jestona wymieniana w kontenerze VirtualHost dla portu 443. Aby włączyć opcję, należyumieścić w pliku konfiguracyjnym wpis SSLEngine ON.

Dyrektywa SSLProtocol

Serwer Apache może pracować z trzema wersjami protokołu SSL.

� SSLv2. Jest to pierwotny protokół, opracowany przez firmę Netscape Corporationw 1994 roku. Został on zaprojektowany z myślą o zapewnieniu bezpiecznejkomunikacji w internecie. Mimo iż podstawowe założenie zostało spełnione,w samym protokole odkryto wiele nieprawidłowości. Do najważniejszych z nichtrzeba zaliczyć możliwość wymuszenia przez jednostkę kliencką stosowaniasłabszych algorytmów szyfrowania i brak ochrony dla procedury wymianykluczy. Wady te sprawiły, że rozwiązanie okazało się mniej bezpieczne, niżpoczątkowo sądzono. Słabości protokołu wymiany kluczy pakietu OpenSSLSSLv2 zostały później wykorzystane w kodzie robaka Slapper do łamaniazabezpieczeń systemu.

� SSLv3. Uaktualnienie protokołu SSL zostało wydane przez firmę Netscapew 1996 roku. Jego celem było wyeliminowanie niedociągnięć wersji SSLv2.Mechanizm ten szybko stał się podstawowym algorytmem szyfrowania danychw komunikacji sieciowej.


� TLSv1. Skrót TLS jest akronimem od angielskich słów Transport LayerSecurity, oznaczających zabezpieczenie warstwy transportowej. Protokół TLSzostał zdefiniowany przez organizację Internet Engineering Task Force w 1999roku w dokumencie RFC 2246. Głównym celem prac IETF było utworzenieotwartego standardu SSL oraz przetestowanie i włączenie do standardu niektórychrozwiązań firmy Microsoft z pakietu PCT.

Mając podstawowe informacje na temat różnych wersji protokołu, można przystąpićdo konfigurowania jego ustawień. Operowanie parametrami dyrektywy SSLProtocol jestzbliżone do ustawień Options (opisanych w poprzednim rozdziale). Do włączania i wy-łączania konkretnych wersji protokołu stosowane są odpowiednio znaki plus (+) i minus(-). Można również użyć słowa kluczowego all, które zastępuje definicję +SSLv2 +SSLv3+TLSv1. Z uwagi na wady protokołu SSLv2 powinien on być wyłączony. Zatem zaleca-nym ciągiem tekstowym dyrektywy jest SSLProtocol all –SSLv2.

Dyrektywa SSLCipherSuite

Jeśli chce się mieć naprawdę skuteczne zabezpieczenie kryptograficzne, trzeba spełnićdwa warunki — zagwarantować dostępność silnego algorytmu kryptograficznego i dłu-giego klucza szyfrowania. Istnieje wiele dowodów na to, że nieefektywny mechanizmszyfrowania lub krótki klucz (mniejszy niż 128-bitowy) przy obecnej mocy obliczenio-wej komputerów można złamać w bardzo krótkim czasie. Dyrektywa SSLCipSerSuitepozwala administratorowi na odpowiednie wyznaczenie obydwu parametrów. Warto-ściami ustawienia są cztery rozdzielane znakiem dwukropka specyfikacje algorytmówszyfrowania, które klient może wykorzystać w trakcie negocjacji. Cztery wspomnianespecyfikacje wyznaczają cztery kategorie parametrów — algorytm wymiany kluczy,algorytm uwierzytelniania, algorytm szyfrowania i algorytm skrótu MAC. W ramachkażdej kategorii administrator może definiować wartości odpowiadające poszczególnymalgorytmom, takim jak RSA, Diffie-Hellman i 3DES. Kolejność wymieniania opcjiwyznacza kolejność użycia ich przez jednostkę kliencką. Pewnym ułatwieniem pro-cedury konfiguracyjnej jest możliwość stosowania aliasów zamiast list poszczegól-nych parametrów. Dyrektywa gwarantująca najwyższy stopień zabezpieczeń powinnamieć następującą treść:

44LCipher4uite H.GH:HED.UH:!aMULL:+4HA1:+HD5:+H.GH:+HED.UH

Powyższy zapis oznacza, że dozwolone są tylko silne algorytmy szyfrujące (o kluczachdłuższych niż 128 bitów). Ponadto wyłączone zostają algorytmy słabsze i nieszyfrującedanych, wyłączone jest również anonimowe uwierzytelnianie. Algorytm SHA1 ma pierw-szeństwo przed MD5 (ze względu na problemy z kolizjami MD5).

Dyrektywa SSLRandomSeed

Innym niezwykle istotnym elementem dobrego algorytmu szyfrowania jest odpowied-nie działanie generatora liczb losowych. Użycie losowych wartości jako wartości wej-ściowej dla funkcji szyfrowania OpenSSL znacznie utrudnia osobie atakującej predykcjęprzyszłych danych. Jednym z parametrów tej dyrektywy może być parametr builtin,który oznacza stosowanie wartości będącej połączeniem aktualnego czasu, identyfikatorauruchomionego procesu oraz przypadkowej wartości pobranej z listy procesów Apache.


Wada tego rozwiązania polega na tym, że przypadkowość wartości pobranej z listyprocesów nie jest wystarczająca. Natomiast dwa pozostałe elementy są potencjalniełatwe do ustalenia.

Najczęściej stosowanymi generatorami liczb losowych na platformach Unix są urządze-nia /dev/random i /dev/urandom. Obydwa wymienione urządzenia mogą być stosowanejako źródła wartości początkowej dla funkcji szyfrowania. Jednak zalecanym urządze-niem jest /dev/urandom. Wynika to z faktu, że w przypadku niemożności uzyskania do-statecznej entropii /dev/random może się zablokować. Oprogramowanie Apache pozwalana wykorzystywanie dyrektywy SSLRandomSeed w dwóch różnych kontekstach — startuserwera (startup) (analizowana w chwili pierwszego uruchamiania za pomocą skryptuapachectl) oraz połączenia (connect) (analizowana w chwili inicjowania przez jednostkękliencką połączenia z procesem potomnym). Zalecanym ustawieniem dyrektywy jest:

44LRandom4eed startup file:/dev/urandom 51244LRandom4eed connect file:/dev/urandom 512

Dyrektywy SSLCertificateFile i SSLCertificateKeyFile

Te dwie dyrektywy stanowią dla serwera Apache informację o tym, w których plikachjest zapisany certyfikat i klucz prywatny SSL. Jeżeli został utworzony certyfikat PEMserwera, zawierający jego klucz prywatny, można wykorzystać jedynie dyrektywęSSLCertificateFile. W większości przypadków są jednak stosowane dwa niezależnepliki. Wystarczy przejrzeć przedstawione wcześniej polecenie openssl, aby zobaczyć, żegeneruje ono dwa pliki certyfikatów SSL. Konieczne jest zatem wprowadzenie dwóchnastępujących wierszy:

44LCertificateFile /usr/local/apache/conf/ssl.crt/server.crt44LCertificateKeyFile /usr/local/apache/conf/ssl.key/server.key

Certyfikaty bez haseł

Klucz prywatny serwera (server.key) jest szyfrowany. Z tego względu podczas uru-chamiania usługi Apache administrator musi podać hasło, które pozwoli oprogramo-waniu rozszyfrować plik i wykorzystać klucz prywatny. Pod względem bezpieczeństwasystemu takie rozwiązanie jest optymalne. Gwarantuje bowiem zachowanie poufnościnawet w przypadku, gdy włamywacz zdobędzie plik klucza prywatnego — jeżeli niebędzie znał hasła, nie będzie mógł rozszyfrować treści pliku i użyć klucza. Uniemożliwiazatem obcej jednostce podszycie się pod serwer z przechwyconym certyfikatem SSL.

Wymienione zalety wydają się dostatecznie przekonujące, by uznać stosowanie hasełza najkorzystniejsze rozwiązanie. Wiąże się ono jednak z dużymi utrudnieniami w auto-matyzacji zadań administracyjnych. Wielu doświadczonych administratorów serwerówuruchamia różnego rodzaju skrypty monitorujące pracę usługi httpd. Gdy skrypt wykryjewyłączenie serwera, automatycznie próbuje ponownie go uruchomić. Metoda ta niesprawdza się jednak w przypadku zabezpieczenia klucza prywatnego za pomocą hasła.Jednym ze sposobów rozwiązania problemu jest umieszczenie hasła w kodzie skryptui automatyczne wprowadzenie danych uwierzytelniających na żądanie programu serwera.Koncepcja ta wyklucza jednak wszystkie korzyści związane z bezpieczeństwem i ochro-ną klucza.


Niewątpliwie jednym z najczęściej występujących pytań na listach FAQ jest pytanieo sposób usunięcia hasła z certyfikatu SSL. Przedstawiane w tej książce rozwiązaniabazują na założeniu, że bezpieczeństwo aplikacji WWW zależy od zabezpieczeń danejjednostki. Zgodnie z informacjami zawartymi w rozdziale 2. serwera nie można uznaćza bezpieczny, jeżeli brakuje zabezpieczeń samego systemu operacyjnego. Przyjmującten tok rozumowania, należy stwierdzić, że jeżeli nie można polegać na systemie ope-racyjnym, to ryzyko przechwycenia klucza prywatnego SSL powinno być najmniej-szym zmartwieniem. Zatem usunięcie hasła z pliku klucza prywatnego nie powinnostanowić problemu przy założeniu, że administrator skrupulatnie zrealizował wszyst-kie procedury zabezpieczenia jednostki. Aby usunąć z pliku klucza prywatnego hasło,trzeba wykonać następujące instrukcje:

# cd /usr/local/apache/conf/ssl.key# mv server.key server.key.old# openssl rsa -in server.key.old -out server.key

Zadanie przedstawionych poleceń polega na utworzeniu kopii zapasowej pliku ser-

ver.key oraz usunięciu szyfrowania RSA z tego pliku. Od chwili wykonania tej operacjiserwer Apache nie będzie wymagał hasła podczas uruchamiania usługi w trybie SSL.

Dyrektywa SSLOptions

Moduł SSL pozwala na definiowanie wielu opcji, które umożliwiają precyzyjne pa-rametryzowanie sposobu jego działania w szczególnych sytuacjach (np. gdy trzeba wpro-wadzić dodatkową zmienną środowiskową dla skryptu CGI lub wykorzystać fragmentycertyfikatu klienta jako dane uwierzytelniające w podstawowej procedurze uwierzytel-niania [ang. Basic Authentication]). Wśród nich jest opcja, która pozwala na kontynuowa-nie przetwarzania żądania klienckiego, jeżeli spełni ono jedno z kryteriów. Z punktuwidzenia osoby zajmującej się zabezpieczeniami nie jest to rozwiązanie idealne, gdyżdaje możliwość zaakceptowania żądania, które zostało odrzucone na podstawie innejopcji. Przedstawiona dyrektywa zapewni ścisłe respektowanie wszystkich reguł.

44LOptions +4trictRequire

SSLRequireSSL

Po uwierzytelnieniu klienta w aplikacji WWW jego dane są zapisywane w nagłówkupodstawowego uwierzytelnienia lub w formie identyfikatora sesji w pliku cookie.W obydwu przypadkach istotne jest, aby poufne informacje nie zostały przekazane przezinternet w formie otwartego tekstu — każda aplikacja monitorujące pracę sieci mogłabytakie dane przechwycić. Problem można rozwiązać kilkoma metodami, a oprogramo-wanie Apache zapewnia jedną z nich. Zastosowanie dyrektywy SSLRequireSSL wymuszana jednostce klienckiej stosowanie protokołu SSL podczas próby dostępu do zasobówo określonym adresie URL. Jeżeli klient prześle żądanie w protokole HTTP, zostanie onoodrzucone z kodem statusowym 403-Forbidden. Dyrektywa może występować wewnątrzróżnych kontenerów, w tym w Directory, Location i LocationMatcS. Oto przykład:

<LocationMatch /account/login.*>44LRequire44LAuthType Basic


AuthUserFile /ścieżka/do/pliku_hasełRequire user test</LocationMatch>

Choć stosowanie opisywanej dyrektywy wydaje się dobrym mechanizmem zabezpie-czającym, ma ono pewną wadę, którą trzeba uwzględnić. Stanowi bowiem doskonałąbramę wejściową, która wymusza stosowanie protokołu SSL na klientach rozpoczy-nających pracę z aplikacją wymagającą uwierzytelnienia. Niemniej mechanizm ten niemoże funkcjonować jako brama wyjściowa. Gdy klient opuszcza witrynę zabezpie-czoną protokołem SSL i pobiera stronę z serwera HTTP wymagającego dostarczeniahasła otwartym tekstem, przeglądarka może przesłać dane uwierzytelniające z witrynyszyfrowanej w formie niezabezpieczonej. Aby usunąć tę niedogodność, administratorzyserwerów stosują dwa rozwiązania. Pierwsze z nich polega na dołączeniu opcji securedo wszystkich danych cookie przesyłanych w ramach aplikacji WWW. Dzięki temuprzeglądarka otrzymuje informację, że pliki cookie należy przesyłać jedynie do stronobjętych działaniem protokołu SSL. Druga metoda sprowadza się do zaimplemento-wania mechanizmu wylogowania, który zagwarantuje zamknięcie okna przeglądarkiprzechowującego dane uwierzytelniające. W praktycznej realizacji opisanej koncepcjipomocny jest kod JavaScript.

<INPUT onClick="javascript:window.close()" TYPE="BUTTON" IALUE="Zamknij" TITLE="Kliknij, aby zamknąć okno" NAME="CloseTindow" >

Gdy użytkownik kliknie przycisk Zamknij, na ekranie zostanie wyświetlone oknodialogowe przedstawione na rysunku 5.2.

Rysunek 5.2.Okno dialogowe

JavaScript,

które poprzedza

zamknięcie okna

przeglądarki z danymi

uwierzytelniającymi

Dyrektywy SSLVerifyClient i SSLRequire

Wymienione dyrektywy zazwyczaj występują jednocześnie, ponieważ odpowiadająza weryfikację certyfikatu klienta. Działanie dyrektywy SSLVerifyClient nie jest szcze-gólnie skomplikowane. Jeżeli ma ona wartość require, klient musi przedstawić certy-fikat, aby dostać się do chronionych zasobów. Po przesłaniu certyfikatu przez klientaserwer musi sprawdzić, jakie dane są potrzebne, aby można było zaakceptować żądaniedostępu do wymienionych zasobów. Definiowanie listy potrzebnych informacji należydo zadań parametru SSLRequire. Dyrektywa SSLRequire jest niezwykle interesująca,chociażby ze względu na elastyczność wyznaczania parametrów. Pozwala na zapisywa-nie wyrażeń logicznych, bazujących na zmiennych środowiskowych CGI i SSL. Abyklientowi zostało przydzielone prawo korzystania z zasobów, muszą być spełnionewszystkie zdefiniowane wyrażenia. Na poniższym zestawieniu znajduje się wykaz wszyst-kich zmiennych środowiskowych, które mogą być stosowane w treści dyrektywy SSL-Require.


Zmienne standardu CGI/1.d i serwera Apache:HTTP_USER_AGENT PATH_INFO AUTH_TYPEHTTP_REFERER TUERY_STRING SERIER_SOFTTAREHTTP_COOKIE REMOTE_HOST API_IERSIONHTTP_FORTARDED REMOTE_IDENT TIME_YEARHTTP_HOST IS_SUBRET TIME_MONHTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAYHTTP_ACCEPT SERIER_ADMIN TIME_HOURHTTP:nazwa_nagazwka SERIER_NAME TIME_MINTHE_RETUEST SERIER_PORT TIME_SECRETUEST_METHOD SERIER_PROTOCOL TIME_TDAYRETUEST_SCHEME REMOTE_ADDR TIMERETUEST_URI REMOTE_USER ENI:nazwa_zmiennejRETUEST_FILENAME

Zmienne związane z protokołem SSL:HTTPS SSL_CLIENT_M_IERSION SSL_SERIER_M_IERSION SSL_CLIENT_M_SERIAL SSL_SERIER_M_SERIALSSL_PROTOCOL SSL_CLIENT_I_START SSL_SERIER_I_STARTSSL_SESSION_ID SSL_CLIENT_I_END SSL_SERIER_I_ENDSSL_CIPHER SSL_CLIENT_S_DN SSL_SERIER_S_DNSSL_CIPHER_EXPORT SSL_CLIENT_S_DN_C SSL_SERIER_S_DN_CSSL_CIPHER_ALGKEYSIZE SSL_CLIENT_S_DN_ST SSL_SERIER_S_DN_STSSL_CIPHER_USEKEYSIZE SSL_CLIENT_S_DN_L SSL_SERIER_S_DN_LSSL_IERSION_LIBRARY SSL_CLIENT_S_DN_O SSL_SERIER_S_DN_OSSL_IERSION_INTERFACE SSL_CLIENT_S_DN_OU SSL_SERIER_S_DN_OU SSL_CLIENT_S_DN_CN SSL_SERIER_S_DN_CN SSL_CLIENT_S_DN_T SSL_SERIER_S_DN_T SSL_CLIENT_S_DN_I SSL_SERIER_S_DN_I SSL_CLIENT_S_DN_G SSL_SERIER_S_DN_G SSL_CLIENT_S_DN_S SSL_SERIER_S_DN_S SSL_CLIENT_S_DN_D SSL_SERIER_S_DN_D SSL_CLIENT_S_DN_UID SSL_SERIER_S_DN_UID SSL_CLIENT_S_DN_Email SSL_SERIER_S_DN_Email SSL_CLIENT_I_DN SSL_SERIER_I_DN SSL_CLIENT_I_DN_C SSL_SERIER_I_DN_C SSL_CLIENT_I_DN_ST SSL_SERIER_I_DN_ST SSL_CLIENT_I_DN_L SSL_SERIER_I_DN_L SSL_CLIENT_I_DN_O SSL_SERIER_I_DN_O SSL_CLIENT_I_DN_OU SSL_SERIER_I_DN_OU SSL_CLIENT_I_DN_CN SSL_SERIER_I_DN_CN SSL_CLIENT_I_DN_T SSL_SERIER_I_DN_T SSL_CLIENT_I_DN_I SSL_SERIER_I_DN_I SSL_CLIENT_I_DN_G SSL_SERIER_I_DN_G SSL_CLIENT_I_DN_S SSL_SERIER_I_DN_S SSL_CLIENT_I_DN_D SSL_SERIER_I_DN_D SSL_CLIENT_I_DN_UID SSL_SERIER_I_DN_UID SSL_CLIENT_I_DN_Email SSL_SERIER_I_DN_Email SSL_CLIENT_A_SIG SSL_SERIER_A_SIG SSL_CLIENT_A_KEY SSL_SERIER_A_KEY SSL_CLIENT_CERT SSL_SERIER_CERT SSL_CLIENT_CERT_CHAINn SSL_CLIENT_IERIFY


Jako przykład wykorzystania obydwu dyrektyw rozważmy aplikację, w której istniejekatalog rachunki. Do katalogu rachunki powinni mieć dostęp jedynie pracownicy działuksiegowosc. Oto stosowne dyrektywy:

<Location /klienci/rachunki>44LVerifyClient require44LRequire %{44L_CL.EMT_4_DM_O} eq "Firma .ks" \and %{44L_CL.EMT_4_DM_OU} in {"ksiegowosc"}</Location>

Dyrektywy SSLSessionCache i SSLSessionCacheTimeout

Jak nietrudno się domyślić, konieczność wymiany kluczy publicznych podczas zesta-wiania połączenia między klientem a serwerem jest przyczyną generowania dużegonarzutu transmisyjnego. Aby zwiększyć nieco wydajność mechanizmu SSL, oprogra-mowanie Apache udostępnia możliwość wykorzystywania pamięci podręcznej sesji dlakażdego połączenia. Pamięć podręczna jest wykorzystywana przez jednostki klienckie,które przekazują strumienie żądań w ramach mechanizmu KeepAlive. Czas trwaniasesji dla danego połączenia wyznacza wartość dyrektywy SSLSessionCacSeTimeout. Zale-cane ustawienie obydwu parametrów zostało przedstawione poniżej.

SSLSessionCache dbm:/ścieżka/do/apache/logs/ssl_cacheSSLSessionCacheTimeout 6d

Podsumowanie mechanizmu SSL

Nie ulega wątpliwości, że na temat modułu mod_ssl można napisać oddzielną książkę.Ilość zagadnień związanych z szyfrowaniem danych nie pozwala na opisanie ich wszyst-kich w tej publikacji. Sam moduł mod_ssl odgrywa bardzo istotną rolę w całościowymzabezpieczeniu witryny WWW. Zapewnia poufność transmitowanych danych orazudostępnia mechanizmy uwierzytelniania serwera i klienta. Z tego względu odniesieniado jego funkcji występują także w innych rozdziałach książki.

Moduł mod_rewrite

Najciekawszą cechą modułu mod_rewrite jest to, że zapewnia takie

możliwości konfiguracyjne i elastyczność pracy, jak Sendmail. Największą

wadą modułu mod_rewrite jest to, że zapewnia takie możliwości

konfiguracyjne i elastyczność pracy, jak Sendmail.

— Brian Behlendotf, Apache Group

Mimo niezliczonych przykładów i instrukcji mod_rewrite to czarna magia.

Rewelacyjna czarna magia, ale jednak czarna magia.

— Brian Moor, [email protected]


W dokumentacji Apache znajduje się informacja, że moduł mod_rewrite jest tak uni-wersalny, jak szwajcarski scyzoryk. Jego zadanie polega na odpowiednim przetwarzaniuciągów URL. To niezwykle użyteczne narzędzie działa na podstawie wyrażeń regular-nych, za pomocą których administrator systemu kontroluje dostęp klientów do stronwitryny. Skuteczność mechanizmu wynika z możliwości połączenia funkcji wyrażeńregularnych z takimi danymi, jak zmienne środowiskowe CGI i nagłówki HTTP. Liczbaparametrów konfiguracyjnych sprawia, że moduł mod_rewrite jest niezwykle skompli-kowany, a jego działanie nie zawsze jest oczywiste dla administratora. Z tego względuw tym podrozdziale zostaną zaprezentowane jedynie podstawowe elementy konfigura-cyjne, które pozwolą na zaimplementowanie pewnych szczególnych rozwiązań.

Włączenie modułu mod_rewrite

Pierwszą czynnością, jaką trzeba wykonać, jest sprawdzenie, czy kod mod_rewrite zo-stał skompilowany wraz z oprogramowaniem Apache. Ponieważ wszystkie kompilo-wane wcześniej moduły mają postać obiektów DSO, zadanie sprowadza się do sprawdze-nia, czy w pliku httpd.conf występuje dyrektywa LoadModule właściwa dla tego modułu.

# grep mod_rewrite httpd.confLoadModule rewrite_module modules/mod_rewrite.so

Wynik polecenia potwierdza włączenie modułu. Można więc przystąpić do zapisaniakilku dyrektyw, które w dalszej części książki będą wykorzystywane do zabezpieczeniaaplikacji.

Dyrektywa RewriteEngine

Dyrektywa RewriteEngine włącza lub wyłącza mechanizm mod_rewrite podczas uru-chamiania serwera. Zagadnienie nie jest jednak tak oczywiste, jak by się mogło wy-dawać. Zmieniając ustawienie RewriteEngine, warto wziąć pod uwagę dwie sprawy. Popierwsze, jeżeli w pliku konfiguracyjnym występuje znaczna liczba dyrektyw i zachodzikonieczność wyłączenia ich na czas usuwania problemów w działaniu aplikacji, nienależy poprzedzać wierszy modułu znakiem komentarza. Wystarczy zmienić wartośćdyrektywy na off i ponownie uruchomić serwer Apache. Po drugie, moduł mod_rewritemusi być implementowany w poszczególnych serwerach wirtualnych (o ile są zdefinio-wane), ponieważ jego funkcje nie podlegają dziedziczeniu. Aby włączyć mechanizm,trzeba zastosować następującą dyrektywę:

RewriteEngine On

Dyrektywa RewriteLog

Dyrektywa RewriteLog wyznacza pliki dziennika, w których mechanizm mod_rewritebędzie rejestrował wszystkie zdarzenia zachodzące w czasie przetwarzania żądań klienc-kich. Jeżeli w danej aplikacji prowadzenie dzienników jest zbędne, wystarczy tę dyrek-tywę poprzedzić znakiem komentarza lub usunąć. Niektórzy administratorzy rozwiązująproblem, podając jako plik danych wyjściowych plik /dev/null. Choć takie ustawienie


rzeczywiście powoduje usunięcie zbędnych informacji, nie wstrzymuje działania algo-rytmu generowania danych wyjściowych, co obniża wydajność serwera. Zalecana postaćdyrektywy to:

RewriteLog /ścieżka/do/apache/logs/rewrite.log

Dyrektywa RewriteLogLevel

Ustawienie RewriteLogLevel jest blisko związane z poprzednią dyrektywą. Wyznaczailość danych rejestrowanych w pliku określonym za pomocą parametru RewriteLog.Wartość 0 oznacza całkowite wyłączenie rejestracji (przy podtrzymaniu działania sa-mego mechanizmu, co zostało opisane w poprzednim punkcie). Z kolei wartość 9 i wyż-sze zapewniają zapisywanie olbrzymich ilości danych. Podczas normalnej pracy serweraparametr ten powinien mieć wartość z przedziału od 2 do 4. Dyrektywa ma następującąpostać:

RewriteLogLevel 3

Dyrektywy RewriteCond i RewriteRule

Dyrektywa RewriteCond występuje razem z dyrektywą RewriteRule i definiuje warunek,którego spełnienie oznacza wyzwolenie funkcji opisanej za pomocą ustawienia Rewri-teRule. Dyrektywa RewriteCond ma dostęp do tych samych zmiennych środowiskowychCGI, którymi operuje dyrektywa SSLRequire (opisana w poprzednim podrozdziale).Gwarantuje jej to niezwykłą elastyczność w działaniu. Dodatkowo istnieje możliwośćłączenia reguł RewriteCond z bardziej złożonymi wyzwalaczami warunkowymi. Najlep-szym sposobem na wyjaśnienie zasady działania obydwu ustawień jest analiza przy-kładu. Załóżmy, że celem konfiguracji jest zabezpieczenie witryny przed działaniemniebezpiecznej aplikacji robota, która w polu user-agent ma wpisaną wartość zly-robot.Aby wykonać zadanie, trzeba użyć następujących dyrektyw RewriteCond i RewriteRule:

RewriteCond HTTP_U4ER_AGEMT ^zly-robot$RewriteRule .* - [F]

W przypadku zestawienia połączenia z serwerem jednostka kliencka o ustalonym wcze-śniej polu nazwy aplikacji (user-agent) odbierze komunikat o błędzie 403-Forbidden.W pliku dziennika zostanie wówczas zapisana następująca treść:

192.168.26.1 - - l2d/Apr/2dd5:15:31:44 --d4ddtllocalhost.localdomain/sid#8dadd5dtlrid#81be228/initialt (2) init rewrite enginewith requested uri /192.168.26.1 - - l2d/Apr/2dd5:15:31:44 --d4ddtllocalhost.localdomain/sid#8dadd5dtlrid#81be228/initialt (4)RewriteCond: input=ozly-roboto pattern=o^zly-robot$o => matched192.168.26.1 - - l2d/Apr/2dd5:15:31:44 --d4ddtllocalhost.localdomain/sid#8dadd5dtlrid#81be228/initialt (2)forcing o/o to be forbidden


Podsumowanie modułu mod_rewrite

Moduł mod_rewrite udostępnia wiele niezwykle elastycznych funkcji. Ich wykorzy-stanie w określonych sytuacjach związanych z zabezpieczeniem serwera zostanie opisanew kolejnych rozdziałach książki — w części dotyczącej zapobiegania rozpoznaniu sie-ciowemu i implementacji systemów-pułapek.

Moduł mod_log_forensic

Co spowodowało błąd segmentacji procesu potomnego Apache? Takie pytanie częstosię nasuwa podczas przeglądania wpisów w dzienniku error_log, w którym występująwiersze podobne do pokazanych poniżej.

lSun Apr 24 d9:11:d2 2dd5t lnoticet child pid 55dd exit signal Segmentation fault (11)

Zapis bardzo ogólnikowy, prawda? Ogólnie rzecz ujmując, błąd segmentacji nie jestczymś dobrym. Może być spowodowany błędem w kodzie aplikacji, prowadzącym donatychmiastowego przerwania jej działania lub, co gorsza, próbą wykorzystania błędówserwera, prowadzącą do jego „zawieszenia”. Niezależnie od przyczyn wpisy podobnedo przedstawionych wymagają dokładniejszej analizy. Największy problem polega jed-nak na tym, że komunikatowi o błędzie segmentacji nie towarzyszą jakiekolwiek danena temat żądania klienckiego, które doprowadziło do wystąpienia błędu. Wyelimino-wanie tej niedogodności należy do zadań modułu mod_log_forensic. Jednak przed jegowykorzystaniem trzeba się upewnić, że w pliku httpd.conf znajdują się wpisy włączająceobiekty DSO mod_log_forensic i mod_unique_id.

# egrep olog_forensic|unique_ido /usr/local/apache/conf/httpd.confLoadModule log_forensic_module modules/mod_log_forensic.soLoadModule unique_id_module modules/mod_unique_id.so

Dyrektywa ForensicLog

Dyrektywa ForensicLog wyznacza jedyny parametr modułu — nazwę pliku dziennika.Stanowi ona informację dla serwera Apache, gdzie należy zapisywać dane wyjściowemodułu mod_log_forensic. Wartość parametru może się odnosić do zwykłego pliku lubprogramu, który będzie pobierał informacje. Oto podstawowa forma zapisu ustawienia:

ForensicLog /usr/local/apache/logs/forensic.log

Zasada działania modułu jest bardzo prosta. Generuje on plik dziennika, w którym każ-demu żądaniu odpowiadają dwa wpisy. Pierwszy odzwierciedla żądanie klienckie i jestoznaczony znakiem plus (+). Drugi wpis, oznaczony znakiem minus (-), zawiera odpo-wiedź serwera na dane żądanie. W obydwu wpisach występuje ten sam unikalny identy-fikator operacji. Przykładowy fragment dziennika dla udanej transakcji żądanie-odpowiedźzostał przedstawiony poniżej:

# tail -2 /usr/local/apache/logs/forensic.log+cDkrlsCoAaUAAC4xChEAAAAA|GET / HTTP/1.1|Accept:image/gif, image/x-xbitmap,image/jpeg, image/pjpeg,application/vnd.ms-powerpoint, application/vnd.ms-excel,


application/msword, application/x-shockwave-flash, */*|Accept-Language:en-us|Accept-Encoding:gzip, deflate|User-Agent:Mozilla/4.d (compatible; MSIE 5.5;Tindows NT 5.d)|Host:192.168.1.1d1|Connection:Keep-Alive-cDkrlsCoAaUAAC4xChEAAAAA

W przypadku wystąpienia błędu segmentacji w pliku dziennika nie zostanie zarejestro-wana odpowiedź serwera (ciąg poprzedzony znakiem minus). Kod źródłowy Apachejest rozpowszechniany ze skryptem powłoki check_forensic, który ułatwia automatyzacjęprocesu sprawdzania pliku error_log i wyszukiwania przypadków błędów segmentacji.Kolejny listing przedstawia wynik uruchomienia programu.

# /tools/httpd-2.d.52/support/check_forensic /usr/local/apache/logs/forensic.log+Ll@PbH8AAAEAAFYcFXkAAAAE|GET / HTTP/1.1|Accept:*t*|Accept-Language:en-us|Accept-Encoding:gzip, deflate|If-Modified-Since:Sat, 19 Feb 2dd5 16%3ad6%3ad7 GMT;length=1833|User-Agent:Mozilla/4.d (compatible; MSIE 6.d; Tindows NT 5.1; SI1; .NETCLR 1.1.4322)|Host:192.168.26.134|Connection:Keep-Alive|Transfer-Encoding:Chunked+NKqZ6X8AAAEAAFYhFuwAAAAF|GET / HTTP/1.1|Accept:*/*|Accept-Language:en-us|Accept-Encoding:gzip, deflate|If-Modified-Since:Sat, 19 Feb 2dd5 16%3ad6%3ad7 GMT;length=1833|User-Agent:Mozilla/4.d (compatible; MSIE 6.d; Tindows NT 5.1; SI1; .NETCLR 1.1.4322)|Host:192.168.26.134|Connection:Keep-Alive|Transfer-Encoding:Chunked

W treści wyniku znajdują się informacje o dwóch żądaniach, które doprowadziły doprzedwczesnego zakończenie pracy procesu. Analizując nagłówki przesyłane przez prze-glądarki klienckie, można dojść do wniosku, że są one związane z próbą wykorzystaniabłędu wcześniejszych wersji oprogramowania Apache, opisanego na stronie www.cert.

org/advisories/CA-2002-17.html. Świadczy o tym informacja o rodzaju kodowania —Transfer-Encoding: CSunked.

Moduł mod_evasive

W rozdziale 4. zostały opisane standardowe dyrektywy Apache zapewniające minimali-zację negatywnych skutków ataku typu DoS. Wśród stosownych ustawień zostały wy-mienione Timeout, KeepAlive i KeepAliveTimeout. Mimo iż zwiększają one wydajnośćpracy serwera Apache i ograniczają wpływ ataków DoS, nie gwarantują aż takiej efek-tywności, jaką zapewnia moduł zewnętrznej firmy — mod_evasive.

Do czego służy moduł mod_evasive?

Moduł mod_evasive jest obiektem Apache przeznaczonym do ochrony serwera przedatakami HTTP DoS i (lub) atakami bazującymi na metodach siłowych. Został opra-cowany przez Jonathana Zdziarskiego i jest dostępny w serwisie www.nuclearele-

phant.com. Ważnym elementem rozwiązania jest funkcja wykonywania poleceń sys-temowych w przypadku wykrycia ataku. Dzięki temu istnieje możliwość przekazaniaadresu IP atakującej jednostki do innych aplikacji zabezpieczających, takich jak lo-kalne firewalle (w celu zablokowania połączeń z danego adresu IP). Rozwiązania zaim-plementowane w module mod_evasive doskonale sprawdzają się zarówno w atakach


pojedynczych, jak i rozproszonych. Niemniej, jak w przypadku każdego ataku DoS, naj-istotniejszym czynnikiem jest tu szerokość pasma transmisyjnego oraz zajętość procesorai pamięci RAM.

Instalacja modułu mod_evasive

Zgodnie z informacjami zawartymi w rozdziale 3. implementacja modułu mod_evasivew postaci obiektu DSO wymaga użycia skryptu Apache apxs. Kod źródłowy jest do-stępny w dwóch wersjach — dla Apache 1.3 (mod_evasive.c) i dla Apache 2.0 (mod_

evasive20.c). Wykonanie poniższego polecenia powoduje skompilowanie, zainstalowa-nie i uaktywnienie modułu.

# ./apxs -cia /narzedzia/mod_evasive/mod_evasive2d.c/usr/local/apache/build/libtool --silent --mode=compile gcc -prefer-pic -DAP_HAIE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=5dd -D_BSD_SOURCE -D_SIID_SOURCE -D_GNU_SOURCE -g -O2 -pthread -I/usr/local/apache/include -I/usr/local/apache/include -I/usr/local/apache/include -c -o /narzedzia/mod_evasive/mod_evasive2d.lo/narzedzia/mod_evasive/mod_evasive2d.c && touch/narzedzia/mod_evasive/mod_evasive2d.slo...chmod 755 /usr/local/apache/modules/mod_evasive2d.solactivating module `evasive2d' in /usr/local/apache/conf/httpd.conft# grep mod_evasive /usr/local/apache/conf/httpd.confLoadHodule evasive20_module modules/mod_evasive20.so

Jak działa moduł mod_evasive?

Kod modułu tworzy i analizuje dynamiczną tablicę skrótów wyznaczanych na podsta-wie adresu IP i ciągu URI każdego odebranego żądania. Gdy serwer odbiera nowe żąda-nie, moduł mod_evasive wykonuje następujące operacje.

� Sprawdza, czy adres IP klienta znajduje się na tymczasowej czarnej liście tablicyskrótów. Jeżeli tak, klient otrzymuje informację o odmowie dostępu — błąd403-Forbidden.

� Jeżeli adres IP jednostki klienckiej nie znajduje się na czarnej liście, adres IPnadawcy i identyfikator zasobu URI zostają poddane działaniu funkcji skrótu.Uzyskana wartość stanowi klucz w tablicy skrótów. Algorytm sprawdza, czywyznaczona wartość była wcześniej zapisana w tablicy. Jeśli tak, określa liczbęwystąpień w danym przedziale czasu i porównuje z wartością progową zapisanąw pliku httpd.conf w dyrektywach mod_evasive.

� Jeżeli sprawdzenie nie prowadzi do odrzucenia żądania, adres IP jednostkiklienckiej zostaje wykorzystany do wyznaczenia kolejnego skrótu. Następnieponownie sprawdzana jest tablica skrótów. Jedyna różnica w porównaniuz poprzednio opisaną procedurą polega na tym, że nie jest uwzględniany ciągURI. Celem zadania jest sprawdzenie, czy dany klient nie przekroczyłdopuszczalnej liczby żądań w jednostce czasu dla całej witryny.


Jeżeli kryteria którejkolwiek z procedur sprawdzających zostaną spełnione, żądanie zo-staje odrzucone, a klient otrzymuje standardową informację o błędzie 403-Forbidden. Poodrzuceniu żądania połączenia z danej jednostki są ignorowane przez ustalony czas(domyślnie 10 sekund). Jeśli w tym okresie jednostka kliencka nie zaprzestanie przesy-łania żądań, blokada połączeń zostaje przedłużona. Działanie algorytm mod_evasive zo-stało zilustrowane na rysunku 5.3.

Rysunek 5.3. Algorytm mod_evasive

Konfiguracja

Domyślne ustawienia modułu mod_evasive pozwalają na uruchomienie rozszerzenia bezpotrzeby wprowadzania dodatkowych dyrektyw w pliku httpd.conf. W praktyce jednakrozwiązanie to często wymaga dostosowania do określonego środowiska — ustawieniaodpowiednich wartości progowych. Z tego względu warto umieścić w pliku httpd.conf

następujący blok dyrektyw:

<IfModule mod_evasive2d.c> DOSHashTableSize 3d97 DOSPageCount 2 DOSSiteCount 5d DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 1d</IfModule>

Każda z wymienionych dyrektyw została opisana w dalszej części podrozdziału. Więk-szość przytaczanych tu informacji pochodzi z pliku README pakietu mod_evasive

i została przygotowana przez twórców modułu.


Dyrektywa DOSHashTableSize

Dyrektywa ta określa maksymalną liczbę węzłów najwyższego poziomu w tablicy skró-tów dla każdego procesu potomnego. Zwiększanie wartości powoduje przyspieszeniedziałania mechanizmu z uwagi na zmniejszenie liczby iteracji, które trzeba wykonać,aby odczytać rekord. Kosztem jest jednak zwiększenie rozmiaru pamięci potrzebnej doprzechowywania tablicy. W przypadku mocno obciążonych serwerów WWW wartośćpowinna być zwiększana. Podana wartość parametru zostanie automatycznie zmienionana najbliższą liczbę pierwszą spośród zbioru wykorzystywanych liczb pierwszych (listawykorzystywanych liczb pierwszych jest zapisana w pliku mod_evasive.c).

Dyrektywa DOSPageCount

Dyrektywa DOSPageCount wyznacza wartość progową dla liczby żądań kierowanych dotej samej strony (lub zasobu o określonym ciągu URI) w jednostce czasu, definiowanejza pomocą dyrektywy DOSPageInterval. Gdy liczba żądań generowanych przez danąjednostkę przekroczy wartość tego parametru, adres IP klienta zostanie dodany do listyblokowanych stacji.

Dyrektywa DOSSiteCount

Dyrektywa DOSSiteCount wyznacza wartość progową dla liczby żądań wygenerowa-nych przez jednego klienta i kierowanych do tego samego procesu nasłuchu (niezależnieod strony witryny) w jednostce czasu, definiowanej za pomocą dyrektywy DOSSiteInte-rval. Po przekroczeniu wartości progowej adres IP jednostki klienckiej zostaje dodany dolisty blokowanych stacji.

Dyrektywa DOSPageInterval

Dyrektywa ta określa czas oczekiwania na przekroczenie progu DOSPageCount. Domyślnawartość odpowiada jednej sekundzie.

Dyrektywa DOSSiteInterval

Dyrektywa określa czas oczekiwania na przekroczenie progu DOSSiteCount. Domyślnawartość odpowiada jednej sekundzie.

Dyrektywa DOSBlockingPeriod

Dyrektywa DOSBlockingPeriod odpowiada za wyznaczanie czasu (w sekundach) igno-rowania żądań stacji po umieszczeniu jej na liście blokowanych jednostek. Wszystkienadchodzące w tym czasie żądania są odsyłane z informacją o błędzie 403, a odbiór każ-dego żądania powoduje rozpoczęcie ponownego zliczania czasu (np. następnych dziesię-ciu sekund). Z uwagi na każdorazowe zerowanie zegara czas blokowania nie musi byćdługi. W przypadku ataku DoS zegar będzie ciągle resetowany.


Dyrektywa DOSEmailNotify

Jeżeli dyrektywa DOSEmailNotify zostanie zdefiniowana, informacja o każdym przypadkuzarejestrowania adresu IP na czarnej liście zostanie przesłana na podany adres IP. Mecha-nizm blokad (korzystający z katalogu /tmp) zabezpiecza administratora przed ciągłymwysyłaniem listów e-mail.

Przed skompilowaniem modułu należy sprawdzić, czy zawartej w pliku mod_evasive.c

(lub mod_evasive20.c) stałej MAILER zostało przypisane odpowiednie polecenie prze-

słania poczty. Domyślnie jest to instrukcja /bin/mail –t %s, gdzie %s odpowiada do-celowemu adresowi poczty, definiowanemu w pliku konfiguracyjnym. W przypadkuużywania innego systemu operacyjnego niż Linux lub stosowania innego programupocztowego niż /bin/mail konieczne jest odpowiednie dostosowanie wartości stałej.

Dyrektywa DOSSystemCommand

Jeżeli parametrowi DOSSystemCommand zostanie przypisane polecenie systemowe, będzieono wykonywane automatycznie, po każdorazowym dopisaniu adresu IP do czarnej listy.Funkcja ta pozwala na systemowe odwołania do oprogramowania IP Filter lub do in-nych narzędzi. Mechanizm blokad (korzystający z katalogu /tmp) chroni system przedciągłymi wywołaniami. Symbol %s oznacza adres IP dopisany do czarnej listy.

Dyrektywa DOSLogDir

Dyrektywa pozwala na zdefiniowanie alternatywnego katalogu danych tymczasowych.Domyślnie mechanizm blokad wykorzystuje katalog /tmp. Jeżeli system jest dostępnydla wielu użytkowników powłoki, takie rozwiązanie nie jest najbezpieczniejsze. Wartowówczas utworzyć osobny katalog i przypisać prawa modyfikacji tylko do konta, którejest skojarzone z serwerem Apache. Następnie w pliku httpd.conf trzeba umieścić dyrek-tywę DOSLogDir z odpowiednią wartością katalogu.

Dyrektywa WhiteListing

Od czasu opracowania wersji 1.8 modułu adresy IP mogą być również umieszczane nabiałej liście, która gwarantuje, że jednostki o tych adresach nigdy nie zostaną zablo-kowane. Opcja jest przeznaczona dla programów, skryptów, lokalnych wyszukiwareki automatycznych narzędzi pobierających znaczne ilości danych z serwera. Nie należyjej jednak wykorzystywać do dodawania listy użytkowników, gdyż może to narazićserwer na atak. Wyzwolenie funkcji modułu nie jest wcale łatwe i wymaga przepro-wadzenia rzeczywistego ataku. Dlatego decyzję o tym, czy dany użytkownik powinienzostać zablokowany, czy nie, bez obaw można pozostawić algorytmowi modułu.

Aby dodać adres lub pulę adresów do białej listy, trzeba wpisać w pliku konfiguracyj-nym Apache następujące wiersze:

DO4ahitelist 127.0.0.1DO4ahitelist 127.0.0.*


Symbole wieloznaczne mogą zastępować maksymalnie trzy ostatnie oktety adresu.Nic nie stoi na przeszkodzie, żeby w jednym pliku konfiguracyjnym występowało wieledyrektyw DOSWSitelist.

Testowanie

Kod modułu mod_evasive jest rozpowszechniany wraz ze skryptem języka PERL o na-zwie test.pl. Uruchomienie programu powoduje przesłanie stu żądań o inkrementowa-nych wartościach URL do lokalnego serwera (localhost) na port 80. Częstotliwość wysy-łania żądań jest dostatecznie duża, by po około dwudziestu próbach moduł mod_evasivezablokował połączenia. Treść skryptu została przedstawiona poniżej.

#!/usr/bin/perl

# test.pl: small script to test mod_dosevasive's effectiveness

use IO::Socket;use strict;

for(d..1dd) { my($response); my($SOCKET) = new IO::Socket::INET( Proto => "tcp", PeerAddr=> "127.d.d.1:8d"); if (! defined $SOCKET) { die $!; } print $SOCKET "GET /r$_ HTTP/1.dtntn"; $response = <$SOCKET>; print $response; close($SOCKET);}

Wynik wykonania skryptu powinien być zbliżony do pokazanego na kolejnym listingu.

# ./test.plHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 2dd OKHTTP/1.1 4d3 ForbiddenHTTP/1.1 4d3 ForbiddenHTTP/1.1 4d3 Forbidden


HTTP/1.1 4d3 ForbiddenHTTP/1.1 4d3 Forbidden...

Podsumowanie modułu mod_evasive

Modułu mod_evasive okazuje się niezwykle skuteczny w zwalczaniu ataków DoSprowadzonych na małą i średnią skalę oraz w obronie przed atakami realizowanym me-todami siłowymi. Chroni on system przed nadmiernym zużyciem pasma i uruchamianiemtysięcy procesów CGI (w wyniku ataku). Cecha ta zostanie wykorzystana w kolejnychrozdziałach książki, podczas analizowania zaawansowanych mechanizmów alarmo-wych. Połączenie funkcji modułu z innymi rozwiązaniami prewencyjnymi, takimi jakblokowanie nadawców na poziomie routera (ang. router blackholing), pozwala na walkąrównież z atakami prowadzonymi na dużą skalę.

Jeżeli w danej infrastrukturze nie są zaimplementowane żadne mechanizmy obrony przedinnymi rodzajami ataków DoS, narzędzie to może być przynajmniej pomocne w wy-znaczeniu całkowitej przepustowości sieci i pojemności serwera. Niemniej bez odpo-wiednio przygotowanej infrastruktury i planu unikania ataków DoS zmasowany roz-proszony atak DoS nadal pozostaje dużym zagrożeniem.

Moduł mod_evasive został opisany także w kolejnych rozdziałach książki. Umożliwiabowiem precyzyjne przetestowanie i sparametryzowanie dyrektyw odpowiedzialnychza utrzymanie wysokiej wydajności aplikacji. Poza tym w dalszej części książki zostanąprzedstawione pewne modyfikacje kodu modułu, które podnoszą poziom zabezpieczeńserwera.

Moduł mod_security

Gdyby trzeba było wybrać jedno spośród różnych rozwiązań związanych z zabezpie-czeniem serwera, wiele osób — w tym autor książki — wybrałoby właśnie modułmod_security. Niezależnie od tego, czy konieczne jest utworzenie systemu wykrywaniawłamań WWW, czy aplikacji typu firewall WWW, moduł mod_security zawsze okażesię odpowiednim narzędziem. Pakiet mod_rewrite jest uznawany za niedoścignionerozwiązanie w zakresie przetwarzania ciągów URL. Moduł mod_security jest jego od-powiednikiem w dziedzinie zabezpieczania aplikacji WWW.

Kod mod_security został napisany przez Ivana Ristica i udostępniony na stronie www.

modsecurity.org. Firma Ristica Thinking Stone (www.thinkingstone.com) oferuje rów-nież pomoc o charakterze komercyjnym. W czasie pisania książki biblioteka mod_securitybyła dostępna w wersji 1.8.7. W dalszej części podrozdziału zostało przedstawionychwiele dyrektyw modułu, jednak najbardziej aktualnym źródłem informacji na ich tematjest dokumentacja dostępna w serwisie modsecurity www.modescurity.org/documen-

tation/index.html.


Instalacja modułu mod_security

Instalacja modułu mod_security przebiega tak samo, jak w przypadku biblioteki mod_evasive — odpowiada za nią skrypt apxs. Aby sprawdzić, czy pakiet został zainstalo-wany, wystarczy użyć polecenia grep.

# grep security_module httpd.confLoadModule security_module modules/mod_security.so

Ogólne informacje na temat modułu

Do najważniejszych cech modułu mod_security należy zaliczyć:

� Filtrowanie żądań. Nadchodzące żądania są poddawane analizie natychmiastpo dostarczeniu do systemu, przed przekazaniem do serwera WWW lub innychmodułów.

� Techniki przeciwdziałania maskowaniu ataków. W celu uniezależnieniamechanizmu od różnych technik maskowania ataków analiza żądania jestpoprzedzana normalizacją parametrów i ścieżek dostępu.

� Analiza danych protokołu HTTP. Kod modułu został dostosowanydo standardu HTTP, co umożliwia precyzyjne filtrowanie danychprzesyłanych w tym protokole.

� Analiza danych pola ładunkowego metody POST. Analiza informacjiobejmuje również dane użytkownika przekazywane do serwera za pomocąmetody POST.

� Rejestracja przebiegu komunikacji. Wszystkie przesyłane informacje(wraz z polem metody POST) mogą być rejestrowane z przeznaczeniemdo późniejszej weryfikacji.

� Filtrowanie żądań HTTPS. Z uwagi na fakt, że moduł jest osadzonyw środowisku serwera WWW, ma dostęp do danych HTTPS po ichrozszyfrowaniu.

Funkcje modułu mod_security obejmują zadania przechwytywania i analizowaniazarówno danych wejściowych (żądań klienckich), jak i wyjściowych (odpowiedziserwera). Ich celem jest wykrycie przypadków ataku lub niestandardowej wymianyinformacji. Umiejscowienie modułu mod_security w diagramie przetwarzania żądańserwera Apache zostało przedstawione na rysunku 5.4.

Na szczególną uwagę zasługuje fakt, że kod najnowszych wersji (1.9) modułu mod_security może korzystać z zerowego punktu zaczepienia (hook 0). Dzięki temu istniejemożliwość analizowania wszystkich żądań, włącznie z tymi, które normalnie są prze-twarzane przez moduł jądra Apache. Są to żądania o treści niezgodnej ze standardem,których odbiór powoduje wygenerowanie błędu 400-Bad Request.


Rysunek 5.4.Przechwytywanie

danych wejściowych

i wyjściowych przez

moduł mod_security

Opcje i możliwości modułu mod_security

W module mod_security została zaimplementowana obsługa różnych dyrektyw, któreodpowiadają za realizację wielu zadań związanych z bezpieczeństwem aplikacji. W dal-szej części rozdziału zostanie przedstawionych kilka z najważniejszych. Pozostałe sątematem rozdziału dotyczącego zapobiegania atakom. Opis dyrektyw mod_securityzostał w dużej części zaczerpnięty z doskonałego podręcznika, dostępnego w serwisiemodsecurity.org.

Dyrektywa SecFilterEngine

Ustawienie to odpowiada za włączenie lub wyłączenie modułu. Domyślnie moduł jestwyłączony. Dopuszczalnymi wartościami parametrów są: On, Off (odpowiednio włączeniei wyłączenie).

4etFilterEngine On

Dyrektywa SecFilterScanPOST

Funkcja opisywana dyrektywą jest domyślnie wyłączona (Off). Jej włączenie (On) po-woduje uaktywnienie skanowania pola danych HTTP metody POST, jeżeli zostało onozakodowane zgodnie z jednym z wymienionych typów MIME:

� application/x-www-form-urlencoded — transfer danych formularza;

� multipart/form-data — przesłanie pliku do serwera.


Zalecana postać dyrektywy to:

4ecFilter4canPO4T On

Dyrektywa SecFilterScanOutput

Dyrektywa ta pozwala na włączenie opcji analizowania danych wyjściowych, genero-wanych po przetworzeniu żądania klienckiego. Ze względu na budowę interfejsu APIApache funkcja ta jest dostępna tylko w gałęzi 2.0 oprogramowania serwera. Mimo iżjej zasada działania jest zbliżona do zadań opcji SecFilterScanPOST, definiowane przezadministratora filtry danych różnią się od tych, które są stosowane w odniesieniu doinformacji wejściowych. Zagadnienie analizowania danych wyjściowych zostało opisanew kolejnym rozdziale. Składnia dyrektywy jest następująca:

4ecFilter4canOutput On

Techniki przeciwdziałania maskowaniu ataków

Osoby przeprowadzające atak często starają się ukryć generowane przez siebie żąda-nia przed sygnaturowymi systemami wykrywania włamań. W tym celu przekształcająw pewien sposób treść żądań. Poniżej zostało opisanych kilka przykładów operacji nor-malizacyjnych wykonywanych na żądaniach przed porównaniem ich z sygnaturą ataku.

� Usunięcie wielokrotnych znaków ukośnika.

Przekształcenie ciągu // w /.

� Jednakowe traktowanie znaków ukośnika i odwrotnego ukośnika(tylko w systemie Windows).

Przekształcenie znaku \ w znak / w systemie Windows.

� Usunięcie cyklicznych odwołań do katalogu.

Skrócenie ciągu /./ do /.

� Wyszukanie i usunięcie pustych bajtów (%00).

Usunięcie pustych bajtów (null) umożliwia przeprowadzenie standardowejanalizy danych.

� Dekodowanie znaków zakodowanych w sposób charakterystycznydla ciągów URL.

Usunięcie kodowania znaków specjalnych pozwala na zastosowaniefiltrów sygnaturowych.

Szczegółowe omówienie technik maskowania ataków HTTP zostało zamieszczone w roz-dziale 9.


Specjalne wbudowane procedury sprawdzające

Kod modułu mod_security wykonuje kilka operacji weryfikacji kodowania tekstu i akcep-tuje jedynie znaki z określonych zbiorów. Poszczególne funkcje sprawdzające zostałyopisane w dalszej części punktu.

Weryfikacja kodowania URL — dyrektywaSecFilterCheckURLEncoding

Podczas formowania pola identyfikatora zasobu (URI) niektóre znaki muszą zostaćzakodowane w określonej formie. Wynika to z tego, że wiele metaznaków ma szczególneznaczenie w danym systemie i może być przyczyną błędów podczas próby interpreto-wania tekstu. Więcej informacji na ten temat zawiera dokument RFC 2396. Aby zatemznaki specjalne mogły być przekazywane do serwera WWW, trzeba je poddać kodo-waniu zgodnie z formatem przewidzianym dla adresów URL. Każdy znak może byćzastąpiony przez trzyznakowy symbol %XY, gdzie wartości XY odpowiadają szesnast-kowemu kodowi danego znaku. Liczby szesnastkowe składają się z cyfr 0 – 9 oraz litera – f. Na rysunku 5.5 znajduje się wykaz wszystkich znaków (o kodach od 0 do 255)oraz odpowiadających im kodów URL. Hakerzy i programy robaków często wykorzy-stują nadmiarowe kodowanie znaków w żądaniach. Dyrektywa SecFilterCSeckSRL-Encoding włącza mechanizm sprawdzający, czy zastosowane kodowanie jest poprawne.Powinna ona mieć następującą treść:

4ecFilterCheckURLEncoding On

Weryfikacja kodowania Unicode — dyrektywaSecFilterCheckUnicodeEncoding

Podobnie jak w przypadku opisanej wcześniej procedury sprawdzenia kodowania URLweryfikacja kodowania Unicode ma na celu ustalenie, czy użyte znaki spełniają kilkakryteriów charakterystycznych dla tego kodowania.

� Niedostateczna liczba bajtów. Standard UTF-8 pozwala na stosowaniekodowania z wykorzystaniem dwóch, trzech, czterech, pięciu lub sześciubajtów. Moduł mod_security sprawdza, czy nie brakuje jednego lub większejliczby bajtów w kodowaniu danego znaku.

� Błędne kodowanie. Dwa najstarsze bity większości znaków powinny miećtaką wartość, aby bajt miał wartość 0x80. Hakerzy wykorzystują ten faktdo wywoływania błędów w pracy dekoderów Unicode.

� Zbyt długi kod znaku. Znaki ASCII są odwzorowywane bezpośredniow przestrzeni Unicode. Są więc reprezentowane za pomocą jednego bajta.Jednak większość znaków ASCII może być również opisywana dwoma,trzema, czterema, pięcioma lub sześcioma znakami. Takie kodowanie możewywołać błędną pracę dekodera, który może interpretować dany znak jakoinną informację (a tym samym nie wykonać odpowiedniego sprawdzenia).


Rysunek 5.5. Kodowanie URL

Zalecana treść dyrektywy to:

4ecFilterCheckUnicodeEncoding On

Weryfikacja zakresu wartości bajta— dyrektywa SecFilterForceByteRange

Pojedyncze znaki mogą być zapisywane w różnych standardach — ASCII, w kodowaniuURL, kodowaniu Unicode itd. Dodatkowym sposobem notacji jest zapis dziesiętny,wykorzystujący jeden bajt (dwu- lub trzycyfrową wartość). Zestawienie właściwe dlakodowania URL (przedstawione na rysunku 5.5) można przekształcić w zestawienieznaków kodowanych dziesiętnie (rysunek 5.6).


Rysunek 5.6. Kodowanie dziesiętne — zakres bajtowy 0 – 255

Sprawdzanie zakresu wartości bajta jest istotne w przypadku wielu ataków bazującychna metodzie przepełnienia bufora. Przesyłane informacje zawierają wówczas dane binarne,których celem jest uruchomienie odpowiedniego kodu powłoki (shellcode’u). W jednymz kolejnych rozdziałów zostało przedstawione zastosowanie tej dyrektywy do obronyprzed atakami wykorzystującymi przepełnienie bufora. Zdefiniowanie dyrektywy takjak w poniższym przykładzie gwarantuje akceptację jedynie znaków z „przedziału” ogra-niczanego znakami spacji i tyldy (~).

4ecFilterForceByteRange 32 126


Reguły filtrowania

Po wykonaniu wbudowanych procedur sprawdzających moduł mod_security analizujefiltry zdefiniowane przez administratora. Kryteria dopasowania reguły do dowolnej porcjidanych są wyznaczane za pomocą wyrażeń regularnych. Sprawdzenie obejmuje nagłówkiHTTP wraz z polem danych metody POST. Oto kilka cech charakterystycznych procesu:

� Użytkownik może zdefiniować dowolną liczbę reguł.

� Reguły są zapisywane w formie wyrażeń regularnych.

� Obsługiwane są wyrażenia negowane (odwrotne).

� Każdemu kontenerowi (VirtualHost, Location itp.) można przypisać inneustawienia.

� Analiza obejmuje nagłówki HTTP.

� Analiza obejmuje dane cookie.

� Analiza obejmuje zmienne środowiskowe.

� Analiza obejmuje zmienne serwera.

� Analiza obejmuje zmienne strony.

� Analiza obejmuje pole danych metody POST.

� Analiza obejmuje dane wyjściowe skryptu.

Zasady filtrowania regulują dwie dyrektywy: SecFilter i SecFitlerSelective. Ustawie-nie SecFilter odpowiada podstawowemu (ogólnemu) filtrowi. Składnia instrukcji jestnastępująca:

4ecFilter Słowo_kluczowe lakcjat

Wartość Słowo_kluczowe jest wyrażeniem regularnym. Moduł mod_security dokonujeanalizy pierwszego wiersza żądania, poszukując w nim ciągu Słowo_kluczowe. Jeżelitaki ciąg zostanie znaleziony, opcjonalnie może zostać wykonana określona akcja (opi-sana w kolejnym punkcie). Jeżeli żadna akcja nie zostanie zdefiniowana, program wy-korzysta regułę wyznaczającą akcję domyślną SecFilterDefaultAction. DyrektywęSecFilterSelective cechuje mniejszy obszar poszukiwania. Wymaga ona precyzyjnegozdefiniowania obszaru żądania, który będzie przeszukiwany. Składania instrukcji jestnastępująca:

4ecFilter4elective Obszar Słowo_kluczowe lakcjat

Parametr Obszar może się składać z kilku nazw pól nagłówka, które powinny zostaćsprawdzone. Nazwy pól są zbliżone do tych, które są stosowane w module mod_rewrite.Choć jest również kilka dodatkowych, istotnie zwiększających efektywność modułu.W praktyce bardzo użyteczne okazują się reguły negowane, dlatego kolejny przykładdotyczy sposobu zapisu tego typu reguł. Jest on zbliżony do prezentowanego wcześniej,jednak zapis obszaru przeszukiwania i (lub) słowa kluczowego musi być poprzedzonyznakiem wykrzyknika (!).

4ecFilter4elective HTTP_U4ER_AGEMT "!Przegladarka_testowa123"


Zastosowanie takiej reguły oznacza odrzucenie żądania każdego użytkownika, który niekorzysta z aplikacji o nazwie Przegladarka_testowa123. Opisywana funkcja jest nie-zwykle użyteczna podczas implementowania bardzo złożonych mechanizmów zabez-pieczających.

Akcje

Jeżeli żądanie spełni kryteria dopasowania filtru, moduł mod_security automatyczniewykonuje pewną zdefiniowaną czynność (akcję). Akcje są podzielone na trzy kategorie:podstawowe, wtórne i sterujące.

Akcje podstawowe

Od definicji akcji podstawowej zależy to, czy po spełnieniu kryteriów filtru żądaniebędzie dalej przetwarzane, czy zostanie odrzucone. Każdemu filtrowi można przypisaćtylko jedną akcję podstawową. Jeśli zostanie zdefiniowana większa liczba akcji podsta-wowych, obowiązującą będzie ostatnia na liście. Nazwy czterech podstawowych akcjiwraz z krótkim opisem zostały wymienione poniżej.

� Deny — dyrektywa ta powoduje natychmiastowe przerwanie przetwarzaniażądania i wygenerowanie odpowiedzi o kodzie błędu 500, chyba że zostałazastosowana również dyrektywa statusu.

� Pass — pozwala na kontynuowanie procesu przetwarzania żądaniai porównywanie go z kolejnymi regułami.

� Allow — działa podobnie jak Pass, ale nie pozwala na porównywanie żądaniaz kolejnymi regułami.

� Redirect — kieruje żądanie klienckie spełniające kryteria dopasowaniapod określony adres URL.

Akcje wtórne

Akcje wtórne są wykonywane niezależnie od akcji podstawowych. Istnieje pięć tegotypu akcji.

� Status — dyrektywa ta umożliwia nadpisanie domyślnego kodu statusowegoo wartości 500. Dzięki niej administrator może przypisać odpowiedzi dowolnykod statusowy. Kod ten będzie również wykorzystany przez dyrektywyErrorDocument zapisane w pliku konfiguracyjnym httpd.conf.

� Exec — dyrektywa ta pozwala na uruchomienie programu w przypadkuzgodności żądania z regułą dopasowania. Definiując program, trzeba podaćpełną ścieżkę dostępu do pliku, bez parametrów. Można stosować zmienneśrodowiskowe CGI.

� Log — dyrektywa ta stanowi dla modułu mod_security rozkaz rejestrowaniażądań w dzienniku błędów określonym za pomocą dyrektywy ErrorLog.


� Nolog — dyrektywa ta uniemożliwia zarejestrowanie żądania w dziennikubłędów, nawet jeśli zgadza się ono z podanym kryterium.

� Pause — dyrektywa wymusza wstrzymanie generowania odpowiedzi naokreśloną wartość czasu. Okres przerwy jest definiowany w milisekundach,zatem zapis pause:5000 oznacza wstrzymanie pracy na 5 sekund. Ustawienieto przydaje się do opóźnienia działania skanerów sieciowych. Liczne testywykazują, że niektóre aplikacje skanerów w ogóle przestają działać,gdy opóźnienie osiąga pewną wartość.

Akcje sterujące

Akcje sterujące określają sposób doboru filtrów dla danego żądania. Podczas normalnejpracy po nadejściu żądania jest ono poddawane normalizacji, czyli sprawdzeniu ko-dowania URL itp. Następnie kod modułu mod_security porównuje treść żądania z ko-lejnymi regułami filtrów, zgodnie z kolejnością ich występowania w pliku httpd.conf

lub pliku włączanym. Zatem kolejność definiowania reguł jest bardzo istotna. Abyzredukować liczbę błędnie dopasowanych żądań, reguły ogólne oraz te o najszerszymobszarze zgodności powinny być wymieniane na końcu zestawienia. Filtry o precy-zyjnie ustalonych kryteriach dopasowania powinny z kolei znajdować się w począt-kowej części listy. Koncepcja definiowania reguł jest zbliżona do rozwiązań stosowa-nych w wielu aplikacjach firewall. Jednak nawet ustalony porządek analizy reguł niegwarantuje dostatecznej elastyczności mechanizmu. Dlatego funkcje modułu zostałyuzupełnione o dyrektywy cSain i skipnext.

� Chain — dyrektywa ta umożliwia łączenie reguł w łańcuchy (ang. chain)w celu definiowania bardziej złożonych testów, precyzyjnie dopasowanychdo określonego rodzaju żądań. Opcja budowania łańcuchów reguł istotniezmniejsza liczbę przypadków błędnego dopasowania żądań.

� Skipnext — dyrektywa ta wymusza pominięcie jednej lub większej liczbykolejnych reguł. Jest to następny sposób, poza budowaniem łańcuchów,na zmniejszenie liczby przypadków błędnego dopasowania żądań. Jeżeliwśród zdefiniowanych reguł występuje taka, której kryteria dopasowania sąbardzo ogólne, zawsze można ją poprzedzić filtrem o dokładniej sprecyzowanymwzorcu dopasowania, którego akcja będzie miała wartość skipnext. Aby pominąćkilka reguł, należy zastosować składnię pokazaną poniżej.

4ecFilter4elective Arg_username "jkowalski12" skipnext:24ecFilter4elective Arg_username "jkowalski1"4ecFilter4elective Arg_username "jkowalski"

Dyrektywa SecFilterDefaultAction

Dyrektywa SecFilterDefaultAction wyznacza domyślną akcję dla wszystkich reguł.Jeżeli parametr akcji konkretnego filtru nie zostanie nadpisany, obowiązuje akcja do-myślna. Ustawienie wykorzystane w kolejnym przykładzie przekazuje do modułu mod_security informację o konieczności odrzucenia żądania, zarejestrowania danych żądaniaw dzienniku błędów i wygenerowania odpowiedzi o kodzie błędu 403.

4ecFilterDefaultAction "deny,log,status:403"


Z kolei akcja zdefiniowana w sposób pokazany poniżej powoduje wstrzymanie pracy na5 sekund, a następnie przekazanie żądania do innej witryny i uruchomienie programu.

4ecFilterDefaultAction"redirect:http://192.168.1.1,pause:50000,exec:/bin/program.sh"

Weryfikacja przesyłanych plików

Moduł mod_security udostępnia opcję analizowania i zapisywania plików przesyłanychdo serwera.

� SecUploadKeepFiles — dyrektywa odpowiada za przechwytywanie plikówprzesyłanych do serwera.

� SecUploadDir — dyrektywa odpowiada za zapisanie pliku na dysku.

� SecUploadApproSeScript — dyrektywa odpowiada za uruchomieniezewnętrznego skryptu, ustalającego, czy plik zostanie zaakceptowany,czy odrzucony (np. przez program antywirusowy).

Rejestrowanie zdarzeń

W module mod_security zostały zaimplementowane niezwykle użyteczne funkcje reje-stracji zdarzeń. Działanie mechanizmu jest definiowane dyrektywą SecFilterAuditEngine,która jest niezależna od dyrektywy SecFilterEngine. Dzięki temu istnieje możliwośćrejestrowania zdarzeń bez nakładania jakichkolwiek filtrów. Takie rozwiązanie częstobywa użyteczne, gdy administrator musi zgromadzić pewną ilość informacji, zanim przy-stąpi do definiowania filtrów. Działanie mechanizmu rejestracji jest regulowane dwomaponiższymi dyrektywami.

4ecAuditEngine On4ecAuditLog logs/audyt.log

Po ich wprowadzeniu moduł mod_security będzie zapisywał dane wszystkich żądańw pliku audyt.log w katalogu dzienników pracy serwera. Format wpisów w dziennikujest następujący:

====================================================================Żadanie: adres_IP_zdalny użytkownik_zdalny użytkownik_lokalny laktualny_czastt"treść_żądaniat" status liczba_bajtówProcedura_przetwarzania: cgi-script/proxy-server/nullBłąd: Komunikat o błędzie--------------------------------------------------------------------Tiersz URL żądaniaNagłówki klienckieKod statusowy odpowiedzi serweraNagłówki odpowiedzi serwera====================================================================

Kolejny listing przedstawia przykładowe wpisy z pliku audyt.log, w których procedu-ra rejestracji została wyzwolona po spełnieniu kryteriów dopasowania filtra chroniącegoplik /etc/passwd.


====================================================================UNITUE_ID: gYI8wH8AAAEAAHYBBFEAAAAARequest: 192.168.26.1 - - l21/Apr/2dd5:1d:53:34 --d4ddt "GET /etc/passwd HTTP/1.1"4d3729Handler: cgi-script--------------------------------------------------------------------GET /etc/passwd HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.d (compatible; MSIE 6.d; Tindows NT 5.1; SI1; .NET CLR1.1.4322)Host: 192.168.26.134Connection: Keep-Alivemod_security-message: Access denied with code 4d3. Pattern match "/etc/passwd" atTHE_RETUEST.mod_security-action: 4d3HTTP/1.1 4d3 ForbiddenContent-Length: 729Keep-Alive: timeout=15, max=5ddConnection: Keep-AliveContent-Type: text/html; charset=ISO-8859-1====================================================================

Pozostałe funkcje

Moduł mod_security udostępnia administratorom jeszcze wiele bardzo użytecznychfunkcji, o których warto wspomnieć, ponieważ będą wykorzystywane w dalszych roz-działach książki.

Maskowanie serwera — dyrektywa SecServerSignature

Dyrektywa ta pozwala na zmianę informacji zwracanej przez serwer w nagłówku HTTPServer. Aby zmodyfikować treść nagłówka, wystarczy dodać odpowiedni wiersz do plikuhttpd.conf, bez potrzeby edytowania kodu źródłowego i ponownego kompilowania opro-gramowania. Oto składnia dyrektywy:

4ec4erver4ignature "Hicrosoft-..4/5.0"

Trzeba jednak pamiętać, że dodanie opcji tylko nieznacznie podnosi poziom zabez-pieczeń. W ten sposób można oszukać jedynie aplikacje analizujące „komunikaty po-witalne” serwerów. Niemniej mimo iż nie jest to idealny mechanizm zabezpieczający,zapewnia pewną ochronę przed robakami, których działanie bazuje na weryfikacjitreści pola Server.

Wewnętrzny mechanizm chroot

W rozdziale 2. zostały omówione zagadnienia związane z przygotowaniem oprogramo-wania Apache do uruchomienia w środowisku chroot. Każdy, kto próbował zaimple-mentować opisane rozwiązania, wie, że ze względu na konieczność spełnienia wszyst-kich zależności między programami realizacja zadania jest niezwykłym wyzwaniem.


Na szczęście moduł mod_security udostępnia dyrektywę, która pozwala na uruchomie-nie serwera Apache w środowisku chroot bez większych komplikacji. Łatwość imple-mentacji wynika z faktu, że funkcja chroot została wbudowana w moduł mod_securityi jest wywoływana bezpośrednio przed powołaniem procesów potomnych Apache. Wcze-śniej serwer ładuje wszystkie niezbędne biblioteki, inicjuje pracę modułów i otwierapliki dzienników. Oznacza to, że pliki nie muszą być przenoszone do specjalnie wy-dzielonych katalogów, tak jak ma to miejsce w przypadku standardowego mechanizmuchroot. Zadanie administratora sprowadza się jedynie do włączenia dyrektywy w plikuhttpd.conf.

4ecChrootDir /ścieżka/do/chroot

Plikami, które muszą być zapisywane w katalogu /ścieżka/do/chroot, są przede wszystkimpliki dokumentów witryny. Poza nimi w katalogu tym należy przechowywać wszyst-kie pliki, które mogą w jakikolwiek sposób być wykorzystywane w działaniu witryny —pliki związane z działaniem skryptów CGI czy pliki uwierzytelniania tworzone przeznarzędzia Stpasswd i Stdigest (są one odczytywane podczas realizacji każdego żądania).

Podsumowanie modułu mod_security

Po zapoznaniu się z opisem modułu mod_security nikt chyba nie ma wątpliwości, żejest on niezwykle użyteczny. Gdyby jednak takowe wątpliwości się nasuwały, zostanąrozwiane po przeczytaniu książki. Moduł charakteryzuje się niezwykłą elastycznościąidentyfikowania ataków i alarmowania o wykrytych atakach. Dla wielu osób odpowie-dzialnych za zabezpieczanie serwerów jest to podstawowe narzędzie pracy — gwaran-tuje odpowiednią ochronę serwera i spokojny sen administratora.

Podsumowanie

Celem rozdziału było przedstawienie kilku dodatkowych modułów Apache, które mogąrozwiązywać pewne problemy związane z bezpieczeństwem serwera. Celowo nie zo-stała tu przedstawiona pełna dokumentacja poszczególnych pakietów. Jest ona dostępnana stronach modułów i na tych stronach należy szukać szczegółowych danych.

Niemniej ilość przedstawionych informacji jest wystarczająca, aby Czytelnik mógł za-poznać się z przeznaczeniem i dyrektywami każdego modułu. W dalszej części książkibędą opisywane różne rozwiązania systemu zabezpieczeń, bazujące na narzędziachi koncepcjach przedstawionych w tym rozdziale.

apache. zabezpieczenia aplikacji i serwerów www

Documents