Aby móc przewidzieć nadciągającą „katastrofę” musimy oczywiście mieć narzędzia i metody, które zawczasu pozwolą nam na stwierdzenie, że dzieje się coś złego. Rozwiązaniem, które pozwoli nam na zareagowanie w przypadku wystąpienia pierwszych symptomów związanych z nieprawidłowo działającą siecią jest raportowanie i logowanie zaistniałych zdarzeń.

Konfiguracja logowania zdarzeń dla kilku urządzeń nie jest dużym wyzwaniem i jest stosunkowo prosta oraz nie zajmująca wiele czasu. Sytuacja komplikuje się wraz ze wzrostem liczby zarządzanych urządzeń. W obu przypadkach bardzo znaczącym ułatwieniem dla administratora będzie gdy logi zaistniałych zdarzeń będą zapisane w jednym centralnym miejscu.

Aby móc zacząć zapisywać logi przy wykorzystaniu specjalnie do tego celu skonfigurowanej maszyny możemy posłużyć się jednym z dwóch rozwiązań:

• zastosować serwer Syslog,
• wykorzystać protokół SNMP.

Pierwsze z rozwiązań to tzw. usługa obsługi logów systemowych, potocznie nazywana Sysylog. Usługa do działania wykorzystuje protokół UDP wraz z portem 514. Pełna specyfikacja usługi została opisana w RFC5424

Zaś protokół SNMP (ang. Simple Network Management Protocol) to rodzina protokołów sieciowych odpowiedzialnych za zarządzanie i monitorowanie stanu urządzeń sieciowych (routery, przełączniki, komputery, macierze dyskowe czy sprzętowy firewall). Protokół ten działa w warstwie aplikacji i domyślnie, tak jak jego poprzednik do działania wykorzystuje protokół UDP w połączeniu z portami 161 oraz 162. Szersze informacje na temat działania protokołu znajdziesz w RFC1157 (wersja SNMPv1), RFC1901 (wersja SNMPv2) oraz RFC3414 (wersja SNMPv3).

Temat obsługi protokołu SNMP jest bardzo szeroki tak więc samym tym protokołem i jego zastosowaniem zajmiemy się w osobnym wpisie, zaś w tym skupimy się na wykorzystaniu serwera Syslog.

Przepływ informacji pomiędzy serwerami zbierającymi informacje o stanie urządzeń a zarządzanymi urządzeniami może odbywać się dwoma ścieżkami:

Metoda out-of band (OOB) - do przesyłania informacji o stanie urządzeń wykorzystywana jest dedykowana sieć. Sieć ta jest niezależna od sieci produkcyjnej, co oznacza, że gdy sieć główna przestaje działać nadal możliwe jest zarządzanie i monitorowanie urządzeń.

Metoda in-band do monitorowania wykorzystuje sieć produkcyjną czyli sieć w której domyślnie prowadzona jest cała komunikacja. Dobrą praktyką wykorzystywaną przy wyborze tego rozwiązania jest odseparowanie ruchu sieciowego związanego z monitorowanie bądź zarządzaniem od reszty prowadzonej komunikacji. Separację ruch sieciowego możemy przeprowadzić w warstwie 2 przy wykorzystaniu sieci prywatnych VLAN.

Poniżej na rysunku schematycznie przedstawiono obie metody.

Od razu nasuwa się pytanie – Który model wybrać? Oczywiście lepszym rozwiązaniem będzie wykorzystanie metody out-of band gdyż w przypadku problemów z siecią główną mamy do dyspozycji dodatkowy kanał komunikacyjny, który możemy wykorzystać do rozwiązania zaistniałych problemów. Metoda ta pomimo dużej zalety w postaci zastosowania redundancji połączeń niestety ma zasadniczą wadę – koszt wdrożenia (koszty związane z infrastrukturą oraz wykorzystaniem zasobów sprzętowych urządzeń). Dlatego też znacznie częściej wybierana jest metoda in-band.

Na co zwrócić uwagę przy wykorzystaniu rozwiązań opartych o rejestrowanie zdarzeń:

