BSD process accounting

Nežli se začneme zabývat security audit frameworkem, podívejme se do historie na jeho předchůdce - tradiční BSD process accounting, který byl poprvé implementován v BSD 3.0 z kterého se pak dostal do Version 7 AT&T UNIXu a velice rychle se stal se standardní součástí snad všech unixových systému, kde přetrval dodnes.

Ačkoliv je dnes BSD process accounting považován za jedno z bezpečnostních opatření, tomu odpovídá i jeho zařazení do security sekce FreeBSD Handbooku, dříve tomu tak nebylo. Jak již jméno napovídá, primárním účelem BSD process accountingu je protokolovat informace o spuštěných procesech abychom pak mohli uživatelům vystavit fakturu za použitý CPU čas a paměť. Kromě CPU času a spotřebované paměti se protokoluje i jméno spuštěného programu, takže se dá v případě nutnosti zjistit, co uživatel spouštěl za aplikace. Sledování aktivit uživatele ovšem nebylo primárním účelem tohoto systému. Pro detaily o údajích zaznamenaných accountingem se podívejte do manuálové stránky

V dřívějších dobách, řekněme před 20 lety, Unixové systémy nebyly tím, co může provozovat každý. Byly drahé. V USA bylo poměrně běžné místo provozování vlastního systému si Unixový systém pronajmout. Ušetřily se tak pořizovací a provozní náklady a nebyla k tomu potřeba žádná high-tech technologie, úplně postačoval terminálový program a 2400 BPS modem s V42bis kompresí. Využívalo se zejména faktu, že cena místních telefonních hovorů byla prakticky nulová. Placení pouze za spotřebované systémové zdroje bylo tak výhodné pro obě strany.

S použitím BSD accountingu pro fakturování se lze setkat i dnes. Nejčastěji bývá použit na výpočetních clusterech a čas od času se s ním setkáte při provozování virtuálních serverů. Kromě již výše zmíněného využití pro sledování aktivit uživatelů se využívá dnes také pro statistiku a sledování zátěže serverů.

Security Event Auditing

Na rozdíl od dříve popisovaného systému, je primárním úkolem Security Event Auditingu sledování aktivit uživatelů. FreeBSD implementuje standard BSM (Basic Security Module). Aplikační rozhraní a souborový formát a je kompatibilní s BSM implementací jak v Sun Solarisu, tak v Apple Mac OS X, ačkoliv ne všechny volby ze Solarisu jsou implementovány ve FreeBSD.

Instalace

Instalace je jednoduchá. Stačí překompilovat kernel s volbou options AUDIT (nelze přeložit jako modul) a v rc.conf pomocí auditd_enable="YES" povolit spuštění auditd. Po instalaci nově přeloženého kernelu a rebootu by se měl auditd bez problémů spustit.

Feb  6 09:37:47 sanatana auditd[77072]: starting...
Feb  6 09:37:47 sanatana auditd[77082]: dir = /var/audit
Feb  6 09:37:47 sanatana auditd[77082]: New audit file is /var/audit/20070206083
747.not_terminated
Feb  6 09:37:47 sanatana auditd[77082]: min free = 20
Feb  6 09:37:47 sanatana auditd[77082]: Registered 441 event to class mappings.
Feb  6 09:37:47 sanatana auditd[77082]: Registered non-attributable event mask.
Feb  6 09:37:47 sanatana auditd[77082]: Audit controls init successful

Standardně se ukládají security logy do adresáře /var/audit, v reálném nasazení se doporučuje pro tento adresář použít vlastní diskový oddíl, aby případné zaplnění diskového prostoru neohrozilo ostatní aplikace.

Konfigurace

Konfiguraci najdete stejně jako na Solarisu v adresáři /etc/security a tvoří ji následující soubory:

audit_class - obsahuje seznam tříd událostí. Po specifikaci tříd se používá bitová maska, z čehož vyplývá díky použitému datovému typu maximální počet tříd 32, ve standardní konfiguraci je jich z toho použito 17.

audit_event - obsahuje seznam událostí (povětšinou se jedná o syscally), jejich slovní popis a jejich zařazení do třídy. Jedna událost může být zařazena do více než jedné třídy.

Ačkoliv jsou oba dva soubory uživatelem modifikovatelné, v praxi není jejich modifikace v naprosté většině případů nutná.

