marzec 2004

46

dla początkujących

Analiza logów systemowych

Piotr Machej

W

trakcie używania komputera (obojętnie,
czy do pracy, czy do rozrywki) używamy
wielu różnych programów. Wiele z nich
działa w tle, bez naszego udziału. Nie do

pomyślenia byłoby, gdyby wszystkie te programy wyrzuca-
ły na ekran wyniki swoich działań lub komunikaty błędów.
W takim systemie nie dałoby się pracować. Z tego powodu
większość tych informacji zapisywana jest w dziennikach
systemowych (plik dziennika systemowego nazywamy też
logiem lub dziennikiem zdarzeń).

Kontrolowanie wpisów w logach daje możliwość

wykrycia nieprawidłowości w konfiguracji i funkcjonowa-
niu naszego systemu. Oprócz tego, jest to jedno ze źró-
deł informacji o wszelkich próbach włamań, więc należy
regularnie przeglądać logi systemowe w poszukiwaniu
wszelkich odchyleń od normy. Oczywiście, w przypad-
ku systemów produkcyjnych zainstalowanych w firmach,
zwykle zatrudniony jest w tym celu administrator bezpie-
czeństwa. Nie należy jednak sądzić, że komputery domowe
są bezpieczne, bo „komu by się chciało włamywać do
mojego komputera”. Nasz system może być wykorzystany
przez „czarne kapelusze”, choćby do przygotowania rozpro-
szonego ataku odmowy usługi (DDOS), czy po prostu jako
„przystanek” podczas dokonywania włamania do innego
systemu.

Nie ulega wątpliwości, że analizowanie logów w syste-

mie wielozadaniowym (jakim jest Linux) może być bardzo
czasochłonne. Stworzono szereg programów mających
na celu ułatwienie pracy administratorom – pomagają od
razu zwrócić uwagę na najistotniejsze dla bezpieczeństwa
wpisy. Oprócz tego, takie programy pozwalają na tworzenie
rozbudowanych statystyk, co szczególnie przydaje się przy
analizie logów serwerów WWW lub proxy.

Przykład użycia

Gdy rano sprawdziłem pocztę, znalazłem codzienny raport
z logów. Znów jakiś wirus rozsyłał po sieci stosy listów. Na
szczęście program antywirusowy w połączeniu z odsiewa-
niem spamu odrzucił większość przesyłek. Przynajmniej
użytkownicy nie będą zbytnio narzekać. Logi zapory

ogniowej informowały tylko o kilkudziesięciu skanowa-
niach portów. Uśmiechnąłem się widząc, że ktoś próbo-
wał włamać się na serwer wykorzystując starą lukę w IIS
Microsoftu. Chyba nawet nie potrafił sprawdzić, jaki serwer
WWW jest zainstalowany. No cóż, script-kiddies przydają
się przynajmniej do poprawiania humoru, o ile ma się uak-
tualniony system.

Przed wyjściem do miasta sprawdziłem jeszcze logi

dzielenia łącza. Od aktualizacji oprogramowania i jądra
tydzień temu, w końcu zdawało się działać poprawnie.
Z zadowoleniem wyłączyłem konsolę administratora,
rozegrałem partyjkę w Go (znów przegrałem o 1,5 moku)
i zgasiwszy monitor wyszedłem na spacer. Jeśli coś się
będzie działo złego, to system i tak powiadomi mnie o tym
SMS-em.

Podstawowe pliki logów

Nie da się skutecznie śledzić dzienników systemowych bez
wiedzy na temat ich lokalizacji i zastosowania. W więk-
szości przypadków pliki logów znajdują się w katalogu
/var/log/ i jego podkatalogach. Za zapis do odpowiednich
plików poszczególnych informacji dotyczących działania
systemu odpowiada demon Syslogd. Oprócz tego istnieje
demon Klogd, odpowiedzialny za przechwytywanie komu-
nikatów jądra systemu.

Plikiem konfiguracyjnym demona Syslogd jest plik /etc/

syslogd.conf. Z niego możemy dowiedzieć się, jakie infor-
macje są kierowane do poszczególnych plików. Każda jego
linia ma postać:

urządzenie.priorytet plik_logu

O autorze:

Autor zakończył studia zaoczne na V roku Informatyki na

