Szakdolgozat. Miskolci Egyetem. A káoszban is van rendszer: összetett események felismerése, korreláció-keresés naplóüzenetekben

Átírás

1 Szakdolgozat Miskolci Egyetem A káoszban is van rendszer: összetett események felismerése, korreláció-keresés naplóüzenetekben Készítette: Szepesi Viktor GBP. Programtervező informatikus-szak Témavezető: Dr. Házy Attila egyetemi docens Miskolc, 2013

2 Miskolci Egyetem Gépészmérnöki és Informatikai Kar Alkalmazott Matematikai Tanszék Szám: Szakdolgozat Feladat Szepesi Viktor (DQM7M1) programtervező informatikus jelölt részére. A szakdolgozat tárgyköre: elektronikus naplózás korrelációs elemzése A szakdolgozat címe: A káoszban is van rendszer: összetett események felismerése, korreláció-keresés naplóüzenetekben A feladat részletezése: Az elektronikus naplózás fogalmának, fontosságának ismertetése. A témához kötődő protokollok ismertetése. Napló szerverek és napló elemzés. A syslog-ng képességeinek bemutatása. Témavezető(k): Dr. Házy Attila egyetemi docens Konzulens(ek): Höltzl Péter, CISA, Senior IT biztonsági tanácsadó A feladat kiadásának ideje: szeptember... szakfelelős 2

3 Eredetiségi Nyilatkozat Alulírott... ; Neptun-kód:... a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végzős... szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és aláírásommal igazolom, hogy... című szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít: szószerinti idézet közlése idézőjel és hivatkozás megjelölése nélkül; tartalmi idézet hivatkozás megjelölése nélkül; más publikált gondolatainak saját gondolatként való feltüntetése. Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül. Miskolc,....év....hó....nap... Hallgató 3

4 1. A szakdolgozat feladat módosítása szükséges (módosítás külön lapon) nem szükséges dátum témavezető(k) 2. A feladat kidolgozását ellenőriztem: témavezető (dátum, aláírás): konzulens (dátum, aláírás): A szakdolgozat beadható: dátum témavezető(k) 4. A szakdolgozat... szövegoldalt... program protokollt (listát, felhasználói leírást)... elektronikus adathordozót (részletezve) egyéb mellékletet (részletezve)... tartalmaz dátum témavezető(k) 5. bocsátható A szakdolgozat bírálatra nem bocsátható A bíráló neve: dátum szakfelelős 6. A szakdolgozat osztályzata a témavezető javaslata:... a bíráló javaslata:... a szakdolgozat végleges eredménye:... Miskolc, a Záróvizsga Bizottság Elnöke 4

5 Tartalomjegyzék 1. Bevezetés 7 2. A naplózásról általában A Windowsos naplózás A Linuxos naplózás Néhány log könyvtár Archiválás Hasznos eszközök Testreszabás Hasznos funkciók a naplózó alkalmazásokban Mire érdemes odafigyelni Naplózási technikák általánosan Log menedzsment (LM) Biztonsági adat és esemény menedzsment, avagy a SIEM Vállalati érettségi Napló analízis Funkciók és technikák A korrelációról bővebben Üzenetek feldolgozása a syslog-ng használatával A naplóüzenetek struktúrája BSD-syslog (RFC3164) IETF-syslog (RFC5424) Naplóüzenetek osztályozása Minta adatbázis használata Üzenetek korrelálása Műveletek beállítása azonosított üzenetekhez Feltételes végrehajtás Külső műveletek végrehajtása Akciók és a korreláció Minta adatbázis létrehozása Minta feldolgozók használata A V4 minta adatbázis formátum A biztonság és a syslog-ng Titkosított üzenettovábbítás A naplóbejegyzések kódolása a TLS segítségével Üzenetvesztés, mikor és hogyan?

6 5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével A flow-control és a többszörös üzenettovábbítás Összefoglalás 44 Irodalomjegyzék 45 Adathordozó használati útmutató 47 6

7 1. fejezet Bevezetés Napjaink rohanó világában az információ vált a legértékesebb erőforrássá. Ez az erőforrás azonban erejét és célját veszti, ha nincs tematikusan rendszerezve és nem lehet könnyen hozzáférni. Szakdolgozatom témája a naplóüzenetek feldolgozása, mely szerves része a kinyert információk strukturálásának. Véleményem szerint egy komplex informatikai infrastruktúra üzemeltetéséhez, illetve mélyebb szintű átlátásához elengedhetetlen, hogy a rendszer által küldött üzeneteket az üzemeltető csapat időben megkapja, és helyesen értelmezni tudja. Jelenleg egy informatikai paradigmaváltás zajlik. Ennek keretein belül előtérbe kerülnek a központosított adattárolási technológiák, a virtualizált erőforrás környezetek és az elosztott számítási módszerek. Mivel ezek a rendszerek jellemzően horribilis adatmennyiséget kezelnek, továbbá a biztonságos és megbízható működésük mindenek felett való, elengedhetetlen hogy a rendszer által küldött értesítések elemzésével egy-egy hibát időben észrevegyenek, és még azelőtt kezeljenek, hogy az kritikus meghibásodáshoz vagy akár egész fürtök leállásához vezetnének. Szakdolgozatom gerincét a BalaBit Kft. által fejlesztett syslog-ng adja. Ezt a terméket a világ számos vezető vállalata nap, mint nap alkalmazza, és ennek segítségével tudnak kiszűrni olyan incidenseket, melyek komoly károkkal járnának, vagy olyan hibákat elhárítani, melyek jelentős kiesést okoznának. Dolgozatomnak nem célja a syslog-ng végletekbe menő ismertetése, csupán egy kiinduló, áttekintő képet kívánok nyújtani arról, hogy mi ez a termék, illetve, hogy mire képes. A téma szakmailag igen specifikus így elengedhetetlen, hogy a dolgozat első részében az olvasót megismertessem az alapvető terminológiákkal, illetve a szükséges elméleti háttértudással. A rendszer alkalmazására konkrét példa nincs, mivel ezt az eszközt minden alkalmazási helyén egyedi igények szerint testre szabják, utána pedig a belső vállalati infrastruktúra szerves részét képezi, melyet a legtöbb cég nem szívesen tesz közzé. A példához szükség volna egy komplett vállalati infrastruktúra létrehozására, melyre azonban jelen dolgozat keretein belül nincs lehetőség. Az olvasó így általános megoldásokkal fog találkozni, azonban ezek a kódok az egyes esetekben akár szignifikáns módon is eltérhetnek. 7

8 Végezetül szeretnék köszönetet nyilvánítani mindazoknak, akik segítették jelen dokumentum elkészültét, szakmai vagy egyéb módon. Köszönöm családomnak a véget nem érő bíztatást, páromnak a türelmét és támogatását, konzulensemnek az iránymutatását, témavezetőmnek pedig odaadó mentori munkáját. "A kutató munka a Miskolci Egyetem stratégiai kutatási területén működő Fenntartható Természeti Erőforrás Gazdálkodás Kiválósági Központ / Alkalmazott Anyagtudomány és Nanotechnológia Kiválósági Központ / Mechatronikai és Logisztikai Kiválósági Központ / Innovációs Gépészeti Tervezés és Technológiák Kiválósági Központ keretében valósult meg." 8

