www.hakin9.org

hakin9 Nr 5/2006

44

Pod lupą

W

sferze bezpieczeństwa systemu in-
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.

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.

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

Pod lupą

46

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 skonfigurować
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.

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

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-
fikuje 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 identyfikować 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-
finiowanych 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 potrafią 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-

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 [Classification: 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

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

47

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 firm 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-

ka z życia wziętych przykładów na
to, jak wykorzystać SEC w monitoro-
waniu i korelowaniu zdarzeń z logów
bezpieczeństwa.

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ść konfiguracji, 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.

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.

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

hakin9 Nr 5/2006

www.hakin9.org

Pod lupą

48

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-
ficznego 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).

Konfiguracja SEC składowana

jest w plikach tekstowych, które moż-
na tworzyć i modyfikować 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 konfigu-
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 konfigura-
cję programu, jako że wiele unikso-
wych narzędzi (np. grep, sed, find
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 definicji 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ń:

• 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ń,

• 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ść definicji 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 identyfikator 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-

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

49

su itd. Łącząc grupy reguł z odpo-
wiednimi listami działań i wyraże-
niami kontekstu można definiować
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.

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:

sec.pl –conf=my.conf
–input=/var/log/messages

Do skonfigurowania 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:

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

Zauważ, że w linii poleceń można
podać więcej niż jedną opcję:

–input

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 identyfikatora 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).

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,

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 definicji reguły deklaruje,
że wzorzec dopasowania zdarze-
nia jest wyrażeniem regularnym,
zaś parametr pattern podaje wy-
rażenie regularne. Parametr desc

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 overflow attempt
# [Classification: 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

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

hakin9 Nr 5/2006

www.hakin9.org

Pod lupą

50

definiuje łańcuch opisu zdarzenia,
parametr action – listę działań wy-
syłającą e-mailem ostrzeżenie do
lokalnego użytkownika root, win-
dow zaś – ustawia okno korelacji
na 300 sekund.

Kiedy wyrażenie regularne pa-

suje do linii na wejściu, zmienne
specjalne $1 i $2 przyjmują wartości
pól odpowiednio: źródłowego i do-
celowego adresu IP z tej linii – wy-
rażenie regularne korzysta bowiem
w przypadku tych pól ze składni
z nawiasami. Następnie SEC wyli-
czy klucz korelacji zdarzeń łącząc
nazwę pliku z regułą, identyfikator
reguły oraz łańcuch opisu zdarze-
nia – np. jeżeli $1 to 192.168.115.34,
a $2 to 192.168.52.179, wówczas
uzyskany klucz będzie miał postać

my.conf | 0 | SNMP public access
from 192.168.115.34 to 192.168.52.179

(identyfikatory reguł nadawane są
od wartości zero, zaś znak poto-
ku wykorzystaliśmy jako separator).
Jeżeli istnieje operacja o danym klu-
czu, SEC przekaże do niej zdarze-
nie wejściowe. Jeżeli operacja o da-
nym kluczu nie istnieje, SEC utwo-
rzy nową, o czasie życia 300 se-
kund. Operacja natychmiast wysy-
ła e-mailem ostrzeżenie do lokal-
nego użytkownika root, korzysta-
jąc z działania pipe – łańcuch opi-
su zdarzenia, oznaczony tutaj przez
%s, zostanie przekazany na stan-
dardowe wejście polecenia

mail –s

'Snort alert' root

– po czym za-

cznie ignorować wszystkie dalsze
zdarzenia tego rodzaju otrzymane
przez SEC do skorelowania. Inny-
mi słowy, reguła zredukuje powta-
rzające się wiadomości SNMP pu-
blic access udp z tymi samymi: źró-
dłowym i docelowym adresem IP,
do pojedynczej wiadomości (pierw-
szej z nich).

Zawarcie w kluczu korelacji zda-

rzeń nazwy pliku z regułami oraz
identyfikatora reguły gwarantuje, że
nigdy nie wystąpi kolizja pomiędzy
operacjami korelacji zdarzeń wy-
zwolonymi przez różne reguły. Po-
nadto użytkownik końcowy może,
wybierając odpowiednią wartość
parametru desc, zmienić zakres ko-
relowania zdarzeń. Jeżeli na przy-

kład wartość parametru desc to

SNMP

public access from $1

, SEC zreduku-

je wszystkie wiadomości o takim sa-
mym źródłowym adresie IP do jed-
nej, całkowicie ignorując adresy do-
celowe.

Na koniec warto wspomieć, iż

należy zachować ostrożność przy
korzystaniu ze zmiennych specjal-
nych $1, $2, … w definicjach sta-
nowiących część linii poleceń – ich
wartości zostaną bowiem zinter-
pretowane przez powłokę tak sa-
mo, jak reszta linii poleceń. Przy-
kładowo, jeżeli parametr pattern
ma wartość

sshd\[\d+\]: (.+)

, ac-

tion zaś –

shellcmd echo $1 >>

myfile

, złowrogi użytkownik mógłby

wywołać poprzez SEC dowolne po-
lecenie zapisując do logów za po-
mocą narzędzia logger fałszywą li-
nię

sshd[0]: `mycommand`

. Aby unik-

