Monitorovanie Informačných systémov

Úvod

Najdôležitejšími technológiami v súčasnej dobe sú technológie pre zber, spracovanie a distribúcia informácií. S príchodom počítačových technológii a hlavne s masívnym rozvojom počítačových sietí sa výrazne zrýchlil nie len zber a spracovanie informácií akéhokoľvek druhu ale hlavne aj ich distribúcia. Používanie informačných systémov (IS) v tomto smere je veľmi výrazné a rozšírené. Nezávisiac od spôsobu ich implementovania veľmi dôležitou úlohou pri prevádzke IS je ich monitorovanie a správa vychádzajúca z tohto monitorovania, či už z hľadiska vylepšovania služieb, stability alebo bezpečnosti.

Vychádzajúc zo zamerania sa na najbežnejšie prostriedky na ktorých sa stavajú IS sme dospeli k záveru, že bude zaujímavé spracovať informácie o log súboroch, ktoré nám poskytnú prehľad o informáciách ktoré sú v nich zapísané a prípadnej možnosti ich využitia pri monitorovaní daného systému a podnikaní následných krokov pri otázke správy a hlavne bezpečnosti systému.

1 Bližšia špecifikácia zadania

Tento semestrálny projekt nadväzuje na semestrálny projekt SP1 s rovnomenným názvom Monitorovanie informačných systémov, ktorý sa zaoberal analýzou prostriedkov na budovanie IS a ich log súborov.

Cieľom tohto semestrálneho projektu je analýza a spracovanie log súborov MySQL^? servera a vytvorenie aplikácie, ktorá by dokázala spracovať informácie z týchto log súborov, ktoré je potrebné rozanalyzovať a ďalej spracovať. Výsledná aplikácia by mala zbierať informácie z log súborov, vytvárať z nich toky vhodné pre ďalšie spracovanie v IPFIX protokole. Nazbierané údaje by ďalej mali slúžiť na utvorenie si predstavy o prevádzke v IS a na základe týchto informácii odhadnúť prípadný útok alebo nechcené používanie IS a zvýšiť tak bezpečnosť systému.

2 Analýza problematiky

2.1 Log

Log je názov pre záznam alebo súbor záznamov (často súbory s príponou .log), ktoré si niektoré programy vytvárajú pre ukladanie informácií o svojej činnosti a behu. Logy slúžia pri spätnej analýze k rozpoznávaniu, či došlo k nejakej chybe a ak áno, tak pomáhajú určiť, k akej chybe došlo a prečo. Môžu tiež obsahovať informácie o tom, ako a kým bola daná aplikácia či služba využívaná (napríklad z akej IP adresy bolo pristupované k WWW serveru).

Niektoré programy umožňujú logovanie vypnúť, zapnúť alebo nastaviť jeho úroveň, tzn. určiť, koľko a ktoré detailné informácie sa do logov majú ukladať.

2.2 Server Log

Server log je súbor (alebo niekoľko súborov) automaticky tvorených a udržiavaných serverom.

Typickým príkladom je web server log, ktorý obsahuje históriu požadovaných stránok. W3C zachováva štandardný formát pre web server log súbory, ale existujú aj iné vhodné formáty. Nové záznamy sa pridávajú na koniec súboru. Štandardne sa zapisujú informácie o požiadavke, klientova IP adresa, dátum/čas, požadovaná stránka, HTTP kód, poskytnuté bajty, používateľov agent. Tieto dáta môžu byť skombinované do jedného súboru, alebo separované do osobitných logov, napríklad access log, error log, alebo referrer log. Server logy však obyčajne nezbierajú informácie viazané na užívateľa.

Tieto súbory obyčajne nie sú verejne prístupné užívateľom na Internete, iba webmasterom alebo iným administratívnym osobám. Štatistická analýza server logov môže byť použitá na preverovanie prevádzky podľa času, dňa, požadovateľa služby, alebo užívateľovho agenta. Efektívna administrácia webovej stránky, adekvátny hosting a vyladenie výkonnosti môžu byť ošetrené práve pri analýze web server logov.

2.3 MySQL^? Server Log-y

MySQL^? má niekoľko typov logov, ktoré nám môžu pomôcť zistiť, čo sa deje v mysqld:

Typ log súboru		Informácie zapísané v log súbore
error log		Problémy so štartovaním, behom alebo zastavením mysqld
general query log		Spojenia zriadené klientom a príkazy prijaté od klienta
binary log		Všetky príkazy, ktoré menia dáta (taktiež používané na odpovedanie)
slow query log		Všetky požiadavky, ktoré požadujú na ich vykonanie viac času ako long_query_time alebo, ktoré nepoužili indexy