• Jakie protokoły monitorowania wspiera i obsługuje dane urządzenie?
• Jaki typ logów powinien być rejestrowany?
• Jak oddzielić informacje ważne (krytyczne) od tych rutynowych (informacyjne, diagnostyczne)?
• Jak radzić sobie z dużą ilością logów?
• Jak śledzić zmiany, gdy wystąpi awaria sieci bądź atak?
• Jak zapewnić integralność otrzymywanych danych m.in. znaczniki czasu?
• Jak nie dopuścić do manipulacji przy logach?
• Które z logowanych danych mogą być potrzebne w śledztwie?

Jak widać powyżej jest szereg pytań na które musimy sobie odpowiedzieć by móc skutecznie prowadzić proces gromadzenia informacji. Mam nadzieję, że po lekturze tego wpisu na tak postawione pytania znajdziesz Czytelniku odpowiedzi.

Urządzenia sieciowe powinny być skonfigurowany do wysyłania komunikatów na jeden lub więcej sposobów. Urządzenia firmy Cisco (routery, przełączniki) obsługują komunikaty dziennika:

Console - router domyślnie wszystkie komunikaty dotyczące pracy urządzenia wysyła do swojego portu konsoli. Dostęp do tych komunikatów mają użytkownicy, którzy mają zestawione połączenie z portem konsoli – tzw. rejestrowanie konsolowe (ang. console logging).

Rejestrowanie terminalowe (ang. terminal logging) - bardzo podobne do rejestrowania przy użyciu portu konsoli z tą różnicą iż komunikaty wysyłane są do linii VTY. Wymaga dodatkowego uaktywnienia.

Rejestrowanie z wykorzystaniem bufora (ang. buffered logging) - komunikaty o stanie dziennika są zapisywane i przechowywane w pamięci RAM urządzenia. Do tego celu rezerwowana jest stała część pamięci RAM. Rozmiar bufora ogranicza przechowywanie dużej ilości logów tak więc w przypadku przepełnienia następuje kasowanie najstarszych wiadomości.

SNMP Server (ang. SNMP trap logging) – komunikaty o stanie urządzenia są wysyłane i zapisywane na zewnętrznym serwerze. Obsługa logów jest realizowana przy wykorzystaniu protokołu SNMP.

Syslog Server – tak jak w metodzie powyżej za odbiór i zapis logów odpowiada zewnętrzny serwer. Rejestrowanie zdarzeń w przypadku tej metody domyślnie jest wyłączone. Przesyłanie odbywa się z pominięciem faktu potwierdzenie przesyłanych raportów.

Przy konfiguracji danej metody zapisu zdarzeń należy mieć na uwadze, że miejsce logowania wpływa na ogólne obciążenie systemu. Poniżej lista użytych metod uszeregowana od stopnia wpływu na obciążenie systemu (góra=duże obciążenie, dół=małe obciążenie).

• logowanie do konsoli,
• logowanie do VTY,
• logowanie do zewnętrznego serwera,
• logowanie do bufora.

W przypadku wykorzystania serwera Syslog, serwerem będziemy określać hosta, którego zadaniem jest odbiór i przetwarzanie logów otrzymywanych od klientów. Natomiast klientem będzie host/urządzenie sieciowe, które logi generuje i przekazuje je w kierunku serwera Syslog.

W przypadku urządzeń Cisco komunikaty generowane przez urządzenie możemy podzielić w zależności od poziomu ich ważności. Poziom komunikatów został ustalony od 0 do 7 a im niższy poziom komunikatu, tym z bardziej krytycznym zdarzeniem będziemy mieli do czynienia.

Poniżej w tabeli zostały zebrane możliwe poziomy ważności zdarzeń wraz z przykładowymi zdarzeniami generującymi dany typ komunikatu.

Poniżej zaprezentowano przykładowy komunikat dziennika routera Cisco.

