Testy penetracyjne cz. 1

W pracy każdego administratora czy osoby odpowiedzialnej za bezpieczeństwo informatyczne nie brakuje chwil zwątpienia. Czy wszystko zostało skonfigurowane tak jak powinno? Czy jesteśmy wystarczająco trudnym celem, żeby zniechęcić potencjalnego hakera? Wypadałoby to jakoś sprawdzić. Tylko jak?

Wyobraźmy sobie: nasza firma zainwestowała w kosztowny sprzęt, a my wdrożyliśmy te skomplikowane systemy. Pół biedy, jeżeli mogliśmy korzystać z pomocy tych, od których pochodzą owe narzędzia. Gorzej, jeżeli wszystko spadło na nasze barki. Przez ostatnie pół roku spędzaliśmy całe dnie na planowaniu, mozolnym konfigurowaniu i dopasowywaniu elementów do potrzeb poszczególnych działów (oczywiście każdy z tych działów ma swoje, NAJWAŻNIEJSZE w całej firmie zadania i to do niego powinni być dostosowani wszyscy pozostali).

Po tej półrocznej mordędze staliśmy się nie tylko znawcami najróżniejszych produktów, ale też specjalistami z zakresu psychologii społecznej, dyplomacji i negocjacji. Właśnie wtedy, kiedy mamy szczerą nadzieję na chociaż jeden dzień słodkiego lenistwa, w drzwiach naszego pokoju staje prezes i zadaje sakramentalne pytanie: "No i jak, panowie, jesteśmy wreszcie bezpieczni?"

Zobacz również:

Wiedząc, że dla prezesa nie ma rzeczy ciekawszej niż golf szybko zmieniamy temat - pytamy o ostatnie rozgrywki w Rajszewie i unikamy odpowiedzi. Ale wcześniej czy później będziemy musieli jej udzielić - najprawdopodobniej wcześniej.

Kilka słów o testach penetracyjnych

Odpowiedzią są dwa słowa: TESTY PENETRACYJNE. Musimy na jakiś czas przejść na drugą stronę barykady i zacząć działać jak potencjalny intruz. Takie testy możemy przeprowadzić we własnym zakresie albo zlecić wyspecjalizowanej firmie. Zarówno jedno, jak i drugie rozwiązanie ma wady i zalety.

Jeżeli przeprowadzamy testy we własnym zakresie, nie będą one do końca obiektywne. Znamy przecież topologię własnej sieci, podejrzewamy gdzie są słabsze, a gdzie silniejsze punkty, no i... wszyscy nas znają (wyjaśnienia w dalszej części). Możemy więc pominąć wiele elementów i niechcący sfałszować wyniki. Z drugiej jednak strony wiemy, pod jakim kątem sprawdzić sieć i czego obawiamy się najbardziej, a ponadto, działając samemu zaoszczędzamy na kosztach.

Zatrudnienie zewnętrznego "testera" to zdecydowanie większy obiektywizm. Osoba taka jest nieprzewidywalna, a więc w większym stopniu odwzorowuje sytuacje spotykane w rzeczywistości. Jeżeli jest fachowcem, nie ograniczy się tylko do "odpalenia" kilku programów. Ale i ten medal ma dwie strony - koszt takiej inwestycji jest znaczny.

Ze względów bezpieczeństwa najlepiej jest połączyć obydwa rozwiązania - spróbować własnych sił, a potem porównać rezultaty z niezależną ekspertyzą. Miejmy też na uwadze, że nie wszędzie i nie w każdym przypadku testy wyglądać będą identycznie. Inaczej zostaną przeprowadzone w małej firmie, a zupełnie inaczej w organizacji o międzynarodowym zasięgu, a ten artykuł nie jest instrukcją od A do Z, a jedynie wskazaniem jednej z możliwych dróg.

Jak to wszystko ugryźć?

Testy penetracyjne cz. 1

Fazy testów penetracyjnych

To zależy od tego, jak głęboko chcemy sięgnąć i jakie mamy wytyczne. Generalnie istnieją dwa podstawowe podejścia do testów. Pierwsze - black box - polega na tym, że testujący nie wie kompletnie nic o badanej firmie. Drugie - white box - zakłada znajomość topologii organizacji i jej kluczowych elementów.

Oba mają swoje wady i zalety. W przypadku testów black box należy zdawać sobie sprawę z ich czasochłonności i kosztów. Poza tym, nie każdy potrzebuje aż tak wyszukanego podejścia. Większość osób zdecyduje się na testy white box, gdyż środki finansowe przeznaczane na bezpieczeństwo są coraz niższe, a ten typ testów jest tańszy. Ponadto nie zawsze można pozwolić sobie na wystawianie organizacji na niedogodności testów przez kilka tygodni.

W idealnej sytuacji, jeśli testy obejmują swoim zakresem wszystkie elementy systemu, składają się z 6 faz (patrz rysunek). Są to działania podjęte w celu zlokalizowania potencjalnych luk. Nie należy tu jednak zapominać o pozostałych elementach, które może niewiele mają wspólnego z "brudną" robotą, ale ich brak może odbić się bardzo boleśnie na naszej skórze. Dla przykładu weźmy odpowiednie zezwolenia. Jeżeli pracujemy w dużej korporacji, nie możemy ot tak, nagle zabrać się do wyszukiwania dziur. Musimy zadbać o odpowiednie zezwolenie, wytłumaczyć czemu testy będą służyć i wreszcie, czy zagrażają one płynności funkcjonowania firmy. Z reguły wszelkie badania inwazyjne obarczone są pewnym ryzykiem. Czasem nawet proste próby skanowania mogą "rozłożyć" niektóre systemy, nie wspominając już o bardziej agresywnych technikach. Taka nadgorliwość może skończyć się nawet zwolnieniem dyscyplinarnym. A zatem bądźmy naprawdę ostrożni.