nąć sytuacji tego rodzaju, wzorce
SEC ustawiające specjalne zmien-
ne dla linii poleceń powinny być pi-
sane tak, by metaznaki powłoki i in-
ne niespodziewane dane nie były
przypisywane zmiennym.

Tworzenie zestawów reguł

SEC z pojedynczych reguł

Przedstawiony na Listingu 2 zbiór
reguł do przetwarzania wiadomości
o porażkach i sukcesach uwierzy-
telniania stanowi bardziej złożony
przykład, pokazujący jak uzyskać
można interakcję reguł poprzez
syntetyczne zdarzenia oraz kon-
teksty. Zadaniem tego zbioru reguł
jest filtrowanie przypadkowych po-
rażek logowania, po których wkrót-
ce następuje sukces, a następnie
zliczenia nieprzypadkowych po-
rażek, próbując w ten sposób wy-
kryć próby włamania się w krótkim
okresie czasu na dużą liczbę wielu
kont, w odróżnieniu od działań skie-
rowanych przeciwko pojedynczemu
bądź kilku kontom.

Pierwsza reguła, typu PairWi-

thWindow, ma za zadanie kojarzyć
wiadomości sshd o porażkach i
sukcesach uwierzytelniania, w so-
larisowym dzienniku systemowym
/var/adm/messages. Po tym jak wy-
rażenie regularne podane przez pa-
rametr pattern dopasowane zosta-

nie do wiadomości o porażce uwie-
rzytelniania dla danego użytkow-
nika, zmienna $1 ustawiana jest
na nazwę użytkownika. Następnie
SEC uruchamia operację korelowa-
nia zdarzeń, która czeka na wiado-
mość o sukcesie uwierzytelnienia
w ciągu kolejnych 30 sekund. Je-
żeli wiadomość ta dotrze na czas,
nie są podejmowane żadne dzia-
łania (ponieważ parametr action2
ustawiany jest na

none

). Warto za-

uważyć, że w regułach Pair* moż-
na korzystać ze zmiennych specjal-
nych $1, $2, … w parametrze pat-
tern2, tj. wzorzec w drugiej połowie
reguły Pair* może mieć dynamiczny
charakter. Jeżeli wiadomość o suk-
cesie uwierzytelnienia nie pojawi-
ła się, operacja generuje poprzez
działanie event syntetyczne zdarze-
nie o nazwie

PAM _ AUTHENTICATION _

FAILED _ FOR _ <username>

.

Synte-

tyczne zdarzenia SEC traktowane
są jak zwyczajne zdarzenia wej-
ściowe, czytane z plików dziennika
– są dodawane do kolejki wejścio-
wej i dopasowywane do wszyst-
kich reguł.

Druga reguła, typu SingleWithTh-

reshold, uruchamia operację korela-
cji zdarzeń dopasowującą i zliczającą
wiadomości

PAM _ AUTHENTICATION _

F A I L E D _ F O R _ < u s e r n a m e >

.

Jeżeli w oknie o szerokości 600 se-
kund zaobserwowano 10 takich wia-
domości, operacja wysyła e-mailem
ostrzeżenie do lokalnego użytkow-
nika root, a ponadto tworzy kontekst

COUNTING _ OFF

o czasie życia 1 go-

dziny – pozwala on uniknąć wysyła-
nia ostrzeżeń do roota co 10 minut
w sytuacji, gdy skanowanie kont trwa
dłużej. Wyrażenie podane w parame-
trze context definicji reguły można od-
czytać jako: kontekst USER_<user-
name>_ALREADY_COUNTED nie
istnieje i kontekst COUNTING_OFF
nie istnieje (w wyrażeniach kontekstu
SEC

!

oznacza logiczne zaprzecze-

nie,

&&

- logiczną koniunkcję (AND), a

||

- logiczną alternatywę (OR)). Dla-

tego w przypadku istnienia kontek-
stu

COUNTING _ OFF

wyrażenie zwró-

ci fałsz i reguła nie dopasuje żadne-
go zdarzenia. Po zliczeniu zdarzenia

PAM _ AUTHENTICATION _ FAILED _ FOR _

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

51

<username>

jest ono przekazywane

do trzeciej reguły, albowiem parametr
continue drugiej reguły ma wartość

TakeNext

. Trzecia reguła tworzy kon-

tekst

USER _ <username> _ ALREADY _

COUNTED

i, biorąc pod uwagę że czas

życia kontekstu i rozmiar okna zlicza-
nia są takie same (600 sekund), za-
pewnia on że każda unikalna nazwa
użytkownika zwiększy licznik tylko
raz na etapie zliczania (po utworze-
niu kontekstu dla danej nazwy użyt-
kownika wyrażenie kontekstu drugiej
reguły dla tej nazwy będzie zwracało
fałsz). Innymi słowy, interakcja pomię-
dzy drugą a trzecią regułą oznacza,
że e-maile z ostrzeżeniami będą wy-
syłane tylko w przypadkach dotyczą-
cych dziesięciu różnych kont.

Wykorzystanie kontekstów

SEC do konsolidacji zdarzeń

Konteksty SEC wykorzystać moż-
na nie tylko do aktywowania i de-
aktywowania reguł, ale także do
składowania zdarzeń. SEC definiu-
je działanie add dodające zdarze-
nie do składu zdarzeń danego kon-
tekstu, działanie report do przekazy-
wania wszystkich zdarzeń ze składu
na standardowe wejście zewnętrz-
nego polecenia, a także szereg zda-
rzeń do wykonywania innych ope-
racji na kontekstach (np. do prze-
noszenia danych pomiędzy kontek-
stami bądź zmiennymi specjalnymi
SEC). W niniejszej sekcji przyjrzy-
my się prostemu scenariuszowi wy-
korzystania kontekstów do agrega-
cji i zgłaszania wiadomości alarmo-
wych Snort IDS.

Wiadomości alarmowe w dzien-

nikach demonów Snorta mają przy-
znawany priorytet od 1 do 3 (gdzie
1 to najwyższy, a 3 – najniższy
priorytet), ponadto każda wiado-
mość posiada pola ze źródłowym
i docelowym adresem IP, odzwier-
ciedlające nadawcę i odbiorcę po-
dejrzanego ruchu w sieci. Dość po-
wszechnym zjawiskiem jest fakt, że
po zauważeniu przez Snorta zda-
rzenia dla pewnego źródłowego
adresu IP, wkrótce potem pojawiają
się inne zdarzenia związane z tym-
że adresem (szczególnie prawdzi-
we jest to w przypadku ataków za

pomocą narzędzi starających się
znaleźć w sieci docelowej jak naj-
większą liczbę słabych punktów).
Z tego względu często nie jest roz-
sądne generowanie alarmów dla
każdego wydarzenia – lepiej kon-
solidować je w mniejszą liczbę ra-
portów.

Zestaw reguł przedstawiony na

Listingu 3 zaprojektowano tak, by
przetwarzać komunikaty Snorta o
priorytecie 1 i tej samej wartości po-
la źródłowego adresu IP (w dalszej
części tego fragmentu tekstu ruch
sieciowy wyzwalający takie wiado-
mości nazywać będziemy atakami).
Kiedy zauważona zostaje pierwsza
wiadomość dla danego źródłowe-
go adresu IP, SEC wyśle e-mailem
ostrzeżenie o rozpoczęciu ataku. Je-
żeli w ciągu kolejnych 5 minut nie po-
jawiły się żadne nowe wiadomości
dla tego adresu o priorytecie 1, SEC
traktuje to jako koniec ataku i wysyła
e-mailem raport zawierający wszyst-
kie zapisane wiadomości istotne dla
tego ataku.

Aby składować wiadomości doty-

czące pewnego adresu IP

<ipaddress>

,

zbiór reguł tworzy kontekst

ATTACK _

FROM _ <ipaddress>

. Pierwsza reguła

wykrywa pierwsze zdarzenie przyna-
leżące do ataku – dopasowuje on zda-
rzenia o priorytecie 1 dla danego źró-
dłowego adresu IP tylko wtedy, gdy nie
istnieje jeszcze kontekst dla tego adre-
su. Po dopasowaniu zdarzenia reguła
tworzy kontekst i wysyła e-mailem do
lokalnego użytkownika root ostrzeże-
nie o rozpoczęciu ataku. Druga regu-
ła dopasowuje wiadomości priorytetu
1 i za pomocą działania add dołącza
je do składu zdarzeń odpowiedniego
kontekstu (zmienna specjalna $0 za-
wiera całość dopasowanej linii wiado-
mości). Następnie reguła wykorzystu-
je działanie set, aby przedłużyć czas
życia kontekstu o kolejne 300 sekund
oraz ustawić dlań działanie przy kaso-
waniu (

report ATTACK _ FROM _ $1 mail

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

). Działanie to zostanie

wywołane tuż przed upływem cza-
su życia kontekstu i jego usunięciem,

Listing 5.

Zbiór reguł SEC do monitorowania dziennika błędów

lokalnego serwera WWW Apache za pomocą dynamicznej listy wyrażeń
regularnych, a także przekazywania pasujących linii do zdalnego
serwera syslog

type

=

Single

ptype

=

SubStr

pattern

=

SEC_STARTUP

context

=

SEC_INTERNAL_EVENT

continue

=

TakeNext

desc

=

Load

the

Sys

::

Syslog

module

action

=

assign

%

a

0

;

eval

%

a

(

require

Sys

::

Syslog

);

\

eval

%

a

(

exit

(

1

)

unless

%

a

)

type

=

Single

ptype

=

RegExp

pattern

=(

SEC_STARTUP

|

SEC_RESTART

)

context

=

SEC_INTERNAL_EVENT

desc

=

Compile

the

logging

routine

and

initialize

the

list

of

patterns

action

=

eval

%

syslog

(

sub

{

Sys

::

Syslog

::

syslog

(

'

err

', $

_

[

0

]);

}

);

\

eval

%

a

(

@

regexp

=

(

'

192

\.

168

\.

1

\.

1

', '

File

does

not

exist

:

'

);

\

Sys

::

Syslog

::

openlog

(

'

SEC

', '

cons

,

pid

', '

daemon

'

)

)

