39360.zip
Skalowalny i wydajny system wykrywania włamań sieciowych (NIDS) o otwartym kodzie źródłowym Snort wykorzystuje serię dobrze zdefiniowanych reguł do wykrywania anomalnych pakietów w sieci. Utrzymanie tych zestawów reguł znacząco poprawia skuteczność systemu. Kilka technik zarządzania regułami może pomóc w utrzymaniu systemu Snort IDS. Po pierwsze, można zapobiec przeciążeniu alarmami poprzez uściślenie definicji zmiennych i pielęgnację reguł Snorta. Można również zachować własne reguły podczas uaktualniania zestawu reguł. Wreszcie, można zdekonstruować regułę, aby zrozumieć, jak dostosować ją do swojego środowiska.
Domyślnie Snort zawiera ponad 1900 reguł składowych w serii prawie 50 plików tekstowych uporządkowanych według typów, jak pokazuje Rysunek 1. Reguły te definiują wyzwalacze reakcji na wiele znanych luk w systemach Windows, UNIX i powszechnie używanych aplikacjach, takich jak Microsoft IIS, Apache, Microsoft SQL Server i Oracle SQL. Reguły pomagają również Snortowi w dostarczaniu danych zwiadowczych i ewentualnych ostrzeżeń konfiguracyjnych, które ostrzegają o skanowaniu sieci lub o maszynie, która np. rozgłasza domyślny ciąg społeczności SNMP. Jak można sobie wyobrazić, Snort może generować ogromną liczbę alertów. Aby zmniejszyć hałas generowany przez reguły, domyślna konfiguracja Snorta włącza domyślnie tylko około 1300 reguł i wyłącza domyślnie całe typy reguł, takie jak polityka, czat i wirusy. (Typ reguły jest zazwyczaj zawarty w swoim własnym pliku tekstowym, tak więc reguły typu wirus są zawarte w pliku virus.rules). Przejrzyj wszystkie wyłączone grupy reguł i włącz te, które mogą mieć zastosowanie w twoim środowisku.
Prune Your Rules
Nawet przy wielu regułach, które Snort domyślnie wyłącza, twój system Snort IDS prawdopodobnie będzie generował wiele alertów. Przebrnięcie przez te wszystkie alerty może przytępić twoje zmysły na naprawdę podejrzany ruch. Po zainstalowaniu Snorta w swoim środowisku, usuń te reguły, które nie dotyczą twojego środowiska lub które cię nie interesują. Na przykład, jeśli nie masz wbudowanego w HTML języka skryptowego PHP: Hypertext Preprocessor (PHP) zainstalowanego w twoim środowisku, możesz wyłączyć plik reguł web-php.rules. Przy podejmowaniu decyzji, które reguły wyłączyć, należy jednak wziąć pod uwagę użytkowników, którzy mogą mieć na swoich komputerach różne oprogramowanie. Na przykład, jeden z czujników Snorta może odebrać podejrzane pakiety ze skompromitowanego komputera domowego poprzez połączenie VPN. Tak więc, kontynuując poprzedni przykład, nawet jeśli nie masz zainstalowanego PHP na żadnym z komputerów firmowych, jeden z użytkowników końcowych mógł zainstalować go w domu. Jeśli ten domowy komputer zostałby zaatakowany przez lukę w PHP, atakujący mógłby uzyskać dostęp do sieci korporacyjnej, podczas gdy ten komputer jest zdalnie podłączony do sieci korporacyjnej (np. przez VPN).
Większość systemów alertów i raportowania wyświetla nazwę i SID dla każdej reguły dla łatwego odniesienia. Aby jeszcze bardziej przyciąć listę włączonych reguł, należy monitorować systemy, notować nazwy lub SID niepotrzebnych reguł, a następnie wyłączać te reguły. Aby ręcznie wyłączyć regułę Snorta, należy otworzyć plik z regułą i wstawić znak funta (#) przed regułą. Aby wyłączyć całą klasę reguł, należy dodać znak funta przed nazwą pliku z regułą w pliku konfiguracyjnym Snorta. Aby załadować zmodyfikowane reguły, należy ponownie uruchomić Snorta.
Regularne sprawdzanie reguł i eliminowanie tych, które nie mają zastosowania w danej sieci, znacznie zmniejszy liczbę alertów generowanych przez Snorta, ułatwiając tym samym wykrywanie i identyfikację naprawdę podejrzanych pakietów. Pamiętaj też o ponownym włączaniu reguł w razie potrzeby, gdy wprowadzisz nową technologię, którą obecnie wyłączone reguły mogłyby chronić.
Uaktualniaj reguły
Snort.org udostępnia dwie wersje reguł Snort: snortrules-stable i snortrules-current, które działają odpowiednio ze Snortem 2.0x i Snortem 1.9x. Nowsze reguły zawierają dodatkowe sygnatury i uaktualnienia istniejących reguł, aby wykorzystać rozszerzone zmienne. Przykładowo, reguły w wersji 2.0.0 definiują zmienne, które w szczególny sposób opisują pewne funkcje maszyn (np. zmienne HTTP_SERVERS i HTTP_PORTS charakteryzują komputery, na których działają serwisy internetowe i które mogą być podatne na ataki z ich wykorzystaniem). Te nowe zmienne są wykorzystywane w nowych regułach w celu dokładniejszej selekcji nadchodzących ataków. Stara reguła może ostrzegać o podejrzanym żądaniu HTTP skierowanym do dowolnego komputera w sieci, natomiast nowa reguła szuka tego samego ataku tylko wtedy, gdy jest on skierowany do serwera WWW zdefiniowanego w zmiennej HTTP_SERVERS. Ten proces klasyfikacji pomaga zmniejszyć liczbę fałszywych alarmów.
Snort.org często aktualizuje zestawy reguł, aby być na bieżąco z nowymi odkryciami exploitów. Aby być na bieżąco, regularnie sprawdzaj, pobieraj i stosuj nowe reguły, które mogą być przydatne w twoim środowisku. Należy jednak pamiętać, że za każdym razem, gdy pobierasz zestaw nowych reguł, pliki tekstowe zawierające nowe reguły nadpisują te zawierające stare reguły. Szybko przekonasz się, że komentowanie wszystkich nieużywanych reguł za każdym razem, gdy aktualizujesz pliki reguł jest uciążliwe.
Oinkmaster na ratunek
Na szczęście, kilka narzędzi open-source może pomóc ci przezwyciężyć ten problem. Program skryptowy Perla o nazwie Oinkmaster, który można pobrać z http://www.algonet.se/~nitzer/oinkmaster, automatyzuje pobieranie nowych reguł i zarządza wyłączonymi lub zmodyfikowanymi regułami. Dostosowany do systemów UNIX, skrypt Perla używa narzędzi wget, tar i gzip do pobierania i rozszerzania nowych reguł przy każdym uruchomieniu skryptu. Większość z tych narzędzi jest instalowana na systemach UNIX, ale można pobrać narzędzia dla Windows. Pamiętaj, że rozwiązania open-source mają ograniczone wsparcie techniczne (jeśli w ogóle), więc poszukaj w Internecie rozwiązań problemów lub pytań, które możesz mieć. Społeczność oprogramowania o otwartym kodzie źródłowym (OSS) obfituje w przydatne informacje. Dobrym miejscem na rozpoczęcie jest zapisanie się na jedną z list mailingowych Snorta, na którą można się zapisać pod adresem http://www.snort.org/lists.html.
Upewnij się, że zapoznałeś się z plikiem README dla szczegółowych instrukcji instalacji dla twojej platformy. Podstawowa procedura instalacji Oinkmastera składa się z rozszerzenia plików oinkmaster.pl i oinkmaster.conf do katalogu Snort (lub katalogu wskazanego przez użytkownika), a następnie użycia oinkmaster.conf do skonfigurowania Oinkmastera.
Otwórz oinkmaster.conf i postępuj zgodnie z komentarzami inline, aby skonfigurować narzędzie. Po pierwsze, potwierdź lokalizację zaktualizowanych reguł jako adres internetowy (np., http://www.snort.org/dl/signatures/snortrules.tar.gz). Upewnij się, że wskazujesz Oinkmasterowi zaufaną i renomowaną stronę, szczególnie jeżeli wybierasz pobieranie i instalację reguł automatycznie. W przeciwnym razie, ryzykujesz pobranie uszkodzonych (lub gorzej, zmodyfikowanych) reguł, które mogą zagrozić twojemu IDS.
Następnie, określ pliki do pominięcia, modyfikacji i wyłączenia. Domyślnie, Oinkmaster nie przetwarza (tj. pomija) local.rules i snort.conf.
Funkcja modifysid skryptu pozwala modyfikować nowo pobrane reguły; pomyśl o modifysid jak o funkcji Search and Replace dla specyficznej reguły, którą identyfikujesz przez SID. Za pomoc± tego polecenia można modyfikować tekst okre¶lonej reguły. Na przykład, można użyć modifysid do wł±czenia reguły, która jest domyślnie wyłączona. Aby to zrobić, dodaj nowe polecenie modifysid identyfikuj±ce regułę, któr± chcesz wł±czyć i poinstruuj j±, aby usunęła znak komentarza (#). Za każdym razem, gdy nowy zestaw reguł jest pobierany, ten znak komentarza będzie usunięty, gdy Oinkmaster przetwarza tę regułę. Możesz również użyć modifysid do podniesienia typu akcji reguły. Na przykład, polecenie
modifysid 2003 "alert" | "sev1"
podnosi alert z SID 2003 do niestandardowego typu akcji sev1. Oinkmaster robi to poprzez wyszukanie „alert” i zastąpienie go „sev1”. Ostatnia i najbardziej popularna funkcja Oinkmastera, disablesid, pozwala na wyłączenie wybranych reguł. Określ identyfikatory SID wszystkich reguł, które mają być wyłączone. Na przykład, aby wyłączyć alarmowanie o skanowaniu sieci, możesz zacząć od wpisu podobnego do
disablesid 469, 615, 618, 620
Po pobraniu i przetworzeniu nowego zestawu reguł, Oinkmaster szuka podanych SID i komentuje reguły. Tak długo, jak Oinkmaster zarządza twoimi regułami, reguły pozostaną wyłączone, nawet przez aktualizacje zestawu reguł.
Ręcznie wykonaj skrypt za każdym razem, gdy chcesz zaktualizować swoje reguły. Jeśli czujesz się odważny, zaplanuj uruchamianie skryptu i aktualizację reguł w sposób cykliczny. Oinkmaster pobierze reguły, rozszerzy je i skopiuje do katalogu reguł twojego czujnika. Jak w przypadku większości OSS, używaj Oinkmastera z rozwagą i najpierw dowiedz się co robi i jak wpłynie na twoje środowisko. Na przykład, przetestuj nowy zestaw reguł uruchamiając Snorta w trybie autotestu (używając snort -T plus inne parametry) zanim wdrożysz reguły do środowiska produkcyjnego.
Oinkmaster pozwala uniknąć ryzyka pobierania podejrzanych aktualizacji, dając opcję tworzenia kopii zapasowych starych reguł i dostarczając log swoich działań do konsoli. Przejrzyj to wyjście, które pokazuje usunięte reguły, zmodyfikowane aktywne reguły, rewizje nie będące regułami i nowe pliki, aby potwierdzić, że Oinkmaster pomyślnie zakończył swoje zadania i aby potwierdzić reguły, które Oinkmaster zmodyfikował. Jeżeli zdecydujesz się zaplanować automatyczne działanie Oinkmastera, rozważ wysłanie wyników e-mailem, aby ułatwić przeglądanie, jak pokazuje Rysunek 2. Następujący przykład pokazuje jak zaplanować Oinkmastera by działał codziennie o 6:15 rano używając linuksowej komendy crontab (crontab pozwala zaplanować zadania w Linuksie):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Parametry Oinkmastera określają katalog reguł (-o), katalog reguł zapasowych (-b), i komendę do wysłania emaila z wynikami do właściciela. Polecenie 2>&1 wysyła wyjście StdErr do StdOut (konsola) przed wysłaniem go do aplikacji e-mail.
Spojrzenie na regułę Snort
Oprócz wyłączania lub wprowadzania podstawowych modyfikacji w regułach standardowych, można tworzyć własne reguły i dalej dostosowywać reguły Snort bezpośrednio do swojego środowiska. Na przykład, rozważmy wdrożenie czujnika, który monitoruje ruch wewnątrz i na zewnątrz firewalla. O ile wiedza o tym, ile ataków robaków odpiera firewall, może być interesująca, o tyle wiedza o tym, czy któryś z tych ataków pochodzi z wnętrza sieci, będzie prawdopodobnie jeszcze bardziej interesująca. Ostatnio, reguły Snorta zawierają reguły „dostrojone”, takie jak powyższy przykład, ale pozostało wiele innych, które można dostosować w podobny sposób. Listing 1 pokazuje standardową regułę, która alarmuje użytkownika, gdy wykryje robaka SQL Slammer (aka Sapphire). Rozłóżmy szybko tę regułę na czynniki pierwsze. (Szczegółowe informacje o wszystkich dostępnych parametrach definiujących reguły można znaleźć w dokładnej dokumentacji reguł Snorta na stronie http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Wszystkie reguły muszą znajdować się w jednym wierszu i rozpoczynać się od akcji reguły, która w tym przypadku brzmi
alert
Akcja reguły określa sposób, w jaki Snort zareaguje na regułę, jeśli zostanie ona uruchomiona. Można zmodyfikować typ reguły (np. na ciąg znaków 'sev1′), aby zapewnić niestandardową obsługę – np. eskalować działanie w przypadku dopasowania. Ten krok różni się od poprzedniego przykładu, w którym użyliśmy Oinkmastera do zmiany typu alertu istniejącej reguły; w tym przykładzie tworzymy nową regułę używając istniejącej reguły jako szablonu.
Zestaw parametrów
udp $EXTERNAL_NET any -> $HOME_NET 1434
zawiera protokół, adres IP, informacje o porcie i kierunku ruchu dla reguły. Reguła ta mówi Snortowi, aby znalazł każdy pakiet UDP ze źródła sieciowego (które definiuje zmienna $EXTERNAL_NET) próbujący przejść do zmiennej $HOME_NET na porcie 1434. Większość reguł domyślnych używa przede wszystkim zmiennych $EXTERNAL_NET i $HOME_NET. Jednakże, niektóre reguły używaj± bardziej specyficznych zmiennych. Na przykład, reguły dotycz±ce serwerów DNS (w pliku dns.rules) używaj± zmiennej $DNS_SERVERS. Zdefiniuj te zmienne w pliku konfiguracyjnym Snorta (zwykle snort.conf). Opcjonalnie można utworzyć własne zmienne, aby odzwierciedlały topologię (np. $MAIL_SERVERS) i były używane w niestandardowych regułach. Zdefiniuj zmienną używając jej nazwy (np. var MAIL_SERVERS= 192.168.0.20/30), a następnie odwołaj się do niej poprzedzając ją znakiem dolara ($ – np. $MAIL_SERVERS). Akcja reguły i te parametry tworz± nagłówek reguły.
Opcje reguły dalej precyzuj± regułę tak, że podejrzany pakiet (i tylko podejrzany pakiet) wywoła reakcję. Jak można się domy¶lić, sygnatury te mog± być bardzo szczegółowe i wykraczać daleko poza proste dopasowywanie portów. Na przykład, proszę sobie wyobrazić fałszywe wyniki pozytywne, które powstałyby, gdyby reguła Slammera po prostu ostrzegała o ruchu na porcie UDP 1434.
Opcja msg
msg:"MS-SQL Worm propagation attempt"
zapewnia prosty opis alertu do wykorzystania w alertach i raportach. Opcja content
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
zawiera rozróżniający wielkość liter łańcuch dopasowania wzorca payload, w wartościach ASCII lub szesnastkowych (wartości szesnastkowe należy otoczyć znakiem pipe-|). Można określić wiele opcji zawartości. Opcja głębokości następuje po każdej opcji zawartości i określa, w ilu bajtach payloadu ma być przeszukiwana określona zawartość. W tym przykładzie, pakiet spowoduje reakcję, je¶li będzie zawierał warto¶ć heksadecymaln± 04 w pierwszym bajcie lub pozostał± zawarto¶ć w dowolnym miejscu payloadu.
Pobierane reguły często zawieraj± odniesienia do szczegółowych informacji na temat podejrzanego exploita lub powodu utworzenia reguły. Niektóre systemy raportowania wspierają opcję referencji poprzez dostarczanie bezpośrednich linków do tych informacji:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort przypisuje reguły do klas i przypisuje tym klasom priorytet wysoki, średni lub niski. Obecnie istnieje ponad 30 klasyfikacji, w tym: próba-admin, trojan-activity, próba denial of service i network-scan. W naszym przykładzie, klasyfikacja to
classtype:misc-attack
Snort zapisuje priorytet odpowiedzi dla wykrytych włamań. Można użyć zewnętrznego narzędzia lub skryptu do dalszego przetwarzania tego priorytetu i podjęcia działań z aplikacją raportującą.
W ostatnim segmencie
sid:2003; rev:2;
sid reprezentuje unikalną regułę Snort, a rev oznacza numer rewizji. Te właściwości jednoznacznie identyfikują regułę.
Doskonalenie reguły
Sprawdźmy, jak zmodyfikować regułę, aby zapewniała eskalowany alarm, gdy wykryje wewnętrzne zainfekowane hosty. Ponieważ mamy do czynienia z tym samym exploitem, co w oryginalnej regule, definicja zawartości reguły pozostaje taka sama. Musimy zmodyfikować jedynie adresy IP i kierunek ruchu. Zmieńmy źródłowy adres IP na $HOME_NET, w następujący sposób:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definiuje $EXTERNAL_NET jako „any”, więc ta reguła nadal będzie wychwytywać uszkodzone pakiety skierowane do wewnętrznych hostów (tak jak oryginalna reguła). Jednak teraz, gdy mamy dedykowaną regułę, która śledzi tylko wewnętrzne źródłowe adresy IP, możemy zmienić typ akcji na niestandardowy typ akcji, który wyzwala eskalowany alarm.
Obecne reguły Snorta zawierają tę regułę wykrywania wychodzących robaków Slammer w domyślnym zestawie reguł. Jednakże, kiedy nowy robak, wirus lub inny exploit zaczyna się rozprzestrzeniać, należy rozważyć stworzenie nowych reguł, które zwrócą uwagę na konkretne włamania.
Stworzenie reguł
Oprócz istniejących lub niestandardowych reguł, które można modyfikować lub tworzyć, można dołączyć reguły uzyskane z innego źródła. Na przykład, kiedy w Internecie pojawiają się informacje o nowym robaku, witryny i grupy dyskusyjne poświęcone bezpieczeństwu szybko publikują jednorazowe reguły Snorta, które mogą wykryć nowego robaka. Wklej te nowe reguły do pliku local.rules, a następnie uruchom ponownie Snorta, aby nowe reguły zaczęły działać.
Snort zapewnia ramy dla niedrogiego i konfigurowalnego systemu IDS. Dzięki zestawowi reguł wspieranemu przez społeczność, Snort pozostaje elastycznym i skutecznym systemem. Utrzymywanie aktualnych reguł zwiększy twoją czujność i zmniejszy szum wynikający z nieefektywnych alarmów. Jak w przypadku każdego projektu open-source, poświęcenie czasu na zrozumienie jego działania i zapoznanie się z dodatkami opracowanymi przez społeczność znacznie poprawi komfort pracy z systemem i zwiększy jego skuteczność w Twoim środowisku.