Kicsit ugyan ferdítve szól a mondás, de ha már van két magyar termékünk, próbáljuk meg őket összehozni!
Syslog-ng
"A syslog-ng™ termékcsalád, a nyílt forráskódú technológiától a kulcsrakész log szerverekig, a naplóüzenetek gyűjtésének és feldolgozásának vezető megoldása 1997 óta." - szól a leírás a balabit.hu-n. Valóban, a termék bizonyított, tudja a dolgát.
Patterndb
A syslog-ng szerver képes a naplóüzenetek valós idejű, nagy teljesítményű feldolgozására, melynek során a naplóüzeneteket a felhasználói közösség által összegyüjtött mintázatokhoz (pattern-ek) illeszti.
LOGalyze
A LOGalyze egy központi napló gyűjtő és elemző rendszer. Képes valós idejű elemzésre. Gyűjt, parszol, osztályoz, aggregál, korrelál, riaszt.
Syslog-ng + Patterndb + LOGalyze
A LOGalyze-nak megvan az az előnye, hogy képes a logok begyűjtésére számos módon önállóan is, be is tudja azonosítani azokat, fel is tudja bontani. Akkor miért is kell nekünk a syslog-ng?
A naplógyűjtés, elemzés bonyolult folyamat, ráadásul szétválasztható, de legalábbis egymásra épül. Számos szervezetnél a központi naplógyűjtés már hosszú idők óta megbízhatóan üzemel, amikor felmerül az igény a begyűjtött naplók valós idejű és automatizált elemzésére. Ilyenkor nyilvánvalóan nem szeretnék a meglévő naplózó infrastruktúrát lecserélni, inkább hozzáillesztik az elemzőt a gyűjtő rendszerhez, ami az esetek többségében nem is jelent problémát.
Tételezzük fel, hogy van már egy központi naplógyűjtő rendszerünk syslog-ng alapon. A küldő eszközök halmaza heterogén: Linux, Windows szerverek, hálózati eszközök, stb. A logokat a központi syslog-ng szerver fogadja, és file-okba rendezi forrás hoszt és dátum alapján. A napi rutinba tartozik a naplók és a naplózási folyamat ellenőrzése. Incidens estén jön a jól bevált grep és társai (sort, uniq, awk és cut). Sőt, vannak perl scriptek is, amik bizonyos időközönként végigfutnak a logokon és adatok gyűjtenek, esetleg riasztanak valamilyen mintára. Egyszerű esetekre a swatch-ot is használják. Ha belegondolunk, ez már egy jól működő központi gyűjtő és elemző rendszer lehet. Vagyis lehetne, ha nem csak az a rendszergazda tudná használni, aki kiépítette.
De valljuk be, az ilyen rendszerek előbb vagy utóbb eljutnak abba a fázisba, hogy a adatgyűjtések válaszideje már nem elégséges, a riasztások bővítése bonyolult és körülményes, az aggregáció kezelhetetlen. Ekkor jön képbe egy logelemző rendszer. De ragaszkodnak a bevált gyűjtő megoldáshoz.
Mit csináljunk?
Semmi gond, illesszük az elemzőnket a syslog-ng szerverünkhöz!
Az egyszerűbb megoldás
A LOGalyze illesztése egy syslog-ng-hez nagyon egyszerű: készítjünk egy új tcp destinationt a LOGalyze szerverünk IP:port adataival (titkosíthatjuk is a csatornát) és küldjük át a logokat párhuzamosan a LOGalyze-unknak. Ő majd egy syslog kollektoron keresztül fogadja, értelmezi, felbontja, elemzi.
De mi van akkor, ha van már syslog-ng oldalon is felbontás és osztályozás patterndb segítségével? Ekkor felmerül a kérdés, hogy milyen módon tudnám ezeket az adatokat is az elemzésnél felhasználni.
A szép megoldás
A syslog-ng 3.3 újdonsága a json template. Ez egy kimeneti sablon, ami arra képes, hogy a kimeneten JSON formátumú serializált adatokat küldjön. Ez mehet file-ba is, de mehet socketen távoli cél felé. Nézzünk egy ilyen logot:
{ "HOST": "ubuntu1", "PRIORITY": "info", "MESSAGE": "Failed password for username from 10.0.2.15 port 56148 ssh2", "FACILITY": "auth", "PROGRAM": "sshd", "DATE": "Feb 3 12:23:38" }Nincs felbontás, csak a sylsog mezők serializálva.
Mi értelme van ennek? Hiszen az elemzőnk a syslogot is megérti, miért jó, ha JSON.ban megy az adat? Akkor, ha jól struktúrált adataink vannak, valljuk be, semmi. A JSON - és társai - akkor hasznosak, ha adataink struktúrálatlanok, azaz minden objektum (esetünkben logsor) más mezőkből áll, nem is tudjuk előre, hogy milyenekből.
Pont ilyen struktúrálatlan adathalmazt kapok, ha egy naplóállományt elkezdek szétbontani mezőkre. Minden logom más adatokat tartalmaz, más mezők nyerhetők ki belűlük, más információhoz szeretnék jutni általuk. Mégis egy csatornán kell őket továbbítanom, hiszen egy helyen keletkeznek és egy egy helyen gyűjtöm őket.
A LOGalyze az elemzési folyamat során ilyen struktúrálatlan objektumokat gyárt. A sylsog-ng patterndb segítségével ilyen struktúlálatlan adatokat gyárt, amit aztán továbbít valahogyan valahová. File-ba, hálózaton, adatbázisba.
Lássuk, hogy is néz ki egy patterndb-vel parszolt log syslog-ng oldalon:
{ "HOST": "ubuntu1", "HOST_FROM": "ubuntu1", "usracct.service": "ssh2", "usracct.authmethod": "password", "LEGACY_MSGHDR": "sshd[2045]: ", "usracct.sessionid": "2045", "PRIORITY": "info", "SOURCEIP": "127.0.0.1", "MESSAGE": "Failed password for bvamos from 10.0.2.15 port 56148 ssh2", "FACILITY": "auth", "TAGS": ".classifier.system,.source.s_src,usracct,secevt", "usracct.application": "sshd", "PROGRAM": "sshd", "secevt.verdict": "REJECT", "DATE": "Feb 3 12:23:38", "PID": "2045", "SOURCE": "s_src", "usracct.username": "bvamos", "usracct.device": "10.0.2.15", "usracct.type": "login" }
Jól néz ki. Külön vannak a fontos mezők, ráadásul nevesítve. Van osztályozás. Van még egy szépséghibája, hogy az eseménynek nincs egyedi azonosítója, de ez már csak konfiguráció kérdése, könnyen belevarázsolhatjuk a patterdb szabály azonosítóját a logba, látni fogjuk a LOGalyze képernyőjén.
Akkor küldjük át ezt a LOGalyze-nak.
# Patterndb aktivalasa
parser p_db{ db-parser(); };
destination d_json_tcp{
tcp("<REMOTE_IP>") port("<PORT>")
template("$(format_json --scope all-nv-pairs --scope core)\n");
};
# Parszolt adatok atkuldese json formatumban tcp socketen
log{ source(s_remote); parser(p_db); destination(d_json_tcp); };
Mit lát ebből a LOGalyze? Ahhoz, hogy fogadni tudja, kell egy socketen hallgatózó kolektor, ami képes értelmezni a JSON formátumban jövő adatokat. Még szerencse, hogy van ilyenje. A főbb paraméterei:
- DTP: socket (a megfelelő ip-vel és porttal)
- DF: json
Nézzük, hogy is néz ez ki:
Látom, jött is már log (Events processed: 491). Keressük meg! Ehhez a legegyszerűbb keresési kifejezés a '_df:json', ami minden logot megjelenít, ami JSON formátumú kollektoron jött. Azért tegyünk még hozzá egy patterndb mezőt is: '_df:json AND usracct.username:bvamos'! Raw nézetben látjuk a teljes JSON formátumú logot.
Váltsunk át Syslog nézetbe, és nézzük meg a parszolt mezőket is! Gyönyörű!
A többi már csak fantázis kérdése, gyárthatunk statisztikát amivel aggregált adatokat kapunk, készíthetünk egyszerű, vagy korrelált eseményeket a parszolt mezők felhasználásával.
Jó elemzést!