Jak można zauważyć powyżej komunikat dziennika składa się z dwóch bądź trzech części. Obowiązkowymi elementami komunikatu jest nazwa poziomu wraz z jego identyfikatorem oraz tekst informacyjny. Opcjonalnym elementem jest znacznik czasowy. Włączenie znacznika odbywa się za pomocą polecenia: service timestamp wydanego w trybie konfiguracji globalnej.

Kolejną częścią komunikatu jest jego kod oraz poziom ważności. W przykładzie powyżej kodem jest SYS oraz LINK, natomiast poziom ważności został ustalony w przypadku pierwszego komunikatu na poziom 5 czyli Notifications, drugi komunikat jest poziomu 3 czyli Errors. Jak już wspomniano komunikaty klasyfikuje się według poziomu czyli komunikaty poziomu 7 są najmniej ważne zaś te poziomu 0 mają znaczenie krytyczne. Dodatkowo dołączana jest informacja o zaistniałym zdarzeniu. W przypadku rozważanych komunikatów jest to informacja o przeprowadzonej konfiguracji z wykorzystaniem połączenia linii VTY – CONFIG_I oraz włączeniu interfejsu – UPDOWN.

Ostatnią częścią wpisu jest treść informacyjna poszerzająca komunikat o dodatkowe szczegóły zarejestrowanego zdarzenia.

Zanim rozpoczniemy zbieranie informacji o zaistniałych zdarzeniach, warto na wszystkich urządzeniach, które będą podlegać temu procesowi wykonać konfigurację daty oraz czasu. Jak ustawić czas ręcznie bądź wykorzystać do tego celu protokół NTP przeczytasz w wpisie: Zarządzanie routerem CISCO

Nasze rozważania rozpoczniemy od włączenia rejestrowania lokalnego.

1 - rejestrowanie włączymy z wykorzystaniem polecenia: logging buffered <poziom_komunikatu>,

2 - za pomocą komendy: logging buffered <wartość> określamy maksymalny rozmiar bufora w którym będą przechowywane logi zdarzeń.

Domyślny poziom ważności rejestrowanych komunikatów obejmuje zapisywanie wszystkiego, oznacza to, że wydanie samego polecenia: logging buffered spowoduje ustawienie rejestracji zdarzeń na poziomie 7 (debugowanie). Wybranie poziomu debugowania jest jednoznaczne z zapisywaniem zdarzeń poziomów niższych. Dlatego też by ograniczyć liczbę zbieranych i przechowywanych logów ich ilość możemy kontrolować poprzez definicję poziomu (severity level). Maksymalny poziom ważności rejestrowanych komunikatów określamy za pomocą słów kluczowych (patrz tabela powyżej, kolumna nazwa poziomu) bądź numeru poziomu.

Domyślny rozmiar bufora zarezerwowany na potrzeby przechowywania logów wynosi 4096 bajtów (nie jest to wartość stała obejmująca wszystkie modele routerów). Jest to niewiele i bardzo często rozmiar ten przez administratorów jest modyfikowany tak by pomieścić większą liczbę wpisów. Domyślny rozmiar bufora pozwala na przechowanie około 50 wpisów. Po przekroczeniu rozmiaru dziennika najstarsze wpisy są usuwane tak by zrobić miejsce na nowsze. Wielkość ustalonego bufora ma wpływ na ilość dostępnej pamięci RAM - im więcej zarezerwujemy na potrzeby dziennika tym mniej pamięci router będzie miał do wykorzystanie podczas realizacji swoich podstawowych zadań.

Historie zaistniałych zdarzeń możemy przeglądać za pomocą polecenia: show logging Logi systemowe zostały uszeregowane od najstarszego do najnowszego.

Dodatkowo po wydaniu polecenia poznamy takie informacje jak:

1 - stan oraz ustalony poziom rejestrowania konsolowego. Aby wyłączyć wszystkie komunikaty routera o zaistniałych zdarzeniach wydaj polecenie: no logging console Po wydaniu polecenia zostanie wyłączone wyświetlanie jakichkolwiek komunikatów.

2 - stan oraz ustalony poziom rejestrowania zdalnego (o tym temacie szerzej już za chwilę).

