Sieciowe serwery i serwisy to numer jeden na liście ataków hakerów. Postawienie FTP-a lub serwera pocztowego oznacza, że codziennie zapora ogniowa będzie blokować kilka prób włamania do każdego z nich. Dopiero co skonfigurowany serwer będzie obiektem kilkuset jednoczesnych prób w tej samej ramce czasowej. Ochrona serwisu musi być więc naszym priorytetem.
Każdego miesiąca hakerzy niszczą tysiące stron za pomocą exploitów w oprogramowaniu sieciowych serwerów lub dzięki \”szczęśliwemu\” odgadnięciu hasła. Większość zniszczeń nigdy nie trafia na nagłówki gazet, jednak w ciągu ostatnich lat stało się to udziałem wielu znaczących serwisów. W Stanach Zjednoczonych członkowie CIA, którzy kiedyś przyszli do biura odkryli, że główna strona ich serwisu dumnie wita gości w Centralnej Agencji Głupoty (Central Stupidy Agency). W czasie skandalu z Moniką Lewinsky celem ataku stała się też strona Billa Clintona. Haker przerobił wszystkie hyperlinki na stronie i przekierował je na serwis Playboya.
Aby chronić się przed niszczącymi atakami, musimy być pewni, że na serwerze są zainstalowane najnowsze łaty (lub dostawca usług hostingowych może dostarczyć wiarygodnego dowodu, że robi to regularnie, jeśli nie prowadzimy własnego serwera). Konieczne jest także regularne tworzenie kopii zapasowych, tak by można było wszystko odtworzyć z dobrej kopii, gdyby było to konieczne. Pamiętajmy o kopiach zapasowych nie tylko statycznych stron HTML, ale także treści generowanych z baz danych, takich jak tabele MySQL. Zachowajmy ścisłą kontrolę nad hasłami, z których korzystamy przy pracach konserwacyjnych na serwerze. Nikt poza administratorami nie powinien mieć dostępu do rdzenia serwera.
Każda z osób, które zapełniają strony treścią, powinna mieć własne hasło dla zwiększenia odpowiedzialności, a każde konto powinno umożliwiać użytkownikowi dostęp jedynie do \”jego\” części serwisu i żadnej innej. Jeśli mamy własny serwer sieciowy, chrońmy go firewallem. Dostęp poprzez FTP do uploadu nowych plików powinien być ograniczony do wybranych adresów IP i dostępny jedynie ze znanych lokalizacji (także określonych komputerów lub przynajmniej powinien zostać ograniczony dostęp z innych komputerów, niż pozwala firma). Pamiętajmy o zmianie lub zablokowaniu haseł w przypadku, gdy pracownik odejdzie z firmy lub zmieni stanowisko).
Jeśli korzystamy z systemu zarządzania treścią, by ułatwić aktualizację poprzez formularze html, upewnijmy się, że system administrowania jest zabezpieczony przez cały czas. Napotkaliśmy już wiele systemów, gdzie każdy, kto trafił, powiedzmy na {stala}http://www.mywebsite.com/admin{/stala}, natychmiast uzyskiwał dostęp do menu administratora, bez jakiejkolwiek prośby o wprowadzenie hasła.
Podstawowe uwierzytelnienie HTTP
Przypisanie nazwy użytkownika i uwierzytelniającego hasła do jednego lub kilku obszarów serwisu nie jest trudne. Nie wymaga umiejętności programowania. Po prostu tworzymy dwa specjalne pliki tekstowe i wgrywamy je do folderu lub katalogu, który zamierzamy chronić. W jednym pliku znajdują się niezbędne komendy umożliwiające uwierzytelnienie, w innych są przechowywane ważne nazwy użytkowników i hasła.
Gdy je ustanowimy, każdy, kto spróbuje zobaczyć stronę objętą ochroną, napotka wyskakujące okienko żądające wprowadzenia nazwy użytkownika i hasła. Ten mechanizm funkcjonuje we wszystkich przeglądarkach i jest wspierany przez większość znanych serwerów sieciowych, włączając w to Apache\’a i IIS. Ta funkcja jest znana jako podstawowe uwierzytelnienie HTTP (ang. Basic HTTP Authentication).
Aby z niej skorzystać, zacznijmy od utworzenia pliku .htaccess, dzięki któremu możliwe jest korzystanie z uwierzytelnienia. Plik powinien wyglądać tak:
AuthUserFile /home/oursite/public html/staff/.htpasswd AuthName \"Protected Area
for Staff\" AuthType basic require valid-user .
Wgrajmy go do katalogu, który chcemy chronić. Zwróćmy tylko uwagę na kilka spraw. Plik musi się nazywać .htaccess (nie zapomnijmy o rozpoczynającej nazwę kropce). Może okazać się, że nasz pecet nie zezwoli na utworzenie pliku o takiej nazwie. Wtedy nadajmy mu bardziej oczywistą nazwę, np. htaccess.txt, i za pomocą programu do obsługi FTP zmieńmy nazwę, gdy już wgraliśmy go na serwer. Pierwsza linia w pliku, która zaczyna się od AuthUserFile, musi zawierać ścieżkę do pliku .htpasswd (który krótko omówimy).
Konieczna będzie zmiana części {stala} /home/oursite/public html/staff/{/stala} na właściwy zapis odpowiadający ustawieniom serwera. W tym przykładzie chronimy katalog o nazwie staff. Linia AuthName umożliwia określenie tekstu, który przeglądarka będzie wyświetlać w oknie dialogowym.
Po utworzeniu pliku {stala}.htaccess{/stala} możemy teraz założyć plik, w którym będą przechowywane nazwy użytkowników i hasła. Nazwijmy go .htpasswd (możemy przemianować go w ten sam sposób, jak plik {stala}.htaccess{/stala}) i umieśćmy go w tym samym katalogu, co chronione strony i plik {stala}.htaccess{/stala}. Oto przykład pliku:
.htapasswd: holly:CERvekVZDDINw
olivia: LKmimHQzZX5wE.
Znów zwróćmy uwagę na kilka spraw. Każde wejście składa się z nazwy użytkownika (holly i olivia w tym przypadku) oraz hasła oddzielonego dwukropkiem. Każda para nazwa użytkownika – hasło musi być umieszczona w oddzielnej linii w pliku. Hasło trzeba wprowadzić w specjalnym zaszyfrowanym formacie, stąd raczej dziwnie wyglądający tekst w powyższym przykładzie.
Najprostszym sposobem znalezienia zaszyfrowanej formy hasła jest odszukanie w sieci generatora htpasswd online – powinniśmy znaleźć kilka serwisów umożliwiających konwersję. W powyższym przykładzie wprowadzono nazwę użytkownika holly i hasło Gremlin do generatora, który przetworzył to na formę: holly:CERvekVZDDINw, gotową do skopiowania i wklejenia do pliku .htpasswd. Korzystanie z generatorów online jest wystarczająco bezpieczne, gdyż generator nie wie na którym serwisie będą one wykorzystywane.
Atak siłowy
Choć uwierzytelnienie za pomocą htaccess/htpasswd jest niewiarygodnie wygodne, jedynym problemem jest atak siłowy (ang. brute force), podczas którego haker korzysta z programu próbującego tysiące haseł na minutę. Programy do przeprowadzania tego rodzaju ataków na sieciowe serwery można pobrać z internetu – jednym z nich jest Brutus. Zahartowanie uwierzytelnienia htaccess wymaga stosowania dodatkowego programowania i jest zalecane.
Jedną z metod jest zapisywanie adresu IP każdej osoby, która usiłuje się połączyć ze stroną, oraz blokowanie każdego użytkownika, który próbował, powiedzmy 10 razy bez powodzenia, zalogować się z tego samego adresu IP w czasie ostatnich 24 godzin. Jeśli nasz serwis przygotowano w języku skryptowym, takim jak PHP, i korzysta on z bazy danych, takiej jak MySQL, nie jest to trudne.
Inna opcja, która nie wymaga bazy danych, polega na użyciu komendy sleep PHP, aby wprowadzić krótkie opóźnienie między wprowadzeniem przez użytkownika nazwy i hasła a udostępnieniem lub zablokowaniem połączenia ze stroną. Pięciosekundowe opóźnienie nie powinno być dużym utrudnieniem dla legalnych użytkowników, ale przeprowadzanie ataków siłowych stanie się niemożliwe.
PHP/MySQL
Programy, które działają w serwisie korzystającym z bazy danych, są podatne na ataki hakerów, którzy mogą (i robią to) wykorzystać luki w tych programach w celu uzyskania nieautoryzowanego dostępu do serwisu. Stworzenie podręcznika ze szczegółową procedurą jak utworzyć bezpieczne serwisy oparte na bazach danych jest niemożliwe. Wynika to z faktu istnienia wielu kombinacji oprogramowania serwerowego (Apache, Windows IIS itd.), silników baz danych (Oracle, MySQL, Microsoft SQL Server itd.) oraz języków programowania (PHP, Perl, ASP, Python i wielu innych).
Najbardziej popularnym środowiskiem programistycznym jest język PHP i system bazodanowy MySQL. Starajmy się przechowywać poufne informacje z dala od plików PHP. Zazwyczaj program PHP działa, gdy ktoś łączy się z adresem gdzie się znajduje (na przykład {stala}http://www.yoursite.com/catalogue.php{/stala}), gdzie program PHP generuje kod HTML, który użytkownik może wyświetlić w przeglądarce.
Użytkownicy nigdy nie powinni zobaczyć kodu PHP, choć hakerom sporadycznie się to udaje. Jeśli, jak robi większość programistów, pomiędzy plikami PHP trzymamy niezbędne hasła dostępu do bazy danych MySQL, wówczas cała zawartość bazy danych jest stale narażona na atak.
Aby uniknąć takiej sytuacji, umieśćmy hasło dostępowe do bazy danych w pliku z rozszerzeniem .inc.php (np. Dbaccess.inc.php), wgrajmy je do katalogu, który jest powyżej katalogu głównego z dokumentami serwera sieciowego (i przez to jest niedostępny dla internautów), i odwołajmy się do pliku w kodzie PHP za pomocą komendy require once. W ten sposób nasz kod PHP bez trudu może przeczytać plik, ale dla hakera będzie to o wiele trudniejsze.
Upewnijmy się, że register globals jest wyłączone w naszej instalacji PHP. To domyślne ustawienie w wersji 4.2 i wyższych PHP. Z włączonym register global hakerzy będą w stanie uzyskać dostęp do treści dowolnej zmiennej w naszym kodzie PHP. Podobnie nabierzmy nawyków uruchamiania wszystkich programów PHP z poleceniem error reporting (E ALL), aby zagwarantować sobie zgłaszanie maksymalnej liczby komunikatów o błędach i słabościach bezpieczeństwa w naszym kodzie.
Wiele firm korzysta z gotowych programów w PHP w swoich serwisach. Te programy, znane jako Systemy Zarządzania Treścią, można bezpłatnie pobrać z takich stron jak http://www.opensourcecms.com, a najbardziej znane z nich to Mambo, Drupal i Nuke. Jeżeli chcemy na stronie zamieścić forum dyskusyjne, także możemy skorzystać z bezpłatnego oprogramowania, którego dobrym przykładem jest phpBB.
W przypadku korzystania z gotowego już forum lub oprogramowania CMS, bez względu na to, czy jest to open source czy wersja komercyjna, nie zapomnijmy, by była ona zawsze aktualna i zaopatrzona w najnowsze łaty. Jeśli łatę bezpieczeństwa wydano dla konkretnego oprogramowania, którego używamy, hakerzy w kilka minut przeskanują cały internet w poszukiwaniu instalacji tego oprogramowania, które nie ma jeszcze założonych łat, i przez to jest otwarta na exploity.
Pamiętajmy też, by usunąć wszystkie pliki instalacyjne, gdy już skonfigurujemy program. Jeśli tego nie zrobimy, hakerzy będą mogli ponownie uruchomić instalację i wymazać zawartość bazy danych. Jeśli sytuacja wymaga udzielenia dostępu do plików z danymi podczas instalacji, nie zapomnijmy o cofnięciu uprawnień do statusu tylko do odczytu, gdy już zakończymy konfigurację.
Jeśli oprogramowujemy stronę WWW, która wymaga logowania się użytkowników z wykorzystaniem nazwy i hasła, zatroszczmy się o to, by trudno było obejść sposób uwierzytelniania. Gdy użytkownik podaje ważne dane, wykorzystajmy ciasteczka lub zmienne sesji, by oznaczyć, że miało to miejsce, i sprawdzajmy ten zapis za każdym razem, gdy użytkownik próbuje uzyskać dostęp do chronionej strony.
Nie zakładajmy, że skoro użytkownik poprawnie zalogował się, gdy po raz pierwszy zobaczył naszą stronę, jest nadal zalogowany, gdy próbuje dostać się na inną naszą stronę. Mógł trafić na nią poprzez wyszukiwarkę, a nie stronę z ekranem logowania.
Nigdy nie stosujmy kodu po stronie klienta, takiego jak JavaScript lub ukrytych pól formularza dla funkcji związanych z bezpieczeństwem, takich jak potwierdzanie hasła. W przeciwieństwie do PHP, gdzie normalnie kod nie jest widoczny dla użytkownika, kod po stronie klienta może zostać podejrzany przez każdego, kto kliknie \”Źródło strony\” w swojej przeglądarce.
Regularnie zapisujmy kopie bezpieczeństwa plików ze skryptami PHP i nie przechowujmy kopii na sieciowym serwerze. Pamiętajmy też o wykonaniu kopii bezpieczeństwa plików SQL. Korzystajmy z oprogramowania w rodzaju PHPMyADmin lub mysqldump, które wykonuje kopie w formacie ASCII. Nigdy nie kopiujmy po prostu plików binarnych, gdyż nie będą one dostępne, gdy przeniesiemy się na inny serwer bazodanowy, serwer sieciowy lub system operacyjny. Więcej porad znajdziemy na stronie Open web Application Security Project pod adresem http://www.owasp.org. Serwis jest bezpłatny i regularnie aktualizowany.