Politechnice Opolskiej. Z Linuksem (i ogólnie systemami

uniksowymi) ma styczność od wielu lat. Obecnie admi-

nistruje siecią blokową złożoną z dziesięciu komputerów.

Kontakt z autorem: [e-mail].

Rysunek 1.

Oto skutek zerwanego kabla – dwa dni bez sieci

Zobacz w:

47

www.linux.com.pl

analiza logów systemowych

Pole urządzenie określa, skąd pochodzą informacje. Może
przyjmować takie wartości, jak:

• authpriv – informacje dotyczące bezpieczeństwa i auto-

ryzacji;

• cron – demony Cron i At;
• daemon – demony systemowe bez osobnej wartości

urządzenie;

• ftp – demon FTP;
• kern – wiadomości jądra;
• lpr – system drukowania;
• mail – system pocztowy;
• news – system wiadomości news (USENET );
• syslog – wewnętrzne komunikaty demona Syslogd;
• user – wiadomości programów użytkownika;
• uucp – system UUCP;
• local0 do local7 – zarezerwowane do lokalnego

użytku.

W polu priorytet określamy, jakie informacje chcemy
logować. Do dziennika systemowego określonego w polu
plik_logu trafią te informacje, które mają priorytet równy
lub wyższy od podanego w polu priorytet. Pole to może
przyjmować następujące wartości (poczynając od najniższe-
go priorytetu): debug, info, notice, warning, err, crit, alert
oraz emerg. Możemy również zabronić zapisywania infor-
macji z wybranego urządzenia w pliku – wystarczy w polu
priorytet użyć wartości none. Zarówno pole urządzenie,
jak i priorytet, może przyjmować wartość *, oznaczającą
wszystkie dostępne urządzenia i priorytety (odpowiednio).

Przykładowa linia z pliku /etc/syslog.conf może wyglą-

dać tak:

*.info;mail.none;news.none;authpriv.none;cron.none

S

/var/log/messages

Powoduje ona, że do pliku /var/log/messages zostaną
zapisane wszystkie wiadomości o priorytecie info lub wyż-
szym, ze wszystkich urządzeń z wyjątkiem wiadomości
z systemów poczty, news, Crona i informacji dotyczących
bezpieczeństwa.

Jeśli chcemy te same informacje wysyłać na niewy-

korzystywaną konsolę (np. na dziesiątą), możemy wpisać
w pliku /etc/syslog.conf linię podobną do poniższej:

*.info;mail.none;news.none;authpriv.none;cron.none

S

/dev/tty10

Dzięki temu po zrestartowaniu demona Syslogd (np. pole-
ceniem

/etc/rc.d/init.d/syslog restart

) i przełączeniu

się na dziesiątą konsolę (klawiszami [Alt]-[F10 ]), będziemy
mogli na bieżąco czytać informacje dopisywane do pliku
/var/log/messages.

Analizując plik syslog.conf, możemy zorientować się

w przeznaczeniu części plików dziennika systemowego.
W domyślnie zainstalowanym systemie najczęściej wyko-

rzystywane są następujące pliki znajdujące się w katalogu
/var/log/:

• messages – plik ogólnego przeznaczenia; są tu logowa-

ne zarówno komunikaty jądra podczas startu systemu,
jak i informacje wysyłane przez różne programy uru-
chomione w systemie;

• secure – plik zawierający informacje dotyczące bezpie-

czeństwa oraz dane o autoryzacji użytkowników w sys-
temie;

• maillog – tu logowane są wszystkie informacje wysyła-

ne przez system pocztowy;

• cron – komunikaty o uruchamianiu zadań przez

demony Cron, Anacron oraz At;

• spooler – informacje krytyczne z działania systemów

UUCP i news;

• boot.log – komunikaty wyświetlane podczas startu sys-

temu.

Oprócz powyższych plików, w katalogu /var/log/ mogą
znaleźć się inne pliki i podkatalogi tworzone przez zainsta-
lowane oprogramowanie. Przykładowo często znajdziemy
tam podkatalogi cups/ (systemu drukowania), httpd/ (logi
serwera WWW), samba/ (komunikaty z działania Samby)
czy squid/ (informacje o serwerze pośredniczącym).

Nie należy dziwić się, jeśli oprócz pliku messages