# Matching input line:
# [Fri Mar 24 09:19:50 2006] [error] [client 192.168.1.1]
# File does not exist: /var/apache/htdocs/robots.txt

type

=

Single

ptype

=

PerlFunc

pattern

=

sub

{

foreach

my

$

pat

(

@

regexp

)

{

\

if

(

$

_

[

0

]

=

~ /$

pat

/

)

{

return

1

;

}

}

return

0

;

}

desc

=

Forward

the

suspicious

message

line

to

remote

syslog

server

action

=

call

%

o

%

syslog

$

0

hakin9 Nr 5/2006

www.hakin9.org

Pod lupą

52

tj. w sytuacji gdy nie zaobserwowano
żadnych wiadomości o priorytecie 1
dla danego IP przez ostatnie 300 se-
kund. Działanie przy kasowaniu wyko-
rzystuje działanie report do przekaza-
nia składu zdarzeń danego kontekstu
do polecenia

mail -s 'Snort: priority

1 attack from $1 (report)' root

, któ-

re wysyła zebrane zdarzenia do lokal-
nego użytkownika root. Z jednej stro-
ny ataki składające się z wielu zdarzeń
będą zgłaszane w jednym liście, z dru-
giej zaś nawet w przypadku długotrwa-
łego ataku końcowy użytkownik wciąż
otrzyma na czas ostrzeżenie o jego
rozpoczęciu.

Monitorowanie wielu plików

Obok możliwości zaawansowane-
go korelowania i konsolidacji zda-
rzeń, SEC posiada kolejną istot-
ną zaletę w porównaniu z inny-
mi dobrze znanymi rozwiązaniami
do monitorowania logów – możli-
wość jednoczesnego monitorowa-
nia wielu dzienników, dzięki której
SEC jest w stanie korelować zda-
rzenia pochodzące z różnych źró-
deł. Ponadto w sytuacji, gdy w sys-
temie istnieje duża liczba dzienni-
ków, mogą być one monitorowane
przez pojedynczy proces SEC, co
nie tylko oszczędza miejsce w ta-
beli procesów, ale także upraszcza
pielęgnację samego SEC (np. SEC
posiada wtedy tylko jeden identy-
fikator procesu i jeden plik dzien-
nika). Konfiguracja SEC pod ką-
tem monitorowania więcej niż jed-
nego źródła wejściowego jest bar-
dzo prosta – po prostu podaje się
mu więcej niż jedną opcję

–input

w

linii poleceń, przekazuje się opcji

–input

nazwę pliku zawierającą jo-

kery, względnie łączy obie możli-
wości.

Jeżeli jednak stosuje się wie-

le reguł, korzystanie z więcej niż
jednego źródła wejściowego może
spowodować problemy z wydajno-
ścią i przejrzystością. Jeżeli obec-
nych jest wiele reguł zaprojektowa-
nych pod kątem pojedynczego źró-
dła, dopasowywanie doń linii po-
chodzących z innych źródeł może
generować istotny narzut na dzia-
łanie programu. Ponadto jeżeli linie

wejściowe z różnych źródeł przy-
padkowo pasują do reguł, do któ-
rych nie miały pasować, wywoły-
wane w ten sposób niespodziewa-
ne efekty uboczne mogą uczynić
zachowanie zbioru reguł niezrozu-
miałym dla użytkownika.

Celem zajęcia się ww. problema-

mi SEC oferuje opcję

–intcontexts

,

która nakazuje mu stworzenie we-
wnętrznego kontekstu po wczyta-
niu linii ze źródła, a następnie ska-
sowaniu go po porównaniu tej li-
nii ze wszystkimi regułami. Jeże-
li plik wejściowy nosi nazwę np.
/var/log/messages, odpowiedni we-
wnętrzny kontekst zostanie nazwa-
ny

_ FILE _ EVENT _ /var/log/messages

.

Dzięki temu, że wewnętrzne kontek-
sty mogą być wykorzystywane w wy-
rażeniach kontekstu w definicjach re-
guł, użytkownik może pisać reguły
pasujące do zdarzeń pochodzących
jedynie z pewnego konkretnego źró-
dła. Jeżeli użytkownik pragnie zasto-
sować własne nazwy wewnętrznych
kontekstów albo stworzyć jeden ta-
ki kontekst dla wielu źródeł wejścio-
wych, odpowiednie nazwy mogą być
podane w argumencie opcji

–input

.

Przykładowo, opcje

–input=/var/

log/syslog=SYSLOG –input=/var/adm/
messages=SYSLOG

nakazują SEC sto-

sować wewnętrzny kontekst

SYSLOG

zarówno dla /var/log/syslog, jak i
/var/adm/messages.

Tytułem przykładu zastosowania

wewnętrznych kontekstów rozważ-
my regułę Suppress przedstawioną
na Listingu 4, umieszczoną na po-
czątku pliku z regułami.

Reguła SEC typu Suppress

ukrywa pasujące do niej zdarze-
nia – pełni rolę filtru nieprzepusz-
czającego zdarzeń do dalszych re-
guł w ich pliku. W definicji regu-
ły na Listingu 4 parametry ptype
i pattern określają, że wzorzec to
wartość logiczna TRUE, pasująca
do każdej linii – jednak wyrażenie
kontekstu

