Sziasztok,
Kérdésem a következő lenne illetve kíváncsi lennék, hogy máshol ezt hogyan oldják meg / mik a tapasztalatok:
- Központi log tárolás (Graylog)
- Azok üzemeltetnék a log szervert, akik a többi szervert is (nincs akkora létszám, hogy ez szeparálható lenne)
- On-prem környezet és Linux infrastruktúra
Hogyan oldható meg, hogy egy üzemeltető admin ne tudja manipulálja a logokat, úgy hogy közben a rendszert ő maga üzemelteti? Bizonyos WORM "Write once read many" fájlrendszerekről olvastam, de nincs velük tapasztalatom. Ha nem írható a fájlrendszer, akkor hogyan oldható meg a log rotation + retention?
Ha valaki nyomokat szeretne eltüntetni maga után akkor nyilván nem csak a manipulálás, hanem a teljes naplóállomány törlése is játszik.
Bármilyen jól bevált praktikát, fájlrendszert vagy "elvet" szívesen fogadok! HUP-on próbáltam hasonló témát keresni, de nem igazán találtam.
Köszönöm!
Hozzászólások
WORM cuccok pl de AWS-en is tarolhatod
Mennyi penz van erre ? :)
a WORM cucc is csak a már kiírt adatok megváltoztatása ellen véd, egy 'elszánt' admin még ez előtt be tud avatkozni...
zrubi.hu
Nem, igen ... az ellen nem ved ... :)
Ilyet biztosan nem lehet megakadályozni.
Naplózni (audit) azonban lehet, és pl checksum alapján az esetleges változásokra 'triggerelni'.
QRadar pl. checksum-ot csinál minden beérkező (és tárolt) event-hez, de ez is csak akkor ér valamit ha nem ugyan azon a node-on tárolják, mint magát az eventet :) - és az evil adminisztátor is bele tud kontárkodni ha nagyaon akar. Cserébe erről meg audit bejegyzés készül, ami meg csak akkor ér valamit ha ez azonnal egy remote - és más által üzemeltetett gépre - is megy :)
Szóval nem triviális, és én nem is tudok olyan termékről amelyik ezt hitelt érdemlő módon - és out of te box - tudja.
zrubi.hu
Checksum integritasvedelemre jo. HW kulcsos digitalis alairas mar jobb.
A digitális aláírás nem rossz, de az is kell hogy ne tudjon random log bejegyzéseket kitörölni, tehát mindig alá kell írni az előző bejegyzésből képzett hash-t is, gyakorlatilag egy blockchain jellegű dolgot építve. De itt még mindig ott van a probléma hogy ha az üzemeltető hozzáfér a digitális aláírást végző szolgáltatáshoz akkor 0-ról létre tud hozni egy valid log-chaint.
Ha blokkok kerulnet alairasra es a titok ismeretlen, hisz egy hw taroloban van (pl privat es publikus kulcs par). Ha megfelelo eszkozt hasnzalunk akkor idobelyeggel is el lehet latni a blokkot, igy a hamisitas kiderul. Ettol meg a hamis entry problema megmarad.
Ha ezt olyan tarolora helyezzuk ami write only es fizikailag nem fer hozza az akarki, akkor ami logolasra kerull, abban lehet bizni.
Igen, egy write only tároló kombinációval ez már elég erős védelmet ad.
Az SSB (by Balabit/OneIdentity) ezt csinálja ki tudja éve (10+), saját vagy külső/hiteles TSA szerverrel. Chunk-onként láncolva aláír és ha kell kulcspárral titkosít.
A manipulálás detektálható (integrity), illetéktelen hozzáférés (confidentiality) megakadályozható.
Csak az alvailability-re (nem törölhesse le az egész file-t pl.) kell megoldást hozni.
Ez azért egy nehéz feladat mert ugye mindig átconfigurálhatja a rendszert úgy hogy logok ne kerüljenek irásra, még ha nem is tudja megváltoztatni. Egy megoldás ha szervert elindítani csak közösen lehet. Először config módba kerül, ekkor lehet beállításokat eszközölni, majd utána ha átlép live módba, akkor mindenkit kizár. Ha a log szerver nem elérhető akkor a funkciók leállnak. Ha újraindítják, akkor is csak közösen lehet bármit csinálni. A szervernek pedig tampered-proofnak kell lennie. Azt is meg kell oldani hogy a log szervert ne tudják szimulálni.
Ehhez az kell hogy magát a rendszert ennek megfelelően tervezzék és fejlesszék. Nagyon nem triviális feladat, és nem úgy működik hogy fogunk egy meglévő rendszert és beconfigurálunk valamit és már biztonságos is lesz.
meg mindig felhuzhat egy iptables szabalyt es akkor nem jon at log a tobbi szerverrol. ha udp akkor a stringmatch-al meg pontosan szurni is tud, nemcsak minden drop. a syslog-ot is le tudja allitani a kuldo gepen. stb.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
A küldő géphez elindulás után hozzá se tud férni, egyszerűen nem fog tudni belépni, csak a tulajdonossal közösen, ujraindítás után. Ennek az a trade-offja hogy az update-et csak rendszerleállás mellett lehet végrehajtani.
Ha loggolás nem a rendszeren történik hanem külső logszerre, akkor ahhoz se szabad hozzáférést engedni, ha pedig a küldő és a log szerver között megszűnik a kapcsolat (erős authentikációval) akkor az üzleti funkciókat a szerveren le lehet állítani.
De ez ilyen nagyon trükkös cucc, kell hozzá teljes threat modeling hogy minden helyzetre legyen válasz, és baromira drága.
Az is látszik hogy ehhez a megoldáshoz custom log megoldást kell implementálni, a graylog és társait el kell felejteni, nem erre valóak.
Haha. Jaja, ize vedjuk a lopas ellen azt az autot aminek a kulcsat odaadjuk a potencialis tolvajnak. Itt az a kerdes, hogy mi a maximum amit thehetunk, idealis megoldas nincs, teny.
megkell fizetni az admint, es akkor nem akar logokat eltuntetni... lehet olcsobb mint csillagrombolot epiteni
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nem tudod mire kell es a pontos helyzetet sem, de remek es univerzalis megoldast ajanlottal :)
OP: plz menjen a megoldva tag a topic cime ele!
Ez akkreditációs követelmény, vagy manageri agymenés?
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Ez szerintem egy baromi jó kérdés, nagyon gyorsan nagyon drága projekt lehet belőle.
Mi a baj azzal, ha valami sok mernoknek ad hosszunidon keresztul munkat?
Raadasul meg erdekes is a feladat, nem valami lampa kigyulladasara gombot nyomni...
Egyébként jogos, ez egy érdekes feladat, mi is elég sokat szórakoztunk vele mire egy elég jó megoldást össze tudtunk rakni.
Az, hogy ilyenkor másra nem fog jutni pénz, amire meg valóban kéne. Jön egy manager, aki olvasott valamilyen buzzwordöt, és a rendelkezésre álló büdzsét erre szórja el, miközben meg valójában máshol sokkal jobb helye lenne.
A pénz ugyanúgy el van költve, a mérnökök ideje ugyanúgy le van kötve, csak éppen a hasznossága kérdőjeles.
> ...egy üzemeltető admin ne tudja manipulálja a logokat, úgy hogy közben a rendszert ő maga üzemelteti?
Olyan nagyon drága project nem lesz belőle, ha egy második adminra nincs keret... :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Nem egy admin van, hanem több. Nem kicsi infrastruktúráról beszélünk, de ettől függetlenül ez nem kivitelezhető. A fenti leírást csak példaként írtam E/3-ban.
Na de ha emiatt kell beszerezni havertől erre való célszoftvert, vagy éppen a manager látott a konferencián valami hiperszuper előfizetéses szoftvert, ami ezt megoldja, az sokba kerülhet. És emellé indkolatlan még egy admin, hiszen a hiperszuper SaaS megoldja majd minden egyéb költség nélkül.
Egyrészt hatósági megfelelés, másfelől szerintem ez egy legitim igény, hogy valahogyan legyen biztosítva a log sértetlensége. E nélkül a napló nem tudja teljes körűen ellátni azt, amire való. :-)
Syslog-ng esetén van egy logstore nevű file formátum (destination) ami időpecsételve tárolja a logokat.
Ezzel minden sorról lehet tudni, hogy mely időpecsétek között keletkezett, valamint az adott blokk hash értéke miatt (amire az időpecsét készül) az is bizonyítható, hogy a log tartalma nem változott. Mivel mindig benne van az előző blokk hash értéke is, ezért blockchainről beszélünk, vagyis egy múltbéli adat megváltoztatásához hamisítani kéne az összes utána következő időpecsétet.
Az időpecsétek hamisítása még akkor sem triviális, ha a rendszerben root joga van, főleg, ha az kívülről jön, egy megbízható (és a helyi admintól független) időpecsét szolgáltatótól.
https://www.syslog-ng.com/whitepaper/white-paper-the-logstore-file-form…
Az Airbus is írt egy secure logging modult a syslog-ng hez. Ez elérhető az open source verzióban is. Nem tudom mennyire van jövője a Syslog-ng PE-nek egyébként amiben a logstore megtalálható (fizetős megoldásban). Az One Identity nem úgy tűnik hogy erőforrásokat nyomna a fejlesztésébe. A syslog-ng core fejlesztők nekem úgy tűnik már mind az az AxoSyslog forkba fejlesztenek. :)
De hátha van itt a HUP-on olyan magyar (ex) fejlesztő aki tisztázza a helyzetet :)
https://archive.fosdem.org/2020/schedule/event/security_secure_logging_…
https://man.archlinux.org/man/secure-logging.7.en
Igen, elvileg és a gyakorlatban is elég jól működik, de nekem anno volt vele némi elméleti gondom.
Ha jól emlékszem az időpecsét blokkokra vonatkozik, minden blokk végén van erre pár mező. A napló bejegyzések tudnak nagyon gyorsan is jönni míg az időpecsétnek lehet némi késleltetése. Ebben az állapotban - a blokk már tele, az időpecsét szerver még a gatyáját húzza - csupa nulla van a mezőkben. Ha én gonosz admint játszanék akkor megkeresném az inkrimináló naplóbejegyzést - ha nem tudtam megakadályozni hogy egyáltalán elérjen a logstore-ig - kitörölném a blokkból és nullára állítanám az időpecsétet. Ha chainelve van akkor utána a többit is (mindig is chainelve volt? nekem nem rémlik).
Egy analízis persze kibuktatná hogy a logstoreból eltűnt az időpecsét, de - és itt van egy nagyon nagy HA - ha jól emlékszem a CLI tool erre nem kiabált, azaz nagy eséllyel nem szúrná ki senki. Ha kiderül akkor lehet azzal védekezni hogy "hát vasárnap délutántól nem ment az időpecsét szolgáltatás, de hétfőre megjavult". Hogy ezt el is hiszik-e, az már más kérdés.
Sosem próbáltam ki, ezt csak a doksi alapján gondoltam végig.
Leporelló :)
Amúgy meg hátha hasznos: https://hup.hu/node/175192
Léteznek már olyan szolgáltatók, akik szolgáltatásként biztosítanak log tárolására lehetőséget. Ott biztos, hogy nem férsz hozzá adminként a géphez, mert csak egy web-s felületet kapsz, ahol van lehetőséged keresni.
Naponta freetsa timestamp és backup ?
NetApp SnapLock is lehet, van "appendable" módja is: https://docs.netapp.com/us-en/ontap/snaplock/commit-files-worm-state-ma…
Rotálásra szerintem nincs mód vagy túlságosan kacifántos, inkább abban kellene gondolkodni, hogy eleve rotált névbe mentesz, például app1-20250113.log
A visszatartás pedig adódik: beállított ideig nem tudod törölni.
Amire figyelni kell: nem olcsó a NetApp tároló, egy szöveges napló pedig tömörítve jelentősen méretgazdaságosabb lehet, így vagy azt csinálod, hogy eleve tömörítve tárolod, vagy pedig egy idő után (például egy hét) adott intervallum naplóit összetömöríted és úgy tartod vissza. Ekkor a visszatartást úgy kell beállítani, hogy a tömörítetlen fájlokat a tömörítés után már törölhessed.
Ez nem "out-of-the-box" megoldás erre a célra, kell vele játszani (az admin hozzáféréseken is kell meditálni: ha mégis kell törölni, akkor miként lehessen), de akár jó is lehet, ráadásul sok minden másra is.
fájlokat rotálni?
LOL
Egy normális SIEM nem clear text file-okba tárolja a begyűjtött logokat :)
Ha file rotálással kell bohóckodni az már régen rossz.
szerintem.
zrubi.hu
A fő kérdés így hangzik: "Hogyan oldható meg, hogy egy üzemeltető admin ne tudja manipulálja a logokat, úgy hogy közben a rendszert ő maga üzemelteti?", további kérdés: "hogyan oldható meg a log rotation"
Ebből én azt veszem ki, hogy elfogadjuk a naplók keletkezését (bármilyen módon is történjen vagy akár ne történjen), ami már megvan, az maradjon is úgy, az üzemeltető ne tudja piszkálni.
Én ezt látom feladatnak, kérdező számolja ki, hogy mely megoldás mennyiért oldja meg a problémáját, válassza ki a legolcsóbbat. Ha egy normális SIEM a legolcsóbb, nyilván azt.
Szerintem.
egyébként lehet köpködni, de a systemd-journald ezen igények nagy részét megoldja.
kombinálva egy jól belőtt auditd-vel szerintem simán átmegy a legerősebb compliance check-eken is.
És nem mellesleg értelme is van/lenne. :) - de ez ugye keveseket érdekel :D
Persze ehhez :
- nem szabad utálni a journald-t csak azért mert systemd-vel kezdődik a neve. Persze szeretni sem kell ;)
- erősen el kell határolódni az ilyen hybrid
szarságoktólmegoldásoktól mint amit legtöbb helyen látni:Hogy a (r)syslog olvassa a journal-t, majd leírja a végeredményt lokális file-okba, esetleg még egy harmadik szuper agent ezeket a file-okat felolvassa, és elküldi az xy- SIEM (szerű) képződméyn irányába titkosítatlanul. brrr.
zrubi.hu