9 2. fejezet A naplózásról általában Számítógépes naplózás alatt általában azt a folyamatot értjük, amely események rögzítéséből áll, jellemzően egy számítógépes program által, abból a célból, hogy adott szempontok alapján szolgáltasson ellenőrző adatokat egy rendszer vagy egy szoftver jobb megértése végett. Az elektronikus naplóbejegyzések (továbbiakban: log-ok) alapvető eszközök, ha szeretnénk komplex rendszerek viselkedését megérteni, különösen akkor, ha a monitorozott alkalmazás viszonylag kevés felhasználói beavatkozással rendelkezik, ilyenek tipikusan a szerveralkalmazások. A log-olás igazi ereje akkor mutatkozik meg, amikor a log-okat heterogén rendszerekből gyűjtjük be. Ha ezt kombináljuk a statisztikai analízissel, akkor bonyolult és összetett kapcsolatokat fedezhetünk fel ránézésre össze nem tartozó adatokon, eseményeken melyek eltérő forrásból érkeztek. Ilyen lehet egy behatolás detektálás, melyet általában jól felismerhető jelek előznek meg, vagy egy felhasználó szokásaiban beálló radikális változás, amely egy fiók jogosulatlan elérését jelentheti, esetleg egy fizikai hiba miatti szolgáltatás kiesés terjedése szerverről szerverre. (Csak példaként említhetnénk itt a március elején történt esetet, amikor a Microsoft felhő szolgáltatása egy hibás kód miatt kártyavár módjára dőlt össze) A naplózást azonban nem csak ipari vagy nagyvállalati környezetben érdemes használni. A legtöbb mai operációs rendszer is tartalmaz valami féle naplózó megoldást A Windowsos naplózás A Windows rendszerekben a naplózási folyamatokért az úgynevezett Event Log service felel. Ez a szolgáltatás automatikusan indul a rendszerrel (ha csak azt mi magunk kézzel le nem tiltjuk), és ez kreálja a naplóbejegyzéseket, amiket aztán az Event Viewer nevű programban meg is tudunk tekinteni. Alapbeállítások mellett az átlagfelhasználó csak az alkalmazás és a rendszer szintű logokat tekintheti meg, és csak rendszergazdai jogosultságokkal lehet hozzáférni a biztonsági logokhoz. Ennek oka, hogy a biztonsági logok olyan érzékeny információkat tartalmazhatnak a rendszerről, amelyek ha rossz kezekbe kerülnek egy támadás alapját képezhetik. (A Windows használat egyik hátulütője, hogy ha mezei felhasználók vagyunk, akkor nagy valószínűséggel rendszergazdai 9

10 2.2. A Linuxos naplózás jogosultsággal felruházott fiókunk van, így a szóban forgó programot elindítva mindhárom log fajtát megtekinthetjük) A Windows operációs rendszer több különböző típusú naplóbejegyzést különböztet meg. Ezek pedig: Alkalmazás log - olyan bejegyzések, amelyeket különböző telepített alkalmazások generálnak valamely esemény bekövetkeztekor. Biztonsági log - sikeres illetve sikertelen bejelentkezési eseményeket tartalmaz illetve azokat az eseteket, amikor valamilyen erőforrás használat történt pl. egy fájl megnyitása, törlése, létrehozása. Rendszer log - Ez a típus a rendszerösszetevők eseményeit fedi le, driver illetve hardware hibákat rendszerint. Domain Controller log - Ha tartományi kiszolgálót üzemeltetünk, akkor meg tudjuk nézni annak adatait. Kik léptek be, stb... File Replication Service log - file replication service eseményeket tartalmazó log. Tipikusan a SYSVOL könyvtár változásainak eseményei. Megosztott állományok változásának deployolása. DNS log - ha a gépünk egy tartomány kiszolgáló, akkor további logok is keletkezhetnek, ezek részletezése azonban jelen dokumentumnak nem célja. Megjegyzés: A biztonsági szakértők számára a legfontosabb naplóállomány a biztonsági log. Ez tartalmazza ugyanis a kapcsolódó hálózaton történő eseményeket. Minden naplóbejegyzés eltérő fajta logokat tartalmazhat. Egy-egy ilyen log lehet hiba (error), figyelmeztetés (warning), információ (information), sikeres audit (success audit) vagy sikertelen audit (failure audit). Könnyen belátható hogy egy nagyobb forgalommal bíró rendszeren, vagy hálózaton rövid idő alatt óriási mennyiségű (extrém esetben több GB-nyi) naplóbejegyzés keletkezhet. Ekkora mennyiségű adatot pedig lehetetlen folyamatosan valós időben nyomon követni limitált emberi erőforrások mellett. Ebből következik, hogy egy harmadik féltől származó naplózó illetve naplógyűjtő alkalmazás igen hasznos lehet a hétköznapokban A Linuxos naplózás Egy rendszer menedzselésének egyik kulcsa, hogy mindig tudjuk, mi történik a rendszerünkben. A Linux egy különleges logolási technikát ad a kezünkbe, ráadásul a log-ban megjelenő részletek mind konfigurálhatók. A Linuxos log állományok sima szöveges fájlok, így megnyitható, kereshető, olvasható bármilyen speciális program szükséglete nélkül. Ha akarjuk, írhatunk egy script-et is, ami végigfut a log-on és a tartalmától függően különböző parancsokat hajt végre. 10

11 2.2. A Linuxos naplózás A Linux rendszerben a logok alapértelmezés szerint a /var/log elérési út alatt találhatók meg, bár ezt az elérési utat a megfelelő konfigurációs beállítás megváltoztatásával könnyedén módosíthatjuk. Itt vannak olyan napló állományok, amiket a rendszer kezel, de más folyamatok, programok is tehetik ide a log fájljaikat. A legtöbb log állományt csak a root felhasználónak van jogosultsága olvasni, de ezen változtathatunk egy egyszerű hozzáférési jogosultság váltással Néhány log könyvtár /var/log/messages A messages log a rendszermag log állománya. Tartalmazza egyrészt a rendszer bootolása közben keletkező üzeneteket csakúgy, mint a rendszer futása közben keletkező egyéb üzeneteket. Ilyenek lehetnek pl. hibák IO műveleteknél, hálózati és egyéb általános rendszer hibák. Egyéb információk, mint például mikor kapott valaki root jogosultságot szintén ebben az állományban találhatóak. Ha valamilyen szolgáltatás fut az adott gépen, pl. DHCP szerver akkor az itt keletkezett üzenetek szintén ebben a részben találhatók. A /var/log/messages az elsődleges kiindulópont, ha hibakeresésbe kezdünk. /var/log/xfree86.0.log Ez a log tartalmazza az Xfree86 Xwindows szerver legutóbbi végrehajtásának eredményét. Ha problémánk akad a grafikus móddal érdemes itt kezdeni a keresést. /var/log/secure Tipikusan az autentikációs és jogosultság módosulás eseményekhez kötött információkat tartalmaz, ilyen lehet ha egy felhasználó UID vagy GUI-ja változik, illetve az sshd is ide logolja például a hibás bejelentkezéseket. /var/log/maillog Itt tárolódik minden pop/imap kapcsolat bejegyzése, be illetve kijelentkezések, továbbá minden egyes levél fejléce ami beérkezik vagy kimegy az adott gépen keresztül. (kitől, kinek, hova, msgid, status, stb... ) Archiválás A /var/log könyvtárban egy már régóta működő rendszerben láthatunk számra végződő állományokat. Ezek az úgynevezett forgatott (rotated) archív állományok. Mivel a log fájlok szeretnek hízni a Linux rendelkezésünkre bocsát egy parancsot (logrotate) aminek segítségével saját beállításaink alapján archiválja a logokat így előzve meg egye esetleges keveredést. Alapbeállítás szerint a logrotate automatikusan lefut adott időközönként, de természetesen lehetőség van manuális végrehajtására is. Amikor ez a parancs lefut, fogja az aktuális log fájlokat és befűzi a ".1"-et a fájlnév végére. Ezután ha van már korábban forgatott állományok, akkor azok verziószámát a rendszer automatikusan növeli. Ebből következik, hogy minél nagyobb szám szerepel az állomány nevében annál régebbi a napló állomány. Ezen parancs működését módosíthatjuk saját ízlésünk szerint. Ehhez elegendő a /etc/logrotate.conf fájl tartalmát átszabni. Bővebben lásd a Linux beépített súgójában. (man logrotate) 11

