2006.05_Simple Event Correlator (SEC) w monitorowaniu logów bezpieczeństwa.pdf

Pod lupą

Simple Event Correlator

(SEC) w monitorowaniu

logów bezpieczeństwa

Risto Vaarandi

stopień trudności

W ciągu ostatniej dekady korelacje między zdarzeniami stały

się istotną techniką przetwarzania zdarzeń w wielu dziedzinach

(zarządzaniu sieciami i bezpieczeństwem, detekcja intruzów itd.),

jednak istniejące otwarte narzędzia monitorujące nie obsługują

ich zbyt dobrze. Omówimy tutaj, jak zastosować SEC

w monitorowaniu i korelowaniu zdarzeń z logów bezpieczeństwa.

formatycznego logi zdarzeń odgry-

wają krytyczną rolę. We współcze-

snym świecie wiele aplikacji, systemów ope-

racyjnych, urządzeń sieciowych i innych kom-

ponentów systemu jest w stanie zapisywać do

plików komunikaty o związanych z bezpieczeń-

stwem wydarzeniach. Pochodzący z BSD pro-

tokół syslog to standard logowania zdarzeń ob-

sługiwany przez większość producentów syste-

mów operacyjnych i urządzeń sieciowych, po-

zwalający na uruchomienie centralnego ser-

wera logów, który zbiera i składuje wiadomo-

ści o zdarzeniach z całego systemu informa-

tycznego. Istnieje także szereg elastycznych i

potężnych implementacji serwera syslog zdat-

nych do użytku na centralnym serwerze logów,

w szczególności Syslog-ng. Biorąc pod uwa-

gę, że logowanie zdarzeń jest szeroko rozpo-

wszechnione i wysoce ustandaryzowane, są

duże szanse że po zaistnieniu w systemie in-

formatycznym incydentu związanego z bez-

pieczeństwem, fakt ten dokumentować będzie

jedna lub więcej wiadomości w pliku bądź pli-

kach logów.

Jako że w większości przypadków wiado-

mości o zdarzeniach są dołączane do plików

logów w czasie rzeczywistym w miarę, jak są

one emitowane przez komponenty systemu, lo-

gi zdarzeń są doskonałym źródłem informacji

dla monitorowania systemu, uwzględniając tu-

taj mogące w nim wystąpić wydarzenia z dzie-

dziny bezpieczeństwa. W ciągu ostatnich 10-15

lat powstało wiele otwartych narzędzi pozwala-

jących na monitorowanie logów zdarzeń w cza-

sie rzeczywistym, m.in. Swatch czy Logsurfer.

Z artykułu dowiesz się...

• Czym jest korelowanie zdarzeń i jakie są po-

wszechne podejścia do tego zagadnienia,

• jaka była motywacja ku stworzeniu SEC i jakie

są jego główne możliwości,

• jak zastosować SEC w monitorowaniu w czasie

rzeczywistym logów zdarzeń bezpieczeństwa.

Powinieneś wiedzieć...

• zakładamy, że czytelnik zna język wyrażeń re-

gularnych,

• przy czytaniu sekcji Integrowanie własnego ko-

du Perla z zasadami SEC pomocna okaże się

znajomość podstaw Perla.

hakin9 Nr 5/2006

www.hakin9.org

W sferze bezpieczeństwa systemu in-

Pod lupą

Niestety, większość z tych narzędzi

jest w stanie wykonywać jedynie naj-

prostsze zadania, na przykład pod-

nosić alarm natychmiast po dołącze-

niu konkretnej wiadomości do pliku

logów. Z drugiej strony, wiele waż-

nych zadań z dziedziny przetwarza-

nia zdarzeń opiera się na korelowa-

niu zdarzeń – konceptualnej proce-

durze interpretacji, w której znacze-

nie przypisywane jest szeregom zda-

rzeń mających miejsce w uprzednio

określonych przedziałach czasu (Ja-

kobson i Weissman, 1995). Aplikacja

implementująca korelowanie zda-

rzeń nazywana jest korelatorem zda-

rzeń ; w czasie realizacji procedury

interpretacji korelator może tworzyć

nowe zdarzenia i/lub ukrywać zda-

rzenia oryginalne przed końcowym

użytkownikiem.

