Snort jest otwartoźródłowym systemem wykrywania intruzów wdzierających się z sieci (ang. network intrusion detection system, IDS), może też służyć jako system zabezpieczania przed intruzami wdzierającymi się z sieci (ang. network intrusion prevention system, IPS). Oprogramowanie to jest rozwijane przez firmę komercyjną (obecnie, 2021 rok, Cisco). Jednak ważnym elementem zaufania do tego systemu jest jego otwartoźródłowość - każdy ma możliwość sprawdzenia, że zastosowanie Snorta nie spowoduje wprowadzenia intruza bocznymi drzwiami przez zastosowanie tego narzędzia. Dodatkowo duża popularność narzędzia sprawia, że w tym przypadku otwartoźródłowość sprzyja zmniejszaniu zagrożenia.
Snort może działać w wielu rodzajach strumieni danych:
Na takim ruchu może on też wykonywać różnego rodzaju funkcje:
Na tych zajęciach pokażemy najprostszy scenariusz, gdy Snort pracuje na ruchu, który dociera do maszyny i działa jako system wykrywania intruzów (IDS).
Uwaga: dobrze jest mieć do tych zajęć przygotowane dwie maszyny wirtualne.
Na dobry początek warto zainstalować Snorta na maszynie wirtualnej:
# apt-get install snort snort-doc
Podczas instalacji otrzymamy zapytanie o sieć, na której będziemy
wykonywać badania. W związku z tym, że będziemy tego obrazu używali
w różnych sieciach, pole to należy wyczyścić i odpowiednio ustawić
zmienną HOME_NET w
pliku /etc/snort/snort.conf.
W tym celu po zakończeniu instalacji otwieramy wspomniany plik i
zauważamy, że edytowanie wspomnianej zmiennej nie jest właściwe i
należy otworzyć plik /etc/snort/snort.debian.conf,
gdzie należy zmiennej DEBIAN_SNORT_HOME_NET nadać
wartość opisującą adres sieci, przed atakami z której chcemy się
bronić. Możemy ją wyczytać np. za pomocą
polecenia ifconfig. Widząc tam zapis
inet 10.2.7.46 netmask 255.255.240.0 broadcast 10.2.15.255
wpisujemy do zmiennej wartość 10.2.0.0/20, bo wskazuje on, że właśnie 20 bitów zajmuje część adresu określająca adres sieci.
Możemy zacząć od tego, żeby sprawdzić, czy plik konfiguracyjny Snorta jest prawidłowy (na pewno jest prawidłowy po zainstalowaniu, ale warto zobaczyć, jak w takiej sytuacji wygląda działanie programu):
# snort -T -i enp0s3 -c /etc/snort/snort.conf 2>&1 | less
Opcna -T oznacza właśnie testowe wykonanie, -i pozwala wskazać, jakiego interfejsu oglądanie nas interesuje, zaś opcja -c pozwala wskazać plik konfiguracyjny. Po uruchomieniu tego polecenia ukaże nam się bardzo długa ściana tekstu, która zawiera raport z poszczególnych etapów wczytywania reguł zakończony podsumowaniem (też długim) zaczynającym się od opisu:
4057 Snort rules read
3383 detection rules
0 decoder rules
0 preprocessor rules
3383 Option Chains linked into 932 Chain Headers
który wskazuje, ile reguł zostało wczytane oraz ile z nich jest związane z wykrywaniem nieprawidłowości, ile z odkodowywaniem danych, a ile ze wstępnym przetwarzaniem. Wypisane informacje kończą się opisem wersji Snorta oraz oprogramowania, z którego on korzysta.
Cała siła programu Snort leży w regułach, które można pogrupować w
zestawy. Po krótkim przyjrzeniu się
plikowi /etc/snort/snort.conf
łatwo stwierdzimy, że do pliku konfiguracyjnego dołączane są liczne
pliki z katalogu /etc/snort/rules/, zawierającego właśnie różne zestawy reguł pogrupowane „tematycznie”. Można sobie rzucić
okiem, jakie zestawy są dostępne, i jak wyglądają poszczególne wpisy.
Zwykle diagnozowanie działania sieci, również z użyciem Snorta, zaczynamy od ustawienia interfejsu sieciowego karty w tryb promiscuous. W trybie tym karta przekazuje do oprogramowania wszystkie pakiety, które do niej docierają - również te, które nie są do niej adresowane. Co prawda w dzisiejszych czasach ruch pakietów adresowanych do innych interfejsów niż interfejs na końcu kabla jest drastycznie ograniczony przez przełączniki, ale nie zawsze to działa (NB. warto zgłosić administratorom, gdy na interfejsie pojawiają się pakiety do niego nie adresowane). Przełączenie karty w tryb promiscuous uzyskujemy za pomoca polecenia:
# ip link set enp0s3 promisc on
lub
# ifconfig enp0s3 -promisc
Możemy teraz uruchomić Snorta w celu określenia, czy nie dochodzi do naszej maszyny jakiś podejrzany ruch:
# snort -d -l /var/log/snort/ -h 10.2.0.0/20 -A console -c /etc/snort/snort.conf
Tutaj opcja -d wskazuje, że Snort jest używany w trybie systemu
wykrywania intruzów (ang. Network Intrusion Detection System,
NIDS). W trybie tym widzimy tylko informacje pochodzące z ruchu o
podejrzanych charakterystykach (np. pakiety o niepoprawnej
strukturze). Opcja -l wskazuje, gdzie są umieszczane pliki z
zebranymi przez Snorta informacjami. Dodanie -h 10.2.0.0/20 powoduje, że widzimy nieco mniej informacji na
ekranie, a podejrzany ruch z odległych maszyn umieszczany jest w
katalogach o nazwach zgodnych z nazwami tych maszyn, zaś -A console powoduje, że dostajemy raporty na ekranie terminala.
Możemy sobie chwilę poobserwować ruch, żeby się nieco oswoić z rodzajem uzyskiwanej informacji. Warto raz na jakiś czas nacisnąć na dłużej enter, żeby sobie oczyścić ekran z nadmiaru informacji.
Najbardziej typowym sposobem badania komputerów w sieci jest wyłanie do maszyny pinga. Wykonajmy z jakiejś innej maszyny niż ta, na której działa Snort, polecenie:
# ping 10.2.7.46
Zapewne nic tutaj nie zobaczymy, bo reguły Snorta są tak napisane, aby nie robić alarmu w przypadku ruchu zasadniczo nieszkodliwego. Natomiast jeśli spróbujemy wysłać niestandardowe pakiety ping, to ujrzymy nietrywialny efekt działania Snorta. Po wysłaniu pakietu ping (technicznie jest to pakiet ICMP echo request) o rozmiarze 4096
# ping -s 4096 10.2.7.46
dostaniemy następujące trzy sygnały od Snorta:
12/04-20:00:39.553493 [**] [1:480:5] ICMP PING speedera [**] [Classification: Misc activity] [Priority: 3] {ICMP} 10.2.1.95 -> 10.2.7.46
12/04-20:00:39.553493 [**] [1:499:4] ICMP Large ICMP Packet [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.2.1.95 -> 10.2.7.46
12/04-20:00:39.553669 [**] [1:499:4] ICMP Large ICMP Packet [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.2.7.46 -> 10.2.1.95
Jak to zwykle bywa, wpisy zaczynają się od znaczników czasowych. Ciąg [**] to specyficzny separator używany przez Snorta. Następny znacznik, na przykład [1:480:5], wskazuje, jakie moduły wewnętrzne Snorta zajmowały się przetwarzaniem prowadzącym do danego alarmu (pierwsza 1, zob. plik etc/generators w źródłach Snorta), jaka reguła została użyta (patrzymy na wartość sid w regule) oraz w jakiej wersji (patrzymy na wartość rev w regule).
Pochodzenie alarmu możemy w ogromnej większości przypadków (nie dotyczy to reguł preprocesora) stwierdzić, wykonując polecenie w stylu:
# grep sid:499 /etc/snort/rules/*
Powyższa instrukcja szybko nam też wyjaśni pochodzenie następnego
napisu - komentarza do alertu. Następnie po separatorze [**] widać
określenie, do jakiej kategorii zdarzeń został dany alert
przydzielony. Z każdą kategorią zdarzeń związany jest domyślny
priorytet zwykle konfigurowany w
pliku /etc/snort/classification.config. Można jednak te
wartości nadpisywać w regułach.
Końcowy zapis {ICMP} 10.2.7.46 -> 10.2.1.95 jest
zapisem przepisanym na początku reguły (wskazanie protokołu niższej
warstwy oraz adresów pochodzenia i docelowego pakietu; czasami
rozszerzone o numer portu).
Inny przykład raportu, jaki daje Snort, uzyskamy, wydając (na innej maszynie wirtualnej) polecenie:
# nmap -A 10.2.7.46
Wtedy uzyskamy raport postaci:
12/04-19:50:41.178872 [**] [1:1418:11] SNMP request tcp [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.2.1.95:35957 -> 10.2.1.95:161
12/04-19:50:41.197157 [**] [1:1421:11] SNMP AgentX/tcp request [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.2.1.95:35957 -> 10.2.1.95:705
12/04-19:50:42.150598 [**] [1:1228:7] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.2.1.95:47570 -> 10.2.1.95:1
12/04-19:50:42.150779 [**] [1:485:4] ICMP Destination Unreachable Communication Administratively Prohibited [**] [Classification: Misc activity] [Priority: 3] {ICMP} 10.2.1.95 -> 10.2.1.95
Wskazujący, że program nmap do określenia systemu
operacyjnego na komputerze, który jest badany, używa protokołu SNMP,
następnie wykonuje skanowanie portów, aby zakończyć proces wysłaniem
niestandardowego pakietu ICMP.
Spróbujmy teraz napisać własną regułę Snorta. Umieścimy ją w pliku
/etc/snort/rules/local.rules i nadamy jej taką postać:
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg: "Attempt to telnet from external net"; sid:10000002; rev:1;)
Pamiętajmy, że reguła musi być zapisana w jednym wierszu.
Teraz próba wykonania polecenia telnet z adresem naszej maszyny wirtualnej spowoduje wyświetlenie się odpowiedniego alarmu Snorta. Jednak taki alarm może być dla nas niezadowalający: brakuje klasyfikacji i priorytet jest bardzo wysoki. Dlatego poprawmy regułę tak:
alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg: "Attempt to telnet from external net"; sid:10000002; rev:2; classtype:attempted-user)
Tym razem próba telnetu da nam już wskazanie, że alarm należy do określonej klasy, a także wskaże sensowny jej priorytet. Warto zwrócić uwagę, że przy okazji zmiany zwiększyła się też wartość pola rev. Zwiększyliśmy je o jeden, żeby wskazać, iż zaszła zmiana i w obiegu mogą być alerty pochodzące z różnych wersji tej reguły, a zatem prawdopodobnie mające różne znaczenie.
Reguły Snorta pozwalają na badanie wielu charakterystyk pakietów,
jakie trafiają do komputera. Proszę przyjrzeć się regułom z plików
/etc/snort/rules/web-*, aby zorientować się, jakie
rodzaje alarmów są tworzone dla aplikacji webowych. Warto też obejrzeć dokumentację ze strony
https://www.snort.org.
Snort bywa umieszczany jako część dedykowanego systemu operacyjnego służącego do wykrywania intruzów. Przykładem takiego rozwiązania jes system Security Onion.
Gdy Snort jest używany jako sonda IDS/IPS, która bada ruch w segmencie sieciowym, jest uruchamiany wraz z odpowiednimi rozwiązaniami sprzętowymi takimi jak urządzenia TAP lub na końcu połączenia przez port lustrzany.
Strona Snorta oferuje kilka rodzajów reguł (zob. https://www.snort.org/downloads/#rule-downloads):
Są też dostępne inne subskrypcje komercyjne, oferuje takie na przykład firma Cisco.
Proszę napisać regułę Snorta wykrywającą próbę połączenia się protokołem HTTP pod niestandardowy numer portu. Fragment pliku reguł zawierający taką regułę proszę wysłać do Moodle.