Samba túl beszédes audit log

Web, mail, IRC, IM, hálózatok

Sziasztok

 

Adott a következő smb.config részlet:

### full audit ########

    vfs objects = full_audit
    full_audit:prefix = %u|%I|%m|%S
    full_audit:failure = connect
    full_audit:success = audit_file mkdirat write pwrite renameat ftruncate  unlinkat openat read pread snap_delete
    full_audit:facility = local5
    full_audit:priority = NOTICE
    path = /data/Fileserver

##########################

Ha az openat benne van, akkor 1db mappa megnyitásakor, (dokumentacio) melyben 1db almappa van (helyisegrajzok, de oda bele sem lépek, csak látom), ennnyi sor generálódik (hozzászólásba illesztem).

Miért olvassa fel ennyiszer?

Cél: Mappák és fájlok olvasásáról logom legyen. A kliensek sajnos folyamatosan sasolják a mappákat és ezek tonnányi sort generálnak.
Elég volna mappába lépéskor egy. Fájl felolvasáskor 1.
Nem tudom számít-e, de öröklő ACL-ek vannak a szülő mappákon, fájlokon.

  • 426 megtekintés

( Proci85 v | 2024. 11. 26., k – 15:08 )

|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/.
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/..
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/helyisegrajzok
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/helyisegrajzok
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/.
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/..
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/helyisegrajzok
|openat|ok|r|/data/Fileserver/shares
|openat|ok|r|/data/Fileserver/shares
|openat|ok|r|/data/Fileserver/shares
|openat|ok|r|/data/Fileserver/shares
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/.
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/..
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/helyisegrajzok
|openat|ok|r|/data/Fileserver/shares/
|openat|ok|r|/data/Fileserver/shares/uzemeltetes
|openat|ok|r|/data/Fileserver/shares/uzemeltetes/dokumentacio/helyisegrajzok

 

( ggallo | 2024. 11. 26., k – 16:15 )

A Samba azt naplózza amit tőle a kliens kér. Nem a Samba gyárt ennyi sort egy mappa hozzáférésről, hanem a kliens ennyiszer fér hozzá adott módon a mappához (valami okból, nem tudom miért van erre szüksége), amit a Samba a konfig szerint le is naplóz rendesen.
Ezen szerintem semmivel nem tudsz érdemben egyszerűsítani. Az audit log helyigényes jószág.

De a mappák olvasásáról miért kell napló? Fontos, hogy valaki belépett-e egy mappába a tartalmát megnézni anélkül, hogy bármilyen állományt megnyitott volna? Ha nem jogosult, ne tudjon belépni se oda, ha meg jogosult, akkor nem elég a napló arról, ha állományt nyit meg?

Az első hsz-ben 1db mappa egyszeri megnyitásának logját látod. Szószátyár és nem értem miért. 32 log bejegyzés jön létre arról, hogy frissítést nyomtam a kliensben egy mappára.
A kliens ludas, mert ennyiszer lekéri? Lehet, bár linux a kliens, nem kellene ennyire hülyének lennie. Vagy túl érzékeny a samba config? Nem tudom.
Ha az openat nem szerepel az smb.onf -ban, semmilyen olvasási, mappa vagy fájlmegnyitási műveletről nem logol. Na ez baj.

A kettő között tényleg nincs egy jobb opció? Napi több GB-nyi log keletkezik jelenleg, pedig csak jóformán ülnek a fájlszerver előtt. 1-1 fájlt cüccögtetnek.
A log teljesen félrevezető információt logol. Adott szituban feldolgozni sem könnyű.
Szeretnénk monitpringot beállítani, log feldolgozást végezni arra vonatkozóan, ha valaki kiugróan sokat scanneli a fájlszrerver mappákat.
Ezt így lehetetlen. Oké, ez egy kevésbé fontos probléma.

"De a mappák olvasásáról miért kell napló? "

Ha feltörnek egy klienst, látnom kell, hogy mit látott. De azzal is megelégednék, ha a konkrét fájl megnyitásokat láthatnám. Jelenleg openat nélkül nem látom.

Régebben voltak "open" és "opendir" műveletek is, nem csak az "openat". Most ránéztem, és szerencsére nagyjából Samba verziónként változik a lista a gyári doksi szerint.