12 2.2. A Linuxos naplózás Hasznos eszközök Mint korábban említettem a Linux rendszerekben a log állományok tipikusan egyszerű szöveges fájl-ok, így kezelésükhöz nincs szükség "célszerszámra", azonban mégis van egy néhány eszköz, amivel nem árt megismerkedünk. dmesg Ha gyors bepillantást szeretnénk a boot log-ba a rendszert legutóbbi felállásakor, akkor érdemes ezt használni. Alapból elég sok szöveges információt jelenít, meg így nem árt, ha a csővezeték segítségével oldalakra bontjuk: dmesg more tail Előfordulhat olyan helyzet, amikor szeretnénk egy naplóállomány változását figyelni. Ekkor érdemes ezt a parancsot használni. A tail-t arra tervezték, hogy a szöveges állomány utolsó pár sorát megmutassa. A -f kapcsolóval a tail folyamatosan kiírja majd az újabb sorokat, ahogy azok bekerülnek az állományba. t a i l f /var/ log /messages A fenti sor megjeleníti a /var/log/messages fájl utolsó 10 sorát, aztán folytatja a kiírást, ha a naplófájl bővül. Ha parancsot a Ctrl+C billentyű kombinációval tudjuk megszakítani. more Működése ugyanaz, mint a DOS-os társáé, a megadott állomány tartalmát úgy tördeli, hogy egyszerre csak egy képernyőnyi jelenjen meg. more /var/ log / secure Kilépés a q vagy Ctrl+C kombinációval. less A less egy text nézegető, de lehetőség van benne egy nagyobb állomány végiggörgetésére, illetve keresésre is. l e s s /var/ log /messages Kilépés itt is a q használatával, illetve van súgó, ami a h betű megnyomására jelenik meg. logger Ez a parancs lehetővé teszi, hogy saját log üzeneteket továbbítsunk a rendszernek. Saját programokban szkriptekben alkalmazva információkat küldhetünk a futásidejű hibákkal és egyéb jelenségekkel kapcsolatban. Ha a naplózó rendszert előzőleg testre szabtuk, ne felejtsük el hozzáigazítani a saját log-ot. rsyslog Az rsyslog egy ingyenes, nyílt forráskódú szoftver a Unix, illetve a Unix alapú operációs rendszerekhez ami log üzeneteket továbbít IP hálózatokon. Ez az eszköz az alap syslog protokollt egészíti ki sokszínű tartalom alapú szűrési lehetőséggel, flexibilis beállításokkal illetve ez már TCP protokollt használ az üzenettovábbításra. 12

13 2.3. Hasznos funkciók a naplózó alkalmazásokban Testreszabás A teljes körű testreszabhatóság leírása jelen dokumentumban nem cél. Felületes képet kívánok nyújtani az olvasónak, amiből nagyjából képbe kerül és el tud indulni önállóan a témában. Kettő démont kell megemlíteni, melyek tulajdonképpen a logolást végzik, ezek a klogd és a syslogd (bár ez utóbbit már felváltotta a korszerűbb rsyslog eszköz). A klogd csak a kernel szintű üzeneteket kezeli, míg a syslogd kezeli a többi rendszer szintű eseményt. Mindkettő viselkedését tudjuk módosítani, ehhez csupán a /etc/syslog.conf és a /etc/sysconfig/syslog állományokat kell modifikálnunk. Alapvetően minden üzenet, amit egy program generál, tartalmaz bizonyos információkat, amelyek alapján azonosítani lehet. Honnan jött az üzenet illetve hogy milyen üzenet is tulajdonképpen. A /etc/syslog.conf fájlban lehet meghatározni, hogy mit is szeretnénk csinálni egy bizonyos típusú üzenettel. Kiírhatjuk a message fájlba, kiírhatjuk egy saját fájlba, elküldhetjük egy távoli kiszolgálónak, hogy az dolgozza fel. A távoli logolás biztonságilag egy elfogadott megoldás, mivel ha a log fizikailag nincs a gépen, akkor nem is lehet kompromittálni. Az alább láthatunk egy részletet, amit a /etc/syslog.conf állományból lett kiemelve: # Kernel messages are f i r s t, stored in the kernel # f i l e, c r i t i c a l messages and higher ones also go # to another host and to the console # kern. /var/adm/ kernel kern. c r i kern. c r i t /dev/ console kern. info ; kern.! err /var/adm/ kernel info Az első szabály átirányít minden üzenetet ami, a kernelhez érkezik a /var/ adm/kernel fájlba. A második szabály átirányít minden kernelhez érkező üzenetet ami crit vagy magasabb prioritással rendelkezik a magyarhon nevű távoli géphez. Ennek hasznossága korábban már tárgyalásra került. A harmadik szabály ugyanezen üzeneteket a átirányítja a konzolra, így az aktuális felhasználó is értesül az üzenetről. A negyedik szabály megmondja a syslogd-nek hogy mentsen minden kernel üzenetet ami info vagy magasabb prioritással, de az err -nél kisebb prioritással rendelkezik a /var/adm/kernel-info fájlba. 13

14 2.3. Hasznos funkciók a naplózó alkalmazásokban 2.3. Hasznos funkciók a naplózó alkalmazásokban A következőkben kitérek néhány olyan funkciókra, melyek hasznosak lehetnek egy naplózó alkalmazásban és ezzel segítségünkre lehetnek a megelőzésben vagy az utólagos nyomozásban. Valósidejű monitorozás és értesítés, ha egy olyan esemény következik be amiről a biztonságért felelős személynek tudnia kell. A Windows önmagában sajnos nem képes értesítésre egy előre beállított esemény bekövetkezésekor. A Windows rendszerek nem tartalmaznak központi ellenőrző megoldást. Ez azt jelenti, hogy minden egyes gép lokálisan tartalmazza a releváns naplóbejegyzéseket ezzel jelentősen megnehezítve egy eseményhez tartozó bejegyzések felkutatását. Sokkal egyszerűbb egyetlen (vagy legalábbis néhány) log üzenetből tájékozódni az aktuális rendszer állapotáról, mint több száz, esetleg több ezer naplóbejegyzés között valami fontos dolgon elsiklani. Éppen ezért érdemes egy központi monitorozó rendszert felállítani, amit a szakértő(k) egyszerűen el tudnak érni, ha bepillantást szeretnénk valahova. A biztonsági logok távoli felügyelete szintén elvárás. Ez annyit jelent, hogy ha egy behatolási kísérlet történik, melynek során egy lokális felhasználói fiókkal akarnak egy géphez hozzáférést szerezni, az ellenőrzési nyomvonal (audit trail) korlátozódjon csupán a helyi biztonsági naplóbejegyzésekre. A kritikus események leírásának egyértelműsítése. A hagyományos Windowsos környezetben a naplóbejegyezések gyakran rejtélyesek és félrevezetőek lehetnek. Szerencsére a korszerű naplózó alkalmazásokban már be lehet állítani riasztásokat egy speciális eseményhez így könnyítve meg az adminisztrátor munkáját a logok kibogarászásában. Archiválás. Egyes intézményeknél, bankoknál a legtöbb országban követelmény a naplóüzenetek megőrzése 7 vagy akár több évig is bizonyos esetekben. Az alap Windows beállítás az, hogy ha a log állomány elér egy bizonyos méretet, akkor felülírja, ami adatvesztéssel jár, illetve megakadályozhatja egy esemény nyomozását is. Egyik lehetőség, hogy a felhasználó maga gondoskodik a naplóállományok kitisztításáról illetve fizikai tárolásáról. Napjainkban viszont már lehetőség van ennek a folyamatnak az automatizálására, amivel centralizálhatjuk, a folyamatot ezzel pedig megnövelhetjük a produktivitást egy nagy hálózaton, emellett pedig csökkenti a segélykérések (support calls) számát, és lehetőséget nyújt, az adminisztrátornak távolról kideríteni mit történik vagy történt az adott gépen. Napló állományok integritása. A lokálisan tárolt logok nagyobb veszélyforrásnak vannak kitéve, mivel a felhasználó kitörölheti, vagy egy behatoló miután hozzáférést szerzett eltakarhatja a nyomait az aktuális log törlésével. Elterjedt gyakorlat hogy behatolásnál az illetéktelen hozzáférő hatalmas mennyiségű fals logot helyez el az állományban ezzel fedve el a nyomait. Egy távoli logkezelő alkalmazás használatával a szakértő riasztást kap egy ilyen esetnél és szinte azonnal reagálhat a feltételezett veszélyhelyzet elhárítása végett, továbbá mivel a log állomány távoli helyen van tárolva a behatoló vagy a felhasználó nem tudja sem törölni sem módosítani azt. 14

15 2.4. Mire érdemes odafigyelni Szűrés. Az adatszemét egy nagy probléma a log témakörében. A monitorozó alkalmazások szerencsére rendelkeznek viszonylag fejlett szűrő lehetőségekkel, amikkel kiszűrhetők a zaj események, amik csak időt és tárhelyet pocsékolnak, ugyanakkor nem tartalmaznak hasznos információt. A fontos fájlokhoz való hozzáférés monitorozása is alapvető. Ezt úgy tudjuk megvalósítani, hogy az elutasított hozzáféréseket listázzuk, így pedig képet kaphatunk arról, ha valaki olyan állományhoz próbál hozzáférni, amihez nem szabadna. Szintén hasznos lehet, ha az alkalmazás képes vagy sms értesítésre, mivel az adminisztrátor sem biztos, hogy mindig gépközelben tartózkodik, így azonban nagyobb eséllyel jut el hozzá a riasztás és így megteheti a megfelelő lépéseket a melyek szükségesek az adott esetben. A web szervermonitorozást külön ki lehet emelni, mivel ez egy ritkán említett terület. Egy monitorozó szoftver használata ugyanis egy plusz réteget adhat az alap védelem mellé, ami a web szerverünket védi. Ez az a rész ahol az értesítési funkció erőssége megmutatkozik mivel nem egyszerű dolog monitorozni egy szervert, ami a DMZ-ben van. Az adattárolás egy megbízható kereshető adatbázisban (pl.: SQL) előnyt jelenthet, illetve nagyvállalati környezetben elvárt dolog. A legtöbb naplóalkalmazás ma már rendelkezik ezzel a funkcionalitással. Riportkészítés elterjedt eszközökkel, mint pl.: SAP Crystal Reports szintén elvárás egy nagyvállalati környezetben, mivel a különböző szokások illetve történések szemléltetésének egy igen kifinomult eszköze lehet. Gondoljunk arra, hogy egy eseménye prezentálása egy feljebb valónak mennyivel könnyebb, ha úgy tudjuk ábrázolni az adatokat illetve tényeket, amiket egy felhasználó is érteni tud. Éppen ezért elvárás, hogy a monitorozó alkalmazásunkat hozzá lehessen kötni egy ilyen eszközhöz. Az események kategorikus rendezése priorizált szekciókba. Az alkalmazásnak képesnek kell lennie arra, hogy az adminisztrátor egy szempillantás alatt értesüljön a kiemelkedő prioritással bíró eseményekről majd a közepes és az alacsony prioritással bíró eseményekről. Ez a sorrendiség időt spórol és javítja a vezetői döntéshozatalt. A logok takarítása is monitorozva kell legyen, egyrészt mert csak a rendszerért felelős biztonsági szakértő takaríthatja a logokat másrészt pedig nyoma kell legyen az eltüntetett adatoknak, abban az esetben ha a legfőbb adminisztrátor fiókja kompromittálódna. A célzott nyomkövetés is egy alapelvárás, hiszen gyakran szükség lehet arra, hogy egy adott eseményt monitorozzunk egy adott gépen, hogy a gép továbbra is biztonságos maradhasson, így a monitorozásnak sokkal összetettebbnek kell lennie. 15

