A BSM (Basic Security Module; ~”alapvető biztonsági modul” – a későbbiekben előnyben részesített megnevezése „Solaris Auditing„) egy integrált kernel-szintű rendszerfelügyeleti eszköz, amely teljes körű rendszernaplózási lehetőséget biztosít. Igény szerint képes a rendszeren zajló majdhogynem összes történést nyomon követni, és azokat bináris formátumú naplóállományokba írni, vagy syslog-kiszolgálóra továbbítani. Képességei megfelelnek az amerikai C2 információ-biztonsági besorolás minősítési kívánalmainak.
Bevezetés
Jelen van a Solaris-ban modulként annak 2.3-mas kiadásától, és funkcionalitásának jelentős része korábban is elérhető volt hol kernel-patch, hol modul formájában. (Az HP-UX és AIX rendszerek is rendelkeznek hasonló implementációval.)
Telepítést egy standard (S10u3+) rendszeren nem igényel (csomagfüggőségei: SUNWcar, SUNWcsr, SUNWcsu, SUNWhea és SUNWman); üzembe helyezése és beállítása minimális konfigurációt követően rendkívül egyszerűen, néhány lépésben kivitelezhető. Az /etc/security/bsmconv script futtatásával engedélyezhetjük a működését; mivel azonban ez bizonyos kernelszintű elemek életre lehelésével és lényegi konfigurációs változásokkal jár, ezen a ponton a folyamat megköveteli a rendszer egyszeri újraindítását.
(Hasznos lehet tudni, hogy a folyamat reverzibilis – ugyanott a bsmunconv script is fellelhető.)
A szolgáltatás elindítását megelőzően szükséges bizonyos beállításokat áttekinteni, ehhez azonban valamelyes rálátás szükségeltetik a BSM lelkivilágára. Az audit-alrendszer az általa követni képes történéseket (eseményekhez kötött rendszerhívásokat) ún. esemény-osztályokra bontva határozza meg, melyek többek közt a következőek:
(…)
fr: állomány olvasása
fw: állomány írása
fa: állomány-tulajdonságok lekérése
fm: állomány-tulajdonságok módosítása
fc: állomány létrehozása
fd: állomány törlése
cl: állomány lezárása
lo: be- vagy kijelentkezés
ad: adminisztratív tevékenység
pc: folyamatkezelés
ex: végrehajtás
(…)
Létezik és használható természetesen az „all” elnevezésű, ún. meta-eseményosztály is. (A teljes lista megtekinthető az audit_class man-oldalon.) Igény szerint személyre szabott, új osztályok is kialakíthatóak. Megjegyzendő továbbá a tárolt adatok vonatkozásában, hogy (a GNU userland hasonló eszközével szemben) a Solaris rendszerek BSM moduljával csak a teljes filerendszer-struktúra egésze vizsgálható. Megkülönböztet a rendszer ezen belül sikeres avagy sikertelen besorolású eseményeket is, melyeket a + és – aritmetikai műveleti jelekkel lát el. Kivétel jelölésére a ^ használatos.
Ezek összessége adja az ún. „jelölőket” (flags), amelyeket meg kell határoznunk.
Köthetőek ezen események felhasználókhoz is (ilyenkor az /etc/security/audit_user állomány beállításai érvényesülnek kiegészítőleg), és külön kezeltetnek az erre alkalmatlan (rendszerint a rendszerhez kötődő, és ritkán előforduló) bejegyzések is a naflags (non-attributable flags) direktívában – ezek kerülnek ilyen esetekben rögzítésre.
A tényleges beállítás az /etc/security/audit_control állományban történik az alábbi módon:
dir:/var/audit
flags:
minfree:20
naflags:lo
Fenti, alapértelmezett esetben a naplófile-ok a /var/audit könyvtárba íródnak, kijelölt eseményosztályok hiányában nem sok tényleges haszonnal kecsegtetve. A napló-állományoknak otthont adó filerendszer kapacitása 20 százalékánál kevesebb rendelkezésre álló tárterület határértékét elérve figyelmeztetést kapunk.
Amenyiben nyomon kívánnánk követni rendszerünkön a ki- és bejelentkezéseket, úgy a flags direktívában meg kellene adjuk az érintett eseményosztálynak megfelelő „lo” jelzést.
A konfigurációs állomány az auditd SMF-szolgáltatás elindításakor kerül beolvasásra. Futásidőben eszközlendő változtatások esetén az állomány szerkesztését követően a /usr/sbin/audit -s parancs kiadásával olvastathatjuk újra és juttathatjuk azokat érvényre.
Az auditálásért felelős szolgáltatás elindításának legkényelmesebb módja az auditd SMF szervíze elindítása a /usr/sbin/svcadm enable auditd parancs kiadásával. A szolgáltatás állapota felől a /usr/sbin/auditconfig -getcond utasítás futtatása útján tájékozódhatunk.
A /usr/sbin/modinfo | fgrep c2audit paranccsal előzetesen ellenőrizhetjük a szükséges kernelmodul rendelkezésre állását. Természetesen a futó folyamatra magára is vethetünk nyugalmunk érdekében a /usr/bin/ps -p `/usr/bin/pgrep audit` beírásával egy pillantást…
A szolgáltatás szabályos indítása az /etc/security/audit_startup script által történik. Ebben az állományban célszerű rögzítenünk a szolgáltatásnak átadandó paramétereket is. Ennek eszköze ismét a /usr/sbin/auditconfig utasítás, melyet a megfelelő kapcsolókkal (-setpolicy) ellátva állítható be a BSM tulajdonképpeni, szolgáltatás-szintű finomhangolása a már ismert – és + előjelekkel értelemszerűleg ki- avagy bekapcsolva. Néhány az itt alkalmazható házirend-lehetőségek közül:
(…)
conf: az események és ~osztályok összerendelése a tárolt adatbázis alapján
aconf: a nem társítható (non-attributable) maszk beállítása az /etc/audit_control szerint
cnt: erőforrások elfogytakor ne függesszen fel folyamatot, a logba írandó rekordot dobja el és számolja – azaz növelje az eldobott rekordokat nyilvántartó numerikus számláló értékét
ahlt: az audit-események írási sorban való megakadásakor állítsa le a rendszert
argv: végrehajtás esetén az argumentumok rögzítése a paramétersorból
arge: a végrehajtáskor élő környezeti változók rögzítése
(…)
A BSM ún. „zones-aware” (~zóna-tudatos) alkalmazás, tehát alapesetben is képes együttműködni a Solaris natív virtualizációs technológiájával. E célt a +perzone és a +zonename házirend-opciók szolgálják, melyeket a „host” szerepet ellátó, ún. „global zone” BSM -jében állítunk be. Futtatható avagy elhagyható a naplózás globálisan átfogó, vagy zóna-specifikus módon is. (Előfeltétele azonban zóna naplózásának a gazdagép BSM moduljának engedélyezése a zónák különleges, a kernel használatának módját érintő jellegéből adódóan.)
A futó auditról számos információt kérdezhetünk le a megfelelő jogosultság birtokában. Ezek közül például informatív lehet a /usr/sbin/auditconfig -getstat parancs kimenete.
Az audit-folyamat rögzített kimenetének filenév-formátuma tartalmaz időbélyeget és az érintett rendszer nevét. A rögzítés alatt álló, nyitott állományt ezen felül a .not_terminated. filenév-taggal ellátva is megkülönbözteti a rendszer. Új állomány folytatólagos megnyitására, egyidejűleg a nyitott állomány lezárására a /usr/sbin/audit -n paranccsal szólíthatjuk fel a modult. Bevált gyakorlat a kimenet megkívánt darabokra való felszabdalása céljára ezen utasítás automatikus végrehajtásra történő időzítése. Futásidőben manuálisan felszabadított tárterületre a pkill -HUP auditd avagy a /usr/sbin/svcadm refresh auditd parancsokkal hívhatjuk fel a figyelmét.
A keletkező naplók („trail„), amint azt korábban már említettem, céleszköz igénybe vétele nélkül nemigen emészthetőek; alapértelmezésben is rendelkezésünkre áll azonban két segédeszköz: a /usr/sbin/praudit és a /usr/sbin/auditreduce program. Mindemellett a kimenet számos egyéb módon is feldolgozható lehetőségeinknek és ízlésünknek megfelelően. Egyes kereskedelmi IDS (Intrusion Detection System; ~”behatolás-jelző rendszer„) termékek is hasznát veszik. A felhasznált eljárás az igényekhez választandó.
Teljesítmény tekintetében elmondható, hogy a rendszerhívások mellett végrehajtásra kerülő auditálási kód nagyságrendileg 5-10 százalékos teljesítménycsökkenéssel jár a BSM-et futtató rendszerre nézve. Ez azonban az esetek többségében elfogadható kompromisszum a kiemelt biztonságot igénylő környezetekben.
További, megfontolást igénylő szempont még az ún. auditnyom tárhely-igénye, melynek mértéke az audit mélységének függvénye – valamint a rögzített naplók hozzáférhetősége, adatbiztonsága.
A BSM rendkívül gazdag dokumentációval rendelkezik; man-oldalak tucatjai taglalják részletesen mindazt, amiről én igyekeztem a fentiekben röviden értekezni – emellett a szakma ajánlásai (best practice) és számos esettanulmány is fellelhető az Interneten.
Demonstráció
Demonstrációm céljaira egy teljesen újonnan telepített Solaris 10 rendszert használok fel az alábbiakban:
Látható, hogy alapesetben a szolgáltatás inaktív. Aktiválásához a már említett scriptet hívom meg:
Újraindítás feltétlenül szükséges a továbbiakhoz!
Az újraindítást követően látható, hogy a szolgáltatás valóban elindult:
Ellenőrizzük az alapértelmezett konfigurációs beállításokat, valamint azok érvényre jutását:
Megváltoztatom a konfigurációs beállításokat:
A változások érvényre juttatását kézzel kell kikényszerítenünk: (a /usr/sbin/audit -s parancs futó auditok folyamat-előválasztóit (process preselection mask) NEM változtatja meg!)
Látható, hogy az „ad” meta-eseményosztály által új jelölőkkel egészült ki a feltételek listája. Az ezeket tartalmazó adatbázisra vetett gyors pillantás további tételes információkkal szolgál:
Végezetül vessünk egy pillantást az audit-naplóra:
Szemmel láthatóan eredeti, bináris formátuma magában kezelhetetlen, de a rendelkezésünkre álló eszközök közül a legalapvetőbbekkel is nagyságrendekben kifejezhető javulást érhetünk el.
Rövid ismertetőm végére érkeztem. Remélem, sikerült a téma iránt érdeklődő kollégák figyelmét felkeltenem, számukra valamelyes betekintést, a használatba vétel megkezdéséhez segítséget nyújtanom!