! _ FILE _ EVENT _ /var/

log/messages

zwraca prawdę je-

dynie dla linii nie pochodzących z
/var/log/messages. Z tego wzglę-
du reguła ta może zostać użyta
na początku pliku z regułami za-
projektowanymi do przetwarzania

/var/log/messages, przepuszcza
ona bowiem jedynie linie dla niej
odpowiednie.

Jeżeli opcja –intcontexts zosta-

ła podana, dla syntetycznych zda-
rzeń generowanych przez działa-
nie event SEC stosuje wewnętrz-
ny

kontekst

_ INTERNAL _ EVENT

.

Z drugiej strony, czasem końco-
wy użytkownik chciałby móc zde-
finiować inny wewnętrzny kontekst
dla syntetycznego zdarzenia. Moż-
na to obejść tworząc nazwany po-
tok za pomocą narzędzia mkfifo,
nakazując SEC za pomocą opcji

–input

monitorowanie tego potoku

i stosując w odpowiednich defini-
cjach reguł działanie write zamiast
event. Jeżeli np. stworzyliśmy na-
zwany potok /var/log/pipe wywołu-
jąc polecenie

mkfifo /var/log/pipe

,

a SEC został uruchomiony z opcją

–input=/var/log/pipe=SYSLOG

,

za-

stosowanie

action=write /var/log/

pipe MY _ SYNTHETIC _ EVENT

(które

to działanie każe SEC zapisać linię

MY _ SYNTHETIC _ EVENT

do /var/log/

pipe) powoduje wystąpienie zda-
rzenia

MY _ SYNTHETIC _ EVENT

w we-

wnętrznym kontekście

SYSLOG

.

Integracja własnego kodu

Perla z regułami SEC

Chociaż omówione do tej pory moż-
liwości SEC pozwalają pisać zbiory
reguł odpowiednie dla szerokiego
zakresu scenariuszy korelowania
zdarzeń, istnieją pewne przypadki
których nie da się przetworzyć po-
przez połączenie tych możliwości.
Przykładowo, wzorce RegExp nie
mogą być wykorzystane do zdefi-
niowania dynamicznej listy wyra-
żeń regularnych. Ponadto działanie
pipe z poprzedniego przykładowe-
go zbioru zadań wymaga tworzenia
osobnych procesów dla zewnętrz-
nych poleceń, przez co wywołanie
pipe kilkaset razy na sekundę spo-
woduje zmarnowanie na tworzenie
nowych procesów znaczących ilo-
ści czasu procesora. Wprawdzie
SEC zapewnia zmienne specjalne,
które użytkownik może wykorzy-
stać do składowania wartości, są
one jednak podobne do perlowych
skalarów i nie jest możliwe zbudo-

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

53

wanie z nich bardziej złożonych
struktur danych (takich jak perlowe
listy czy hasze). Wychodząc na-
przeciw tym problemom SEC ofe-
ruje wzorce PerlFunc (zdefiniowa-
ne przez użytkownika funkcje Per-
la służące do dopasowywania linii
wejściowych) oraz perlowe wyra-
żenia kontekstu, ale także i działa-
nia eval i call pozwalające kompilo-
wać i uruchamiać własny kod Perla
z poziomu SEC.

Zbiór reguł z Listingu 5 pokazu-

je, jak można zastosować działania
eval i call oraz wzorce PerlFunc,
ale także jak korzystać w SEC z
modułów Perla oraz jak tworzyć
i sięgać do struktur danych Perla
we własnym kodzie. Zbiór reguł za-
projektowano pod kątem monitoro-
wania dziennika błędów lokalnego
serwera WWW Apache za pomo-
cą dynamicznej listy wyrażeń regu-
larnych, a także przekazywania pa-
sujących linii do zdalnego serwe-
ra syslog (gdzie mogą być skore-
lowane przez inną instancję SEC).
Celem zaoszczędzenia czasu pro-
cesora zbiór nie wywołuje w ce-
lu przekazywania linii jako wiado-
mości syslog, narzędzia logger, po-
legając zamiast tego na funkcjach

openlog()

i

syslog()

z perlowego

modułu Sys::Syslog.

Aby móc korzystać z modu-

łu Sys::Syslog musi on być za-
ładowany przy starcie SEC. Je-
żeli SEC uruchomiony został z
opcją

–intevents

, przy starcie ge-

neruje on jako pierwsze syntetycz-
ne zdarzenie

SEC _ STARTUP

, przy-

pisuje mu wewnętrzny kontekst

SEC _ INTERNAL _ EVENT

i przetwarza

je przed jakimikolwiek innymi zda-
rzeniami. Pozwala to użytkowniko-
wi pisać reguły służące do urucha-
miania rozmaitych procedur starto-
wych. Pierwsza reguła jest regu-
łą właśnie tego rodzaju, próbują-
cą załadować moduł Sys::Syslog
korzystając z działań: assign oraz
eval. Najpierw ustawia ona zmien-
ną specjalną %a na 0 za pomocą
działania assign, a następnie prze-
twarza kod Perla

require Sys::

Syslog

za pomocą działania eval