3 - stan oraz ustalony poziom rejestrowania lokalnego z wykorzystaniem bufora.

4 - ustalony rozmiar dziennika.

Aby włączyć licznik wystąpień zdarzeń określonego rodzaju należy posłużyć się poleceniem: logging count Po włączeniu licznika stan zdarzeń przejrzymy po wydaniu komendy: show logging count

Aby wyłączyć zapis zdarzeń do bufora routera należy wydać polecenie: no logging buffered natomiast by wyczyścić zawartość bufora wydaj komendę: clear logging.

Omówienie rejestrowanie z wykorzystaniem zestawionej sesji zdalnej oraz serwera Syslog omówimy na przykładzie topologii sieciowej przedstawionej na rysunku poniżej.

Rejestrowanie zdarzeń jak już wiesz Czytelniku możemy również prowadzić z wykorzystaniem zestawionej sesji wykorzystującej linie VTY.

Aby włączyć wyświetlanie zdarzeń podczas sesji połączenia zdalnego należy wydać polecenia:

1 - logging monitor <poziom_komunikatu> (w trybie konfiguracji globalnej) – wydanie polecenie uruchamia rejestrowanie terminalowe,

2 - dodatkowo proces należy uruchomić oddzielnym poleceniem: terminal monitor (tryb EXEC).

Właściwe polecenia zostały wydane sprawdźmy zatem ich efekt. Poniżej zostało nawiązane połączenie zdalne z routerem R1 z hosta o adresie IP 192.168.0.1, celem sprawdzenia faktu rejestracji został włączony i wyłączony interfejs f0/1 routera R1.

Jak widać powyżej żaden komunikat o zmianie statusu interfejsu f0/1 nie został wyświetlony. Nasuwa się pytanie – Dlaczego wyświetlenie komunikatów o zdarzeniach podczas trwania sesji zdalnej nie działa?

Powodem takiego stanu rzeczy jest błędna lokalizacja wydania polecenia: terminal monitor O ile samo włączenie rejestrowania terminalowego możemy wykonać na routerze (polecenie te jest wydawane w trybie konfiguracji globalnej tak więc obowiązuje niezależnie od miejsca jego wydania) to już włączenie rejestrowanie VTY powinno odbyć się oddzielnie dla każdego nawiązanego połączenia.

Poprawny zatem konfigurację i sprawdźmy efekty.

Zostaje nawiązane połączenie z routerem R1 i po zestawieniu sesji w trybie uprzywilejowanym administrator wydaje polecenie: terminal monitor W kolejnym kroku ponownie zostają wydane polecenia nakazujące włączenie a następnie wyłączenie interfejsu f0/1 routera. Jak widać, tym razem o zaistniałych zmianach w konfiguracji urządzenia jesteśmy informowani stosownymi komunikatami.

Rejestrowanie zdarzeń z wykorzystaniem połączenia zdalnego działa.

Przejdźmy zatem do metody zbierania logów z wykorzystaniem zewnętrznego serwera Syslog.

Do obsługi i zapisu logów zdarzeń wysyłanych przez urządzenia budujące naszą sieć, niezbędne jest posiadanie dodatkowego oprogramowania.

W wpisie tym zajmiemy się oprogramowaniem pracującym pod kontrolą systemu Windows (system Linux będzie omówiony w oddzielnym wpisie). Do zaproponowania mam dla Ciebie Czytelniku trzy programy:

Kiwi Syslog Server - to oprogramowanie do zarządzania logami systemowymi, program oferuje wiele funkcji od pobierania, rejestrowania i przekazywania logów systemowych, SNMP czy dziennika zdarzeń Windows do powiadamiania o zaistniałych zdarzeniach. Program obsługuje routery, switche, hosty z zainstalowanym systemem Windows oraz Linux. Kiwi Syslog Server występuje w dwóch wersjach: płatnej oraz darmowej. Wersja bezpłatna pozwala na rejestrowanie zdarzań przy wykorzystaniu protokołu Syslog oraz SNMP. Ilość obsługiwanych urządzeń została ograniczona do 5, dodatkowo brak jest funkcjonalności archiwizacji logów, powiadomień o zaistniałym zdarzeniu (alarm, email) oraz konfiguracji opartej o www. Wersja płatna oczywiście opisanych ograniczeń nie posiada. Program można pobrać ze strony: http://www.kiwisyslog.com/free-edition.aspx