w katalogu /var/log/ znajdą się pliki messages.1, messages.2
itd. Może to również dotyczyć innych plików. Jest to wynik
działania demona LogRotate, odpowiedzialnego za rotację
logów. Rotacja ma na celu uniknięcie przepełnienia dysku.
Plik z logiem co pewien czas ma zmienianą nazwę (doda-
wana jest cyfra). W ten sposób przechowywanych jest kilka
archiwalnych kopii pliku, z których najstarsza jest usuwana
przy kolejnej rotacji.

Analiza logów w trybie tekstowym

Jeśli szukamy w logach konkretnej informacji, najszyb-
ciej znajdziemy ją wykorzystując podstawowe narzędzia
dostępne z konsoli. Najprostszym z tych poleceń jest
grep.

Rysunek 2.

Możemy określić, które słowa są dla nas alarmujące

marzec 2004

48

dla początkujących

Przypuśćmy, że chcemy sprawdzić, czy ktoś odwiedza
naszą stronę. Wiemy już, że logi serwera WWW prze-
chowywane są w katalogu /var/log/httpd/. Informacje
o odwiedzinach zawarte są w pliku access_log. Jeśli więc
stworzyliśmy stronę i opublikowaliśmy ją pod adresem http://
nasz.serwer/~uzytkownik/strona/, to możemy poszukać
informacji o niej:

grep uzytkownik/strona /var/log/httpd/access_log*

Jeśli w plikach access_log* znajdują się jakieś linie zawiera-
jące tekst uzytkownik/strona, to zostaną one wyświetlone
na ekranie. Przykładowo może to wyglądać tak:

access_log.1:127.0.0.1 - - [28/Jan/2004:13:17:41 +0100]

S

"GET /~uzytkownik/strona/ HTTP/1.1" 200 1603 "-"

S

"Mozilla/5.0 (X11; U; Linux i686; pl-PL; rv:1.4)

S

Gecko/20030704"
access_log.1:127.0.0.1 - - [28/Jan/2004:13:17:41 +0100]

S

"GET /~uzytkownik/strona/style.css HTTP/1.1" 200 648

S

"http://localhost/~uzytkownik/strona/" "Mozilla/5.0

S

(X11; U; Linux i686; pl-PL; rv:1.4) Gecko/20030704"

Z powyższych linii możemy dowiedzieć się, że dnia 28
stycznia 2004 roku o godzinie 13:17 jeden z użytkowników
naszego komputera (localhost – 127.0.0.1) wszedł na stronę
o adresie http://localhost/~uzytkownik/strona/. Strona ta
została wysłana do niego bez problemu (kod 200) i miała
rozmiar 1603 bajty. Oprócz tego, strona ta korzystała
z arkusza stylów umieszczonego w pliku style.css o rozmia-
rze 648 bajtów. Użytkownik wchodzący na stronę korzystał
z przeglądarki przedstawiającej się jako Mozilla. Informacje
te znajdują się w pliku archiwalnym access_log.1.

Możemy także sprawdzić adres MAC naszej karty sie-

ciowej:

dmesg | grep eth

Polecenie to w moim systemie drukuje następujące infor-
macje:

divert: allocating divert_blk for eth0
eth0: RealTek RTL8139 Fast Ethernet at 0xd17ea000,

S

00:01:29:24:0d:2f, IRQ 10
eth0: Identified 8139 chip type 'RTL-8139B'

Interesujący nas adres MAC to 00:01:29:24:0d:2f. Przy
okazji dowiadujemy się, że jest to karta oparta na chipie
RealTek RTL8139B.

Oprócz użycia grepa, możemy wykorzystać również

inne polecenia. Poniższe polecenie powoduje zliczenie
listów wysłanych 11 i 12 stycznia (serwerem poczty jest
Postfix):

grep sent /var/log/maillog* | grep "Jan 1[12]" | wc -l

W moim przypadku listów takich było niewiele, więc pole-
cenie to zwróciło jednocyfrowy wynik:

2

Bardzo przydatne może okazać się polecenie Awk. Jest to
właściwie cały język wyszukiwania i przetwarzania wzor-
ców. Zobaczmy przykładowo, jak z plików secure wyłuskać
informację o tym, kto i z jakiego komputera logował się do
naszego systemu:

awk '/Accepted/ {print $9 "\t" $7 "\t" $11}'

S

/var/log/secure* | sort | uniq

