Co w sieci piszczy, czyli jak lepiej zarządzać zdarzeniami

W tym artykule skupimy się na odpowiedzi na pytane: Co zrobić, by „wycisnąć” więcej ze SIEM-a i zarządzania zdarzeniami bezpieczeństwa?

social_network_abstractO użyteczności i „sile” narzędzi klasy SIEM tylko w części decyduje ich rodzaj i oferowana funkcjonalność. Nie do tego jednak rzecz się ogranicza. O efektach najważniejszej funkcji SIEM-a, jaką jest korelacja zdarzeń, decyduje niewątpliwie rodzaj i jakość danych źródłowych, na których operuje system. Dlatego też ogromnie ważne jest, by „nakarmić” SIEM-a wartościowym materiałem.
Co mam na myśli, mówiąc: wartościowy materiał? Otóż, chodzi o logi o zestandaryzowanej strukturze, o normalizację, o poziom istotności zdarzeń i wreszcie o to, czy określone źródło zdarzeń jest w stanie sygnalizować wszystko to, czego od niego oczekujemy.

Temu ostatniemu aspektowi będzie poświęcony ten właśnie artykuł. Skupimy się w nim na tym, jak wykorzystać SIEM-a do jeszcze skuteczniejszego monitorowania bezpieczeństwa urządzeń sieciowych, wykorzystując w tym celu nie tyle możliwości samego SIEM-a, co warte uwagi funkcjonalności urządzeń sieciowych Cisco. Jestem bowiem przekonany, że to właśnie na styku SIEM-a i źródeł zdarzeń pojawia się prawdziwy „power” zarządzania zdarzeniami bezpieczeństwa, któremu warto przyglądnąć się baczniej.

Warto przez chwilę poświęcić czas i uwagę funkcjonalności EEM (Embedded Event Manager) w systemie operacyjnym urządzeń Cisco i temu, jak „zaprząc” tego „czarnego konia” do pojazdu o nazwie SIEM, by jechał jak Lamborghini, zamiast wlec się jak szkapa.

Na czym się dokładniej skoncentrujemy?

Na początek powiem o tym, czym jest EEM i jakie użyteczne dla nas funkcje oferuje. Potem przejdę do krótkiego omówienia i pokazania praktycznych przykładów wykorzystania tego narzędzia, cały czas koncentrując się na jego kooperacji z systemem SIEM.
Praktyczne przykłady zastosowania EEM i SIEM-a będą podzielone na dwa bloki – blok zastosowań podstawowych oraz blok zastosowań zaawansowanych.
W bloku zastosowań podstawowych zajmiemy się planowaniem i uruchamianiem wybranych, ciekawych funkcji obsługi zdarzeń w oparciu wyłącznie o interfejs systemu IOS routera Cisco. W części zaawansowanej zainteresuje nas, jak pójść krok dalej i – wykorzystując język skryptowy Tcl – uzyskać coś jeszcze lepszego. Przyglądniemy się mianowicie temu, jak wykorzystać wbudowany w system operacyjny urządzeń Cisco interpreter Tcl, do jeszcze doskonalszej obsługi zdarzeń.

Startujemy?

Na początek kilka słów o EEM – Czym jest? Co oferuje? Jak z niego korzystać?

EEM jest relatywnie nową funkcjonalnością, a właściwie podsystemem takowej, która umożliwia inteligentne zarządzania zdarzeniami na samym urządzeniu sieciowym. W zakres takiego zarządzania wchodzi po pierwsze inteligentne identyfikowanie zdarzeń o charakterystyce definiowanej przez administratora, a po drugie równie inteligentnym odpowiadaniu na wystąpienie tych zdarzeń. Jeśli mowa o reagowaniu, to EEM nie ogranicza nas jedynie do notyfikacji o wystąpieniu zdarzenia, choć to samo w sobie cenna rzecz, móc reagować na zdarzenia inne niż te sygnalizowane w standardowy sposób, z jedynie domyślnie działającego na urządzeniu, podsystemu logowania i protokołu Syslog. Reagowanie na zdarzenia może polegać także na podejmowaniu konkretnych akcji, w postaci choćby zebrania dodatkowych danych diagnostycznych przed zasygnalizowaniem problemu albo wykonaniu rekonfiguracji urządzenia.
Choć, jak wspomniałem, EEM może funkcjonować autonomicznie, to jego siła polega na możliwości zasilania reguł korelacyjnych na SIEM-ie interesującymi nas informacjami, o interesującym nas poziomie jakości.
Z EEM-a możemy korzystać na dwa sposoby: przez standardowy interfejs apletów definiowanych w konfiguracji urządzenia oraz przez skrypty Tcl uruchamiane z wykorzystaniem, wbudowanego w system operacyjny urządzenia, interpretera tego języka skryptowego.
W dalszej części warsztatów zajmiemy się jednym i drugim sposobem programowania tak rozpoznawania zdarzeń, jak i akcji podejmowanych przez urządzenie w odpowiedzi na ich wystąpienie.

Aplety EEM – jak się zabrać za robienie z nich pożytku?

Definiujemy i rejestrujemy pierwszy aplet w EEM:

ROUTER(config)# event manager applet MOJ_PIERWSZY_APLET

Określamy rodzaj interesującego nas zdarzenia. Zdarzeniem jest w naszym przykładzie awaria jednego z dwóch łączy do sieci operatora. Jedno z nich – podstawowe – działa w oparciu o interfejs FastEthernet 0/0, drugie jest łączem zapasowym, działającym w trybie „standby”, w oparciu o interfejs FastEthernet 0/1.

ROUTER(config-applet)# event syslog pattern "Interface FastEthernet0/0, changed state to down"

Można dodatkowo, opcjonalnie opisać aplet:

ROUTER(config-applet)# description “Automatic external link switchover”

Określamy następnie działania podejmowane w odpowiedzi na zdarzenie – uruchomienie łącza zapasowego (standby). O kolejności podejmowanych działań decyduje alfabetyczny (nie numeryczny) porządek ich znaczników. Warto stosować notację podobną jak zastosowana w podanym przykładzie, bo umożliwia ona łatwą, późniejszą modyfikację „polityki” EEM-a.

ROUTER(config-applet)# action 1.0 cli command "enable"
ROUTER(config-applet)# action 1.1 cli command "configure term"
ROUTER(config-applet)# action 1.2 cli command "interface f0/1"
ROUTER(config-applet)# action 1.3 cli command "no shut"
ROUTER(config-applet)# action 1.4 syslog msg “External link switchover”

Reasumując, składnia poleceń systemu do tworzenia apletów jest następująca:

ROUTER(config)# event manager applet NAZWA_APLETU
ROUTER(config-applet)# event <rodzaj_zdarzenia> <charakterystyka_zdarzenia>
ROUTER(config-applet)# action <znacznik> <rodzaj_działania> <charakterystyka_działania>

Najciekawsze rodzaje zdarzeń to:

  • Wykonanie określonego polecenia lub sekwencji poleceń IOS (typ: cli)
  • Przekroczenie wartości określonego, zdefiniowanego licznika stanu (typ: counter)
  • Przekroczenie stanu predefiniowanych liczników zdarzeń związanych z interfejsem (typ: interface)
  • Przekroczenie stanu liczników wykorzystania zasobów (‘watchdog’ utylizacji CPU, pamięci, buforów) (typ: ioswdsysmon)
  • Przekroczenie stanów bazowych wykorzystania łączy (typ: ipsla)
  • Zdarzenia związane z funkcjonalnością NetFlow (typ: nf)
  • Zmiany w tablicy routingu (typ: routing)
  • Zmiany wartości zmiennych MIB (typ: snmp)
  • Wystąpienie określonego zdarzenia (możliwego do opisania wyrażeniem regularnym) zasygnalizowanego komunikatem Sysloga (typ: syslog)
  • Spełnienie kryteriów daty i czasu, włącznie z obsługą schedulera CRON (typ: timer)
  • Zmiana stanu śledzonego obiektu (typ: track)

Najbardziej interesujące typy działań w odpowiedzi na zdarzenia to:

  • Wykonanie polecenia lub ciągu poleceń IOS (diagnostycznych lub konfiguracyjnych) (typ: cli)
  • Wysłanie notyfikacji via e-mail do administratora (typ: mail)
  • Wygenerowanie komunikatu Syslog (typ: syslog)
  • Wygenerowanie komunikatu SNMP trap (typ: snmp-trap)
  • Pobranie lub wyprowadzenie informacji – STDIN/STDOUT (typ: gets / puts)
  • Ustawienie i inkrementacja lub dekrementacja licznika wystąpień zdarzenia (typ: increment / dekrement / append)
  • Uruchomienie warunkowej obsługi zdarzenia lub pętli obsługi zdarzeń (typ: if / else / elseif / while / end / break / continue / foreach)
  • Przeładowanie systemu na urządzeniu (typ: reload)
  • Odczytanie/ustawienie stanu śledzonego obiektu (typ: track)
  • Przeprowadzenie dopasowania do wzorca zdefiniowanego jako wyrażenie regularne (typ: regexp)

Aplety, po zarejestrowaniu, uruchamiane są automatycznie przez podsystem EEM w odpowiedzi na wystąpienie zdefiniowanych zdarzeń. Dodatkowo, istnieje możliwość ręcznego uruchamiania apletów, co czasem przydaje się nie tylko w celu ich testowania.

Przykładowo, możemy zdefiniować aplet EEM przeznaczony do ręcznego uruchamiania (zwróć uwagę na charakterystykę zdarzenia: event none). Będzie on kasował licznik ruchu i błędów na interfejsach.

event manager applet clear_counters
   event none
   action 0.9 puts “Clearing interface counters…”
   action 1.0 cli command “enable”
   action 1.1 cli command “clear counters” pattern “confirm”
   action 1.2 cli command “y”
   action 1.3 cli command “disable”
   action 1.4 cli command “end”

Taki aplet możemy manualnie uruchomić poleceniem:

event manager run clear_counters

lub – prościej – zdefiniować alias na bazie apletu:

ROUTER(config)# alias exec clear_counters event manager run clear_counters

…by w następnej kolejności uruchamiać aplet aliasem clear_counters wprost z linii poleceń.

Garść przykładów zastosowań apletów EEM

1. Śledzenie zmian w konfiguracji

Zaprezentowany przykład dwóch apletów EEM pozwala na sygnalizowanie zmian w konfiguracji routera wprowadzanych z poziomu linii poleceń.

Pierwszy z apletów uruchamiany jest w odpowiedzi na wejście w tryb konfiguracyjny, co określa wzorzec polecenia (CLI pattern), podany jako kryterium wyzwolenia zdarzenia. Proszę zwrócić uwagę na dalsze parametry kryterium zdarzenia: sync yes. Oznaczają one, że wejście w tryb konfiguracyjny następuje w trybie synchronicznym względem wykonania sekwencji działań apletu. Innymi słowy rzecz ujmując, tak długo, dopóki sekwencja czynności nie zostanie wykonana, nie będzie możliwe wejście w tryb konfiguracyjny urządzenia.
W ramach sekwencji działań, wykonywane są kolejno polecenia mające na celu określenie kiedy i kto chce wejść w tryb konfiguracyjny oraz jaki jest stan konfiguracji bieżącej w momencie sprzed wprowadzenia zmian.
Te ważne informacje zapisywane są do pliku w pamięci flash urządzenia. Wysyłane są także komunikaty do Syslog-a (SIEM-a) o zdarzeniach.

event manager applet CONFIG_ENTRY
   event cli pattern "configure terminal" sync yes skip no
   action 1.0 syslog priority emergencies msg "Configuration mode entry on ROUTER"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:change_before.txt"
   action 1.3 cli command "show clock | append flash:change_before.txt"
   action 1.4 cli command "who | append change_before.txt"
   action 1.5 cli command "show run | append change_before.txt"
   action 1.6 cli command “end”

event manager applet CONFIG_EXIT
   event syslog occurs 1 pattern "%SYS-5-CONFIG_I:"
   action 1.0 syslog priority emergencies msg "Exit from configuration mode on ROUTER. Detailed accounting record available in the file on flash"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:change_after.txt"
   action 1.3 cli command "show clock | append flash:change_after.txt"
   action 1.4 cli command "who | append change_after.txt"
   action 1.5 cli command "show run | append change_after.txt"
   action 1.6 cli command “end”

Zaprezentowany przykład można rzecz jasna potraktować jako bazę do dalszych zmian i udoskonaleń. Potencjalnie interesujące zmiany mogą iść w kierunku:

  • wprowadzenia rozróżnienia, z jakiego urządzenia terminalowego wprowadzane są zmiany, by na przykład nie logować zmian wprowadzanych z konsoli fizycznej, a jedynie z poziomu linii wirtualnych terminali (Telnet, SSH etc.);
  • opracowania przy pomocy skryptów Tcl informacji zapisywanych w pliku w pamięci flash pod kątem rejestrowania samych zmian (delty zmian);
  • zapisywania plików z diagnostyką na zewnętrznym serwerze (TFTP, TFP, SCP etc.);
  • znakowania nazw plików z diagnostyką znacznikami czasów wystąpienia;
  • wzbogacenia informacji wysyłanych do Sysloga (SIEM-a) o wybrane, istotne informacje zapisywane w pliku z diagnostyką;
  • zbudowania w oparciu o skrypty Tcl narzędzi do roll-backu zmian.

Chcąc poddać plik ze zgromadzonymi informacjami diagnostycznymi dalszej, inteligentnej obróbce, można napisać w tym celu skrypt w języku Tcl, a następnie wykonać go w sekwencji czynności apletu EEM, w następujący sposób:

action 1.6 cli command “tclsh skrypt.tcl”

Skrypt Tcl uruchamiany tym sposobem może zarówno selekcjonować i formatować najistotniejsze, wybrane informacje, lecz także uruchamiać działania takie, jak komunikacja z agentem SIEM-a, z serwerem Sysloga (SIEM-a) etc. Skrypt taki może być zapisany w pamięci flash urządzenia lub na zewnętrznym serwerze, z którego router może go sobie pobrać przed wykonaniem, na przykład w protokole TFTP.

Przykładem prostego skryptu do „wyciągania” istotnych informacji z pliku diagnostycznego niech będzie ten kod:

if {[catch {set diag_file [open "flash:show_version.txt"]} results options]} {
   puts stderr "Could not open a file flash:show_version.txt"
   exit 1
} else {
   set file_data [read $diag_file]
   close $diag_file
}
set list [split $file_data "\n"]

# Wyszukiwanie łańcuchów znakowych w danych diagnostycznych wykonane metodą
# dopasowania na podstawie globbingu
# Ten sam efekt można uzyskać z wykorzystaniem wyrażeń regularnych
foreach line $list {
   if {[string match -nocase "Cisco IOS Software*" $line]} {
      puts $line
   } elseif {[string match -nocase "*bootstrap*" $line]} {
     puts $line
   } elseif {[string match -nocase "*uptime*" $line]} {
      puts $line
   } elseif {[string match -nocase "*system*" $line]} {
      puts $line
   } elseif {[string match -nocase "*memory*" $line]} {
      puts $line
   } elseif {[string match -nocase "*interface*" $line]} {
     puts $line
   } elseif {[string match -nocase "*module*" $line]} {
     puts $line
   } elseif {[string match -nocase "*flash*" $line]} {
     puts $line
   } elseif {[string match -nocase "*register*" $line]} {
     puts $line
   }
}

Co prawda przytoczony skrypt nie odnosi się do żadnego z poleceń, które w ramach diagnostyki zostały w poprzednio analizowanym przypadku wykonane na urządzeniu, dotyczy bowiem polecenia show version, ale za to dobrze ilustruje mechanizm selekcji informacji w oparciu o dopasowanie przez globbing łańcuchów znakowych. Inna, alternatywna metoda szukania dopasowań łańcuchów znakowych polega na zastosowaniu wyrażeń regularnych.

Inny przykładowy skrypt ilustruje możliwość zastosowania dopasowań bazujących na wyrażeniach regularnych.

proc tylko_cyfry {dane} {
   regsub -all {[^0-9]} $dane "" pasuje
   return $pasuje
}

if {[catch {set fd [open "flash:show_proc_mem.txt" r]} result]} {
   puts "Błąd otwarcia pliku show_proc_mem.txt do odczytu: $result"
   return -1
} else {
   set file_data [read $fd]
   close $fd
   set data [split $file_data "\n"]
   foreach line $data {
      set pasuje ""
         set pasuje [regexp -inline -all -nocase -- "Total.+" $line]
      if {$pasuje != ""} {
         set mem_data [split $line " "]
         set mem_total [tylko_cyfry [lindex $mem_data 1]] 
         set mem_used [tylko_cyfry [lindex $mem_data 3]]
         set mem_free [tylko_cyfry [lindex $mem_data 5]]
         set czas [clock seconds]
         set timestamp [clock format $czas -format "%d\/%m\/%Y-%H:%M:%S"]
         set mem_proc_free [expr {int(double($mem_free)/double($mem_total)*100)}]
         puts -nonewline "%SYS-5-MEM-$timestamp: "
         if {$mem_proc_free > 75} {
            puts -nonewline "Memory state: VERY HEALTHY"
         } elseif {$mem_proc_free > 25 && $mem_proc_free <= 75} {
            puts -nonewline "Memory state: HEALTHY"
         } else {
            puts -nonewline "Memory state: POOR"
         }
         puts -nonewline " - Total MEM: $mem_total, used: $mem_used, \
                              free: $mem_free\(${mem_proc_free}%\)"
      }      
   }
}

Jedną ze wspomnianych wcześniej korzyści z zastosowania skryptów Tcl do zaawansowanej obróbki danych diagnostycznych jest między innymi formatowanie komunikatów wyprowadzanych na konsolę lub kierowanych do serwera Syslog-a (SIEM-a). W języky Tcl robi się to niezwykle prosto:

set komunikat [format „%s\%SYS-5-DIAG: Counter TRAFFIC and ERROR_RATE exceeded by: %d, %d” $date $traffic $error]

Wyprowadzenie komunikatu na konsolę:

puts $komunikat

…skierowanie go do Syslog-a (SIEM-a):

action_syslog priority info msg $komunikat

Istnieje również możliwość wykonania polecenia diagnostycznego lub ciągu poleceń diagnostycznych z poziomu skryptu Tcl. Można to zrobić w następujący sposób:

typeahead „\n”
exec {clear counters}

Czasem przydaje się wykonanie komendy lub – częściej – sekwencji komend konfiguracyjnych z poziomu tegoż skryptu. Sposób wykonania tego zadania ilustruje następujący przykład:

ios_config „int Fast 0/0” „no shutdown” „end”

Wykonując polecenia trybu konfiguracyjnego na urządzeniu z poziomu skryptu Tcl, trzeba pamiętać, by ich ciąg zakończyć poleceniem „end”, pozwalającym na „czyste” wyjście z trybu konfiguracyjnego i nieblokowanie routera.

2. Monitorowanie administracyjnego blokowania interfejsów routera

W kolejnym przykładzie prezentujemy bardzo proste narzędzie do monitorowania administracyjnego blokowania interfejsów routera. Przykład nie należy być może do bardzo zaawansowanych, ale jego celem jest wyłącznie pokazanie, w jaki sposób ciąg wykonywanych poleceń systemu operacyjnego routera można wykorzystać jako zdarzenie i w ślad za jego wystąpieniem podjąć odpowiednie czynności.

event manager applet SHUTDOWN_MONITOR
   # event cli pattern "conf t; interface *; shutdown" sync yes
   event syslog pattern “%LINK-5-CHANGED”
   action 1.0 cli command "show ip int brief | append flash:interface_diag.txt"
   action 1.1 syslog priority info msg "%SYS-5-DIAG: Administrative shutdown on one of the ROUTER interfaces occurred"

W przedstawionym przykładzie, w odpowiedzi na zdefiniowany ciąg poleceń, podejmujemy sekwencyjnie dwa działania. Jedno z nich polega na wykonaniu polecenia show ip interface brief i dopisaniu wyników jego działania do pliku w pamięci flash routera. Drugie działanie polega na wysłaniu komunikatu do Syslog-a (SIEM-a). Oczywiście, jak w poprzednio omawianym przypadku, można poddać dane diagnostyczne zaawansowanej obróbce przy pomocy skryptu w języku Tcl, by wysłać do Syslog-a (SIEM-a) więcej istotniejszych informacji, pozyskać dodatkowe dane diagnostyczne, czy też nawet przeprowadzić automatyczną rekonfigurację routera.

3. Diagnostyka problemów z połączeniem lub degradacją parametrów transmisyjnych sieci

Często zdarza się tak, że doświadczamy pogorszenia się parametrów transmisyjnych łączy sieciowych lub też całkowitego braku komunikacji do krytycznego dla organizacji serwera. Pojawia się w związku z tym potrzeba monitorowania komunikacji pod kątem spełnienia określonych wymogów SLA, po to, by w razie odnotowania spadku parametrów transmisyjnych poniżej poziomu krytycznego, móc zebrać dodatkowe informacje diagnostyczne oraz podjąć odpowiednie działania. Z pomocą w takiej sytuacji przychodzi nam monitorowanie stanu odpowiednio zdefiniowanego obiektu SLA.

Najpierw definiujemy parametry SLA:

ip sla 10
   icmp-echo 192.168.1.100

Uruchamiamy pomiar parametrów SLA:

ip sla schedule 10 life forever start-time now

Określamy w jakich warunkach mają być sygnalizowane zmiany stanu obiektu SLA aktywny/nieaktywny oraz nieaktywny/aktywny:

track 10 ip sla 10 reachability
   delay down 5 up 10

Potem wykorzystujemy zmiany stanu obiektu SLA jako kryterium zdarzeń w aplecie EEM.

event manager applet important_server_unreachable
   event track 10 state down
   action 1.0 syslog msg "Serious contingency problem: 192.168.1.100 server unreachable!"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:server_unreachable"
   action 1.3 cli command "show clock | append server_unreachable"
   action 1.4 cli command "show ip arp 192.168.1.100 | append server_unreachable"
   action 1.5 cli command "show ip route 192.168.1.100 | append server_unreachable"
   action 1.6 cli command "show interface FastEthernet0/0 | append server_unreachable"
   action 1.7 cli command "more flash:server_unreachable"
   action 1.8 syslog msg "Server 192.168.1.100 unreachable. More diagnostic data available in flash:server_unreachable"
   action 1.9 cli command “end”

4. Zablokowanie możliwości wykonania komendy reload

Kolejny aplet EEM ukazuje, jak – korzystając z EEM-a – można blokować wykonywanie określonych komend na routerze. Zaprezentowanych przykład jest oczywiście wersją najbardziej uproszczoną tej funkcjonalności, ponieważ w warunkach rzeczywistych będziemy prawdopodobnie zainteresowani obwarowaniem tej czynności jakimiś warunkami typu: kto ją wykonuje i z poziomu jakiej linii terminalowej etc., co oczywiście jest możliwe do oprogramowania nawet z wykorzystaniem wyłącznie interfejsu konfiguracyjnego apletów, bez potrzeby odwoływania się do skryptów Tcl.

event manager applet RELOAD_DISABLE
   event cli pattern “reload” sync no skip yes occurs 1
   action 1.0 syslog msg “$_cli_msg is disabled”

W omawianym przykładzie, za zablokowanie możliwości wykonania komendy reload odpowiada modyfikator definicji zdarzenia: skip yes.

5. Okresowe wykonywanie komend diagnostycznych lub konfiguracyjnych na routerze

EEM dysponuje kolejną znakomitą funkcjonalnością stwarzającą doskonałe możliwości monitorowania stanu urządzenia. Jest nią możliwość określenia czasu wykonania określonego działania lub sekwencji działań, bazując na interfejsie CRON, dobrze znanym użytkownikom i administratorom systemów unixowych.

event manager applet PERIODIC_COMMAND_EXEC
   event timer cron cron_entry „45 20 * * *”
   action 1.0 cli command “enable”
   action 1.1 cli command “show ip access list 101”
   action 1.2 syslog msg “Access lists statistics: $_cli_result”

W rezultacie działania omawianego apletu o godzinie 20:45 każdego dnia, każdego miesiąca, każdego dnia tygodnia będzie wykonana komenda show ip access-list 101, a jej efekt działania, zawarty w predefiniowanej zmiennej systemowej _cli_result, zostanie przesłany do Syslog-a (SIEM-a).

6. Wyrażenia regularne w apletach EEM

Zaprezentowany aplet charakteryzuje się oczywiście bardzo ograniczoną użytecznością, ale za to pokazuje bardzo cenną funkcjonalność podsystemu EEM, jaką jest możliwość operowania na wyrażeniach regularnych.

event manager applet ADDRESS_INT_FAST
   event none sync yes
   action 1.0 cli command “show ip interface brief | include FastEthernet0/0”
   action 1.1 set result “”
   action 1.2 regexp “ [0-9.]+ ” $_cli_result result
   action 1.3 if $_regexp_result eq 1
   action 1.4 puts “Adres IP interfejsu FastEthernet0/0 to: $result”
   action 1.5 else
   action 1.6 puts “Brak adresu IP na interfejsie FastEthernet0/0”
   action 1.7 end

Jak widać, aplet ten służy do manualnego uruchamiania, ponieważ nie posiada określonych kryteriów rozpoznania zdarzenia (event none sync yes). Można go zatem uruchamiać wyłącznie manualnie:

ROUTER# event manager run ADDRESS_INT_FAST

Przykład ten pokazuje, jak wydobyć adres IP interfejsu FastEthernet 0/0, choć – jak łatwo sobie wyobrazić – można tym samym sposobem eksplorować jakiekolwiek dane diagnostyczne, będące efektem działania dowolnych komend routera, w poszukiwaniu cennych informacji, możliwych do zaprezentowania na konsoli lub wysłania w komunikacie o zdarzeniu do Syslog-a (SIEM-a).

Czego można chcieć więcej, czyli rzecz o skryptach Tcl

Alternatywą dla apletów EEM są skrypty Tcl, które określają zarówno wzorzec zdarzenia, jak i podejmowane w odpowiedzi działania.

Temat tworzenia tego typu skryptów wykracza jednak poza ramy tego artykułu, zatem ograniczymy się jedynie do podstawowych informacji na temat tego, jak uruchamiać skrypty na urządzeniu.

Skrypty należy przygotować przy pomocy znakowego edytora tekstu i załadować na router lub wskazać lokalizację zewnętrzną, z której mają być pobrane przed wykonaniem. Może to przykładowo wyglądać tak:

ROUTER(config)# scripting tcl encdir tftp://192.168.1.10/enctcl/

Następnie należy je wywoływać podając nazwę pliku jako parametr interpretera języka Tcl na routerze. Na przykład:

ROUTER# tclsh skrypt.tcl

Istnieje także możliwość interaktywnego wykonywania poleceń interpretera Tcl.

ROUTER# tclsh
ROUTER(tcl)# exec „show run”

Prosty przykład skryptu diagnostycznego:

set diagnostic_file [open "flash:show_interface.txt" r]
set diagnostic_data [read $diagnostic_file]
close $diagnostic_file
set input_block ""
set output_block ""
set generic_errors ""
set data [split $diagnostic_data "\[\n;\}"]
foreach line $data {
   if {[string match "*line protocol*" $line]} {
      # set line [string map {"line protocol" "protokół warstwy łącza danych"} $line]
      set interface [format "Interface: %s" $line]
   }
   if {[string match "*error*" $line] || [string match "*drop*" $line]} {
      set bufor [split $line ","]
      foreach elem $bufor {
         if {[string match -nocase "*input*" $elem]} {
            append input_block [string trim $elem] "\n"
         } elseif {[string match -nocase "*output*" $elem]} {
            append output_block [string trim $elem] "\n"
         } else {
            append generic_errors [string trim $elem] "\n"
         }
      }
   }
}

set input_block_header [format " %10s " "Input Errors:"]
set output_block_header [format " %10s " "Output Errors:"]
set generic_block_header [format " %10s " "Generic Errors:"]

append interface "\n" "----------$input_block_header-------------------------------------------"
append input_block "----------$output_block_header------------------------------------------"
append output_block "----------$generic_block_header-----------------------------------------"
append generic_errors "---------------------------------------------------------------"

puts $interface
puts $input_block
puts $output_block

if {[string length generic_errors] > 63} {
   puts $generic_errors
}

Skrypty Tcl oferują ogromne możliwości wspomagania zarządzania urządzeniami sieciowymi, ograniczone jedynie wyobraźnią administratora.
Interesujące fragmenty konfiguracji routera

Na potrzeby opracowania tego artykułu powstała ćwiczeniowa konfiguracja routera, której obszerne fragmenty dotyczące celu i przedmiotu ćwiczeń, zamieszczam poniżej.

ip sla 10
   icmp-echo 10.1.1.1
   timeout 10000
   frequency 20000
ip sla schedule 10 life forever start-time now
!
alias exec clear_counters event manager run clear_counters
alias exec show_proc_cpu event manager run SHOW_PROC_CPU
!
line con 0
   login local
line aux 0
line vty 0 4
   exec-timeout 0 0
   privilege level 15
   login local
line vty 5 15
   exec-timeout 0 0
   privilege level 15
   login local
!
scheduler allocate 20000 1000
!
event manager applet CONFIG_ENTRY
   event cli pattern "configure terminal" sync no skip no occurs 1
   action 1.0 syslog priority emergencies msg "Configuration mode entry on ROUTER"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:change_before.txt"
   action 1.3 cli command "show clock | append flash:change_before.txt"
   action 1.4 cli command "who | append change_before.txt"
   action 1.5 cli command "show run | append change_before.txt"
   action 1.6 cli command "end"
!
event manager applet CONFIG_EXIT
   event syslog occurs 1 pattern "%SYS-5-CONFIG_I:"
   action 1.0 syslog priority emergencies msg "Exit from configuration mode on ROUTER. Detailed accounting record available in the file on flash"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:change_after.txt"
   action 1.3 cli command "show clock | append flash:change_after.txt"
   action 1.4 cli command "who | append change_after.txt"
   action 1.5 cli command "show run | append change_after.txt"
   action 1.6 cli command "end"
!
event manager applet important_server_unreachable
   event track 10 state down
   action 1.0 syslog msg "Serious contingency problem: 10.1.1.1 server unreachable!"
   action 1.1 cli command "enable"
   action 1.2 cli command "del /force flash:server_unreachable"
   action 1.3 cli command "show clock | append server_unreachable"
   action 1.4 cli command "show ip arp 10.1.1.1 | append server_unreachable"
   action 1.5 cli command "show ip route 10.1.1.1 | append server_unreachable"
   action 1.6 cli command "show interface loo 0 | append server_unreachable"
   action 1.7 cli command "more flash:server_unreachable"
   action 1.8 syslog msg "Server 10.1.1.1 unreachable. More diagnostic data available in flash:server_unreachable"
   action 1.9 cli command "end"
!
event manager applet clear_counters
   event none
   action 0.9 puts "Clearing interface counters"
   action 1.0 cli command "enable"
   action 1.1 cli command "clear counters" pattern "confirm"
   action 1.2 cli command "y"
   action 1.3 cli command "disable"
   action 1.4 cli command "end"
!
event manager applet ADDRESS_INT_FAST
   event none sync yes
   action 1.0 cli command "show ip interface brief | include FastEthernet0/0"
   action 1.1 set result ""
   action 1.2 regexp " [0-9.]+ " "$_cli_result" result
   action 1.3 if $_regexp_result eq 1
   action 1.4 puts "Adres IP interfejsu FastEthernet0/0 to: $result"
   action 1.5 else
   action 1.6 puts "Brak adresu IP na interfejsie FastEthernet0/0"
   action 1.7 end
!
event manager applet SHUTDOWN_MONITOR
   event syslog pattern "%LINK-5-CHANGED"
   action 1.0 cli command "show ip int brief | append flash:interface_diag.txt"
   action 1.1 syslog priority informational msg "%SYS-5-DIAG: Administrative shutdown on one of the ROUTER interfaces occurred"
!
event manager applet VERSION
   event none
   action 1.0 cli command "show version | append flash:show_version.txt"
   action 1.1 cli command "tclsh flash:show_version.tcl"
   action 1.2 cli command "end"
!
event manager applet SHOW_PROC_CPU
   event none
   action 1.0 cli command "enable"
   action 1.1 set result ""
   action 1.2 cli command "show proc cpu | include CPU"
   action 1.3 regexp "CPU utilization for .*" "$_cli_result" result
   action 1.4 if $_regexp_result eq 1
   action 1.5 syslog msg "CPU utilization monitoring: $result"
   action 1.6 else
   action 1.7 puts "Error..."
   action 1.8 end
   action 1.9 cli command "end"
!
event manager applet SHOW_PROC_CPU_MON
   event timer cron cron-entry "0,15,30,45 * * * *"
   action 1.0 cli command "enable"
   action 1.1 set result ""
   action 1.2 cli command "show proc cpu | include CPU"
   action 1.3 regexp "CPU utilization for .*" "$_cli_result" result
   action 1.4 if $_regexp_result eq 1
   action 1.5 syslog msg "CPU utilization monitoring: $result"
   action 1.6 else
   action 1.7 puts "Error..."
   action 1.8 end
   action 1.9 cli command "end"

Informacje Janusz Nawrat
Just ordinary man who likes thinking...

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s

TOMASZ WEŁNA

artysta grafik | wykładowca

PRACOWNIA OKO

Szkoła Rysunku Malarstwa i Grafiki DR TOMASZA WEŁNY | KRAKÓW | Plac Matejki 10 | tel 691 81 75 74

Piękno neurobiologii

Blog Jerzego Vetulaniego

Teoria muzyki, zasady muzyki, podstawy muzyki

Teoria muzyki, zasady muzyki, podstawy muzyki - czyli to co każdy amator muzyki wiedzieć powinien :)

Personal Development & Inspirations

Przemyślenia i refleksje, którymi warto się podzielić (blog by Janusz Nawrat)

Business IT Cooperation Platform

Biznes i IT - dwa światy, które muszą współdziałać

%d bloggers like this: