PLD-doc/book/pl_book__uslugi/pl_uslugi_snort.sec
ciesiel
cvs w pld-linux.org
Nie, 10 Paź 2004, 00:55:10 CEST
Author: ciesiel
Date: Sat Oct 9 22:55:07 2004
New Revision: 4732
Added:
PLD-doc/book/pl_book__uslugi/pl_uslugi_snort.sec
Log:
- inicjacja
- wersja surowa i do obrobki (nie dolaczac do mastera)
Added: PLD-doc/book/pl_book__uslugi/pl_uslugi_snort.sec
==============================================================================
--- (empty file)
+++ PLD-doc/book/pl_book__uslugi/pl_uslugi_snort.sec Sat Oct 9 22:55:07 2004
@@ -0,0 +1,1070 @@
+<?xml version="1.0" encoding="iso-8859-2"?>
+<section id="uslugi_snort">
+ <title>Snort - Sieciowy System Wykrywania Włamań</title>
+ <para>
+ <ulink url="www.snort.org">Snort</ulink> to bardzo silny
+ sieciowy system wykrywania ataków (ang. Network
+ Intrusion Detection System, NIDS), który daje szeroki zakres
+ mechanizmów detekcji, mogących w czasie rzeczywistym dokonywać analizy
+ ruchu i rejestrowania pakietów w sieciach opartych na protokołach
+ IP/TCP/UDP/ICMP. Potrafi przeprowadzać analizę strumieni pakietów,
+ wyszukiwać i dopasowywać podejrzane treści, a także wykrywać wiele
+ ataków i anomalii, takich jak przepełnienia bufora, skanowanie portów
+ typu stealth, ataki na usługi WWW, SMB, próby wykrywania systemu operacyjnego
+ i wiele innych.
+ </para>
+ <section id="snort_wymagania">
+ <title>Wymagania</title>
+ <para>
+ Przed instalacją Snorta warto zaopatrzyć się w bazę
+ danych (w opisie wykorzystano MySQL) i serwer Apache z
+ obsługą PHP. W bazie będą składowane logi, a za
+ wygodny interfejs do przeglądania alarmów posłuży ACID
+ (ang. Analysis Console for Intrusion Databases).
+ </para>
+ </section>
+ <section id="snort_instalacja">
+ <title>Instalacja Snorta i ACID</title>
+ <para>
+ Gdy mamy już bazę danych i serwer WWW z PHP, instalujemy
+ następujące pakiety.
+ </para>
+ <screen>poldek> install snort acid</screen>
+ <para>
+ Przed konfiguracja środowiska NIDS zakładamy dwie bazy, dla
+ Snorta i dla archiwum alarmów.
+ </para>
+ <screen># mysql -u mysql -p
+Enter password:
+mysql> create database snort_log;
+Query OK, 1 row affected (0.01 sec)
+mysql> create database snort_archive;
+Query OK, 1 row affected (0.01 sec)
+mysql> quit</screen>
+ <para>
+ Dodajemy tabele w taki sam sposób dla obu baz.
+ </para>
+ <screen># gzip -d /usr/share/doc/snort-{wersja}/create_mysql.gz
+# mysql -D snort_log -u mysql -p < /usr/share/doc/snort-{wersja}/create_mysql
+# gzip -d /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql.gz
+# mysql -D snort_log -u mysql -p < /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql
+
+# mysql -D snort_archive -u mysql -p < /usr/share/doc/snort-{wersja}/create_mysql
+# mysql -D snort_archive -u mysql -p < /usr/share/doc/acid-{wersja}/create_acid_tbls_mysql.sql</screen>
+ <para>
+ Następnie (najprościej przy użyciu popularnego narzędzia
+ phpMyAdmin) tworzymy użytkownika i nadajemy mu prawa dla
+ stworzonych baz.
+ </para>
+ <para>
+ Przechodzimy do edycji pliku /etc/acid_conf.php, w którym
+ dodajemy parametry dla połączenia się z bazami.
+ </para>
+ <screen>[...]
+/* Alert DB connection parameters */
+[...]
+$alert_dbname = "snort_log";
+$alert_host = "localhost";
+$alert_port = "3306";
+$alert_user = "login";
+$alert_password = "haslo";
+
+/* Archive DB connection parameters */
+$archive_dbname = "snort_archive";
+$archive_host = "localhost";
+$archive_port = "3306";
+$archive_user = "login.;
+$archive_password = "haslo";
+[...]</screen>
+ <para>
+ Teraz strona z interfejsem jest dostępna pod adresem
+ http://twoje_ip/acid. Oczywiście dla bezpieczeństwa zalecane
+ jest zastosowanie protokołu SSL do komunikacji z zasobem i
+ autoryzacji poprzez pakiet apache-mod_auth.
+ </para>
+ <para>
+ Snort zależnie od środowiska w jakim działa może generować
+ dużą ilość zbędnych alertów, te bardziej istotne można
+ przenosić do drugiej bazy za pomocą ACID, dla przejrzystości
+ ogółu.
+ </para>
+ </section>
+ <section id="snort_konfiguracja">
+ <title>Konfiguracja Snorta</title>
+ <para>
+ Do działania jako sieciowy system wykrywania włamań, Snort
+ potrzebuję sprecyzowania zasad funkcjonowania całości w
+ głównym pliku konfiguracyjnym snort.conf. W starszych wersjach
+ systemu, wszystkie opcje, łącznie z regułami ataków znajdowały
+ się w jednym pliku. Ciągła rozbudowa Snorta, rosnąca liczba
+ sygnatur i ogólna funkcjonalność, wymusiła rozdzielenie
+ niektórych części konfiguracyjnych, w tym reguł ataków.
+ Przejrzystość i spójność snort.conf została przywrócona przy
+ użyciu polecenia include, którym dołącza się odpowiednie
+ zestawy sygnatur i inne części konfiguracyjne, np.:
+ </para>
+ <screen>include: ścieżka_do_pliku/nazwa</screen>
+ <para>
+ Bazy reguł charakteryzują się nazwą pliku z końcówką .rules,
+ pierwszy człon nazwy zawiera rodzaj usługi lub typ ataku,
+ którego dotyczy dany zestaw. Pozostałymi plikami
+ konfiguracyjnymi są:
+ </para>
+ <para>
+ Pozostałymi plikami konfiguracyjnymi są:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ classification.config - zawierający
+ klasyfikatory rodzajów ataków z
+ nadanym priorytetem zagrożenia, tak
+ jak poniżej:
+ </para>
+ <screen>config classification:
+ web-application-attack,Web Application
+ Attack,1</screen>
+ </listitem>
+ <listitem>
+ <para>
+ reference.config - posiadający skróty
+ adresów do stron organizacji z bazą
+ opisów ataków, np.:
+ </para>
+ <screen>config reference: bugtraq
+ http://www.securityfocus.com/bid/</screen>
+ </listitem>
+ <listitem>
+ <para>
+ threshold.conf - metody łagodzenia
+ licznych, fałszywych alarmów,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ unicode.map - zestaw kodowanych znaków
+ unicode, na potrzeby preprocesora
+ http_inspect.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Główny plik konfiguracyjny można podzielić na cztery sekcje.
+ Pierwsza, odpowiedzialna jest za ustalanie zmiennych var,
+ wykorzystywanych w składni reguł ataków.
+ </para>
+ <para>
+ Przyjmijmy że docelowo Snort ma monitorować dwie podsieci o
+ adresach 192.168.1.0/24 i 192.168.2.0/24, jego pliki
+ konfiguracyjne znajdują się bezpośrednio w katalogu
+ /etc/snort, a regułki w /etc/snort/rules.
+ </para>
+ <screen># Adres sieci lokalnej
+var HOME_NET [192.168.1.0/24,192.168.2.0/24]
+# Adres sieci zewnetrznej
+var EXTERNAL_NET !$HOME_NET
+# Lista adresow serwerow znajdujacych sie w strefie chronionej
+var DNS_SERVERS $HOME_NET
+var SMTP_SERVERS $HOME_NET
+var HTTP_SERVERS $HOME_NET
+var SQL_SERVERS $HOME_NET
+var TELNET_SERVERS $HOME_NET
+var SNMP_SERVERS $HOME_NET
+# Lista portow
+var HTTP_PORTS 80
+var SHELLCODE_PORTS !80
+var ORACLE_PORTS 1521
+# Lista serwerow czat, komunikatorow
+var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,]
+# Scieżka do katalogu z regulami atakow
+var RULE_PATH /etc/snort/rules</screen>
+ <para>
+ W tej samej sekcji znajduje się zestaw parametrów
+ uruchomieniowych, zaczynających się od wyrażenia config (pełna
+ ich lista znajduję się w dokumentacji):
+ </para>
+ <screen># wybor interfejsu do nasłuchu (jeden demon Snorta
+moze obslugiwac tylko jeden
+# interfejs sieciowy)
+config interface: eth0</screen>
+ <para>
+ Druga część głównego pliku konfiguracyjnego, zawiera
+ ustawienia preprocesorów. Parametry domyślne nie będą
+ przedstawione w poniższym opisie. Kompletną listę opcji, można
+ znaleźć w dokumentacji Snorta.
+ Oto przykłady ustawień preprocesorów:
+ </para>
+ <para>
+ Frag2:
+ </para>
+ <screen># detect_state_problems . zwraca alarm przy pokrywaniu sie fragmentow.
+preprocessor frag2: detect_state_problems</screen>
+ <para>
+ Stream4, Stream4_reassemble:
+ </para>
+ <screen># disable_evasion_alerts . brak alarmow przy nakladaniu sie pakietow TCP,
+# detect_scans . detektor prob cichego skanowania,
+# detect_state_problems . detektor nienaturalnego zachowania
+# pakietow.
+preprocessor stream4: disable_evasion_alerts detect_scans detect_state_problems
+# both . skladanie sesji TCP w obu kierunkach pomiedzy klientem i serwerem,
+# ports . lista portow, na ktorych ma dzialac reasemblacja.
+preprocessor stream4_reassemble: both ports [ 21 25 80 143 110 ]</screen>
+ <para>
+ Http_inspect:
+ </para>
+ <screen># iis_unicode_map . wskazuje plik z kodowaniem unicode i wybiera standardowe.
+preprocessor http_inspect: global is_unicode_map unicode.map 1252
+# profile . wybor profilu ustawien dla serwerow typu iis, apacze i all.
+preprocessor http_inspect_server: server adres_IP_serwera_MS_IIS \
+ profile iis \
+ ports { 80 }
+preprocessor http_inspect_server: server adres_IP_serwera_Apache \
+ profile apache \
+ ports { 80 }</screen>
+ <para>
+ Powyższy przykład przedstawia możliwość profilowania ustawień
+ dla poszczególnych serwerów, które podlegają ochronie. Serwery
+ IIS i Apache, pracują w odmienny sposób, a zarazem posiadają
+ inne słabe punkty wykorzystywane podczas ataków. Operacja
+ dostosowania ustawień skupia mechanizmy ochronne na
+ odpowiednich metodach ataków dla danego typu serwera bądź ich
+ grupy w danej sieci objętej ochroną.
+ </para>
+ <para>
+ RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance
+ Monito:
+ </para>
+ <screen># alert_fragments . wlacza alarm, przy fragmentowaniu pakietow RPC,
+# Domyślne porty: 111 i 32771.
+preprocessor rpc_decode: 111 32771 alert_fragments
+preprocessor bo
+preprocessor telnet_decode
+preprocessor arpspoof
+preprocessor arpspoof_detect_host: adresy_IP przypisane_do_nich_adresy_MAC
+# console . wyswietlanie statystyk na ekranie,
+# flow i events . statystyki badanego ruchu i ilosci dopasowanych
+# regul,
+# time . aktualizacja danych co 10s.
+preprocessor perfmonitor: console flow events time 10</screen>
+ <para>
+ Flow i Flow-portscan:
+ </para>
+ <screen># stats_interval . zapisywanie statystyk, 0 - wylaczone,
+# hash . wybor metody mieszania.
+preprocessor flow: stats_interval 0 hash 2
+# server-watchnet . adresy IP, na ktorych flow bedzie
+# prowadzic badania,
+# server-learning-time . czas utrzymania punktow dla danego adresu IP,
+# server-scanner-limit . ilosc zapytan decydujacych o przyznaniu
+# statusu
+# skanowania z danego adresu,
+# src-ignore-net, dst-ignore-net . lista ignorowanych adresow docelowych
+# i zrodlowych.
+preprocessor flow-portscan: \
+ server-watchnet [xxx.xxx.xxx.xxx/xx] \
+ server-learning-time 14400 \
+ server-scanner-limit 10 \
+ src-ignore-net [xxx.xxx.xxx.xxx/xx, xxx.xxx.xxx.xxx/xx] \
+ dst-ignore-net [xxx.xxx.xxx.xxx/xx]</screen>
+ <para>
+ Trzecia sekcja snort.conf, zawiera metody konfiguracji modułów
+ wyjściowych, czyli różnych sposobów logowania wyników i tzw.
+ akcji reguł. Na potrzeby tego opisu wymieniony będzie tylko
+ przykład logowania do bazy MySQL.
+ </para>
+ <screen>output database: alert, mysql, user=login password=haslo \
+dbname=snort_log host=127.0.0.1</screen>
+ <para>
+ Za pomocą reguł akcji można tworzyć własne rodzaje reakcji na
+ wykryte zdarzenie, np.:
+ </para>
+ <screen>ruletype czerwony_alarm
+ {
+ type log
+ # zapis do demona syslogd, lokalnie
+ output alert_syslog: LOG_ALER
+ }
+# Przykladowa regula:
+czerwony_alarm $HOME_NET any -> $HOME_NET 6667 (msg:"Internal IRC Server";)</screen>
+ <para>
+ Czwarta, ostatnia część, głównego pliku konfiguracyjnego,
+ zawiera odniesienia do zestawów reguł i wcześniej już
+ opisanych plików, classification.config, reference.config,
+ threshold.conf (przykład poniżej).
+ </para>
+ <screen>include classification.config
+include reference.config
+
+include $RULE_PATH/bad-traffic.rules
+include $RULE_PATH/exploit.rules
+include $RULE_PATH/telnet.rules
+include $RULE_PATH/rpc.rules
+include $RULE_PATH/dos.rules
+(...)
+# dodatkowy zestaw regul Bleeding Snort - http://www.bleedingsnort.com
+include $RULE_PATH/bleeding.rules
+include threshold.conf</screen>
+ <para>
+ Dostosowanie Snorta do swoich potrzeb obejmuje, obok
+ konfiguracji preprocesorów przede wszystkim decyzje, jakie
+ zbiory reguł mają być brane pod uwagę (czyli jakie pliki z
+ regułami mają być dołączane za pomocą polecenia include). W
+ środowisku, w którym wszystkie serwery WWW to Apache, reguły
+ chroniące serwer IIS będą generowały zupełnie niepotrzebne
+ alarmy. Jeśli nie udostępniamy FTP, reguły opisujące ataki na
+ tę usługę będą tylko spowalniały pracę całego systemu. To
+ sprawy oczywiste, jednak właściwe dostosowanie NIDS do swoich
+ potrzeb wymaga wiele pracy. Dobranie odpowiednich dla danego
+ środowiska reguł jest kluczowe dla działania całego systemu,
+ duża ilość fałszywych alarmów nie tylko zużywa zasoby (każda z
+ reguł musi być przecież przeanalizowana), ale może również
+ bardzo skutecznie "zaciemnić" obraz, sprawiając, że prawdziwy
+ atak może przejść niezauważony w zalewie informacji mało
+ istotnych. Obecna baza sygnatur liczy sobie około 2500 reguł i
+ jest praktycznie każdego dnia wzbogacana o nowe opisy ataków.
+ Dla przybliżenia występujących w bazie kategorii sygnatur,
+ opiszę jakiego rodzaju ataki wykrywają:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ attack-responses - odpowiedzi usług na próbę
+ ataku;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ backdoor - działalność tzw. tylnych drzwi,
+ trojanów, rootkitów;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ bad-traffic - nieprawidłowy ruch, np. na port
+ 0;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ chat - aktywność różnego rodzaju
+ komunikatorów;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ddod, dos - zmasowane ataki Distributed Denial
+ of Service (rozproszony atak typu - blokada
+ usługi);
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ deleted - regły przestarzałe, wykasowane;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ dns - ataki na usługę Domain Name System;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ experimental - zestaw eksperymentalnych reguł;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ exploit - programy mające na celu
+ wykorzystywanie błędów w oprogramowaniu;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ icmp-info, icmp - komunikaty ICMP z różnych
+ programów, testujących ruch;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ imap, pop2, pop3, smtp - ataki na systemy
+ pocztowe;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ info - próby logowania na usługi Telnet, Ftp;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ local - zestaw własnych reguł;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ misc - różne, dotyczące usług CVS, MS
+ Terminal, BOOT, UPnP itd.;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ multimedia - strumienie audio, wideo;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ mysql, sql, oracle - ataki na znane serwer baz
+ danych;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ netbios - anomalia związane z protokołem
+ Netbios/SMB;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ nntp - ataki na serwer grup dyskusyjnych;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ other-ids - działalność innych systemów IDS;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ p2p - aktywność programów Peer to Peer;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ policy - próby ataków na usługi policy ftp
+ itp.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ porn - aktywność stron portnograficznych;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ rpc - ataki na usługi Remote Procedure Call;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ finger, rservices, telnet - ataki na dość
+ słabo zabezpieczone usługi uniksowe: finger,
+ rlogin, rsh, rexec, telnet;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ scan - różnego rodzaju techniki skanowania
+ portów;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ shellcode - wykorzystanie nieprawidłowego kodu
+ do prób przepełnienia bufora;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ snmp - ataki na usługi SNMP;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ tftp, ftp - zdarzenia związane z przesyłaniem
+ plików poprzez serwer ftp;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ virus - transfer poczty z podejrzanym
+ załącznikiem;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ web-attacks, web-misc, web-client, web-cgi,
+ web-php, web-coldfusion, web-frontpage,
+ web-iis - ataki na różnego typu serwery WWW,
+ przeważnie z wykorzystaniem błędów w skryptach
+ cgi, php;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ x11 - aktywności sesji serwera XFree86.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section id="snort_aktualizacja">
+ <title>Aktualizacja reguł</title>
+ <para>
+ Do aktualizacji sygnatur posłuży nam perlowy skrypt
+ <ulink url="http://oinkmaster.sourceforge.net/">Oinkmaster</ulink>.
+ Ma on duże możliwości które pozwalają w prosty
+ sposób zarządzać regułami Snorta. Wymagane pakiety do
+ uruchomienia to: perl, perl-base, perl-modules i vixie-cron
+ albo hc-cron .
+ </para>
+ </section>
+ <section id="snort_install_oinkmaster">
+ <title>Instalacja Oinkmaster</title>
+ <para>
+ Ściągamy archiwum tar, rozpakowujemy, skrypt wgrywamy do
+ katalogu /usr/local/bin, a konfig do /etc:
+ </para>
+ <screen># wget --passive-ftp \
+ftp://ftp.it.su.se/pub/users/andreas/oinkmaster/oinkmaster-1.0.tar.gz
+# tar -zxvpf oinkmaster-1.0.tar.gz
+# cp oinkmaster-1.0/oinkmaster.pl /usr/local/bin/
+# cp oinkmaster-1.0/oinkmaster.conf /etc/</screen>
+ <para>
+ Operacja aktualizacji odbywa się po następującej sekwencji
+ komend:
+ </para>
+ <screen># /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/</screen>
+ <para>
+ Dodanie innego źródła reguł:
+ </para>
+ <screen># /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
+http://www.bleedingsnort.com/bleeding.rules.tar.gz</screen>
+ <para>
+ Aby aktualizacja odbywała się automatycznie, w katalogu
+ /etc/cron.daily tworzymy plik uprules.
+ </para>
+ <screen># touch /etc/cron.daily/uprules
+# chmod 700 /etc/cron.daily/uprules</screen>
+ <para>
+ I dodajemy do niego następującą zawartość, podając adres
+ e-mail na który ma zostać wysłany raport z codziennej
+ aktualizacji jeśli pojawia się coś nowego:
+ </para>
+ <screen>TMP=`mktemp /tmp/oinkmaster.XXXXXXXX` &&
+(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q > $TMP 2>&1;
+if [ -s $TMP ]; then mail -s "Update Snort Rules" root w twoja_domena < $TMP; fi;
+rm $TMP)
+
+# dodatkowy zestaw regul Bleeding Snort - http://www.bleedingsnort.com
+TMP=`mktemp /tmp/oinkmaster.XXXXXXXX` &&
+(/usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
+http://www.bleedingsnort.com/bleeding.rules.tar.gz > $TMP 2>&1;
+if [ -s $TMP ]; then mail -s "Update Bleeding Rules" root w twoja_domena < \
+$TMP; fi; rm $TMP)
+
+/etc/rc.d/init.d/snort restart</screen>
+ <para>
+ Warto przyjżeć się bliżej ciekawym funkcjonalnościom
+ oinkmastera. W pliku konfiguracyjnym mamy możliwość wyłączania
+ poszczególnych regułek po nr sid, dodawania do nich własnych
+ modyfikacji itp. Wtedy jest pewność że po aktualizacji, nasze
+ zmiany w plikach reguł nie będą nadpisywane.
+ </para>
+ </section>
+ <section id="snort_architektura">
+ <title>Architektura Snorta</title>
+ <para>
+ Snort jest logicznie podzielony na kilka komponentów, które
+ współpracują ze sobą by wykrywać ataki i generować wyniki w
+ odpowiednim formacie. Głównymi składnikami systemu są: dekoder
+ pakietów (sniffer), preprocesory, silnik detekcji i moduł
+ wyjściowy.
+ </para>
+ <para>
+ W swej najprostszej formie Snort może działać jako sniffer.
+ Przechwytuje pakiety z warstwy łącza danych za pomocą
+ biblioteki pcap. Rozpoznaje różne protokoły modelu OSI -
+ Ethernet, 802.11, Token Ring oraz wiele protokołów
+ działających w wyższych warstwach jak: IP, TCP, UDP i ICMP.
+ Surowe pakiety z warstwy łącza danych (np. ramki Ethernetowe)
+ po zdekodowaniu wądrują do preprocesorów (warstwa
+ transportowa), gdzie są testowane i w razie konieczności
+ obrabiane na potrzeby silnika detekcji (warstwa sesji). Tam
+ dokonywana jest analiza pakietów pod kątem zbioru zadanych
+ reguł. Następnie po wykryciu próby ataku bądź anomalii
+ sieciowych, system przekazuje odpowiednie dane do modułu
+ wyjściowego, który to decyduje o zapisaniu wyniku wykrycia w
+ logach lub wszczęciu alarmu.
+ </para>
+ </section>
+ <section id="snort_tryby_pracy">
+ <title>Tryby pracy</title>
+ <para>
+ Snort umożliwia dużą swobodę konfiguracji, za pomocą wielu
+ parametrów, które pozwalają kontrolować trzy podstawowe tryby
+ pracy programu: sniffer, packet logger i network intrusion
+ detection.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Sniffer Mode - wychwytuje wszystkie pakiety w
+ danym segmencie sieci i przedstawia ich
+ zawartość na ekranie. Najprostszym sposobem
+ użycia tego trybu jest uruchomienie programu z
+ parametrem -v w wyniku, czego Snort będzie
+ wyświetlać informacje o nagłówkach IP,
+ TCP/UDP/ICMP. Do uzyskania bardziej
+ szczegółowych danych o wychwyconych pakietach,
+ służą parametry -d (aby monitorować ładunek
+ pakietów) i -e (dodatkowe nagłówki warstwy
+ łącza danych). Parametry można łączyć razem,
+ bez znaczenia jest ich kolejność (np. snort
+ -ved). Aby zakończyć pracę w tym trybie należy
+ użyć sekwencji klawiszy CTRL+C.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Packet Logger Mode - logowanie pakietów
+ poprzez zapis na dysku. Czynność ta odbywa się
+ po użyciu opcji -l, którą wskazujemy katalog,
+ gdzie Snort będzie zapisywać w odpowiednio
+ nazwanych podkatalogach i plikach, zawartość
+ zebranych pakietów. Program potrafi także
+ zapisywać dane w formie binarnej tak jak robi
+ to znany sniffer tcpdump. Służy do tego opcja
+ -b, po jej użyciu nie trzeba stosować
+ dodatkowych kombinacji parametrów -ved,
+ ponieważ format tcpdump, określa to, co ma być
+ logowane (np. snort -b -l ./log). Uzyskane w
+ ten sposób informacje, można wykorzystać do
+ późniejszej analizy za pomocą programów
+ rozpoznających format binarny tcpdump (np.
+ Ethereal). Oczywiście można tą samą czynność
+ wykonać z wykorzystaniem Snorta, używając
+ opcji -r, po czym przetworzyć sczytane pakiety
+ dostępnymi trybami.
+ Snort czytając swoje dzienniki (tak samo
+ działając w trybie sniffera) przyjmuje
+ parametry w formacie BPF (Berkeley Packet
+ Filter), dzięki którym możemy sprecyzować (na
+ podstawie nagłówków), jakie konkretnie pakiety
+ chcemy obserwować (np. określić adres hosta,
+ protokół, port). Jeśli np. interesuje nas
+ tylko ruch na porcie 80 można uruchomić Snorta
+ poleceniem: snort -r /var/log/snort/snort.log
+ port www, jeśli chcemy wyświetlić tylko
+ odpowiedzi serwera www: snort -vde src port
+ www. Aby ignorować cały ruch z sieci np.
+ 192.168.1.0 na port 80: snort -vde not ( src
+ net 192.168.1 and dst port 80 ).
+ Połączenie Snorta z filtrami BPF znacznie
+ zwiększa wydajność całego systemu, gdyż
+ filtrowanie BPF odbywa się w warstwie łącza
+ danych (a więc na poziomie biblioteki pcap).
+ Określając w ten sposób, jakie pakiety nas
+ interesują (lub jakie chcemy zignorować) można
+ dość dokładnie "zawęzić" obszar poszukiwań.
+ Filtry BPF można również zapisać w oddzielnym
+ pliku i załadować w trakcie uruchamiania
+ Snorta parametrem -F: snort -r snort.log -F
+ plik_z_bdf. Więcej na temat możliwości
+ oferowanych przez BPF można poczytać na
+ stronach podręcznika zarówno Snorta, jak i
+ Tcpdump.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Network Intrusion Detection Mode - sieciowy
+ system wykrywania włamań. Jest najbardziej
+ skomplikowanym trybem działania programu. Za
+ pomocą parametru -c, wskazujemy plik
+ konfiguracyjny, w którym określane są zasady
+ badania przechwyconego ruchu sieciowego,
+ ustawienia preprocesorów, a także zestaw
+ sygnatur ataków. Aby program działał w tle
+ jako demon, należy użyć opcji -D (np. snort -d
+ -D -c snort.conf). Reszta operatorów i ich
+ opisy, jakie można wykorzystać przy starcie
+ programu, przedstawia parametr -h.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section id="snort_preprocesory">
+ <title>Preprocesory</title>
+ <para>
+ Preprocesory zostały wprowadzone do Snorta w wersji 1.5.
+ Pozwalają użytkownikom i programistom w prosty sposób na
+ rozbudowę funkcjonalności całego systemu poprzez pisanie
+ dodatkowych modułów (ang. plugins).
+ </para>
+ <para>
+ Preprocesory analizują pakiety przed wykorzystaniem ich przez
+ silnik detekcji. W ten sposób zwiększają możliwości całego
+ procesu wykrywania ataków sieciowych, wzbogacając go o
+ zdolność składania (reasemblacji) pakietów, wykonywania
+ specyficznych dla poszczególnych protokołów operacji (np.
+ konwersja na ASCII znaków z URI zakodowanych szesnastkowo,
+ usuwanie ciągów binarnych z sesji FTP czy Telnet, normalizacja
+ żądań RPC), jak i wykrywania niezgodności z tymi protokołami.
+ </para>
+ <para>
+ Poniżej pokrótce opiszemy standardowy zestaw
+ preprocesorów wchodzących w skład darmowej dystrybucji Snorta
+ w wersji 2.1.3.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Frag2 - defragmentuje i normalizuje dane
+ przychodzące w postaci fragmentów, co utrudnia
+ ukrywanie ataków prowadzonych za pomocą
+ nieprawidłowo sfragmentowanych pakietów IP. W
+ tym celu wykorzystuje ustalony przez
+ użytkownika bufor pamięci, w której przez
+ określony czas przetrzymuje do badania pakiety
+ z tablicy stanów połączeń. Im większa liczba
+ sfragmentowanych pakietów tym wymagany jest
+ większy bufor. Defragmentacja, układając
+ datagramy IP w jedną całość, ułatwia dalszą
+ analizę danych poprzez pozostałe preprocesory
+ i silnik detekcji. Frag2 umożliwia
+ wychwytywanie znanych ataków wykorzystujących
+ zniekształcenia fragmentów pakietów np.
+ teardrop, fragroute.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Stream4 - rozwija model detekcji oparty na
+ testowaniu pojedynczych pakietów umożliwiając
+ śledzenie sesji (stanu połączenia) TCP i
+ składanie (reasemblacji) strumieni TCP, co nie
+ byłoby możliwe w mechanizmie opartym na
+ wyszukiwaniu wzorców. Na tym poziomie działa
+ także wykrywanie niektórych prób skanowania
+ portów, gdzie wymagane jest notowanie prób
+ łączenia się z poszczególnymi usługami w
+ określonych odstępach czasu oraz wykrywanie
+ prób oszukania Snorta za pomocą narzędzi
+ takich, jak np. Stick lub Snot, które generują
+ pojedyncze (niewchodzące w skład poprawnych
+ sesji TCP) pakiety mające za zadanie zalać
+ mechanizm detekcji masą fałszywych alarmów (są
+ to pakiety budowane na losowo wybranych
+ sygnaturach). Snort broni się przed takimi
+ technikami wykorzystując stream4 preprocesor -
+ losowe pakiety są dość łatwo identyfikowane (i
+ ignorowane), ponieważ nie należą do
+ prawidłowej sesji TCP. Stream4 wychwytuje
+ próby skanowania technikami: stealth, null,
+ xmas, fin; wykrywanie systemu operacyjnego -
+ fingerprint i inne anomalia związane z
+ protokołem TCP.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Flow i Flow-Portscan - posiada mechanizm
+ śledzenia połączeń, zapisując całość do
+ tablicy stanów w celu dalszego przetwarzania.
+ Na tej podstawie flow-portscan wykrywa próby
+ skanowania w bardziej wyrafinowany sposób niż
+ preprocesory stream4 i portscan. Celem
+ wykrywania, są skany z jednego hosta do wielu
+ i z jednego hosta na wiele portów.
+ Flow-portscan prowadzi statystyki na podstawie
+ punktacji różnych rodzajów połączeń, np. jeśli
+ jakaś usługa jest popularna i na jej port
+ przychodzi dużo zapytań, jednocześnie dostaje
+ najmniej punktów w ogólnej skali. Preprocesor
+ posiada bardzo wiele opcji za pomocą, których
+ reguluje się skale punktacji, rozmiary tablicy
+ wyników, tolerancję niepowtarzalności zdarzeń
+ itp.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ HTTP Inspect - jest ogólnym dekoderem
+ protokołu HTTP na poziomie warstwy
+ aplikacyjnej. Za pomocą ustalonego bufora
+ wynajduje odpowiednią składnie HTTP i ją
+ normalizuje. HTTP Inspekt działa w obydwu
+ trybach jednocześnie: client requests (pol.
+ zapytania klienta) i server responses (pol.
+ odpowiedzi serwera). Mnoga liczba dostępnych
+ opcji w konfiguracji preprocesora, umożliwia
+ dostosowanie ustawień do konkretnego typu
+ serwera WWW.
+ Głównymi zadaniami http_inspect jest
+ przetwarzanie adresów URI, konwertując na
+ ASCII znaki zakodowane w postaci
+ szesnastkowej. Utrudnia to ukrycie ataku przed
+ modułem wykrywającym sygnatury ataków przez
+ zakodowanie typowych sekwencji. Dekoduje także
+ znaki zakodowane jako Unicode, oraz wykrywa
+ nielegalne kodowania, wykorzystywane m.in. w
+ ostatnich dziurach MS IIS.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Portscan Detector - wykrywa próby skanowania
+ portów, polegające na przekroczeniu pewnej
+ progowej liczby prób połączeń z różnymi
+ portami w określonym przedziale czasu. Ze
+ względu na brak możliwości uniknięcia
+ fałszywych alarmów w typowych przypadkach (np.
+ obciążony serwer DNS), istnieje możliwość
+ wyłączenia alarmów wzbudzanych przez określone
+ adresy IP używając dodatkowego procesora
+ portscan-ignorehosts. Pozwala także, zapisać
+ wyniki w oddzielnym pliku dziennika.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Telnet Decode - usuwa z sesji TELNET i FTP
+ binarne ciągi mogące utrudnić wyszukiwanie z
+ udziałem sygnatur ataków.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ RPC Decode - normalizuje żądania po protokole
+ RPC, utrudniając ukrywanie podejrzanych
+ pakietów za pomocą mniejszych operacji.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Back Orifice detektor - wyszukuje w pakietach
+ UDP próby połączeń konia trojańskiego Back
+ Orifice i próbuje złamać zabezpieczające je
+ słabe kodowanie.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Arpspoof - wykrywa podejrzane pakiety ARP,
+ mogące sygnalizować próby ARP spoofingu.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Performance Monitor - udostępnia wszelkiego
+ rodzaju statystyki liczbowe, odnośnie ilości
+ przeanalizowanych pakietów, zużycia procesora
+ itp. Całość wyświetlana jest na ekranie
+ konsoli lub zapisywana do pliku, wg ustalonych
+ wcześniej wartości.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Zarówno preprocesory, jak i mechanizm detekcji mogą zareagować
+ w określony sposób. Po wychwyceniu pakietów, spełniających
+ warunki nadane konfiguracją preprocesorów lub regułami,
+ podejmowane jest odpowiednie działanie (np. zapisanie pakietów
+ bądź alarm).
+ </para>
+ </section>
+ <section id="snort_sygnatury">
+ <title>Moduł sygnatur</title>
+ <para>
+ Główny mechanizm systemu detekcji zagrożeń polega na
+ dopasowaniu przetworzonych pakietów i ich zrekonstruowanych
+ strumieni z bazą sygnatur. System detekcji porównuje cechy
+ pakietu ze zbiorem reguł. Po dopasowaniu, zostaje podjęta
+ odpowiednia akcja. Do porównywalnych cech należą atrybuty
+ główne - adresy, porty źródłowe i docelowe oraz opcje
+ pomocnicze: flagi TCP identyfikujące np. żądania związane z
+ WWW, różne typy pakietów ICMP, opcje IP czy wreszcie sama
+ treść pakietu. Na razie w głównej części reguł możliwe jest
+ śledzenie protokołów IP, ICMP, TCP i UDP. Autorzy przewidują
+ rozszerzenie Snorta o następne protokoły sieciowe, m.in. IPX,
+ GRE, czy protokoły wymiany informacji między routerami - RIP,
+ OSPF oraz IGRP.
+ </para>
+ <para>
+ Reguły identyfikowania ataku pozwalają na podjęcie pięciu
+ rodzajów akcji: przepuszczenia pakietu (pass), zapisania
+ informacji do dziennika (log), ogłoszenia alarmu (alert),
+ alarmowania i podjęcia do działania innej dynamicznej reguły
+ (activate) i pozostanie w spoczynku do czasu aktywowania przez
+ regułę activate, po czym działanie jako reguła log (dynamic).
+ </para>
+ <para>
+ Sygnatury Snorta zazwyczaj składają się z dwóch głównych
+ sekcji - nagłówka i ciała (treści). Nagłówek określa m.in.,
+ jaką akcję należy podjąć po przypasowaniu reguły, informacje o
+ wykorzystanym protokole, adresy bądź porty źródłowe i
+ docelowe. Ciało reguły pozwala rozwinąć informacje zawarte w
+ nagłówku, tu także podaje sią treść wzbudzanych alarmów i
+ różnego rodzaju informacje dodatkowe (np. odniesienia do bazy
+ z opisami danego naruszenia, tzw. referencje -
+ <ulink url="http://www.securityfocus.com/bid">Bugtraq</ulink>,
+ <ulink url="http://www.cert.org/">CERT</ulink> czy
+ <ulink url="http://www.cve.mitre.org/">CVE</ulink>).
+ </para>
+ <para>
+ Najprostsze sygnatury obejmują wskazanie akcji, protokołu,
+ kierunku, adresów i portów będących przedmiotem obserwacji,
+ jak np. poniższa reguła, stanowiąca reakcję na próbę
+ skorzystania z usługi pop3 (port 110):
+ </para>
+ <screen>log tcp any any -> 192.168.1.0/24 110</screen>
+ <para>
+ W sygnaturach można umieszczać zmienne zdefiniowane jako
+ adresy sieci (wg CIDR) lub porty zapisane w pliku
+ konfiguracyjnym snort.conf:
+ </para>
+ <screen>log tcp $EXTERNAL_NET -> $HOME_NET 110</screen>
+ <para>
+ W podanych powyżej regułach wykorzystany był jednokierunkowy
+ operator "->". Język sygnatur umożliwia zadeklarowanie reguły,
+ który dopasuje pakiety poruszające się w obu stronach
+ operatorem dwukierunkowym "<>", np.:
+ </para>
+ <screen>alert tcp any any <> $HOME_NET 23</screen>
+ <para>
+ Do zasadniczej części reguły można dodać ograniczone okrągłymi
+ nawiasami pole opcjonalne (tzw. ciało), zawierające definicję
+ bardziej złożonych i wyrafinowanych działań związanych z
+ przejęciem danego pakietu. Użytkownik może także sformułować
+ własny komunikat, np.:
+ </para>
+ <screen>log tcp $EXTERNAL_NET -> $HOME_NET 110 ("msg: Proba polaczenia z pop3";)</screen>
+ <para>
+ Podjęte działania nie muszą być ograniczone do pojedynczej
+ czynności. Średnik separuje deklaracje poszczególnych działań,
+ jak w poniższym przykładzie, w którym opcją content testowana
+ jest treść przesyłanego strumienia TCP, a w razie odnotowania
+ podejrzanego ciągu znaków generowany jest odpowiedni
+ komunikat:
+ </para>
+ <screen>alert tcp any any -> 192.168.1.0/24 80 (content: "/cgi-bin/phf"; msg: "PHF probe!";)</screen>
+ <para>
+ Opcji content można użyć nawet kilka razy w jednej regule.
+ Pozwala to na wyszukiwanie wielu różnych ciągów znaków w
+ obrębie przesyłanych treści.
+ </para>
+ <para>
+ Warto nadmienić, iż do przeszukania treści pakietów i
+ reasemblowanych strumieni używany jest obecnie najbardziej
+ efektywny algorytm - Boyera-Moore'a, którego wydajność rośnie
+ wraz z długością poszukiwanych ciągów. Możliwość rekonstrukcji
+ całych strumieni transmisji TCP, wglądu w warstwę aplikacyjną
+ i efektywne wyszukiwanie treści pozwala na walkę przy użyciu
+ Snorta również z zainfekowanymi załącznikami elektronicznych
+ listów. Oprócz przeszukiwania treści pakietów możemy badać pod
+ różnymi kątami ich nagłówki, m.in. pola i kody ICMP, pole TTL,
+ rozmiary fragmentacji czy numery sekwencji.
+ </para>
+ <para>
+ Bardzo silną konstrukcją w regułach Snorta jest możliwość
+ aktywowania kolejnych reguł po pierwszym dopasowaniu.
+ Konstrukcja ta nosi nazwę activate/dynamic rules i wygląda w
+ następujący sposób:
+ </para>
+ <screen>activate tcp any any -> $HOME_NET 143 (flags: PA; content: \
+"|E8C0FFFFFF|bin|;activates: 1; msg: "IMAP buffer overflow!";)
+dynamic tcp any any -> $HOME_NET 143 (activated_by: 1; count: 50;)</screen>
+ <para>
+ Opcje activates i activated_by wiążą reguły activate i
+ dynamic. W powyższym przykładzie wykrycie ataku typu buffer
+ overflow na serwer IMAP powoduje uruchomienie kolejnej,
+ dynamicznej reguły, która zbiera treść następnych 50 pakietów
+ (opcja count) w celu późniejszej analizy. Druga opcja w reguły
+ dynamicznej jest obligatoryjna - reguła zawierająca wyłącznie
+ opcję dowiązania do innej, macierzystej konstrukcji jest
+ bezużyteczna.
+ </para>
+ <para>
+ Następne godne uwagi parametry, to resp i react wspierają
+ mechanizm elastycznego reagowania na atak. Opcja resp może
+ doprowadzić do zerwania połączenia, np. poprzez wysłanie do
+ atakującego komunikatu ICMP o niedostępności trasy do
+ zaatakowanego komputera, natomiast react służy do blokowania
+ dostępu do usług związanych z WWW.
+ </para>
+ </section>
+ <section id="snort_projekty">
+ <title>Ciekawe projekty</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink
+ url="http://www.nessus.org/">Nessus</ulink>
+ - sieciowy tester
+ bezpieczeństwa, przydatny do
+ określania skuteczności
+ skonfigurowanego przez nas
+ Snorta.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink
+ url="http://jeremy.chartier.free.fr/snortalog/">SnortALog</ulink>
+ - skrypt Perlowy pozwalający
+ na generowanie różnego rodzaju
+ raportów, grafów i statystyk.
+ Korzystając z logów Snorta,
+ format wygenerowanych raportów
+ może stanowić plik tekstowy,
+ HTML, a nawet PDF.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink
+ url="http://snort-inline.sf.net/">Snort
+ Inline</ulink> - poprawka dla
+ Snorta, umożliwiająca współprace z
+ regułami firewalla IPtables,
+ stosowanego w systemach opartych na
+ jądrze Linux. Specjalnie sformułowane
+ sygnatury Snorta, reagują na atak i
+ blokują bądź przekierowują za pomocą
+ ściany ogniowej drogę pakietów
+ pochodzących od intruza.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink
+ url="http://www.snortsam.net/">SnortSam</ulink>
+ - jest to zestaw pluginów do Snorta
+ pełniących podobną funkcje jak Snort
+ Inline, ale wspomagająca większą
+ liczbę różnego rodzaju zapór ogniowych
+ (m.in. Checkpoint Firewall-1, Cisco
+ PIX, Cisco Routers z ACL, Netscreen,
+ IP Filter dla *BSD, Linux IPchains,
+ Linux IPtables, WatchGuard Firebox).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink
+ url="http://www.geschke-online.de/FLoP/">FLoP</ulink>
+ - projekt ma na celu, przyspieszenie
+ logowania w procesie wykrywania
+ włamań. Do tego wykorzystuje
+ odpowiednie bufory i możliwość
+ szybkiego zapisu przez gniazdo unixowe
+ do baz danych MySQL i PostgreSQL.
+ Bardzo przydatne narzędzie przy pracy
+ w sieciach o dużej przepustowości.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+</section>
Więcej informacji o liście dyskusyjnej pld-doc