Przykładowy wynik może wyglądać tak:

gerard password 192.168.100.200
gerard publickey 192.168.100.200
ktosik publickey 215.13.57.4

W zestawieniu tym mamy podane nazwy użytkowników
logujących się do naszego komputera za pomocą SSH,
wykorzystaną metodę autoryzacji (hasło lub klucz publicz-
ny) oraz adres komputera, z którego nawiązano połączenie.
Nie mamy tu informacji na temat ilości połączeń – dzięki
kombinacji poleceń sort i uniq wyeliminowaliśmy wszyst-
kie powtórzenia. Jeśli interesują nas konkretne linie doty-
czące pierwszego z wymienionych połączeń, to możemy
znów skorzystać z grepa:

grep "password.*gerard.*192.168.100.200" /var/log/secure*

Przykładowo, możemy uzyskać w wyniku następujący
wydruk (zacytowano jedynie fragment):

secure:Jan 25 03:43:49 illusion sshd[6498]:

S

Accepted password for gerard from

S

192.168.100.200 port 52790 ssh2

Rysunek 3.

W Webminie możemy nie tylko przeglądać logi, ale

również dodawać nowe

49

www.linux.com.pl

analiza logów systemowych

secure.1:Jan 31 01:48:13 illusion sshd[28930]:

S

Accepted password for gerard from

S

192.168.100.200 port 2203

W powyższym przykładzie illusion jest nazwą komputera,
na którym znajdują się logi.

Samodzielne analizowanie logów stwarza duże pole

do popisu wszystkim programistom. To prawdziwy egza-

min z umiejętności wykorzystania wyrażeń regularnych
oraz z wiedzy na temat działania systemu. Dla początku-
jących jest to świetna możliwość zdobycia nowej wiedzy
i umiejętności. Nie zawsze jednak chcemy lub mamy
czas samodzielnie się wszystkim zajmować. Z pomocą
przychodzą nam inni programiści, którzy stworzyli wiele
programów i filtrów na różne sposoby przetwarzające logi
i wyłuskujące istotne informacje.

Red Hat LogViewer

W Auroksie mamy do dyspozycji bardzo przyjemne narzę-
dzie, które zwalnia nas z konieczności stosowania polece-
nia grep. Red Hat LogViewer, bo o tym programie mowa,
dostępny jest z menu Narzędzia systemowe –> System logs.
Oczywiście pod warunkiem, że zainstalowaliśmy go w sys-
temie. Jeśli nie, to możemy go znaleźć na pierwszej płycie
instalacyjnej.

Program ten jest bardzo prosty w użyciu. Po lewej stro-

nie mamy do wyboru różne pliki dziennika systemowego.
Gdy wybierzemy jeden z nich, jego zawartość pojawi się
w głównym oknie. Wpisy zasługujące na uwagę oznaczo-
ne są czerwonym wykrzyknikiem. W polu Filter for mamy
możliwość wpisania wyrażenia, które chcemy odszukać
w logu. Po wciśnięciu przycisku Filter na ekranie pozostaną
tylko linie zawierające to wyrażenie.

W menu Edit –> Preferences możemy wskazać lokali-

zacje poszczególnych plików logów, ustawić czas odświe-
żania, a także wskazać wyrażenia, które powinny być
oznaczane wykrzyknikiem.

Program ten nie jest szczególnie rozbudowany, lecz

z pewnością spełnia swoją funkcję – pozwala w wygodny
sposób przeglądać logi.

Webmin

Ten popularny program służący do administracji systemem
za pośrednictwem WWW nie mógł się obyć bez przeglądar-
ki logów. W sekcji System –> Logi systemowe mamy dostęp
do ustawień znanych nam już z pliku /etc/syslogd.conf.
Tym razem możemy skonfigurować każdy log za pomocą
interfejsu graficznego, co dla wielu osób jest łatwiejsze
i wygodniejsze.

Niestety, samo przeglądanie logów nie jest tu zbyt roz-

budowane. Jedyne, co możemy zrobić, to wybrać liczbę
linii do wyświetlenia oraz wyświetlić tylko linie zawierające
wprowadzony tekst. Pod tym względem lepszy wydaje się
Red Hat LogViewer.

LogWatch – automatyczne

wykrywanie podejrzanych wpisów

W wyłuskiwaniu nietypowych wpisów w dziennikach sys-
temowych może nam pomóc program LogWatch. Narzędzie
to codziennie przegląda wybrane pliki i przepuszcza je przez
odpowiednie filtry. Informacje sformatowane przez te filtry
wysyłane są pocztą e-mail na adres administratora. Nie
zawsze muszą one wzbudzać nasze podejrzenia – często są
to zestawienia, np. ilości połączeń z serwerem poczty.

Opcje polecenia Logwatch:

•

detail

poziom – ustawia poziom szczegółowości raportu;

można użyć wartości low (niska), med (średnia) i high
(wysoka) lub wartości liczbowych od 0 (niska) do 10
(wysoka);

•

logfile

nazwa_logu – ogranicza analizę do wskazane-

go pliku (lub plików, bo tej opcji można użyć kilkakrot-
nie) dziennika systemowego; LogWatch użyje filtrów
powiązanych ze wszystkimi usługami korzystającymi ze
wskazanego pliku;

•

service

nazwa_usługi – ogranicza analizę do wskazanej

usługi (lub usług – opcja może być użyta wielokrotnie);
LogWatch przeanalizuje wszystkie pliki dziennika sys-
temowego wykorzystywane przez tą usługę; przydatną
wartością nazwa_usługi jest All, pozwalająca wskazać
wszystkie dostępne usługi;

•

print

– powoduje wysłanie wyniku na standardowe

wyjście (np. na ekran);

•

mailto

adres – wysyła wynik na adres e-mail lub do

użytkownika podanego jako adres;

•

archives

– powoduje, że LogWatch oprócz właściwego

pliku logu analizuje również pliki archiwalne (np. messa-
ges.1 i następne w przypadku logu messages), oczywi-
ście z uwzględnieniem wartości opcji range;

•

range

– pozwala określić zakres analizowanych dat;

obecnie dostępne są tylko trzy wartości: Today (dzisiaj),
Yesterday (wczoraj) i All (wszystkie dni);

•

debug

poziom – opcja przydatna podczas rozwiązywa-

nia problemów oraz analizowania działania programu
LogWatch; wartość poziom może wynosić od 0 do 10
(powyżej 10 jest sens ustawiać tylko wartości większe od
100, gdyż wtedy nie jest usuwany katalog roboczy);

•

save

nazwa_pliku – zamiast drukować lub wysyłać

listem e-mail, zapisuje wynik analizy do pliku o nazwie
nazwa_pliku;

•

logdir

katalog – poleca szukać plików z logami w katalo-

gu katalog zamiast w standardowej lokalizacji;

•

hostname

nazwa_hosta – w raportach używa nazwa_

hosta zamiast nazwy zdefiniowanej dla tego systemu;
jeśli w pliku konfiguracyjnym /etc/log.d/logwatch.conf
włączyliśmy opcję

HostLimit

, to użycie opcji

hostname

w linii poleceń spowoduje analizowanie tylko wpisów
dotyczących hosta o nazwie nazwa_hosta; wyjątkiem
są pliki logów nie zawierające informacji o nazwie hosta
(pliki te będą przetwarzane niezależnie od wartości opcji

HostLimit

);

•

usage

– wypisuje informacje o dostępnych opcjach;

•

help

– to samo, co

usage

;

marzec 2004

50

dla początkujących

Instalacja

W przypadku dystrybucji Aurox program LogWatch
dostarczany jest na pierwszej płycie instalacyjnej.
Możemy sprawdzić, czy jest zainstalowany w systemie
poleceniem

rpm -q logwatch

. Powinniśmy uzyskać nazwę

pakietu wraz z numerem wersji. Jeśli zamiast tego otrzy-
mamy komunikat Pakiet logwatch nie jest zainstalowany,
to należy zainstalować go z płyty. W tym celu montujemy
pierwszą płytę instalacyjną w systemie (np.

mount /mnt/

cdrom

), po czym instalujemy nasz pakiet –

rpm -Uvh /mnt/

cdrom/RedHat/RPMS/logwatch*.rpm

.

Jeśli wolimy skorzystać z bardziej aktualnej wersji,

możemy ją pobrać z witryny domowej programu (http://
www.logwatch.org/ ). W chwili pisania artykułu najnow-
sza dostępna wersja stabilna nosiła numer 5.0. Warto
ją zainstalować choćby dlatego, że udostępnia większą
liczbę przydatnych filtrów.

