Extended Slackware

Używanie syslog-ng i logcheck

Data dodania: Mon, 18 Apr 2005 01:22:39 +0200

Autor: dozzie

Dlaczego warto używać syslog-ng?

Głównym powodem, dla którego ja się przesiadłem, jest możliwość rozrzucenia wszystkich logów po wielu plikach, na przykład na podstawie nazwy programu, od którego pochodzi dany komunikat. W przypadku standardowego slackware'owego sysloga też jest to wykonalne, ale musiałem pisać osobny skrypt uruchamiany przy starcie systemu, a dodatkowo przez ten skrypt logrotate zwyczajnie głupiał.

Dlaczego warto używać logcheck?

Administrator jest bardzo leniwym stworzeniem i jeśli nie dostanie logów pod nos, to ich nie przejrzy. Wiem z autopsji. Skrypt logcheck sprawdza, co się od ostatniego sprawdzania zmieniło w logach, odfiltrowuje nieinteresujące wpisy i tak spreparowaną wiadomość przesyła administratorowi na maila.

Instalacja i konfiguracja syslog-ng

Najlepiej zdobądź jakąś gotową paczkę dla Slackware (polecam moją, a jakże). Jeśli interesuje cię własnoręczna kompilacja, to zajrzyj do slackbuilda (dokopiesz się do niego w moim katalogu z pakietami). Załóżmy, że skusisz się na mój pakiet. Przed zainstalowaniem pakietu wypadałoby usunąć sysklogd (bieżącego demona syslog). Jeśli nie zrobisz tego, będziesz miał do wyboru albo zmienić nazwę pliku rc.syslog i w to miejsce podstawić rc.syslog.new lub rc.syslog-ng, albo zmodyfikować skrypt rc.M, aby uruchamiał rc.syslog-ng (wszystkie te pliki znajdują się w katlaogu /etc/rc.d/). Chodzi o to, żeby syslog-ng był uruchamiany przy każdym starcie systemu.

Zanim przeniesiesz się całkowicie na innego demona logowania, warto go jeszcze skonfigurować. Cała konfiguracja przychodząca z moim pakietem znajduje się w pliku /etc/syslog-ng/syslog-ng.conf.
Konfiguracja jest podzielona na pięć osobnych klas definicji. Opcje globalne są ustawiane wewnątrz dyrektywy options { ... };. Możesz za ich pomocą ustawić, czy tworzone będą katalogi dla plików logów, kto będzie właścicielem tych katalogów i plików, a także parę opcji przydatnych, gdy korzystasz z logowania zdarzeń na zdalnej maszynie, gdzie serwerem logującym jest syslog-ng. W naszym przypadku nie ma tam nic szczególnie interesującego. Pozostałe cztery klasy to definicje źródeł logów, definicje plików docelowych (nie do końca plików, bo to mogą być zdalne hosty), definicje filtrów i powiązania źródeł i filtrów z celami logów. Zwróć uwagę na średniki po każdej dyrektywie.

Na początek zajmijmy się definicją źródeł logów:

source nasze_zrodlo {
  unix-stream("/dev/log");
  file("/proc/kmsg" log_prefix("kernel: "));
  internal();
};

Definiujemy źródło nazywające się nasze_zrodlo, na które składają się trzy źródła komunikatów: gniazdo uniksowe /dev/log (komunikaty od programów), komunikaty kernela (odczytywane z pliku /proc/kmsg), do których zostanie dołączony ciąg kernel: i na koniec komunikaty wewnętrzne demona syslog-ng. Jeśli teraz powiążesz nasze_zrodlo z jakimś celem logów, to wszystkie wpisy pochodzące z tych źródeł tam trafią. Jeśli powiążesz nasze_zrodlo z paroma celami, wszystkie te logi trafią do każdego z celi.

Obejrzyjmy teraz, jak wygląda definicja celu:

destination nasz_cel { file("/var/log/nasz_cel"); };