16 2.5. Naplózási technikák általánosan 2.4. Mire érdemes odafigyelni Vannak bizonyos kulcs elemek, amikre egy biztonsági szakértőnek oda kell figyelni, hogy a hozzá tartozó rendszer továbbra is biztonságos és behatolástól mentes maradhasson. Az illetéktelen hozzáférők gyakran támadják, a log állományokat mivel tudják, hogy ha egy tapasztalt ember nézi át azokat, akkor őket meggyanúsíthatják vagy akár nyomon is követhetik a ténykedésüket. Ezen felül, ha egy eseménynek nincs nyoma, akkor elég nehéz bebizonyítani, hogy az adott esemény megtörtént. Érdemes tehát olyan alkalmazás után nézni, aminek nagyfokú testreszabhatósága van mivel ez nagy segítséget fog nyújtani abban, hogy egy irdatlan adathalmazból kiszűrjük a számunkra az adott időszeletben releváns információkat. Egyes folyamatok automatizálásával órákat akár napokat is spórolhatunk, azonban ne essünk a ló másik oldalára, ne hagyjuk, hogy a túlzottan automatizált rendszerben detektálatlanul maradjon egy biztonsági rés. Fordítsunk gondot és időt arra, hogy a riportokat összeállítsuk acélból, hogy a végén megkapott jelentés tartalmazza mindazt a fontos és releváns információt, amikkel még idejében jelezhető a baj. Hibás bejelentkezések, rossz felhasználó és jelszó páros, felhasználói fiókzárolások, szokatlan időben történő bejelentkezések és visszautasított erőforrás elérések mind-mind egy lehetséges vagy jövőben bekövetkező betörésre utalhatnak. Ezeket az eseményeket ki kell vizsgálni és a korreláló felhasználóval együtt validálni kell, hogy miért történtek. Az idő egy fontos tényező, és mint a legtöbb emberrel kapcsolatos dologban, itt is az idő a szűkkeresztmetszet. Az idő pénz és a logok átnézése és értelmezése többnyire nem tartozik azok közé a feladatok közé, amiket egy cég elvár, ha egy magasan képzett IT specialistát alkalmaznak, ennek ellenére ezt a részét is el kell végezni a feladatnak. Lehet azonban egyszerűsíteni a folyamaton és itt bizonyít újra az állítás, miszerint elengedhetetlen használni egy harmadik fél által fejlesztett naplózó alkalmazást hogy a naplózás, az archiválás és a jelentések az eseményekről megfelelő minőségben, mélységben és időben készüljenek Naplózási technikák általánosan A naplóinformáció gyűjtésére és kezelésére kettő irányzat terjedt el. Az egyik a nalómenedzsment (Log Management), a másik a SIEM (Security Information and Event Management). E két módszer különbségeit illetve működését fogjuk áttekinteni az alábbiakban Log menedzsment (LM) A naplómenedzsment egy bonyolult folyamat, melynek során a cégeknek tengernyi dologra, paraméterre kell odafigyelniük és emitt gyakran adódik, hogy egy rövid idő alatt felállított vagy felületesen megtervezett rendszer nem, vagy nem úgy működik, ahogy azt elvárták korábban. Ezt elkerülendő tekintsük át a lépéseket, amiket be kell járni 16

17 2.5. Naplózási technikák általánosan egy korrekt infrastruktúra kialakításához. 1. A célok és elvárások pontos meghatározása. Egy naplózó rendszer számos feladata lehet. Ez lehet, biztonsági naplóelemzés (behatolások és gyanús tevékenységek detektálása), egy alkalmazás hibás működésének detektálása (nagyobb forgalmú web service-k), vagy a hatósági megfelelőség bizonyító eszköze (pl.:bankok és egyéb pénzintézetek). 2. A naplózó keretrendszer meghatározása. Definiálni kell a naplók típusait illetve a naplókat előállító rendszerek specifikációit. 3. Meg kell határozni, hogy a naplózást hogyan lesz alkalmazva az első pontnál felállított cél elérésére. Elég csak gyűjteni a naplókat, vagy mondjuk elemezni, feldolgozni is kell őket, esetleg napi riportokat készíteni a rendszer használatáról. Hogyan és mennyi ideig lesznek tárolva a naplók? Megfelel-e a tárolási metódus a kompetens törvényi szabályozásnak? Kódolva vagy natív formában lesznek-e tárolva? Ezekre a kérdésekre választ kaphatunk az adott ország idevonatkozó torvényi szabályozásai által. (Magyarországon ezt az Informatikai Tárcaközi Bizottság ajánlásával kiadott "Informatikai rendszerek biztonsági követelményei" c. dokumentum ratifikálja) 4. Definiáljuk, milyen típusú információkat, adatokat szeretnénk kinyerni a naplókból. Ezek lehetnek végfelhasználói riportok, alkalmazás hibák és még sok egyéb is a helyzettől függően. 5. Piaci kínálat áttekintése. Ki kell választani a technológiát, illetve egy konkrét alkalmazást, ami legjobban illeszkedik a felállított modellre. Ez lehet egy szoftver készítő cég, ami ezzel foglalkozik, vagy ahogy már fentebb tárgyaltuk egy saját készítésű alkalmazás Biztonsági adat és esemény menedzsment, avagy a SIEM A SIEM megoldások két korábban külön kezelt termékkategória egyesülése nyomán születtek. Az egyik a SIM (security information management), a másik pedig a SEM (security event management) volt. A SIEM eszközök lehetőséged kínálnak a hálózati hardverek által generált biztonsági riasztások valós idejű elemzésére. Ezek az eszközök elfordulhatnak szoftver, fizikai eszköz vagy menedzselt szolgáltatás formájában, és többek között a biztonsági adatok naplózására és riportok generálására is használhatók. A SEM, SIM és SIEM mozaikszavak napjainkban szinte egyé forrottak, annak ellenére, hogy különbség van mind a jelentésben mind az alkalmazások képességeiben. A biztonsági menedzsment szektora, ami lefedi a valós idejű monitorozást, események korrelálását és az értesítések kezelését általában a SEM-hez tartozik. A tartós megőrzés, különböző szempontok szerinti analízis és a napló adatok riportálását a SIMhez szoktuk kötni. A különböző jelentések, definíciók fejlődése, átalakulása, egyesülése vezetett végül oda, hogy megszületett a SIEM termék kategória. 17

18 2.6. Vállalati érettségi Magát a Security Information and Event Management kifejezést Mark Nicolett és Amrit Williams alkották meg 2005-ben. Ekkor determinálták azokat a képességeket, amiket egy ilyen összetettségű eszköznek tudnia kell. Ezek a begyűjtés, analizálás, tárolás és információ prezentálása hálózati és biztonsági eszközökből. Tartalmaznia kell azonosítást és beléptetést végző alkalmazásokat, sebezhetőség kezelést, házirend felülvizsgálót és a különböző operációs rendszerek, adatbázis, alkalmazások naplóit is tudnia kell kezelni januárjában a Mosaic Security Research felmérése szerint a piacon 85 különböző SIEM termék volt megtalálható. A SIEM termékek képességei Adat aggregáció - a naplók begyűjtése több forrásból történhet (hálózat, biztonsági eszközök, szerverek, adatbázisok, alkalmazások). A sokrétű adatok központi gyűjtése csökkenti az esélyét annak, hogy egy fontos esemény rejtve marad. Korreláció - bizonyos paraméterek szerinti történések összekötése egyetlen eseménnyé. A korreláció alkalmazásával lehetőség nyílik több forrás által szolgáltatott adatokat olyan információvá gyúrni mellyel egy komplexebb képet kapunk a rendszerek működéséről. Figyelmeztetés - az automatikus elemzéssel azonnali riasztást kaphatunk előre beállított események bekövetkeztekor, vagy ha olyan korreláló eseménysorozat következik be/zajlik amiről feltétlen tudnia kell a rendszer felügyelőjének. A figyelmeztetés lehet a kezelőfelületen keresztül, vagy egyéb harmadik fél által szolgáltatott csatornán pl.: , sms, stb.. Kezelőfelület - a kezelőfelületen jeleníthetünk meg minden, amit a naplózó rendszerünk "megtud". A jobb rendszerek kimutatásokat és riportokat is tudnak készíteni automatikusan, ezzel is javítva a megértést. Megfelelőség - a legtöbb ország rendelkezik saját adatbiztonsági irányelvekkel, amiket a cégeknek be kell tartaniuk, és ezeket az országok rendszeresen ellenőrzik is. Egy kifinomult SIEM terméket be lehet állítani, hogy a szükséges adatokat kimutatásokat automatikusan legenerálja a hozzá érkező adathalmazból. Archiválás - a hosszú távú tárolással lehetőség nyílik az adatok utólagos korrelálására, illetve ez egy kötelező pontja minden ország adatbiztonsági irányelvének. Az adatok hosszú távú tárolása elengedhetetlen egyes vizsgálatok lefolytatásához, mivel például egy biztonsági rés felfedezése nagy eséllyel annak kialakulása után történik Vállalati érettségi Egyes vélemények szerint egy vállalat érettségét, megbízhatóságát lehet az általuk használt naplózó technikák kiforrottságával, komplexitásával is mérni. Jelen alfejezet célja egy feltételezett szintrendszer bemutatása a teljesség igénye nélkül, nem reprezentatív módon. 1. szint a kezdeti fázisban, különböző log elemzők állnak munkába elsősorban a biztonsági részlegből kinyert naplók elemzése végett, hogy a támadások mintáit felismerjék, ami a céget elsődlegesen érhetik. 18