Zaraz po instalacji LogWatch jest w zasadzie gotowy

do użycia. Zwykle nie ma potrzeby ingerencji w pliki
konfiguracyjne. Jeśli jednak chcemy rzeczywiście wie-
dzieć, co się dzieje w naszym systemie, to powinniśmy
to zrobić.

Konfiguracja

Większość plików znajduje się w katalogu /etc/log.d/.
Główny plik konfiguracyjny to logwatch.conf (właściwie jest
to łącze symboliczne do pliku conf/logwatch.conf ). Zawiera
on domyślne ustawienia, które są stosowane w przypadku
pominięcia poszczególnych opcji w linii poleceń. Przy
zmianach posługujemy się naszym ulubionym edytorem
(np. Vim, mcedit czy pico).

Na samym początku możemy ustawić adresata listów

informacyjnych (MailTo). Domyślnie jest to użytkownik
root, ale możemy wskazać dowolnego innego lub nawet
wpisać pełny adres e-mail.

Inną ważną opcją jest Range – określa ona, które wpisy

w dziennikach systemowych będą analizowane. Opcja

ta może przyjąć kilka wartości – All (wszystkie wpisy),
Yesterday (wczorajsze) oraz Today (dzisiejsze). Domyśl-
nie analizowane są wpisy z poprzedniego dnia. Warto
zaznaczyć, że opcja ta jest jeszcze bardzo niedoskonała.
W trakcie pracy z LogWatch można zauważyć, że wyniki
zwracane przez program wywoływany z Crona różnią
się od tych zwracanych podczas wywoływania programu
z linii poleceń. Dzieje się tak, gdyż LogWatch pobiera daty
w formacie zależnym od wykorzystywanego w systemie
języka. Załóżmy, że dziś jest 2 luty, a w naszym systemie
zmienna środowiskowa $LANG ustawiona jest na „pl_PL”
(można to sprawdzić poleceniami

locale

lub

echo $LANG

).

W takim przypadku użycie opcji –range yesterday spowo-
duje wyszukiwanie linii z datą lut 1. Gdy jednak zmienna
$LANG ustawiona jest na „C”, to poszukiwane będą linie
z datą Feb 1. Jak więc widać, obecnie jedyną naprawdę
bezpieczną wartością opcji –range jest All. Dzięki niej
zostaną przeanalizowane wszystkie linie.

Oprócz tego, możemy określić, jak bardzo szczegó-

łowe raporty chcemy otrzymywać. Służy do tego opcja
Detail, która może przyjąć wartości Low (niewiele szcze-
gółów – domyślna), Med (średnia ilość szczegółów) oraz
High (dużo szczegółów). Zamiast tych trzech wartości
możemy użyć liczb od 0 (odpowiada to Low) do 10 (od-
powiednik High).

Dzięki opcji Service możemy wskazać usługi, o których

chcemy uzyskać informacje – wartość tej opcji wskazuje
nazwy filtrów (znajdujących się w katalogu /etc/log.d/
scripts/services/ ), których chcemy użyć. W większości
przypadków najlepiej pozostawić tę opcję w ustawieniu
All, dzięki czemu uruchamiane będą wszystkie filtry.
Jeśli z jakiegoś powodu chcemy jednak któryś wyłą-
czyć, możemy poniżej umieścić dodatkową linię Service
z nazwą wyłączanego filtru poprzedzoną znakiem minusa
(np.

Service = -cron

).

Wiemy już, że w katalogu /etc/log.d/scripts/services/

znajdują się filtry dotyczące konkretnych usług. Oprócz
tego, w katalogu /etc/log.d/scripts/ znajdują się jeszcze dwa
podkatalogi zawierające filtry. Są to logfiles/ oraz shared/,
zawierające odpowiednio filtry dotyczące konkretnych
plików logów oraz filtry wspólne dla kilku różnych usług
lub logów. Same filtry to po prostu skrypty, napisane
zwykle w języku Perl (ale niekoniecznie). Możemy więc
(jeśli znamy ten język w wystarczającym stopniu) samo-
dzielnie przeanalizować poszczególne filtry, a nawet napi-
sać własne.

Wspomniane wyżej filtry mają za zadanie przeszukać