Mi lenne, ha csinálnál egy "full" beállítással naplót, hogy milyen eseményeket log-oz a Samba verziód, és abból csemegéznél.

( Proci85 v | 2024. 11. 26., k – 16:28 )

Szerkesztve: 2024. 11. 26., k – 16:46

-

( Proci85 v | 2024. 11. 26., k – 16:54 )

Úgy tűnik nem teljesen reménytelen a helyzet.

Ha openat helyett fcntl parancsot írok be, akkor mappába lépésekről nem logol.
1db pl. kép megnyitásról 4db tök egyforma sort belogol, de már nagyságrendi haladás.

( djsmiley v | 2024. 11. 27., sze – 09:00 )

Ugyan segíteni nem tudok, de megkérdezhetem h. ez most valami NIS2 megfelelés miatt jött elő v. tényleg csak szakmai/security megfontolásból? Bármelyik is, majd érdekel a végeredmény h. mivel tűnik a legjobbnak az audit log, ami még nem kva nagy, de benne van minden aminek értelme van.

Részletesebben válaszolok, mert több oldala van.
Kb 1 éve fut és egy kolléga által írt python script feldolgozza az audit logokat és a kiugró read, write eseteket jelenti a nagiosnak. Az eredeti cél, hogy a kiugró fájlszerver aktivitásról riasztást küldjön. Pl. ha egy crypto vírus épp dolgozik a fájlszerveren egy kolléga gépén keresztül. Vagy egy távozásra ítélt kolléga éppen lementi magának a fájszervert.
Sajnos sok fals pozitiv jelzést okozott. Ennek oka részben a fenti probléma, részben a kliens gépeken futó vírusírtó, ami minden mappába lépéskor az ott látható fájlokat gyorsan felolvassa és leellenőrzi. Utóbbi majd megoldandó, hogy kiszűrjem, kikapcsoljam(?).

A feldolgozó scriptet ideiglenesen kikapcsoltam a sok kamu jelzés miatt, de a logolás megmaradt, mert baromi hasznos, hogy minden fájlszerver műveletnek van nyoma.
Ha történik egy incidens, meg tudjuk mondani, hogy az adott gép mit csinált a fájlszerveren. Ha semmit, azt is tudjuk bizonyítani.
Egy ideje random fájlszerver lassulásról számoltak be a kollégák, akkor amikor sokan matatnak rajta. Ilyen volt tegnap is és bizony a systemd-journal tekerte a CPU-t. Nem győzte írni/feldoglozni ezt a sok logot.
Most openat nélkül sokkal nyugodtabb, cpu-t sem pörgeti.

A NIS2 szellemisége csak tovább erősít a dolgon, de már korábbi belső igény volt :)

( YleGreg | 2024. 11. 27., sze – 09:22 )

Hasonló problémát mi a következőképpen oldottuk meg:

- syslog-ng kapja a töménytelen szószátyár de leginkább monoton logot

- file destination dátum idő pattern szerint óránként gyárt külön állományt (régen naponta volt, de váltanunk kellett órára a mennyiség miatt)

- egy óránként induló cronjob a letett log állományok közül az utolsó kettőt (az utolsó két teljes órát, plusz az éppen írt állományt) békén hagyja, de ami annál régebbi (normál esetben óránként egy ilyen lesz) azt betömöríti xz -1 (ez adta az optimális méret és futás idő értékeket) paranccsal, majd átnevezi, hogy a következő futáskor ne akarja még egyszer betömöríteni

- ugyanez a script az X napnál régebbi tömörített állományokat letörli (ha már kétszer is kikerült szalagra)

Így az utolsó órákról van plain-text logunk, amiben könnyű keresni (meg egyéb gépi feldolgozást építeni rá) viszont ami annál régebbi, az már alig foglal helyet a lemezen. Az xz -1 tényleg baromi jó erre a célra.

Nem rossz gondolat a tiétek. Tovább gondoltam. Betolni syslog-ng-nek, megcsámcsogni pl. egyforma másodpercben egyforma path-ban lévő sorokat összevonni (lásd fenti ~30 log sor) és letárolni az így elő-feldolgozott logot. Később kiértékelni és könnyebb, helyet is drasztikusan kevesebbet foglal. Kicsit i/o pazaró, de egy lehetséges jó megoldás.