Hlavní konfigurace se nachází v souboru audit_control, který je rozdíl od předchozích dvou krátký a jednoduchý:

dir:/var/audit
minfree:20
filesz:0
policy:cnt
flags:lo
naflags:lo

Tato konfigurace obsahuje následující nastavení: Protokolační soubory jsou ukládány do adresáře /var/audit, pokud volné místo v tomto diskovém oddílu poklesne pod 20 procent systém vygeneruje varování, maximální velikost jednoho log souboru je neomezena (pokud ji omezíme auditd bude rotovat logy), protokolační politika je cnt (continue) - systém bude pokračovat v činnosti i když nebude možné provádět audit, flags je seznam auditovaných tříd pro všechny uživatele a naflags označuje seznam auditovaných tříd pro události ke kterým nelze přiřadit uživatele. V obou případech je v default konfiguraci uvedena třída lo neboli login/logout události.

K jednotlivým třídám lze přiřadit prefix - (auditovat pouze neúspěšné pokusy) nebo + (auditovat pouze úspěšné pokusy), standardně se auditují obě skupiny. Více podrobností najdete v manuálové stránce.

Posledním konfiguračním souborem je audit_user ve kterém se nastavuje auditování specifické pro jednotlivé uživatele. Formát souboru je jednoduchý - jedná se o tři položky (jméno uživatele, třídy co se mají auditovat, třídy co se nemají auditovat) oddělené dvojtečkou. Jako příklad uvedu záznam www:fc,+ex:no, který pro uživatele www zapne auditování vytvořených souborů (fc) a úspěšně spuštěných programů (+ex), nebude potlačena auditace žádných tříd ze standardní konfigurace (no).

Pokud potřebujete poradit s konfigurací tak vhledem k tomu, že BSM se používá v Solarisu již dost dlouho, lze s úspěchem googlovat a vyhledat si články o BSM, které často obsahují doporučené konfigurace. Já osobně jsem po prostudování vzorových konfigurací začal s nastavením flags: pc,ad,ex,lo naflags: lo,na,ad.

Administrace systému

Administrace systému je jednoduchá. Pokud pomineme problematiku archivování či odmazávání starých logů, což si musí administrátor zajistit vlastními prostředky, jediným administrativním nástrojem je příkaz audit sloužící k ovládání auditd démona. Příkaz audit umí poslat 3 žádosti: přepnutí logu, znovu načtení konfigurace a shutdown. Za zmínku ještě stojí script audit_warn v adresáři /etc/security. Auditd jej volá s argumentem closefile a jménem souboru, pokud je uzavřen démonem protokolační soubor a s parametrem soft, pokud pokleslo volné místo na svazku pod nastavenou hranici. Auditd volá audit_warn i pro oznamování různých chybových stavů, které lze tak poměrně elegantně ošetřit.

Prohlížení logů

header,93,10,audit startup,0,Tue Feb  6 09:37:47 2007, + 352 msec
subject,root,root,wheel,root,wheel,77082,77082,0,0.0.0.0
text,auditd::Audit startup
return,success,0
trailer,93
header,87,10,login - local,0,Tue Feb  6 11:04:59 2007, + 490 msec
subject,-1,root,wheel,-1,-1,43564,4294967295,0,0.0.0.0
text,Login incorrect
return,failure : Operation not permitted,2
trailer,87
header,68,10,login - local,0,Tue Feb  6 11:05:01 2007, + 745 msec
subject,hsn,root,wheel,hsn,users,43564,43564,0,0.0.0.0
return,success,0
trailer,68

Pokud jej spustíte na zařízení /dev/auditpipe můžete systémové události monitorovat online. Užitečným pomocníkem je filter auditreduce, který filtruje záznamy podle zadaných kritérií. FreeBSD na rozdíl od Solarisu neobsahuje GUI aplikaci pro prohlížení logů a na žádný open source ekvivalent jsem nenarazil.

Závěr

Odhaduji, že vzhledem k jednoduché konfiguraci si BSM audit najde k uživatelům cestu mnohem snadněji nežli MAC framework. Pokud si BSM uživatelé dostateční oblíbí určitě se brzo dočkáme kvalitních programů pro zpracování logů a podpory v IDS systémech.