Drugim programem jest 3CDaemon. Program jest całkowicie darmowy i jedną z jego funkcjonalności jest rejestrowanie zdarzeń przy wykorzystaniu Syslog. Dodatkowo program oferuje funkcjonalność serwera FTP czy TFTP. Oznacza to, że w bardzo prosty sposób możemy np. archiwizować konfigurację routerów czy switchy wykorzystując do tego jeden z dwóch wymienionych protokołów. Narzędzie niestety nie obsługuje protokołu SNMP. Program pobierzesz ze strony: http://www.firewall.cx/downloads/ftp-tftp-servers-a-clients/16-1-3cdaemon-server-a-client.html

Ostatnim zaś programem jest tftpd32/64. Narzędzie te jak pozostałe również pełni rolę serwera Syslog lecz ma bardzo ograniczone możliwości (pewnie niektórym tak minimalistyczne podejście do tematu się spodoba).

Po pobraniu i zapisaniu Kiwi Syslog Server rozpoczynamy instalację programu. Instalacja programu przebiega standardowo z małym wyjątkiem. Podczas instalacji zostaniemy zapytani – Czy program po instalacji ma pracować jako usługa czy aplikacja? Wybranie usługi spowoduje uruchomienie serwera za każdym razem gdy zostanie włączony system. Konsekwencją zainstalowania programu jako usługi będzie niemożność uruchomienia innych narzędzi rejestrujących zdarzenia z wykorzystaniem metody Syslog bądź SNMP, zaś zaletą wybrania tego rozwiązania jest ciągła rejestracja napływających informacji. Wybranie opcji drugiej spowoduje zainstalowanie narzędzia, tak jak standardowej aplikacji.

My decydujemy się na instalację opartą o usługę. Dlatego też w kolejnym kroku musimy zdefiniować poziom uprawnień z których będzie korzystał serwer. Do wyboru mamy dwie opcje: konto systemowe bądź inne zdefiniowane przez nas konto.

W kolejnym kroku definiujemy typ instalacji oraz wybieramy opcjonalne czynności, które zostaną wykonane wraz z instalacją programu.

Po definicji wszystkich ustawień następuje instalacja narzędzia.

W przypadku 3CDaemon pobieramy spakowany plik w formacie ZIP po rozpakowaniu, którego instalujemy program. Instalacja przebiega w sposób standardowy.

Po uruchomieniu narzędzia Kiwi Syslog Server warto zajrzeć do opcji programu aby zapoznać się z jego możliwościami. Do ustawień dostaniemy się po wybraniu z menu File opcji Setup (skrót Ctrl+P).

Warto również zajrzeć do menu Manage gdzie między innymi możemy włączyć/wyłączyć usługę serwera czy przeprowadzić proste testy diagnostyczne sprawdzające czy np. wiadomości nie będą blokowane przez zaporę systemową.

Aby narzędzie Kiwi Syslog Server mogło prawidłowo odbierać logi o zaistniałych zdarzeniach, należy skonfigurować jeszcze jedną opcje. Opcja ta związana jest z ograniczeniem wersji darmowej do pięciu urządzeń. Aby określić urządzenia, których logi będą rejestrowane należy przejść do ustawień programu i na karcie Inputs określić adresy IP urządzeń, które będą podlegały procesowi rejestrowania.

Narzędzie Kiwi Syslog Server jest gotowe do odbierania wiadomości.

Nadszedł czas by skonfigurować router, przechodzimy do linii poleceń routera R1.

Aby router mógł przesyłać logi do zewnętrznego serwera Syslog należy wydać polecenia:

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