pliki dzienników systemowych i wydobyć z nich pewne
informacje. W katalogu /etc/log.d/conf/logfiles/ znajdują
się pliki konfiguracyjne określające lokalizację dzienni-
ków systemowych oraz archiwów. W katalogu /etc/log.d/
conf/services/ znajdziemy pliki konfiguracyjne dotyczące
poszczególnych usług. Wskazują one między innymi, które
pliki logów lub które fragmenty tych plików dotyczą kon-
kretnej usługi.

Rysunek 4.

Wiele programów wspomagających analizę logów

z powodzeniem działa pod konsolą

51

www.linux.com.pl

analiza logów systemowych

Uruchamianie

Wraz z instalacją pakietu w katalogu /etc/cron-daily/ zosta-
je umieszczony plik o nazwie 00-logwatch. Właściwie
jest to łącze symboliczne prowadzące do pliku /etc/log.d/
scripts/logwatch.pl. Dzięki temu, demon Cron będzie dbał
o codzienne uruchamianie programu LogWatch. Listy e-mail
z wynikami działania filtrów będą wysyłane na konto okre-
ślone w pliku /etc/log.d/logwatch.conf w zmiennej MailTo.

Nie jest to jedyna metoda uruchomienia programu. Jeśli

potrzebujemy w danej chwili wyniku działania konkret-
nego filtru, możemy uruchomić LogWatch z linii poleceń.
Wywołanie polecenia

logwatch

bez parametrów spowoduje

użycie domyślnych opcji ustawionych w pliku konfigura-
cyjnym. Zależnie od tego, co chcemy osiągnąć, możemy
jednak wykorzystać różne parametry. Przykładowo, jeśli
chcemy sprawdzić komunikaty demona init (np. o zmianie
poziomu runlevel), możemy użyć polecenia:

logwatch --detail high --archives --service init

S

--range all --print

Poniżej nagłówka informującego o dacie i warunkach
wykonywania raportu, w sekcji zamkniętej liniami Init
Begin i Init End znajdziemy wynik działania filtru. Może
mieć on postać:

Entered or switched to runlevel 0: 2 Time(s)
Entered or switched to runlevel 6: 34 Time(s)

Jak widać, zestawienie to informuje nas, że dwukrotnie
system przechodził do poziomu runlevel 0, natomiast to
poziomu runlevel 6 przechodził 34 razy. Informacje te uzy-
skamy tylko korzystając z opcji –detail high, gdyż nie są one
na tyle istotne, aby umieszczać je przy niższych poziomach
szczegółowości.

W rozdziale Analiza logów w trybie tekstowym wydo-

bywaliśmy z logu secure informacje o tym, kto logował się
do naszego komputera z pomocą ssh. LogWatch również
pozwala nam uzyskać te informacje. Wystarczy, że użyjemy
polecenia:

logwatch --detail high --service sshd –range=all

S

--archives --print

Może ono zwrócić dosyć obszerny wynik, jednak nas w tej
chwili interesują linie umieszczone w bloku Users logging in
through sshd. We wspomnianym przykładzie linie te mogą
wyglądać na przykład tak:

gerard:
192.168.100.200: 21 times
ktosik:
215.13.57.4: 7 times

Przy okazji filtru sshd chciałbym zwrócić uwagę, że high
niekoniecznie jest najwyższym poziomem szczegółowości

informacji. Autor filtru sshd przewidział możliwość wyświe-
tlenia dodatkowych informacji w przypadku użycia opcji
–detail 20 lub wyższej. W takim przypadku powyższe
informacje mogłyby wyglądać tak:

gerard:
192.168.100.200:
publickey: 20 times
password: 1 time
ktosik:
215.13.57.4:
publickey: 7 times

Daje nam to znacznie bardziej szczegółowy raport niż nasze
krótkie polecenie awk. A to tylko mały wycinek informacji,
jakie udostępnia nam filtr sshd.

Jeśli chcemy zapoznać się z raportami na temat kilku

wybranych usług, możemy tego dokonać jednym polece-
niem, np.:

R

E

K

L

A

M

A

marzec 2004

52

dla początkujących

logwatch --detail high --service arpwatch

S

--service cron --range today --print

