J:/Dokumentumok/EGYETEM/Szakdolgozat/Saj䄐t …phd.lib.uni-miskolc.hu/JaDoX_Portlets/documents/document_14576_… · 1. fejezet Bevezetés Napjaink rohanó világában az információ

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 KarAlkalmazott 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 szak-irodalom 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 92.1. A Windowsos naplózás . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2. A Linuxos naplózás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1. Néhány log könyvtár . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2. Archiválás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3. Hasznos eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4. Testreszabás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Hasznos funkciók a naplózó alkalmazásokban . . . . . . . . . . . . . . . 142.4. Mire érdemes odafigyelni . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5. Naplózási technikák általánosan . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1. Log menedzsment (LM) . . . . . . . . . . . . . . . . . . . . . . 162.5.2. Biztonsági adat és esemény menedzsment, avagy a SIEM . . . . 17

2.6. Vállalati érettségi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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

4. Üzenetek feldolgozása a syslog-ng használatával 234.1. A naplóüzenetek struktúrája . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1. BSD-syslog (RFC3164) . . . . . . . . . . . . . . . . . . . . . . . 234.1.2. IETF-syslog (RFC5424) . . . . . . . . . . . . . . . . . . . . . . 25

4.2. Naplóüzenetek osztályozása . . . . . . . . . . . . . . . . . . . . . . . . 264.3. Minta adatbázis használata . . . . . . . . . . . . . . . . . . . . . . . . 274.4. Üzenetek korrelálása . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5. Műveletek beállítása azonosított üzenetekhez . . . . . . . . . . . . . . . 30

4.5.1. Feltételes végrehajtás . . . . . . . . . . . . . . . . . . . . . . . . 304.5.2. Külső műveletek végrehajtása . . . . . . . . . . . . . . . . . . . 304.5.3. Akciók és a korreláció . . . . . . . . . . . . . . . . . . . . . . . 31

4.6. Minta adatbázis létrehozása . . . . . . . . . . . . . . . . . . . . . . . . 314.6.1. Minta feldolgozók használata . . . . . . . . . . . . . . . . . . . 314.6.2. A V4 minta adatbázis formátum . . . . . . . . . . . . . . . . . 33

5. A biztonság és a syslog-ng 365.1. Titkosított üzenettovábbítás . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1. A naplóbejegyzések kódolása a TLS segítségével . . . . . . . . . 385.2. Üzenetvesztés, mikor és hogyan? . . . . . . . . . . . . . . . . . . . . . . 39

5

5.3. Bejövő és kimenő forgalom kezelése flow-control segítségével . . . . . . 405.3.1. A flow-control és a többszörös üzenettovábbítás . . . . . . . . . 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 lehetkönnyen hozzáférni. Szakdolgozatom témája a naplóüzenetek feldolgozása, mely szer-ves része a kinyert információk strukturálásának.

Véleményem szerint egy komplex informatikai infrastruktúra üzemeltetéséhez, illet-ve mélyebb szintű átlátásához elengedhetetlen, hogy a rendszer által küldött üzeneteketaz üzemeltető csapat időben megkapja, és helyesen értelmezni tudja.

Jelenleg egy informatikai paradigmaváltás zajlik. Ennek keretein belül előtérbe ke-rü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 adat-mennyiséget kezelnek, továbbá a biztonságos és megbízható működésük mindenek felettvaló, elengedhetetlen hogy a rendszer által küldött értesítések elemzésével egy-egy hi-bát időben észrevegyenek, és még azelőtt kezeljenek, hogy az kritikus meghibásodáshozvagy 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 ter-méket a világ számos vezető vállalata nap, mint nap alkalmazza, és ennek segítségéveltudnak kiszűrni olyan incidenseket, melyek komoly károkkal járnának, vagy olyan hi-bá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 kiindu-ló, á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életiháttértudással.

A rendszer alkalmazására konkrét példa nincs, mivel ezt az eszközt minden al-kalmazási helyén egyedi igények szerint testre szabják, utána pedig a belső vállalatiinfrastruktú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, melyreazonban 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ódonis eltérhetnek.

7

Végezetül szeretnék köszönetet nyilvánítani mindazoknak, akik segítették jelen do-kumentum elkészültét, szakmai vagy egyéb módon. Köszönöm családomnak a végetnem érő bíztatást, páromnak a türelmét és támogatását, konzulensemnek az iránymu-tatá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ő Fenn-tartható Természeti Erőforrás Gazdálkodás Kiválósági Központ / Alkalmazott Anyag-tudomány és Nanotechnológia Kiválósági Központ / Mechatronikai és Logisztikai Ki-válósági Központ / Innovációs Gépészeti Tervezés és Technológiák Kiválósági Központkereté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ög-zítéséből áll, jellemzően egy számítógépes program által, abból a célból, hogy adottszempontok alapján szolgáltasson ellenőrző adatokat egy rendszer vagy egy szoftverjobb megértése végett.

Az elektronikus naplóbejegyzések (továbbiakban: log-ok) alapvető eszközök, ha sze-retnénk komplex rendszerek viselkedését megérteni, különösen akkor, ha a monitorozottalkalmazás viszonylag kevés felhasználói beavatkozással rendelkezik, ilyenek tipikusana szerveralkalmazások.