(które wewnętrznie wywołuje per-

Bibliografia

• Jim Brown. 2003. Working with SEC – the Simple Event Correlator. http://sixshoot

er.v6.thrupoint.net/SEC-examples/article.html,

• P. Froehlich, W. Nejdl, M. Schroeder, C. V. Damasio, L. M. Pereira. 2002. Using

Extended Logic Programming for Alarm-Correlation in Cellular Phone Networks.
Applied Intelligence 17(2), pp. 187-202,

• Boris Gruschke. 1998. Integrated Event Management: Event Correlation using De-

pendency Graphs. Proceedings of the 9th IFIP/IEEE International Workshop on
Distributed Systems: Operations and Management, pp. 130-141,

• G. Jakobson i M. Weissman. 1995. Real-time telecommunication network ma-

nagement: Extending event correlation with temporal constraints. Proceedings
of the 4th International Symposium on Integrated Network Management, pp.
290-301,

• Dilmar Malheiros Meira. 1997. A Model For Alarm Correlation in Telecommunica-

tion Networks. PhD thesis, Federal University of Minas Gerais, Brazil,

• Elaine Rich i Kevin Knight. 1991. Artificial Intelligence, 2nd edition. McGraw-Hill,

ISBN 0-07-052263-4,

• John P. Rouillard. 2004. Real-time Logfile Analysis Using the Simple Event Corre-

lator (SEC). Proceedings of USENIX 18th System Administration Conference, pp.
133-149,

• M. Steinder i A. S. Sethi. 2002. End-to-end Service Failure Diagnosis Using Be-

lief Networks. Proceedings of the 8th IEEE/IFIP Network Operations and Manage-
ment Symposium, pp. 375-390,

• James Turnbull. 2005. Hardening Linux. Apress, ISBN: 1-59059-444-4.
• Risto Vaarandi. 2005. Tools and Techniques for Event Log Analysis. PhD thesis,

Tallinn University of Technology, Estonia,

• Hermann Wietgrefe. 2002. Investigation and Practical Assessment of Alarm Cor-

relation Methods for the Use in GSM Access Networks. Proceedings of the 8th
IEEE/IFIP Network Operations and Management Symposium, pp. 391-404,

• Hermann Wietgrefe, Klaus-Dieter Tuchs, Klaus Jobmann, Guido Carls, Peter

Froehlich, Wolfgang Nejdl, Sebastian Steinfeld. 1997. Using Neural Networks
for Alarm Correlation in Cellular Phone Networks. Proceedings of the Internatio-
nal Workshop on Applications of Neural Networks in Telecommunications, pp.
248-255,

• S. A. Yemini, S. Kliger, E. Mozes, Y. Yemini i D. Ohsie. 1996. High speed and ro-

bust event correlation. IEEE Communications Magazine 34(5), pp. 82-90.

W Sieci

• http://www.bmc.com/ – BMC Patrol,
• http://www.cisco.com/ – CiscoWorks,
• http://www.managementsoftware.hp.com/products/ecs/index.html – HP ECS,
• http://www.openview.hp.com/ – HP OpenView,
• http://www.netfilter.org/ – Iptables,
• http://www.logec.com/ – LOGEC,
• http://www.cert.dfn.de/eng/logsurf/ – Logsurfer,
• http://www.mysql.com/ – MySQL,
• http://www.nagios.org/ – Nagios,
• http://www.openservice.com/products/nervecenter.jsp – NerveCenter,
• http://www.micromuse.com/ – NetCool,
• http://www.prelude-ids.org/ – Prelude IDS,
• http://www.rulecore.com/ – RuleCore,
• http://simple-evcorr.sourceforge.net/ – Simple Event Correlator,
• http://www.smarts.com/ – SMARTS,
• http://snmptt.sourceforge.net/ – SNMPTT,
• http://www.snort.org/ – Snort IDS,
• http://swatch.sourceforge.net/ – Swatch,
• http://www.balabit.com/products/syslog_ng/ – Syslog-ng.

hakin9 Nr 5/2006

www.hakin9.org

Pod lupą

lową funkcję

eval()

). Jeżeli dzia-

łanie eval zakończyło się sukce-
sem i moduł został załadowany, do
%a przypisana zostanie wartość 1
(którą to wartość zwraca pozytyw-
ne wywołanie

require Sys::Syslog

),

jeżeli eval poniosło porażkę %a za-
chowuje swoją oryginalną wartość
(0). Następnie ponownie wykorzy-
stujemy działanie eval, aby spraw-
dzić wartość %a; jeżeli wynosi ona
0 (tj. moduł nie mógł zostać zała-
dowany), wywołujemy w perlowym
kodzie przetwarzanym przez eval
polecenie

exit(1)

. Jako że wywo-

łanie

exit(1)

ma miejsce wewnątrz

procesu SEC process, spowodu-
je ono zamknięcie SEC z kodem
wyjścia 1.

Przeznaczeniem drugiej reguły

jest dopasowywanie zarówno we-
wnętrznych zdarzeń

SEC _ STARTUP

,

jak i

SEC _ RESTART