Jak widać, opcji –service możemy użyć kilkakrotnie,
wskazując kolejne interesujące nas usługi. Powyższe pole-
cenie wydrukuje nam wyniki działania filtrów arpwatch
i cron umieszczone odpowiednio w sekcjach Arpwatch
Begin/End oraz Cron Begin/End. Program Arpwatch
służy do śledzenia zmian przypisania numerów IP do
poszczególnych kart sieciowych. Informacje zwracane
przez ten filtr mogą dotyczyć pojawienia się nowego
komputera w sieci, jak również wymiany karty sieciowej
w jednym z komputerów.

LogWatch pozwala nam na nie wskazywanie konkret-

nych usług. Zamiast tego, możemy wskazać plik logu,
który chcemy przeanalizować. LogWatch wykorzysta
wtedy filtry wszystkich usług powiązanych z tym pli-
kiem. Przykładowo, możemy sprawdzić wczorajsze infor-
macje dotyczące pliku /var/log/messages i przesłać je do
skrzynki pocztowej użytkownika gerard (jeśli mamy go
w systemie):

logwatch --detail low --logfile messages

S

--range yesterday --mailto gerard

Użytkownik ten otrzyma list zawierający informacje takie,
jak komunikaty błędów zwracane przez jądro (w sekcji
Kernel), informacje o problemach z ładowaniem modu-
łów (ModProbe), komunikaty demona Identd i inne. Warto
zwrócić uwagę, że w sekcjach niektórych filtrów może poja-
wić się linia o treści **Unmatched Entries**. Umieszczone
po niej linie nie pasowały do żadnej z reguł filtru (chociaż
dotyczyły tej konkretnej usługi).

Inne narzędzia

Programów wspomagających przeglądanie i analizę logów
systemowych jest wiele. Dobór odpowiedniego zależy od
naszych potrzeb, umiejętności i przyzwyczajeń. Warto

odwiedzić serwis FreshMeat (http://freshmeat.net/ ), gdzie
między innymi w sekcji Browse –> System –> Logging znaj-
dziemy co najmniej kilkadziesiąt tego typu programów.
Zachęcam do samodzielnych poszukiwań, a w ramce
W Sieci zamieszczam odnośniki do kilku wybranych pro-
jektów.

Zakończenie

Przeglądanie i analizowanie logów systemowych ma sens.
Pozwala nam na wykrycie błędów w konfiguracji systemu,
„doszlifowanie” go i dopasowanie do naszych potrzeb. Ana-
lizując logi rutera możemy dostosowywać podział łącza tak,
aby korzystanie z niego było jak najbardziej komfortowe
dla użytkowników. Logi serwera WWW mogą nam wska-
zać błędy w konstrukcji naszych serwisów. Mogą nas też
powiadomić o próbach włamań (oby nieudanych).

Jeśli chodzi o włamania, trzeba zdawać sobie sprawę

z pewnej rzeczy. Analiza logów w tym konkretnym przy-
padku jest często spóźniona. Będzie to już jedynie czyta-
nie historii o tym, jak ktoś dostał się do naszego systemu
i zrobił z nim, co chciał. Może być też tak, że włamywacz
usunie z logów wpisy świadczące o jego obecności. Uchro-
nić nas przed takimi sytuacjami mogą systemy wykrywania
włamań (IDS – Intrusion Detection System).

W Sieci:

• ADMLogger:

http://aaron.marasco.com/linux.html

• AJMS:

http://www.argray.org/ams/

• Analog:

http://www.analog.cx/

• Firewall Log Daemon:

http://rouxdoo.freeshell.org/dmn/

• FWAnalog:

http://tud.at/programm/fwanalog/

• FWLogWatch:

http://www.kyb.uni-stuttgart.de/boris/software.shtml

• FWReport:

http://sourceforge.net/projects/fwreport/

• GLogWatch:

http://www.uberh4x0r.org/download/gkrellm/

• Log_analysis:

http://linux.umbc.edu/~mabzug1/log_analysis.html

• Log Tool:

http://xjack.org/logtool/

• LogWatch:

http://www.logwatch.org/

• MultiTail:

http://www.vanheusden.com/multitail/

• Swatch:

http://swatch.sourceforge.net/

• Webalizer:

http://www.mrunix.net/webalizer/

• Webmin:

http://www.webmin.com/

Rysunek 5.

Na witrynie programu LogWatch znajdziemy dokładne

wskazówki, jak stworzyć własne filtry