W systemie Linux za gromadzenie informacji o zdarzeniach odpowiedzialny jest mechanizm: rsyslog (dawniej – syslog).

Pliki konfiguracyjne odpowiedzialne za działanie tej usługi (i nie tylko tej):

rsyslog - /etc/rsyslog.conf – plik zawierający konfigurację mechanizmu wraz z definicją logowanych zdarzeń,

logrotate - /etc/logrotate – plik zawierający konfigurację mechanizmu odpowiedzialnego za porządkowanie utworzonych logów – planowanie czasu przechowywania logów czy definicja rozmiarów plików zawierających przechwycone zdarzenia.

By móc prowadzić skuteczną rejestrację wystąpienia danych sytuacji w pierwszej kolejności musimy zdecydować jakie kategorie zdarzeń muszą podlegać logowaniu.

Kategorie zdarzeń (selektor), które mogą podlegać logowaniu to:

auth,authpriv - autoryzacja użytkowników,

kern - jądro systemowe,

security - logi bezpieczeństwa,

user - aplikacje wykorzystywane przez użytkowników,

mail - zdarzenia związane z pocztą,

lpr - komunikaty dotyczące obsługi drukarek i procesu wydruku,

ftp - logi serwera ftp,

cron - informacje dotyczące deamona cron.

Po definicji interesującej nas kategorii należy określić ich poziom:

Przykładowe wpisy:

security.* /var/log/security - logi bezpieczeństwa o każdym priorytecie będą zapisywane w pliku: /var/log/security,

*.warning;mail.none;ftp.none /var/log/warning - logi wszystkich kategorii o priorytetach od emergency do warning (włącznie) będą zapisywane w pliku: /var/log/warning Rejestracji nie podlegają logi kategorii: mail oraz ftp,

auth.=crit /var/log/authcrit - logi dotyczące kategorii auth będą zapisywane w pliku: /var/log/authcrit Rejestracji podlegają tylko zdarzenia o priorytecie critical (brak rejestracji zdarzeń dotyczących poziomów wyższych).

Sprawdzenie statusu usługi rsyslog następuje po wydaniu polecenia: /etc/init.d/rsyslog status Jak widać poniżej usługa działa a jej numer PID to 3637

Dodatkowo sterowanie usługą możemy kontrolować za pomocą parametrów:

1 - stop - zatrzymanie usługi rsyslog,

2 - start - uruchomienie usługi,

3 - restart - zrestartowanie usługi np. celem wprowadzenia nowych ustawień.

Tak więc aby móc zacząć rejestrować interesujące nas zdarzenia musimy określić kategorię oraz podać poziom zdarzeń, które rejestracji mają podlegać.

Rejestrację zdarzeń określamy poprzez definicję roli. Konfiguracja danej roli odbywa się poprzez edycję pliku: /etc/rsyslog.conf bądź jak w naszym przypadku poprzez edycję pliku: /etc/rsyslog.d/50-default.conf (generalnie definicja roli odbywa się w pliku rsyslog.conf lecz jak to bywa zasada ta nie zawsze jest regułą, w Ubuntu 14.04 oraz 16.04 rolę tą przejął plik: 50-default.conf)

Tak więc spróbujmy utworzyć jakąś rolę i sprawdźmy czy rejestrowanie zdarzeń działa.

Poniżej została utworzona rola rejestracji zdarzeń związanych z autoryzacją użytkowników. Poprzez wpis: auth,authpriv.* w pliku: /var/log/użytkownicy.log będą zapisywane wszystkie te zdarzenia (użycie gwiazdki spowoduje rejestrację wszystkich możliwych sytuacji - wszystkie możliwe poziomy), które dotyczą zdefiniowanej roli.

By wprowadzona definicja mogła zacząć obowiązywać należy wykonać restart usługi rsyslog.

Listening plików zawartych w katalogu: /var/log nie uwidacznia istnienia pliku: użytkowicy.log ponieważ jeszcze żadne zdarzenie podlegające rejestracji nie miało miejsca.

Zmieńmy zatem ten stan i wymuśmy sytuację w której zaistniałe zdarzenie zostanie odnotowane przez serwer Syslog.