(jeżeli SEC uru-

chomiony został z opcją

–intevents

,

po otrzymaniu sygnału SIGHUP
– żądania resetu jego wewnętrz-
nego stanu i ponownego wczyta-
nia konfiguracji – program generuje
syntetyczne zdarzenie

SEC _ RESTART

,

w wewnętrznym kontekście

SEC _

INTERNAL _ EVENT

). Po zaobserwo-

waniu pasującego zdarzenia, regu-
ła najpier korzysta z działania eval
aby przetworzyć kod Perla

sub {

Sys::Syslog::syslog('err', $ _ [0]);
}

. Kod ten stanowi definicję funkcji,

w efekcie eval skompiluje ją i zwróci
wskaźnik do skompilowanego kodu,
który zostanie zapisany w zmiennej
specjalnej %syslog. Sama funkcja
przyjmuje jeden parametr wejściowy
i korzysta z funkcji

syslog()

z modu-

łu Sys::Syslog, by przesłać parametr
wejściowy jako wiadomość poziomu
err do serwera syslog. Następnie re-
guła zainicjuje listę @regexp – per-
lową listę do przechowywania wy-
rażeń regularnych. @regexp jest li-
stą globalną, dzięki czemu można
do niej sięgać bądź ją modyfikować
kolejnymi wywołaniami eval. (Aby
uniknąć kolizji z nazwami zmien-
nych w kodzie SEC tworzona jest
osobna przestrzeń nazw,

main::SEC

,

zaś działanie eval zawsze przetwa-
rza własny kod Perla w tej przestrze-
ni.) Ostatnim krokiem jest otwarcie
połączenia syslog za pomocą funk-
cji

openlog()

, ustawienie nazwy pro-

gramu na

SEC

, obiektu logowania

na

daemon

oraz opcji logowania na

cons,pid

(jeżeli standardowe logowa-

nie zawiedzie; wyślij komunikat na
konsolę; dołącz do każdej wiadomo-
ści identyfikator procesu).

Trzecia reguła została stworzo-

na do dopasowywanie linii wejścia
za pomocą wyrażeń regularnych

z listy @regexp, którą zainicjowa-
ła druga reguła (i która może być
zmieniana w czasie działania pro-
gramu). Do dopasowywania regu-
ła wykorzystuje wzorzec PerlFunc
– wartość parametru pattern musi
być poprawną definicją funkcji Per-
la, która zostanie skompilowana w
czasie wczytywania reguł. W przy-
padku trzeciej reguły funkcja po-
biera linię wejściową (przekazaną
do funkcji poprzez parametr wej-
ściowy $_[0]) i skanuje listę @re-
gexp w poszukiwaniu pasujące-
go wyrażenia regularnego. Jeżeli
znajdziemy odpowiednie wyraże-
nie regularne funkcja zwraca 1 (co
oznacza, że wzorzec PerlFunc do-
pasował linię wejściową), w prze-
ciwnym razie zwraca 0 (co ozna-
cza brak dopasowania). W pierw-
szym przypadku reguła wywoła,
za pomocą działania call, prekom-
pilowaną funkcję Perla służącą do
logowania syslog. Zmienna spe-
cjalna %o służy do przechowywa-
nia wartości wyjściowej wywoła-
nia funkcji, zmienna %syslog za-
wiera wskaźnik do funkcji, zaś $0
(zawierająca całą dopasowywaną
linię wejścia) to parametr wejścio-
wy dla funkcji.

W ten sposób zbiór reguł efek-

tywnie implementuje dynamicz-

R

E

K

L

A

M

A

Chcesz regularnie otrzymywać swoje

czasopismo?

Chcesz płacić mniej?

22,50 zł

w prenumeracie tylko:

* więcej o prezentach na stronie www.hakin9.org/prenumerata

gr

at

is

do

każ

dej prenum

era

ty *

za numer

A

rc

hiw

um

m

agaz

ynu hakin9 2005

na

pł

yc

ie

C

D

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

55

ne dopasowywanie wyrażeń regu-
larnych do linii z dziennika błędów
serwera WWW, które nie mogłoby
być wyrażone poprzez wzorce Re-
gExp patterns, jak również prze-
kazywanie dopasowanych linii do
zdalnego serwera syslog bez two-
rzenia osobnego procesu wymaga-
nego przez zewnętrzne polecenie.
Dzięki temu, że wszystkie fragmen-
ty kodu Perla zastosowane w trze-
ciej regule są kompilowane, gdy
SEC jest uruchamiany, ich wykony-
wanie podczas działania programu
jest równie wydajne, jak wykonywa-
nie kodu samego SEC.

Wydajność SEC

i doświadczenia

praktyczne

Chociaż SEC jest napisany w ję-
zyku interpretowanym (i z tego
względu nie jest tak szybki ani nie
dysponuje pamięcią tak efektyw-
nie jak skompilowane programy w
C), jest w stanie przetwarzać set-
ki zdarzeń na sekundę i wciąż wy-
magać względnie skromnych zaso-
bów. W przeprowadzonym niedaw-
no eksperymencie o czasie trwa-
nia 49,8 dni, dwie instancje SEC
uruchomiono na linuksowym ser-
werze syslog z dwoma procesora-
mi Intel P4 Xeon o częstotliwości 3
GHz. Pierwsza instancja monitoro-
wała jednocześnie 20 dzienników
i korzystała z 243 reguł w 22 pli-
kach konfiguracyjnych, druga zaś
czytała dane z nazwanego potoku
i korzystała z 67 reguł w 5 plikach.
Pierwsza instancja przetworzyła
107 059 511 linii wejścia (średnio
24,9 linii na sekundę) i zużyła 3,0%

