PLD-doc/queue/PLD_snort.html
krolik
cvs w pld-linux.org
Czw, 1 Lip 2004, 12:24:43 CEST
Author: krolik
Date: Thu Jul 1 10:24:41 2004
New Revision: 4282
Added:
PLD-doc/queue/PLD_snort.html
Log:
- kolejny doc do kolejki
Added: PLD-doc/queue/PLD_snort.html
==============================================================================
--- (empty file)
+++ PLD-doc/queue/PLD_snort.html Thu Jul 1 10:24:41 2004
@@ -0,0 +1,767 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+"http://www.w3.org/TR/html4/loose.dtd">
+<html>
+
+<head>
+ <title>Snort - Sieciowy System Wykrywania W艂ama艅</title>
+ <meta name="GENERATOR" content="Quanta Plus">
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <style type="text/css">
+<!--
+
+pre {
+ font-family: courier;
+ padding: 4;
+ color: #ffffff;
+ background-color: #000000;
+ font-size: 11pt;
+}
+
+h2 {
+ font-family: verdana;
+ font-size: 16pt;
+}
+
+h3 {
+ font-family: verdana;
+ font-size: 14pt;
+}
+
+-->
+</style>
+</head>
+<body link="darkGreen" alink="darkGreen" vlink="darkGreen"
+style="font-family:verdana;font-size:11pt">
+
+<h1>Snort - Sieciowy System Wykrywania W艂ama艅</h1>
+
+<p><A href="http://www.snort.org">Snort</A> 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.</p>
+
+<h2>Wymagania</h2>
+<p>Przed instalacj膮 Snorta warto zaopatrzy膰 si臋 w baz臋 danych (w
+opisie wykorzystano <A href="http://www.mysql.com/">MySQL</A>) i serwer <A
+href="http://www.apache.org">Apache</A> z obs艂ug膮 <A
+href="http://www.php.net">PHP</A>. W bazie b臋d膮 sk艂adowane
+logi, a za wygodny interfejs do przegl膮dania alarm贸w pos艂u偶y <A
+href="http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html">ACID</A>
+(ang. Analysis Console for Intrusion Databases).</p>
+
+<h2>Instalacja Snorta i ACID</h2>
+<p>Gdy mamy ju偶 baz臋 danych i serwer WWW z <A href="http://www.php.net">PHP</A>,
+instalujemy nast臋puj膮ce pakiety.</p>
+<pre>poldek> install snort acid</pre>
+<p>Przed konfiguracja 艣rodowiska NIDS zak艂adamy dwie bazy, dla Snorta i dla
+archiwum alarm贸w.</p>
+<pre>
+# 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
+</pre>
+<p>Dodajemy tabele w taki sam spos贸b dla obu baz.</p>
+<pre>
+# 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
+</pre>
+<p>Nast臋pnie (najpro艣ciej przy u偶yciu popularnego narz臋dzia <A
+href="http://www.phpmyadmin.net/">phpMyAdmin</A>) tworzymy u偶ytkownika i
+nadajemy mu prawa dla stworzonych baz. </p>
+
+<p>Przechodzimy do edycji pliku <em>/etc/acid_conf.php</em>, w kt贸rym dodajemy
+parametry dla po艂膮czenia si臋 z bazami.</p>
+<pre>
+[...]
+/* 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";
+[...]
+</pre>
+
+<p>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.</p>
+<p>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.</p>
+
+<h2>Konfiguracja Snorta</h2>
+<p>Do dzia艂ania jako sieciowy system wykrywania w艂ama艅, Snort
+potrzebuj臋 sprecyzowania zasad funkcjonowania ca艂o艣ci w g艂贸wnym pliku
+konfiguracyjnym <em>snort.conf</em>. 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艣膰
+<em>snort.conf</em> zosta艂a przywr贸cona przy u偶yciu polecenia <em>include</em>,
+kt贸rym do艂膮cza si臋 odpowiednie zestawy sygnatur i inne cz臋艣ci konfiguracyjne, np.: </p>
+<pre>include: 艣cie偶ka_do_pliku/nazwa</pre>
+<p>Bazy regu艂 charakteryzuj膮 si臋 nazw膮 pliku z ko艅c贸wk膮 <em>.rules</em>,
+pierwszy cz艂on nazwy zawiera rodzaj us艂ugi lub typ ataku, kt贸rego dotyczy dany zestaw.
+Pozosta艂ymi plikami konfiguracyjnymi s膮: </p>
+<p>Pozosta艂ymi plikami konfiguracyjnymi s膮: </p>
+<ul>
+<li><i>classification.config</i> - zawieraj膮cy klasyfikatory rodzaj贸w
+atak贸w z nadanym priorytetem zagro偶enia, tak jak poni偶ej: </li>
+<pre>
+config classification: web-application-attack,Web Application Attack,1
+</pre>
+<li><i>reference.config</i> - posiadaj膮cy skr贸ty adres贸w do stron
+organizacji z baz膮 opis贸w atak贸w, np.: </li>
+<pre>config reference: bugtraq http://www.securityfocus.com/bid/</pre>
+<li><i>threshold.conf</i> - metody 艂agodzenia licznych, fa艂szywych
+alarm贸w, </li>
+<li><i>unicode.map</i> - zestaw kodowanych znak贸w unicode, na
+potrzeby preprocesora http_inspect. </li>
+</ul>
+
+<p>G艂贸wny plik konfiguracyjny mo偶na podzieli膰 na cztery sekcje.
+Pierwsza, odpowiedzialna jest za ustalanie zmiennych <em>var</em>,
+wykorzystywanych w sk艂adni regu艂 atak贸w.</p>
+<p>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
+<em>/etc/snort</em>, a regu艂ki w <em>/etc/snort/rules</em>.</p>
+<pre>
+# 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,]
+# Scieszka do katalogu z regulami atakow
+var RULE_PATH /etc/snort/rules
+</pre>
+
+<p>W tej samej sekcji znajduje si臋 zestaw parametr贸w
+uruchomieniowych, zaczynaj膮cych si臋 od wyra偶enia <em>config</em> (pe艂na ich
+lista znajduj臋 si臋 w dokumentacji):</p>
+<pre>
+# wybor interfejsu do nas艂uchu (jeden demon Snorta moze obslugiwac tylko jeden
+# interfejs sieciowy)
+config interface: eth0
+</pre>
+
+<p>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.<br>
+Oto przyk艂ady ustawie艅 preprocesor贸w:</p>
+
+<p><strong>Frag2:</strong>
+<pre>
+# detect_state_problems 鈥 zwraca alarm przy pokrywaniu sie fragmentow.
+preprocessor frag2: detect_state_problems
+</pre></p>
+
+<p><strong>Stream4, Stream4_reassemble:</strong>
+<pre>
+# 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 ]
+</pre></p>
+
+<p><strong>Http_inspect: </strong>
+<pre>
+# 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 }
+</pre></p>
+
+<p>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膮.</p>
+
+<p><strong>RPC_decode, Back Orfice, Telnet_decode, Arpspoof, Performance
+Monito:</strong>
+<pre>
+# 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
+</pre></p>
+
+<p><strong>Flow i Flow-portscan: </strong>
+<pre>
+# 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]
+</pre></p>
+
+<p>Trzecia sekcja <em>snort.conf</em>, 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.</p>
+
+<pre>
+output database: alert, mysql, user=login password=haslo \
+dbname=snort_log host=127.0.0.1
+</pre>
+
+<p>Za pomoc膮 regu艂 akcji mo偶na tworzy膰 w艂asne rodzaje reakcji na wykryte
+zdarzenie, np.:</p>
+<pre>
+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";)
+</pre>
+
+<p>Czwarta, ostatnia cz臋艣膰, g艂贸wnego pliku konfiguracyjnego, zawiera odniesienia
+do zestaw贸w regu艂 i wcze艣niej ju偶 opisanych plik贸w,
+<em>classification.config</em>,
+<em>reference.config</em>, <em>threshold.conf</em> (przyk艂ad poni偶ej).</p>
+
+<pre>
+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
+</pre>
+
+<p>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膮: </p>
+
+<ul>
+<li><strong>attack-responses</strong> 鈥 odpowiedzi us艂ug na pr贸b臋 ataku;</li>
+<li><strong>backdoor</strong> 鈥 dzia艂alno艣膰 tzw. tylnych drzwi, trojan贸w,
+rootkit贸w; </li>
+<li><strong>bad-traffic</strong> 鈥 nieprawid艂owy ruch, np. na port 0; </li>
+<li><strong>chat</strong> 鈥 aktywno艣膰 r贸偶nego rodzaju komunikator贸w; </li>
+<li><strong>ddod, dos</strong> 鈥 zmasowane ataki Distributed Denial of Service
+(rozproszony atak typu - blokada us艂ugi); </li>
+<li><strong>deleted</strong> 鈥 reg艂y przestarza艂e, wykasowane; </li>
+<li><strong>dns</strong> 鈥 ataki na us艂ug臋 Domain Name System; </li>
+<li><strong>experimental</strong> 鈥 zestaw eksperymentalnych regu艂; </li>
+<li><strong>exploit</strong> 鈥 programy maj膮ce na celu wykorzystywanie b艂臋d贸w w
+oprogramowaniu; </li>
+<li><strong>icmp-info, icmp</strong> 鈥 komunikaty ICMP z r贸偶nych program贸w,
+testuj膮cych ruch; </li>
+<li><strong>imap, pop2, pop3, smtp</strong> 鈥 ataki na systemy pocztowe; </li>
+<li><strong>info</strong> 鈥 pr贸by logowania na us艂ugi Telnet, Ftp; </li>
+<li><strong>local</strong> 鈥 zestaw w艂asnych regu艂; </li>
+<li><strong>misc</strong> 鈥 r贸偶ne, dotycz膮ce us艂ug CVS, MS Terminal, BOOT, UPnP
+itd.; </li>
+<li><strong>multimedia</strong> 鈥 strumienie audio, wideo; </li>
+<li><strong>mysql, sql, oracle</strong> 鈥 ataki na znane serwer baz danych;
+</li>
+<li><strong>netbios</strong> 鈥 anomalia zwi膮zane z protoko艂em Netbios/SMB; </li>
+<li><strong>nntp</strong> 鈥 ataki na serwer grup dyskusyjnych; </li>
+<li><strong>other-ids</strong> 鈥 dzia艂alno艣膰 innych system贸w IDS; </li>
+<li><strong>p2p</strong> 鈥 aktywno艣膰 program贸w Peer to Peer; </li>
+<li><strong>policy</strong> 鈥 pr贸by atak贸w na us艂ugi policy ftp itp. </li>
+<li><strong>porn</strong> 鈥 aktywno艣膰 stron portnograficznych; </li>
+<li><strong>rpc</strong> 鈥 ataki na us艂ugi Remote Procedure Call; </li>
+<li><strong>finger</strong>, rservices, telnet 鈥 ataki na do艣膰 s艂abo
+zabezpieczone us艂ugi uniksowe: finger, rlogin, rsh, rexec, telnet; </li>
+<li><strong>scan</strong> 鈥 r贸偶nego rodzaju techniki skanowania port贸w; </li>
+<li><strong>shellcode</strong> 鈥 wykorzystanie nieprawid艂owego kodu do pr贸b
+przepe艂nienia bufora; </li>
+<li><strong>snmp</strong> 鈥 ataki na us艂ugi SNMP; </li>
+<li><strong>tftp, ftp</strong> 鈥 zdarzenia zwi膮zane z przesy艂aniem plik贸w
+poprzez serwer ftp; </li>
+<li><strong>virus</strong> 鈥 transfer poczty z podejrzanym za艂膮cznikiem; </li>
+<li><strong>web-attacks, web-misc, web-client, web-cgi, web-php, web-coldfusion,
+web-frontpage, web-iis</strong> 鈥 ataki na r贸偶nego typu serwery WWW, przewa偶nie
+z wykorzystaniem b艂臋d贸w w skryptach cgi, php; </li>
+<li><strong>x11-</strong> aktywno艣ci sesji serwera XFree86. </li>
+</ul>
+
+<h2>Aktualizacja regu艂</h2>
+
+<p>Do aktualizacji sygnatur pos艂u偶y nam perlowy skrypt <A
+href="http://oinkmaster.sourceforge.net/">Oinkmaster</A>. 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 .</p>
+
+<h2>Instalacja Oinkmaster</h2>
+
+<p>艢ci膮gamy archiwum tar, rozpakowujemy, skrypt wgrywamy do katalogu
+<em>/usr/local/bin</em>, a konfig do <em>/etc</em>:</p>
+<pre>
+# 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/
+</pre>
+
+<p>Operacja aktualizacji odbywa si臋 po nast臋puj膮cej sekwencji komend:</p>
+<pre># /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/</pre>
+<p>Dodanie innego 藕r贸艂a regu艂:</p>
+<pre>
+# /usr/local/bin/oinkmaster.pl -o /etc/snort/rules/ -q -u \
+http://www.bleedingsnort.com/bleeding.rules.tar.gz
+</pre>
+
+
+<p>Aby aktualizacja odbywa艂a si臋 automatycznie, w katalogu
+<em>/etc/cron.daily</em> tworzymy plik <em>uprules</em>.</p>
+<pre>
+# touch /etc/cron.daily/uprules
+# chmod 700 /etc/cron.daily/uprules
+</pre>
+<p>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:</p>
+<pre>
+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
+</pre>
+
+<p>
+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.
+</p>
+
+
+<h2>Troch臋 teorii - Architektura Snorta</h2>
+
+<p>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.
+</p>
+<p>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. <br>Surowe pakiety z warstwy 艂膮cza danych (np. ramki
+Ethernetowe) po <u>zdekodowaniu</u> w膮druj膮 do
+
+<u>preprocesor贸w</u> (warstwa transportowa), gdzie s膮
+testowane i w razie konieczno艣ci obrabiane na potrzeby <u>silnika
+detekcji</u> (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 <u>modu艂u wyj艣ciowego</u>,
+kt贸ry to decyduje o zapisaniu wyniku wykrycia w logach lub
+wszcz臋ciu alarmu.
+
+</p>
+
+
+<h3>Tryby pracy</h3>
+<p>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.
+</p>
+
+<ul>
+ <li><b>Sniffer Mode</b> - wychwytuje wszystkie pakiety w danym segmencie sieci
+i przedstawia ich
+zawarto艣膰 na ekranie. Najprostszym sposobem u偶ycia tego trybu jest
+uruchomienie programu z parametrem <b><i>-v</i> </b>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 <i><b>-d</b> </i>(aby
+monitorowa膰 艂adunek pakiet贸w) i <b><i>-e</i></b> (dodatkowe
+nag艂贸wki warstwy 艂膮cza danych). Parametry mo偶na 艂膮czy膰 razem,
+bez znaczenia jest ich kolejno艣膰 (np. <b><i>snort -ved</i></b>). Aby
+zako艅czy膰 prac臋 w tym trybie nale偶y u偶y膰 sekwencji klawiszy
+CTRL+C.</li>
+
+ <li><b>Packet Logger Mode </b> - logowanie pakiet贸w poprzez zapis
+na dysku. Czynno艣膰 ta odbywa si臋 po u偶yciu opcji <b><i>-l</i></b>,
+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 <A href="http://www.tcpdump.org/"
+target="_blank">tcpdump</A>. S艂u偶y do tego
+opcja <i><b>-b</b>,</i> po jej u偶yciu nie trzeba stosowa膰
+dodatkowych kombinacji parametr贸w <i><b>-ved</b>,</i> poniewa偶 format
+tcpdump, okre艣la to, co ma by膰 logowane (np. <b><i>snort -b -l ./log</i></b>).
+Uzyskane w ten spos贸b informacje, mo偶na wykorzysta膰 do
+p贸藕niejszej analizy za pomoc膮 program贸w rozpoznaj膮cych format
+binarny tcpdump (np. <a href="http://www.ethereal.com/"
+target="_blank">Ethereal</a>).
+Oczywi艣cie mo偶na t膮 sam膮 czynno艣膰 wykona膰
+z wykorzystaniem Snorta, u偶ywaj膮c opcji <b><i>-r</i></b>, po czym
+przetworzy膰 sczytane pakiety dost臋pnymi trybami. <br>
+
+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: <i><b>snort
+-r /var/log/snort/snort.log port www</b></i>, je艣li chcemy
+wy艣wietli膰 tylko odpowiedzi serwera www: <i><b>snort -vde src port www</b></i>.
+Aby ignorowa膰 ca艂y ruch z sieci np. 192.168.1.0 na port 80: <i><b>snort
+-vde not ( src net 192.168.1 and dst port 80 )</b></i>.<br>
+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 <b><i>-F</i></b>: <b><i>snort -r snort.log -F plik_z_bdf</i></b>.
+Wi臋cej na temat mo偶liwo艣ci oferowanych przez BPF mo偶na poczyta膰 na
+stronach podr臋cznika zar贸wno Snorta, jak i Tcpdump.</li>
+ <li><b>Network Intrusion Detection Mode</b> - sieciowy system wykrywania
+w艂ama艅. Jest najbardziej skomplikowanym trybem dzia艂ania programu.
+Za pomoc膮 parametru <b><i>-c</i></b>, 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 <b><i>-D</i></b>
+
+(np. <b><i>snort -d -D -c snort.conf</i></b>). Reszta
+operator贸w i ich opisy, jakie mo偶na wykorzysta膰 przy starcie
+programu, przedstawia parametr <b><i>-h</i></b>.</li>
+</ul>
+
+<h3>Preprocesory</h3>
+<p>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).
+</p>
+<p>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.
+</p>
+<p>Poni偶ej pozwol臋 sobie pokr贸tce opisa膰 standardowy zestaw
+preprocesor贸w wchodz膮cych w sk艂ad darmowej dystrybucji Snorta w wersji 2.1.3.
+</p>
+<ul>
+
+ <li><b>Frag2</b> - 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.</li>
+ <li><b>Stream4</b> - 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.</li>
+ <li><b>Flow i Flow-Portscan</b> - posiada mechanizm 艣ledzenia
+po艂膮cze艅, zapisuj膮c ca艂o艣膰 do tablicy stan贸w w celu dalszego przetwarzania. Na
+tej podstawie <b>flow-portscan</b>
+
+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.</li>
+
+ <li><b>HTTP Inspect</b> - 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: <i>client requests</i> (pol. zapytania klienta) i <i>server
+responses</i> (pol. odpowiedzi serwera). Mnoga liczba dost臋pnych opcji
+w konfiguracji preprocesora, umo偶liwia dostosowanie ustawie艅 do
+konkretnego typu serwera WWW.<br>
+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.</li>
+ <li><b>Portscan Detector</b> - 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 <b>portscan-ignorehosts</b>. Pozwala tak偶e,
+zapisa膰 wyniki w oddzielnym pliku dziennika.</li>
+
+ <li><b>Telnet Decode</b> - usuwa z sesji TELNET i FTP binarne ci膮gi
+mog膮ce utrudni膰 wyszukiwanie z udzia艂em sygnatur atak贸w.</li>
+ <li><b>RPC Decode</b> - normalizuje 偶膮dania po protokole RPC,
+utrudniaj膮c ukrywanie podejrzanych pakiet贸w za pomoc膮 mniejszych operacji.</li>
+ <li><b>Back Orifice detektor</b> - wyszukuje w pakietach UDP pr贸by
+po艂膮cze艅 konia troja艅skiego Back Orifice i pr贸buje z艂ama膰 zabezpieczaj膮ce je
+s艂abe kodowanie.</li>
+ <li><b>Arpspoof</b> - wykrywa podejrzane pakiety ARP, mog膮ce
+sygnalizowa膰 pr贸by ARP spoofingu.</li>
+
+ <li><b>Performance Monitor</b> - 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.</li>
+</ul>
+<p>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).</p>
+
+<h3>Modu艂 sygnatur</h3>
+<p>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.</p>
+<p>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艂臋 <i>activate</i>, po czym dzia艂anie jako
+regu艂a <i>log</i> (dynamic).</p>
+
+<p>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 - <A href="http://www.securityfocus.com/bid"
+target="_blank">Bugtraq</A>, <A href="http://www.cert.org">CERT</A> czy <A
+href="http://www.cve.mitre.org/" target="_blank">CVE</A>).</p>
+
+
+<p>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):
+</p>
+<pre>log tcp any any -> 192.168.1.0/24 110</pre>
+<p>W sygnaturach mo偶na umieszcza膰 zmienne zdefiniowane jako
+adresy sieci (wg CIDR) lub porty zapisane w pliku konfiguracyjnym
+<i>snort.conf</i>:
+
+</p>
+<pre>log tcp $EXTERNAL_NET -> $HOME_NET 110</pre>
+<p>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.:</p>
+<pre>alert tcp any any <> $HOME_NET 23</pre>
+
+<p>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.:</p>
+<pre>log tcp $EXTERNAL_NET -> $HOME_NET 110 ("msg: Proba polaczenia z pop3";)</pre>
+<p>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膮 <i>content</i> testowana jest tre艣膰 przesy艂anego
+strumienia TCP, a w razie odnotowania podejrzanego ci膮gu znak贸w
+generowany jest odpowiedni komunikat:</p>
+
+<pre>alert tcp any any -> 192.168.1.0/24 80 (content: "/cgi-bin/phf"; msg: "PHF probe!";)</pre>
+<p>Opcji <i>content</i> 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.
+</p>
+
+<p>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.</p>
+
+<p>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:
+
+<pre>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;)</pre>
+
+<p>Opcje <i>activates</i> i <i>activated_by</i> wi膮偶膮 regu艂y <i>activate</i> i <i>dynamic</i>. 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 <i>count</i>) 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. </p>
+
+
+<p>Nast臋pne godne uwagi parametry, to <i>resp</i> i <i>react</i> wspieraj膮 mechanizm elastycznego reagowania
+ na atak. Opcja <i>resp</i> 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 <i>react</i>
+ s艂u偶y do blokowania dost臋pu do us艂ug zwi膮zanych z WWW. </p>
+
+
+<h2>Ciekawe projekty</h2>
+<ul>
+<li><strong><A href="http://www.nessus.org">Nessus</A></strong> 鈥 sieciowy
+tester bezpiecze艅stwa, przydatny do
+okre艣lania skuteczno艣ci skonfigurowanego przez nas Snorta.</li>
+<li><strong><A
+href="http://jeremy.chartier.free.fr/snortalog/">SnortALog</strong></A> 鈥
+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. </li>
+<li><strong><A href="http://snort-inline.sf.net/">Snort Inline</A></strong> 鈥
+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. </li>
+<li><strong><A href="http://www.snortsam.net/">SnortSam</A></strong> - 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).</li>
+<li><strong><A href="http://www.geschke-online.de/FLoP/">FLoP</A></strong> 鈥
+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.</li>
+</ul>
+
+
+</body>
+</html>
Wi阠ej informacji o li禼ie dyskusyjnej pld-doc