Igła w stogu siana

Znalezienie ruchu związanego ze złośliwym oprogramowaniem może być kluczem do wykrycia nieznanych dotąd zagrożeń spowodowanych przez botnety.

Poznaj własną sieć

Ruch generowany przez złośliwe oprogramowanie różni się od tego, który powstaje w normalnych warunkach pracy aplikacji w firmie. Aby móc wykrywać anomalie, należy:

- znać ścieżki ruchu związane z dozwoloną transmisją danych w firmie;

- znać protokoły używane w firmie i ścieżki dla każdego z nich;

- określić dopuszczalne typy plików dla każdej podsieci i ścieżki;

- rozpoznać ruch, biorąc pod uwagę geolokalizację - jaki on jest i w którym kierunku odbywa się transmisja;

- ustalić, jak te zależności zmieniają się w przypadku ruchu pożądanego i tego, który trzeba wykryć.

Botnety, czyli sieci stworzone z komputerów, nad którymi przejęto kontrolę za pomocą złośliwego oprogramowania, od kilku lat stały się częścią zjawisk występujących w Internecie. Ponieważ cyberprzestępcy zauważyli, że co trzecia maszyna w botnetach jest komputerem firmowym, pojawiły się specjalizowane botnety, które kradną informacje z firm. Problem polega na tym, że wykorzystują one specjalne oprogramowanie, niewykrywalne dla IPS-ów ani antywirusów. Zagadnienie wykrycia zagrożenia w firmowym środowisku sprowadza się do szybkiej reakcji, przy czym sygnatury kodu są bezużyteczne, niezbędne jest inne podejście, bazujące na ruchu.

Drugie dno HTTP

Najpopularniejszym protokołem wykorzystywanym w sieci jest HTTP. W jego sesjach można się spodziewać obiektów HTML, obrazów (gif, jpg, png itp.), innych plików (pdf, exe, doc) oraz nagłówków klientów i serwerów. Gdy przyjrzeć się nagłówkom związanym z żądaniem GET, można zauważyć, że zazwyczaj pole Host: w normalnym żądaniu zawiera adres DNS, podczas gdy malware często korzysta z wyrażeń numerycznych. To samo dotyczy żądania POST, przy czym w tym drugim zdarzają się żądania bez wyrażenia Content-Type, a także powtarzalne ciągi znaków.

Stąd wynika, że podejrzany ruch rzadko ma nagłówki typowe dla poprawnych klientów (na przykład przeglądarki internetowej).

Co, gdzie, którędy

Aby stwierdzić, że ruch naprawdę jest podejrzany, należy stosować założenia, takie jak:

- przy analizie protokołu X można się spodziewać zawartości Y i Z;

- ruch związany z protokołem A odbywa się na porcie B (i vice versa);

- przy analizie protokołu Z nigdy nie występują obiekty A, B i C;

- te same reguły stosuje się do wszystkich protokołów.

Eddie Schwartz, CSO w firmie RSA, mówi: "Cechą charakterystyczną złośliwego oprogramowania jest jego umiejętność ukrywania się na stacjach roboczych. Malware robi to gorzej w przypadku ruchu sieciowego. Im więcej wiemy na temat popularnych protokołów, tym lepiej będziemy mogli wykrywać podejrzaną aktywność w firmowej sieci".

Jednym z etapów analizy ex post jest sprawdzenie domeny, do której odbywa się podejrzany ruch. W tym celu można skorzystać z narzędzia whois oraz serwisu robtex. Do rozpoznawania domen związanych z dystrybucją złośliwego oprogramowania można użyć różnych list, takich jak: BrowserDefender, SURBL czy Google Diagnostic, a także serwisu URLVoid.

Badania cięższego kalibru

Od nieregularności związanych z protokołem i domeną, ciekawszych informacji dostarcza analiza zawartości. Celem takiej analizy jest detekcja zagrożeń bez znajomości a priori, łatwa integracja, niski odsetek fałszywych alarmów i wysoka skuteczność detekcji.

"Do analizy ruchu można z powodzeniem użyć narzędzia NetWitness Investigator, które jest dostępne za darmo. Jest to dobre narzędzie analityczne, które umożliwi wykrywanie anomalii w

sieci" - informuje Eddie Schwartz.

Aby wykryć pobieranie malware’u, należy zbudować filtr wykrywający pliki Windows wykonywalne przesyłane siecią. Każdy plik rozpoczyna się sekwencją 4D 5A ("MZ"), ale wykrywanie ciągu powoduje olbrzymią liczbę fałszywych alarmów (średnio co ósmy pakiet zawiera taki ciąg), o wiele lepszą sygnaturę opracowano dla oprogramowania Snort, wykrywając typ "application/octet-stream" wraz z początkowymi znakami. Mimo wszystko nie jest to optymalne rozwiązanie, gdyż nie wykryje pliku wysyłanego z innym parametrem content-type (na przykład x-javascript). Niektórzy administratorzy poszukują ciągu "MZ@!L!This program cannot be run in DOS mode", co skutecznie wykrywa część binariów. Podejścia statyczne zawiodą, gdy zawartość jest pozbawiona znaków "MZ" albo występuje jako część obiektu z prawidłowymi nagłówkami.

Szybkie reguły

Czasami zadowalające efekty można osiągnąć bardzo prostymi środkami. Badacze zbudowali następujący zestaw trzech reguł:

- pakiety, które odbiegają od założeń RFC dla http;

- ruch do/z krajów o podwyższonym ryzyku rozsiewania złośliwego oprogramowania*);

- pliki z rozszerzeniami, które często pojawiają się w badaniach nad złośliwym oprogramowaniem: exe, cgi, php, bin, rar, zip, pdf, txt, jar, js.

- Uri Rivner, szef działu nowych technologii w firmie RSA informuje: "Monitoring ruchu w prawdziwej sieci, wykorzystujący wszystkie trzy reguły jednocześnie, wykrył 180 alarmów, z czego aż 175 było prawdziwymi atakami".

*) Afganistan, Białoruś, Bośnia i Hercegowina, Bułgaria, Wyspy Kajmańskie, Chiny, Chorwacja, Republika Czeska, Egipt, Gruzja, Indie, Kazachstan, Kirgistan, Łotwa, Libia, Litwa, Holandia, Nigeria, Oman, Pakistan, Katar, Rumunia, Rosja, dostawcy satelitarni, Arabia Saudyjska, Serbia, Singapur, Słowacja, Słowenia, Syria, Trynidad i Tobago, Turcja, Ukraina, Zjednoczone Emiraty Arabskie, Uzbekistan i Jemen.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200