czasu procesora oraz 8,1 MB pa-
mięci. Druga instancja przetworzy-
ła 364 534 428 linii wejścia (śred-
nio 84,7 linii na sekundę), zużyw-
szy 8,8% czasu procesora oraz
6,1 MB pamięci.

Prędkość przetwarzania zda-

rzeń przez SEC silnie zależy od
sposobu ułożenia reguł, istnieje
więc kilka sposobów na poprawie-
nie wydajności. Jako że linie wej-
ściowe są porównywane z regułami
w kolejności, w jakiej te ostatnie de-
finiowane są w pliku, przesunięcie
najczęściej dopasowywanych re-
guł na początek pliku reguł oszczę-
dza czas procesora. Ponadto jeże-
li wiele linii wejścia nie pasuje do
żadnej reguły, oszczędność czasu
da nam również wstawienie na po-
czątku pliku z regułami odpowiada-
jących tym liniom reguł Suppress.
Jeżeli SEC skonfigurowano do mo-
nitorowania wielu źródeł, można
zwiększyć prędkość przetwarzania
zdarzeń przez program stosując
wewnętrzne konteksty (patrz sek-
cja Monitorowanie wielu plików).
Wśród innych pomysłów na popra-
wienie wydajności SEC wspomnieć
można pisanie wydajniejszych wy-
rażeń regularnych oraz zastępowa-
nie gdzie się da wzorców RegExp
wzorcami SubStr (te ostatnie są
szybsze).

W ciągu ostatnich kilku lat SEC

został przyjęty przez wiele różnych
rozmiarów instytucji oraz był wyko-
rzystywany w wielu dziedzinach,
w tym w monitorowaniu logów, za-
rządzaniu firewallami, detekcji intru-
zów oraz zarządzaniu siecią (tro-
chę szczegółowych studiów przy-

O autorze

Risto Vaarandi uzyskał w czerwcu 2005 stopień doktora inżynierii komputerowej na
Politechnice Tallińskiej (Estonia). Od ośmiu lat pracuje w SEB Eesti Ühispank jako in-
żynier rozwoju informatycznego, obecnie zaś jest także na część etatu badaczem w
Instytucie Informatyki na Uniwersytecie Tartu, Estonia. Z Risto można skontaktować
się poprzez jego stronę domową, dostępną pod adresem http://kodu.neti.ee/~risto.

Podziękowania

Opisane tu prace wspierane są przez SEB Eesti Ühispank, a ponadto uzyskały one
wsparcie finansowe w formie estońskiego narodowego grantu nr SF0182712s06.

padków znaleźć możesz w [Vaaran-
di 2005]). SEC stosowano z po-
wodzeniem z: Snort IDS, Prelude
IDS, firewallem iptables, HP Ope-
nView (zarówno NNMm jak i Ope-
rations), Nagios, CiscoWorks, BMC
patrol, SNMPTT itd. SEC wykorzy-
stywano pod szerokim zakresem
systemów operacyjnych, w tym pod
Linuksem, FreeBSD, OpenBSD, So-
larisem, HP-UXem, AIXem, Tru64
Unixem, Mac OSem X oraz Win-
dows 2000.

Podsumowanie

Niniejsza publikacja omówiła SEC
(Simple Event Correlator) – otwar-
te narzędzie do lekkiego i nieza-
leżnego od platformy korelowa-
nia zdarzeń – a ponadto przed-
stawiła z życia wziętych przykła-
dów wykorzystania SEC w moni-
torowaniu w czasie rzeczywistym
zdarzeń z logów bezpieczeństwa,
jednak ze względu na ograniczo-
ną przestrzeń nie wspomina ona
o wielu funkcjonalnościach SEC.
Zainteresowani mogą odnaleźć
dogłębny opis SEC w jego doku-
mentacji online. Dostępny jest tak-
że trochę innych źródeł informacji
na temat SEC. Repozytorium re-
guł SEC na BleedingSnort (http://
www.bleedingsnort.com/sec/) za-
wiera szereg przykładowych zbio-
rów reguł dla wielu scenariuszy,
na przykład korelowania zdarzeń
z programu Snort bądź zarządza-
nia firewallem iptables. Working
with SEC – the Simple Event Cor-
relator (Brown 2003) to tutorial on-
line, który nie tylko stanowi dobre
wprowadzenie do SEC, ale tak-
że omawia kilka zaawansowanych
zagadnień, takich jak np. integra-
cja SEC z MySQL. Rozdział 5 Har-
dening Linux (Turnbull 2005) opi-
suje, jak zaprząc SEC do logowa-
nia plików logów syslog. Wreszcie,
wydana niedawno publikacja za-
wierająca bibliotekę przydatnych
zestawów reguł opisuje zastoso-
wania SEC na Uniwersytecie Mas-
sachusetts w Bostonie (Rouillard
2004). l