Sprawdźmy zatem efekt przeprowadzonej konfiguracji.

Jak można zauważyć poniżej efekt wydania poleceń włączenia/wyłączenia interfejsu f0/1 routera R1 znajduje odzwierciedlenie w logach serwera Syslog.

Ponieważ program Kiwi Syslog Serwer działa jako usługa nie musi on być fizycznie uruchomiony by móc logi o zaistniałych zdarzeniach odbierać.

Do określenia ważności przesyłanych komunikatów użyto polecenie: logging trap <poziom>, pominięcie polecenia spowoduje włączenie wysyłania komunikatów o poziomie ważności: informational. W przypadku ustawienia większej liczby serwerów logowania definicja poziomu ważności obowiązuje dla wszystkich. Nie ma możliwości określenia poziomów dla każdego z serwera Syslog osobno.

Sprawdzenie ustawionego poziomu ważności komunikatów zweryfikujemy wydając komendę: show logging

Konfigurację rejestrowania zdarzeń przy użyciu serwera Syslog można również przeprowadzić z wykorzystaniem nazw domenowych. Poniżej na zrzucie został zaprezentowany przykład takiej konfiguracji.

1 - router jest wstanie rozwiązywać nazwy hostów przy użyciu serwera DNS, warunkiem oczywiście jest istnienie takiego serwera w naszej sieci, dlatego też gdy w naszej sieci serwer DNS nie istnieje dobrze jest wykonać odwzorowanie typu: adres IP-nazwa hosta. Wykonanie odwzorowywanie uchroni nas przed sytuacją w której serwer DNS uległ awarii, gdyż router w swojej konfiguracji posiada wpis, który pozwoli mu powiązać adres IP z nazwą domenową hosta. Przypisanie adresu IP do odpowiadającej nazwy domenowej hosta wykonamy za pomocą polecenia: ip host <nazwa_domenowa> <adres_IP> W przykładzie poniżej hostowi o adresie IP 192.168.0.1 została przypisana nazwa yyy.firma.local (taka jest nazwa domenowa serwera Syslog). Po dokonaniu przypisania nazwy domenowej hosta możemy używać w poleceniach – np. sprawdzenie dostępności hosta przy wykorzystaniu polecenia: ping (punkt 3).

2 - po utworzeniu dowiązania włączamy logowanie, lecz tym razem zamiast adresu IP podajemy nawę hosta.

Reszta konfiguracji przebiega jak w przykładzie powyżej.

Rejestracja zdarzeń z wykorzystaniem aplikacji Kiwi Syslog Serwer została przeprowadzona prawidłowo czas zatem by przejść do kolejnego narzędzia.

Do przesyłania wiadomości o zdarzeniach skonfigurowaliśmy router R2 a do ich odbioru użyjemy narzędzia 3CDaemon.

Aby móc użyć programu do rejestracji logów musimy w pierwszej kolejności zatrzymać usługę serwera Kiwi Syslog (krok ten jest zbędny w przypadku instalacji serwera Kiwi jako aplikacji, brak zatrzymania usługi spowoduje błąd uruchomienia programu 3CDaemon). Zatrzymanie usługi wykonamy bezpośrednio z programu wybierając z menu Manage opcję Stop the Syslogd service Oczywiście usługę serwera Kiwi możemy również wyłączyć wykorzystując do tego okno: Usługi.

Po uruchomieniu programu 3CDaemon do dyspozycji mamy następujące ustawienia:

1 - Konfiguracja serwer Syslog – opcje konfiguracji programu są bardzo skromne wpływ mamy na: określenie ścieżki zapisu logów; określenie adresów IP urządzeń, których logi mają być zapisywane oraz zdefiniowane sposobu zapisu przychodzących komunikatów (wszystko do jednego pliku, zapis do plików w zależności od poziomu otrzymanego komunikatu, zapis do plików w zależności od kategorii wiadomości czy zapis do plików w zależności od adresu IP).

2 - Włączenie/wyłączenie serwera Syslog,

3 - Wyczyszczenie listy,