Zanim na dobre zabierzemy się do testów warto byłoby sprawdzić, czy nie istnieją jakieś udokumentowane źródła, które pomogą nam od strony metodologicznej. Jednym z najbardziej wartościowych jest Institute for Security and Open Source Methodologies (ISECOM) i dokument "Open Source Security Testing Methodology Manual". Lada moment ukaże się jego najnowsza wersja 3.0. Publikacja ta to skarbnica wiedzy nie tylko dla testera. Obejmuje swoim zakresem (oczywiście w sposób skrótowy) wszystkie kluczowe składniki bezpieczeństwa - poczynając od wskazania elementów układanki, a na przykładowych raportach i tabelach pomocnych w podsumowaniu testów kończąc.

Małe rozpoznanie czas zacząć

Po załatwieniu wszelkich formalności powoli przystępujemy do dzieła. Dlaczego powoli? Z prostej przyczyny. Chcemy uzyskać jak najbardziej miarodajne wyniki, a nie jest to możliwe bez sporządzenia precyzyjnego, czasochłonnego planu. Przeprowadzając testy podatności, musimy zmienić trochę sposób myślenia i zacząć "kombinować" jak intruz lub nawet tajny agent.

Jak to w wywiadzie bywa, kluczowe jest wstępne rozpoznanie. Jeżeli przeprowadzamy testy samodzielnie, krok ten w zasadzie możemy pominąć. Powinniśmy bowiem posiadać wszelkie informacje, jakie poszukiwane są na tym właśnie etapie. Niemniej warto wiedzieć, w jaki sposób dane te mogą być zebrane.

Zaczynamy od zupełnie "legalnych" źródeł informacji, czyli wstępnego rozeznania. Powinniśmy dowiedzieć się czegoś o profilu organizacji, jej strukturze, poznać nazwiska osób, które pracują w firmie itp. Najłatwiej takie dane zebrać, odwiedzając strony internetowe organizacji. My jednak pójdziemy o krok dalej i pobierzemy cały serwis www. Zrobimy tak, ponieważ chcemy, aby nasze działania pozostały możliwie niezauważone. Jeżeli będziemy wielokrotnie odwiedzać jedną witrynę, może to wzbudzić podejrzenia jej administratora. Ktoś może zapytać: Jak to, a niby zassanie całej witryny to nie wzbudzi podejrzeń? Otóż nie - jeżeli wykażemy się sprytem. Rozciągnięcie pobierania witryny na powiedzmy 5 godz. wzbudzi mniej podejrzeń, niż kilkugodzinne odwiedziny przez 3 tygodnie, dzień po dniu. Poza tym pobranie całego serwisu ma tę zaletę, że jesteśmy w stanie uzyskać dostęp do stron, do których nie prowadzą żadne linki, a więc przeglądając witrynę online nie mielibyśmy szans ich zobaczyć.

Do pobrania serwisu posłuży nam genialny i zarazem darmowy program wget (http://www.gnu.org/software/wget/wget.html ). Powiedzmy, że chcemy odtworzyć strukturę serwisu, ściągnąć go z podkatalogami i linkami do 5 stopnia zagnieżdżenia. Ponadto zrobimy to w nieregularnych odstępach czasu, tak aby utrudnić rozpoznanie prawdziwego oblicza naszych poczynań.

C:\wget.exe --recursive --tries=3 --wait=5 --random-wait --level=5http://www.naszafirma.pl

Teraz musimy uzbroić się w cierpliwość. W zależności od "wagi" serwisu proces kopiowania może potrwać od kilkunastu minut do kilku godzin. A więc: wdech, wydech - cierpliwość to przecież wielka cnota.

Jeżeli jednak chcemy trochę więcej klikać i lubimy być "trendy", wówczas możemy użyć broni o wdzięcznej nazwiehttp://www.google.com i również wyszperać sporo użytecznych informacji. Na przykład wpisując w oknie wyszukiwania "telefon site:naszafirma.pl", możemy zebrać wszystkie numery telefonów pojawiające się na stronie naszafirma.pl.

Mając już cały serwis WWW, możemy spokojnie przeglądać go offline i szukać potrzebnych informacji. W tym czasie przejrzyjmy nagłówki stron. Być może znajdziemy tam podpis oprogramowania, które posłużyło do stworzenia serwisu, lub nazwę firmy utrzymującej serwis czy inne tego typu informacje. Dzięki tym wskazówkom być może uda nam się ustalić, na jakim rodzaju serwera WWW działa strona (np. Apache, IIS itp.), a może nawet na jakiej platformie. Jeżeli po przejrzeniu struktury pobranego portalu znajdziemy tam pliki .cgi, możemy z dużą dozą prawdopodobieństwa stwierdzić, że serwer działa pod Unixem; a w przypadku plików .aspx, że pod Windowsem itd.

Zatem już po zawartości samego serwisu możemy wyciągnąć sporo wniosków. Wszystko zależy od naszej wiedzy i dociekliwości. Na przykład, jeżeli uda nam się ustalić, że portal działa na IIS, możemy zacząć wyszukiwać luki (a w zależności od wersji może być ich naprawdę dużo). Dodatkowo, przeglądając adresy poczty e- mail wymienione na stronie z łatwością zrozumiemy klucz, według którego tworzone są konta pocztowe w organizacji.


TOP 200