A log-olás igazi ereje akkor mutatkozik meg, amikor a log-okat heterogén rendsze-rekbő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 hibamiatti szolgáltatás kiesés terjedése szerverről szerverre. (Csak példaként említhetnénkitt a 2012. március elején történt esetet, amikor a Microsoft felhő szolgáltatása egyhibá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 hasz-ná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 servicefelel. Ez a szolgáltatás automatikusan indul a rendszerrel (ha csak azt mi magunk kéz-zel le nem tiltjuk), és ez kreálja a naplóbejegyzéseket, amiket aztán az Event Viewernevű 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 rendszergazdaijogosultságokkal lehet hozzáférni a biztonsági logokhoz. Ennek oka, hogy a biztonságilogok olyan érzékeny információkat tartalmazhatnak a rendszerről, amelyek ha rosszkezekbe 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 mind-há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öztetmeg. Ezek pedig:

• Alkalmazás log - olyan bejegyzések, amelyeket különböző telepített alkalmazásokgenerálnak valamely esemény bekövetkeztekor.

• Biztonsági log - sikeres illetve sikertelen bejelentkezési eseményeket tartalmazilletve azokat az eseteket, amikor valamilyen erőforrás használat történt pl. egyfájl megnyitása, törlése, létrehozása.

• Rendszer log - Ez a típus a rendszerösszetevők eseményeit fedi le, driver illetvehardware hibákat rendszerint.

• Domain Controller log - Ha tartományi kiszolgálót üzemeltetünk, akkor meg tud-juk 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ányokváltozásának deployolása.

• DNS log - ha a gépünk egy tartomány kiszolgáló, akkor további logok is kelet-kezhetnek, 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 bizton-sá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 lehethiba (error), figyelmeztetés (warning), információ (information), sikeres audit (succ-ess audit) vagy sikertelen audit (failure audit). Könnyen belátható hogy egy nagyobbforgalommal bíró rendszeren, vagy hálózaton rövid idő alatt óriási mennyiségű (extrémesetben több GB-nyi) naplóbejegyzés keletkezhet. Ekkora mennyiségű adatot pedig le-hetetlen 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ő al-kalmazás igen hasznos lehet a hétköznapokban.


Egy rendszer menedzselésének egyik kulcsa, hogy mindig tudjuk, mi történik a rendsze-rünkben. A Linux egy különleges logolási technikát ad a kezünkbe, ráadásul a log-banmegjelenő részletek mind konfigurálhatók.

A Linuxos log állományok sima szöveges fájlok, így megnyitható, kereshető, olvas-ható bármilyen speciális program szükséglete nélkül. Ha akarjuk, írhatunk egy script-etis, ami végigfut a log-on és a tartalmától függően különböző parancsokat hajt végre.

10


A Linux rendszerben a logok alapértelmezés szerint a /var/log elérési út alatt talál-hatók meg, bár ezt az elérési utat a megfelelő konfigurációs beállítás megváltoztatásávalkö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ánytcsak a root felhasználónak van jogosultsága olvasni, de ezen változtathatunk egy egy-szerű hozzáférési jogosultság váltással.

2.2.1. Néhány log könyvtár

/var/log/messagesA messages log a rendszermag log állománya. Tartalmazza egyrészt a rendszerbootolása közben keletkező üzeneteket csakúgy, mint a rendszer futása közbenkeletkező 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 kapottvalaki root jogosultságot szintén ebben az állományban találhatóak. Ha valami-lyen 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ődlegeskiindulópont, ha hibakeresésbe kezdünk.

/var/log/XFree86.0.logEz a log tartalmazza az Xfree86 Xwindows szerver legutóbbi végrehajtásánakeredményét. Ha problémánk akad a grafikus móddal érdemes itt kezdeni a kere-sést.

/var/log/secureTipikusan az autentikációs és jogosultság módosulás eseményekhez kötött infor-má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/maillogItt 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épenkeresztü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ég-ződő állományokat. Ezek az úgynevezett forgatott (rotated) archív állományok. Mivela log fájlok szeretnek hízni a Linux rendelkezésünkre bocsát egy parancsot (logrota-te) aminek segítségével saját beállításaink alapján archiválja a logokat így előzve megegye esetleges keveredést. Alapbeállítás szerint a logrotate automatikusan lefut adottidő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évvégére. Ezután ha van már korábban forgatott állományok, akkor azok verziószámát arendszer automatikusan növeli. Ebből következik, hogy minél nagyobb szám szerepelaz á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.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 vanegy néhány eszköz, amivel nem árt megismerkedünk.

dmesgHa 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

tailElőfordulhat olyan helyzet, amikor szeretnénk egy naplóállomány változását fi-gyelni. Ekkor érdemes ezt a parancsot használni. A tail -t arra tervezték, hogy aszöveges állomány utolsó pár sorát megmutassa. A -f kapcsolóval a tail folyama-tosan 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 folytatjaa kiírást, ha a naplófájl bővül. Ha parancsot a Ctrl+C billentyű kombinációvaltudjuk megszakítani.

moreMűködése ugyanaz, mint a DOS-os társáé, a megadott állomány tartalmát úgytö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.

lessA less egy text nézegető, de lehetőség van benne egy nagyobb állomány végiggör-geté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árajelenik meg.

loggerEz a parancs lehetővé teszi, hogy saját log üzeneteket továbbítsunk a rendszer-nek. Saját programokban szkriptekben alkalmazva információkat küldhetünk afutásidejű hibákkal és egyéb jelenségekkel kapcsolatban. Ha a naplózó rendszertelőzőleg testre szabtuk, ne felejtsük el hozzáigazítani a saját log-ot.

rsyslogAz 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özaz 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épetkívánok nyújtani az olvasónak, amiből nagyjából képbe kerül és el tud indulni önállóana témában.

Kettő démont kell megemlíteni, melyek tulajdonképpen a logolást végzik, ezek aklogd és a syslogd (bár ez utóbbit már felváltotta a korszerűbb rsyslog eszköz). A klogdcsak a kernel szintű üzeneteket kezeli, míg a syslogd kezeli a többi rendszer szintű ese-ményt. Mindkettő viselkedését tudjuk módosítani, ehhez csupán a /etc/syslog.conf ésa /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 egybizonyos típusú üzenettel. Kiírhatjuk a message fájlba, kiírhatjuk egy saját fájlba, el-küldhetjük egy távoli kiszolgálónak, hogy az dolgozza fel. A távoli logolás biztonságilagegy elfogadott megoldás, mivel ha a log fizikailag nincs a gépen, akkor nem is lehetkompromittá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 , s t o r ed in the ke rne l# f i l e , c r i t i c a l messages and h igher ones a l s o go# to another host and to the conso l e#kern .∗ /var /adm/ ke rne lkern . c r i t @magyarhonkern . c r i t /dev/ conso l ekern . i n f o ; kern . ! e r r / var /adm/ kerne 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 ma-gasabb prioritással rendelkezik a ’magyarhon’ nevű távoli géphez. Ennek hasznosságakorábban már tárgyalásra került.

A harmadik szabály ugyanezen üzeneteket a átirányítja a konzolra, így az aktuálisfelhasználó is értesül az üzenetről.

A negyedik szabály megmondja a syslogd -nek hogy mentsen minden kernel üzenetetami ’info’ vagy magasabb prioritással, de az ’err ’-nél kisebb prioritással rendelkezik a/var/adm/kernel -info fájlba.

13



A következőkben kitérek néhány olyan funkciókra, melyek hasznosak lehetnek egy nap-lózó alkalmazásban és ezzel segítségünkre lehetnek a megelőzésben vagy az utólagosnyomozásban.

• Valósidejű monitorozás és értesítés, ha egy olyan esemény következik be ami-ről a biztonságért felelős személynek tudnia kell. A Windows önmagában sajnosnem 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 je-lenti, hogy minden egyes gép lokálisan tartalmazza a releváns naplóbejegyzéseketezzel 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ódniaz aktuális rendszer állapotáról, mint több száz, esetleg több ezer naplóbejegyzésközött valami fontos dolgon elsiklani. Éppen ezért érdemes egy központi moni-torozó rendszert felállítani, amit a szakértő(k) egyszerűen el tudnak érni, habepillantást szeretnénk valahova.

• A biztonsági logok távoli felügyelete szintén elvárás. Ez annyit jelent, hogyha egy behatolási kísérlet történik, melynek során egy lokális felhasználói fiókkalakarnak 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 Windowsoskö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áso-kat egy speciális eseményhez így könnyítve meg az adminisztrátor munkájáta logok kibogarászásában.

• Archiválás. Egyes intézményeknél, bankoknál a legtöbb országban követelménya naplóüzenetek megőrzése 7 vagy akár több évig is bizonyos esetekben. Az alapWindows beállítás az, hogy ha a log állomány elér egy bizonyos méretet, akkorfelü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ányokkitisztításáról illetve fizikai tárolásáról. Napjainkban viszont már lehetőség vanennek a folyamatnak az automatizálására, amivel centralizálhatjuk, a folyama-tot ezzel pedig megnövelhetjük a produktivitást egy nagy hálózaton, emellettpedig csökkenti a segélykérések (support calls) számát, és lehetőséget nyújt, azadminisztrá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élyfor-rásnak vannak kitéve, mivel a felhasználó kitörölheti, vagy egy behatoló miutánhozzáférést szerzett eltakarhatja a nyomait az aktuális log törlésével. Elterjedtgyakorlat hogy behatolásnál az illetéktelen hozzáférő hatalmas mennyiségű falslogot helyez el az állományban ezzel fedve el a nyomait. Egy távoli logkezelő al-kalmazás használatával a szakértő riasztást kap egy ilyen esetnél és szinte azonnalreagálhat a feltételezett veszélyhelyzet elhárítása végett, továbbá mivel a log ál-lomány távoli helyen van tárolva a behatoló vagy a felhasználó nem tudja semtö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 monitoro-zó 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 tud-juk megvalósítani, hogy az elutasított hozzáféréseket listázzuk, így pedig képetkaphatunk arról, ha valaki olyan állományhoz próbál hozzáférni, amihez nemszabadna.

• 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, ígyazonban 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ítettterület. Egy monitorozó szoftver használata ugyanis egy plusz réteget adhat azalap 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 egyszervert, ami a DMZ-ben van.

• Az adattárolás egy megbízható kereshető adatbázisban (pl.: SQL) előnytjelenthet, illetve nagyvállalati környezetben elvárt dolog. A legtöbb naplóalkal-mazás ma már rendelkezik ezzel a funkcionalitással.

• Riportkészítés elterjedt eszközökkel, mint pl.: SAP Crystal Reports szinténelvá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, hogyegy eseménye prezentálása egy feljebb valónak mennyivel könnyebb, ha úgy tud-juk á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ötniegy ilyen eszközhöz.

• Az események kategorikus rendezése priorizált szekciókba. Az alkalma-zá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 ala-csony prioritással bíró eseményekről. Ez a sorrendiség időt spórol és javítja avezetői döntéshozatalt.

• A logok takarítása is monitorozva kell legyen, egyrészt mert csak a rendsze-rért felelős biztonsági szakértő takaríthatja a logokat másrészt pedig nyoma kelllegyen az eltüntetett adatoknak, abban az esetben ha a legfőbb adminisztrátorfió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ábbrais biztonságos maradhasson, így a monitorozásnak sokkal összetettebbnek kelllennie.

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, hogya 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, hogyha egy tapasztalt ember nézi át azokat, akkor őket meggyanúsíthatják vagy akár nyo-mon is követhetik a ténykedésüket. Ezen felül, ha egy eseménynek nincs nyoma, akkorelég nehéz bebizonyítani, hogy az adott esemény megtörtént. Érdemes tehát olyan al-kalmazás után nézni, aminek nagyfokú testreszabhatósága van mivel ez nagy segítségetfog nyújtani abban, hogy egy irdatlan adathalmazból kiszűrjük a számunkra az adottidőszeletben releváns információkat.

Egyes folyamatok automatizálásával órákat akár napokat is spórolhatunk, azonbanne essünk a ló másik oldalára, ne hagyjuk, hogy a túlzottan automatizált rendszerbendetektá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, amikkelmé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ítotterőforrás elérések mind-mind egy lehetséges vagy jövőben bekövetkező betörésre utal-hatnak. Ezeket az eseményeket ki kell vizsgálni és a korreláló felhasználóval együttvalidálni kell, hogy miért történtek.

Az idő egy fontos tényező, és mint a legtöbb emberrel kapcsolatos dologban, itt isaz idő a szűkkeresztmetszet. Az idő pénz és a logok átnézése és értelmezése többnyirenem tartozik azok közé a feladatok közé, amiket egy cég elvár, ha egy magasan képzettIT 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 el-engedhetetlen használni egy harmadik fél által fejlesztett naplózó alkalmazást hogy anaplózás, az archiválás és a jelentések az eseményekről megfelelő minőségben, mélység-ben és időben készüljenek.


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 EventManagement). E két módszer különbségeit illetve működését fogjuk áttekinteni az aláb-biakban.