19 2.6. Vállalati érettségi 2. szint a számítógépes integráció magasabb szintű használatával, a vállalatok a titkos adatok elérését is használatát monitorozzák a naplók segítségével. 3. szint ezen a szinten a log analizáló nyomon tudja követni és monitorozni tudja a teljesítményt és a rendelkezésre állását a rendszer különböző szintjeinek, különös tekintettel azokra melyeke a vállalat egészséges működéséhez elengedhetetlenek. 4. szint a vállaltok különböző üzleti alkalmazások naplóit integrálják egy vállalati szintű naplókezelő rendszerbe, hogy az adatok alapján optimalizálhassák saját működésüket, termelésüket. 5. szint a szervezetek egyesítik a fizikai elérés monitorozását a logikai elérések monitorozásával, ezzel egy mindent lefedő képet kapva a kiszolgáló rendszerről. 19

20 3. fejezet Napló analízis A napló vagy log analízis egy olyan tudomány terület (egyesek szerint művészeti ág) melynek során megpróbáljuk értelemmel felruházni a számítógépek által ontott megannyi bejegyzést. A főbb okok, amiért az emberek, vállaltok alkalmazzák a napló analízist: Biztonsági előírások teljesítése Az adott ország kurrens szabályzatának való megfelelés Hibakeresés a rendszerben Bűnügyi okokból (folyamatban lévő nyomozásnál a bíróság elrendelheti a digitális bizonyítékok prezentálását, ekkor a naplóüzeneteket veszik elő) Egy biztonsági incidens válaszaként Napló állományokat hálózati eszközök, operációs rendszerek, alkalmazások és mindenféle egyéb programozható eszközök kreálnak többnyire. A napló állományokat tárolhatjuk fájlokban a helyi lemezen, vagy egy hálózati folyamként továbbíthatóak egy központi log gyűjtőnek. Az alkalmazások által generált logok lehetnek olyan naplók is melyeket az alkalmazás készítője programozott bele, hogy egy esetleges hibánál a hibakeresést megkönnyítse. A logok szemantikája és szintaktikája nem egységes, többnyire az adott alkalmazásra vagy vállaltra jellemző formát ölt. Ebből következik, hogy a terminológia is elég változatos lehet. Mivel az ilyen alkalmazások 99%-ban angol nyelvűek, egy program által történő felhasználó autentikáció lehet logon, login, user connection vagy authentication esemény is. Éppen ezért a log analízisnek úgy kell interpretálnia az üzenetet, hogy az illeszkedjen az adott alkalmazás, vállalat, kontextusába, ezzel is hasznos összehasonlításoknak helyet adva. A naplóüzenet fajták vagy tartalmuk nem mindig vannak dokumentálva, ezért a log analizáló feladatai közé tartozik, hogy a rendszert minél több log kibocsátásra késztesse, ezzel mintegy meghatározva a log üzenetek egy spektrumát melyből a logok kikerülhetnek. A naplóanalizáló a rendszer vizsgálatakor felfedezett különbségeket úgy oldja fel, hogy a sok eltérő terminológiájú napló állományt egységesíti egy normalizált terminológiába és így, a kimutatások statisztikák alapjául szolgáló adatok heterogén rendszerekből is származhatnak. 20

21 3.1. Funkciók és technikák 3.2. A korrelációról bővebben A piacon található naplófeldolgozók jól bevált módszereket és technikákat alkalmaznak, hogy a hatalmas mennyiségű adatot kezelhető mennyiségű eseménnyé redukálják. Ezek az alábbiak lehetnek: Minta felismerés - a funkció célja, hogy a bejövő üzeneteket egy előre megadott minta adatbázis alapján szűrje vagy kiválassza. Normalizálás - ez a funkció konvertálja a különböző üzenetek részeit ugyanolyan formátumba, pl.: eltérő idő formátum. Osztályozás és címkézés - a későbbi felhasználás illetve a könnyebb visszakeresés céljából lehet ezt a funkciót használni. Korreláció analízis - ez a technológia az összegyűjtött üzenetekből kikeresi azokat, amik ugyanaz az eseményhez tartozik. Mesterséges kizárás - az a folyamat melynek során eltávolításra kerülnek azok az üzeneteket, amik nem érdekesek. Ez tulajdonképpen egy olyan metódus, ami figyelmen kívül hagyja azokat az üzeneteket, amik egy normálisan rendszerből érkeznek, és csak azokra figyel fel, amik eltérnek a szokásostól, amiket érdemes lehet kivizsgálni A korrelációról bővebben A korreláció analízis vizsgálati tárgya két entitás kapcsolata. Az ezt kifejező mennyiség, amit korrelációs együtthatónak nevezünk, mutatja, hogy ha az egyik entitás változik az, hogy és mennyire lesz hatással a másikra. Amikor korrelációt vizsgálunk, az egyik objektum a függő, míg a másik a független. A célunk megvizsgálni, hogy ha a független elemen változtatunk (ez többnyire egy mutató) akkor fog-e változást okozni a függő elemben. Ez segítségünkre lehet az indikátor elem előrejelző képességének megértésében. A korrelációs együttható értéke ± 1 között változhat. Ha az együttható értéke +1.0 akkor azt "tökéletes pozitív korrelálásnak" nevezzük, ami azt jelenti, hogy ha változtatunk a független objektumon, akkor azonos változás fog történni a függő elemen is. Akkor, ha a korrelációs együttható értéke -1.0, azt "tökéletes negatív korrelálásnak" nevezzük, és azt jelenti, hogy ha változtatunk a független elemen, akkor azonos változás fog történni a független elemen is azonban az ellenkező irányban. A 0 értékű korrelációs együttható azt jelenti, hogy nincs kapcsolat a két objektum között és a független elem változtatása nem fog változást eredményezni a függő elemben. Az együttható alacsony értéke (± 0.10 vagy kevesebb) utalhat arra, hogy a két változó közötti kapcsolat nagyon gyenge vagy talán nem is létezik. A magasabb értékű együtthatók (közelebb állnak a ą1-hez) általában azt jelentik, hogy függő elem biztosan változni fog, ha a független változót módosítjuk. 21