W ramach przykładu na to, jak

ważne jest korelowanie zdarzeń w

zarządzaniu bezpieczeństwem, roz-

ważmy przetwarzanie zdarzeń nie-

udane logowanie . Chociaż pojedyn-

cze zdarzenie nieudane logowanie

może być oznaką próby złamania ha-

sła, jednak może ono także znaczyć,

że użytkownik przypadkowo wpisał

niewłaściwe hasło. Z tego względu

nie można po prostu skonigurować

narzędzia monitorującego logi tak,

by ogłaszało ono natychmiastowy

alarm po wystąpieniu w logach wia-

domości nieudane logowanie – skut-

kiem takiego podejścia mogłaby być

duża liczba fałszywych alarmów. Do

ograniczenia liczby fałszywych alar-

mów wykorzystać można jeden bądź

oba przedstawione poniżej sposoby

korelacji zdarzeń:

• jeżeli wystąpiło N zdarzeń nie-

udane logowanie jako użytkow-

nik X w ciągu ostatnich T sekund,

wygeneruj zdarzenie nadmierna

liczba nieudanych logowań jako

użytkownik X i wyślij je w formie

alarmu do administratora bezpie-

czeństwa,

• jeżeli wystąpiło zdarzenie nie-

udane logowanie jako użytkow-

nik X , a w ciągu kolejnych T se-

kund nie zaobserwowano zda-

rzenia udane logowanie jako

użytkownik X , wygeneruj zdarze-

nie nieudane logowanie bez póź-

niejszego sukcesu, jako użytkow-

nik X i wyślij je w formie alarmu

do administratora bezpieczeń-

stwa.

korelator ma skorelować szereg zda-

rzeń, wyszukuje najlepiej pasujący

wektor bądź wektory w księdze kodów

i zgłasza odpowiednie dla niego/nich

interpretacje. W metodzie opartej na

grafach, człowiek-analityk identy-

ikuje wszystkie zależności pomię-

dzy komponentami systemu (usługa-

mi, hostami, urządzeniami sieciowymi

itd.) i konstruuje graf, w którym każdy

wierzchołek to komponent systemu,

każda krawędź zaś – zależność po-

między dwoma komponentami. Kie-

dy występuje szereg zdarzeń, za po-

mocą grafu wyszukuje się pierwotną

ich przyczynę (np. dziesięć zdarzeń

serwer HTTP nie odpowiada zosta-

ło spowodowanych przez awarię po-

jedynczego połączenia sieciowego).

W metodzie opartej na sieciach neu-

ronowych odpowiednio szkoli się sieć,

by mogła identyikować anomalie

w strumieniu zdarzeń, wykrywać pier-

wotne przyczyny i tak dalej.

Podejście oparte na regułach

jest stosowane bardzo powszech-

nie w korelowaniu zdarzeń i zo-

stało wykorzystane w wielu pro-

duktach, na przykład HP ECS czy

RuleCore. W tym przypadku zda-

rzenia korelowane są według zde-

iniowanych przez człowieka-anali-

tyka reguł postaci warunek → dzia-

łanie ,. Jedną z głównych zalet kore-

lowania zdarzeń w oparciu o reguły

jest fakt, że ludzie potraią na ogół

wyrazić w naturalny sposób swo-

ją wiedzę w postaci reguł. Przykła-

dowo, za pomocą reguł łatwo moż-

na opisać zależności czasowe po-

między zdarzeniami – co w przy-

padku innych metod byłoby kłopo-

tliwe. Ponadto w przeciwieństwie

do niektórych innych metod korelo-

wania zdarzeń (np. w oparciu o sie-

ci neuronowe), korelowanie w opar-

ciu o reguły i jest jasne i przejrzy-

ste dla końcowego użytkownika.

Jak postuluje się w (Rich i Knight,

1991), kiedy końcowi użytkownicy

nie rozumieją, dlaczego i jak aplika-

cja zwróciła takie, a nie inne infor-

macje, mają oni tendencję do igno-

rowania obliczonych przez tę apli-

kację rezultatów.

Chociaż korelowanie zdarzeń

stało się ważną techniką przetwa-

W ciągu ostatniej dekady zapropo-

nowano szereg podejść do korelo-