Zdefiniowana rola dotyczy autoryzacji użytkowników tak więc najprostszą sytuacją wymuszającą zapisanie logów jest użycie konta root - użytkownik luk podwyższa swoje uprawnienia do poziomu root.

Wykonanie zmiany poświadczeń użytkownika wymusiło rejestrację tego faktu. Plik: użytkownicy.log został utworzony.

Sprawdzenie zawartości pliku przekonuje nas, że zasymulowana przez Nas sytuacja została zarejestrowana.

W ten oto prosty sposób możemy utworzyć dowolny schemat logowania zdarzeń, które muszą podlegać rejestracji.

Lokalne rejestrowanie zdarzeń mamy omówione. Przejdźmy zatem do skonfigurowania rejestracji zdarzeń pochodzących od urządzeń sieciowych.

Poniżej dla przypomnienia obowiązująca topologia sieciowa, różnica z wpisem poprzednim polega na zamianie systemu pod kontrolą, którego pracuje serwer Syslog. Z systemu Windows przechodzimy na Linux Ubuntu 16.04

Pierwsza czynność, którą należy wykonać to włączenie obsługi połączeń sieciowych. Włączenie nasłuchiwania na porcie UDP 514 obsługującym połączenia następuje po wykasowaniu znaku komentarza (#) umieszczonego przed definicjami:

• ModLoad imudp
• UDPServerRun 514

Zmianę tą należy dokonać w pliku: /etc/rsyslog.conf w sekcji Modules.

W przypadku systemu Linux mamy możliwość skorzystania z rejestracji zdarzeń wykorzystując do tego protokół TCP. Aby włączyć tą funkcjonalność należy uaktywnić linie:

• ModLoad imtcp
• InputTCPServerRun 514

Na uwadze należy jednak mieć fakt iż możliwość zmiany protokołu bądź portu docelowego usługi Sysylog musi mieć zaimplementowane również urządzenie, które logi będzie generować.

Po wprowadzonej zmianie serwer Syslog restartujemy za pomocą znanego nam już polecenia: /etc/init.d/rsyslog restart

Sprawdzenie statusu portu sprawdzimy za pomocą polecenia: netstat -tul Jak widać na zrzucie poniżej usługa serwera Syslog została włączona.

Bardziej szczegółowe informacje uzyskamy wydają komendę: netstat -ulpn

Mamy pewność, że serwer Syslog oczekuje na nadchodzące połączenia.

Przechodzimy do kolejnego kroku konfiguracji a mianowicie do określenia kategorii i poziomu rejestrowanych zdarzeń. Opcje te należy zdefiniować w pliku: /etc/rsyslog.d/50-default. Aby móc rejestrować zdarzenia pochodzące od urządzeń Cisco należy do pliku dodać wpis: local7.* <ścieżka_plik_log> Czemu akurat taki wpis? Ponieważ routery/przełączniki domyślnie wszystkie komunikaty dotyczące zaistniałych zdarzeń klasyfikują do kategorii local7. Dodanie znaku gwiazdki spowoduje włączenie rejestrowania zdarzeń na poziomie Debug czyli tak naprawdę wszystkie możliwe zdarzenia. Włączenie tak wysokiego poziomu rejestracji tak naprawdę jest bez znaczenia gdyż informacja o typie wysyłanych komunikatów zostanie skonfigurowana na routerze.

Poniżej na zrzucie zaprezentowano włączenie rejestrowanie zdarzeń pochodzących od routera R1. Serwer przeprowadzi zapis zdarzeń do pliku: /var/log/routerR1.log

Serwer Syslog został skonfigurowany prawidłowo, przejdźmy zatem do konfiguracji routera R1 i jego współpracy z mechanizmem Syslog. Konfigurację przeprowadzamy analogicznie jak w poprzednim wpisie.

1 - określamy adres IP serwer Syslog z wykorzystaniem polecenia: logging host <adres_IP_serwera_Syslog>,

2- określamy poziom wysyłanych komunikatów - polecenie: logging trap <poziom>,

3 - za pomocą polecenia: logging source-interface <interfejs> możemy określić interfejs wyjściowy,

4 - włączamy proces wysyłania powiadomień - polecenie: logging on

Router R1 został skonfigurowany, czas zatem przetestować całą przeprowadzoną konfigurację i sprawdzić czy zdarzenia będą poprawnie wysyłane i logowane. W tym celu zasymulujemy zdarzenie, które będzie polegać na włączeniu i wyłączeniu jednego z interfejsów routera. Poniżej na zrzucie przedstawiono proces włączenia i wyłączenia interfejsu f0/1 routera R1. Jak widać odpowiednie informacje towarzyszące temu zdarzeniu zostały wygenerowane.

Te same informacje powinny zostać zapisane w logach serwera Syslog. Plik: routerR1.log powinien zostać utworzony w katalogu: /var/log i jak można zauważyć poniżej tak też się stało - punkt 1.

Sprawdzenie informacji zawartych w pliku przekonuje Nas iż rejestrowanie zdarzeń działa prawidłowo. Użycie polecenia: tail w połączeniu z nazwą pliku oraz z flagą -f pozwala na bieżąco śledzić pojawiające się komunikaty - punkt 2.

Poniżej na rysunku przechwycony ruch sieciowy pomiędzy routerem R1 a serwerem Syslog. Jak można zauważyć użyty protokół to UDP w połączeniu z docelowym portem 514.

Podczas konfiguracji zapisu logów pochodzących od routera R1 użyliśmy domyślnej kategorii: local7 co nie oznacza, że nie możemy skorzystać z innych kategorii. Do czego użycie innej kategorii logowania zdarzeń może się przydać? - zapytasz Czytelniku. A mianowicie użycie różnych kategorii pozwala nam na separację logów pochodzących z różnych urządzeń. Wykorzystanie różnych kategorii podczas konfiguracji urządzeń spowoduje zapis logów do odrębnych plików. Możliwy jest również scenariusz w którym to np. wszystkie routery mają przypisaną określoną stałą kategorię obowiązującą dla tego typu urządzeń zaś przełączniki inną. Tak przeprowadzona konfiguracja spowoduje zapis zdarzeń pochodzących od routerów do jednego pliku zaś przełączników do drugiego.

Lista dostępnych i możliwych do wykorzystania kategorii została zamieszczona w tabeli poniżej.

Wykorzystajmy zatem zdobytą wiedzę i skonfigurujmy router R2 do korzystania z mechanizmu Syslog tylko z tą różnicą, że logi routera R2 będą zapisywane w oddzielnym pliku.

Tak jak poprzednio rozpoczynamy od wprowadzenia stosownych ustawień na serwerze Syslog. Ponownie edytujemy plik: /etc/rsyslog.d/50-default.conf Do bieżącej konfiguracji dodajemy wpis nakazujący logowanie zdarzeń wszystkich poziomów przypisanych do kategorii: local6 do pliku: /var/log/routerR2.log

Oczywiście aby ustawienia mogły zacząć obowiązywać, restartujemy usługę deamona rsyslog.

Serwer Syslog został skonfigurowany.

Ostatnim etapem konfiguracji jest wprowadzenie stosownych ustawień na routerze R2. Konfiguracja routera przebiega analogicznie jak routera R1 z jednym małym wyjątkiem. Aby serwer Syslog, mógł zapisać zdarzenia routera R2 do odrębnego pliku (pominięcie tego kroku spowoduje zapisanie logów z wykorzystaniem domyślnie ustawionej kategorii: local7 czyli do pliku routerR1.log) należy dokonać zmiany kategorii wysyłanych przez router komunikatów. Zmianę kategorii dokonujemy za pomocą polecenia: logging facility <kategoria>

I tak jak poprzednio celem sprawdzenia poprawności wykonanych czynności przeprowadzamy zmianę stanu interfejsu routera R2.

Jak widać poniżej wszystkie zdarzenia zostały poprawnie przesłane i zarejesrtowane przez serwer Syslog.

Opcjonalnie możemy skonfigurować zapis zaistniałych zdarzeń w osobnych plikach czyli zapis zdarzenia w zależności od jego poziomu będzie realizowany w odrębnym pliku. Poniżej zdefiniowano zapis zajść pochodzących od routera R1 o poziomie ERROR (numer poziomu: 3) do pliku: routerR1_err.log oraz o poziomie NOTICE (numer poziomu: 5) do pliku: routerR1_notice.log

Po zrestartowaniu usługi Syslog oraz ponownym wygenerowaniu zdarzenia (zmiana stanu interfejsu) sprawdzamy efekt ich rejestracji na serwerze Sysylog. Jak widać poniżej odpowiednie pliki zostały wygenerowane. Sprawdzenie zawartości plików przekonuje Nas, że w plikach tych zostały zapisane zdarzenia odpowiadające danemu poziomowi.

Uważny Czytelnik po analizie rysunku powyżej na pewno zauważy, że w pliku routerR1_err.log znajdują się logi odpowiadające zdarzeniom tylko z tego poziomu natomiast w pliku routerR1_notice.log oprócz logów przypisanych do poziomu 5 znajduje się jedno, zapisane zdarzenie poziomu 3 - %LINK-3-UPDOWN Dlaczego tak się stało? Odpowiedź jest prosta - Użycie definicji: local7.notice spowoduje zapisanie logów należących do wszystkich poziomów od 0 do 5. Aby rejestrować logi należące tylko do poziomu NOTICE definicję zapisu należy skorygować na wpis: local7.=notice Użyte polecenie spowoduje zarejestrowanie tylko zdarzeń przypisanych do poziomu 5 czyli NOTICE.

Sprawdźmy zatem wprowadzoną zmianę i jeszcze raz wygenerujmy zdarzenie. Jak widać poniżej wprowadzona przez Nas zmiana spowodowała zapis logów w pliku: routerR1_notice.log - zostały zapisane tylko zdarzenia przynależne poziomowi 5.

Na początku wpisu zaznaczyłem, że do odbierania informacji o zdarzeniach przez serwer Syslog zamiast domyślnego protokołu UDP może zostać użyty protokół TCP. Spróbujmy zatem skonfigurować serwer Syslog w ten sposób by mógł on prowadzić komunikację z innymi urządzeniami właśnie przy wykorzystaniu TCP.

W pierwszej kolejności poprzez edycję pliku: /etc/rsyslog.conf wyłączamy komunikację opartą o protokół UDP (punkt 1). Do zablokowania protokołu UDP wykorzystujemy: #

Po wyłączeniu UDP, włączamy TCP. Aby protokół TCP mógł zacząć działać usuwamy znak: # przed liniami:

• Module(load="imtcp"),
• Input(type="imtcp" port="700")

W ćwiczeniu dodatkowo zamieniono domyślny port 514 na port 700.

Po wprowadzeniu zmian oczywiście restartujemy usługę serwera Syslog.

Stan włączenia usługi wraz z otwarciem portu 700 możemy zweryfikować za pomocą komendy: netstat -utlpn Serwer Syslog działa i oczekuje na nadchodzące informacje na porcie TCP 700.

Serwer Syslog został skonfigurowany tak więc czas by skonfigurować router. W ćwiczeniu użyjemy routera R1. Aby router R1 mógł nawiązać poprawne połączenie z serwerem Syslog należy zmodyfikować domyślne ustawienia komunikacji. Definicję tą przeprowadzamy za pomocą już znanego nam polecenia: logging host <adres_serwera_Syslog>, uzupełniając je o dodatkowe informacje tj. użyty protokół oraz wykorzystywany numer portu. Definicję protokołu przeprowadzamy za pomocą flagi: transport natomiast numer portu określamy przy użyciu opcji: port.

Standardowo aby sprawdzić poprawność przeprowadzonej konfiguracji wymuszamy zdarzenie polegające na zmianie stanu interfejsu.

Zdarzenia te jak widać zostały poprawnie zarejestrowane przez serwer Syslog.

I na koniec - fakt przesłania danych przez router R1 w kierunku serwera Syslog można dodatkowo zweryfikować przeglądając informacje uzyskane dzięki sniffingowi. Jak widać poniżej do przesłania logów został wykorzystany protokół TCP oraz port 700.

Tak więc wpisem tym temat logowania zdarzeń przy wykorzystaniu serwera Syslog kończymy, co nie oznacza, że do zagadnienia rejestracji zdarzeń nie powrócimy. Został Nam do omówienie protokół SNMP.