2.5.1. Log menedzsment (LM)

A naplómenedzsment egy bonyolult folyamat, melynek során a cégeknek tengernyi do-logra, paraméterre kell odafigyelniük és emitt gyakran adódik, hogy egy rövid idő alattfelállított vagy felületesen megtervezett rendszer nem, vagy nem úgy működik, ahogyazt elvárták korábban. Ezt elkerülendő tekintsük át a lépéseket, amiket be kell járni

16


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 felada-ta lehet. Ez lehet, biztonsági naplóelemzés (behatolások és gyanús tevékenységekdetektá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 ésegyéb pénzintézetek).

2. A naplózó keretrendszer meghatározása. Definiálni kell a naplók típusait illetvea 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álfelá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ódusa kompetens törvényi szabályozásnak? Kódolva vagy natív formában lesznek-etá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 Bi-zottsá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 kinyernia 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étalkalmazást, ami legjobban illeszkedik a felállított modellre. Ez lehet egy szoftverkészítő cég, ami ezzel foglalkozik, vagy ahogy már fentebb tárgyaltuk egy sajátké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ánszü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 bizton-sági riasztások valós idejű elemzésére. Ezek az eszközök elfordulhatnak szoftver, fizikaieszköz vagy menedzselt szolgáltatás formájában, és többek között a biztonsági adatoknaplózására és riportok generálására is használhatók. A SEM, SIM és SIEM mozaik-szavak napjainkban szinte egyé forrottak, annak ellenére, hogy különbség van mind ajelentésben mind az alkalmazások képességeiben.

