56
OBRONA
HAKIN9 5/2010
N
a powyższe pytanie można
odpowiedzieć sobie na dwa sposoby:
należy zapomnieć o logach i nie
zawracać sobie nimi głowy, jeśli chodzi o
bezpieczeństwo lub wdrożyć system LIDS, który
większość pracy wykona za nas.
Każdy system operacyjny, praktycznie
każdy program komputerowy, tworzy jakiegoś
rodzaju logi, w których zapisuje informacje
na temat swojego działania. W typowym
systemie produkcyjnym, na każdej maszynie
znaleźć można kilka/kilkanaście plików, których
zawartość stale jest uaktualniana. Pół biedy jeśli
zaglądamy do nich okazjonalnie, w poszukiwaniu
rozwiązań problemów dotyczących działania
oprogramowania. Jeśli jednak analiza logów
ma pomóc nam w poprawianiu bezpieczeństwa
(w szczególności wykrywaniu incydentów), musi
być wykonywana regularnie i często. W dodatku,
informacje dotyczące bezpieczeństwa stanowią
zwykle znikomą część wszystkich informacji
zapisywanych w logach. Perspektywa ręcznego
przeglądania informacji z kilku programów,
przemnożonych przez kilka hostów, nie rysuje się
w jasnych barwach. W praktyce jest to nierealne.
Jak rozwiązać ten problem? Większość
informacji z logów nie powinna interesować
specjalistów od bezpieczeństwa. Pozbądźmy
się więc automatycznie wszystkiego, co z
całą pewnością nie jest nam potrzebne, a
ręcznie analizujmy tylko potencjalnie ważne
informacje.
MARCIN
TEODORCZYK
Z ARTYKUŁU
DOWIESZ SIĘ
co to jest LIDS,
jak zautomatyzować analizę
logów,
• co może zaoferować
oprogramowanie OSSEC.
CO POWINIENEŚ
WIEDZIEĆ
jak używać linii poleceń w
systemach *NIX,
jak skonfigurować serwer
WWW Apache,
jak zbudowany jest format XML.
LIDSy, HIDSy, IDSy, IPSy
LIDS (ang. Log-based Intrustion Detection
Systems) to system przeznaczony do
analizowania logów. Pełni on rolę wstępnego
filtru, dzięki któremu człowiek dostaje o wiele
mniejszą ilość danych do przetworzenia
ręcznie, a jego głównym celem jest wykrywanie
incydentów bezpieczeństwa.
Systemy LIDS zaliczyć można do szerszej
grupy systemów HIDS (ang. Host-level
Intrusion Detection Systems), które to starają
się wykrywać naruszenia bezpieczeństwa
na podstawie informacji dostępnych lokalnie
na monitorowanym hoście. W praktyce, wiele
systemów implementuje zarówno analizę logów
(typową dla systemów LIDS) jak i dodatkowe
moduły pozwalające np. na sprawdzanie
integralności plików na dysku twardym
(typowe dla systemów HIDS). Ponadto, niektóre
z nich pozwalają na aktywne odpowiedzi
w przypadku wystąpienia określonych
warunków. Zachowanie takie, z kolei, typowe
jest dla systemów IPS (ang. Intrusion Prevention
System).
Przykładowe rozwiązania, które można
uznać za LIDS to OSSEC, Samhain, Osiris.
Refleks!
Bardzo użyteczną i bardzo często spotykaną
funkcjonalnością systemów LIDS/HIDS/IPS jest
tzw. alarmowanie. Typowo, wyniki monitoringu
dostępne są w postaci plików tekstowych lub
Stopień trudności
HIDS? LIDS
– logi Twoim
przyjacielem
Myśl o logach systemowych często wzbudza
w administratorach mieszane uczucia. Z jednej strony, są one
niesamowicie pomocne w diagnozowaniu problemów, także
związanych z bezpieczeństwem, a z drugiej strony, ich ręczna
analiza przysporzyć może bólu głowy. Jak sobie w takiej
sytuacji poradzić?
57
LIDS – LOGI TWOIM PRZYJACIELEM
HAKIN9
5/2010
witryn WWW (ang. World Wide Web).
W przypadku zdarzeń wymagających
jak najkrótszego czasu reakcji,
podejście takie nie sprawdza się. Dzięki
alarmowaniu, informacje o określonych
zdarzeniach mogą być przesyłane na
bieżąco administratorowi przez e-mail lub
SMS (ang. Short Message Service).
Często możliwe jest skrócenie czasu
reakcji jeszcze bardziej. Można to zrobić
dzięki automatycznym odpowiedziom
systemu, które uruchamiane są od razu
po wystąpieniu określonego zdarzenia.
Taką automatyczną odpowiedzią
może być praktycznie wszystko, od
zablokowania ruchu sieciowego dla
określonego IP (ang. Internet Protocol),
po uruchomieniu dowolnego programu.
Znanym już zastosowaniem tego rodzaju
taktyki jest przypadek z Defcon 15, kiedy
to Paul Sebastian Zeigler zastosował
system OSSEC do uruchamiania ARP
(ang. Address Resolution Protocol) cache
poisoning przeciwko atakującym jego
host.
Pięta Achillesowa
Piętą achillesową systemów IDS (HIDS
nie są tutaj wyjątkiem) są niekiedy
ogromne ilości generowanych danych
(alarmów). Źle skonfigurowany IDS potrafi
generować kilkaset alarmów dziennie.
Efekt jest taki, że administrator zaczyna je
ignorować.
Rozwiązaniem tego problemu
jest dostosowanie konfiguracji IDS do
monitorowanego systemu. Przykładowo,
czy zależy nam, aby podsystem
sprawdzania integralności systemu
plików raportował zmiany dokonane
w katalogach użytkowników? Albo dajmy
na to, w logach? Chyba niekoniecznie.
Domyślna konfiguracja wielu IDS nie
zawsze to zapewnia.
Proces konfigurowania systemu
IDS bywa żmudny i jest zazwyczaj
kompromisem między dokładnością
raportowania, a czytelnością
(skutecznością) wyników. Zwykle
wymagane są kilkukrotne korekty w
czasie używania systemu. Konieczne
też będą korekty po jego modyfikacji
czy rozbudowie. W wielu przypadkach
instalacja IDS jest jednak opłacalną
inwestycją w bezpieczeństwo.
Mniej istotną wadą systemów
HIDS jest wysoka zależność od
monitorowanego hosta. Typowe systemy
HIDS funkcjonują przecież na hoście,
który monitorują. Oczywistym jest,
że intruz będzie w stanie wpłynąć na
działanie takiego systemu po przejęciu
kontroli nad maszyną i zafałszować
wyniki jego działania. Problem ten
dotyczy wielu elementów systemów HIDS
i jest rozwiązywany różnymi metodami.
Przykładowo, sumy kontrolne używane do
sprawdzania integralności plików mogą
być zapisywane na systemie plików
z prawami tylko do odczytu, lub też na
nośniku fizycznie uniemożliwiającym
zapis (np. płycie CD/DVD). Podobnie
można postępować z binariami samego
systemu HIDS (aby uniemożliwić ich
modyfikację). Łatwiej niż przed wpływem
na działanie systemu monitoringu, można
się ustrzec przed wpływem na wyniki
jego działania. Tutaj wystarczy je np. jak
najszybciej po otrzymaniu wysyłać przez
sieć na inną maszynę, do której dostęp
jest ograniczony.
LIDS i sieć?
Z definicji systemy LIDS mają niewiele
wspólnego z siecią. Czy jednak na
pewno? W praktyce często pojawia się
potrzeba monitorowania wielu hostów.
Instalacja, konfiguracja i przeglądanie
wyników działania dla każdego hosta
z osobna nie jest wygodnym (ani
wydajnym) rozwiązaniem. Nawet przy
kilku maszynach. Nie mówiąc już
o większej liczbie.
Z tego powodu, coraz częściej
spotyka się systemy LIDS zaprojektowane
z myślą o zastosowaniu na wielu
hostach. W takim przypadku, zbierane
dane przesyłane są przez sieć w jedno
miejsce i tam przetwarzane. Dzięki temu
monitorowane hosty obciążane są
w minimalnym stopniu, a administrator
w prosty sposób może uzyskać dostęp
do wszystkich wyników monitoringu.
Podejście takie ma jeszcze jedną,
dużą zaletę. Mianowicie eliminuje część
z wcześniej wymienionych problemów
z systemami HIDS. A wszystko dzięki
architekturze klient/serwer. W takim
Listing 1.
Fragment logu ossec.log klienta
[root@white ossec-hids-2.3]# cat /var/ossec/logs/ossec.log
2010/02/19 20:46:14 ossec-execd: INFO: Started (pid: 2751).
2010/02/19 20:46:14 ossec-agentd(1410): INFO: Reading authentication keys file.
2010/02/19 20:46:14 ossec-agentd: INFO: Started (pid: 2755).
2010/02/19 20:46:14 ossec-agentd: INFO: Server IP Address: 192.168.56.3
2010/02/19 20:46:14 ossec-agentd: INFO: Trying to connect to server (192.168.56.3:1514).
2010/02/19 20:46:15 ossec-agentd(4102): INFO: Connected to the server (192.168.56.3:1514).
2010/02/19 20:46:18 ossec-syscheckd: INFO: Started (pid: 2763).
2010/02/19 20:46:18 ossec-rootcheck: INFO: Started (pid: 2763).
2010/02/19 20:46:18 ossec-syscheckd: INFO: Monitoring directory: '/etc'.
2010/02/19 20:46:18 ossec-syscheckd: INFO: Monitoring directory: '/usr/bin'.
2010/02/19 20:46:18 ossec-syscheckd: INFO: Monitoring directory: '/usr/sbin'.
2010/02/19 20:46:18 ossec-syscheckd: INFO: Monitoring directory: '/bin'.
2010/02/19 20:46:18 ossec-syscheckd: INFO: Monitoring directory: '/sbin'.
2010/02/19 20:46:20 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/auth.log'.
2010/02/19 20:46:20 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/httpd/error_log'.
2010/02/19 20:46:20 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/httpd/access_log'.
2010/02/19 20:46:20 ossec-logcollector: INFO: Started (pid: 2759).
2010/02/19 20:46:50 ossec-syscheckd: INFO: Starting syscheck database (pre-scan).
OBRONA
58
HAKIN9 5/2010
przypadku intruz, który przejął kontrolę
nad klientem, niewiele może zdziałać
jeśli chodzi ukrycie swojej obecności czy
zacieranie śladów – jego atak został już
odnotowany i przesłany do serwera, do
którego dostępu intruz nie ma.
OSSEC
OSSEC jest wolnodostępnym wraz
z kodem źródłowym (licencja GNU GPL)
systemem LIDS/HIDS. Opcjonalnie
dostępne jest komercyjne wsparcie ze
strony firmy Third Brigade.
System przeznaczony jest głównie
do scentralizowanego monitorowania
wielu hostów, ale może być także
uruchamiany w trybie lokalnym
(monitoring tylko lokalnego hosta).
Ważnymi cechami OSSEC są: wysoki
poziom bezpieczeństwa (procesy
uruchamiane w środowisku chroot ze
specjalnie tworzonych kont użytkowników
o minimalnych uprawnieniach),
wieloplatformowość (pełne wsparcie
dla systemów Linux, Solaris, HP-UX oraz
oprogramowanie klienta dla Microsoft
Windows), prostota obsługi (możliwa
instalacja i konfiguracja w trybie
tekstowym, z użyciem interaktywnych
menu), przejrzysta dokumentacja
(dostępna na stronie domowej projektu)
oraz praktycznie nieograniczone
możliwości konfiguracji i rozbudowy
(dzięki zastosowaniu formatu XML (ang.
eXtended Markup Language) do opisu
reguł przetwarzania logów).
Największą zaletą OSSEC jest
bogaty zestaw predefiniowanych
reguł dla logów szeregu
systemów operacyjnych i aplikacji
– i tu niespodzianka, także aplikacji
komercyjnych. Wśród nich znaleźć
można m.in.: *NIX PAM, OpenSSH,
Samba, serwery FTP takie jak ProFTPd,
Microsoft FTP Server czy Solaris ftpd,
serwery poczty m.in. Postfix, Microsoft
Exchange Server, bazy danych takie
jak PostgreSQL, MySQL, serwery
WWW Apache i IIS, zapory sieciowe,
m.in. Iptables, Solaris IPFilter, Windows
Firewall, rutery i przełączniki Cisco,
Snort IDS, Symantec AntiVirus, Nmap,
Arpwatch, BIND (ang. Berkeley Internet
Name Domain) czy Vmware.
Architektura
OSSEC może pracować w dwóch
trybach: lokalnym i klient/serwer.
W trybie lokalnym analiza logów
odbywa się na maszynie, która jest
monitorowana. W trybie klient/serwer,
na monitorowanych maszynach działa
jedynie proces przesyłający dane do
analizy serwerowi (Rysunek 1). W dalszej
części niniejszego artykułu skupię się na
drugim z wymienionych trybie pracy, tj.
klient/serwer.
Na system OSSEC składa się
kilka daemonów, z których każdy
wykonuje specyficzne zadanie.
Analysisd odpowiada za analizę
danych (uruchomiony jest na serwerze).
Remoted, działa tylko na serwerze
i odbiera dane od klientów. Agentd
odpowiada za wysyłanie danych
serwerowi do analizy (uruchomiony
jest na kliencie). Monitord porządkuje
dane znajdujące znajdujące się na
serwerze, kompresuje je i podpisuje
cyfrowo. Logcollector jest jedynym
procesem działającym z prawami root i
nie ograniczonym przez chroot. Zajmuje
się on wydobywaniem informacji z
logów (stąd konieczność uprawnień
root). Oczywiście logcollector działa
na kliencie. Dwa ostatnie procesy
są opcjonalne: maild i execd. Maild
Rysunek 2.
Instalacja OSSEC na serwerze
Rysunek 1.
Architektura systemu OSSEC w wersji klient/serwer
OBRONA
60
HAKIN9 5/2010
LIDS – LOGI TWOIM PRZYJACIELEM
61
HAKIN9
5/2010
wysyła powiadomienia e-mail. Execd
odpowiada za aktywną odpowiedź na
wykryte zdarzenia.
Przepływ informacji w systemie
OSSEC można zatem streścić
następująco. Działający na kliencie
logcollector kolekcjonuje logi, następnie
agentd wysyła je do serwera. Ten z kolei
odbiera dane (remoted), porządkuje
(monitord) i analizuje, generując
alarmy (analysisd). W razie potrzeby,
są one przesyłane na e-mail (maild).
Mogą także automatycznie zostać
uruchomione dowolne procesy (execd),
jako automatyczna odpowiedź.
Zalety takiej budowy są
niezaprzeczalne. Po pierwsze,
kosztowny obliczeniowo proces
przetwarzania danych przeniesiony jest
na serwer. Na klientach działają jedynie
dwa procesy, zużywające znikomą ilość
zasobów. Po drugie, kompromitacja
klienta będzie natychmiast odnotowana
przez serwer. Po trzecie, dane zebrane
na temat ataku przechowywane są
na serwerze, ergo są poza zasięgiem
atakującego host.
Instalacja i konfiguracja
Instalacja przeprowadzana jest
w sposób interaktywny i w trybie
tekstowym. Dzięki temu w prosty sposób
można ją wykonać także zdalnie, np.
z użyciem SSH (ang. Secure SHell). Na
początek proszeni jesteśmy o wybranie
języka (dostępny jest język polski).
Następnie podać należy typ instalacji
(lokalna czy klient/serwer), i katalog
instalacji. Potem jesteśmy pytani, czy
chcemy korzystać z opcjonalnych
narzędzi sprawdzania integralności
plików oraz wykrywania rootkitów, czy
chcemy włączyć aktywną odpowiedź
oraz powiadomienia e-mail itp (Rysunek
2). W przypadku włączenia aktywnej
odpowiedzi, ważne jest podanie białej
listy adresów IP. Połączenia SSH
nawiązywane z tych adresów nigdy
nie będą blokowane. Po udzieleniu
odpowiedzi na wszystkie pytania,
instalator stara się wykryć logi, które
OSSEC jest w stanie monitorować
i wyświetla ich listę do zaakceptowania.
Następnie oprogramowanie jest
kompilowane i kopiowane w wyznaczone
miejsce w systemie. Aby system działał,
konieczne jest jeszcze umożliwienie
komunikacji sieciowej między serwerem,
a klientami. Służy do niej port 1514
UDP (ang. User Datagram Protocol).
Oczywiście, aby instalacja przebiegła
pomyślnie, konieczne jest posiadanie
zainstalowanego kompilatora GCC (ang.
GNU Compiller Collection) i narzędzi
make, automake.
Instalatory OSSEC dla systemów
Unix/Linux (ten sam instalator dla serwera
i klienta) oraz Windows (tylko klient) można
pobrać ze strony http://www.ossec.net/
main/downloads/. Zanim przystąpimy do
instalacji, mocno zalecane jest pobranie
i sprawdzenie sumy kontrolnej. Aby
przystąpić do instalacji w systemie Linux,
należy rozpakować pobrane archiwum
TAR.GZ (ang. Tape ARchiver GnuZip) i
uruchomić skrypt ./install.sh. W systemie
Windows należy uruchomić pobrany plik
EXE (ang. EXEcutable).
Plik konfiguracyjny OSSEC dostępny
jest w katalogu /var/ossec/etc/ossec.conf.
Jego edycja konieczna jest w przypadku
doinstalowania lub odinstalowania
oprogramowania produkującego logi
na monitorowanym hoście (jako, że logi
aktualnie istniejące na hoście wykrywane
są podczas instalacji). W niniejszym
artykule bazować będę na domyślnej
konfiguracji generowanej po domyślnej
instalacji.
Niezbędnym etapem konfiguracji jest
natomiast zarejestrowanie na serwerze
wszystkich klientów. Odbywa się to
poprzez podanie wygenerowanego przez
serwer dla każdego klienta klucza.
Przykład użycia
Dla przykładu, przeprowadźmy
instalację systemu na dwóch hostach.
Pierwszy z nich, posiadający adres IP
192.168.56.3 (hostname blue) będzie
pełnił rolę serwera. Drugi z nich,
posiadający adres IP 192.168.56.4
(hostname white) będzie pełnił rolę
klienta. Na obu hostach zainstalowany
jest system Arch Linux oraz serwery
WWW Apache i OpenSSH. Instalacja
OSSEC na obu hostach została
wykonana z domyślnymi wartościami
wszystkich opcji oprócz powiadomienia
e-mail, które wyłączono.
Listing 2.
Fragment pliku apache_rules.xml
<
group name=
"apache,"
>
<
rule id=
"30100"
level=
"0"
>
<
decoded_as
>
apache-errorlog
<
/decoded_as
>
<
description
>
Apache messages grouped.
<
/description
>
<
/rule
>
<
rule id=
"30101"
level=
"0"
>
<
if_sid
>
30100
<
/if_sid
>
<
match
>
^[error]
<
/match
>
<
description
>
Apache error messages grouped.
<
/description
>
<
/rule
>
<
rule id=
"30102"
level=
"0"
>
<
if_sid
>
30100
<
/if_sid
>
<
match
>
^[warn]
<
/match
>
<
description
>
Apache warn messages grouped.
<
/description
>
<
/rule
>
<
rule id=
"30103"
level=
"0"
>
<
if_sid
>
30100
<
/if_sid
>
<
match
>
^[notice]
<
/match
>
<
description
>
Apache notice messages grouped.
<
/description
>
<
/rule
>
<
rule id=
"30104"
level=
"12"
>
<
if_sid
>
30103
<
/if_sid
>
<
match
>
exit signal Segmentation Fault
<
/match
>
<
description
>
Apache segmentation fault.
<
/description
>
<
info
>
http://www.securityfocus.com/infocus/1633
<
/info
>
<
group
>
service_availability,
<
/group
>
<
/rule
>
OBRONA
60
HAKIN9 5/2010
LIDS – LOGI TWOIM PRZYJACIELEM
61
HAKIN9
5/2010
Po pomyślnym zakończeniu
instalacji, na serwerze należy
zarejestrować wszystkie hosty, które
mają być monitorowane. Można to zrobić
uruchamiając:
[root@blue ossec-wui]# /var/ossec/
bin/manage_agents
Aby dodać naszego klienta (192.168.56.4),
należy wygenerować dla niego klucz
potrzebny do uwierzytelniania (Rysunek
3). Analogicznie po stronie klienta
uruchomić należy:
[root@white ossec-wui]# /var/ossec/
bin/manage_agents
A następnie zaimportować
wygenerowany wcześniej klucz.
Najprościej zrobić to poprzez zwykłe
przeklejenie z jednego terminala na drugi
– korzystamy przecież z połączenia SSH.
Czas uruchomić nasz LIDS. Aby
to zrobić, na obu hostach wydajemy
polecenie:
[root@blue ossec-wui]# /var/ossec/
bin/ossec-control
start
Warto upewnić się, czy wszystko działa
tak, jak trzeba, zaglądając, a jakże, do
logów (najlepiej także na obu hostach):
[root@blue ossec-wui]# cat /var/
ossec/logs/
ossec.log
Fragment logu klienta przedstawia
Listing 1.
Warto też dodać uruchamianie
systemu OSSEC do skryptów startowych
naszej dystrybucji. Dla Arch Linux można
to zrobić na przykład tak:
[root@blue ossec-wui]# Echo ''/var/
ossec/bin/ossec-
control start''
>> /etc/rc.local
Ludzki interfejs
Przeglądanie wyników działania OSSEC
po domyślnej instalacji jest uciążliwe.
Dostępne są one w postaci plików
tekstowych. Standardowo, alarmy
zapisywane są w pliku /var/ossec/
logs/alerts/alerts.log. Do przeglądania
wyników można użyć także narzędzi
z pakietu OSSEC, jednak znacznym
ułatwieniem w codziennej pracy jest
możliwość wykorzystania interfejsu WWW
OSSEC-WUI. Interfejs ten do działania
wymaga serwer WWW z obsługą PHP
(ang. PHP: Hypertext Preprocessor).
Instalator pobrać można ze strony http:
//www.ossec.net/main/downloads/.
Wypróbujmy go zatem na naszym
serwerze.
Po pobraniu i rozpakowaniu paczki,
wystarczy umieścić pliki interfejsu
w katalogu, z którego nasz serwer WWW
udostępnia dokumenty, np:
[root@blue ~]# mv ossec-wui-0.3 /srv/
http/ossec-wui
A następnie uruchomić skrypt:
[root@blue ~]# /srv/http/ossec-wui/
.setup.sh
Zapytani zostaniemy o nazwę
użytkownika. Chodzi tutaj o nazwę
użytkownika, w ramach której działa
serwer WWW. W przypadku Arch Linux
jest to http. Następnie należy ustawić
odpowiednie prawa dla katalogu tmp:
[root@blue ossec-wui]# chmod 770 tmp/
[root@blue ossec-wui]# chgrp http tmp/
Na koniec trzeba jeszcze umożliwić
dostęp serwera WWW do plików OSSEC.
Aby to zrobić, należy dodać użytkownika
http do grupy ossec, na przykład edytując
plik /etc/groups.
Od tej pory, nasz interfejs powinien
być dostępny pod adresem http:
//192.168.56.3/ossec-wui (Rysunku 4).
UWAGA! W systemie Arch Linux
domyślna instalacja PHP wykonywana
jest z włączoną opcją open_basedir,
ustawioną zbyt restrykcyjnie, aby OSSEC-
WUI mógł działać. Aby interfejs OSSEC
działał poprawnie, konieczne jest dodanie
katalogu instalacyjnego OSSEC w pliku
/etc/php.ini w następujący sposób:
open_basedir = /srv/http/:/home/:
/tmp/:/var/ossec/
Funkcjonalność
Strona główna interfejsu pokazuje
ostatnio zarejestrowane alarmy oraz
zmiany w systemach plików. Oprócz
tego, przez interfejs dostępne są pełne
wyniki testów integralności oraz statystyki
wystąpień poszczególnych alarmów.
Możliwe jest także wyszukiwanie
alarmów na podstawie szeregu
właściwości.
Widok strony głównej pozwala na
szybkie wychwycenie interesujących
Rysunek 3.
Proces dodawania klienta na serwerze
OBRONA
62
HAKIN9 5/2010
nas informacji. Przykładowo zmiana
pliku /etc/passwd, na którymś
z monitorowanych hostów zostanie
natychmiast odnotowana i wyświetlona,
wraz z czasem jej dokonania. Podobnie
nieudane próby logowania np. przez SSH,
czy nieudane wywołania polecenia su.
Bardzo przydatną możliwością jest
wyświetlanie alarmów tylko o określonych
właściwościach. Można tutaj podać np.
nazwę hosta, czy stopień alarmu. Dzięki
temu w łatwy sposób jesteśmy w stanie
odsiać mało ważne alarmy, których może
być wiele, od alarmów o krytycznym
znaczeniu, które z natury zdarzają się
rzadziej. Przykładowe wyniki wyszukiwania
wszystkich alarmów o minimalnym
stopniu 4 przedstawia Rysunek 4.Widać
na nim nieudaną próbę logowania SSH
na konto użytkownika guess z hosta
192.168.56.1.
Przydatne informacje znaleźć można
także w statystykach. Na Rysunku 5 widać
np., że wystąpiło ponad 200 zdarzeń na
godzinę. Dla dwóch hostów, tak wysoka
liczba powinna nas zaalarmować. W tym
przypadku, po sprawdzeniu alarmów,
okazało się, że ogromna większość
dotyczyła ostrzeżeń PHP związanych
z ustawieniami czasu i strefy czasowej.
Po zmodyfikowaniu konfiguracji hostów,
liczba zdarzeń drastycznie spadła (jedno/
dwa na godzinę).
Rzut oka pod maskę
O sile systemu OSSEC stanowią reguły
przetwarzania. Pliki je zawierające
znaleźć można w katalogu /var/ossec/
rules. Fragment pliku web_rules.xml
przedstawia Listing 2. Widać na nim,
w jaki sposób są one definiowane.
Po pierwsze, reguły są numerowane
i grupowane. Pozwala to na korzystanie
z czegoś na kształt dziedziczenia, co
znacznie upraszcza ich tworzenie. Po
drugie przy dopasowaniu do danych
pobieranych z logów wykorzystywane
są wyrażenia regularne. Przykładem jest
^[error]
widoczne na wspomnianym
listingu. Takie wyrażenie regularne wskaże
wszystkie linie rozpoczynające się od
tekstu [error], czyli, zgodnie ze składnią
pliku logu Apache, błędy przez niego
raportowane.
Do każdej reguły, oprócz zasad
jej wystąpienia dodane są stopień
(określający jej ważność) oraz krótki opis
słowny, wyświetlane w logu OSSEC oraz
interfejsie graficznym WWW.
Jak widać, zasady przetwarzania
logów muszą być specyfikowane
dla każdej aplikacji, zgodnie
z konwencjami, jakie są w niej
stosowane. Oczywistym jest, że praca
taka jest żmudna i wymaga precyzji.
Z drugiej strony, reguły takie wystarczy
zdefiniować raz (pod warunkiem, że
aplikacja nie zmienia sposobu w jaki
zapisuje informacje w logach) i można
Rysunek 5.
Graficzny interfejs użytkownika OSSEC – statystyki
Rysunek 4.
Graficzny interfejs użytkownika OSSEC – wyniki wyszukiwania
OBRONA
64
HAKIN9 5/2010
ich używać do woli. W systemie
OSSEC mamy je gotowe dla kilkunastu
aplikacji.
OSSEC i syslog
OSSEC może zostać skonfigurowany
tak, aby wysyłał alarmy do serwera
syslog. Dzięki temu, dane z kilku
systemów OSSEC (lub też kilku innych
systemów HIDS/NIDS) mogą być
gromadzone w jednym miejscu. Mało
tego, wysyłane alarmy mogą być
filtrowane na podstawie np. stopnia.
Standardowo, konfiguracja tworzona
jest w formacie XML. Przykładowo, aby
wszystkie alarmy o stopniu 10 były
wysyłane do serwera syslog o nr IP
192.168.56.8 należy dodać do pliku
konfiguracyjnego:
<syslog_output>
<level>10</level>
<server>192.168.56.8</server>
</syslog_output>
Następnie włączyć funkcjonalność
w OSSEC:
[root@blue ossec-wui]# /var/ossec/
bin/ossec-control
enable client-
syslog
I zrestartować system:
[root@blue ossec-wui]# /var/ossec/
bin/ossec-control
restart
Tym razem oprócz wymienionych
wcześniej daemonów uruchomiony
powinien zostać csyslogd. Dla pewności,
można jeszcze sprawdzić logi na
serwerze:
[root@blue ossec-wui]# tail -n
1000 /var/ossec/logs/ossec.log |
grep csyslog
2008/07/25 12:55:16 ossec-csyslogd:
INFO: Started
(pid: 19412).
2008/07/25 12:55:16 ossec-csyslogd:
INFO: Forwarding
alerts via
syslog to:
‘192.168.56.8:
514′.
Podsumowanie
Ręczna analiza logów pod kątem
wykrywania incydentów bezpieczeństwa
to już historia. Dopracowane systemy
LIDS, takie jak OSSEC, nie tylko zdejmują
ten ciężar z barków administratorów,
ale także pozwalają na znaczne
skrócenie czasu reakcji na naruszenia
bezpieczeństwa.
Oczywiście systemy HIDS nie
są idealnym rozwiązaniem. Nie
ma idealnych rozwiązań. Czy czas
poświęcony na konfigurację jest
dobrą inwestycją? Czy systemy oparte
o parsowanie danych tekstowych mają
rację bytu w ciągle rozbudowywanych
systemach komputerowych? Czy
współczesne logi, rosnące z prędkością
megabajtów na sekundę są dobrym
narzędziem do wykrywania incydentów
bezpieczeństwa? Zastanowienie się nad
tym pozostawię Czytelnikowi.
Systemy IDS
Systemy IDS (ang. Intrusion Prevention Systems) służą do wykrywania incydentów
bezpieczeństwa. Wyróżnia się systemy IDS analizujące ruch sieciowy (NIDS) oraz systemy IDS
analizujące dane lokalnie (HIDS) w tym logi (LIDS). IDSy mogą działać pasywnie, informując
administratorów lub aktywnie odpowiadać na wykryte incydenty (IPS).
Pod względem algorytmów spotykane są dwa podejścia. Pierwsze to analiza statystyczna
i wychwytywanie anomalii. Drugie to dopasowanie do znanych sygnatur. Omawiany w artykule
system OSSEC stosuje drugą metodę, analizując logi pod kątem występowania określonych
wpisów.
Akronimy
• Address Resolution Protocol – ARP,
• Berkeley Internet Name Domain – BIND,
• EXEcutable – EXE,
• File Transfer Protocol – FTP,
• GNU Compiller Collection – GCC,
• GNU's Not UNIX – GNU,
• General Public License – GPL,
• GNU Zip – GZIP,
• Host-based Intrusion Detection System – HIDS,
• Internet Information Services – IIS,
• Internet Protocol – IP,
• Intrusion Prevention System – IPS,
• Log-based Intrusion Detection System – LIDS,
• Network-based Intrusion Detection System – NIDS,
• PHP: Hypertext Preprocessor – PHP,
• Pluggable Authentication Modules – PAM,
• Short Message Service – SMS,
• Secure SHell – SSH,
• Tape ARchiver – TAR,
• User Datagram Protocol – UDP,
• World Wide Web – WWW,
• eXtensible Markup Language – XML.
W Sieci
• http://www.ossec.net – OSSEC,
• http://la-samhna.de/samhain/ – Samhain.
Marcin Teodorczyk
Autor jest absolwentem kierunku Informatyka jednej
z największych polskich uczelni technicznych.
Obecnie pracuje jako asystent informatyczny w dziale
bezpieczeństwa jednego z wiodących w Polsce
dostarczycieli usług obliczeniowych i sieciowych.
Kontakt z autorem: marcin@teodorczyk.info.