Snort_inline.pdf
(
941 KB
)
Pobierz
222432169 UNPDF
Snort_inline jako
rozwiązanie
sposoby na utworzenie
dedykowanego urządzenia
najlepiej odpowiadającego
środowisku, które chcemy
chronić.
Obrona
Pierpaolo Palazzoli, Matteo Valenza
stopień trudności
Wykorzystanie Snort_inline okazało się skuteczną strategią na
zabezpieczenie sieci wewnętrznych, DMZ oraz domowych, w
przypadku wielu różnych środowisk i scenariuszy. Aby narzędzie
to działało poprawnie w trybie drop powinno ono adaptować
się do właściwości środowiska, które chroni. Z tego względu
przedstawimy tutaj nie tylko techniki koniguracji, ale także
mań (ang.
Intrusion Detection System
,
IDS), jego natywny tryb działania opiera
się więc na wykorzystaniu karty sieciowej nasłu-
chującej ruchu w danym segmencie sieci.
Aby Snort_inline był w stanie przetwarzać
ruch w segmencie sieci musi on zostać niewi-
dzialnie weń włączony, za pomocą dwóch kart
sieciowych w trybie mostka (ang.
bridge
) oraz
funkcjonalności
inline
. Funkcjonalność tę za-
pewnia nam kolejkowanie ruchu poprzez ipta-
bles (
ip _ queue
); nie jest to jednak wszystko,
musimy bowiem wiedzieć także, na poziomie ip-
tables, który ruch kolejkować. Dzięki temu trybo-
wi pracy Snort_inline może on zachowywać się
jak każdy inny system zapobiegania włamaniom
(ang.
Intrusion Prevention System
, IPS) i bloko-
wać nawiązywane połączenia. Aby Snort mógł
działać jako system zapobiegania włamaniom
musi on zostać skompilowany z opcją pobiera-
nia lex-response, co pozwala mu na resetowa-
nie ruchu, który ma być blokowany.
Podsumowując, możemy stwierdzić że
Snort_inline to zdecydowanie najefektywniej-
szy i najdokładniejszy tryb, jako że odrzuca
on ruch w sieci na podstawie załadowanych
uprzednio reguł.
Snort_inline w sieci lokalnej
Pierwsza część niniejszego artykułu poświę-
cona będzie krótkiemu wprowadzeniu do za-
gadnienia
Snort_inline w sieci lokalnej
. Zakła-
damy, że ruch w LANie zorientowany jest głów-
nie na klientów. Na tej podstawie zdeiniować
można następujące klasy ruchu w sieci:
• poczta, klienci WWW, p2p, komunikatory,
spyware, malware, wirusy, trojany, vpn.
Wspólną cechą wszystkich tych typów z punk-
tu widzenia IDS / IPS jest, że nie możemy prze-
twarzać ruchu zaszyfrowanego; oznacza to
brak na liście usług vpns oraz ssl.
Z artykułu dowiesz się...
• jak działa Snort_inline,
• podstaw systemów zapobiegania włamaniom,
• jak dostrajać konigurację Snort_inline.
Powinieneś wiedzieć...
• podstawy TCP/IP w środowisku Linux,
• podstawowe zasady działania IDSów.
2
hakin9 Nr 1/2007
www.hakin9.org
S
nort to w zasadzie system detekcji wła-
Tu wpisujemy top, zawsze, w kazdym artykule
Rysunek 1 pokazuje poprawne
rozwiązanie dla ochrony tego rodza-
ju, w którym IPS umieszczony po-
między routerem, a resztą sieci po-
zwala nam analizować ruch, który
chcemy monitorować bądź ochra-
niać.
Po poprawnym przygotowaniu
urządzenia musimy dowiedzieć się,
jakie reguły i preprocesory Snorta
będziemy wykorzystywać.
Załóżmy, że koniguracja Snorta
znajduje się w pliku snort_inline.conf
– na przykład taka, jak dostępna
pod adresem
www.snortattack.org/
mambo/script/snort_inline.conf
– i że dla sieci lokalnej zawiera ona
preprocesory jak pokazano na Li-
stingu 1.
nie wydajnie blokuje e-maile zainfe-
kowane na potrzeby phishingu. Wy-
korzystuje on następujące funkcje:
Preprocesory dla sieci
lokalnych
Preprocesory te przedstawia Li-
sting 1. Poniżej znajdziecie krótki
opis poszczególnych wymienionych
w nim komponentów i funkcji.
Clamav – procesor ten insta-
lowany jest jedynie wtedy, gdy
został wybrany podczas instalacji (
--
enable-clamav
). Dokonuje on skano-
wania w poszukiwaniu wirusów z ba-
zy danych Clamava i upewnia się, że
nie są one zaszyfrowane bądź spa-
kowane. Preprocesor ten niezmier-
•
ports
– lista portów do skanowa-
nia (all, !22 – oprócz 22, 110 – tyl-
ko 110)
•
toclientonly
– określa kierunek
skanowanego ruchu
•
action-drop
– informuje urządze-
nie, jak reagować na wirusy
•
dbdir
– katalog zawierający bazę
danych deinicji Clamava
•
dbreloadtime
– co ile czasu baza
powinna zostać przeładowana
Perfmonitor – preprocesor ten po-
zwala nam na zapisywanie w postaci
tekstowej wszelkich statystyk zwią-
zanych z wydajnością oraz przepły-
wem danych w sieci. Jest on krytycz-
ny dla poprawnego funkcjonowania
narzędzia pmgraph, o którym powie-
my więcej później. Również i ten pre-
procesor należy uruchomić podczas
instalacji (
--enable-perfmon
). Posia-
da następujące funkcje:
Scenariusze dla Snort_inline
Należy zauważyć, że system zorientowany na blokowanie włamań powinien być odpo-
wiednio skonigurowany i gotowy do adaptacji do dowolnych scenariuszy sieciowych
i rodzajów ruchu. Korzystanie z IPS w trybie inline nie rozwiązuje wszystkich proble-
mów z bezpieczeństwem, pozwala za to na stworzenie scentralizowanego, dynamicz-
nego i wydajnego systemu bezpieczeństwa. IPS powinien wykrywać ruch do i z chro-
nionego źródła. Dzięki interfejsom sieciowym działającym w trybie mostka możemy
niezauważalnie włączyć urządzenie w sieć i w ten sposób zebrać wszelkie niezbędne
dane. Do stworzenia urządzenia inline potrzebna jest nam wiedza o wszelkich właści-
wościach chronionej sieci – od warstwy sieci po warstwę aplikacji.
Poniżej opiszemy kilka przykładów rodzajów segmentów sieciowych, w których
implementacja IPS w trybie inline mogłaby przynieść korzyści zwiększając bezpie-
czeństwo całego systemu:
•
time –
czas niezbędny do prób-
kowania odczytu danych
• sieć wewnętrzna; grupa klientów obsługujących WWW, pocztę, komunikatory, p2p
itd. (Rysunek 1),
• DMZ; grupa serwerów zapewniających usługi powiązane z Internetem (smtp, web,
ftp, pop3, imap, mysql itd.) (Rysunek 2),
• LAN + DMZ (Rysunek 3).
Przede wszystkim powinniśmy na jakiś czas uruchomić Snort_inline w trybie IDS (Alert),
który to czas proporcjonalny jest do rozmiaru sieci (innymi słowy, im większa liczba sys-
temów w niej, tym więcej potrzeba czasu). W okresie tym powinniśmy:
• wychwycić awarie (problemy z wydajnością bądź składowaniem danych, spowol-
nienia itd.),
• przeanalizować ruch w sieci pod kątem fałszywych alarmów.
W ten sposób obserwując zebrane dane możemy dokonać zmian w koniguracji i zop-
tymalizować działanie urządzenia. Warto zauważyć, że w porównaniu z rozwiązania-
mi komercyjnymi implementacja otwartego IPS może nie być tak prosta, jak się to mo-
że wydawać, możesz mieć zatem pewne problemy z usuwaniem wielu fałszywych alar-
mów na pierwszym etapie procedury dostrajania.
Sugerujemy instalację Snort_inline na dedykowanym komputerze i odpowiednią
organizację jego zasobów sprzętowych (CPU, RAM), według następujących, prostych
zasad: większa liczba reguł wymaga więcej RAMu, zaś duża intensywność ruchu w
sieci zwiększa obciążenie procesora.
Niedawne testy sieciowe pokazały, że do zabezpieczenia połączenia ADSL
(1280/256) potrzebny jest system Geode o częstotliwości zegara 266 MHz i z 128 MB
RAMu (w przypadku tysiąca reguł). Dla pasm o szerokości większej niż 1 Mbps zale-
camy Pentium 4 1 GHz z 512 MB RAM (w przypadku trzech tysięcy reguł).
Rysunek 1.
Ustawiamy urządzenie
w sieci lokalnej
www.hakin9.org
hakin9 Nr 1/2007
3
Technika
•
File –
ścieżka do pliku z danymi
•
pkcnt –
maksymalna liczba re-
kordów, jaka może znaleźć się w
jednym pliku
Tryb mostka
Ustawienie dwóch kart w tryb mostka oznacza połączenie ich funkcjonalności w
warstwie drugiej, co czyni je przezroczystymi dla ruchu w sieci. W trybie tym pa-
kiety przekazywane są z jednej karty do drugiej, co pozwala na poprawne przeka-
zywanie ruchu. Aby uruchomić ten tryb pod Linuksem należy wykonać następują-
ce operacje:
Instalujemy pakiet
bridge-utils
-
apt-get install bridge-utils
; potrzebne
będzie jądro w wersji 2.6, w przeciwnym razie należy ponownie skompilować jądro
wersji 2.4 włączywszy uprzednio moduł mostka. Mostek pomiędzy dwoma kartami
sieciowymi można zestawić następująco:
Flow – preprocesor ten potrzebny
jest do działania innych preproce-
sorów, takich jak
lowbits detection
plug-in
czy
low-portscan
. W skrócie,
preprocesor Flow pozwala Snortowi
przechowywać mechanizmy akwi-
zycji danych. Ma następujące funk-
cje:
/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth0
/usr/sbin/brctl addif br0 eth1
/sbin/ifconig br0 up
•
stats _ interval
– parametr ten
określa przedziały czasu, w se-
kundach, w których Snort będzie
zrzucać statystyki na standardo-
we wyjście.
•
Hash
– parametr ten określa me-
todę mieszania. Wartość 1 dei-
niuje mieszanie po bajcie, war-
tość 4 – mieszanie po liczbie cał-
kowitej.
Adres MAC przypisany br0 będzie taki sam, jak adres pierwszego interfejsu, który zo-
stał z nim skojarzony.
Rpc decode – preprocesor ten po-
nownie składa strumienie rpc z po-
jedynczych pakietów celem ułatwie-
nia ich analizy, jeżeli obecny jest pre-
procesor stream4 możliwe jest prze-
twarzanie tylko ruchu wychodzące-
go od klientów.
Telnet decode – preprocesor
ten normalizuje przepływ znaków
w sesjach protokołu telnet. Nale-
ży podać mu porty, które ma prze-
twarzać.
•
pass
– ignoruje wybrany przez
siebie ruch.
•
drop
– za pomocą iptables
odrzu-
ca
pakiet, a następnie odnotowu-
je go w pliku bądź bazie danych
•
reject
– w przypadku TCP; połą-
czenie jest
resetowane
z pomocą
iptables, w przypadku UDP wy-
syłany jest komunikat
icmp host
unreachable
; następnie zdarze-
nie odnotowywane jest w pliku
bądź bazie danych
•
sdrop
–
odrzuca
pakiet za pomo-
cą iptables nie logując go.
Stream 4 – preprocesor ten daje
Snortowi umiejętność widzenia pod-
stawowych właściwości pakietów
oraz to, gdzie został wygenerowany
(klient czy serwer). Cytując Marty-
'ego Roescha:
Zaimplementowałem
stream4 na skutek chęci uzyskania
potężniejszych mechanizmów po-
nownego składania strumieni i obro-
ny przed najnowszymi 'atakami bez-
stanowymi
. Wykorzystuje następują-
ce funkcje:
Reguły dla sieci lokalnych
Kiedy już zdeiniowaliśmy preproce-
sory, Snort potrzebuje określenia w
koniguracji odpowiednich reguł. Ist-
nieje wiele różnych rodzajów reguł:
W przedstawionym tutaj przykła-
dzie zadaniem reguły jest blokowa-
nie miosito.com; jest to część zbio-
ru reguł służącego blokowaniu ru-
chu kierowanego do sieciowych ka-
syn nieprzestrzegających reguł wło-
skiego prawa. Funkcja
drop
określa
działanie, które iptables musi wyko-
nać jak tylko reguła zostanie zasto-
sowana.
•
disable _ evasion _ alerts
– wy-
łącza alarmy zapisywane przez
stream4
•
midstream _ drop _ alerts
– na-
kazuje preprocesorowi blokowa-
nie połączeń generowanych bez
tworzenia danego strumienia.
•
alert
– generuje komunikat alar-
mowy, a następnie odnotowu-
je go go w pliku bądź bazie da-
nych.
•
log
– zapisuje do pliku bądź bazy
danych.
Listing 1.
Zalecane preprocesory dla sieci lokalnej
preprocessor perfmonitor: time 60 ile/var/log/snort/perfmon.txt pktcnt 500
preprocessor low:stats_interval 0 hash 2
preprocessor stream4_reassemble: both
preprocessor stream4: disable_evasion_alerts
midstream_drop_alerts
preprocessor clamav:ports all !22 !443,toclientonly, action-drop,dbdir /var/lib/clamav,dbreload-time 43200
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
4
hakin9 Nr 1/2007
www.hakin9.org
Tu wpisujemy top, zawsze, w kazdym artykule
drop tcp $home_net any ->
any $http ports (
msg:"snortattack-italian-law";
low:established;content: "miosito.com";
classtype:policy-violation;
reference:url,
www.snortattack.net;
)
Listing 2.
Lista przydatnych reguł do ochrony sieci lokalnej
# Ogólne
include
/
etc
/
snort_inline
/
rules
/
bleeding
.
rules
# Głównie spyware
include
$
RULE_PATH
/
bleeding
-
malware
.
rules
include
$
RULE_PATH
/
malware
.
rules
include
$
RULE_PATH
/
spyware
-
put
.
rules
# Eksploity i ataki bezpośrednie
include
$
RULE_PATH
/
exploit
.
rules
include
$
RULE_PATH
/
bleeding
-
exploit
.
rules
include
$
RULE_PATH
/
community
-
exploit
.
rules
# DOS
include
$
RULE_PATH
/
dos
.
rules
include
$
RULE_PATH
/
ddos
.
rules
include
$
RULE_PATH
/
bleeding
-
dos
.
rules
# Dotyczące WWW
include
$
RULE_PATH
/
web
-
client
.
rules
include
$
RULE_PATH
/
community
-
web
-
client
.
rules
# Sygnatury poczty
include
$
RULE_PATH
/
community
-
mail
-
client
.
rules
# Trojany, wirusy oraz spyware
include
$
RULE_PATH
/
virus
.
rules
include
$
RULE_PATH
/
bleeding
-
virus
.
rules
include
$
RULE_PATH
/
community
-
virus
.
rules
# Peer to peer
include
$
RULE_PATH
/
p2p
.
rules
include
$
RULE_PATH
/
bleeding
-
p2p
.
rules
Przeznaczeniem koniguracji przed-
stawionej na Listingu 2 jest kontro-
la aplikacji p2p, ochrona przed ata-
kami z wewnątrz (które to ataki sta-
nowią niemal 70% wszystkich ata-
ków), a przede wszystkim selekcja
treści oglądanych przez wewnętrz-
ne hosty.
Snort_inline w DMZ
Drugą część artykułu poświęcimy
krótkiemu wprowadzeniu do zagad-
nienia
Snort_inline w DMZ
.
Jak wspomnieliśmy wcześniej,
ruch sieciowy w DMZ z założenia
dotyczyć będzie głównie serwe-
rów. Na tej podstawie zdeiniować
możemy następujące klasy ruchu
w DMZ:
Jednym z możliwych rozwiązań
dla tego rodzaju segmentów sie-
ciowych jest umieszczenie weń
IPS. Tym razem system umiesz-
czony będzie pomiędzy routerem,
a DMZ.
Preprocesory dla sieci DMZ
Jedynym preprocesorem, którego
koniguracja uległa zmianie jest Cla-
mav – ważne jest zdeiniowanie dlań
parametru
toserveronly
aby wybrać
jedynie ruch skierowany do serwe-
rów. Patrz Listing 3.
Frag3 – preprocesor ten zastę-
puje frag2 i jest niezbędny do re-
konstrukcji strumienia danych roz-
członkowanego wskutek fragmenta-
cji transmisji.
• serwer poczty, serwer WWW,
serwer bazodanowy, serwer apli-
kacji, wirus, vpn.
Reguły dla sieci DMZ
Po zdeiniowaniu wszystkich pre-
procesorów musimy podać Snortowi
trochę reguł. Poniżej znajdziesz kilka
ich zastosowań:
•
max _ frags
– maksymalna liczba
śledzonych fragmentów
•
policy
– wybiera sposób frag-
mentacji, dostępne metody to
irst, ast, bsd, bsd-right, linux.
Domyślnym ustawieniem jest
bsd.
•
detect _ anomalies
– wykrywa
błędy fragmentacji.
Rysunek 2.
Przykład sieci DMZ
Reguły zalecane do użytku w sieci
DMZ przedstawia Listing 4.
www.hakin9.org
hakin9 Nr 1/2007
5
Technika
Snort w sieci mieszanej
Jeżeli chodzi o urządzenie w sie-
ci mieszanej (pokazanej na Rysun-
ku 3), zalecamy następujące urzą-
dzenia.
Preprocesory dla sieci miesza-
nej znaleźć można na Listingu 5, od-
powiednie reguły zaś przedstawia
Listing 6. Przeznaczeniem opisanej
w nich koniguracji jest kontrola wi-
rusów oraz ochrona maszyn przed
atakami z zewnątrz w oparciu o blo-
kowanie eksploitów wymierzonych
w usługi. Kilka różnych technik ata-
ku przedstawimy później, na bazie
praktycznych przykładów.
Listing 3.
Lista preprocesorów dla sieci DMZ
Preprocesory dla DMZ
preprocessor perfmonitor: time 60 ile /var/log/snort/perfmon.txt pktcnt 500
preprocessor low: stats_interval 0 hash 2
preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy irst detect_anomalies
preprocessor stream4: disable_evasion_alerts detect_scans inline_state
preprocessor stream4_reassemble: both
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
preprocessor clamav: ports 25 80, toserveronly, action-drop, dbdir /var/lib/
clamav, dbreload-time 43200
Narzędzia te, napisane w PHP
bądź Pythonie, mają krytyczne zna-
czenie dla dobrego IPS / IDS – kry-
tyczną jest bowiem wiedza o tym, co
dzieje się z naszym urządzeniem
i naszą siecią. Interfejsy te bardzo
prosto się instaluje, wystarczy roz-
pakować archiwa i wyedytować od-
powiednie pliki koniguracyjne tak,
by narzędzia łączyły się z bazą da-
nych Snorta.
Tutaj zdecydowaliśmy się przyj-
rzeć dwóm z nich: BASE oraz PLA-
CID.
Pierwsze z nich jest pochodną
ACID (Analysis Console for Intru-
sion Database); BASE to skrót od
Basic Analysis and Security En-
gine (patrz Rysunek 4). Narzę-
dzie to pozwala na przeglądanie i
przetwarzania bazy danych Snor-
ta i jest napisane w PHP. Jego siłą
jest wiele opcji badawczych oraz
możliwość grupowania alarmów
na podstawie ich adresów IP, jak
również innych parametrów, takich
jak czas bądź rodzaj reguły. Pod-
stawowa implementacja jest pół-
automatyczna, wystarczy rozpako-
wać archiwum tar.gz w domyślnym
katalogu Apache'a (
/var/www/
),
zmienić właściciela utworzone-
go weń folderu oraz przejść do je-
go pierwszego poziomu za pomo-
cą przeglądarki. Zautomatyzowa-
na procedura przeprowadza nas
przez tworzenie niezbędnych ta-
bel i pozwala rozpocząć korzysta-
nie z aplikacji.
Monitorowanie ataków i
zarządzanie regułami
Interfejsy, które przeanalizujemy i
opiszemy, opierają się na bazach
danych. W zasadzie, wszystkie wy-
niki ze Snorta składowane będą w
różnego rodzaju bazach danych: my-
sql, postgres itp. Narzędzia te różnią
się między sobą i są napisane w róż-
nych językach, jednak ogólnie rzecz
biorąc wszystkie robią to samo. Są
to: ACID, BASE, PLACID, SNORT
REPORT, SGUIL itd.
Listing 4.
Lista reguł zalecanych dla DMZ
include
$
RULE_PATH
/
bad
-
trafic
.
rules
include
$
RULE_PATH
/
exploit
.
rules
include
$
RULE_PATH
/
scan
.
rules
include
$
RULE_PATH
/
dos
.
rules
include
$
RULE_PATH
/
ddos
.
rules
include
$
RULE_PATH
/
dns
.
rules
include
$
RULE_PATH
/
web
-
cgi
.
rules
include
$
RULE_PATH
/
web
-
iis
.
rules
include
$
RULE_PATH
/
web
-
misc
.
rules
include
$
RULE_PATH
/
web
-
php
.
rules
include
$
RULE_PATH
/
community
-
web
-
php
.
rules
include
$
RULE_PATH
/
netbios
.
rules
include
$
RULE_PATH
/
attack
-
responses
.
rules
include
$
RULE_PATH
/
mysql
.
rules
include
$
RULE_PATH
/
virus
.
rules
include
$
RULE_PATH
/
web
-
attacks
.
rules
include
$
RULE_PATH
/
backdoor
.
rules
include
$
RULE_PATH
/
bleeding
-
virus
.
rules
include
$
RULE_PATH
/
bleeding
-
attack_response
.
rules
include
$
RULE_PATH
/
bleeding
-
dos
.
rules
include
$
RULE_PATH
/
bleeding
-
exploit
.
rules
include
$
RULE_PATH
/
bleeding
-
malware
.
rules
include
$
RULE_PATH
/
bleeding
-
scan
.
rules
include
$
RULE_PATH
/
bleeding
-
web
.
rules
include
$
RULE_PATH
/
community
-
exploit
.
rules
include
$
RULE_PATH
/
community
-
ftp
.
rules
include
$
RULE_PATH
/
community
-
web
-
misc
.
rules
include
$
RULE_PATH
/
community
-
smtp
.
rules
tar -zxvf base-1.2.4.tar.gz
mv base-1.2.4 base
mv base /var/www
chown apache. /var/www/base
PLACID
PLACID napisany został w Py-
thonie i jest, podobnie jak BA-
SE, przeglądarką zdarzeń w ba-
zie danych. Zapewnia taką samą
funkcjonalność jak BASE, jednak
stwierdzono, że działa szybciej
w przypadku większych baz da-
nych. Instalacja PLACID nie jest
taka prosta, trzeba zainstalować
Pythona 2.3 oraz określić w pli-
ku konfiguracyjnym Apache'a kilka
niezbędnych do poprawnego dzia-
łania parametrów:
6
hakin9 Nr 1/2007
www.hakin9.org
Plik z chomika:
ddwrobel
Inne pliki z tego folderu:
wyscig_pl.pdf
(462 KB)
Wireless_Seguridad_Hakin9.pdf
(1738 KB)
wardriving_tutorial_hakin9.pdf
(1099 KB)
switch_pl.pdf
(2208 KB)
stackoverflow_pl.pdf
(1224 KB)
Inne foldery tego chomika:
CCNA V1
CCNA V2
CCNA V3
CCNA V4
Cisco
Zgłoś jeśli
naruszono regulamin