A biztonsági menedzsment szektora, ami lefedi a valós idejű monitorozást, ese-mények korrelálását és az értesítések kezelését általában a SEM-hez tartozik. A tartósmegőrzés, különböző szempontok szerinti analízis és a napló adatok riportálását a SIM-hez szoktuk kötni. A különböző jelentések, definíciók fejlődése, átalakulása, egyesülésevezetett 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 ésAmrit 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. Tartalmazniakell azonosítást és beléptetést végző alkalmazásokat, sebezhetőség kezelést, házirendfelülvizsgálót és a különböző operációs rendszerek, adatbázis, alkalmazások naplóit istudnia kell kezelni. 2012 januárjában a Mosaic Security Research felmérése szerint apiacon 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, bizton-sági eszközök, szerverek, adatbázisok, alkalmazások). A sokrétű adatok központigyű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 ese-ménnyé. A korreláció alkalmazásával lehetőség nyílik több forrás által szolgálta-tott adatokat olyan információvá gyúrni mellyel egy komplexebb képet kapunk arendszerek működéséről.

• Figyelmeztetés - az automatikus elemzéssel azonnali riasztást kaphatunk előrebeállított események bekövetkeztekor, vagy ha olyan korreláló eseménysorozatkövetkezik be/zajlik amiről feltétlen tudnia kell a rendszer felügyelőjének. A fi-gyelmeztetés lehet a kezelőfelületen keresztül, vagy egyéb harmadik fél által szol-gáltatott csatornán pl.: e-mail, sms, stb..

• Kezelőfelület - a kezelőfelületen jeleníthetünk meg minden, amit a naplózó rend-szerü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őrzikis. Egy kifinomult SIEM terméket be lehet állítani, hogy a szükséges adatokatkimutatá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ántörténik.


Egyes vélemények szerint egy vállalat érettségét, megbízhatóságát lehet az általuk hasz-nált naplózó technikák kiforrottságával, komplexitásával is mérni. Jelen alfejezet céljaegy feltételezett szintrendszer bemutatása a teljesség igénye nélkül, nem reprezentatívmódon.

1. szint a kezdeti fázisban, különböző log elemzők állnak munkába elsősorban a biz-tonsági részlegből kinyert naplók elemzése végett, hogy a támadások mintáit fel-ismerjék, ami a céget elsődlegesen érhetik.

18


2. szint a számítógépes integráció magasabb szintű használatával, a vállalatok a titkosadatok 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 ateljesítményt és a rendelkezésre állását a rendszer különböző szintjeinek, különöstekintettel 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állalatiszintű naplókezelő rendszerbe, hogy az adatok alapján optimalizálhassák sajátmű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 moni-torozá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 meg-annyi bejegyzést. A főbb okok, amiért az emberek, vállaltok alkalmazzák a napló ana-lí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álisbizonyí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 min-denfé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 egyközponti log gyűjtőnek.

Az alkalmazások által generált logok lehetnek olyan naplók is melyeket az alkalma-zás készítője programozott bele, hogy egy esetleges hibánál a hibakeresést megkönnyít-se. A logok szemantikája és szintaktikája nem egységes, többnyire az adott alkalmazásravagy vállaltra jellemző formát ölt. Ebből következik, hogy a terminológia is elég vál-tozatos lehet. Mivel az ilyen alkalmazások 99%-ban angol nyelvűek, egy program általtörténő felhasználó autentikáció lehet logon, login, user connection vagy authenticationesemény is. Éppen ezért a log analízisnek úgy kell interpretálnia az üzenetet, hogy azilleszkedjen 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 loganalizáló feladatai közé tartozik, hogy a rendszert minél több log kibocsátásra kész-tesse, ezzel mintegy meghatározva a log üzenetek egy spektrumát melyből a logokkikerülhetnek.A naplóanalizáló a rendszer vizsgálatakor felfedezett különbségeket úgy oldja fel, hogya 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 isszá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. Ezekaz alábbiak lehetnek:

• Minta felismerés - a funkció célja, hogy a bejövő üzeneteket egy előre megadottminta 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 ugyanolyanformá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éscéljából lehetezt 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 azokaz üzeneteket, amik nem érdekesek. Ez tulajdonképpen egy olyan metódus, amifigyelmen 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 érdemeslehet kivizsgálni.


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áltozikaz, 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 mu-tató) akkor fog-e változást okozni a függő elemben. Ez segítségünkre lehet az indikátorelem 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.0akkor azt "tökéletes pozitív korrelálásnak" nevezzük, ami azt jelenti, hogy ha változ-tatunk 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ásfog történni a független elemen is azonban az ellenkező irányban. A 0 értékű korrelációsegyüttható azt jelenti, hogy nincs kapcsolat a két objektum között és a független elemvá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étvá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 biztosanváltozni fog, ha a független változót módosítjuk.

21


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éknegatí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, hogyegy adott mutatónak milyen előrejelző értéke van, mennyire lehet megjósolni vele adottváltozások kimenetelét, a másik felhasználásnál pedig két változó közötti összefüggéstvizsgáljuk.

22

4. fejezet

Üzenetek feldolgozása a syslog-nghaszná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 egyikaz RFC 3164, más néven a BSD-syslog, a másik az RFC 5424, más néven a IETF-syslog. 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 hosszaalapesetben nem lehet hosszabb 1024 byte-nál. Ezt módosítani a log_msg_size()-allehet, ekkor az üzenet maximális hossza 256 MB lehet összesen. A syslog napló állomány3 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óüzene-tet létrehozta, míg a súlyossági érték egy olyan mutató, ami arról árulkodik mennyirevolt 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 ésmegszorozzuk nyolccal, majd hozzáadjuk a súlyossági tényező numerikus értékét.

23


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 adotteszkö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 nu-merikus értéke. Ha a nap értéke kevesebb, mint 10 akkor az első karakter a rendszerszóközre cseréli pl.: Aug 7. A hh:mm:ss pedig a helyi pontos időt jelenti. Itt a hh az óra

24


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 ats_format() segítségével állíthatunk, erre azonban jelen dolgozatban nem térek kiré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észrebontható 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 minda 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ányszerint (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 syslogaz 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 alkal-mazás specifikus információkat például forgalom számlálókat, IP címet stb. A struk-turá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ékpá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 feldolgo-zá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 aszöveg tartalmaz BOM karaktert. Ha ilyet nem talál a feldolgozó, akkor a kódolástismeretlennek 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 összeha-sonlítsa egy előre meghatározott minta adatbázissal. Azzal hogy az üzenetek egy előredefiniált mintahalmazhoz vannak hasonlítva, a syslog-ng képes felismerni az üzenettí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 tartalmaalapján. Az üzenet osztályokat saját szájízünk szerint testre is szabhatjuk, így azokakár beszédes nevek is lehetnek pl.: felhasználó-bejelentkezés, alkalmazás hiba, fájlkül-dés, stb. . .

Az illeszkedő minta megtalálása egy bizonyos üzenethez egy úgynevezett "longestprefix match radix tree" nevű algoritmussal történik. Ennek során a syslog-ng összeállítegy 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ész-ből, hanem magából a szöveges üzenetből) és kiválasztja azokat a mintákat, amelyekilleszkednek az adott karakterre a többit pedig "eldobja". Ezután a második karak-ter kiválasztása történik és az előbb szelektált halmazból megkeresi azokat a mintákatmelyek, illeszkednek erre a karakterre, a többit pedig figyelmen kívül hagyja. Ez afolyamat egészen addig folytatódik, míg végül csak egyetlen vagy nulla illeszkedő min-ta 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, ilyenlehet 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



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ánosztályozást eredményez, de az üzenettel további műveletet nem végez, így annak ar-chivá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 adjunkmeg az értelmezőnek. Ezzel megoldható az, hogy eltérő értelmező utasításoknak külön-bö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ő mak-rót tartalmaz, amivel az adott üzenet osztályozásának eredménye kérhető le. A .clas-sifier.class makró visszaadja az üzenethez társított osztályt, míg a .classifier.rule_idmakró annak az üzenet sablonnak az azonosítójával tér vissza, amire az üzenet illesz-kedik.

Vegyük szemügyre az alábbi példakódot:

f i l t e r f i l t_os z t_beha to l a s {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 ")) ;} ;

l og {source ( minden_forras ) ;pa r s e r ( pattern_db ) ;f i l t e r ( f i l t_os z t_beha to l a s ) ;d e s t i n a t i on ( ce l_oszt_behato las ) ;} ;

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őtfelhasználtuk a log kifejezésben. Ennek hatására az adott forrás felől érkező összes üze-netből ki lesznek szűrve azok, amikre illeszkedik a "violation" osztály és csak azoklesznek továbbítva a megfelelő célállomás felé. Ha létrehozunk egy hasonlós szűrőt, amiaz "unknown" osztályra illeszkedik, akkor ki tudjuk szűrni azokat az üzeneteket, amik-kel a rendszer még nem találkozott. Ha ezeket egy fájlba irányítjuk, akkor időről időrenyomon 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ánpedig további szűréseket lehet elvégezni az adathalmazon. Ezen lehetőség használatáhoza filter létrehozásánál használjuk a tags() opciót. A syslog-ng OSE 3.2-től kezdődőena 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ánaztá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 ne-vet kell adnunk ahhoz az értelmezőhöz, amit használni szeretnénk, majd ezt a nevethaszná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:

vmilyen-ertek: @ESTRING::.@

Ebben a sablonban az @ESTRING@ egy értelmező, ami folytatja az üzenetrész fel-dolgozását a következő stop karakterig (jelen esetben a stop karakter egy pont (.) ezérta kifejezésben a második kettőspont után az jelenik meg). Ha ezt a sablont használniakarjuk később akkor, rendeljünk hozzá egy nevet, melyet az első és a második kettős-pont 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"));


A syslog-ng OSE 3.2-es verziójától kezdve lehetőség van a mintaadatbázisokkal azono-sí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ön-böző alkalmazások gyakran bontják több különböző log üzenetbe az egy eseményheztartozó üzeneteket. A Postfix e-mail szerver például külön logba tárolja a küldő és a fel-adó címét. Az OpenSSH szerver, ha sikertelen bejelentkezést észlel, küld egy üzenetet asikertelen autentikálásról majd egy másik üzenetet is küld, ami a hiba okát tartalmaz-za. Természetesen a nem ennyire szorosan kötődő üzenetek is állhatnak korrelációbanegymá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 összetar-tozó üzeneteket és beteszi egy csoportba, amit kontextusnak nevezünk. Ez a csoport

28


olyan üzenetek sorozatából áll melyek valamilyen módon kapcsolatban állnak egymás-sal. 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 bizo-nyos 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ő fejezet-ben beszélünk.

Két attribútum áll rendelkezésünkre annak eldöntése végett, hogy az üzenet amiilleszkedik egy meghatározott szabályra része vagy nem része egy kontextusnak, ezekpedig a: context-scope és a context_id attribútumok. A context-scope viselkedése hason-ló 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 alkalma-zástól (${HOST} és a ${PROGRAM} jelölők élnek), vagy azonos hosztól érkeznek. Acontext_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óla 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 att-ribútum, melynek segítségével azt állíthatjuk, hogy a kontextust a rendszer meddigtartsa fent, vagyis, hogy a syslog-ng OSE meddig várjon a következő korreláló üzenetmegérkezéséig.

Ha új üzenet kerül hozzáadásra a kontextushoz, akkor a számláló újraindul. Amikoraz időkalkuláció folyik annak eldöntésére, hogy a timeout érték elmúlt-e vagy sem, asyslog-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épesa 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 rend-szeridő (mintha az üzenet a jövőből jött volna) , ekkor a rendszer az időt automatikusanaz 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ásodpercenbelül elküldi az összes szükséges üzenetet, akkor felesleges a kontextust életben tartaniórákig.

Amikor együtt használjuk a <value> elemet a mintaadatbázis szabályokban a korre-lációval, lehetőségük nyílik az adott kontextus korábbi üzeneteire hivatkozni úgy, hogya @<az_aktulalis_uzenettol_mert_tavolsag> utótagot illesztjük a makróhoz.

Az előbb elmondottakat egy példán keresztül lehet a legjobban szemléltetni: Tegyükfel, 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 érke-zett) hoszt értékére fog mutatni. Így tovább a ${HOST}@2 kifejezés a második üzenetre vonatkozik, míg a ${HOST}@3 az utolsó üzenetet (vagyis amelyik legelőszőr érke-zett) 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 au-tomatikusan, 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ára-ta 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 ér-kezik. Az ilyen üzenet-hozzárendelések az esetek túlnyomó többségében a korrelációvalszorosan 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ülde-ni, használjuk a inject_mode(internal) beállítást. Ekkor a logok oda kerülnek ahovaa syslog-ng alapértelmezetten logol.

A generált üzeneteket a mintaadatbázis szabályban kell konfigurálni. Ahhoz hogyminél beszédesebb üzeneteket alkossunk, használjunk a makrókat illetve az üzenetekbőlkinyert értékeket.

A név-érték párosok örökíthetők az üzenetekből. Ehhez állítsuk a <message> eleminherit-properties attribútumát TRUE értékre. Ekkor az üzenet, ami kiváltja a gene-rált üzenet létrehozását klónozva lesz és tartalmazni fogja a név-érték párokat és akülönböző címkéket is. Ha ezután az <action> elem bármely üzenetében beállítunkegy é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 kifeje-zé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.

<action condition="’${HOST}’ == ’pelda’">

A fenti kódrészlet például csak akkor generál üzenetet, ha a hoszt megegyezik azidé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, haegy adott üzenet ékezik) a generált üzenetet át kell irányítani egy külső alkalmazáshoza 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

<values><value name="UZENET">Log üzenet ${HOST} −t ő l .Egyező szabá ly száma :$ . c l a s s i f i e r . rule_id </value><value name="TRIGGER">t r i g g e r </value>

</values>

2. Hozzunk létre egy célállomást, ami az üzenetet fogja feldolzoni:

d e s t i n a t i on s a j a t_ t r i g g e r s {program ("/ bin /myProgram " ; ) ; } ;

3. Hozzunk létre egy szűrőt, ami kiszűri a generált üzenetet a belső logok közül:

f i l t e r s a j a t _ f i l t e r {match (" t r i g g e r "

value ("TRIGGER")type ( s t r i n g ) ) ;

} ;

4. Hozzunk létre egy log útvonalat, ami kiválasztja a generált üzeneteket és elküldiaz adot programnak:

l og { source ( s_loca l ) ;f i l t e r ( s a j a t _ f i l t e r ) ;d e s t i n a t i on ( s a j a t_ t r i g g e r s ) ; } ;

5. Állítsuk be a programot, ami feldolgozza az üzenetet vagy írjuk meg hozzá aszkriptet.

4.5.3. Akciók és a korreláció

Az automatikus log generálás bizonyos funkciói csak akkor használhatóak, ha ugyan-akkor a korrelálás is használva van. Ilyen például az automatikus kitöltés. A syslog-ngOSE 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 ér-kezett új üzenet bele. Ehhez az <action> elem trigger attribútumát "timeout"-ra kellállítani.


4.6.1. Minta feldolgozók használata

A mintafeldolgozók (angolul pattern parsers) célja, hogy az üzenetek egyes részeit au-tomatikusan 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


• 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 üzenetetfeldolgozni, 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őlminden olyan elemet, adatot, amit az egyéb makrók illetve feldolgozók nem hasz-ná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árolte-mail címek könnyen kiemelhetők. Például a @EMAIL:email:[]<>{}"@ feldol-gozó az alábbi címeket tudja értelmezni: [[email protected]]; <[email protected]>; {[email protected]};"[email protected]"

• @ESTRING@Ez az értelmező átemel mindent az üzenetből egészen, amíg nem találkozik a stopkarakterrel. 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 tartalmazhatnakegyetlen . (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ároltaklehetnek. (pl.: 127.0.0.1)

32


• @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). Aparaméterben megadott szám határozza meg hogy hány darab ilyen oktettet váraz é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 egy-enként kettő darab hexadecimális számból álló cím értelmezésére szolgál, ahol acsoportokat 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őtaggalkezdődik, akkor hexadecimális számként lesz értelmezve, de csak akkor, ha a 0xtagot legalább egyetlen érvényes szám követi. A kezdő kötőjel elfogadott nemhexadecimá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égre-hajtá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 adunkmeg 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ályokattartalmaznak. Ebben a fejezetben a mellékletek között található dlink.xml nevű állo-má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ívatottdefiniálni:

33


<?xml ve r s i on = ’1.0 ’ encoding=’UTF−8’?>

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

<patterndb ve r s i on="3" pub_date="2009−09−01">

A következő elem a <ruleset> ami a szabályok konténere. Ez foglal magába mindenszabá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"id="67e8f199 −67ed−433b−94d4−479535 fe7958">

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 <rules> következik. Ez közvetlenül magábanfoglalja a szabályokat.

<ru l e s >

A szabályok definiálása a <rule> és a </rule> elemek között történik. A rule olyanelem, ami tartalmazza az üzenet sémáját illetve azt, hogy az erre a sémára illeszkedőüzenetek hogyan legyenek osztályozva.

<ru l e id ="3963181a−5f fd −4c83−ac91−f5 fa0303dd27 "c l a s s="system"prov ide r="ba l ab i t">

Az id a szabály globális egyedi azonosítója, a class az üzenet osztálya lesz, a providerpedig a szabályt szállító erőforrás, jelen esetben a balabit. Opcionálisan megadható att-ribútumok a context-id, context-timeout, context-scope. A context-id egy azonosító, amiaz összetartozó logokhoz adható meg. Ez akkor lehet hasznos, amikor az üzeneteketkorrelá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 azelem több <pattern> elemet is tartalmaz, akkor a <rule> 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.

<patterns><pattern>ALG s e s s i o n opened</pattern>

</patterns>

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 <urls>, amitöbb <url> elemet is tartalmazhat, ahonnan extra információt szerezhetünk. Felve-hetünk még <values> konténert, ami több <value> elemet tartalmazhat. A <value>

elem attribútuma a name, ami a név-érték páros neve. Ezt később aztán használhatjukmakróként, hogy elérjük közvetlenül az értéket.

34


A következő fontos elem a <examples> ami egy konténer objektum. Ebben olyanlog ü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 <test_message> elem,ami egy teszt üzenet amit a szabálynak fel kell ismernie, továbbá lehet benne<test_values> elem ami <test_value> elemeket foglal magába. Ez utóbbi azokataz értékeket tartalmazza, amiket az értelmezőnek fel kell vennie miután az üzenetetfeldolgozta.

<examples><example><test_message>Maximum l i n e l ength 150 exceeded ,got 200 cha ra c t e r s . C los ing connect ion .</ test_message><test_values>

<test_value name=". d i c t .max">150</test_value><test_value name=". d i c t . l en ">200</test_value>

</test_values></example>

</examples>

Ha azt szeretnénk, hogy történjen, egy bizonyos esemény az üzenet feldolgozása közbenakkor használjuk az opcionális <actions> konténert. Az <actions>-on belül <action>elemekkel definiálhatjuk a művelet pontos paramétereit. Az <action> elem attribútu-mai a condition, a rate és a trigger. Az első egy syslog-ng szűrő kifejezés, a másodikmeghatározza hány üzenet generálódhat a megadott időintervallumban, a harmadikpedig meghatározza, hogy mikor legyen az akció végrehajtva. A trigger attribútumnaka lehetséges értéke a match, amikor az akció egyből az üzenet feldolgozásakor hajtódikvégre, és a timeout ami egy időbeni eltolást jelent.

Az <action> elemnek van még továbbá egy <message> és egy <values> eleme is.A <message> egy konténer elem, ami azt az üzenetet tartalmazza, ami elküldésre kerüla meghatározott akció végrehajtásakor.

A <values> szintén egy konténer elem, ami azokat az értékeket és mezőket tartal-mazza, melyekből a generált üzenet előáll.

Az üzeneteket tudjuk címkézni is. Ehhez a <tags> konténer használatos. Ezen belülvehetünk fel <tag> elemeket, amik tartalmazzák azokat a kulcsszavakat melyek alapjánkésőbb szűrhetünk illetve szelektálhatunk.

<tags><tag>UserLogin</tag></tags>

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 ahálózaton keresztül. Ehhez az úgynevezett TLS (Transport Layer Security) protokollthasználja.

A TLS protokoll egy titkosítási eljárás melynek segítségével anélkül valósíthatunkmeg adatkapcsolatot, hogy annak lehallgatásától esetleges manipulálásától kellene fél-nünk. A legtöbb napjainkban elérhető üzleti alkalmazás támogatja ezt a biztonságifunkció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 vagysem. Erre kettő lehetőség adódik: az egyik hogy egy erre kihegyezett csatornát tartunkfenn az ehhez hasonló adatáramlás-oknak (pl.: https - 443-as port), a másik, hogy egyszabványos porton való kommunikáció során a kliens kéri a szervert, hogy használja aTLS-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 egy-ségbezárt adatok halmaza. Minden ilyen rekordot lehet tömöríteni, titkosítani illetvekiegészíthető úgynevezett "Message Authentication Code"(MAC)-al is. A rekordok jel-lemző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ányegyéb adatot is tartalmaz: legnagyobb támogatott TLS verziószáma, egyrandom szám, egy titkosítási metódust és egy javasolt tömörítési algorit-must.

• A szerver válaszol egy ServerHello üzenettel, ami tartalmazza a kiválasztottprotokoll verziószámot és titkosítást, egy véletlen számot és a tömörítésialgoritmust.

• A szerver küld egy Certificate üzenetet (ez a rész protokollfüggő nem mindenesetben következik be).

36


• A szerver küld egy ServerHelloDone üzenetet mellyel jelzi, hogy a tárgyalásifázis befejezettnek tekinti.

Második fázis:

• A szerver küld egy ChangeCipherSpec rekordot, ami gyakorlatilag a titko-sított adatfolyam kezdetét jelöli a szerver oldalról. Ez a rekord önmagábanegy rekord szintű protokoll is 20-as típusú tartalomtípussal. (erről bővebbenkicsivel később)

• A szerver küld egy kódolt Finished üzenetet, amely tartalmaz egy hash-t ésegy 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 meg-szakad.

Alkalmazási fázis:Ezen a ponton a kézfogás-szakasz kész van, és a protokoll engedélyezve van a 23-as 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 TCP-alapú 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 szerverszintén elkérheti a kliens tanúsítványát és a kétirányú autentikáció is megoldható, haa 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 - certificationauthority) á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 szerintbő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 kliensazonosító tanúsítványnak

A kölcsönös azonosítás egyértelmű előnye, hogy biztosítható vele, hogy a syslog-ngszerver csak azonosított kliensektől fogad el napló üzeneteket.

37


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ányegyszerű lépésben. Vélhetően ezután az olvasó maga is képes lesz a jövőben ezeket azegyszerű, ám igen hasznos beállításokat elvégezni. Első körben a kliens beállításai ke-rü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 bizonyosnyilvá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 min-denhol ugyanazon az elérési útvonalon legyen, pl.: /opt/syslog-ng/etc/syslog-ng/ca.daz 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 parancsbanszereplő testcert.pem az a tanúsítvány, amit a megfelelő helyre az imént bemásoltunkminden 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 esetbenpont 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áljaaz 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 sta-tement) a konfigurációs állományhoz, melybe beillesztjük atls(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éterekneka 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 on demo_tls_sett ings {tcp ( " 1 0 . 1 . 2 . 3 " port (1234)

t l s ( ca_dir ("/ opt/ sys log−ng/ e tc / sys log−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 on demo_tls_syslog_dest inat ion {sy s l o g ( " 1 0 . 1 . 2 . 3 " port (6514)

t ranspo r t (" t l s ")

38

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

port (3214)t l s ( ca_dir ("/ opt/ sys log−ng/ e tc / sys log−ng/ca . d ") ) ) ;

} ;

Harmadik lépésként csupán annyi a maradék teendőnk, hogy a második lépésben lét-rehozott célállomást beillesztjük a log kifejezésbe (log statement). Ezzel készen van akliens 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éta szervernek.

Ha mindent jól beállítottunk már csak egy dologra kell odafigyelni: a tanúsítványo-kat a lejártakkor, de inkább előtte frissíteni kell ellenkező esetben egész fürtök állhatnakle, 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ésivagy tárolási helyére számos olyan pont lehet, ahol úgymond eltévedhet, még akkoris, ha a syslog-ng a tőle telhető legjobb módon igyekszik eljárni az információval. Azesetek túlnyomó többségében az üzenetvesztés elkerülhető az infrastruktúra körülte-kintő 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. Megkell bizonyosodni arról, hogy a megfelelő forrást állítottuk be, ahhoz hogy a log-ok azalkalmazástól a naplózó rendszerig érjenek. Érdemesebb például unix-stream-et hasz-nálni a unix-dgram helyett.

Egy másik kritikus pont, amikor a syslog-ng küldi az üzenetet. Ha ugyanis nemképes továbbjuttatni azt és a kimeneti puffer megtelik, akkor az adott üzenete(ke)teldobja. 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észetemiatt fordulhat elő, ugyanis amikor az UDP -n küldött üzenet eléri a fogadó felet, akkorott bekerül egy tárolóba a memóriában, amit úgy neveznek: socket receive buffer. Ha afogadó fél több üzenetet kap, mint amennyit ebben a pufferben tárolni képes akkor aztú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 nemlehet a protokollt TCP-re cserélni, használjuk a so_rcvbuf() opciót a puffer méreténeknövelésére.

Amikor a syslog-ng üzenetet kap, szintén elfordulhat, hogy adatvesztést tapasz-talunk. 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 statisz-tikai log-ja tartalmazza.

Ha a fogadó félnél túrterhelés jelentkezik, akkor van rá esély, hogy adatvesz-téssel kell számolnunk. Ha a syslog-ng nagy sebességgel küld üzeneteket például egySQL adatbázisnak, egy fájlnak vagy egyéb célállomásnak megtörténhet, hogy az adottfogadó fél nem győzi a bejövő adathalmazt és csak lassan dolgozza fel azt. Ekkor asyslog-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 szerverhelytelen leállítása miatt is. Ha a gép amelyik hostolja a syslog-ng szervert egyhelytelen leállítást érzékel, időbe telik mire a kliensek észlelik a kapcsolódás megsza-kadását. Azok az üzenetek, amelyek ebben az időszeletben kerülnek a TCP kimenetibufferjébe nem lesznek elküldve a szervernek.

5.3. Bejövő és kimenő forgalom kezelése flow-controlsegítségével

Ebben a fejezetben górcső alá kerül a syslog-ng belső üzenet feldolgozó modellje, illetvea flow-control (nyersfordításban: folyamirányítás) működése, mellyel megakadályozhat-juk az előzőekben taglalt üzenetvesztéssel járó eseteket. A flow-control használatáhoza 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ájlbanbeállított forrást és periodikusan végigellenőrzi mindet, hogy van-e üzenete. Ha találegy ú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-buffervagy ahogy korábban említettük fifo) küldi őket. Ebből a tárolóból aztán az operációsrendszer 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ülhetbeolvasásra egyetlen ciklus alatt, ezért a syslog-ng egyetlen körben csak meghatározottszá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ú, hiszenha túl alacsony, akkor az üzenetek nem lesznek elég gyorsan feldolgozva és lassul arendszer, esetleg üzeneteket vesztünk, ha pedig feleslegesen túl nagyra állítjuk, akkorroppant erőforrásokat igényelhet az alkalmazás, ami pedig szintén akadozásokhoz vagyrosszabb 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


mert az adott állomás nem feltétlenül képes fogadni az összes üzenetet egyszerre, ezzelazonban kap egy kis időt, hogy "összeszedje" magát. Ennek a tárolónak az értékét alog_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, hogyaz összes üzenet beleférjen.

A TCP és a unix-stream források több, különböző kapcsolaton keresztül is kap-hatnak üzeneteket (pl.: sok eltérő kliens, vagy különböző alkalmazások). Ilyenkor asyslog-ng minden egyes kapcsolatból külön-külön kiolvassa az üzenetet, így alog_fetch_limit() paraméter a forráson belül minden kapcsolatra külön-külön vo-natkozik.

A syslog-ng folyam irányítója (továbbiakban flow-control) gyakorlatilag egy keretetrendel a forrásokhoz, ami azt jelöli még mennyi üzenetet képes a syslog-ng az adottforrástól elfogadni. Minden egyes üzenet, amit a rendszer beolvas, eggyel csökkenti ezta 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élaz értéknél kell nagyobbnak lennie a log_fifo_size()-nak, hogy a flow-control ha-té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éketnöveli vagy csökkenti.

Itt megjegyzendő, hogy a syslog-ng OSE 3.3-tól felfelé a több kapcsolatú forrásokesetében a keret meghatározott értékét elosztják a kapcsolatok számával, majd az ígykapott érték lesz az egyes kapcsolatok maximális keret értéke. Ezzel küszöbölődik kiaz 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 kapcsolatoklehet, hogy nem tudnak kielégítően működni, és így adatvesztés léphet fel. Az osztottkeret 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 kelllennie, 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 adottcélállomáshoz. Éppen ezért ha van két forrásunk számos kapcsolattal és erősen forgal-maznak ugyanahhoz az állomáshoz, a keretnek elegendően nagynak kell lennie, hogybeleférjen mindekét forrás kimeneti tárolója. Ha ez nem teljesül, akkor a syslog-ng nemaktiválja a flow-control-t és ezáltal üzenetvesztés léphet fel.

41


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 adottsyslog-ng szerverhez kerülnek elküldésre. A syslog-ng alkalmazás a kimenő üze-neteket 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 ebbea tárolóba helyezi el a további üzeneteket. Ennek a mérete állítható, mégpedig alog_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 üze-neteket, 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 elveszniaz ü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 enge-délyezni kell a flow_control() flag-et a logpath-ban. Ez a típusú flow-control mindenfajta 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 helyrekell elküldeni. Ha a flow-control aktív és az egyik célállomás nem képes fogadni azadott üzenetet, akkor a többi sem fogja megkapni, mert a syslog-ng leállítja a forrásolvasását. Például van egy üzenetünk, amit el kell küldeni egy távoli szerverhez, és

42


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ódikbele!

43

6. fejezet

Összefoglalás

Remélem sikerült az olvasót valamilyen szinten bevezetni a logolás világába. Mostan-ra biztos világossá vált, hogy ezek a többnyire egyszerű szöveges tartalmak mennyirehasznosak tudnak lenni adott esetben. Abban az esetben, ha ez a dolgozat nem lettvolna elegendő, bátran ajánlom az irodalomjegyzékben szereplő web helyeket továbbikutatá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 is-merteté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ármikorletöltheti és kipróbálhatja, abban az esetben pedig, ha nagyobb léptékű felhasználásbangondolkodik, 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/system-logging.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 álla-pot)

[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 ál-lapot)

[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áju-si állapot)

[10] Crystal Reports - http://en.wikipedia.org/wiki/Crystal_Reports (2013. májusi ál-lapot)

[11] Levonta az Azure-kimaradás tanulságait a Microsoft -http://www.hwsw.hu/hirek/48224/microsoft-windows-azure-leallas-szokoev-felho-cloud.html (2013. májusi állapot)

[12] Windows Event Log - http://msdn.microsoft.com/en-us/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áju-si állapot)

[23] The syslog-ng Open Source Edition 3.4 Administrator Guide -http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.4-guides/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. Azelső könyvtár neve "Diplomamunka", ebben található maga a szakdolgozat LATEXesforrá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 szakdolgozatkészítésekor érvényben lévő szabadon elérhető mintaadatbázist tartalmazza, melyet asyslog-ng használhat. Az adatlemez egyéb állományt nem tartalmaz.

47

Documents

J:/Dokumentumok/EGYETEM/Szakdolgozat/Saj䄐t …phd.lib.uni-miskolc.hu/JaDoX_Portlets/documents/document_14576_… · 1. fejezet Bevezetés Napjaink rohanó világában az információ