Štandardne sú všetky log súbory vytvorené v dátovom adresári mysqld. Pomocou mysqld môžeme zatvoriť a otvoriť log súbory (alebo v niektorých prípadoch prepnúť na nový log) mazaním logov. Mazanie logov dosiahneme pri zadaní príkazu FLUSH LOGS alebo vykonáme mysqladmin flush-logs alebo mysqladmin refresh. Ak používate MySQL^? replikačné schopnosti, tak podradené replikačné servery sa starajú o ďalšie log súbory nazvané relay logy.

2.3.1 Error Log

Error log súbor obsahuje informácie vyjadrujúce kedy mysqld bolo zapnuté, vypnuté a tiež všetky kritické chyby, ktoré sa vyskytli počas behu servera. Ak mysqld zaznamená tabuľku, ktorá potrebuje byť automaticky kontrolovaná alebo opravovaná, napíše správu do error logu.

Na niektorých operačných systémoch error log obsahuje vyhľadávanie hranice v prípade zlyhania mysqld. Hranica môže byť použitá na zistenie kde mysqld ukončilo svoju činnosť. Keď sa mysqld_safe použije na naštartovanie mysqld a mysqld neočakávane skončí, tak mysqld_safe zaznamená, že potrebuje reštartovať mysqld a napíše o tom správu do error log.

Môžeme si špecifikovať kam má mysqld ukladať error log súbor s voľbou --log-error[=file_name]. Ak nie je zadaný žiaden názov súboru mysqld použije názov host_name.err a súbor zapíše do dátového adresára. Ak zadáme FLUSH LOGS, error log sa premenuje s príponou -old a mysqld vytvorí nový prázdny log súbor. (Ak možnosť --log-error nie je daná, nevyskytne sa žiadne premenovávanie) Ak nešpecifikujeme --log-error, alebo (vo Windows) ak použijeme voľbu --console, chyby sú zapísané do stderr - štandardný chybový výstup. Obyčajne je to váš terminál. Vo Windowse je chybový výstup vždy zapísaný do .err súboru ak --console nie je daná.

Voľba --log-warnings alebo systémová premenná log_warnings sa môže použiť ma riadenie varovných logov do error logu. Defaultná hodnota je enabled (1). Varovné logovanie môže byť zakázané použitím hodnoty 0. Zrušené spojenia nie sú logované do error log iba ak je hodnota väčšia ako 1.

2.3.2 General Query Log

General query log predstavuje všeobecný záznam o tom, čo robí mysqld. Server zapíše informácie do tohto logu, ak sa klient pripojí alebo odpojí, a tiež loguje každý SQL príkaz od klienta. General query log dokáže byť veľmi užitočný ak je podozrenie, že chyba je na klientovi a chceme vedieť čo presne klient poslal mysqld.

Mysqld zapíše príkazy do query log v poradí, v akom ich prijal, čo sa môže líšiť od poradia, v akom sa vykonávali. Takéto logovanie je v kontraste s binary log, v ktorom sa príkazy zapisujú potom ,ako sa vykonali, avšak predtým ako sa odstránil nejaký zámok (lock). (Query log obsahuje všetky príkazy, zatiaľ čo binary log neobsahuje príkazy, ktoré iba selektujú dáta.)

Pre zapnutie general query log, spustite mysqld s voľbou --log[=file_name] alebo -l [file_name]. Ak nie je zadané meno súboru pre --log alebo -l, štandardné meno je host_name.log v dátovom adresári.

Server sa reštartuje ale vymazanie logov nezapríčiní vygenerovanie nového general query log súboru (vymazanie logov ho zatvorí a naspäť otvorí). V Unixe môžete súbor premenovať a vytvoriť nový použitím nasledujúcich príkazov:

shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> cp host_name-old.log backup-directory
shell> rm host_name-old.log

V operačnom systéme Windows, nemôžete premenovať log súbor, pokiaľ ho má server otvorený. Musíte stopnúť server a tak premenovať súbor, následne reštartovať server, aby sa vytvoril nový log súbor.

2.3.3 Binary Log

Binary log obsahuje všetky príkazy, ktoré aktualizujú (UPDATE) dáta alebo by ich mohli aktualizovať (napríklad mazanie (DELETE), ktoré sa nevzťahuje na žiaden riadok). Príkazy sú uložené vo forme udalostí, ktoré popisujú zmeny. Binary log tiež obsahuje informácie o tom, ako dlho každý príkaz aktualizoval dát.

Binary log nahradil predtým používaný update log, ktorý už nie je dostupný od MySQL^? verzie 5.0. Binary log obsahuje všetky informácie, ktoré boli dostupné v update log-u avšak v efektívnejšom formáte a spôsobom, ktorý je bezpečný pre transakcie. Ak používate transakcie, musíte použiť MySQL^? binary log kvôli zálohovaniu, namiesto starého update logu.

