Potrzeba dostarczenia bezpiecznego serwisu, któremu można zaufać jest akceptowana bez zastrzeżeń przez organizacje, lecz jak to osiągnąć?
Użyjmy lub straćmy
Kolejnym prostym i efektywnym sposobem zabezpieczenia jest zablokowanie wszystkich usług serwerowych, których nie będziemy potrzebować. Domyślnie jest to realizowane w Windows 2003 i Linuksie, ale w starszych wersjach Windows prawdopodobnie będą uruchamiane usługi, których nie potrzebujemy. Dostępne są skrypty, dzięki którym możemy zablokować działanie niepotrzebnych usług. Za ich pomocą sprawdzimy, które serwisy są uruchomione, i spróbują też podpowiedzieć, które z nich wyłączyć.
Chrońmy naszą bazę danych
Ochrona naszego serwisu będzie bezcelowa, jeśli haker uzyska dostęp do naszej bazy danych i będzie mógł wykraść zawarte w niej dane. Jeśli do bazy danych nie będzie przypisany zewnętrzny adres IP, trudniej będzie ją zaatakować zza zapory ogniowej.
Musimy zablokować też możliwość korzystania z narzędzi do zarządzania bazą danych poprzez zaporę ogniową, choć to może być denerwujące dla twórców stron, oraz ustanowić połączenie VPN, jeśli twórcy stron muszą zdalnie łączyć się z bazą danych. Następstwem tego będzie nie używanie interfejsów administracyjnych w przeglądarce (takich jak phpMyAdmin). Informacje o exploitach w narzędziach takich jak te natychmiast rozchodzą się w społeczności hakerów i jeśli z nich korzystamy, narażamy naszą bazę danych na niebezpieczeństwo.
Serwery sieciowe i serwery aplikacji
Niewłaściwie skonfigurowany i zarządzany serwer sieciowy może być źródłem zagrożenia. Podobnie jak w przypadku systemu operacyjnego, pierwszym krokiem będzie odinstalowanie funkcji, których nie używamy. Wiele serwerów aplikacji jest dostarczanych z wersjami testowymi lub demonstracyjnymi oprogramowania. Trzeba je usunąć. Jeśli nasz serwer aplikacji jest dostarczany z narzędziem konfiguracyjnym obsługiwanym w przeglądarce, należy zablokować jego działanie lub przynajmniej zmienić hasło dostępowe do niego na dużo trudniejsze.
Celem powtarzalnych ataków skryptowych lub ataków inicjowanych przez ludzi będą poszczególne serwery sieciowe lub systemy operacyjne. Sprawdzą nagłówki http strony obsługiwanej przez aplikację, by zobaczyć czy serwer zawiera informację, która podpowiedziałaby, jakiego jest typu. Przykładowo, IIS 6.0 w nagłówkach HTTP domyślnie wysyła następujący skrypt:
{stala}Server: Microsoft-IIS/6.0{/stala}
{stala}X-Powered-By: ASP.NET{/stala}
Apache Tomcat (opensource\’owy silnik Java servlet i serwer HTTP) wysyła:
{stala}Server: Apache Coyote/1.0{/stala}
Istnieje możliwość unieważnienia nagłówka HTTP wysyłanego przez serwer. Możemy sprawić, by IIS serwer zgłaszał się jako Apache, co można uzyskać zmieniając nagłówek HTTP (za pośrednictwem narzędzi administracyjnych). To spowoduje, że skrypt lub haker ominą podatny na atak serwer (sądząc, że jest innego typu) lub daremnie będą próbować korzystać z exploitów zaprojektowanych dla innych serwerów.
Nasze nagłówki HTTP w IIS 6.0
Kolejna technika maskująca jest stosowana w przypadku rozszerzeń plików dla dynamicznych skryptów. Przemapowując pliki JSP na ASP zmylimy hakerów co do technologii z której korzystamy przy budowie serwisu. Takiej zmiany można dokonać w większości narzędzi konfiguracyjnych serwerów.
Stosujmy szyfrowanie tam gdzie to konieczne
Dane są przesyłane między serwerem i przeglądarką w seriach wiadomości tzw. żądań i odpowiedzi – przeglądarka wysyła żądanie, na co serwer wysyła odpowiedź. Format tych wiadomości jest zdefiniowany przez protokół HTTP, który z kolei zależy od TCP/IP. To podstawowa struktura internetu (chociaż HTTP równie dobrze można zaimplementować na innych protokołach).
Wymienione wiadomości zawierają HTML ze strony oraz dane z formularzy, które są wysyłane w postaci niezaszyfrowanej. Jeśli użytkownik znajdujący się między przeglądarką i serwerem będzie w stanie przejąć pakiety zawierające dane HTTP, uzyska dostęp do potencjalnie prywatnych danych, które się w nich znajdują. Jednakże te wiadomości można bez trudu zaszyfrować za pomocą SSL (Secure Sockets Layer) lub TLS (Transport Layer Security).
Szyfrowanie TLS (lub SSL) jest obsługiwane przez serwer i przeglądarkę. Można go zastosować tworząc cyfrowy certyfikat dla serwera. Certyfikaty można utworzyć korzystając z narzędzi takich jak OpenSSL, jednak owe \”samowystawiające się certyfikaty\” dostarczają ułamek tego, co oferują komercyjne firmy certyfikujące, takie jak VeriSign. Certyfikat (ang. CA – Certificate Authority) wystawiony przez podmioty uprawnione do ich wydawania będzie działać jak potwierdzenie autentyczności strony.
Unikanie hakowania URL-i
Często dynamiczne serwisy będą przeglądać dane pochodzące z baz danych według kryteriów wysłanych za pomocą żądania z wykorzystaniem kwerendy w żądaniu HTTP GET.
Np., serwis może mieć następujący URL:
{stala}http://www.mysecuresite.com/accounts/ViewAccount.do?AccountId=1234{/stala}
Ten URL zawiera identyfikator konta jako parametr w kwerendzie (1234). Taki URL może być uprawnionym sposobem autentykacji użytkownika do połączenia się ze swoim kontem. Jednak użytkownik mógłby pokusić się o wypróbowanie takiego URL-a:
{stala}http://www.mysecuresite.com/accounts/ViewAccount.do?AccountId=4321{/stala}
Jeśli nie przeprowadzono kontroli bezpieczeństwa w celu stwierdzenia, który użytkownik ma dostęp do jakiego konta, takie zastosowanie URL-a może stać się bardzo prostym sposobem na zniszczenie naszego bezpieczeństwa przez hakera.
Unikanie fałszywych postów w formularzach
Podobna podatność może zostać wykorzystana poprzez żądanie HTTP POST. Wiele serwisów stosuje ukryte pola formularzy do przechwytywania danych identyfikujących lub innych prywatnych informacji, takich jak:
{html}{/html}
Haker może zapisać lokalnie kopię formularza, a następnie zmienić identyfikator i odesłać go do naszego serwera. Przy niewystarczających zabezpieczeniach mogą się pojawić podobne naruszenia bezpieczeństwa związane z kwerendą.
Unikanie ataków typu \”SQL injection\”
Innym częstym błędem jest wadliwe przygotowanie komend SQL, zanim zostaną one wykonane. Wiele serwisów korzysta z baz danych i dynamicznie generuje treść poprzez tworzenie kwerend SQL bazujących na danych wprowadzonych przez użytkownika – za pośrednictwem formularzy lub poprzez ciągi kwerend (jak opisano powyżej). Ataki typu SQL injection wykorzystują niewłaściwie przygotowane polecenia bazy danych i umożliwiają atakującemu arbitralne wykonanie komend SQL na naszej bazie danych.
Atak polega na użyciu tak zwanych \”escape sequences\” w SQL. Jeśli nie zostały przefiltrowane przez logikę aplikacji, mogą znacząco zmienić deklarację SQL. Często pojedynczy cudzysłów jest wykorzystywany do limitowania łańcuchów w deklaracjach SQL. Wyobraźmy sobie formularz logowania, który pobiera nazwę użytkownika i hasło i uwierzytelnia użytkownika za pomocą:
{stala}\”SELECT * FROM users WHERE username = \’\” + username + \”\’\”{/stala}
Jeśli użytkownik wprowadzi:
{stala}\”a\’ or \’1=1\’\”{/stala}
do pola formularza, w rezultacie komenda SQL powinna wyglądać jak:
{stala}\”SELECT * FROM users WHERE name = \’a\’ OR 1=1\’\”{/stala}
Niestety! Zwróci użytkowników bez względu na wszystko, gdyż zawsze ocenia, czy wyrażenie jest prawdziwe i sprawia, że login jest pomijany.
Ten klasyczny atak typu \”SQL injection\” bez wątpienia jest najgorszy. Wyszukany atak może spowodować uruchomienie wielu kwerend, włączając w to aktualizację, jak też usunięcie deklaracji.
Najważniejsze w unikaniu ataków typu \”SQL injection\” jest upewnienie się, że wszystkie parametry w komendzie SQL przeszły procedury usuwania \”escape sequences\” zanim trafiły do bazy danych. Należy unikać takiego podejścia i korzystać z jednej z następujących metod alternatywnych.
Jeśli nasza baza danych je wspiera, użyjemy przygotowanych, sparametryzowanych kwerend, gdyż automatycznie usuną \”escape sequences\”.
Skorzystamy też z narzędzi w rodzaju Hibernate (http://www.hibernate.org), dzięki czemu unikniemy ataków typu \”SQL injection\” i zyskamy inne korzyści dla naszych aplikacji.
Podsumowanie
Techniki służące zapobieganiu pogwałcenia bezpieczeństwa serwisów są tak różne, jak same zagrożenia, a ich stosowanie wymaga zdyscyplinowanego podejścia zarówno architektów, programistów, jak i administratorów systemów. Czas (a przez to pieniądze), które można by spożytkować na zabezpieczanie serwisu teoretycznie są nieograniczone, trzeba jednak zachować równowagę między skalą zagrożenia i kosztami zapobiegania.
ŁATAMY LUKI BEZPIECZEŃSTWA: Tim Clark – Precedent Communication
Bezpieczeństwo serwisu to ruchomy cel. Nowe exploity pojawiają się codziennie, a radzenie sobie z nimi to praca na pełny etat. Na szczęście istnieje kilka serwisów, dzięki którym możemy być do przodu, np.:
Securiteam, http://www.securiteam.com
BugTraq, http://seclists.org/bugtraq
Skanery zabezpieczeń
Nowe dziury bezpieczeństwa są wykrywane przez cały czas. Upewnienie się, że nasze serwery sieciowe nie są podatne na ataki jest czasochłonne. Skaner zabezpieczeń przetestuje całą baterię exploitów w naszym systemie i powie, gdzie występuje podatność na atak. Naszym ulubionym skanerem jest Nessus (http://www.nessus.org), który jest bezpłatny (choć już nie na licencji GPL). Za jego pomocą przetestujemy naszą sieć pod kątem podatności na atak.
Nie ufajmy standardowym opcjom instalacji
Gdy instalujemy takie funkcjonalności, jak FTP czy SMTP, zawsze trzeba sprawdzać ustawienia, zanim zdecydujemy się je włączyć – zaniechanie tego może okazać się katastrofalne w skutkach. Przykładowo serwer FTP, który jest zainstalowany wraz z IIS6, domyślnie umożliwia anonimowy dostęp, co oznacza, że każdy może wgrywać na niego pliki.
Google jako narzędzie hakerskie, przekierowania i roboty
Ostatnio w biurze zainstalowaliśmy kamerkę internetową IP. Dzięki adresowi internetowemu można ją zdalnie kontrolować. Przeprowadziliśmy eksperyment i skopiowaliśmy część skryptową URL-a do Google\’a. Rezultat był zaskakujący. Mogliśmy zdalnie kontrolować kamery w garażach w Ameryce, na plażach w Kornwalii i wielu biurach na całym świecie, wszystko dlatego, że ludzie nie zabezpieczyli swoich kamer.
Z zasady chcemy, by wyszukiwarki wskazywały na nasz serwis. Jeśli jednak używamy standardowego CMS-a i pojawił się exploit dla niego, reklamujemy podatność na atak za pomocą Google\’a. Rozwiązaniem jest wprowadzenie właściwych zabezpieczeń oraz dodanie pliku \”robots.txt\” do wszystkich katalogów ze skryptami. Google przestanie je śledzić.
ZASOBY: Narzędzia i użytki
Snort
http://www.snort.org
Według twórców, Snort jest opensource\’owym systemem zabezpieczającym przed intruzami, który może w czasie rzeczywistym przeprowadzać analizę ruchu w sieciach IP. Za jego pomocą wykonamy analizę protokołów, wyszukamy treść oraz wykryjemy różne ataki i sondy.
Netfilter
http://www.netfilter.org
Netfilter to szkielet służący do filtrowania pakietów w Linuksie z jądrem 2.4.x i 2.6.x. Może posłużyć do wykonania zapory ogniowej przy wykorzystaniu typowego serwera, na którym zainstalowano Linuksa i Netfiltra. Pojawił się na przełomie 1999/2000 roku.
Apache
http://httpd.apache.org/docs/1.3/mod/mod_proxy.html
Apache\’a można użyć jako odwrotnego proxy (brama dla serwerów, która umożliwia jednemu
serwerowi dostarczanie treści z drugiego w sposób niewidoczny).To jest użyteczne w zamazywaniu obrazu topografii naszych serwerów i serwerów aplikacji.
Bastille Linux
http://www.bastille-linux.org
To narzędzie wspiera dystrybucje Linuksa: Debiana, Red Hata, Gentoo, Mandrake\’a, SuSE oraz Fedorę, można go zastosować w takich systemach, jak HP-UX i pełnym Mac OS X.
SPYTAJMY SIEBIE: Mathew Curie – First Choice Holidays
Nie ufajmy naszym zabezpieczeniom. Nigdy nie mówmy sobie \”Jestem bezpieczny\”.
Zadbajmy, by naszą sieć skontrolował specjalista z zewnątrz i by oglądał ją przynajmniej raz na pół roku. Bezpieczeństwo nie kończy się na zaporze ogniowej czy systemie operacyjnym. Czy funkcjonalności systemu sprawiają, że jest bezpiecznie czy też zachęcają do ataku? Jaka jest jakość danych, które zbieramy? Czy mamy pewność, że adres, na który trafiają nasze pakiety jest właściwy? Jeśli czegoś nie potrzebujemy, usuńmy to.
SZKODA, ŻE TEGO NIE WIEDZIAŁEM (gdy byłem początkującym twórcą stron)
Żałuję, że nie wiedziałem więcej o sposobach tworzenia złośliwych \”SQL injection\” oraz o XSS- -ach (atakach skryptowych typu cross-site). Ta wiedza pomogłaby mi zrozumieć konieczność podjęcia kroków zabezpieczających, bowiem nic lepiej nie uczy niż konieczność usuwania ponad tysiąca niewłaściwych reklam z forum dyskusyjnego przeznaczonego dla klientów. Jako wykładowca uniwersytecki, uczę nieopierzonych twórców stron hakowania i crackowania formularzy mailowych.
(Mog, http://www.mogmachine.com)
Każdego dnia exploity testują moje siedem domen. Nauczyłem się, że sprawdzanie błędów logów odkrywa nieudane działania tych exploitów.
(Mike Cherim, GreeBeast.com)
UNIKAJMY ATAKÓW TYPU \”MAN IN THE MIDDLE\”: Fraser Nevet – Mercurytide
Gdy to konieczne, korzystajmy z bezpiecznego połączenia Gdy dane są wysyłane przez internet, zazwyczaj wędrują przez wiele sieci oraz przechodzą przez liczne rutery i serwery. Owe urządzenia w większości nie patrzą, co przesyłają, monitorują jedynie zajętość pasma. Jednak zawsze istnieje ryzyko, że ktoś może zdobyć kontrolę nad jednym z tych serwerów i śledzić nasze przesyłki. Ten atak jest znany jako \”man in the middle\”. Kolejnym zagadnieniem jest to, czy serwis z którego korzystamy jest tym, za jaki się podaje.
Te potencjalne niebezpieczeństwa można ominąć stosując bezpieczne połączenie. URL bezpiecznego połączenia rozpoczyna się od {stala}https://{/stala}, a jeśli połączenie jest bezpieczne, na pasku przeglądarki wyświetli się ikona zamkniętej kłódki.
HTTPS korzysta z technologii szyfrowania SSL (Secure Socket Layer) do szyfrowania danych w końcowych punktach komunikacji. To oznacza, że jedynie klient i serwer mogą odszyfrować informację, a jakiekolwiek urządzenie pomiędzy nimi po prostu przepuszcza dane, nie będąc w stanie stwierdzić, co to jest. Ta technika zmniejsza ryzyko ataku typu \”man in the middle\”.
HTTPS korzysta także z podpisanych certyfikatów. Gdy znajdujemy się na bezpiecznej stronie, kliknijmy dwa razy ikonę kłódki, a ujrzymy certyfikat strony. Certyfikaty mogą wydawać jedynie uprawnione podmioty. Większość certyfikatów HTTPS jest wykorzystywana do identyfikacji serwera, ale technologia istnieje, by umożliwić użytkownikom (lub \”klientom\”) posiadanie certyfikatów identyfikujących ich na serwerze. Niektóre dowody tożsamości umożliwiają przechowywanie certyfikatu klienta na czipie, przez co umożliwiają mu bezpieczną identyfikację online.
Czyszczenie treści generowanych przez użytkowników
Jeśli umożliwimy użytkownikom wstawianie komentarzy na naszym blogu, a następnie pokazujemy je na stronie, upewnijmy się, że użytkownik nie może wstawiać surowego kodu HTML. Jeśli tego nie zrobimy, ludzie mogą, przykładowo, dodać elementy {html}