Właśnie zdefiniowaliśmy cel nasz_cel. Wszystkie logi ze źródeł, które powiążemy z tym celem, trafią do plików /var/log/nasz_cel. W definicji celu możesz wstawić więcej plików docelowych, zresztą to nie muszą być pliki. Po szczegóły odsyłam do dokumentacji dostarczonej z pakietem.

Zdefiniujmy teraz jakiś filtr. Powiedzmy, że chcemy w logu tylko komunikaty pochodzące od kernela i niech to będą komunikaty firewalla. Załóżmy, że każdy skok do celu LOG w iptables jest opatrzony opcją --log-prefix 'firewall ', jak w regułce iptables -A INPUT -p tcp --dport 23 -j LOG --log-prefix 'firewall '. Żeby złapać takie komunikaty, filtr będzie wyglądał następująco:

filter f_firewall { facility(kern) and match("firewall"); };

Jako że komunikaty pochodzą od kernela, facility jest równe kern. Możesz filtrować także po nazwie programu, w miejsce facility(...) wstawiając program(...). Nazwa programu będzie dopasowana do wyrażenia regularnego, które podasz.
Jak zwykle, po więcej szczegółów odsyłam do dokumentacji.

Teraz zostało tylko powiedzieć, komunikaty z których źródeł zapisywać gdzie. Do tego służy dyrektywa log { ... };:

log { source(nasze_zrodlo); filter(f_firewall); destination(nasz_cel); };

Ta reguła mówi, że wszystko ze źródła nasze_zrodlo, o ile pasuje do filtra f_firewall, zostanie przesłane do celu nasz_cel. Możesz powiązać razem kilka filtrów, wtedy zostanie na nich wykonana koniunkcja logiczna:

log { source(src); filter(filtr1); filter(filtr2); destination(dest); };

Jeśli komunikat ze źródła src pasuje do filtrów filtr1 i filtr2 jednocześnie, to trafi do dest.

Teraz już, z grubsza rzecz biorąc, umiesz skonfigurować demona syslog-ng i dostosować go do swoich potrzeb, możesz zatem zabić starego sysloga i uruchomić syslog-ng. pkill twoim przyjacielem :)

Instalacja i konfiguracja logcheck

Jak przy instalacji syslog-ng, zalecam zdobyć skądś paczkę. Niestety jedyna znana mi paczka dla Slackware jest mojego autorstwa, więc nie masz zbyt wielkiego wyboru. Jeśli zdecydujesz się na własnoręczną instalację, to zajrzyj do mojego slackbuilda, bo logcheck korzysta z dwóch właściwości debian-specific.

Logcheck z założenia jest uruchamiany regularnie z crontaba, a wyniki działania przesyła na wskazanego maila. Mój pakiet przychodzi już ze stosownym skryptem w /etc/cron.daily/. Jeśli instalujesz logchecka własnoręcznie, pamiętaj o dodaniu odpowiedniego wpisu.

Cała konfiguracja znajduje się w katalogu /etc/logcheck. W pliku logcheck.conf są opcje ogólne, jak na przykład do kogo wysyłać wiadomość z podsumowaniem dnia albo jaki wybrać REPORTLEVEL, który wpływa na to, co zostanie odfiltrowane z podsumowania. W pliku logcheck.logfiles znajduje się lista logów, które będą przetwarzane i raportowane, jeden plik na linię.
W katalogu violations.d znajdują się reguły, według których zdarzenia zostaną uznane za naruszenie bezpieczeństwa i wylądują w sekcji Security Events. W katalogu ignore.d.$REPORTLEVEL znajdują się reguły opisujące, które zdarzenia są nieistotne i zostaną pominięte w podsumowaniu.
Wszystkie reguły są extended regexp-ami, jeden na linijkę. To są dokładnie te same regexpy, które są używane przez egrep.

Z uwag końcowych: w katalogu ignore.d.$REPORTLEVEL staraj się umieszczać jak najmniej ogólne regexpy. Lepiej odfiltrować ręcznie niechciane informacje niż informacje istotne odrzucić tak, że nawet nie będziesz wiedzieć, że się pojawiły.

Engine by Dozzie. Awful design by Dozzie.