4 - Podgląd plików logów.

Sprawdźmy zatem działanie programu. Tak jak w przypadku Kiwi Syslog Serwer zasymulowano włączenie i wyłączenie interfejsu routera. Jak można się przekonać po analizie zrzutu poniżej logi do serwera Syslog zostały przesłane prawidłowo.

Zanim przejdziemy dalej z omawianiem konfiguracji urządzeń Cisco do współpracy z zdalnym rejestrowaniem zdarzeń zatrzymajmy się jeszcze chwilkę przy narzędziu 3CDaemon. Jak napisałem wyżej program pomimo tego, że posiada mało opcji konfiguracji serwera Syslog to rekompensuje nam to innymi funkcjami. Przy pomocy programu wykonamy szereg innych działań administracyjnych a nie potrzebujemy do tego dedykowanych aplikacji gdyż niezbędne funkcje są zaimplementowane już w samym programie.

Do tych podstawowych funkcji należy pełnie roli:

Serwera TFTP (ang. Trivial File Transfer Protocol) – zasada działania serwera opiera się na wykorzystaniu protokołu UDP wraz w połączeniu z numerem portu 69. W przypadku użycia TFTP jedyne co potrzeba by pobrać plik to adres IP serwera i nazwa pliku (nazw pliku jest niezbędna gdyż nie mamy możliwości wylistowania plików na serwerze). Protokół ten jest otwarty dla wszystkich tak więc brak w nim wsparcia dla takich mechanizmów jak: konta użytkowników, pewność dostarczenia przesyłanego pliku czy szyfrowanie. Główną zaletą protokołu jest jego prostota i łatwość wykorzystania. Gdy szybko chcemy z routera/przełącznika przesłać jakiś plik to przy użyciu tego protokołu wykonamy te zadanie bez żadnych problemów.

Konfiguracja narzędzia 3CDaemon sprowadza się do określenia katalogu w którym mają być zapisywane pliki wysyłane przez urządzenia/hosty zdalne.

Inne programy, które pełnią rolę serwera TFTP to: Open TFTP Server (narzędzie wiesza poleceń) oraz TFTPD32/64 (opisany poniżej).

Na większe możliwości pozwala nam wykorzystanie serwera FTP. Protokół FTP działa w oparciu o protokół TCP tak więc mamy pewność iż przesyłany plik dotrze do celu w niezmienionej postaci. O ile TFTP nadaje się świetnie np. do przesłanie kopii konfiguracji urządzenia (running-config) to już do zapisu pliku firmware urządzenia wykorzystanie go może przysporzyć nam problemów. Dlatego też w sytuacjach w których musimy mieć zapewnioną pewność przesyłania danych lepiej jest użyć protokołu FTP (o niezbędne funkcje związane z korekcją ewentualnych błędów zadba protokół TCP).

Konfiguracja narzędzia polega na określeniu konta użytkownika mogącego zestawić połączenie (możliwe jest skorzystanie z konta: anonymous), katalogu zapisu/odczytu plików oraz definicji praw.

Ostatnią funkcjonalnością narzędzia jest wykorzystanie programu w roli klienta TFTP. Skorzystanie z tej funkcjonalności powala nam na wysłanie pliku z hosta w kierunku innego serwer TFTP.

Aby móc skopiować dane należy określić adres IP serwera TFTP oraz wybrać plik, który ma zostać przesłany.

Ostatnim prezentowanym programem mogącym pełnić rolę serwera Syslog jest bezpłatna aplikacja Tftpd32/64, która pomimo swojej prostoty również umożliwi nam zbieranie informacji na temat zaistniałych zdarzeń. Tak naprawdę uruchomienie serwera Syslog sprowadza się tylko do włączenia samej aplikacji. Po włączeniu programu, narzędzie jest gotowe do pracy.

Opcje na którą mamy wpływ to określenie lokalizacji zapisu pliku logu.

Po uruchomieniu narzędzia program zaczyna zbierać logi. Poniżej zasymulowana sytuacja włączenia i wyłączenia interfejsu f0/1 routera R1. Jak widać aplikacja działa, logi są przekazywane prawidłowo.