22 3.2. A korrelációról bővebben A függő változó értékének változása függ az együttható előjelétől. Ha az pozitív, akkor a függő változó értékmódosulása követni fogja a független változót. Ha az érték negatív, akkor a változás azonos mértékű, de ellentétes irányú lesz. Kétféle felhasználása van a korreláció analízisnek. Az egyiknél azt vizsgáljuk, hogy egy adott mutatónak milyen előrejelző értéke van, mennyire lehet megjósolni vele adott változások kimenetelét, a másik felhasználásnál pedig két változó közötti összefüggést vizsgáljuk. 22

23 4. fejezet Üzenetek feldolgozása a syslog-ng használatával 4.1. A naplóüzenetek struktúrája A naplóüzenetek struktúra leírására jelenleg kettő elfogadott szabvány létezik. Az egyik az RFC 3164, más néven a BSD-syslog, a másik az RFC 5424, más néven a IETFsyslog. A következőkben ezeket fogjuk áttekinteni BSD-syslog (RFC3164) Ebben a részben górcső alá vesszük a címben említett szabványt. Az üzenet teljes hossza alapesetben nem lehet hosszabb 1024 byte-nál. Ezt módosítani a log_msg_size()-al lehet, ekkor az üzenet maximális hossza 256 MB lehet összesen. A syslog napló állomány 3 részből áll, melyek: PRI HEADER MSG A naplóállomány PRI része Az üzenet ezen része, más nevén a prioritási érték, tartalmazza az alrendszert, illetve az üzenet súlyosságát. Az alrendszer azonosítja a rendszer azon részét mely a naplóüzenetet létrehozta, míg a súlyossági érték egy olyan mutató, ami arról árulkodik mennyire volt komoly az esemény, amely miatt a naplóüzenet létrejött. A fontossági érték kiszámítása úgy történik, hogy mindenek előtt vesszük az alrendszert azonosító értéket és megszorozzuk nyolccal, majd hozzáadjuk a súlyossági tényező numerikus értékét. 23

24 4.1. A naplóüzenetek struktúrája Numerikus érték A HEADER rész Alrendszer 0 kernel üzenet 1 felhasználó szintű üzenet 2 mail rendszer 3 rendszer daemon-ok 4 biztonsági/autentikációs üzenetek 5 a syslogd által belsőleg generált üzenet 6 nyomtató alrendszer 7 hálózati alrendszer 8 UUCP alrendszer 9 óra deamon 10 biztonsági/autentikációs üzenetek 11 FTP daemon 12 NTP alrendszer 13 log audit 14 log alert 15 óra daemon felhasználó által használt alrednszerek (local0-local7) Numerikus érték Súlyossági besorolás 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages A fejléc tartalmazza az időpontot és a host nevet (a domain nélkül) vagy az adott eszköz IP címét. Az időpont a helyi időt jelenti az alábbi formátumban: Mmm dd hh:mm:ss Ebben a formátumban a Mmm a tárgyhó angol nyelvű rövidítése (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec). A dd az adott hónap napjának numerikus értéke. Ha a nap értéke kevesebb, mint 10 akkor az első karakter a rendszer szóközre cseréli pl.: Aug 7. A hh:mm:ss pedig a helyi pontos időt jelenti. Itt a hh az óra 24

25 4.1. A naplóüzenetek struktúrája 24 órás formátumban, a mm és a ss pedig rendre a perc és a másodperc megfelelője. Ez utóbbi kettő esetben az elfogadott értékék 0-tól 59-ig terjednek, míg az óra esetében értelemszerűen 0-tól 23-ig. Természetesen más időformátumokat is képes kezelni a rendszer melyeket a ts_format() segítségével állíthatunk, erre azonban jelen dolgozatban nem térek ki részletesen IETF-syslog (RFC5424) Most tekintsük az IETF-syslog protokoll leírását. A log üzenet itt is három fő részre bontható szét. Ezek a részek: HEADER (ez tartalmazz a PRI szekciót is) STRUCTURED-DATA MSG A PRI szekció Ez a rész teljesen megegyezik a BSD-syslog protokoll által deklarált PRI résszel mind a numerikus értékek mind a generáló szabályok tekintetében. Ezeket részletesen lásd "A naplóállomány PRI része" fejezetben. A HEADER szekció VERSION - a használt syslog protokoll szabvány verzió száma, jelenleg ez 1 ISOTIMESTAMP - az időpont amikor az üzenet generálódott, ISO 8601 szabvány szerint (yyyy-mm-ddthh:mm:ss+-zone) HOSTNAME - az üzenetet küldő gép APPLICATION - az eszköz vagy alkalmazás ami az üzenetet generálja PID - annak a syslog alkalmazásnak a neve vagy az ID-ja amelyik küldte az üzenetet. Ez nem feltétlenül egyezik meg azzal amelyik generálta! MESSAGEID - az üzenet azonosítója Mivel a HEADER rész tartalma nem lehet nagyobb egy adott méretnél azért a syslog az alábbi megkötéseket alkalmazza: Ha az alkalmazás neve hosszabb, mint 48 karakter akkor a többit levágja. Ha a procesz azonosítója hosszabb, mint 128 karakter a többit levágja. Ha az üzenet azonosítója hosszabb, mint 32 karakter a többit levágja. Ha a hostname hosszabb, mint 255 karakter a többit levágja. 25

26 4.3. Minta adatbázis használata STRUCTURED DATA A strukturált adat rész meta információkat tartalmaz a syslog üzenetről, illetve alkalmazás specifikus információkat például forgalom számlálókat, IP címet stb. A strukturált jelző abból adódik, hogy adat blokkokból épül fel, amit szögletes zárójelek ([]) határolnak. Minden blokk tartalmazza a blokk azonosítóját és egy vagy több név=érték párosból álló adathalmazt. A syslog-ng eszköz képes automatikusan elemezni ezt a részét az üzenetnek és képes ezekhez makrókat beállítani, ezáltal is könnyítve a feldolgozást. Az MSG rész Ebben a részben található meg a naplóüzenet maga. A szöveg kódolása UTF-8 ha a szöveg tartalmaz BOM karaktert. Ha ilyet nem talál a feldolgozó, akkor a kódolást ismeretlennek jelöli meg Naplóüzenetek osztályozása A syslog-ng alkalmazás képes arra, hogy a beérkező log üzeneteke tartalmát összehasonlítsa egy előre meghatározott minta adatbázissal. Azzal hogy az üzenetek egy előre definiált mintahalmazhoz vannak hasonlítva, a syslog-ng képes felismerni az üzenet típusát és azok alapján különböző osztályokba sorolni azokat. Az üzenet osztályokat így használhatjuk arra, hogy az esemény típusát is osztályozzuk a log üzenet tartalma alapján. Az üzenet osztályokat saját szájízünk szerint testre is szabhatjuk, így azok akár beszédes nevek is lehetnek pl.: felhasználó-bejelentkezés, alkalmazás hiba, fájlküldés, stb... Az illeszkedő minta megtalálása egy bizonyos üzenethez egy úgynevezett "longest prefix match radix tree" nevű algoritmussal történik. Ennek során a syslog-ng összeállít egy fa struktúrát az elérhető mintákból, amiben a minta különböző helyein található karakterek képezik a fa ágait. Az osztályozáskor a rendszer veszi a naplóüzenet első karakterét (nem a head részből, hanem magából a szöveges üzenetből) és kiválasztja azokat a mintákat, amelyek illeszkednek az adott karakterre a többit pedig "eldobja". Ezután a második karakter kiválasztása történik és az előbb szelektált halmazból megkeresi azokat a mintákat melyek, illeszkednek erre a karakterre, a többit pedig figyelmen kívül hagyja. Ez a folyamat egészen addig folytatódik, míg végül csak egyetlen vagy nulla illeszkedő minta marad. Utóbbi esetben az üzenetet a rendszer automatikusan ismeretlennek jelöli, egyéb esetben az üzenet megkapja az illeszkedő minta osztály besorolását. Az osztályozás flexibilisebbé tételéért a minták tartalmazhatnak úgynevezett minta értelmezőt (pattern parsers). Ezek többnyire egy karakter készletre illeszkednek, ilyen lehet pl.: NUMBER ami bármilyen egész vagy hexadecimális számra illeszkedik. Más értelmezők egyéb karakterre, karakter sorozatra illeszkednek, erről részletesebben a 3.5- ös fejezetben lehet olvasni. 26

27 4.3. Minta adatbázis használata 4.3. Minta adatbázis használata Lehetőségünk van az üzeneteket osztályozni úgynevezett minta adatbázisok segítségével is. Ehhez a megfelelő helyen használjuk a db_parser() opciót a konfigurációs állományban az alábbi szintaktika szerint: parser <azonosito> {db_parser(file("<adatbazis_allomany>"));}; Érdemes megemlíteni, hogy a fenti parser használata a log kifejezésben csupán osztályozást eredményez, de az üzenettel további műveletet nem végez, így annak archiválásához vagy továbbításához további beállítások szükségesek! Az adatbázis alapértelmezett elérési útvonala az alábbi: /opt/syslog-ng/var/run/patterndb.xml Ez az útvonal a konfigurációs állomány módosításával változtatható. A db_parser() file() opciója lehetőséget ad nekünk arra, hogy eltérő útvonalon lévő adatbázis adjunk meg az értelmezőnek. Ezzel megoldható az, hogy eltérő értelmező utasításoknak különböző adatbázisa legyen, ezzel is elősegítve a moduláris kialakítás létrehozását. Egy üzenet osztályozásának vagy "parszolásának" eredménye használható különböző szűrők illetve fájl és adatbázis sablonok beállításánál is. A syslog-ng OSE kettő makrót tartalmaz, amivel az adott üzenet osztályozásának eredménye kérhető le. A.classifier.class makró visszaadja az üzenethez társított osztályt, míg a.classifier.rule_id makró annak az üzenet sablonnak az azonosítójával tér vissza, amire az üzenet illeszkedik. Vegyük szemügyre az alábbi példakódot: f i l t e r filt_oszt_behatolas { match(" violation " value (". c l a s s i f i e r. class ") type (" string ") ) ; }; log { source ( minden_forras ) ; parser ( pattern_db ) ; f i l t e r ( filt_oszt_behatolas ) ; destination ( cel_oszt_behatolas ) ; }; A kód első felében létrehozunk egy szűrőt, ami illeszkedik a "violation" típusra. Ehhez felhasználtuk az előbb megismert,.classifier.class makrót, majd ezt a szűrőt felhasználtuk a log kifejezésben. Ennek hatására az adott forrás felől érkező összes üzenetből ki lesznek szűrve azok, amikre illeszkedik a "violation" osztály és csak azok lesznek továbbítva a megfelelő célállomás felé. Ha létrehozunk egy hasonlós szűrőt, ami az "unknown" osztályra illeszkedik, akkor ki tudjuk szűrni azokat az üzeneteket, amikkel a rendszer még nem találkozott. Ha ezeket egy fájlba irányítjuk, akkor időről időre nyomon tudjuk követni, hogy vannak-e olynak üzenetek, amiket a rendszer nem ismer 27

28 4.4. Üzenetek korrelálása és igény esetén ezeket is kezelni tudjuk. Az adatbázisszabályok képesek címkékkel ellátni az üzeneteket. A címkék alapján pedig további szűréseket lehet elvégezni az adathalmazon. Ezen lehetőség használatához a filter létrehozásánál használjuk a tags() opciót. A syslog-ng OSE 3.2-től kezdődően a rendszer automatikusan címkézi az üzeneteket aszerint, hogy ki küldte. A címkék ".classifier.<definialt_osztaly>" formátumúak, tehát ha például egy web szerver küld üzenetet, akkor az a ".classifier.webserver" címkét fogja kapni. Ezek a címkék alapján aztán további feldolgozási szabályokat lehet felállítani. A feldolgozott üzenetek egyes részei használhatók önálló makróként. Ehhez egy nevet kell adnunk ahhoz az értelmezőhöz, amit használni szeretnénk, majd ezt a nevet használva, mint egy makróra tudunk hivatkozni vele. Ha van például egy alkalmazásunk, ami a következő szerkezetű logokat küld: vmilyen-ertek: <típus>. ahol a típus egy karakterlánc, ami különböző értékeket vehet fel (pl.: alacsony, közepes, magas), akkor azt az alábbi sablonnal tudjuk lefedni: Ebben a sablonban egy értelmező, ami folytatja az üzenetrész feldolgozását a következő stop karakterig (jelen esetben a stop karakter egy pont (.) ezért a kifejezésben a második kettőspont után az jelenik meg). Ha ezt a sablont használni akarjuk később akkor, rendeljünk hozzá egy nevet, melyet az első és a második kettőspont közé kell beiktatni: Ezután meg a fent megadott néven tudunk rá hivatkozni. Szűrjük ki például az összes "közepes"-értékkel rendelkező üzenetet. Ekkor a sablonunk így néz ki: match("közepes" value("makro_nev")); 4.4. Üzenetek korrelálása A syslog-ng OSE 3.2-es verziójától kezdve lehetőség van a mintaadatbázisokkal azonosított üzenetek korrelálására. A log üzentek, mint azt már tudjuk, egy esemény leírására szolgálnak, de a különböző alkalmazások gyakran bontják több különböző log üzenetbe az egy eseményhez tartozó üzeneteket. A Postfix szerver például külön logba tárolja a küldő és a feladó címét. Az OpenSSH szerver, ha sikertelen bejelentkezést észlel, küld egy üzenetet a sikertelen autentikálásról majd egy másik üzenetet is küld, ami a hiba okát tartalmazza. Természetesen a nem ennyire szorosan kötődő üzenetek is állhatnak korrelációban egymással, vegyük például a ki és bejelentkezések log állományait. Az üzenetek korrelálásakor a syslog-ng a mintaadatbázis alapján fogja az összetartozó üzeneteket és beteszi egy csoportba, amit kontextusnak nevezünk. Ez a csoport 28