wania zdarzeń, między innymi opar-

te na: regułach (Froehlich et al.,

2002), księgach kodów (Yemini et

al., 1996), grafach (Gruschke 1998)

i sieciach neuronowych (Wietgrefe

et al., 1997; Wietgrefe 2002), a tak-

że metody probabilistyczne (Meira

1997; Steinder and Sethi, 2002). Po-

nadto na rynku dostępnych jest wie-

le produktów korelujących zdarze-

nia, na przykład HP ECS, SMARTS,

NetCool, NerveCenter, LOGEC czy

RuleCore.

Metoda oparta na księgach kodów

(wykorzystywana przez SMARTS)

działa następująco – jeżeli szereg

zdarzeń e1, …, ek ma być interpreto-

wany jako zdarzenie A, e1, …, ek jest

składowany w księdze kodów jako bi-

towy wektor wskazujący na A. Gdy

Listing 1. Reguła SEC korelująca wiadomości SNMP public access udp

ze Snort IDS

# Sample matching input line:

# Mar 1 00:36:32 snorthost.mydomain [auth.alert] snort[17725]: [1:1411:10]

# SNMP public access udp [Classiication: Attempted Information Leak]

# [Priority: 2]: {UDP} 192.168.115.34:54206 -> 192.168.52.179:161

type = SingleWithSuppress

ptype = RegExp

pattern = snort \ [ \ d + \ ]: \ [[ \ d :]+ \ ] SNMP public access udp . * \ { UDP \ } \

([ \ d \. ]+): \ d + -> ([ \ d \. ]+): \ d +

desc = SNMP public access from $ 1 to $ 2

action = pipe ' % s ' mail - s ' Snort alert ' root

window = 300

hakin9 Nr 5/2006

www.hakin9.org

Simple Event Correlator

rzania zdarzeń w wielu dziedzi-

nach (w tym zarządzaniu sieciami

i bezpieczeństwem, detekcji intru-

zów itd.), istniejące otwarte narzę-

dzia do monitorowania logów nie

obsługują go zbyt dobrze. Pomi-

mo faktu, że systemy korelacji zda-

rzeń obecne już na rynku odniosły

wielki sukces i są używane przez

wiele dużych irm na całym świe-

cie, cierpią one na szereg przy-

padłości. Po pierwsze, istniejące

systemy to często ciężkie rozwią-

zania o skomplikowanej konstruk-

cji i interfejsie użytkownika. Ozna-

cza to, że ich wdrażanie i pielę-

gnacja są czasochłonne, a także

że wymagają szeroko zakrojone-

go szkolenia użytkowników. Ponad-

to ich złożoność i wymagania pod

względem zasobów często czynią

je niezdatnymi do wykorzystania

w mniejszych systemach informa-

tycznych bądź do korelowania zda-

rzeń na węzłach o ograniczonych

zasobach obliczeniowych. Po dru-

gie, ze względu na to że istniejące

systemy są w większości komercyj-

ne, są one przywiązane do konkret-

nych platform – klientom zapewnia

się pliki binarne programów, które

można uruchomić pod ograniczo-

ną liczbą systemów operacyjnych.

Ponadto niektóre komercyjne sys-

temy zaprojektowane zostały tylko

pod jedną konkretną platformę za-

rządzania (np. HP OpenView). Nie-

które obciąża także fakt, że zapro-

jektowano je konkretnie pod kątem

zarządzania problemami z siecią,

co czyni niewygodnym ich zasto-

sowanie w innych sferach (w tym

do monitorowania logów zdarzeń).

Po trzecie, istniejące systemy ma-

ją tendencję do bycia dość drogimi,

a co za tym idzie wiele instytucji o

coraz bardziej ograniczonym bu-

dżecie nie może korzystać z nich w

codziennych zadaniach z dziedzi-

ny zarządzania bezpieczeństwem

i sieciami.

W niniejszej publikacji omówi-

my SEC (Simple Event Correlator)

– otwarte narzędzie stworzone przez

jej autora na potrzeby lekkiego i nie-

zależnego od platformy korelowania

zdarzeń – oraz przeanalizujemy kil-

Listing 2. Zbiór reguł SEC do korelowania wiadomości sshd o porażce i

