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

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

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: 2012. szeptember

................................. szakfelelős 2

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

1. szükséges (módosítás külön lapon) A szakdolgozat feladat módosítása 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):

..............

.............

..............

.............

..............

.............

3. 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

Tartalomjegyzék 1. Bevezetés

7

2. A naplózásról általában 2.1. A Windowsos naplózás . . . . . . . . . . . . . . . . . . 2.2. A Linuxos naplózás . . . . . . . . . . . . . . . . . . . . 2.2.1. Néhány log könyvtár . . . . . . . . . . . . . . . 2.2.2. Archiválás . . . . . . . . . . . . . . . . . . . . . 2.2.3. Hasznos eszközök . . . . . . . . . . . . . . . . . 2.2.4. Testreszabás . . . . . . . . . . . . . . . . . . . . 2.3. Hasznos funkciók a naplózó alkalmazásokban . . . . . . 2.4. Mire érdemes odafigyelni . . . . . . . . . . . . . . . . . 2.5. Naplózási technikák általánosan . . . . . . . . . . . . . 2.5.1. Log menedzsment (LM) . . . . . . . . . . . . . 2.5.2. Biztonsági adat és esemény menedzsment, avagy 2.6. Vállalati érettségi . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

9 9 10 11 11 12 13 14 16 16 16 17 18

3. Napló analízis 3.1. Funkciók és technikák . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. A korrelációról bővebben . . . . . . . . . . . . . . . . . . . . . . . . . .

20 21 21

4. Üzenetek feldolgozása a syslog-ng használatával 4.1. A naplóüzenetek struktúrája . . . . . . . . . . . . 4.1.1. BSD-syslog (RFC3164) . . . . . . . . . . . 4.1.2. IETF-syslog (RFC5424) . . . . . . . . . . 4.2. Naplóüzenetek osztályozása . . . . . . . . . . . . 4.3. Minta adatbázis használata . . . . . . . . . . . . 4.4. Üzenetek korrelálása . . . . . . . . . . . . . . . . 4.5. Műveletek beállítása azonosított üzenetekhez . . . 4.5.1. Feltételes végrehajtás . . . . . . . . . . . . 4.5.2. Külső műveletek végrehajtása . . . . . . . 4.5.3. Akciók és a korreláció . . . . . . . . . . . 4.6. Minta adatbázis létrehozása . . . . . . . . . . . . 4.6.1. Minta feldolgozók használata . . . . . . . 4.6.2. A V4 minta adatbázis formátum . . . . .

. . . . . . . . . . . . .

23 23 23 25 26 27 28 30 30 30 31 31 31 33

5. A biztonság és a syslog-ng 5.1. Titkosított üzenettovábbítás . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. A naplóbejegyzések kódolása a TLS segítségével . . . . . . . . . 5.2. Üzenetvesztés, mikor és hogyan? . . . . . . . . . . . . . . . . . . . . . .

36 36 38 39

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . a .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIEM . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

5

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével . . . . . . 5.3.1. A flow-control és a többszörös üzenettovábbítás . . . . . . . . .

40 42

6. Összefoglalás

44

Irodalomjegyzék

45

Adathordozó használati útmutató

47

6

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

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

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 2012. 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.

2.1. 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

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.

2.2. 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

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.

2.2.1. 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. . . )

2.2.2. 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

2.2. A Linuxos naplózás

2.2.3. 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 / l o g / 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 / l o g / s e c u r e 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 / l o g / 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

2.3. Hasznos funkciók a naplózó alkalmazásokban

2.2.4. 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 a r e f i r s t , s t o r e d i n t h e k e r n e l # f i l e , c r i t i c a l messages and h i g h e r ones a l s o go # t o a n o t h e r h o s t and t o t h e c o n s o l e # kern . ∗ / var /adm/ k e r n e l kern . c r i t @magyarhon kern . c r i t / dev / c o n s o l e kern . i n f o ; kern . ! e r r / var /adm/ k e r n e l −i n f o 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

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

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 e-mail 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

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.

2.5. 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.

2.5.1. 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

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.

2.5.2. 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

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. 2012 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.: e-mail, 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.

2.6. 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

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

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

3.2. A korrelációról bővebben

3.1. Funkciók és technikák 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.

3.2. 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

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

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.

4.1.1. 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

4.1. A naplóüzenetek struktúrája Numerikus érték

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

16-23

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 HEADER rész 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

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.

4.1.2. 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

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.

4.2. 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

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 {db_parser(file(""));}; É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 ( " v i o l a t i o n " value ( " . c l a s s i f i e r . c l a s s ") type ( " s t r i n g " ) ); }; log { s o u r c e ( minden_forras ) ; p a r s e r ( 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

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: . 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: vmilyen-ertek: @ESTRING::.@ Ebben a sablonban az @ESTRING@ 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: vmilyen-ertek: @ESTRING:makro_nev:.@ 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 e-mail 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

4.4. Üzenetek korrelálása olyan üzenetek sorozatából áll melyek valamilyen módon kapcsolatban állnak egymással. Amikor új üzenet érkezik, a feldolgozó megvizsgálja azt, majd ha arra van szükség, akkor hozzácsatolja a kontextus tartalmához. Úgyszintén egy új üzenet kiválthat bizonyos akciókat, például küld egyetlen összefoglaló üzenetet, ami tartalmazza a kontextus összes üzenetének lényegesebb információit, de erről részletesebben a következő fejezetben beszélünk. Két attribútum áll rendelkezésünkre annak eldöntése végett, hogy az üzenet ami illeszkedik egy meghatározott szabályra része vagy nem része egy kontextusnak, ezek pedig a: context-scope és a context_id attribútumok. A context-scope viselkedése hasonló az előzőekben tárgyalt filterekéhez. Kiszűri az üzeneteket, amelyek azonos processztől (használhatók a ${HOST}, a ${PROGRAM} és a ${PID} jelölők is), azonos alkalmazástól (${HOST} és a ${PROGRAM} jelölők élnek), vagy azonos hosztól érkeznek. A context_id feladata, hogy az üzenetet hozzácsatolja az ID-ban definiált kontextushoz. Ez az azonosító lehet egy karakterlánc vagy tartalmazhat makrókat, esetleg magából a logból kinyert értékeket a később szűrések céljából. A most bemutatott két eszköz mellett van egy harmadik, a context-timeout attribútum, melynek segítségével azt állíthatjuk, hogy a kontextust a rendszer meddig tartsa fent, vagyis, hogy a syslog-ng OSE meddig várjon a következő korreláló üzenet megérkezéséig. Ha új üzenet kerül hozzáadásra a kontextushoz, akkor a számláló újraindul. Amikor az időkalkuláció folyik annak eldöntésére, hogy a timeout érték elmúlt-e vagy sem, a syslog-ng OSE a beérkező üzenetek időbélyegét használja, nem pedig a két üzenet beérkezése között eltelt rendszeridőt. Ennek a funkciónak köszönhetően a syslog-ng képes a már létező logokat offline korrelálni, ha szükséges. Elméletileg a logok időrendi sorrendben vannak (az A2_log_időbélyege > A1_log_időbélyege), de megtörténhet, hogy egy üzenet időbélyege újabb, mint a rendszeridő (mintha az üzenet a jövőből jött volna) , ekkor a rendszer az időt automatikusan az aktuális rendszeridőre cseréli. A timeout érték megfelelő megválasztása igen fontos, hiszen a sok üzenetet tartalmazó kontextusok jelentős mennyiségű memóriát emészthetnek fel, így a megválasztásuknál érdemes az elégséges minimum értéket beállítani. Ha egy alkalmazás 20 másodpercen belül elküldi az összes szükséges üzenetet, akkor felesleges a kontextust életben tartani órákig. Amikor együtt használjuk a elemet a mintaadatbázis szabályokban a korrelációval, lehetőségük nyílik az adott kontextus korábbi üzeneteire hivatkozni úgy, hogy a @ utótagot illesztjük a makróhoz. Az előbb elmondottakat egy példán keresztül lehet a legjobban szemléltetni: Tegyük fel, hogy van 3 üzenetünk a kontextusban, és a harmadikhoz beállítunk egy üzenetet. Ekkor a ${HOST}@1 kifejezés az aktuális üzenet (vagyis az időben a legkésőbb érkezett) hoszt értékére fog mutatni. Így tovább a ${HOST}@2 kifejezés a második üzenet re vonatkozik, míg a ${HOST}@3 az utolsó üzenetet (vagyis amelyik legelőszőr érkezett) célozza meg. Ezek alapján alkossunk meg egy üzenetet, ami egy feltételezett SSH 29

4.5. Műveletek beállítása azonosított üzenetekhez szerverről érkezett logokat használ fel: Az SSH kapcsolat a ${SSH_CLIENT_ADDRESS}@3 címről érkező, ${SSH_USER_NAME}@1 nevű felhasználónak véget ért. A kapcsolat ${SSH_SESSION_DATE}@2 -tól/től, ${SSH_SESSION_DATE} -ig tartott.

4.5. Műveletek beállítása azonosított üzenetekhez Ahogy az előzőkben láthattuk, a syslog-ng OSE generálni (triggerelni) üzeneteket automatikusan, ha egy bizonyos esemény bekövetkezik, például egy meghatározott log érkezik, vagy egy kontextus nem kapja meg a megfelelő üzeneteket az időkorlát lejárata előtt. Alapjában véve minden mintaadatbázis szabályhoz hozzárendelhetünk ilyen üzeneteket, amiket akkor küld a rendszer, amikor egy szabálynak megfelelő üzenet érkezik. Az ilyen üzenet-hozzárendelések az esetek túlnyomó többségében a korrelációval szorosan együtt vannak használva, de természetesen külön is használhatók. Alapértelmezetten a generált üzenetek oda lesznek irányítva, ahova a db_parser kifejezés hivatkozik a log útvonalban. Ha szeretnénk a syslog-ng belső logjaként küldeni, használjuk a inject_mode(internal) beállítást. Ekkor a logok oda kerülnek ahova a syslog-ng alapértelmezetten logol. A generált üzeneteket a mintaadatbázis szabályban kell konfigurálni. Ahhoz hogy minél beszédesebb üzeneteket alkossunk, használjunk a makrókat illetve az üzenetekből kinyert értékeket. A név-érték párosok örökíthetők az üzenetekből. Ehhez állítsuk a <message> elem inherit-properties attribútumát TRUE értékre. Ekkor az üzenet, ami kiváltja a generált üzenet létrehozását klónozva lesz és tartalmazni fogja a név-érték párokat és a különböző címkéket is. Ha ezután az elem bármely üzenetében beállítunk egy értéket, akkor az felülírja majd az eredeti üzenetben szereplőket.

4.5.1. Feltételes végrehajtás Ahhoz, hogy szabályozzuk, egy üzenet generálódását használhatunk feltételes kifejezéseket. Ezt a condition attribútum segítségével tehetjük meg, ami után egy szűrő kifejezést (feltételt) kell meadnunk. A fenti kódrészlet például csak akkor generál üzenetet, ha a hoszt megegyezik az idézőjelek között megadott értékkel.

4.5.2. Külső műveletek végrehajtása Egy külső művelet végrehajtásához (mondjuk, a rendszer küldjön e-mail értesítést, ha egy adott üzenet ékezik) a generált üzenetet át kell irányítani egy külső alkalmazáshoz a program() opció segítségével. Ezt bemutatandó tekintsük az alábbi példát: 1. A generált üzenetben állítsunk be egy mezőt, amit könnyű azonosítani és szűrni:

30

4.6. Minta adatbázis létrehozása Log ü z e n e t ${HOST} −t ő l . Egyező s z a b á l y száma : $ . c l a s s i f i e r . r ule _id t r i g g e r 2. Hozzunk létre egy célállomást, ami az üzenetet fogja feldolzoni: d e s t i n a t i o n s a j a t _ t r i g g e r s { program ( " / b i n /myProgram " ; ) ; } ; 3. Hozzunk létre egy szűrőt, ami kiszűri a generált üzenetet a belső logok közül: filter sajat_filter { match ( " t r i g g e r " v a l u e ( "TRIGGER" ) type ( s t r i n g ) ) ; }; 4. Hozzunk létre egy log útvonalat, ami kiválasztja a generált üzeneteket és elküldi az adot programnak: log { source ( s_local ) ; filter ( sajat_filter ); destination ( sajat_triggers ) ; } ; 5. Állítsuk be a programot, ami feldolgozza az üzenetet vagy írjuk meg hozzá a szkriptet.

4.5.3. Akciók és a korreláció Az automatikus log generálás bizonyos funkciói csak akkor használhatóak, ha ugyanakkor a korrelálás is használva van. Ilyen például az automatikus kitöltés. A syslog-ng OSE automatikusan kitölti a generált üzenet egyes mezőit az adott kontextus alapján. Lehetséges úgy üzenetet generálni, hogy a kontextus timeout-ja már lejárt és nem érkezett új üzenet bele. Ehhez az elem trigger attribútumát "timeout"-ra kell állítani.

4.6. Minta adatbázis létrehozása 4.6.1. Minta feldolgozók használata A mintafeldolgozók (angolul pattern parsers) célja, hogy az üzenetek egyes részeit automatikusan feldogozzák egy szabály vagy szabályrendszer alapján, amit a feldolgozó típusa határoz meg. A feldolgozókra vonatkozó szintaktikai szabályok a következők: • A kezdő karakter mindig a @ szimbólum • A feldolgozó neve nagybetűkkel írandó 31

4.6. Minta adatbázis létrehozása • Név opcionálisan megadható • Megadhatók a paraméterek, ha vannak • A részeket a : szimbólum szeparálja • A lezáró karakter szintén a @ szimbólum Egyszerű feldolgozó: @STRING@ Névvel ellátott feldolgozó: @STRING:feldolgozo_neve@ Névvel és paraméterrel ellátott feldolgozó: @STRING:feldolgozo_neve:*@ Név nélküli paraméterezett feldolgozó: @STRING::*@ A minták és a literálok tetszés szerint keverhetők. Például ha szeretnénk egy üzenetet feldolgozni, amely úgy kezdődik hogy "Küldő: ", majd ezután egy e-mail cím követi (pl.: Küldő: [email protected]), akkor a minta így fog kinézni: Küldő:@EMAIL@ A következőkben áttekintjük, a syslog-ng OSE-ben alkalmazható minta feldolgozókat, és röviden ismertetésre kerül a funkciójuk. • @ANYSTRING@ Feldolgoz mindent az üzenet végéig. Használatával begyűjthetünk az üzenetből minden olyan elemet, adatot, amit az egyéb makrók illetve feldolgozók nem használtak fel. • @DOUBLE@ Ez a @FLOAT@ egy elavult, alias-a, használata egyre ritkább. • @EMAIL@ E-mail címek illesztésére használatos értelmező. Paramétere egy karakterhalmaz, a címet határoló karakterekből. Segítségével az egyéb karakterek által határolt e-mail címek könnyen kiemelhetők. Például a @EMAIL:email:[]<>{}"@ feldolgozó az alábbi címeket tudja értelmezni: [[email protected]]; ; {[email protected]}; "[email protected]" • @ESTRING@ Ez az értelmező átemel mindent az üzenetből egészen, amíg nem találkozik a stop karakterrel. A stop karakter egy kötelező paramétere ennek a feldolgozónak. • @FLOAT@ Lebegő pontos számok értelmezésére használatos. A számok tartalmazhatnak egyetlen . (pont) karakter. • @HOSTNAME@ Egy általános hoszt nevet dolgoz fel. A hoszt név csak alfanumerikus karaktereket (A-Z, a-z, 0-9), kötőjelet vagy pontot tartalmazhat. • @IPv4@ Egy IPv4 típusú címet dolgoz fel. A számok maximum 3 pont által határoltak lehetnek. (pl.: 127.0.0.1)

32

4.6. Minta adatbázis létrehozása • @IPv6@ IPv6 típusú címeket dolgoz fel (pl.: 2001:0:9d38:953c:18ae:2eaf:53ed:f8f3). • @IPvANY@ Bármilyen egyéb IP címet vár. • @LLADDR@ Link Layer Address feldolgozó. A címek szerkezete a xx:xx:xx:. . . formát követik, ahol minden egyes xx tag egy 2 számjegyből álló hexadecimális szám (oktett). A paraméterben megadott szám határozza meg hogy hány darab ilyen oktettet vár az értelmező. A @MACADDR@ egy speciális esete ennek a feldolgozónak. • @MACADDR@ Az MC-48-as formátumú címek feldolgozására szolgáló értelmező. 6 csoport egyenként kettő darab hexadecimális számból álló cím értelmezésére szolgál, ahol a csoportokat kettőspont választja el egymástól. • @NUMBER@ Decimális számsorozatok (0-9) feldolgozására való. Ha a számsor a 0x előtaggal kezdődik, akkor hexadecimális számként lesz értelmezve, de csak akkor, ha a 0x tagot legalább egyetlen érvényes szám követi. A kezdő kötőjel elfogadott nem hexadecimális számok esetében, de már szeparátor már nem. • @PCRE@ Perl-Compatible Regular Expresson. Perl kompatibilis reguláris kifejezés végrehajtására szolgál. • @QSTRING@ A paraméterben megadott szeparátor karakterek közötti szöveget dolgozza fel. A szeparáló karakterek eltérhetnek az adott szöveg elején és a végén. Például a @QSTRING::"@ olyan szöveget vár, ami idéző jelek között van, a @QSTRING::#@ értelmező viszont olyan szöveget ami - jellel kezdődik és # jellel végződik. A @ karakter nem lehet szeparátor, illetve sortörés és tabulátor karakterek sem. • @SET@ A paraméterben megkapott karakterek tetszőleges kombinációját dolgozza fel, egészen addig, amíg másik karaktert nem talál. Például ha szóköz karaktert adunk meg neki, akkor a különböző logokban található helyközöket tudjuk feldolgozni, ahol mondjuk a felhasználó név után 5-10 szóköz van formázás miatt. • @STRING@ Alfanumerikus karakterek (A-z, 0-9) sorozatának feldolgozója, kivétel a szóköz. Ha szükséges, akkor paraméterben további karaktereket lehet felsorolni.

4.6.2. A V4 minta adatbázis formátum A minta adatbázisok olyan XML file-ok, melyek egy üzenet sémát leíró szabályokat tartalmaznak. Ebben a fejezetben a mellékletek között található dlink.xml nevű állományon keresztül mutatom be a minta adatbázisok szerkezetét. XML állományról lévén szó az első sor az xml verziót és a kódolási típust hívatott definiálni: 33

4.6. Minta adatbázis létrehozása Ezt követi a <patterndb> elem, ami az állomány gyökere. Ennek van egy version és egy pub_date attribútuma. Az első a verziót a második pedig a file publikálásának idejét tárolja.

A következő elem a ami a szabályok konténere. Ez foglal magába minden szabályt, amit az állományban definiálunk. Két kötelező paramétere a name és az id. Az első a halmaz nevét, míg a másik a program egyedi azonosítója. < r u l e s e t name="D−l i n k DFL−210/260/800/860/1600/2500" i d ="67 e 8 f 1 9 9 −67ed −433b−94d4 −479535 f e 7 9 5 8"> Opcionális elem a description, ami egy leírást ad hozzá, és az url, ami egy link lehet, ahol több információt szerezhetünk az alkalmazás szabályhalmazáról. Ezután szintén egy konténer elem a következik. Ez közvetlenül magában foglalja a szabályokat. A szabályok definiálása a és a elemek között történik. A rule olyan elem, ami tartalmazza az üzenet sémáját illetve azt, hogy az erre a sémára illeszkedő üzenetek hogyan legyenek osztályozva. Az id a szabály globális egyedi azonosítója, a class az üzenet osztálya lesz, a provider pedig a szabályt szállító erőforrás, jelen esetben a balabit. Opcionálisan megadható attribútumok a context-id, context-timeout, context-scope. A context-id egy azonosító, ami az összetartozó logokhoz adható meg. Ez akkor lehet hasznos, amikor az üzeneteket korrelálják. A context-timeout az az érték, amíg a kontextus tárolódik a memóriában. A context-scope határozza meg, mely üzenetek tartoznak egy kontextusba. A következő elem a <patterns> elem, ami a szabály mintáját tartalmazza. Ha az elem több <pattern> elemet is tartalmaz, akkor a elem osztálybesorolása az összes <pattern> elemre érvényes lesz. A <pattern> elem írja le magát a log üzenetet. Ezt az elemet szokás üzenet mintának is hívni.

ALG s e s s i o n opened

A szabály leíró tartalmazhat még <description> elemet is. Ez lényegében egy leírás a mintára illeszkedő log üzenetről. Szintén opcionális elem lehet az , ami több elemet is tartalmazhat, ahonnan extra információt szerezhetünk. Felvehetünk még konténert, ami több elemet tartalmazhat. A elem attribútuma a name, ami a név-érték páros neve. Ezt később aztán használhatjuk makróként, hogy elérjük közvetlenül az értéket.

34

4.6. Minta adatbázis létrehozása A következő fontos elem a <examples> ami egy konténer objektum. Ebben olyan log üzenet példáknak kell lennie amit a szabálynak fel kell ismernie. Az <examples> objektum, <example> elemeket foglal magába. Ezen belül lehet elem, ami egy teszt üzenet amit a szabálynak fel kell ismernie, továbbá lehet benne elem ami elemeket foglal magába. Ez utóbbi azokat az értékeket tartalmazza, amiket az értelmezőnek fel kell vennie miután az üzenetet feldolgozta. <examples> <example> Maximum l i n e l e n g t h 150 exceeded , g o t 200 c h a r a c t e r s . C l o s i n g c o n n e c t i o n . 150 200 Ha azt szeretnénk, hogy történjen, egy bizonyos esemény az üzenet feldolgozása közben akkor használjuk az opcionális konténert. Az -on belül elemekkel definiálhatjuk a művelet pontos paramétereit. Az elem attribútumai a condition, a rate és a trigger. Az első egy syslog-ng szűrő kifejezés, a második meghatározza hány üzenet generálódhat a megadott időintervallumban, a harmadik pedig meghatározza, hogy mikor legyen az akció végrehajtva. A trigger attribútumnak a lehetséges értéke a match, amikor az akció egyből az üzenet feldolgozásakor hajtódik végre, és a timeout ami egy időbeni eltolást jelent. Az elemnek van még továbbá egy <message> és egy eleme is. A <message> egy konténer elem, ami azt az üzenetet tartalmazza, ami elküldésre kerül a meghatározott akció végrehajtásakor. A szintén egy konténer elem, ami azokat az értékeket és mezőket tartalmazza, melyekből a generált üzenet előáll. Az üzeneteket tudjuk címkézni is. Ehhez a konténer használatos. Ezen belül vehetünk fel elemeket, amik tartalmazzák azokat a kulcsszavakat melyek alapján később szűrhetünk illetve szelektálhatunk. UserLogin

35

5. fejezet A biztonság és a syslog-ng 5.1. Titkosított üzenettovábbítás A syslog-ng alkalmazás képes az üzenetek biztonságos továbbítására és fogadására a hálózaton keresztül. Ehhez az úgynevezett TLS (Transport Layer Security) protokollt használja. A TLS protokoll egy titkosítási eljárás melynek segítségével anélkül valósíthatunk meg adatkapcsolatot, hogy annak lehallgatásától esetleges manipulálásától kellene félnünk. A legtöbb napjainkban elérhető üzleti alkalmazás támogatja ezt a biztonsági funkciót. Ahhoz, hogy a kliens-szerver koncepcióban ez a funkció használható legyen, elengedhetetlen, hogy a kliens jelezze a szerver felé azt, hogy használ-e TLS-t vagy sem. Erre kettő lehetőség adódik: az egyik hogy egy erre kihegyezett csatornát tartunk fenn az ehhez hasonló adatáramlás-oknak (pl.: https - 443-as port), a másik, hogy egy szabványos porton való kommunikáció során a kliens kéri a szervert, hogy használja a TLS-t is valamilyen protokoll-specifikus eljárás segítségével. A TLS úgynevezett rekordok segítségével kommunikál, mely nem más, mint egységbezárt adatok halmaza. Minden ilyen rekordot lehet tömöríteni, titkosítani illetve kiegészíthető úgynevezett "Message Authentication Code"(MAC)-al is. A rekordok jellemzően tartalmaznak legalább 3 mezőt melyek a tartalom típus, hossz és a TLS verzió. Egy egyszerű TSL kapcsolat kiépülése az alábbi minimális és elégséges lépésekből áll: Tárgyalási fázis • A kliens elküldi a ClientHello üzenetet a szervernek. Emellett még néhány egyéb adatot is tartalmaz: legnagyobb támogatott TLS verziószáma, egy random szám, egy titkosítási metódust és egy javasolt tömörítési algoritmust. • A szerver válaszol egy ServerHello üzenettel, ami tartalmazza a kiválasztott protokoll verziószámot és titkosítást, egy véletlen számot és a tömörítési algoritmust. • A szerver küld egy Certificate üzenetet (ez a rész protokollfüggő nem minden esetben következik be). 36

5.1. Titkosított üzenettovábbítás • A szerver küld egy ServerHelloDone üzenetet mellyel jelzi, hogy a tárgyalási fázis befejezettnek tekinti. Második fázis: • A szerver küld egy ChangeCipherSpec rekordot, ami gyakorlatilag a titkosított adatfolyam kezdetét jelöli a szerver oldalról. Ez a rekord önmagában egy rekord szintű protokoll is 20-as típusú tartalomtípussal. (erről bővebben kicsivel később) • A szerver küld egy kódolt Finished üzenetet, amely tartalmaz egy hash-t és egy MAC-et a tárgyalási fázisból. • A kliens megpróbálja dekódolni az üzenetet majd ellenőrizni az adatokat. Ha ez sikertelen, akkor a kapcsolódás megszakad. Harmadik fázis: • A kliens küld egy ChangeCipherSpec rekordot, amivel jelzi a szerver felé, hogy most már a tőle érkező adatok is titkosítva vannak. • A kliens is elküldi a maga titkosított Finished üzenetét. • A szerver ezt dekódolja és ellenőrzi, ha ez sikertelen, akkor a kapcsolat megszakad. Alkalmazási fázis: Ezen a ponton a kézfogás-szakasz kész van, és a protokoll engedélyezve van a 23as tartalomtípussal. Az üzenetek, amik a szerver és a kliens között közlekednek, ugyanúgy vannak titkosítva, mint a Finish üzenetek. A TLS tehát egy titkosító protokoll a TCP/IP protokoll felett, ezért tehát csak TCPalapú források és célállomások esetén lehet használni. Amikor a syslog-ng felek építik ki a kapcsolatot, akkor a kliens elkéri a szerver tanúsítványát és a publikus kulcsát és ezekkel autentikálja a szervert. Opcionálisan a szerver szintén elkérheti a kliens tanúsítványát és a kétirányú autentikáció is megoldható, ha a helyzet indokolja azt. Ahhoz, hogy használni lehessen a TLS titkosítást két dolognak kell teljesülnie: • Lennie kell egy tanúsítványnak a szerveren, ami a szervert azonosítja • A kliensnél meg kell lennie a tanúsítvány kibocsátó hatóság (CA - certification authority) által kiadott szerver autentikáló tanúsítványnak Ha kölcsönös azonosítást akarunk kiépíteni akkor a szempontok az alábbiak szerint bővülnek: • Lennie kell egy tanúsítványnak a kliensen, ami a klienst magát azonosítja • A szervernél meg kell lennie a tanúsítvány kibocsátó hatóság által kiadott kliens azonosító tanúsítványnak A kölcsönös azonosítás egyértelmű előnye, hogy biztosítható vele, hogy a syslog-ng szerver csak azonosított kliensektől fogad el napló üzeneteket. 37

5.1. Titkosított üzenettovábbítás

5.1.1. A naplóbejegyzések kódolása a TLS segítségével Ebben a fejezetben ismertetésre kerül a TLS titkosítás beállításának menete néhány egyszerű lépésben. Vélhetően ezután az olvasó maga is képes lesz a jövőben ezeket az egyszerű, ám igen hasznos beállításokat elvégezni. Első körben a kliens beállításai kerülnek ismertetésre. Első lépésként kreáljunk a szerverünkhöz egy X.509-es certifikációt . Ez lényegében egy igen egyszerű tanúsítvány formátum, mely hozzárendel egy nevet egy bizonyos nyilvános kulcs értékhez. A feladata pedig, hogy a tanúsítványban foglalt azonosító adatokat hozzákösse a nyilvános kulcs értékhez. Ha ezzel megvagyunk, akkor vegyük a hatóság által elkészített tanúsítványunkat (ami a syslog-ng szerverhez tartozik) és másoljuk fel az összes kliens gépre, ha lehet mindenhol ugyanazon az elérési útvonalon legyen, pl.: /opt/syslog-ng/etc/syslog-ng/ca.d az elérési utunk a jelen esetben. Hajtsuk végre az alábbi parancsot: openssl x509 -noout -hash -in testcert.pem. Vegyük észre, hogy a parancsban szereplő testcert.pem az a tanúsítvány, amit a megfelelő helyre az imént bemásoltunk minden gépre. Ha mindent jól csináltunk, akkor egy hash érték lesz a parancs eredménye pl.: 2f97d5a9b. Ez a sztring lényegében számok és betűk sorozata, de jelen esetben pont erre van szükség. Adjuk ki az alábbi utasítást: ln -s testcert.pem 2f97d5a9b.0 Ennek hatására létrehozunk egy szimbolikus linket a tanúsítványhoz, ami használja az előbb generált hash-t és a ’.0’ végződést. A második lépésben konfiguráljuk a syslog-ng klienst a tanúsítvány használatára. Ehhez nem kell mást tenni, mint hozzáadni egy ’célállomás kifejezést’(destination statement) a konfigurációs állományhoz, melybe beillesztjük a tls(ca_dir(tanusítvány_elérési_utvonala)) opciót, amiben definiáljuk a tanúsítvány elérési útvonalát. A célállomásnak a tcp() vagy a tcpv6() driverek egyikét kell használnia, és az IP cím és port paramétereknek a syslog-ng szerverre kell mutatnia. Példa: Nézzük egy egyszerű példát a fentiekre: d e s t i n a t i o n demo_tls_settings { tcp ( " 1 0 . 1 . 2 . 3 " port (1234) t l s ( ca_dir ( " / opt / s y s l o g −ng/ e t c / s y s l o g −ng/ ca . d " ) ) );}; Ugyanezen bejegyzés a syslog() driver használatával így néz ki: d e s t i n a t i o n demo_tls_syslog_destination { syslog ( " 1 0 . 1 . 2 . 3 " port (6514) transport (" t l s ") 38

5.2. Üzenetvesztés, mikor és hogyan?

};

port (3214) t l s ( ca_dir ( " / opt / s y s l o g −ng/ e t c / s y s l o g −ng/ ca . d " ) ) ) ;

Harmadik lépésként csupán annyi a maradék teendőnk, hogy a második lépésben létrehozott célállomást beillesztjük a log kifejezésbe (log statement). Ezzel készen van a kliens oldali konfiguráció. Érdemes odafigyelni arra, hogy ha a szerver tanúsítványa vagy a "common name" vagy a "subject_alt_name" paraméter nem tartalmazza a hoszt nevét vagy az IP címét a szervernek. Ha mindent jól beállítottunk már csak egy dologra kell odafigyelni: a tanúsítványokat a lejártakkor, de inkább előtte frissíteni kell ellenkező esetben egész fürtök állhatnak le, ahogy az a Microsoft felhős szolgáltatásával az Azure -al is történt nemrégiben.

5.2. Üzenetvesztés, mikor és hogyan? Egy üzenet életciklusa alatt, amíg a "szülőhelyétől" meg nem érkezik a rendeltetési vagy tárolási helyére számos olyan pont lehet, ahol úgymond eltévedhet, még akkor is, ha a syslog-ng a tőle telhető legjobb módon igyekszik eljárni az információval. Az esetek túlnyomó többségében az üzenetvesztés elkerülhető az infrastruktúra körültekintő konfigurálásával. Ebben a fejezetben felsorolásra kerülnek a leggyakoribb okok, amelyek üzenetvesztést eredményezhetnek. Az első ilyen pont az üzenetküldő alkalmazás és a syslog-ng között van. Meg kell bizonyosodni arról, hogy a megfelelő forrást állítottuk be, ahhoz hogy a log-ok az alkalmazástól a naplózó rendszerig érjenek. Érdemesebb például unix-stream-et használni a unix-dgram helyett. Egy másik kritikus pont, amikor a syslog-ng küldi az üzenetet. Ha ugyanis nem képes továbbjuttatni azt és a kimeneti puffer megtelik, akkor az adott üzenete(ke)t eldobja. Ilyen esetek elkerülése végett használjuk flag-eket (lásd később). Az állomásonként eldobott üzenetek számát meg tudjuk tekinteni a syslog-ng statisztikái között. A hálózat sajátosságai is okozhatnak üzenetvesztést. Ha UDP protokollt használunk, a kommunikáció során könnyen előfordulhat, hogy 1-2 üzenet anélkül vész kárba, hogy arról semmilyen értesítést nem kapunk. Ez sajnos az UDP protokoll természete miatt fordulhat elő, ugyanis amikor az UDP -n küldött üzenet eléri a fogadó felet, akkor ott bekerül egy tárolóba a memóriában, amit úgy neveznek: socket receive buffer. Ha a fogadó fél több üzenetet kap, mint amennyit ebben a pufferben tárolni képes akkor az túlcsordul, és a kernel eldobja a felesleget anélkül, hogy a syslog-ng-t értesítené róla. Ezt elkerülni a TCP protokoll használatával tudjuk. Abban az esetben, amikor nem lehet a protokollt TCP-re cserélni, használjuk a so_rcvbuf() opciót a puffer méretének növelésére. Amikor a syslog-ng üzenetet kap, szintén elfordulhat, hogy adatvesztést tapasztalunk. Ez főképp akkor történhet meg, amikor a célállomány fifo-ja (más nevén a 39

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével syslog-ng kimeneti puffere) megtelik. Az eldobott üzenetek számát a syslog-ng statisztikai log-ja tartalmazza. Ha a fogadó félnél túrterhelés jelentkezik, akkor van rá esély, hogy adatvesztéssel kell számolnunk. Ha a syslog-ng nagy sebességgel küld üzeneteket például egy SQL adatbázisnak, egy fájlnak vagy egyéb célállomásnak megtörténhet, hogy az adott fogadó fél nem győzi a bejövő adathalmazt és csak lassan dolgozza fel azt. Ekkor a syslog-ng előbb utóbb feltölti a puffereket és utána nem fogja tudni kezelni a bejövő üzeneteket így üzenetvesztés lép fel. Végül, de nem utolsó sorban veszteséggel kell számolnunk a syslog-ng szerver helytelen leállítása miatt is. Ha a gép amelyik hostolja a syslog-ng szervert egy helytelen leállítást érzékel, időbe telik mire a kliensek észlelik a kapcsolódás megszakadását. Azok az üzenetek, amelyek ebben az időszeletben kerülnek a TCP kimeneti bufferjébe nem lesznek elküldve a szervernek.

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével Ebben a fejezetben górcső alá kerül a syslog-ng belső üzenet feldolgozó modellje, illetve a flow-control (nyersfordításban: folyamirányítás) működése, mellyel megakadályozhatjuk az előzőekben taglalt üzenetvesztéssel járó eseteket. A flow-control használatához a flow-control flag-nak engedélyezve kell lennie az adott log útvonalon (log path). A syslog-ng alkalmazás folyamatosan monitoroz minden, a konfigurációs fájlban beállított forrást és periodikusan végigellenőrzi mindet, hogy van-e üzenete. Ha talál egy új üzenetet egy forrásnál, akkor végigiterálja mindet és beolvassa az új üzeneteket. Ezekhez az üzeneteket aztán feldolgozza, majd utána a kimeneti tárolóba (output-buffer vagy ahogy korábban említettük fifo) küldi őket. Ebből a tárolóból aztán az operációs rendszer küldi tovább az üzeneteket a megfelelő célállomásra. Nem nehéz belátni, hogy egy nagy forgalmú környezetben rengeteg üzenet kerülhet beolvasásra egyetlen ciklus alatt, ezért a syslog-ng egyetlen körben csak meghatározott számú üzenetet olvas be minden forrásból. Ezt a log_fetch_limit() opcióval tudjuk módosítani. Egyértelműen látszik, hogy az itt megadott érték kritikus fontosságú, hiszen ha túl alacsony, akkor az üzenetek nem lesznek elég gyorsan feldolgozva és lassul a rendszer, esetleg üzeneteket vesztünk, ha pedig feleslegesen túl nagyra állítjuk, akkor roppant erőforrásokat igényelhet az alkalmazás, ami pedig szintén akadozásokhoz vagy rosszabb esetben (ha több erőforrást kér annál ami van) kritikus leállásokhoz vezethet.

Minden állomásnak megvan a maga saját kimeneti tárolója. Erre azért van szükség, 40

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével mert az adott állomás nem feltétlenül képes fogadni az összes üzenetet egyszerre, ezzel azonban kap egy kis időt, hogy "összeszedje" magát. Ennek a tárolónak az értékét a log_fifo_size() paraméterrel tudjuk állítani, és úgy kell megválasztani, hogy a mérete nagyobb legyen, mint a log_fetch_limit() értéke, így biztosítva, hogy minden, egy ciklusban beolvasott üzenet, elfér a tárolóban. Ha a log-path több forrásból küld üzenetet egyetlen célállomás felé, akkor úgy kell a tároló értékét megválasztani, hogy az összes üzenet beleférjen. A TCP és a unix-stream források több, különböző kapcsolaton keresztül is kaphatnak üzeneteket (pl.: sok eltérő kliens, vagy különböző alkalmazások). Ilyenkor a syslog-ng minden egyes kapcsolatból külön-külön kiolvassa az üzenetet, így a log_fetch_limit() paraméter a forráson belül minden kapcsolatra külön-külön vonatkozik.

A syslog-ng folyam irányítója (továbbiakban flow-control) gyakorlatilag egy keretet rendel a forrásokhoz, ami azt jelöli még mennyi üzenetet képes a syslog-ng az adott forrástól elfogadni. Minden egyes üzenet, amit a rendszer beolvas, eggyel csökkenti ezt a keretet, és értelem szerűen minden üzenet, ami elküldésre kerül a fifo-ból eggyel növeli ezt az értéket. Ha ez a keret megtelik (az értéke zérus lesz) a syslog-ng leállítja az üzenetek beolvasását az adott forrás felől. A keret alapértelmezett értéke 1000. Ennél az értéknél kell nagyobbnak lennie a log_fifo_size()-nak, hogy a flow-control hatékonyan tudjon működni. Ha egy forrás több kapcsolattal rendelkezik, akkor a keret értéke magára a forrásra vonatkozik, tehát minden egyes kapcsolat ugyanazt az értéket növeli vagy csökkenti. Itt megjegyzendő, hogy a syslog-ng OSE 3.3-tól felfelé a több kapcsolatú források esetében a keret meghatározott értékét elosztják a kapcsolatok számával, majd az így kapott érték lesz az egyes kapcsolatok maximális keret értéke. Ezzel küszöbölődik ki az egyenlőtlen kihasználtság, hiszen ha például 1000-es keretértékre jut 30 kapcsolat, és ebből mondjuk 6 kapcsolat felemészti a keret 70%-át akkor a maradék kapcsolatok lehet, hogy nem tudnak kielégítően működni, és így adatvesztés léphet fel. Az osztott keret bevezetésével minden egyes kapcsolat ugyanakkora szeletet kap. Tehát amikor flow-control-t használunk, minden forrásnak megvan a maga kerete. Minimális esetben pedig, a célállomás kimeneti tárolójának elegendően nagynak kell lennie, hogy kezelni tudja keretmennyiség összes üzenetét, tehát a log_fifo_size()nak (célállomásonként) nagyobbnak kell lennie, mint a number_of_sources* log_iw_size() értéknek. Ez vonatkozik minden forrásra, ami üzeneteket küld az adott célállomáshoz. Éppen ezért ha van két forrásunk számos kapcsolattal és erősen forgalmaznak ugyanahhoz az állomáshoz, a keretnek elegendően nagynak kell lennie, hogy beleférjen mindekét forrás kimeneti tárolója. Ha ez nem teljesül, akkor a syslog-ng nem aktiválja a flow-control-t és ezáltal üzenetvesztés léphet fel.

41

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével A syslog-ng kimenő üzenetkezelő logikáját az alábbi ábra szemlélteti:

• Output queue (kimenő sor): Az üzenetek ebből a tárolóból egyenesen az adott syslog-ng szerverhez kerülnek elküldésre. A syslog-ng alkalmazás a kimenő üzeneteket egyenesen ebbe a tárolóba teszi bele kivéve, ha ez tele van. A tároló egyszerre 64 üzenetet képes megtartani. Ez az érték fix, nem módosítható! • Overflow queue (tulcsorduló sor): Ha az output queue megtelik a syslog-ng ebbe a tárolóba helyezi el a további üzeneteket. Ennek a mérete állítható, mégpedig a log_fifo_size() paraméter segítségével. A flow-control-nak két fajtája van, nevezetesen a hard és a soft flow control (kemény és könnyű folyamirányítás). Soft flow-control esetén nincs veszteség, ha a célállomás képes fogadni az üzeneteket, azonban ha ez valamilyen okból kifolyólag nem lehetséges (nem irható a file, vagy megtelt a lemez), és minden tartaléktároló tele van, akkor elkezdenek elveszni az üzenetek. A soft flow-control-t nem lehet konfigurálni, automatikus beállításokkal érkezik, és automatikusan elérhető akkor, ha a célállomás egy fájl, vagy egy logsotre. Egyéb célállomás típusok esetén ez a lehetőség nem él! Hard flow-control használatakor nincs üzenetvesztés. Ennek használatához engedélyezni kell a flow_control() flag-et a logpath-ban. Ez a típusú flow-control minden fajta célállomás esetében a rendelkezésünkre áll.

5.3.1. A flow-control és a többszörös üzenettovábbítás A flow-control használatának van egy fontos mellékhatása, ha egy üzenetet több helyre kell elküldeni. Ha a flow-control aktív és az egyik célállomás nem képes fogadni az adott üzenetet, akkor a többi sem fogja megkapni, mert a syslog-ng leállítja a forrás olvasását. Például van egy üzenetünk, amit el kell küldeni egy távoli szerverhez, és 42

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével emellett még lokálisan egy fájlban tárolni, és az internetkapcsolattal probléma adódik, akkor sem a távoli szerver nem kapja meg az üzenetet, sem a helyi fájlba nem íródik bele!

43

6. fejezet Összefoglalás Remélem sikerült az olvasót valamilyen szinten bevezetni a logolás világába. Mostanra biztos világossá vált, hogy ezek a többnyire egyszerű szöveges tartalmak mennyire hasznosak tudnak lenni adott esetben. Abban az esetben, ha ez a dolgozat nem lett volna elegendő, bátran ajánlom az irodalomjegyzékben szereplő web helyeket további kutatások, informálódások kiindulásául. Ahogy azt az elején közöltem, a dolgozat célja nem egy kulcsrakész megoldás ismertetése, sokkal inkább az elvi háttér bemutatása. Ha az olvasó érdeklődik a syslog-ng iránt, akkor annak ingyenes verzióját bármikor letöltheti és kipróbálhatja, abban az esetben pedig, ha nagyobb léptékű felhasználásban gondolkodik, akkor a BalaBit munkatársai örömmel állnak rendelkezésre, egy kölcsönösen előnyös együttműködést létrehozva.

44

Irodalomjegyzék [1] System and User Logging - http://www.linuxtopia.org/online_books/ linux_administrators_security_guide/ 08_Linux_System_and_User_Logging.html (2013. májusi állapot) [2] System logging explained in Linux - http://www.aboutlinux.info/2005/01/systemlogging.html (2013. májusi állapot) [3] 20 Linux Log Files that are Located under /var/log Directory http://www.thegeekstuff.com/2011/08/linux-var-log-files/ (2013. májusi állapot) [4] Rsyslog - http://en.wikipedia.org/wiki/Rsyslog (2013. májusi állapot) [5] syslogd - http://linux.die.net/man/8/syslogd (2013. májusi állapot) [6] Windows-to-Linux roadmap: Part 5. Linux logging http://www.ibm.com/developerworks/library/l-roadmap5/ (2013. májusi lapot)

ál-

[7] Computer data logging - http://en.wikipedia.org/wiki/Computer_data_logging (2013. májusi állapot) [8] File Replication Service - http://en.wikipedia.org/wiki/File_Replication_Service (2013. májusi állapot) [9] DMZ (computing) - http://en.wikipedia.org/wiki/DMZ_(computing) (2013. májusi állapot) [10] Crystal Reports - http://en.wikipedia.org/wiki/Crystal_Reports (2013. májusi állapot) [11] Levonta az Azure-kimaradás tanulságait a Microsoft http://www.hwsw.hu/hirek/48224/microsoft-windows-azure-leallas-szokoevfelho-cloud.html (2013. májusi állapot)

-

[12] Windows Event Log http://msdn.microsoft.com/enus/library/windows/desktop/aa385780(v=vs.85).aspx (2013. májusi állapot) [13] Log management and intelligence - http://en.wikipedia.org/wiki/ Log_management_and_intelligence (2013. májusi állapot) [14] Security information and event management http://en.wikipedia.org/wiki/Security_information_and_event_management (2013. májusi állapot)

-

45

[15] Log analysis - http://en.wikipedia.org/wiki/Log_analysis (2013. májusi állapot) [16] CORRELATION ANALYSIS - http://www.metastock.com/Customer/ Resources/TAAZ/?c=3&p=44 (2013. májusi állapot) [17] What is Correlation Analysis and How is it Performed ? http://www.managementstudyguide.com/correlation-analysis.htm (2013. májusi állapot) [18] Correlation and dependence - http://en.wikipedia.org/wiki/ Correlation_and_dependence (2013. májusi állapot) [19] Open Academy: Naplózás a gyakorlatban - http://www.slideshare.net/ open_academy/bala-bit-openacademylogmenedzsmentfinal (2013. májusi állapot) [20] Transport Layer Security - http://en.wikipedia.org/wiki/ Transport_Layer_Security#TLS_handshake_in_detail (2013. májusi állapot) [21] What is an X.509 Certificate? - http://fusesource.com/docs/broker/5.3/security/ i284538.html (2013. májusi állapot) [22] Ezért állt le újra a Microsoft felhője - http://www.hwsw.hu/hirek/49903/ microsoft-azure-leallas-tanusitvany-felho-cloud-iaas-tarolo-https.html (2013. májusi állapot) [23] The syslog-ng Open Source Edition 3.4 Administrator Guide http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4guides/en/syslog-ng-ose-v3.4-guide-admin/html-single/index.html (2013. májusi állapot)

46

Adathordozó használati útmutató A diplomamunka kiegészítője egy CD lemez. A lemez kettő könyvtárat tartalmaz. Az első könyvtár neve "Diplomamunka", ebben található maga a szakdolgozat LATEXes forrása. A második könyvtár neve "Szükséges file-ok" ebben vagy egy "dlink.xml" nevű állomány. Ez tartalmazza azt a példakódot melyet az ötödik fejezetben használtam. Ebben a könyvtárban van tovább még egy mappa "patterndb" néven. Ez a szakdolgozat készítésekor érvényben lévő szabadon elérhető mintaadatbázist tartalmazza, melyet a syslog-ng használhat. Az adatlemez egyéb állományt nem tartalmaz.

47