plik

www.hakin9.org

hakin9 Nr 5/2006

Pod lupą

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ą

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

[

[[

:]+

]

SNMP

public

access

udp

{

UDP

}

([

]+):

([

]+):

desc

SNMP

public

access

from

action

pipe

mail

Snort

alert

root

window

300

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

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

[

auth

error

]

error

PAM

Authentication

failed

for

(

from

desc

PAM

authentication

failed

for

action

event

PAM_AUTHENTICATION_FAILED_FOR_

ptype2

RegExp

pattern2

sshd

[

auth

info

]

Accepted

keyboard

interactive

pam

for

(

)

from

port

ssh2

desc2

PAM

authentication

successful

for

action2

none

window

type

SingleWithThreshold

ptype

RegExp

pattern

PAM_AUTHENTICATION_FAILED_FOR_

(

context

USER_

_ALREADY_COUNTED

COUNTING_OFF

continue

TakeNext

desc

Ten

authentication

failures

for

distinct

users

have

been

observed

action

pipe

mail

PAM

alert

root

;

create

COUNTING_OFF

3600

window

600

thresh

type

Single

ptype

RegExp

pattern

PAM_AUTHENTICATION_FAILED_FOR_

(

context

USER_

_ALREADY_COUNTED

COUNTING_OFF

desc

Set

the

"count once"

context

for

user

action

create

USER_

_ALREADY_COUNTED

600

hakin9 Nr 5/2006

www.hakin9.org

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

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

[

[[

:]+

]

[

Priority

([

]+):

[

]+:

context

ATTACK_FROM_

continue

TakeNext

desc

Priority

attack

started

from

action

create

ATTACK_FROM_

;

pipe

mail

Snort

priority

attack

from

(

alert

)

root

type

Single

ptype

RegExp

pattern

snort

[

[[

:]+

]

[

Priority

([

]+):

[

]+:

context

ATTACK_FROM_

desc

Priority

incident

from

action

add

ATTACK_FROM_

;

set

ATTACK_FROM_

300

(

report

ATTACK_FROM_

mail

Snort

priority

attack

from

(

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ą

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

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

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

;

eval

(

require

Sys

Syslog

);

eval

(

exit

(

)

unless

)

type

Single

ptype

RegExp

pattern

SEC_STARTUP

SEC_RESTART

)

context

SEC_INTERNAL_EVENT

desc

Compile

the

logging

routine

and

initialize

the

list

patterns

action

eval

syslog

(

sub

{

Sys

Syslog

syslog

(

err

', $

[

]);

}

);

eval

(

regexp

(

192

168

', '

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

pat

(

regexp

)

{

(

[

]

~ /$

pat

)

{

return

;

}

return

;

}

desc

Forward

the

suspicious

message

line

remote

syslog

server

action

call

syslog

hakin9 Nr 5/2006

www.hakin9.org

Pod lupą

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

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

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()

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

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-

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

każ

dej prenum

era

ty *

za numer

hiw

agaz

ynu hakin9 2005

pł

Simple Event Correlator

hakin9 Nr 5/2006

www.hakin9.org

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