sukcesie uwierzytelniania, pod Solarisem

# Sample matching input lines:

# Apr 3 14:20:19 myhost sshd[25888]: [ID 800047 auth.error] error:

# PAM: Authentication failed for risto from myhost2

# Apr 3 14:20:23 myhost sshd[25888]: [ID 800047 auth.info] Accepted

# keyboard-interactive/pam for risto from 192.168.27.69 port 9729 ssh2

type = PairWithWindow

ptype = RegExp

pattern = sshd \ [ \ d + \ ]: \ [ ID \ d + auth \. error \ ] \

error : PAM : Authentication

failed for ( \ S +) from \ S +

desc = PAM authentication failed for $ 1

action = event PAM_AUTHENTICATION_FAILED_FOR_ $ 1

ptype2 = RegExp

pattern2 = sshd \ [ \ d + \ ]: \ [ ID \ d + auth \. info \ ] \

Accepted keyboard - interactive / pam for ( $ 1 ) from \ S + port \ d + ssh2

desc2 = PAM authentication successful for $ 1

action2 = none

window = 30

type = SingleWithThreshold

ptype = RegExp

pattern = PAM_AUTHENTICATION_FAILED_FOR_ ( \ S +)

context =! USER_ $1 _ALREADY_COUNTED && ! COUNTING_OFF

continue = TakeNext

desc = Ten authentication failures for distinct users have been observed

action = pipe ' % s ' mail - s ' PAM alert ' root ; create COUNTING_OFF 3600

window = 600

thresh = 10

type = Single

ptype = RegExp

pattern = PAM_AUTHENTICATION_FAILED_FOR_ ( \ S +)

context =! USER_ $1 _ALREADY_COUNTED && ! COUNTING_OFF

desc = Set up the "count once" context for user $ 1

action = create USER_ $1 _ALREADY_COUNTED 600

ka z życia wziętych przykładów na

to, jak wykorzystać SEC w monitoro-

waniu i korelowaniu zdarzeń z logów

bezpieczeństwa.

Aby osiągnąć niezależność od

platformy systemu operacyjnego,

autor zdecydował się napisać SEC

w Perlu. Biorąc pod uwagę, że Perl

dostępny jest pod prawie każdym ro-

dzajem systemów operacyjnych i że

stał się standardową częścią wie-

lu ich dystrybucji, perlowe aplikacje

mogą działać pod całą gamą syste-

mów. Ponadto, dobrze napisane pro-

gramy w Perlu są szybkie i efektyw-

nie korzystają z pamięci.

SEC pobiera zdarzenia ze stru-

mieni plików. W chwili obecnej ob-

sługiwane są zwykłe pliki, nazwa-

ne potoki i standardowe wejście,

co pozwala wykorzystywać SEC w

charakterze rozwiązania monitoro-

wania logów zdarzeń i zintegrować

je z dowolnymi aplikacjami zdolny-

mi zapisywać wysyłane przez sie-

bie zdarzenia do strumieni plików.

Podstawy SEC

SEC to otwarte narzędzie korelu-

jące zdarzenia, wykorzystujące do

przetwarzania zdarzeń podejście

oparte na regułach. To ostatnie wy-

brane zostało ze względu na natu-

ralność wyrażania w nim wiedzy

oraz przejrzystość procesu korelo-

wania zdarzeń. Głównymi zadania-

mi projektowymi SEC były: nieza-

leżność od platformy, lekkość kon-

strukcji i łatwość koniguracji, możli-

wość zastosowania w szerokim za-

kresie zadań z udziałem korelowa-

nia zdarzeń oraz niskie wymaga-

nia pod względem zasobów syste-

mowych.

www.hakin9.org

hakin9 Nr 5/2006

Pod lupą

Aplikacje posiadające API zarzą-

dzania zdarzeniami można również

zintegrować poprzez proste wtycz-

ki, które korzystają z wywołań API

przy czytaniu strumienia zdarzeń

z aplikacji i kopiują te ostatnie na

standardowe wyjście bądź do pliku

(przykładową wtyczka dla HP Open-

View Operations znaleźć można w

pakiecie SEC).

SEC może serwować zdarzenia

wywołując podane przez użytkow-

nika polecenia powłoki, zapisując

