W ramach projektu HoneySpider Network, poza opracowywaniem sposobów rozpoznawania złośliwych bądź podejrzanych stron WWW przez klienckie honeypoty, pojawiła się konieczność rozpoznawania, czy badany URL należy do sieci fast-flux czy nie. Decyzja taka wpływa na sposób badania takiego URLa – zdarzają się bowiem przypadki, w których część komputerów sieci fast-flux przekierowuje nie na złośliwe strony, ale na strony nieszkodliwe. Może się też zdarzyć, że IP zwracane w odpowiedzi na zapytanie o domenę w danym momencie są nieosiągalne, co powoduje, że pająki sieciowe nie zbadają prawidłowej strony.

W NASK opracowano więc narzędzie, pozwalające rozpoznać czy dana domena należy do sieci fast-flux czy nie. Narzędzie umożliwia sprawdzenie dużej ilości domen w krótkim czasie, tak aby wykorzystywany algorytm mógł zostać dodany do pająków sieciowych opracowywanych w ramach projektu. Zaimplementowano własną metodę, bazując na uwagach zawartych w Honeynet Project: Know Your Enemy: Fast-Flux Service Networks. Metodę zweryfikowano empirycznie oraz porównując z metodą opracowaną przez Thorsten’a Holz’a. W porównaniu do wspomnianej metody, algorytm opracowany w NASK umożliwia uzyskanie szybszych wyników, bez konieczności zapytań do zewnętrznych serwisów whois przy zachowaniu podobnych wskaźników skuteczności.

Zbadaliśmy URLe przychodzące w spamie do skrzynki pocztowej cert@cert.pl oraz spamtrap’ów CERT Polska. Każdy URL przychodzący w spamie wysłany był do pająka sieciowego, który badał stronę i ściągał kolejne URLe z badanych stron. W przypadku spamu z ostatnich dni na cert@cert.pl, wydobyto bezpośrednio z maili 2748 unikalnych URLi (2106 unikalnych domen). Po zapytaniach pająków o te URLe uzyskaliśmy w sumie 2664 unikalnych domen. Z tych domen:

• 1965 zostało sklasyfikowanych jako nie należących do fast-flux

• 455 już się nie resolvowało

• 244 okazało się być domenami typu fast-flux

W przypadku testu spamu ze spamtrap’ów, wydobyto bezpośredniu z maili 2840 unikalnych URLi (2159 unikalnych domen). Po zapytaniu pająków o te URLe uzyskaliśmy w sumie 2473 unikalnych domen. Z tych domen:

• 1796 zostało sklasyfikowanych jako nie należących do fast-flux

• 550 już się nie resolvowało

• 127 okazało się być domenami typu fast-flux

W pierwszym przypadku ilość domen fast-flux kształtowała się na poziomie 9,2%, w drugim 5,1%. Oznaczo to, że fast-flux jest częstym zjawiskiem wykorzystywanym w spamie, uzasadniając tezę, że aby skutecznie analizować URLe ze spamu, kliencki honeypot musi być w stanie poprawnie rozpoznawać takie domeny.

Od połowy września 2008 roku w sieci obserwowane są skanowania w poszukiwaniu niezabezpieczonych bramek PSTN, które umożliwiają zestawienie połączenia pomiędzy siecią VoIP a publiczną siecią telefoniczną PSTN. Takie niepoprawnie skonfigurowane bramki PSTN umożliwiają atakującemu wykonywanie połączeń telefonicznych do abonentów publicznej sieci na koszt właściciela takiej bramki.

Atak polega na wysyłaniu (najczęściej na port 5060/UDP) pakietów zawierających żądanie INVITE protokołu SIP. Żądanie takie w zamierzeniu służy do inicjowania połączeń głosowych. Atakujący może dowolne sfałszować nagłówki żądania SIP (takie jak numer wywołujący czy identyfikator połączenia), jednak adres IP atakującego w opisywanym scenariuszu nie jest fałszowany, aby umożliwić mu otrzymanie odpowiedzi (a tym samym informacji o powodzeniu ataku). Gdy taki pakiet dotrze do publicznie dostępnej bramki PSTN, nastąpi przekazanie połączenia do publicznej sieci PSTN. Co ciekawe, gdy taki pakiet trafi do telefonu VoIP, nastąpi wywołanie (to właśnie dzwoniące telefony VoIP były jednym z symptomów, dzięki którym zauważono opisywane skanowania). Podejrzane żądania INVITE zostały także zauważone przez system wczesnego ostrzegania ARAKIS – pierwsze obserwacje pochodzą z 14 września 2008 roku. Dnia 2 października nastąpił znaczny wzrost takiej aktywności, co doprowadziło do wyzwolenia reguły systemu wykrywania włamań Snort “VOIP INVITE Message Flood“. Tak przedstawia się przykładowy pakiet protokołu SIP zarejestrowany na porcie 5060/UDP zawierający podejrzane żądanie INVITE:

Aby zapobiec tego typu atakom, administratorzy bramek PSTN lub serwerów proxy SIP powinni wyeliminować możliwość nieautoryzowanego dostępu do tych usług. Zabezpieczenie powinno polegać na umożliwieniu korzystania z bramek tylko wybranym adresom IP (jeśli oprogramowanie bramek nie udostępnia takiej funkcjonalności, powinien zostać zastosowany firewall) lub tylko uwierzytelnionym użytkownikom. Centralki PBX (np. Asterisk) powinny zostać skonfigurowane w taki sposób, aby odrzucać nieautoryzowane żądania połączeń do sieci PSTN.

Więcej szczegółów w artykule Analysis of a VoIP Attack.

Niniejszym wpisem rozpoczynamy cykl artykułów opisujących interesujące zagadnienia związane z projektem HoneySpider Network. Będą one zawierać charakterystykę problemów, jakie napotkaliśmy przy rozwoju tego klienckiego honeypota, jak również kwestie popularnych ataków na przeglądarki WWW i technik wykorzystywanych przez cyberprzestępców.

Podczas wdrażania modułu HSN o niskim poziomie interakcji (bazującym na robotach emulujących przeglądarki) zaistniała konieczność szybkiego pozbycia się plików ściągniętych przez te roboty. Jak się okazało, kasowanie dziesiątek milionów małych plików rozproszonych po skomplikowanej strukturze katalogów wcale nie jest procesem szybkim – czas takiej operacji przeprowadzonej na systemie plików EXT3 był liczony w godzinach. Stąd zaistniała konieczność przeprowadzenia testów wydajnościowych popularnych systemów plików, których wyniki prezentujemy poniżej.

Rozpatrywaliśmy 5 popularnych systemów plików dostępnych domyślnie w większości dystrybucji linuksowych: EXT3, XFS, ReiserFS, JFS, EXT4Dev. Zaprojektowany test polegał na utworzeniu na partycji z testowanym systemem plików 1 miliona różnej wielkości plików rozproszonych po 1000 katalogów, a następnie zmierzeniu czasu ich kasowania za pomocą polecenia rm. Aby uzyskać powtarzalność testu, na każdym systemie plików tworzona była identyczna struktura plików i katalogów.

W celu upodobnienia takiego zbioru plików do ściągniętych przez roboty stron internetowych, tworzone pliki cechowały się różnym rozmiarem rzędu kilkudziesięciu kB (średnio 37kB). Cała struktura plików miała w sumie rozmiar około 38 GB (w zależności od specyfiki konkretnego systemu plików). Uzyskano następujące czasy kasowania:

• EXT3: 2667 s
• XFS: 5345 s
• ReiserFS: 222 s
• JFS: 4840 s
• EXT4Dev: 3764s

Uzyskane wyniki pokazują bardzo wyraźną przewagę ReiserFS pod względem szybkości kasowania, co potwierdza powszechną opinię o dobrych wynikach tego systemu plików przy operacjach na małych plikach (zwłaszcza do 4 kB). Pozostałe systemy plików mają dość zbliżone wyniki (rzędu kilkudziesięciu minut), choć można zauważyć nieco lepsze rezultaty EXT3. Niestety najbardziej obiecujący pod względem wydajności ReiserFS obecnie nie jest już wspierany (o tym dlaczego nie jest już wspierany zainteresowani mogą przeczytać na przykład tutaj).

Nie zdecydowaliśmy się na testy jego następcy, systemu Reiser4, gdyż jest on we wczesnej fazie testowej i nie wszedł jeszcze do stabilnej wersji jądra Linuksa. Dylemat między szybkim lecz niewspieranym ReiserFS a zdecydowanie wolniejszymi pozostałymi systemami plików doprowadził do powstania odmiennej koncepcji – na ściąganą przez roboty zawartość stron internetowych przeznaczona byłaby cała partycja, a czyszczenie odbywałoby się przez ponowne utworzenie wybranego systemu plików (za pomocą mkfs). Taka operacja jest stosunkowo szybka – w zależności od konkretnego systemu plików trwa od kilku do kilkudziesięciu sekund i nie zależy od ilości plików zgromadzonych na partycji.