Program nie tylko pełni role serwera Syslog ale również tak jak 3CDaemon można go wykorzystać jako serwer TFTP ale również narzędzie jest klientem TFTP. Unikatową funkcją Tftpd32/64 jest zaimplementowana rola serwera DHCP.

Przy korzystaniu z rejestrowania zdarzeń istnieje możliwość wyłączenia przesyłania komunikatów dotyczących najczęstszych zajść związanych z działanie interfejsów.

Zajścia te dotyczą wysyłania komunikatów w sytuacji zmiany stanu interfejsu z aktywnego na nieaktywny i z powrotem a także zmiany stanu podinterfejsów (oczywiście jeśli takowe zostały skonfigurowane).

Zasymulujmy więc sytuację w której włączymy i wyłączymy interfejs f0/1 routera R1. Jak można zauważyć po analizie poniższego zrzutu włączenie i wyłączenie interfejsu powoduje wyświetlenie stosownych komunikatów w linii poleceń konsoli oraz wysłanie ich do serwera Syslog (punkt 1).

W kolejnym kroku zostały wydane dwa dodatkowe polecenia (komendy wydajemy w trybie konfiguracji interfejsu):

no logging event link-status - polecenie wyłącza wyświetlenia komunikatów dotyczących zmiany stanu interfejsu f0/1 routera R1 (punkt 2),

no logging event subif-link-status - polecenie wyłącza wyświetlenia komunikatów dotyczących aktywacji bądź dezaktywacji łącza podinterfejsów (punkt 3).

Po dokonanych zmianach ponownie wykonujemy czynność włączenia i wyłączenia interfejsu f0/1. Tym razem brak jest jakichkolwiek komunikatów informujących o zaistniałej zmianie stanu łącza (komunikaty zostają również wyłączone dla linii poleceń konsoli) - punkt 4.

Prócz wyłączenia informowania o zmianie statusu interfejsu możemy również wykonać operację polegającą na ograniczeniu liczby wysyłanych danych do serwera Syslog. Domyślnie router bądź przełącznik wysyła wszystkie pojawiające się komunikaty. Czasem podczas prowadzonych działań może dojść do sytuacji w której bieżące komunikaty będą „zalewały” serwer Syslog (szczególnie gdy włączymy przetwarzanie zdarzeń na poziomie debugowania). Dlatego też by ograniczyć ich ilość możemy posłużyć się poleceniem: logging rate-limit <wartość>

Powyżej na rysunku skonfigurowano:

1 - ograniczenie liczby komunikatów do 20 z wyłączeniem zdarzeń o poziomie warnings (poziom 4) i niższych,

2 - ograniczenie liczby komunikatów do 20 z wyłączeniem zdarzeń o poziomie warnings (poziom 4) i niższych, komenda ta ze względu na użycie parametru: console ma zastosowanie do komunikatów pojawiających się w linii poleceń konsoli.

Zastosowane komendy spowodują włączenie ograniczenia wysyłania komunikatów do 20 na sekundę. Liczba ograniczonych komunikatów może przyjąć wartość z zakresu od 1 do 10000. Aby ograniczenie obowiązywało dla wszystkich poziomów należy użyć parametru: all (bądź ustalić ich poziom na: debugging).

I na tym etapie kończymy, nie wszystkie opcje zostały omówione gdyż zabrakło trochę więcej informacji na temat zmiany domyślnej kategorii wysyłania komunikatów, ale obiecuję to nadrobić w kolejnym wpisie w którym to również zajmiemy się rejestracją zdarzeń lecz tym razem serwer Syslog, będzie pracował pod kontrolą systemu Linux.

BIBLIOGRAFIA:

Configuring a Syslog Agent in Windows Server 2012 :: Windows Server 2012 :: Articles & Tutorials :: WindowsNetworking.com

6 Free Syslog Servers for Windows and Linux/Unix

tftpd32 | protocolSyntax