komunikaty do plików bądź nazwa-

nych potoków, wywołując prekom-

pilowane procedury Perla itd. Za-

uważ także, że zdarzenia te mogą

być także wysyłane przez sieć do

innej instancji SEC, co pozwala na

zestawienie rozproszonych mecha-

nizmów korelowania zdarzeń. Po-

nadto chociaż SEC nie posiada gra-

icznego interfejsu użytkownika do

przeglądania i zarządzania wytwa-

rzanymi przez siebie zdarzeniami,

bardzo prosto można skierować je-

go zdarzenia do aplikacji/ramy za-

rządzania systemem, która taki GUI

posiada (np. HP OpenView Opera-

tions).

Koniguracja SEC składowana

jest w plikach tekstowych, które moż-

na tworzyć i modyikować za pomo-

cą dowolnego edytora tekstu. Każ-

dy plik zawiera jedną lub więcej re-

guł, zaś zbiory reguł z różnych pli-

ków stosowane są praktycznie rów-

nolegle. SEC czyta dane ze swoich

źródeł linia po linii, zaś za każdym

razem, gdy wczytana została nowa

linijka, jest ona porównywana z re-

gułami z pliku bądź plików konigu-

racyjnych.

Ważną częścią każdej regu-

ły SEC jest wzorzec dopasowania

zdarzenia . SEC obsługuje we wzor-

cach wyrażenia regularne, podłań-

cuchy, procedury Perla oraz war-

tości logiczne. Wsparcie dla wyra-

żeń regularnych ułatwia konigura-

cję programu, jako że wiele unikso-

wych narzędzi (np. grep , sed , ind

itp.) opiera się na nich i przez to

większość administratorów bezpie-

czeństwa, systemów i sieci zna już

język wyrażeń regularnych. Ponad-

to biorąc pod uwagę, że język wy-

rażeń regularnych jest stosowa-

ny przy dopasowywaniu zdarzeń

przez większość narzędzi do moni-

torowania logów, ewentualne wdro-

żenie SEC jako alternatywy dla nich

wymaga znacznie mniej wysiłku.

Poczynając od wersji 2.3.0 moż-

liwe jest przekazywanie zdarzeń

do sprawdzenia prekompilowanych

procedur Perla, co pozwala użyt-

kownikom tworzyć własne mecha-

nizmy dopasowywania wzorców.

Oprócz wzorca dopasowania

większość reguł określa listę dzia-

łań , a opcjonalnie także boolowskie

wyrażenie określające kontekst .

Konteksty SEC to logiczne twory

tworzone w procesie korelowania

zdarzeń, każdy posiada określo-

ny (skończony bądź nie) czas ży-

cia. Konteksty pozwalają nam ak-

tywować bądź deaktywować zasa-

dy dynamicznie, w czasie działania

– np. jeżeli w deinicji reguły mamy

wyrażenie kontekstu (X OR Y), a

ani kontekst X, ani kontekst Y w da-

nej chwili nie istnieją, dana reguła

nie zostanie zastosowana. Kolejną

ważną funkcją kontekstów SEC jest

działanie jako składy zdarzeń – in-

teresujące nas zdarzenia mogą być

skojarzone z kontekstem, po czym

wszystkie wybrane zdarzenia mo-

gą być przekazane do zewnętrz-

nego przetworzenia w późniejszym

czasie (pomysł ten zapożyczone

został z Logsurfera).

W chwili obecnej SEC obsługuje

dziewięć rodzajów reguł, implemen-

tujących szereg powszechnych sce-

nariuszy korelowania zdarzeń:

• PairWithWindow – po zaobser-

wowaniu zdarzenia A, zaczekaj t

sekund na pojawienie się zdarze-

nia B; jeżeli B nie dotrze na czas

wykonaj listę działań, w przeciw-

nym wypadku wykonaj inną listę,

• SingleWithThreshold – licz pa-

sujące zdarzenia przychodzące

w ciągu t sekund, wykonaj listę

działań jeżeli przekroczony zo-

stał podany próg,

• SingleWith2Thresholds – jak

SingleWithThreshold , ale z do-

datkową drugą rundą zliczania,

z opadającym progiem,

• Suppress – ukryj pasujące zda-