Binary log sa nepoužíva pre príkazy ako SELECT alebo SHOW, ktoré nemenia dáta. Ak chcete logovať všetky príkazy (napríklad identifikovať chybnú požiadavku), použite general query log.

Primárnym účelom binary log-u je schopnosť aktualizácie databázy počas operácie zotavenia maximálne ako je možné, pretože binary log obsahuje všetky aktualizácie vykonané po zálohovaní. Binary log sa tiež používa na hlavných replikačných serveroch ako záznam príkazov, ktoré sa posielajú podradeným serverom. Binary log dokáže tiež vystopovať významné DLL udalosti. Analýza binary logu v tomto smere je časťou MySQL^? Network Monitoring a Advisory Service. Viac informácií na [1].

Server bežiaci so zapnutým binary logovaním má zníženú výkonnosť približne o 1%. Avšak výhody binary logu pri zotavovaní a možnosti nastavenia replikácie, všeobecne prevážia toto malé zníženie výkonu.

Keď naštartujeme server s voľbou --log-bin[=meno_suboru], mysqld zapíše do log súboru všetky SQL príkazy, ktoré aktualizujú dáta. Ak nezadáme meno súboru, štandardne sa nastaví meno host-a, za ktorým sa doplní -bin. Ak je meno súboru zadané (nie ako absolútna cesta), server zapíše súbor do dátového adresára. Všeobecne sa odporúča zadávať meno súboru.

2.3.4 Slow Query Log

Slow query log pozostáva zo všetkých SQL príkazov, ktoré vyžadujú viac sekúnd na vykonanie ako long_query_time. Čas na získanie zámkov pre tabuľku sa nepočíta ako vykonávací čas. Mysqld zapíše príkaz do slow query log po tom ako sa vykonal a všetky zámky sa odstránili, teda poradie logovania môže byť odlišné od poradia v akom sa príkazy vykonali. Minimálna a štandardná hodnota long_query_time sú 1 a 10.

Pre zapnutie slow query log, naštartujte mysqld s voľbou --log-slow-queries[=file_name]. Ak nezadáme meno súboru pre --log-slow-queries, štandardné meno je host_name-slow.log. Ak zadáme meno (nie ako absolútnu cestu), server zapíše súbor do dátového adresára.

Slow query log môžeme použiť pri hľadaní požiadaviek, ktoré vyžadujú dlhý čas na vykonanie a preto sú kandidátmi v prípade optimalizácie. Avšak prehľadávanie dlhého slow query logu sa môže stať náročnou úlohou. Pre uľahčenie sa zadáva mysqldumpslow na zosumarizovanie požiadaviek vyskytujúcich sa v logu.

2.4 Návrh spracovania log súborov

Z hľadiska bezpečnosti a kontroly používateľov je najzaujímavejší z log súborov MySQL^? servera General Query Log. Štruktúra záznamov v tomto druhu súboru však podobne ako v ostatných nie je rovnaká a tak pracovanie Geneal Query Log súboru je dosť obtiažne. Štruktúra Query Log súboru je nasledovná:

C:\Program Files\MySQL\MySQL Server 5.0\bin\mysqld-nt, Version: 5.0.45-community-nt-log (MySQL Community Edition (GPL)). started with:
TCP Port: 3306, Named Pipe: (null)
Time                 Id Command    Argument
071203 15:14:23    1 Connect     root@localhost on 
                   1 Query       SELECT @@sql_mode
                   1 Query       SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER‘
                   1 Query       SET NAMES utf8
                   1 Query       SHOW FULL PROCESSLIST
                   1 Query       SELECT DISTINCT User FROM mysql.user ORDER BY User
                   2 Connect     root@localhost on 
                   2 Query       SELECT @@sql_mode
                   2 Query       SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER’
                   2 Query       SET NAMES utf8
                   2 Quit       
071203 15:14:33    3 Connect     root@localhost on 
                   3 Query       SELECT RID FROM BWS_Core_Exchange.BWS_CORE_MODULE_USERS WHERE ID=2
                   3 Query       SELECT ID FROM BWS_Core_Exchange.BWS_CORE_MODULE_ROLES WHERE ID=1
071203 15:14:34    3 Query       SELECT status FROM BWS_Core_Exchange.BWS_CORE_MODULE_MODULES WHERE ID=23
                   3 Query       SELECT ID FROM BWS_Core_Exchange.BWS_CORE_MODULE_MODULES WHERE code = 'BWS_CORE_MODULE_DATAFILES_GROUPS'

Prvé dva riadky log súboru nie sú z hľadiska spracovania dôležité, pretože vyjadrujú iba cestu k serveru, TCP port. Ďalší riadok vytvára tzv. hlavičku tabuľky, ktorá popisuje jednotlivé hodnoty ktoré sa nachádzajú v záznamoch:

• Čas (Time) – spravidla iba pri vytvorení nového spojenia užívateľom po korektnom ukončení predchádzajúceho spojenia. Obsahuje dátum v tvare yymmdd (rok, mesiac, deň) a čas spojenia v tvare hh:mm:ss (hodiny, minuty sekundy)
• ID – identifikátor vlákna v log súbore. ID nekorešponduje so žiadnym systémovým ID alebo ID procesu MySQL^?.
• Príkaz (Command) – Connect pri pripojení používateľa, Querry ak ide o vykonanie príkazu pri práci s MySQL^? serverom, Init DB pri inicializácii databázy a Close pri ukončení práce s MySQL^? serverom daným používateľom.
• Argument – popisuje presne príkazy prijaté od klienta, ak ide o vytvorenie spojenia, tak ako argument vystupuje používateľské meno klienta. Príkaz Quit je bez argumentu.

Záznamy budeme spracovávať do štruktúry ktorá bude obsahovať jednotlivé hodnoty v samostatných premenných, aby boli neskôr ľahšie prístupné na ďalšie spracovanie pri vytváraní tokov pre IPFIX protokol.

2.5 Návrh programu

Pre návrh programu použijeme jazyk C. Záznamy z Query Log súboru budú načítavané do statického poľa štruktúr. Štruktúra bude evidovať jednotlivé záznamy a ich hodnoty v premenných date (dátum), time (čas), id, command (príkaz) a argument. Zo záznamov majú byť počas behu programu vytvorené toky pre IPFIX protokol na základe dohodnutých kritérií a prostredníctvom funkcií z knižnice libipfix pre jazyk C exportované do kolektora IPFIX. Takto vyexportované údaje je možné použiť pre ďalšie potreby či už z hľadiska QoS^? alebo bezpečnosti.

3 Analýza súčasného stavu

V SP1 – Monitorovanie IS sme sa zaoberali analýzou log súborov v širokom zábere technológii pre informačné systémy. Z týchto poznatkov sme čerpali potrebné informácie aj pre SP2 v ktorom sa zameranie zúžilo na analýzu a hlavne spracovanie log súborov z MySQL^? serverov. V priebehu semestra bol vypracovaný program na spracovanie General Query Log súborov pre MySQL^? podľa návrhu v kapitole 2. V súčasnom stave program načítava General Query Log do statického poľa štruktúr, kde je pripravený na ďalšie spracovanie do tokov.

3.1 Problematika vytvárania tokov pre IPFIX

Doposiaľ neboli stanovené kritéria podľa ktorých by bolo potrebné vytvárať toky pre IPFIX protokol, keďže táto problematika si vyžaduje dlhšiu a hlavne hlbšiu analýzu z hľadiska nie len obsahu log súborov ale aj z hľadiska samotného IPFIX protokolu, ktorého problematika je veľmi obsiahla a náročná na implementáciu v monitorovaní IS, keďže ide o protokol ktorý predstavuje isté nóvum a nie je všeobecne využívaný.

4 Návrh riešenia

V ďalšom pokračovaní projektu je potrebné ešte bližšie pochopiť celú problematiku IPFIX protokolu a jeho činnosti. Je potrebné zamerať sa na problematiku vytvárania tokov pre IPFIX a stanoviť definitívne kritéria ich vytvárania pre náš prípad. Na základe týchto poznatkov doprogramovať funkčnosť programu – vytváranie tokov a ich exportovanie.

Ďalej by bolo vhodné prepracovanie programu na priame spracovávanie General Query Log súboru na bežiacom MySQL^? servery.

Záver

Navrhnutý pohľad na monitorovanie informačných systémov z ich logovacích súborov sa zdá byť celkom využiteľný a v praxi najjednoduchšie realizovateľný. Problémom je len úprava programu v závislosti od technológie na ktorej je informačný systém postavený, avšak správnou úpravou sa dá docieliť aj prenositeľnosť programu medzi rôznymi IS.

Vhodným vytvorením tokov sa dá upraviť zameranie monitorovania a upraviť ho podľa potrieb ďalšieho spracovania. Monitorovanie IS má už význam samo o sebe pretože predstavuje vhodný nástroj na zisťovanie toho, čo sa reálne deje v IS. Vhodným zakomponovaním upozornení alebo úloh, ktoré sa pri výskyte danej akcie majú vykonať je možné vytvoriť systém na riadenie bezpečnosti informačných systémov.

Zoznam použitých zdrojov

[1] Kruckenberg M., Pipes J.: Pro MySQL^?. Apress, 2005

[2] MySQL^? AB: MySQL^? 5.0 Reference Manual. [Online] 1997-2008. Dostupné z: < http://dev.mysql.com/doc/refman/5.0/en/index.html >

[3] IETF working group: libIPFIX. [Online] Dostupné z: < http://libipfix.sourceforge.net/ >

-- MatusTaraba - 15 Feb 2008