Sem vložte zadání Vaší práce.

Transkript

1 Sem vložte zadání Vaší práce.

2

3 České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů Bakalářská práce Sledování síťových prvků v Národní technické knihovně Pavel Diviš Vedoucí práce: Ing. Václav Jansa 4. května 2012

4

5 Poděkování Rád bych touto cestou poděkoval panu Ing. Václavu Jansovi a Bc. Tomáši Emingerovi za odborné vedení, inspiraci, cenné připomínky a poskytnutý čas při zpracování této bakalářské práce.

6

7 Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle 60 odst. 1 autorského zákona. V Praze dne 4. května

8 České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Pavel Diviš. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Pavel Diviš. Sledování síťových prvků v Národní technické knihovně: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

9 Abstract This Bachelor s thesis anylyzes the current state of monitoring network elements in the National Technical Library and proposal suitable method of monitoring these elements with a focus on SNMP protocol. The key parts of the proposal are implemented into the monitoring system Nagios with Centreon expansion. The work also included documentation of the implemented solution and methodical manual for adding other elements to the monitoring system. Keywords monitoring, NTK, SNMP, Nagios, Centreon, NetFlow Abstrakt Tato bakalářská práce se zabývá analýzou současného stavu sledování síťových prvků v Národní technické knihovně a návrhem vhodného způsobu sledování těchto prvků se zaměřením na protokol SNMP. Klíčové části návrhu jsou implementovány do sledovacího systému Nagios s rozšířením Centreon. Součástí práce je také dokumentace implementovaného řešení a metodický manuál pro přidávání dalších prvků do monitorovacího systému. Klíčová slova sledování, NTK, SNMP, Nagios, Centreon, NetFlow 9

10

11 Obsah Úvod 17 1 Seznámení s NTK Software Hardware Analýza a návrh sledování Radius Wifi Switche Zálohování Záložní zdroje napájení IDS/IPS Multifunkční zařízení Přehled protokolů a nástrojů pro sledování síťových prvků Možnosti sledování Realizace Monitorovací nástroje Přidání hosta a jeho služeb do systému Použité programy a skripty pro získávání informací ze zařízení Sledované prvky Skupiny uživatelů a plán komunikace Dokumentace a metodický manuál Šablony pro služby Šablony pro zařízení Nastavení sledování u jednotlivých zařízení Metodický manuál pro přidání zařízení a služeb do monitorovacího systému

12 Závěr 55 Literatura 57 A Seznam použitých zkratek 61 B Obsah přiloženého CD 63 C Dokumentace skriptů 65 D Digramy struktury šablon 69 E Podrobný metodický manuál 71 E.1 Vytvoření šablony pro služby E.2 Vytvoření šablony pro zařízení E.3 Vytvoření příkazu pro sledování E.4 Přidání zařízení E.5 Vytvoření služby a přiřazení k zařízení E.6 Vytvoření skupiny služeb E.7 Nastavení eskalací E.8 Generování konfiguračního souboru pro nagios

13 Seznam obrázků 2.1 Architektura NetFlow (24) Graf datového toku na portu CORE switche Graf datového toku na portu switche v 5. patře, dílčí rozvodna číslo Graf datového toku na portu wifi controlleru D.1 UML diagram vytvořené struktury šablon pro zařízení D.2 UML diagram vytvořené struktury šablon pro služby E.1 Ukázka vytvoření šablony služby E.2 Ukázka vytvoření šablony zařízení E.3 Ukázka vytvoření šablony zařízení - nastavení závislostí E.4 Ukázka přidání pluginu do Centreonu E.5 Ukázka přidání zařízení do monitorovacího systému E.6 Ukázka přidání zařízení do monitorovacího systému - nastavení závislostí E.7 Ukázka vytvoření služby E.8 Ukázka přidání služby k zařízením E.9 Ukázka vytvoření skupiny služeb E.10 Ukázka nastavení závislostí E.11 Ukázka nastavení závislostí - přiřazení skupin služeb E.12 Ukázka generování konfiguračního souboru pro nagios

14

15 Seznam tabulek 2.1 Formát SNMPv.1 paketu Formát SNMPv.1 PDU Trap Přiřazení zařízení ke skriptům Přiřazení šablon služeb k šablonám pro zařízení Přiřazení šablon zařízení k jednotlivým typům zařízení C.1 check_port C.2 add_port C.3 check_switch_status C.4 Skript check_printer C.5 Skript check_printer_prediction

16

17 Úvod S rostoucí složitostí a velikostí počítačových sítí rostou i požadavky na nepřetržitý dohled nad jejich činností. Nepřetržitý dohled je nezbytný pro jejich dobrou výkonnost, spolehlivost a bezpečnost. Sledování sítě nám umožní její efektivní správu. Data získaná ze sledování nám poskytnou informace o výkonnostních charakteristikách sítě, možných bezpečnostních problémech a také umožní efektivně plánovat budoucí rozvoj sítě. Monitoring nám umožňuje nepřetržitě sledovat vybrané údaje u zvolených zařízení v síti a v případě, že nastane definovaná událost, tak o ní podat zprávu. U rozsáhlých sítí je nasazení monitoringu jediným možným řešením, jak zjistit provozní informace a zajistit spolehlivý chod sítě. Jednotlivá síťová zařízení poskytují nepřeberné množství informací, které jsou pomocí monitoringu konsolidovány do jednoho nebo i více míst v závislosti na velikosti monitorování sítě. K vyhodnocení získaných dat nám slouží monitorovací nástroje. Některé nástroje mají i grafické rozhraní, kde lze upravovat parametry monitorování u jednotlivých zařízení nebo také přidávat, případně odebírat zařízení. Nastavení pomocí grafického rozhraní je výrazně jednodušší než pomocí zdrojových kódů a také nám sníží pravděpodobnost vzniku chybné konfigurace. (19) Před nasazením monitoringu je nutné provést analýzu dané sítě a ujasnit si jaké údaje jsou pro nás důležité a naopak, které nás nezajímají. Jednotlivé údaje lze získat mnoha způsoby, ať již procházením logů, pomocí protokolu SNMP, RMON nebo NetFlow, které jsou poté v monitorovacím nástroji zobrazeny. Monitorovací nástroj v závislosti na počtu měřených hodnot potřebuje ke správné funkčnosti dostatek hardwarových prostředků. Dále je třeba si dát pozor na špatně nastavený monitoring, neboť může neúměrně zvýšit provoz na síti a tím přispět k přetížení sítě, případně monitorovaných zařízení. Ve své bakalářské práci se budu zabývat sledováním síťových prvků v Národní technické knihovně. Práce má pomoci správcům těchto zařízení předcházet problémům v síti, případně na problémy včas upozornit. Také má pomáhat v plánování rozvoje síťové infrastruktury knihovny. První kapitola obsahuje 17

18 Úvod seznámení s prostředím knihovny. Druhá kapitola obsahuje analýzu a návrh sledování vybraných síťových prvků. Třetí kapitola obsahuje částečnou implementaci vybraných síťových prvků do monitorovacího systému. V této kapitole jsou také eskalační scénáře, skupiny uživatelů pro jednotlivá zařízení a plán komunikace v případě nastalé definované události. Kapitola čtvrtá je věnována dokumentaci a pracovním návodům pro navrhované prostředí monitoringu. Celkové zhodnocení práce obsahuje nečíslovaná kapitola závěr. Práce dále obsahuje přílohy, kde je vypracován podrobný metodický manuál pro začleňování nových prvků do monitorovacího systému, dokumentace vytvořených skriptů a diagramy vytvořených struktur šablon. 18

19 Kapitola 1 Seznámení s NTK Národní technická knihovna je hlavní vědeckotechnickou knihovnou v České republice. Její fond je největší českou sbírkou domácích a zahraničních dokumentů z oblasti techniky a aplikovaných přírodních a společenských věd s ní souvisejících. Obsahuje přes 1,2 milionu svazků a tvoří jej knihy, časopisy, vědecké práce, normy, informace o firmách, noviny, a to jak v tištěné, tak v elektronické podobě. V NTK se také nachází kromě vlastního fondu i část fondů Ústřední knihovny ČVUT a Ústřední knihovny VŠCHT. Mezi služby, které může klient využít, patří například výpůjčka knih, meziknihovní služby, zpoplatněné rešeršní služby. Pokud klient vlastní zařízení kompatibilní s wifi sítí v knihovně, má možnost se pomocí tohoto zařízení k této síti připojit. Za poplatek je možné využít tiskových služeb, kde je možnost výběru mezi barevným nebo černobílým tiskem. Přes webový portál mají klienti možnost rezervovat si individuální nebo týmové studovny, případně si pronajmout přednáškový sál a další služby.(16) 1.1 Software Operační systémy a virtualizace Na všech zařízeních určených pro klienty běží operační systém Windows. Na většině serverů v knihovně běží operační systém RedHat verze 5 nebo 6, SLES verze 10 nebo 11, případně Windows server ve verzi 2003 a Pro virtualizaci se aktuálně využívá technologie VMware, XEN, KVM. V současné době se přechází z neudržované platformy VMware na perspektivní XEN a KVM. Přitom je očekávaná konsolidace na technologii KVM v horizontu dvou let. Aktuálně běží přibližně 65 virtualizovaných serverů. 19

20 1. Seznámení s NTK Databáze V současné době se používají dvě centrální databáze, a to Oracle a MS SQL 2008, které běží každá na jiném databázovém stroji. Server db1, na kterém běží databáze Oracle, slouží především pro aplikační server AS, IDM, platební systém, rezervační systém a registrace. Server db2, na němž běží MS SQL 2008, slouží jako databáze pro EKV a řízení budovy. Tiskový systém využívá vlastní PostgreSQL cluster na serverech ts1 a ts DNS služby V knihovně fungují dvě zóny, interní s interními adresami a externí s veřejnými adresami. Pro interní zónu jsou v knihovně dva BIND 1 servery, primární a sekundární. Třetí BIND server je primární pro externí zónu, přičemž jako sekundární server je používán DNS server Cesnetu. Klíčové domény v knihovně jsou techlib.cz, která slouží pro prezentaci knihovny, a ntkcz.cz, na které běží interní servery a služby. Doména ntkcz.cz zároveň slouží i jako dokumentace běžících serverů IDM Z důvodu poskytování více služeb klientům je potřeba údaje o klientech udržovat konzistentní mezi různými systémy. IDM zajišťuje udržování konzistentního stavu mezi databázemi těchto systémů. V případě, že některý systém je pro zápis krátkodobě nedostupný, tak IDM nekonzistenci dat v krátkém časovém horizontu vyřeší samo. V případě delšího výpadku dojde k chybě a je nutný ruční zásah. Při extrémním výpadku, kdy ruční zásah není již možný, dojde ke spuštění rekonciliace. Ta trvá dva dny a dojde při ní k ověření všech dat v připojených systémech.(10) Samba Samba je aplikační cluster, který se skládá ze serverů samba1 a samba2. Samba1 a samba2 jsou plnohodnotnými aktiv/pasiv nódy clusteru. Samba určuje pouze prezentační adresu na aktuálně používaný samba server. Samba slouží k ukládání uživatelských dat, jako doménový kontrolér nebo tisková fronta a je nutná k provozu terminálového řešení. 1 DNS server pro Unix systémy. 20

21 1.2. Hardware 1.2 Hardware SAN V knihovně je SAN 2 síť rozdělena do dvou samostatných fabric, které propojují všechny servery nezávisle se sdíleným centrálním diskovým polem HP EVA Každý server je připojen do obou fabric. Každý fabric je připojen na oba controllery diskového pole. Z každého fabric se využívá vždy pouze jedna cesta. Propojení je ve stavu active blocked, kdy v případě výpadku jedné z cest dojde k použití druhé Servery V knihovně jsou používány dva druhy serverů a to od firmy Hewlet Packard servery řady ProLiant BL a DL. Servery typu DL jsou klasické servery umístitelné do racku. Servery typu BL jsou tzv. blade servery, které jsou umístěné v BladeSystem c7000 Enclosures. Použití blade systému snižuje spotřebu elektrické energie (zvýší se využití výpočetního výkonu na 1 W), systém také udržuje informace o firmwarech a systémech na jednotlivých bladech. Při vložení nového blade do systému dojde k připojení ilo 3 k systému, přes které je daný blade konfigurovatelný. Přes ilo můžeme například nakonfigurovat IP adresu a další. Systém umí předvídat možné chyby v konfiguraci jako je nekompatibilní verze ovladače s instalovaným software na bladu. Vzadu na blade systému je vyveden fibre channel systém pro připojení k SAN síti a prezentace portů ethernetových síťových karet sloužících k připojení systému k síti. (6) Diskové pole Diskové pole HP EVA 6100 je centrálním úložištěm dat pro NTK. Maximální kapacita je 112TB s až 4GB pamětí cache a maximálním datovým tokem 8Gbps. Podporuje připojení přes fibre channel. Disky lze zapojovat do RAIDu.(7) Instalované disky jsou dvou druhů, a to rychlé a pomalé. Diskové pole je k serverům připojeno přes SAN síť. V případě vadného disku ho odpojí, a pokud je to možné, tak data zmigruje na jiný disk a o všem podá zprávu. Aktuálně se vyskytují problémy s dostupností pole při zatížení skupiny pomalých disků za hranicí jejich I/O výkonu Terminály Terminály jsou tzv. tencí klienti. Veškeré operace jsou prováděny vzdáleně a posílány na obrazovku terminálu. Terminály jsou napojeny na rozkládané terminálové servery, které využívají NT doménu. Datové disky a tiskové fronty 2 Storage Area Network je vysokorychlostní síť, obvykle s malým dosahem a slouží k propojení úložných zařízení se servery.(18) 3 Subsystém pro správu blade serverů, přístupný přes webové rozhraní nebo ssh. 21

22 1. Seznámení s NTK poskytuje pro terminály služba Samba. Toto umožňuje efektivní správu systému a nastavení uživatelských práv přístupu. Terminály jsou volně přístupné od 3. do 6. patra budovy, a také v noční studovně, kde je mohou zákazníci knihovny volně používat Infokiosky Kiosky jsou zařízení fungující se systémem Windows. Služby poskytované infokiosky jsou závislé na jejich umístění v knihovně, například infokiosky v 1. NP slouží výhradně k přístupu do portálu NTK pro umožnění předregistrace nových klientů. Ostatní infokiosky lze po přihlášení použít k neomezenému přístupu na internet nebo portálu NTK. Infokiosky jsou zapnuté pouze v provozní době knihovny Další zařízení V knihovně se nachází velké množství dalších zařízení, jako jsou například IP televize, IP telefony, stanice pro automatické výpůjčky a vracení knih a další. 22

23 Kapitola 2 Analýza a návrh sledování 2.1 Radius RADIUS je síťový protokol, který prostřednictvím přístupového serveru nabízí centralizovanou správu přístupu klientů do počítačových sítí. Pracuje na principu klient-server. RADIUS umožňuje uživatelům přístup do sítě na základě AAA architektury (authentication, authorization, accounting). Autentizací se rozumí ověření identity uživatele. Autorizace specifikuje, jaké zdroje v síti mohou ověření uživatelé používat. Accounting neboli účtování zodpovídá za záznam všech činností uživatele. Komunikace probíhá pomocí UDP protokolu na defaultním portu (8) Autentizace probíhá tak, že uživatel pošle žádost o autentizaci klientovi, který zažádá uživatele o zadání identifikačních údajů. Poté klient odešle žádost na radius server, kde dojde k vyhodnocení, zda uživatel vyhovuje podmínkám nastaveným na radius serveru pro přístup do sítě. Pokud není nějaká podmínka splněna, je žádost zamítnuta a přístup do sítě není umožněn. Veškerá komunikace mezi klientem a radius serverem je symetricky šifrována pomocí sdíleného klíče. (17) V knihovně fungují celkem 3 radius servery. Každý radius server má vlastní LDAP 4 databázi, která je synchronizována s hlavní databází. Dále využívají sdílenou mysql databázi s MAC adresami, které mají povolen přístup do sítě. Žádosti od návštěvníků obsluhují dva radius servery a třetí slouží pro testování nových konfigurací. Na třetím radiusu, který aktuálně obsluhuje zaměstnaneckou část budovy, se testuje nová konfigurace, která umožňuje připojení k eduroamu po protokolu 802.1x přes metalické spoje. V případě, že nedojde k ověření k přístupu do eduroamu, spadne port do VLANy 5, která není nikam routovaná. Radius servery pro klienty toto zatím neumožňují, neboť by bylo nutné provést restart všech distribučních switchů v budově. Plánovaný upgrade a rekonfigurace radius serverů proběhne při nejbližší odstávce datového centra NTK. 4 Protokol, určený k správě a uchovávání informací v adresářové struktuře. (20) 5 Virtuální síť. 23

24 2. Analýza a návrh sledování 2.2 Wifi V budově je umístěno 140 wifi AP 6, které jsou řízeny dvojicí controllerů. Při připojení klienta na wifi síť dojde k jeho ověření na RADIUS serveru. Jednotlivá AP jsou napájena ze switchů z dílčích rozvoden pomocí tzv. PoE. 7 Veškerá nastavení AP se provádí přes managment controllerů. Zajistit správný chod Wifi sítě je problematické z důvodu silných zdí a velkého množství regálů s knihami, které pohlcují velké množství vyzařovaného signálu, a rozlehlých otevřených prostor, které naopak umožňují připojení na AP z protější strany budovy. Dalším problémem jsou zde také nekvalitní wifi karty v zařízení klientů, které neumí roaming 8 mezi jednotlivými AP. Analýzou bylo zjištěno, že wifi AP blízko otevřených prostor mají nastavený vysoký vyzařovací výkon (14 db), a proto je možné se na dané AP připojit i ze vzdálených míst, kde je již možnost se připojit na bližší zařízení. Toto lze vyřešit snížením vyzařovacího výkonu nebo případným připojením externí antény s nízkým vyzařovacím výkonem. Dalším problémem je velké množství vysílaných sítí z jednotlivých AP a kritický nedostatek volných vysílacích kanálů pro ně. Běžně se proto stává, že jednotlivé sítě vysílají na stejných kanálech, čímž dochází k rušení a zhoršení propustnosti daných sítí. Vyřešení tohoto problému je komplikované z důvodu omezení standardu pro volné vysílací kanály v indoor pásmu. V současné době se u wifi síti sleduje pouze zda jednotlivá AP a controllery mají možnost komunikovat v síti. Na jednotlivých wifi AP by bylo potřebné sledovat údaje o počtu připojených klientů a také průtok z jednotlivých zařízení, abychom včas zjistili případnou možnost přetížení jednotlivých zařízení. Sledovat tyto údaje na instalovaných prvcích není možné ať již z důvodu, že wifi síť ještě nebyla předána pod plnou správu ICT oddělení knihovny a také proto, že daná zařízení neumí poskytnout požadované údaje. V případě výměny zařízení je třeba zahrnout i požadavky na monitoring do parametrů nových zařízení. U wifi sítí mám tedy jedinou možnost monitorování, a to monitorování datových toků procházejících přes controllery. 2.3 Switche Ethernetové switche jsou pro potřeby této práce rozděleny do tří kategorií. Do první kategorie je zařazen CORE switch, do druhé switche v distribučních rozvodnách umístěných na každém patře a do třetí kategorie switche umístěné v počítačových učebnách a přednáškovém sále. Aktuálně se u switchů kontroluje, zda mají možnost komunikovat v síti. U všech switchů budeme pomocí 6 Přístupový bod k wifi síti. 7 Napájení po datovém síťovém kabelu, bez nutnosti přivést napájecí napětí k přístroji dalším samostatným kabelem. 8 Uživatel se přesune od jednoho přístupového bodu k jinému v rámci téže sítě, bez jeho vědomí. (17) 24

25 2.3. Switche protokolu ICMP kontrolovat, zda odpovídají na zaslanou zprávu a tím určíme zda jsou online CORE switch Core swich je hlavní switch umístěný v hlavní serverovně budovy. Přes něj probíhá veškerá komunikace z vnitřní sítě do internetu a většina vnitřního provozu. Zařízení je typu 3COM 7900E, neboli HP 7500, které se skládá ze dvou fyzických switchů (chassis) a celkem 3 řídících karet. V jednom zařízení jsou dvě karty a ve druhém je pouze jedna. Toto rozdělení je z důvodu požadavku na redundanci na úrovni chassis, zvolené nesymetrické řešení je z důvodu úspory pořizovacích nákladů. Jednotlivá fyzická zařízení jsou propojena pomocí technologie IRF do jednoho virtuálního celku (IRF domény), který se z pohledu okolních zařízení chová jako jeden velký switch a veškeré přepínací a směrovací funkce plně virtualizuje. IRF doména vystupuje pod jednou IP adresou a s jedním konfiguračním souborem. Propojení IRF domény s dalšími zařízeními (switche, servery) lze realizovat distribuovaně pomocí standardní linkové agregace. Odpadá zde nutnost využití a složité konfigurace tradičních protokolů, jako jsou Spaning Tree protokoly. Absence těchto protokolů v síti však neznamená ztrátu vysoké dostupnosti. Naopak, IRF nabízí velmi rychlou konvergenci a případný výpadek linky nebo celého prvku je vyřešen v řádu milisekund. Navíc nedochází k blokaci záložních linek, jako je tomu např. u Spaning Tree protokolu. Všechny linky jsou aktivní a plně využívány, což vede k rozložení zátěže provozu a lepšímu využití výkonu prvků. (5) Core switch provádí přiřazení portu do VLANy, případně do více VLAN, pokud je nastavený jako trunk. Pro připojení do internetu má knihovna dva uplinky, a to přes Fakultu Architektury a Fakultu Strojní ČVUT. Linky jsou řešeny jako active backup. Pro hlavní switch je třeba monitorovat využití paměti a CPU, aby nedocházelo k přetížení. Dalším sledovaným údajem bude informace o jednotlivých portech. Z poskytovaných informací budeme získávat alias portu a průtok dat. Z důvodu připojení přívodu internetu do tohoto switche potřebujeme získat údaj o vytížení obou možných připojení. Tento switch umí také poskytnout informace o provozu na jednotlivých VLANách. Také nás bude zajímat informace o admin a oper statusu portu, který určuje, zda daný port je povolený a zařízení k němu připojené může komunikovat v síti. Dále budeme sledovat zda je na zařízení otevřen port pro ssh připojení, přes které je možné provádět konfiguraci daného zařízení Switche v distribučních rozvodnách Na každém patře se nachází 3 pomocné rozvodny, ve kterých je umístěn switch zajišťující provoz pro danou část patra. Do těchto switchů typu 3COM 5500G, 25

26 2. Analýza a návrh sledování neboli HP 5500G. jsou připojeny zásuvky ze stolů pro klienty, terminály a také wifi AP, které jsou z nich napájeny pomocí tzv. PoE. Pro tyto zařízení budeme získávat stejné informace jako pro CORE switch. Dalším potřebným údajem bude využívání PoE. Jelikož jsou z těchto switchů napájeny wifi AP, musíme zajistit, že daná zařízení budou mít zajištěn dostatečný zdroj energie pro svou správnou činnost. Aktuální limit switchů je 300 W Switche v učebnách a přednáškovém sále V knihovně se nachází seminární učebny, které jsou vybavené počítači, proto v každé této učebně je umístěn malý 8+1 portový switch značky 3COM 4210, neboli HP 4210, který zajišťuje síťové spojení pro danou učebnu. Jelikož se tyto switche nachází v dřevěné skříňce u hlavního počítače učebny, dochází často při zavření skříňky k přehřívání zařízení. Pro režii přednáškového sálu a studio interní IPTV 9 byly doplněny 16+2 portové switche 3COM 4210, neboli HP Na těchto zařízeních je pro nás důležitým údajem jejich provozní teplota. Bohužel aktuálně instalovaná zařízení tento údaj neumí poskytnout pomocí SNMP, ať již dotazu nebo trapu. Proto budeme pouze kontrolovat, zda zařízení odpovídají na icmp paket. 2.4 Zálohování Zálohování probíhá pomocí nástroje HP Data Protector, který umožňuje realtime zálohování. Zálohy se ukládají v komprimovaném stavu na páskové mechaniky. Pásková mechanika udržuje informace o připojených páskách a rozvrhuje ukládání dat. Vyhledávání malých souborů v záloze je z důvodu lineárního přístupu zdlouhavé. 2.5 Záložní zdroje napájení Záložní napájení NTK se skládá z dieselového agregátu a UPS. UPS, která se nachází v hlavní serverovně slouží k udržení zařízení v chodu při krátkodobých výpadcích. UPS značky Liebert model NX1000, patří mezi aktivní záložní prvky. Při plném vytížení UPS (tj. 100kVA) je schopná dodávat energii po dobu 15 minut. Při současném zaplnění serverovny je schopná dodávat energii po dobu cca minut (dle náročnosti výpočetních operací servery prováděnými). V případě výpadku delšího než 20 sekund dojde k automatickému zapnutí dieselových agregátů, které jsou schopné dodávat napájení po dobu několika hodin. (23) 26 9 Internet Protocol Television je systém, kde se pomocí IP protokolu šíří digitální televize.

27 2.6. IDS/IPS Máme několik možností jak UPS monitorovat. Základní řešení, které je dodávané výrobcem zařízení je pomocí dodávaného programu, který získává z řídících karet požadované údaje, které jsou dostupné pomocí webového rozhraní. Zařízení také umožňuje sledování pomocí SNMP protokolu, ať již odpovědí na zaslané dotazy, tak i pomocí SNMP trapu. Pro tento typ zařízení se nejvíce hodí sledování pomocí SNMP trapů. 2.6 IDS/IPS IDS/IPS je systém, který slouží k analýze datových toků, detekuje pokusy o útok a je schopen dle nastavené konfigurace aktivně reagovat, tzn. útoku zabránit. Řešení IDS/IPS může být jak softwarové, tak i hardwarové. V knihovně je implementován hardwarový systém HP TippingPoint 2400e a HP Tipping- Point Security Management System. TippingPoint SMS je schopen monitorovat, konfigurovat, diagnostikovat a reportovat zprávy až pro 1000 Tipping- Point systémů. Přístup k tomuto zařízení je pomocí zabezpečeného Java klienta. TippingPoint 2400e je systém, který provádí analýzu paketů ve vrstvě ISO OSI modelu. V systému jsou nadefinovány filtry, podle kterých dochází k rozpoznání případného útoku. Jelikož je přítomen jak TippingPoint IPS, tak i TippingPoint Security Management Systém, je možné v případě nalezení napadeného zařízení nebo pokusu o útok korelovat události a podnikat akce jako například pokročilá oznámení nebo dokonce komunikovat se switchem, aby vypnul přístup obtěžujícího zařízení k síti. Tento proces je automatizovaný pomocí souboru předem stanovených instrukcí v TippingPoint SMS, které vzájemně reagují s infrastrukturou, aby identifikovaly obtěžujícího hostitele a podnikly vhodnou karanténní akci. Zařízení je schopné analyzovat provoz 2,4 Gbitps a až spojení. Systém umí analyzovat i šifrované spojení, kde heslo pro šifrování je uložené v plaintextu v paměti zařízení. Analýza paketu průchodem IDS/IPS zařízením není zjistitelná. V případě poruchy zařízení dojde k přepnutí bypassu na externím relé panelu. Provoz pak obtéká zařízení bez jakékoli analýzy. (1) Systém umožňuje dvě základní reakce na zjištěnou událost: (15) pasivní reakce IDS upozorní administrátora, že je třeba jeho zásah. Mezi možnosti, jak ho informovat, patří například zaslání zprávy na konzoli, poslání zprávy na , sms, pager, případně informovat pomocí snmp nebo zápisu do syslogu aktivní reakce IPS podnikne aktivní kroky ke zpomalení nebo přerušení činnosti útočníka. Reakcí může být upravení filtrovacích pravidel na firewallu, ukončení spojení s útočníkem nebo například zasláním paketu s příznakem RST, případně úplné zablokování provozu na dané zařízení 27

28 2. Analýza a návrh sledování Metody detekce anomálií jsou založené především na: (15) detekci průniku přes protokolové anomálie, kdy se jedná o analýzu protokolu. IPS analyzuje datový tok a vyhledává odchylky od standardní komunikace popsané v RFC dokumentech. Tento typ detekce je vhodný na odhalení útoku přetečení bufferu, například FTP bounce útok detekci průniku pomocí nalezení specifického vzorku komunikace. Tato metoda je založená na prohledávání obsahu paketů na známé typy útoků. Pro větší efektivitu se využívají regulární výrazy detekce průniku backdoor, kdy probíhá analýza komunikace v síti a porovnává se s provozem, který je administrátorem povolený. Výhody hardwarového řešení rychlost v inline režimu, kde se analyzuje více vrstev ISO OSI modelu zároveň možnost provozu na vysokorychlostním ethernetu nezávislost na operačním systému vysoká dostupnost a spolehlivost (15) Zajímavou iniciativou je aktivita firmy TippingPoint (divize firmy Hewlett Packard) nazvaná Zero Day Initiative. Tato firma kupuje od veřejnosti (odborníci na bezpečnost, hackeři a další) ještě nereportované (a tedy oficiálně neopravené) chyby (zero day) v zabezpečení různých softwarů a hardwarových zařízení, ochranu před zneužitím těchto chyb implementuje ve svých IDS/IPS zařízeních a tím zajišťuje svým zákazníkům nejaktuálnější možnou ochranu. (26) Zařízení aktuálně spravuje externí firma, která se stará o správný chod zařízení. Nastavení monitoringu na tomto zařízení je možné přes software dodávaný od výrobce. V programu lze nastavit způsob a možnosti poskytování zpráv o nastalých událostech. Nejzajímavější údaj je informace o počtu a typu odhalených útoků. 2.7 Multifunkční zařízení V NTK se nachází multifunkční zařízení pro barevný a černobílý tisk, skenování a kopírování. Pro zadání tisku může klient využít počítače pro veřejnost nebo svůj vlastní počítač. Po zaslání úlohy k tisku dojde k jejímu uložení do 28

29 2.8. Přehled protokolů a nástrojů pro sledování síťových prvků tiskové fronty na samba serveru, kde je do jejího úplného přijmutí. Poté je ihned odeslána na safeq tiskový server, kde je uložena až do vyzvednutí. U multifunkčních zařízení nás bude zajímat zbývající kapacita toneru. Dalším potřebným údajem je zbývající množství toneru v zásobnících zařízení. Všechny tyto údaje můžeme získat pomocí SNMP protokolu. Nyní jsou multifunkční zařízení monitorovány přímo z helpdesku pomocí programu Webjetadmin. 2.8 Přehled protokolů a nástrojů pro sledování síťových prvků Protokol SNMP SNMP protokol začal vznikat už v roce 1988, jako reakce na potřebu efektivní správy počítačových sítí. První verze protokolu vznikla v roce 1989 a o rok později byla uznána institucí IAB jako standard pro internet, který byl definován v dokumentu RFC V první verzi protokolu byla implementována ochrana pomocí hesla, která se později ukázala jako nevyhovující, protože heslo bylo možno zjistit analyzováním paketů. V této verzi byly implementovány příkazy get, get next, set a trap. Brzy po vydání první verze se stal protokol jednou z nejrozšířenější metod pro správu počítačových sítí. V roce 1993 vznikl SNMP protokol verze 2, který rozšířil první verzi o příkaz getbulk, inform, report, ale stále ještě používal ochranu pomocí hesla - community string. Upravená verze protokolu s názvem v2c vznikla v roce Z důvodu nedostatečného zabezpečení předchozích verzí vznikl SNMP verze 3, který podporuje šifrovaný přenos dat. (18) SNMP byl navržen jako asynchronní, transakčně orientovaný protokol založený na architektuře klient-server. Programové vybavení pro komunikaci se nazývá SNMP manažer a SNMP agent. SNMP manažer posílá požadavky snmp agentům a očekává od nich odpověď, kterou poté zpracuje. Agent běží na síťovém zařízení a odpovídá na dotazy manažera. Výjimkou jsou pouze trapy, které zasílá agent asynchronně v momentu, kdy nastane definovaná událost, jako je výpadek elektrického proudu nebo překročení provozní teploty. Tento agent neustále monitoruje zařízení a sbírá informace o jeho dostupných funkcích a stavech. Informace o zařízení spolu s metadaty jsou organizovány do hierarchie popsané pomocí MIB. Je to hierarchická, stromově uspořádaná, objektová databáze, která je tvořena jednotlivými OID řetězci. OID je řetězec čísel a znaků, které jsou odděleny tečkou. Každý objekt zařízení má svůj OID řetězec, přes který je možné se na něj pomocí snmp odkazovat. MIB tabulky k jednotlivým zařízením jsou volně ke stažení na stránkách výrobců. Dnes je standardní verze MIB-II definována v RFC 1213.(2) (3) 29

30 2. Analýza a návrh sledování Version Tabulka 2.1: Formát SNMPv.1 paketu (11) Community string Request ID version verze snmp protokolu Error status Error index Variable bindings (OID:value) request ID přiřazuje požadavky s odpověďmi error status indikuje chybu a její typ error index přiřazuje chybu dané proměnné z pole variable bindings Variable bindings obsahuje vlastní data SNMP PDU, přiřazuje daným proměnným jejich aktuální hodnoty (vyjma Get a GetNext příkazů) Tabulka 2.2: Formát SNMPv.1 PDU Trap (11) Enterprise Agent address Generic trap type Specific trap code Time stamp Variable bindings enterprise identifikuje typ objektu, který vygeneroval trap agent address adresa objektu, který vygeneroval trap generic trap typ identifikuje typ trapu specific trap code identifikuje kód trapu time stamp čas mezi poslední reinicializací sítě a vygenerováním trapu variable bindings seznam proměnných, které obsahují relevantní informace k danému trapu Základní operace v SNMP: 30 get request získání vybrané hodnoty pomocí OID get-next-request umožňuje získat informace o objektech v MIB bez znalosti jejich přesných jmen, umožňuje postupné procházení celým hierarchickým stromem set-request nastaví hodnotu vybraného objektu, zabezpečeno community stringem trap zasílá agent pokud dojde ke specifikované události, je na manažerovi, aby asynchronní událost zpracoval

31 2.8. Přehled protokolů a nástrojů pro sledování síťových prvků (18) get-response odpověď na dotaz manažera. Odpověď obsahuje i dotaz, protože protokol nezajišťuje souvislost mezi dotazem a odpovědí get-bulk součást SNMP v. 2. Nahrazuje několik dotazů get-next inform součást SNMP v. 2. Slouží k výměně trap informací mezi více manažery Typy SNMP objektů SNMP objekty mohou být v zásadě dvou typů - skalární hodnoty a tabulky. Objekty typu skalár mohou nabývat pouze jednoduché nestrukturované hodnoty. Jedná se o několik typů: (18) Integer jednoduché celé číslo s velikostí 32 bitů Counter nezáporný integer, který se zvětšuje, až do maximální hodnoty (2 32 1), poté začíná znovu od nuly. Používá se zejména na počítání zajímavých událostí v systému Gauge nezáporný integer, jehož hodnota může vzrůstat i klesat, nikdy nemůže překročit maximální hodnotu (2 32 1) TimeTicks nezáporný integer reprezentující v setinách sekundy čas od jisté doby modulo (2 32 1). Může být použit k vyjádření doby chodu nějakého zařízení od jeho zapnutí IpAddress 32 bitová IP adresa Protokol RMON Z důvodu omezených možností použití protokolu SNMP v rozsáhlých sítích byl v roce 1991 uveden protokol sloužící pro vzdálené monitorování RMON MIB verze 1, která pracovala pouze na první a druhé vrstvě ISO OSI modelu. Protokol představuje soubor statistických, diagnostických a analytických skupin informací. O monitorování se starají vzdálená zařízení, sondy, sloužící pro sběr informací přímo ze sítě. Sondy mohou být součástí síťových zařízení nebo to mohou být samostatná zařízení. Oproti SNMP sondy nečekají na dotaz a proaktivně předem zasílají získané informace klientovi. Tím lze efektivněji využít šířku pásma a lépe reagovat na události v síti. Sondy jsou autonomně rozmístěny v segmentech LAN a podávají zprávu o definovaných událostech 31

32 2. Analýza a návrh sledování v síti. Aktuálně používaná druhá verze RMON byla zavedena v roce 1997 a oproti první verzi umožňovala sběr dat i z vyšších vrstev ISO OSI modelu. V aktuální verzi RMON je definováno 9 základních skupin objektů MIB pro ethernet. (25) Objekty RMONv2: (18) statistika (statistics) statistiky o provozu a chybách na síti historie (history) časový vývoj získaných údajů pro možnost analýzy poplašná hlášení (alarms) slouží k nastavení prahových hodnot, při jejichž překročení dojde ke generování poplašných zpráv stanice (hosts) obsahuje statistiky pro jednotlivé hosty stanice top (host TopN) informace pro vybrané hosty dle zvolené statistické hodnoty matice ( Traffic Matrix) sledování vzájemného provozu mezi páry zařízení (podle MAC adres) filtr (Filters) výběr paketů dle filtrovacích parametrů zachytávání paketů (Packet Capture) umožňuje zachytávání paketů podle zvolených kritérií a provádět definované akce události (Events) zajišťuje vyslání poplašných zpráv a provádění akcí na jejich základě Token Ring využívá již zmíněné skupiny a další čtyři, které jsou uvedeny níže: (18) 32 stanice sítě Token Ring statistiky a informace o stanici v lokálním kruhu pořadí stanic na síti zaznamenává pořadí stanic v kruhu konfigurace stanic na síti konfigurace nebo případné odpojení stanice od sítě source routing statistické informace o cestě paketu k cílové stanici

33 2.8. Přehled protokolů a nástrojů pro sledování síťových prvků NetFlow NetFlow je otevřený protokol vyvinutý společností Cisco Systems. Protokol monitoruje provoz v síti pomocí IP toků. Umožňuje správcům získávat v reálném nebo téměř reálném čase informace o provozu na síti. Získané informace lze využít k detekci různých útoků, plánování budoucího rozvoje sítě nebo k vytváření statistik provozu na síti. NetFlow neslouží ke sledování stavu daného prvku v síti, ale analyzuje datové toky, které jím procházejí. V knihovně by bylo možné nastavit jako NetFlow exportér CORE switch a získávat tak informace o datových tocích na daném prvku sítě.(4) NetFlow architektura Typicky se NetFlow architektura skládá z několika exportérů, kteří se na dané lince starají o analýzu datových toků a zasílají statistiky do sběrného bodu tzv. NetFlow kolektoru. Jeden NetFlow kolektor může zpracovávat data z několika exportérů. NetFlow kolektor uloží získané statistiky do databáze, ze které je pak zpracovává aplikace, která umožňuje zpracovat data do libovolné podoby, ať již tabulky či grafy. (24) Možnosti využití NetFlow (9) Monitorování sítí můžeme získat přehled o datových tocích v daném bodě sítě, také můžeme sledovat datový tok z jednotlivých zařízení Monitorování aplikací a uživatelů pomocí získaných dat můžeme sledovat datový tok jednotlivých uživatelů, jaké využívají protokoly nebo také sledovat chování jednotlivých aplikací, které komunikují v síti Plánování sítí pomocí dat získaných pomocí NetFlow můžeme efektivně plunovat budoucí rozvoj sítě, neboť máme přesný přehled o využití sítě Bezpečnostní analýza díky tomu, že sledování probíhá v reálném čase, můžeme dostávat hlášení při překročení prahových hodnot nastavených pro daný provoz na síti Vyúčtování provozu ze získaných dat můžeme vytvářet libovolné statistiky, a tak mít přehled jak o aktuálním využití sítě, tak i o využití sítě v minulosti Data Mining uložená data mohou sloužit pro pozdější analýzu. Můžeme zjistit jaké služby a aplikace jsou využívány danými uživateli a další možné statistky 33

34 2. Analýza a návrh sledování Obrázek 2.1: Architektura NetFlow (24) Arpwatch Sledování pomocí nástroje Arpwatch využívá pro svou činnost arp protokol a snmp protokol. Slouží k odhalení stejných IP adres v síti. V první fázi si Arpwatch vytvoří databázi, která obsahuje záznamy ve tvaru IP adresa - MAC adresa a v případě, že dojde ke změně v tomto přiřazení, tak o tom podá zprávu. Arpwatch také umí získávat informace pomocí snmp ze vzdálených prvků. Tento způsob sledování umožní sledovat provoz zařízení na síti a v případě bezpečnostního problému nám umožní vyhledat příslušnou MAC adresu prvku s nestandardní činností.(22) 2.9 Možnosti sledování Aktivní Při aktivním sledování se posílají do sítě testovací pakety a v jiném místě sítě se přijímají. Toto umožňuje měřit například zpoždění jednotlivých paketů, ztrátovost v sítích, a také propustnost. Nevýhodou aktivního monitorování je zvýšení zátěže sítě, neboť například testování propustnosti intenzivním datovým tokem může ovlivnit provoz pro ostatní uživatele. Charakteristika datového 34

35 2.9. Možnosti sledování toku měřeného pomocí našich testovacích paketů se od charakteristiky uživatelského datového toku může lišit. Také je například obtížné měřit aktivně ztrátovost paketů v síti, neboť ta velmi závisí na objemu a dynamice provozu, které jsou u skutečného provozu uživatelů velmi odlišné od testovacích paketů. (21) Pasivní Při pasivním monitorování se do sítě neposílají žádné testovací pakety, ale vyhodnocují se časové a objemové charakteristiky provozu. Při pasivním monitorování nedochází k ovlivňování uživatelského provozu a můžeme tak sledovat charakteristiky, které jsou pomocí aktivního monitorování nezjistitelné. A to například jaký je objem a dynamika volné kapacity v síti, které aplikace uživatelů mají největší nároky na kapacitu sítě a další. (21) 35

36

37 Kapitola 3 Realizace Jako vstupní bod mi posloužil předchozí monitorovací systém. Import konfigurace bohužel nebyl zcela úspěšný, a tak bylo nutné ručně doplnit jednotlivé hosty, služby a závislosti mezi nimi. Dále probíhala analýza stavu infrastruktury NTK, kde bylo cílem provést doplnění monitorovacího systému o nová zařízení, případně nepoužívaná z něj odstranit. Analýza také zahrnovala zjištění možností monitorování jednotlivých zařízení a služeb u nich. Po aktualizaci hostů, služeb a závislostí do monitorovacího systému jsme mohli vygenerovat pomocí pluginu Nagviz novou mapu, která je umístěna v příloze. 3.1 Monitorovací nástroje Nagios Nagios je populární monitorovací nástroj, který je vyvíjen pro OS linux, lze ho však spustit na většině UNnix systémech. Je to robustní systém, který pomocí pluginů umožňuje sledovat libovolná zařízení libovolným protokolem. Při monitorování lze na definované události služeb reagovat upozorněním správci systému nebo provést předem zvolenou akci, například restart problematické služby. Podávat zprávu lze pomocí u, sms, pageru nebo jiným způsobem implementovaným například pomocí pluginu. Konfigurace probíhá pomocí textových souborů. (14) Významné vlastnosti nagiosu: sledování aktuálních síťových stavů prostřednictvím webového rozhraní, zobrazení historií událostí, logovacích souborů monitorování síťových služeb jako SMTP, POP3, HTTP, NNTP, PING a dalších 37

38 3. Realizace monitorování hostitelských zdrojů jako vytíženost procesoru, využití disku a pamětí, běžící procesy, logovací soubory monitorování činitelů vnějšího prostředí jako je například teplota jednoduché použití pluginů, které umožňuje snadno vyvinout své vlastní kontrolní skripty a postupy možnost rozesílání upozornění různým kontaktním skupinám uchování stavu zařízení a služeb i po restartu schopnost vizualizace problému přes www rozhraní jednoduché autorizační schéma, které umožňuje definovat to, co který uživatel přes webové rozhraní uvidí a co ne možnost navázání stavu na nějakou akci, například při výpadku DHCP serveru restart démona či celého serveru (13) Pro přenos dat se využívá UDP protokol. Odchozí port pro dotaz je generován automaticky a zasílán na port 161 zařízení, kde je spuštěn agent. Trapy jsou odesílány z libovolného portu na port 162 manažera. Komunikace pomocí UDP protokolu je velmi rychlá, ale protokol neřeší doručení paketů, takže může docházet ke ztrátě informací. Tento problém je vyřešen v SNMP od verze 2, která v sobě zahrnuje kontrolu doručení jednotlivých paketů. (14) Architektura Hlavní částí Nagiosu je démon nagios. Po spuštění démona dojde k načtení konfigurace ze souborů a zahájení monitorování. Informace o výsledcích testů se ukládají do MYSQL databáze. Příkazy pro sledování jsou načítány z konfiguračních souborů. Pro zobrazení informací o stavu slouží webové rozhraní, které je realizováno pomocí CGI skriptů. CGI skripty zpracují informace o sledování a zobrazí je v HTML podobě. (14) Centreon Centreon je grafická webová nadstavba nad monitorovacím systémem nagios. Přes webové rozhraní je možné provádět kompletní konfiguraci nagiosu. Konfigurační data ukládá do MYSQL databáze, proto nám umožňuje snadné přidání velkého množství služeb nebo hostů přímo přes databázi. Získaná data ze zařízení ukládá do RRD databáze. Centreon rozšiřuje funkce nagiosu o eskalační scénáře, které jsou pro mě nejdůležitějším rozšířením a které budu ve své práci potřebovat. Pro centreon existuje velké množství pluginů, které rozšiřují jeho 38

39 3.2. Přidání hosta a jeho služeb do systému funkci jako například nagviz, který vytvoří z existujících hostů a závislostí mapu. Výběr a integrace vhodného monitorovacího nástroje byly cílem bakalářské práce Jakuba Lázničky.(12) 3.2 Přidání hosta a jeho služeb do systému Při volbě vhodné metody přidávání hostů a služeb do systému jsem se snažil zvolit nejjednodušší a nejlépe udržovatelnou metodu. Při volbě jsem zohlednil požadavky zadavatele, kde byl požadavek na jednoduché přidávání hosta a služeb k němu a dále pak možnost upravovat služby pro jednotlivé hosty Skupina zařízení První možností pro přidávání hostů a služeb je tzv. host grupa, která umožňuje zařízení sloučit do skupin a k jednotlivým skupinám přiřadit službu. Tato metoda je sice jednoduchá a přehledná, ale neumožňuje úpravu služby pro vybraného hosta ve skupině. Další nevýhodou je, že u jednotlivých služeb nejdou nastavit závislosti. Toto řešení umožňuje přiřadit hosta do více skupin, a tak ušetřit na vytváření šablon, ale zároveň při větším počtu skupin a hostů se stává nepřehledné Služba pro více hostů Další možností je přiřazení jedné služby více hostům, přičemž hosti nemusí být v žádné skupině. U tohoto řešení je v případě úpravy konfigurace společné služby pro jednoho klienta nutné nejprve danou službu zduplikovat, a poté ji danému hostu přiřadit a upravit. Tím se stává řešení velmi nepřehledné Šablona Při použití metody založené na šablonách nepřiřazujeme jednotlivé služby k hostům, ale k šablonám. Pokud přidáváme nový typ zařízení do systému, je nutné pro něj nejprve vytvořit příslušné šablony. Tato metoda je náročnější na přípravu šablon, ale při opětovném použití se nám čas vložený do přípravy vrátí. Při volbě šablon máme možnost využít nastavení závislostí mezi jednotlivými šablonami. Dědičnost nám umožní nastavit parametry pro ostatní šablony v jednom místě (rodičovská šablona). Jelikož můžeme zkombinovat šablony pro hosty se šablonami pro služby, tak máme možnost zvolit automatické vytvoření služeb z daných šablon pro hosta. Služby jsou vytvořené přímo pro konkrétní hosty, a tak máme možnost upravovat parametry služby pouze pro zvoleného hosta. V šabloně máme možnost nastavení četnosti spouštění skriptů nebo způsobu upozornění. Více v kapitole dokumentace

40 3. Realizace 3.3 Použité programy a skripty pro získávání informací ze zařízení V této kapitole popíši jednotlivé skripty pro sledování a k nim možnosti konfigurace. Skripty, které jsem vytvořil jsou v jazyce Python nebo Bash. Ostatní skripty, které jsem ve své práci využil jsou psané v jazyce Perl nebo C, a jsou volně ke stažení ze stránek pluginů nagiosu. Před nasazením skriptů je třeba doinstalovat balíčky, ať již pro jazyk Python balíček umožňující přístup k mysql databázi nebo některé balíčky pro Perl. Z důvodu údržby a aktualizace systému bylo požadováno zadavatelem pro případ instalace využití standardních repozitářů daného systému Skript check_port Tento skript jsem napsal v jazyce Bash a slouží ke sledování datových toků na jednotlivých portech zařízení. Také umožňuje sledovat stav (oper/admin) jednotlivých portů. Jelikož informace o datovém toku na portu jsou datového typu COUNTER a ne GAUGE, tak pro každý port vytvářím dočasný soubor pro uložení předchozích hodnot a času měření. Místo vytváření dočasných souborů je konfigurovatelné ve skriptu, jako defaultní hodnotu jsem zvolil /tmp/swtiche. Proto pro správné fungování skriptu je třeba zajistit právo zápisu do těchto složek. Ve skriptu jsem také musel ošetřit možnost přetečení čítačů, neboť jejich maximální hodnota je V první verzi tento skript využíval pro získání požadovaných hodnot o jednom portu pět snmpget dotazů. Toto řešení způsobovalo velké přetížení serveru již pro cca 300 sledovaných portů. Jelikož testovací server aktuálně běží v clusteru s primárním DNS prezentační domény techlib.cz, došlo při přetížení testovacího prostředí ke zhoršení odezvy na primárním DNS serveru. Druhá verze skriptu již získává veškeré údaje o portu pomocí jednoho snmpget dotazu. Tento skript jsem testoval spolu s kolegou, který měl na starosti integraci monitorovacího systému do prostředí NTK, aby nedocházelo k přetížení serveru. Skript průměruje datový tok za uplynulé časové období od posledního měření. Dále umožňuje pomocí parametrů nastavit sledování stavu oper a admin statusu portu a v případě, že se status nebude rovnat požadované hodnotě předané v parametru, tak skončit s příslušným návratovým kódem, který se projeví v systému stavem u služby warning. Pro více informací viz. C.1. V případě budoucí úpravy skriptu bych navrhl řešení, kde se budou stahovat zvolené části MIB tabulky pomocí příkazu snmpwalk do lokálního souboru, ze kterého poté budou načítány informace o jednotlivých portech (datový tok, oper a admin status). Toto řešení však v sobě zahrnuje některé problémy, které je třeba vyřešit. Například je nutné vyřešit zamezení přístupu k souboru v době stahování MIB tabulky (trvá cca 10 sekund), dále také zajistit vždy 40

41 3.3. Použité programy a skripty pro získávání informací ze zařízení aktuální data tak, aby nedošlo k opětovnému použití údajů již zanesených do monitorovacího systému. Tento skript je využíván u těchto zařízení: switche u těchto zařízení je primárně používán pro sledování datových toků na jednotlivých portech. Také umožňuje sledovat datový tok na jednotlivých VLANách u CORE switche. Sledování oper a admin statusu je využíváno u portů pro uplink do internetu u CORE switche. wifi controllery u controllerů sleduji datový tok na jednotlivých portech. Toto je jediná možnost, jak sledovat využití wifi sítě v knihovně Skript add_port Skript jsem napsal pro skriptovací jazyk Bash a slouží pro přidání sledovaných portů do monitorovacího systému. Tento skript se konfiguruje pomocí parametrů. Pro správný chod skriptu je třeba zajistit přístup k databázi centreonu. Skript vytváří insert příkazy, které přidají port do monitorovacího systému a nastaví hodnoty z parametrů nebo použije defaultní hodnoty. Pro popisky, které se zobrazují v centreonu, jsem zvolil název portů získaných ze zařízení. Tento skript stahuje veškeré informace ze zařízení pomocí příkazu snmpwalk, kde se stáhnou vybrané části MIB tabulky. Při přidávání jednotlivých služeb do monitorovacího systému jsem musel zjistit všechny tabulky a databáze, do kterých se zapíše nová služba (port) tak, jako když je přidaná přes standardní webové rozhraní. Pokud bych přidal prvek pouze do tabulky sertvices, tak by daná služba nešla editovat. Všechny tabulky v databázi centreonu, do kterých je zapsána nová služba jsem zjistil pomocí porovnání exportu databáze před a po vložení prvku (portu) do monitorovacího systému. Porovnání jsem provedl příkazem cmp, který vypsal rozdílné řádky v obou exportovaných souborech. Pro více informací viz. C.2. Základní vlastnosti, které lze pomocí parametrů nastavit: service template zvolená service template, která se použije pro nastavení služby jaký příkaz spouštět slouží k nastavení příkazu, který bude dané službě přiřazen parametr pro příkaz jaký parametr se má předat příkazu ke spuštění popisek popisek, pod kterým je služba zobrazována v centreonu nastavit aktivní stav nastavuje zda se bude ihned provádět monitoring nebo bude daná service pouze přidána do monitorovacího systému 41

42 3. Realizace Skript check_printer Pro tento skript jsem použil skriptovací jazyk Bash. Slouží ke sledování stavu toneru a papíru v tiskárnách. Údaje jsou získávány pomocí protokolu SNMP, konkrétně příkazu snmpwalk. Pomocí argumentů můžeme určit jaké barvy se mají sledovat, případně u nich nastavit prahové hodnoty pro návratový kód warning/critical. Pro více informací viz. C Skript check_printer_prediction Tento skript je doplňkový ke skriptu check_printer a slouží k výpočtu predikce dojití toneru v tiskárně. Skript jsem napsal v jazyce python, který mi umožňoval lepší použití matematických operací. Pro výpočet predikce dojití toneru využívám data získaná ze skriptu check_printer. Data jsou uložena v databázi RRD, kde příslušný datový soubor je pojmenován pomocí id, které je v mysql databázi centstorage tabulce matrics. K příslušnému id se lze dostat z databáze centreon, kde získáme pod IP adresy id daného multifunkčního zařízení z tabulky hosts, poté v databázi centstorage v tabulce host_services získáme id do tabulky matrics pomocí SELECT dotazu, kde budeme porovnávat id hosta a id služby. V tabulce matrics podle porovnání prvku id_host_services zjistíme id matrics, pod kterým je uložen daný datový soubor. Pro získání dat z příslušného souboru RRD databáze použijeme příkaz rrdtool fetch. Z databáze potřebuji data za posledních 14 dní monitorování. Získaná data jsem rozdělil na dvě části, první obsahuje data za poslední dva dny sledování a druhá část zbylá data. Data jsem rozdělil na dvě části z důvodu, že první část obsahuje aktuálnější data, a proto budou mít ve výpočtu větší váhu než druhá část. Obě skupiny dat dále dělím na úseky se stejným intervalem měření a počítám průměrný koeficient úbytku. Dokumentace skriptu viz. C Skript check_switch_status Skript jsem napsal ve skriptovacím jazyce Bash. Slouží k zjišťování informací o využité paměti, vytížení procesoru, stavu větráků a napájecích zdrojů u switchů. Skript získává informace ze zařízení pomocí příkazu snmpwalk. Tento příkaz je použit z důvodu virtualizace některých switchů, kde jednotlivé virtuální switche jsou složeny z více jednotek (unit), kde každá jednotka poskytuje dané údaje. Při kontrole se provádí kontrola na překročení warning a critical hodnoty u každé jednotky, ale výsledné údaje o sledovaných hodnotách jsou vztaženy na celé virtuální zařízení. Pro více informací viz. C Program check_ssh Tento program je napsán v jazyce C, který je dostupný v základní sadě skriptů pro nagios/centreon. SSH představuje základní možnost konfigurace jednotlivých zařízení. Kontrola probíhá tak, že se provede pokus o otevření anonym- 42

43 3.4. Sledované prvky ního spojení a kontrolou se sleduje, zda došlo ke kontaktu ssh daemona na cílovém zařízení Skript check_http Skript pro kontrolu http spojení jsem získal ze stránek pluginů pro nagios. Skript provádí kontrolu tak, že se pokusí zobrazit webovou stránku na daném zařízení, a poté zkontroluje návratový kód Program check_icmp Tento program je napsaný v jazyce C a patří do základní sady skriptů u nagiosu. Skript ověří zda je ICMP aktivní na vzdáleném stroji a zobrazí základní údaje jako je procento ztráty paketu a čas. Pokud dané zařízení neodpovídá (ztrátovost 100 %), tak skončí se stavem critical Skript check_centreon_snmp_consumable Tento skript je obsažen v základní sadě skriptů v centreonu. Tento skript je univerzální pro získání hodnoty pomocí snmp z daného zařízení. Požadovaná hodnota (OID) se předá do skriptu pomocí parametru. U skriptu je možnost zvolit v jakém datovém typu má hodnoty zpracovávat (COUN- TER 10 /GAUGE 11 ). Dále je možnost nastavit prahové hodnoty warning a critical pro sledovanou službu a další možná nastavení Další použité programy a skripty check_telnet kontroluje možnost přihlášení pomocí telnetu check_https kontroluje https 3.4 Sledované prvky U každého prvku, který je v monitorovacím systému, sleduji údaj o dostupnosti v síti pomocí skriptu check_icmp V případě že zařízení neodpovídá, tak u daného zařízení dojde ke změně statusu z UP na DOWN, a pokud jsou nadefinované události, tak dojde k jejich spuštění. 10 Aktuální hodnota čítače nezávislá na čase kontroly a přetečení čítače 11 Průměrný přírůstek od minulého měření 43

44 3. Realizace Switche CORE switch U tohoto zařízení je skript check_port používán primárně pro sledování datových toků na jednotlivých portech. Také umožňuje sledovat datový tok na jednotlivých VLANách. Sledování oper a admin statusu je primárně využíváno u portů pro uplink do internetu. Jednotlivé porty switche byly přidány do monitorovacího systému pomocí skriptu add_port Obrázek 3.1: Graf datového toku na portu CORE switche Switche v distribučních rozvodnách Pro sledování systémových informací o zařízení využívám skript check_switch_status Datové toky na jednotlivých portech sleduji pomocí skriptu check_port U těchto switchů také sleduji využítí tzv. PoE. Maximální hodnota je 300 W. Pro sledování používám skript check_centreon_snmp_consumable Obrázek 3.2: Graf datového toku na portu switche v 5. patře, dílčí rozvodna číslo 2. Switche v učebnách a přednáškovém sále U těchto zařízení sleduji informace o jednotlivých portech pomocí skriptu check_port Jednotlivé porty jsem přidal do monitorovacího systému 44

45 3.4. Sledované prvky pomocí skriptu add_port Aktuálně není sledování portů zapnuté, neboť dané informace pro nás nejsou nyní zajímavé. V případě problému lze sledování portů zapnout nastavením stavu active u jednotlivých portů v monitorovacím systému. Fiber switche u blade systému Skript check_port je použit u těchto zařízení primárně pro hlídání, zda jsou jednotlivé porty nastaveny na požadovaný stav zadaný pomocí parametrů. Kontrola portu je první stupeň kontroly cest směrem od serverů k datovému poli a umožňuje včas reagovat na případný problém, zatímco je používána záložní cesta (každý server je připojen do obou fabric). Dále u zařízení sleduji datový tok na jednotlivých portech a možnost přihlášení na ssh server Wifi AP Do monitorovacího systému jsem přidal wifi AP z důvodu zjištění zda mají zařízení možnost komunikace v síti. Toto kontroluji pomocí skriptu check_icpm Controllery Datový tok na jednotlivých portech controllerů sleduji pomocí skriptu check_port, pomocí kterého získáme přehled o využití wifi sítě. Jednotlivé porty byly přidány do monitorovacího systému pomocí skriptu add_port Dalším sledovaným údajem je kontrola otevřeného ssh portu pomocí skriptu check_ssh Z důvodu možnosti konfigurace zařízení pomocí webového rozhraní kontroluji http spojení na port 80 pomocí skriptu check_http Obrázek 3.3: Graf datového toku na portu wifi controlleru 45

46 3. Realizace UPS Pro sledování stavu UPS jsem zvolil snmp trapy. Tímto řešením nebude docházet ke zbytečnému zatěžování monitorovacího systému opakovaným zasíláním dotazů na stav zařízení. V případě změny stavu zařízení dojde k odeslání zprávy (trapu) do monitorovacího systému, kde v případě definované události dojde k jejímu provedení. Při zvolení této metody bylo nutné v první řadě nalézt a importovat do systému MIB tabulku se snmp trapy pro dané zařízení. Tuto tabulku jsem získal ze stránek výrobce. Dále bylo třeba vytvořit pro dané zařízení službu a k ní přiřadit zpracování vybraných snmp trapů. Dále jsem musel zajistit otevřený port s číslem 162, na který jsou defaultně snmp trapy posílány Multifunkčí zařízení Pro sledování stavu toneru a papíru v multifunkčních zařízeních využívám skript check_printer Dále u tiskáren sleduji predikci dojití toneru, sledování probíhá pomocí skriptu check_printer_prediction Další informace o stavu, v jakém se tiskárna nachází, zjišťuji pomocí skriptu check_hpjd SafeQ terminály SafeQ terminály jsem přídal do monitorovacího systému z důvodu sledování, zda mohou komunikovat v síti. 3.5 Skupiny uživatelů a plán komunikace Skupiny uživatelů V kontextu této práce se uživateli rozumí lidé, kteří mají právo a schopnosti pro správu jednotlivých druhů zařízení. Jednotlivé skupiny a uživatele v nich jsem vytvořil podle informací získaných od vedoucího ICT oddělení. 46 ntk-ict-head do této skupiny patří vedoucí směny ICT oddělení ntk-ict-manager do této skupiny patří ředitel ICT oddělení ntk-network-wifi skupina obsahuje uživatele, kteří spravují wifi síť ntk-network v této skupině jsou uživatelé, kteří se starají o síťové prvky mimo ty, které spravují ostatní skupiny ntk-print-device skupina uživatelů starající se o tiskárnu z pohledu konfigurace tiskáren

47 3.5. Skupiny uživatelů a plán komunikace ntk-helpdesk uživatelům v této skupině jsou zasílány zprávy o stavu spotřebního materiálu v tiskárnách ntk-ids/ips skupina uživatelů, kteří spravují IDS/IPS ntk-ups do skupiny patří uživatelé mající na starost správný chod UPS Plán komunikace Pro zasílání notifikací o stavu jednotlivých zařízení jsem zvolil metodu pomocí u. Pro odesílání zpráv se využívá interní SMTP server. Pro plán komunikace, neboli eskalace, jsem rozdělil jednotlivé skupiny uživatelů do 3 kategorií. Do první kategorie patří skupiny uživatelů, které se starají o jednotlivé typy zařízení. Konkrétně to jsou skupiny ntk-network-wifi, ntk-network, ntk-printdevice, ntk-ids/ips, ntk-ups. Do druhé kategorie patří skupina uživatelů ve skupině ntk-ict-head a ve třetí kategorii je skupina uživatelů ntk-ict-manager. V případě, že v systému nastane definovaná událost, při které se má zaslat zpráva správcům daného zařízení, se nejprve zašle zpráva skupině uživatelů z první kategorie. Zasílání zprávy se bude opakovat po dvou hodinách. V případě, že nedojde do 12 hodin k řešení situace, je o události informována skupina uživatelů z druhé kategorie. Zprávy o události se budou zasílat opět každé dvě hodiny této skupině, až do vyřešení dané události. Pokud ani po informování druhé skupiny nedojde k vyřešení této události, dojde po 12 hodinách od zaslání první zprávy o události uživatelům ze druhé skupiny k informování uživatelů ze třetí kategorie. Časové okamžiky mezi zasíláním zpráv mezi kategoriemi skupin uživatelů jsou pouze orientační. Monitorovací systém umožňuje nastavit změnu skupiny pro zasílání zpráv o událostech pouze podle počtu již zaslaných zpráv předchozí skupině. V systému nelze určit přesné časy pro spouštění služeb, proto ani časové okamžiky mezi zaslanými zprávami nejsou přesně dané. 47

48 3. Realizace Název skriptu nebo programu check_port add_port check_switch_status check_ssh check_http check_icmp check_printer check_printer_prediction check_centreon_snmp_consumable Tabulka 3.1: Přiřazení zařízení ke skriptům Typ zařízení CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému wifi controllery CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému wifi controllery CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému multifunkční zařízení multifunkční zařízení CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému wifi controllery CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému wifi controllery CORE switch switche v distribučních rozvodnách switche v učebnách a přednáškovém sále fiber switche u blade systému wifi AP systému multifunkční zařízení UPS SafeQ terminály IDS wifi controllery switche v distribučních rozvodnách 48

49 Kapitola 4 Dokumentace a metodický manuál 4.1 Šablony pro služby Pro jednotlivé typy zařízení jsem vytvořil hierarchickou strukturu šablon. Struktura je vidět na diagramu v příloze D. U každého zařízení se šablony dělí na šablony status a service, kde jsou nastaveny parametry pro kontrolu u jednotlivých typů služeb. Název každé šablony v sobě nese názvy rodičovských šablon, až ke generické šabloně Popis jednotlivých koncových šablon služeb pro switche ntk-switch-service šablona, ve které jsou nataveny obecné parametry pro kontrolu služeb u zařízení ntk-switch-service-http šablona má přiřazen příkaz pro kontrolu http spojení (pokusí se stáhnout úvodní index stránku) ntk-switch-service-ssh u této šablony je přiřazen příkaz pro kontrolu ssh spojení ntk-switch-service-telnet u této šablony je přiřazen příkaz pro kontrolu telnet spojení ntk-switch-status tato šablona slouží pro nastavení obecných parametrů pro status šablony, které od ní dědí ntk-switch-status-port slouží k vytvoření služby pro sledování portu ntk-switch-status-poe slouží k vytvoření služby pro sledování využití PoE 49

50 4. Dokumentace a metodický manuál ntk-switch-status-health_all šablona slouží k vytvoření služby pro sledování stavu využití paměti, vytížení procesoru, funkčnost napájecích zdrojů a větráků ntk-switch-status-health tato šablona slouží k vytvoření služby pro sledování stavu využití paměti, vytížení procesoru, funkčnost napájecích zdrojů Popis jednotlivých koncových šablon služeb pro wifi ntk-wifi-service šablona, ve které jsou nastaveny obecné parametry pro kontrolu služeb u zařízení ntk-wifi-service-http tato šablona má přiřazen příkaz pro kontrolu http spojení (pokusí se stáhnout úvodní index stránku) ntk-wifi-service-ssh u šablony je přiřazen příkaz pro kontrolu ssh spojení ntk-wifi-service-https u této šablony je přiřazen příkaz pro kontrolu https spojení ntk-wifi-status šablona slouží pro natavení obecných parametrů pro status šablony, které od ní dědí. Také vytváří službu pro sledování stavu zařízení ntk-wifi-status-port tato šablona slouží k vytvoření služby pro sledování portu Popis jednotlivých koncových šablon služeb pro multifunkční zařízení 50 ntk-print-status tato šablona slouží pro nastavení obecných parametrů pro status šablony, které od ní dědí ntk-print-status-toner tato šablona přiřazuje zařízení službu pro kontrolu stavu barev ntk-print-status-days u této šablony je přiřazen příkaz pro výpočet predikce dojití toneru ntk-print-status-info slouží k vytvoření služby pro sledování informací o stavu tiskárny

51 4.2. Šablony pro zařízení 4.2 Šablony pro zařízení V monitorovacím systému jsem vytvořil hierarchickou strukturu šablon D pro jednotlivé typy zařízení. Jednotlivé šablony dědí základní službu na kontrolu, zda jsou připojeny do sítě, od šablony s názvem generic-host. Jednotlivé šablony pro zařízení mají přiřazeny šablony pro služby. Tyto služby jsou automaticky vytvořeny při přiřazení šablony k zařízení. Název šablony specifikuje typ, pro která zařízení je určena. Přiřazení jednotlivých šablon služeb k šablonám zařízení je uvedeno v následující tabulce. Tabulka 4.1: Přiřazení šablon služeb k šablonám pro zařízení Název šablony zařízení Přiřazené šablony služeb ntk-switch-service-http ntk-switch-service-ssh ntk-switch-hp7500 ntk-switch-service-telnet ntk-switch-service-health_all ntk-print-sq - ntk-switch-service-http ntk-switch-service-ssh ntk-switch-hp55xx+poe ntk-switch-service-telnet ntk-switch-service-poe ntk-switch-service-health_all ntk-switch-service-http ntk-switch-service-ssh ntk-switch-42xx ntk-switch-service-telnet ntk-switch-service-health ntk-switch-service-http ntk-switch-service-ssh ntk-switch-hp55xx ntk-switch-service-telnet ntk-switch-service-health_all ntk-wifi-service-ssh ntk-wifi-controller ntk-wifi-service-https ntk-wifi-service-http ntk-wifi-ap - ntk-ups - ntk-print-status-info ntk-print-device ntk-print-status-toner ntk-switch-service-ssh ntk-switch-fiber ntk-switch-service-http 51

52 4. Dokumentace a metodický manuál 4.3 Nastavení sledování u jednotlivých zařízení U zařízení rozlišujeme dva typy služeb. Do první skupiny patří služby, které se vytvoří automaticky při přiřazení dané šablony k zařízení a druhá skupina, kdy se dané služby musí přidat ručně, případně pomocí skriptu Přehled přiřazení šablon zařízení k jednotlivým typům prvků Tabulka 4.2: Přiřazení šablon zařízení k jednotlivým typům zařízení Skupina zařízení Přiřazená šablona CORE switch ntk-switch-hp7500 switche v distribučních rozvodnách s PoE ntk-switch-hp55xx+poe switche v distribučních rozvodnách bez PoE ntk-switch-hp55xx switche v učebnách a přednáškovém sále ntk-switch-42xx wifi controllery ntk-wifi-controller fiber switche u blade systému ntk-switch-fiber multifunkční zařízení ntk-print-device UPS ntk-ups wifi AP ntk-wifi-ap Ručně nastavené služby Tyto služby se vytvářejí a přidávají přímo zvolenému zařízení UPS UPS se monitoruje pomocí SNMP trapů. Pro snmp trapy je připravena šablona pro danou službu pod názvem generic-snmp-trap, která vytvoří u zařízení službu s názvem SNMP_trap. Dále je nutné upravit tuto vytvořenou službu přímo u zařízení a to tak, že jí v záložce Relations přiřadíme specifické trapy, které má zachytávat a zpracovávat Sledování portů u jednotlivých zařízení Pro přidání služby na sledování informací a datovém toku na portu jsem připravil v monitorovacím systému šablonu. Šablona se jmenuje ntk-port a nastavuje obecné parametry pro sledování portu. Při přidávání této služby k zařízení je třeba vytvořit danou službu, nastavit šablonu a přiřadit daný příkaz, který je pod názvem check_port a nastavit mu příslušné parametry, jako je ID portu a další. Pro přidání lze také použít skript add_port. 52

53 4.4. Metodický manuál pro přidání zařízení a služeb do monitorovacího systému 4.4 Metodický manuál pro přidání zařízení a služeb do monitorovacího systému 1. podle typu zařízení zjistíme, zda již daný typ máme v systému 2. pokud podobné zařízení nemáme, vytvoříme hierarchické struktury šablon a) vytvoříme hierarchickou strukturu šablon pro služby E.1 b) vytvoříme hierarchickou strukturu šablon pro zařízení, nastavíme v šablonách základní údaje pro sledování a přiřadíme šablony služeb E.2 3. pokud je třeba, vytvoříme příkaz pro sledování E.3 4. přidáme dané zařízení do systému, nastavíme u něj základní parametry pro sledování a přiřadíme šablony E.4 5. pokud je třeba, tak vytvoříme další služby (mimo základní služby nastavované pomocí šablony pro zařízení) a přiřadíme je k zařízení E.5 6. jednotlivé služby přiřadíme do existujících skupin služeb nebo dané skupiny vytvoříme E.6 7. nastavíme eskalace E.7 8. vygenerujeme zdrojové soubory a restartujeme nagios E.8 53

54

55 Závěr Cílem této práce bylo provést analýzu současného stavu sledování síťových prvků, navrhnout vhodný způsob sledování a implementovat klíčové části návrhu do sledovacího systému. K implementovanému řešení vypracovat dokumentaci a metodický manuál pro přidávání dalších prvků do sledovacího systému. Cíl práce byl splněn, byla provedena analýza současného stavu sledování síťových prvků a návrh realizace sledování. Do sledovacího systému byly implementovány klíčové části návrhu. Pro realizaci sledování byly připraveny potřebné skripty. V systému byla vytvořena struktura šablon umožňující snadné přidávání dalších zařízení a služeb a vytvořeny komunikační skupiny umožňující zasílat při definovaných stavech zařízení zprávy přímo jejich správcům. Byla vypracována dokumentace implementovaného řešení a metodické manuály pro přidávání dalších prvků a služeb do monitorovacího systému. Navržený a implementovaný způsob sledování síťových prvků ve sledovacím systému Nagios s rozšířením Centreon byl plně otestován v připraveném testovacím prostředí s operačním systémem CentOS. Pro implementaci prvků do sledovacího systému bylo třeba získat oprávnění k velkému množství produkčních zařízení. Při realizaci se vyskytovaly problémy se zastaralou dokumentací, která často neodpovídala aktuálnímu stavu sítě. Další problém, který bylo třeba vyřešit, bylo přetěžování testovacího prostředí, z důvodu vysokého počtu SNMP dotazů ve skriptu pro sledování stavu a datových toků na portech u jednotlivých zařízení. Tento problém byl vyřešen použitím jediného SNMP dotazu pro získání všech potřebných údajů. Pro nastavení kompletního sledování je třeba do monitorovacího systému doplnit zbývající zařízení (síťové prvky, servery) a nastavit k nim sledování příslušných služeb. Systém je pak třeba průběžně udržovat a aktualizovat, aby mohl plnit svůj účel. Věřím, že výsledky této bakalářské práce usnadní správu a dohled nad síťovými prvky v Národní technické knihovně a poskytnou cenné informace jak pro správce těchto zařízení, tak i pro budoucí rozvoj sítě. 55

56

57 Literatura (1) Actinet Informační systémy s.r.o. U Bulhara 3: Úvod do IDS/IPS. [cit ]. Dostupné z WWW: < bezpecnost_informacnich_technologii/l19/cl25/st1/j1/uvod_ do_ids/ips.html> (2) Bouška, P.: SNMP - Simple Network Management Protocol. [cit ]. Dostupné z WWW: < snmp-simple-network-management-protocol> (3) DiNicolo, D.: SNMP Commands: Get, GetNext, Set, Trap, GetBulk, and Inform. [cit ]. Dostupné z WWW: < 2000trainers.com/ccda-study-guide/snmp-commands> (4) Hewlett Packard: HP 7500 Switch Series. [cit ]. Dostupné z WWW: < HP_7500_Switch_Series/index.aspx> (5) Hewlett Packard: HP IRF virtualizace síťových prvků. [cit ]. Dostupné z WWW: < hp-irf-virtualizace-sitovych-prvku.html> (6) Hewlett Packard: HP ProLiant BL460c Server Blade. [cit ]. Dostupné z WWW: < quickspecs/12518_div/12518_div.pdf> (7) Hewlett Packard: HP StorageWorks 4100/6100/8100 Enterprise Virtual Arrays. [cit ]. Dostupné z WWW: < hp.com/products/quickspecs/12745_div/12745_div.pdf> (8) IBM s.r.o.: Build a RADIUS server on Linux. [cit ]. Dostupné z WWW: < l-radius> 57

58 Literatura (9) Ipswitch, Inc: Netflow Monitoring and Analyzer WhatsUp Flow Publisher. [cit ]. Dostupné z WWW: <http: // flow-publisher/> (10) Jansa, V.: Čtenář, jeho elektronická identita a služby knihovny. [cit ]. Dostupné z WWW: < podstranka.php?id=51&idm=0&prm1=99&prm2=1&prm3=4173> (11) Klaška, L.: Formát SNMP zpráv. [cit ]. Dostupné z WWW: < Format-SNMP-zprav > (12) Láznička, J.: Integrace monitorovacího systému ICT infrastruktury v prostředí Národní technické knihovny: Bakalářská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, (13) Max Devaine: Nagios + Centreon + MySQL - instalace a základní konfigurace. [cit ]. Dostupné z WWW: < nagios-plus-centreon-plus-mysql-instalace-a-zakladni-konfigurace> (14) Nagios Enterprises: Nagios. [cit ]. Dostupné z WWW: <http: // (15) Northcutt, S.: Bezpečnost počítačových sítí Velká kniha. Brno: Computer Press, (16) Národní technická knihovna: Národní technická knihovna. [cit ]. Dostupné z WWW: < (17) Pužmanová, R.: Bezpečnost bezdrátové komunikace. Jak zabezpečit Wi- Fi, Bluetooth, GPRS či 3G. Brno: Computer Press, (18) Pužmanová, R.: Moderní komunikační sítě od A do Z. Brno: Computer Press, (19) Rott, M.: Správa a monitorování lokálních počítačových sítí. [cit ]. Dostupné z WWW: < sprava-a-monitorovani-lokalnich-pocitacovych-siti-11630> (20) Štěpán, L.: LDAP (Lightweight Directory Access Protocol). [cit ]. Dostupné z WWW: < referaty/2011-jaro/ut/ldap.html> (21) Ubik, S.: Trendy v monitorování vysokorychlostních pocítacových sítí. [cit ]. Dostupné z WWW: < publications/articles/sdel_tech.pdf> 58

59 Literatura (22) Wikipedia: arpwatch. [cit ]. Dostupné z WWW: < en.wikipedia.org/wiki/arpwatch> (23) Wikipedia: IPTV. [cit ]. Dostupné z WWW: < wikipedia.org/wiki/iptv> (24) Wikipedia: NetFlow. [cit ]. Dostupné z WWW: < wikipedia.org/wiki/file:newnetflowapproach.png> (25) Wikipedia: RMON. [cit ]. Dostupné z WWW: < wikipedia.org/wiki/rmon> (26) Zero Day Initiative: Zero Day Initiative. [cit ]. Dostupné z WWW: < 59

60

61 Příloha A Seznam použitých zkratek AP Access point AS Aplikační server BIND Berkeley Internet Name Domain CGI Common Gateway Interface CPU Central Processing Unit ČVUT České vysoké učení technické DNS Hierarchický systém doménových jmen (Domain Name System) EKV Elektronická kontrola vstupu FTP File Transfer Protocol HTTP Hypertext Transfer Protocol HP Hewlett Packard IAB Internet Architecture Board ICMP Internet Control Message Protocol IDM Identity Manager IDS Intrusion Detection Systems ilo Integrated Lights-Out IP Internet Protocol IPS Intrusion Prevention System IPTV Internet Protocol Television 61

62 A. Seznam použitých zkratek IRF Intelligent Resilient Framework LDAP Lightweight Directory Access Protocol MIB Management Information Base NT New Technology NTK Národní technická knihovna NTP Network Time Protocol OID Object ID OSI Open Systems Interconnection PING Packet InterNet Groper PoE Power over Ethernet POP3 Post Office Protocol 3 RFC Request for Comments RMON Remote Monitor RRD Round Robin Databases RST Reset SAN Storage area network SLES SUSE Linux Enterprise Server SNMP Simple Network Management Protocol TCP Transmission Control Protocol UDP User Datagram Protocol UPS Uninterruptible Power Supply VLAN Virtual Local Area Network VŠCHT Vysoká škola chemicko-technologická v Praze 62

63 Příloha B Obsah přiloženého CD readme.txt...stručný popis obsahu CD src impl... vytvořené skripty thesis... zdrojová forma práce ve formátu L A TEX graphs...grafy z Centreonu text... text práce divispa2_2012.pdf... text práce ve formátu PDF divispa2_2012.ps... text práce ve formátu PS 63

64

65 Příloha C Dokumentace skriptů Tabulka C.1: Sleduje datový tok a status portu Název Parametry Návratové hodnoty H IP adresa 0 OK check_port A kontrola, zda je 1 warning port aktivní o port ID v MIB tabulce 2 critical 3 unknown Tabulka C.2: Přidává porty zařízení do testovacího prostředí Název Parametry Návratové hodnoty I IP adresa 0 OK add_port O OID tabulky 1 warning s porty c community string 2 critical s šablona pro 3 unknown službu e zapnout službu u uživatel pro přístup do databáze 65

66 C. Dokumentace skriptů Tabulka C.3: Sleduje využití systémových prostředků switche Název Parametry Návratové hodnoty H IP adresa 0 OK check_switch_- S community string 1 warning status T zvolené testy 2 critical [m-paměť,cprocesor,fvětráky,p-zdroje] f warning hodnota pro větráky 3 unknown F critical hodnota pro větráky p warning hodnota pro napájení P critical hodnota pro napájení m warning hodnota pro paměť M critical hodnota pro paměť c warning hodnota pro procesor C critical hodnota pro procesor 66

67 Tabulka C.4: Sleduje stav toneru a papíru Název Parametry Návratové hodnoty H IP adresa 0 OK check_printer S community string 1 warning T testovat 2 critical [black,yellow,- magenta,cyan,- paper] b warning hodnota pro černou barvu 3 unknown B critical hodnota pro černou barvu c warning hodnota pro modrou barvu C critical hodnota pro modrou barvu y warning hodnota pro žlutou barvu Y critical hodnota pro žlutou barvu m warning hodnota pro purpurovou barvu M critical hodnota pro purpurovou barvu p warning hodnota pro stav papíru P critical hodnota pro stav papíru 67

68 C. Dokumentace skriptů Tabulka C.5: Sleduje datový tok a status portu Název Parametry Návratové hodnoty H IP adresa 0 OK check_printer_prediction S community string 1 warning w prahová hodnota 2 critical pro warning stav c prahová hodnota 3 unknown pro stav critical T Pro jakou barvu se bude predikce počítat 68

69 Příloha D Digramy struktury šablon ntk -switch-fiber ge neric -host ntk -switch-hp750 0 ntk -switch ntk -switch-hp55xx+poe ntk -switch-hp55xx ntk ntk -UPS ntk -wifi-controlle r ntk -wfi ntk -wfi-ap ntk-print ntk -print-dev ice Obrázek D.1: UML diagram vytvořené struktury šablon pro zařízení 69

70 D. Digramy struktury šablon ntk -switch-s tatus -hea lth ntk -switch-s tatus -poe ntk -switch-s tatus ntk -switch-s tatus -hea lth_a ll ntk -switch-s tatus -port ntk -switch ntk -switch-s erv ic es-s sh ntk -switch-s erv ic e ntk -switch-s erv ic e-http ntk -switch-s erv ic e-telnet ntk ntk -wifi-serv ice-http ntk -wifi-serv ice ntk -wifi-serv ice-s sh ntk -wifi-serv ice-https ntk -wifi ntk -wifi-status ntk -wifi-status-port ntk-print-status-info ntk-print-status ntk-print-status-toner ntk-print ntk-print-status-days Obrázek D.2: UML diagram vytvořené struktury šablon pro služby 70

71 Příloha E Podrobný metodický manuál E.1 Vytvoření šablony pro služby Postup pro vytvoření: Povinné parametry: 1. nastavíme zkratku názvu šablony Alias 2. nastavíme název šablony Service Template Name Další nastavení: 1. nastavení rodičovské šablony Service Template Model 2. nastavíme, kdy bude probíhat kontrola Check Period 3. nastavíme příkaz kontroly Check Command 4. nastavíme další parametry pro sledování Max Check Attempts, Normal Check Interval, Retry Check Interval 71

72 E. Podrobný metodický manuál Obrázek E.1: Ukázka vytvoření šablony služby E.2 Vytvoření šablony pro zařízení Postup pro vytvoření: 1. nastavíme název šablony Host Template Name a zkratku Alias 2. pokud je, tak zvolíme rodičovskou šablonu Host Parallel Templates Další nastavení: 1. nastavíme, kdy bude probíhat kontrola Check Period 2. nastavíme příkaz kontroly zařízení Check Command 3. nastavíme další parametry pro sledování Max Check Attempts, Normal Check Interval, Retry Check Interval 4. v záložce Relations přiřadíme k šabloně zařízení šablony služeb, které se budou automaticky vytvářet při přiřazení šablony k zařízení 72

73 E.3. Vytvoření příkazu pro sledování Obrázek E.2: Ukázka vytvoření šablony zařízení Obrázek E.3: Ukázka vytvoření šablony zařízení - nastavení závislostí E.3 Vytvoření příkazu pro sledování Nastavíme: 1. Command Name název příkazu, pod kterým se zobrazí v Centreonu 73

74 E. Podrobný metodický manuál 2. Command Line nastavení spouštění skriptu a jeho parametrů 3. popíšeme argumenty Describe Arguments 4. zvolíme šablonu pro graf Graph Template Obrázek E.4: Ukázka přidání pluginu do Centreonu E.4 Přidání zařízení Postup pro přidání: 1. zadat jméno zařízení Host Name a zkratku Alias 2. nastavíme IP adresu nebo DNS jméno zařízení IP Address/DNS 3. přiřadíme šablonu pro zařízení Host Template 4. zatrhneme Create Services Linked to the Template too, které určujě, že dojde k vytvoření služeb nastavených v šablonách 5. pokud je třeba, upravíme další konfigurační parametry, jako nastavení odpovědných lidí, kterým se zasílá informace o stavu zařízení, dále typ událostí pro které se generují událost a další 6. v záložce Relations nastavíme prvky, ke kterým je zařízení připojeno Parent Hosts a prvky, které jsou připojeny k tomuto zařízení Child Hosts 74

75 E.5. Vytvoření služby a přiřazení k zařízení Obrázek E.5: Ukázka přidání zařízení do monitorovacího systému Obrázek E.6: Ukázka přidání zařízení do monitorovacího systému - nastavení závislostí E.5 Vytvoření služby a přiřazení k zařízení Povinné parametry: 1. zadáme název služby Description 2. přiřadíme danou službu k zařízení Linked with Hosts v záložce Relations Povinné parametry, pokud nejsou zděděny z šablony: 75

76 E. Podrobný metodický manuál 1. nastavíme dobu, kdy je služba aktivní Check period 2. zvolíme příslušný příkaz, který bude spouštěn Check Command 3. nastavíme čas, ve kterém při normálním stavu služby dojde k opakování spouštění příkazu Max Check Attempts 4. nastavíme interval pro opakování kontrol při OK stavu služby Normal Check Interval 5. nastavíme dobu opakování pokusu o sledování v případě předchozího stavu jiného než OK Retry Check Interval 6. určíme, při jakých událostech zasílat upozornění Notification Type Obrázek E.7: Ukázka vytvoření služby 76

77 E.6. Vytvoření skupiny služeb Obrázek E.8: Ukázka přidání služby k zařízením E.6 Vytvoření skupiny služeb Postup vytvoření: 1. zadáme název skupiny Service Group Name 2. napíšeme krátký popis skupiny Description 3. přiřadíme jednotlivé služby ze zařízeních do této skupiny Linked Host Service Obrázek E.9: Ukázka vytvoření skupiny služeb 77

78 E. Podrobný metodický manuál E.7 Nastavení eskalací Postup vytvoření: 1. zadáme název eskalace Escalation Name 2. nastavíme základní údaje pro eskalace, kolik kontrol, dobu mezi opakováními a další 3. zadáme čas, ve který je eskalace aktivní Escalation Period 4. nastavíme pro jaké události u zařízení má být zasílání zpráv o událostech aktivní Hosts Escalation Options 5. nastavíme pro jaké události u služeb má být zasílání o událostech aktivní Services Escalation Options 6. nastavíme skupiny uživatelů, kterým se budou zprávy o událostech zasílat Linked Contact Groups 7. v záložce Servicegroups Escalation zvolíme skupiny služeb, u kterých bude eskalace aktivní (skupiny jsme již vytvořili) 8. nastavit eskalace můžeme i pro samotné služby u jednotlivých zařízení Obrázek E.10: Ukázka nastavení závislostí 78

79 E.8. Generování konfiguračního souboru pro nagios Obrázek E.11: Ukázka nastavení závislostí - přiřazení skupin služeb E.8 Generování konfiguračního souboru pro nagios 1. zatrhneme Move Export Files, Restart Nagios 2. klikneme na Export Obrázek E.12: Ukázka generování konfiguračního souboru pro nagios 79