rzenia wejściowe,

• Calendar – wykonaj listę działań

o określonej porze.

Większość deinicji reguł SEC po-

siada parametr zwany łańcuchem

opisu zdarzenia , którego zada-

niem jest określenie zakresu ko-

relacji zdarzeń (jego szczegółowe

omówienie znajdziecie w sekcji Re-

guły SEC i operacje korelacji zda-

rzeń ). Kiedy zdarzenie pasuje do

danej reguły, SEC wylicza klucz ko-

relacji zdarzenia, łącząc nazwę pli-

ku reguły, jej identyikator oraz łań-

cuch opisu zdarzenia. Jeżeli istnieje

operacja korelacji zdarzeń o takim

samym kluczu, zdarzenie jest z nią

korelowane. Jeżeli nie istnieje taka

operacja, a reguła deklaruje korela-

cję zdarzeń w czasie, SEC tworzy

nową operację o wyliczonym wła-

śnie kluczu. Trzeba tutaj odnoto-

wać, że między regułami, a opera-

cjami korelacji zdarzeń nie istnie-

je zależność jeden na jeden – SEC

może uruchomić wiele operacji dla

jednej reguły, zaś reguły typów:

Single , SingleWithScript , Suppress

oraz Calendar nie deklarują korela-

cji zdarzeń w czasie i z tego wzglę-

du nigdy nie wyzwalają operacji.

Działania SEC przewidziano nie

tylko do generowania zdarzeń wyj-

ściowych, ale także do tworzenia

reguł dla interakcji, do zarządza-

nia kontekstami i składowania zda-

rzeń, do łączenia z SEC zewnętrz-

nych modułów analizy zdarzeń, do

wywoływania własnego kodu Per-

la bez otwierania osobnego proce-

• Single – wykonaj listę działań

po zaobserwowaniu pasującego

zdarzenia,

• SingleWithScript – jak Single , ale

dodatkowo wykorzystaj do dopa-

sowania zewnętrzny skrypt,

• SingleWithSuppress – jak Single ,

ale ponadto ignoruj dalsze pasu-

jące zdarzenia przez t sekund,

• Pair – wykonaj listę działań dla

zdarzenia A, po czym ignoruj dal-

sze wystąpienia A do momentu,

aż nie pojawi się zdarzenie B;

w chwili wystąpienia B wykonaj

drugą listę działań,

hakin9 Nr 5/2006

www.hakin9.org

Simple Event Correlator

su itd. Łącząc grupy reguł z odpo-

wiednimi listami działań i wyraże-

niami kontekstu można deiniować

bardziej złożone mechanizmy ko-

relowania zdarzeń. Poniższa sekcja

przedstawia szczegółowe przykła-

dy oraz dyskusję na temat konstru-

owania zbiorów reguł SEC pod ką-

tem monitorowania logów zdarzeń

bezpieczeństwa.

Listing 3. Zbiór reguł SEC do konsolidacji wiadomości alarmowych

priorytetu 1 ze Snort IDS

# Matching input line:

# Apr 4 10:10:55 snorthost.mydomain [auth.alert] snort[18800]:

# [1:2528:14] SMTP PCT Client_Hello overlow attempt

# [Classiication: Attempted Administrator Privilege Gain]

# [Priority: 1]: {TCP} 192.168.5.43:28813 -> 192.168.250.44:25

type = Single

ptype = RegExp

pattern = snort \ [ \ d + \ ]: \ [[ \ d :]+ \ ] . * \ [ Priority : 1 \ ]: \ S + \

([ \ d \. ]+): ?\ d * -> [ \ d \. ]+: ?\ d *

context =! ATTACK_FROM_ $ 1

continue = TakeNext

desc = Priority 1 attack started from $ 1

action = create ATTACK_FROM_ $ 1 ; \

pipe ' % s ' mail - s ' Snort : priority 1 attack from $ 1 ( alert ) ' root

Monitorowanie logów

bezpieczeństwa z SEC

W niniejszej sekcji omówimy kilka

przykładów zbiorów reguł oraz moż-

liwości przetwarzania zdarzeń ofero-

wane przez SEC. Przykładowe zbio-

ry reguł napisane zostały pod ką-

tem monitorowania w czasie rzeczy-

wistym logów zdarzeń – logów zda-

rzeń Snort IDS, dziennika systemo-

wego Solaris /var/adm/messages

oraz logu błędów serwera WWW

Apache. Zbiory te zostały przetesto-

wane pod SEC w wersji 2.3.3.

Jeżeli chcecie poeksperymento-

wać z przedstawionymi w tej sekcji

zbiorami reguł, możecie pobrać SEC

z jego strony domowej. Aby zainsta-

lować SEC z jego pakietu źródłowe-

go, rozpakuj archiwum (np. tar –xzvf

sec-2.3.3.tar.gz ) i skopiuj nowo utwo-

rzony plik sec.pl do odpowiedniego

katalogu (np. cp sec-2.3.3/sec.pl /

usr/local/bin ). Strona domowa SEC

zawiera także odnośniki do pakietów

binarnych SEC dla różnych platform

systemów operacyjnych.

Aby uruchomić SEC w trybie inte-

raktywnym, do monitorowania dzien-

nika /var/log/messages z wykorzy-

staniem reguł z my.conf , wprowadź

w linii poleceń poniższe:

type = Single

ptype = RegExp

pattern = snort \ [ \ d + \ ]: \ [[ \ d :]+ \ ] . * \ [ Priority : 1 \ ]: \ S + ([ \ d \. ]+): ?\ d * ->

[ \ d \. ]+: ?\ d *

context = ATTACK_FROM_ $ 1

desc = Priority 1 incident from $ 1

action = add ATTACK_FROM_ $ 1 $ 0 ; \

set ATTACK_FROM_ $ 1 300 ( report ATTACK_FROM_ $ 1 \

mail - s ' Snort : priority 1 attack from $ 1 ( report ) ' root )

Listing 4. RegułaSEC przepuszczająca jedynie linie z /var/log/

messages

type = Suppress

ptype = TValue

pattern = TRUE

context =! _FILE_EVENT_ / var / log / messages

desc = Pass only those lines that come from / var / log / messages

i/lub –conf . Inne często stosowane

opcje to –log (ustawia dziennik SEC),

–syslog (poleca SEC generować lo-

gi poprzez syslog ), –debug (ustawia

poziom logowania SEC), –pid (usta-

wia plik identyikatora procesu SEC),

–detach (zmusza SEC do odłączenia

się od sterującego terminala i sta-

nia się demonem) oraz –testonly

(sprawdza poprawność reguł bez

uruchamiania SEC).

gdy demon Snorta zauważa w sie-

ci pakiet zapytania SNMP z polem

społeczności o wartości public , za-

pisuje on odpowiednią wiadomość

– jednak ze względu na to, że wie-

le narzędzi do zarządzania siecią

odpytuje te same hosty wielokrot-

nie z krótkimi interwałami czaso-

wymi, wiadomość może być zapi-

sana wielokrotnie dla tych samych

par źródłowych i docelowych ad-

resów IP. Omawiana tu reguła im-

plementuje scenariusz korelowania

zdarzeń zwany kompresją – powta-

rzające się wystąpienia identycz-

nych zdarzeń są redukowane do

pojedynczego zdarzenia. Parametr

ptype w deinicji reguły deklaruje,

że wzorzec dopasowania zdarze-

nia jest wyrażeniem regularnym,

zaś parametr pattern podaje wy-

rażenie regularne. Parametr desc

sec.pl –conf=my.conf

–input=/var/log/messages

Do skonigurowania SEC tak, by mo-

nitorował on swoje standardowe wej-

ście (jest to przydatne podczas te-

stów) posłuży nam poniższe pole-

cenie:

Reguły SEC i operacje

korelacji zdarzeń

Załóżmy, że mamy plik reguł o na-

zwie my.conf , zawierający jedną re-

gułę przedstawioną na Listingu 1.

Reguła SingleWithSuppress z

Listingu 1 została zaprojektowa-

na tak, by dopasowywać wiadomo-

ści SNMP public access udp z lo-

gów Snort IDS. Za każdym razem,

sec.pl –conf=my.conf –input=–

Zauważ, że w linii poleceń można

podać więcej niż jedną opcję: –input

www.hakin9.org

hakin9 Nr 5/2006

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: