Fórumok
Sziasztok!
Adott egy postfix szerver, és van néhány mail log fájl a /var/log/-ban.
Olyan szolgáltatót, szolgáltatást keresek, ami ezt tudná auditálni (kvázi bizonyítani, hogy a mail.log alapján ezen levelek elküldésre kerültek, de ezen levelek nem érkeztek meg erről a címről erre a címre ebben az időpontban).
Van ilyen? Hasonló? Merre induljak?
Hozzászólások
A küldő szerver csak azt tudja megmondani, hogy a fogadó szerver fogadta, vagy sem. A fogadó oldal logjai alapján lehetne megmondani mi történt a levéllel, amennyiben azt kézbesítésre átvette.
Fedora 41, Thinkpad x280
Fogadó oldalról van szó.
Ezt az esetet kizárólag a fogadó oldalon vizsgálódva nem fogod tudni bizonyítani.
Ha nincs nyoma bejövő emailnek adott címről, illetve IP-ről, akkor nincs. A fogadó oldalon azt látod, hogy konkrétan nálad mi történt. Ehhez kell különösebb audit, egészen értelmesen elmondja a log, hogy mivel mi történt. Postfixnél a többlépcsős továbbpasszolás miatt figyelni kell, de azért az sem ördögtől való. Ha a küldő váltig állítja, hogy márpedig elküldte, akkor semmi gond, kérjétek a logokat, message trace -t vagy bármit ami szerintük bizonyítja, hogy a fogadó fél szervere átvette az emailt.
Az egy dolog, hogy elmondja a log, de ezt hogy lehet olyan formában tálalni, hogy aki nem ért hozzá, az is megértse.
Látom, hogy rossz címre küldte, ez a lényeg.
Lehet, hogy félreértem, de itt most az a cél, hogy a feladó orra alá lehessen tolni a logrészletet, vagy valami hasonlót, amiből ez kiderül (mármint, hogy rossz címre küldte a levelet)?
Ilyen célokra nálam eddig megfelelt az "User unknown..." sor, ami tartalmazza a feladó és a címzett (rossz) email címét is, ebből azért a laikus is rá szokott jönni, hogy szar van a palacsintában, amint meglátja az elírt email címet.
Csak mert kérdés lehet az, hogy egy bármin átforgatott/feldolgozott log mennyire bizonyító erejű... Számomra még az O365 Message Trace képernyőről készült screenshot is sem egészen üti meg azt a szintet, amit egy postfix, vagy exim logrészlet. (márpedig az O365-ben nincs más lehetőség email-életutat követni)
A feladóról tudom, hogy meghamisította a beküldött levelet, ez nem kérdés. A kérdés az, hogy én ezt hogyan tudom bizonyítani a logok birtokában.
Egyéb megállapodás nélkül általában a sima email akkor szokott ráutaló magatartás lenni, ha ment az adott emailre válasz is.
Megállapodás nélkül a feladó "meghamisított" meg nem érkezett emailjének milyen ráhatása lehet a cégetekre, azon kívül, hogy újra kell küldenie?
--
Légy derűs, tégy mindent örömmel!
Ha jól értem valszin az a probléma, hogy nem látszik egyáltalán, hogy adott időben/címzettnek jött a túloldalról email. Az azt látjuk, hogy nemlátjuk történet sokszor nem egyszerű.
A message trace egyáltalán nem olyan rossz. Ha jól emlékszem az lista elemek kibonthatóak, és az utolsón látszik, hogy milyen külső fél vette át a mailt. Volt egy melóm, ahol legalább heti szinten kellett emailt nyomozni, és jól használható volt az O365 trace.
A megadott időben látszik az elküldött levél a feladótól, csak más címre, mint amit becsatolt, így eldobásra is került, hiszen nem létezett. Az már csak mellékes, hogy erről nyilván kapott hibaüzenetet is (Mailer daemon).
Akkor megvan, ennyi. Ezt kell prezentálni, hogy ez látszik, ez van.
No és ennek mégis mi lenne a mikéntje? Mármint, ugye a helyzet a bölcsész bíró problémája. Most ha mellékelek neki egy postfix confot, meg egy logrészletet, és írok némi magyarázatot, az aligha lesz érthető a számára.
Ezt nem a bíró dönti el. Erre vannak az igazságügyi szakértők. Aki áldását adja arra, hogy a te plain text logod, kétséget kizáróan bizonyítja hogy nem jött meg a levél. Erre mondta, ha valaki ebben a szakmában dolgozik azt tudja, hogy egy ilyen loggal kb ki lehet törölni egy per kapcsán, mivel nem tudod te se hitelt érdemlően bizonyítani, hogy de kérem ezt tuti nem Sanyi gépelte be notepadban, hanem a postfix :D
Fedora 41, Thinkpad x280
Engem érdekelne az az eset, ahol egy e-mail bármilyen bizonyító erővel bírna, pláne bírósági ügyben...
Pontosan azért, mert semmi garancia nincs e-mail esetében nagyjából semmire (sem az üzenet eredetiségére, sem a forrására, sem a célra, se a feladásra, se a beérkezésre, sem a titkosságára, sem a tartalmára, stb), én még nem hallottam/olvastam olyan esetről, amiben nevesítetten e-mail alapján született volna döntés...
Pl. az "állami" üzenetek is azért nem e-mail-ben jönnek (csak az értesítés, hogy üzentek nekünk valamit), hanem a "tárhely"-re, mert az e-mail nem bizonyító erejű. A törvénybe meg bele lehetett írni, hogy e-mail ide, e-mail oda, a tárhelyen nézni kell van-e valami (ha jött ilyen értesítés, ha nem), és ha van ott valami, el kell olvasni, és aszerint eljárni. És az jól bizonyítható, hogy a tárhelyet megnézte, az üzenetet letöltötte az állampolgár (kvázi tértivevény értékű).
De az előttem szólókhoz csatlakozva, bírósági ügy esetén egyik fél sem bizonyít semmit (mert a bíróság számára egyik sem hiteles), hanem az igazságügyi szakártő fogja a bekért mail.log-ok (mindkét oldalról) alapján leírni, hogy innen elment a levél vagy sem, oda megérkezett a levél vagy sem. De azt még a szakértő sem tudja sehonnal bizonyítani pl., hogy mi volt a levélben...
Kisebb VH ügyekben elfogadják az emailt, ha a másik fél nem tiltakozik ellene. Legalábbis eddig úgy volt. viszont most érkezett több hamisított levél is, és arra keresek megoldást, hogy ne fogadják el. Egy vidéki bíró nem feltétlenül van tisztában azzal, hogy mi hamis, és mi nem. Lát egy jónak tűnő képet, és nincs semmilyen eszköze arra, hogy lássa, hogy ott át lett írva ez vagy az.
Szakértő kirendelését lehet kérvényezni, de kétlem, hogy egy ilyen kis horderejű ügyben kirendelnék, ahogy mások is írták.
Amúgy, jól sejtem, hogy te pont szakértő vagy?
Véleményem szerint egy vidéki bíró is ugyan olyan képzett, mint adott esetben egy budapesti. Ha nem teszel indítványt szakértő kirendelésére, nem rendelnek ki szakértőt. Ha indítványozod, nem veszítesz semmit.
Sok bírót láttam, nem is szeretnék különbséget tenni a járásbíróságok között, pkkb-n is láttam olyan eszement hibákat, amiket egy 8 éves gyerek nem vétene... . Kicsit rosszul fogalmaztam, de visszavonom.
VH=végrehajtás?
Én végrehajtó esetén olyannal találkoztam, hogy csak elektronikus aláírással ellátott emailt fogadnak el és alternatív megoldás a hivatali kapujukra küldés e-papírral vagy marad a (tértivevényes) posta. Ez meg a végrehajtó minden iratának első oldalán a fejlécben le is van írva.
Az email befogdásáról nem tudom küldenek-e visszaigazolást, viszont nem megugorhatatlan hogy, a befogadott emailrőll (pl. bekerül az iktató/ticketing rendszerbe) menjen visszaigazolás (iktatószámmal, szintén elektronikusan aláírva).
--
Légy derűs, tégy mindent örömmel!
Ez nem olyan végrehajtás szerintem, mint amire te gondolsz. Legalábbis ebben nincsenek végrehajtók, max. az eljárás nevében.
Viszont ott már kialakították azt az ügyfélkapcsolati folyamatot, amilyenhez hasonlóra valószínűleg nektek is szükségetek van.
--
Légy derűs, tégy mindent örömmel!
Mire gondolsz?
Végrehajtónál bizonyíthatónak kell lennie, hogy ki és mit küldött/kapott valamint hogy mikor és gondolom ezért van nála a fenti, bár az email nyugtázásukról nincs információm.
Ha nem akarsz elektronikus aláírást és elég hogy milyen tartalmú emailt és mikor kaptatok, akkor kommunikálhatjátok azt, hogy a megkapás tényének/idejének bizonyítása miatt csak akkor számít hozzátok megérkezettnek/befogadottnak egy email ha a feladónak visszaigazoltátok azt (pl. akár a kapott email visszaküldésével vagy iktatószám és az emailből képzett hash küldésével), mert az email esetében (általában) nincs a postához hasonló a kézbesítést megtörténtét igazolni tudó (a felektől független) harmadik fél.
--
Légy derűs, tégy mindent örömmel!
Mondjuk jogi oldalrol az mit biztonyit ? Mert bárki bármikor összedobhat egy ilyen logsort. Ahogy fogadó oldalon is bárki bármit törölhet a logból ...
Az is kérdés mi áll meg mondjuk egy bírósági perben ...
Fedora 41, Thinkpad x280
Az egy sokadik lépcső. Ha megvan a logrészlet, hogy szerintük hova ment az email, és milyen IP-n vették át, akkor oda lehet tenni mellé a sajátot. Ebben van ott lesz, hogy mi történt az emaillel, vagy nem. Ha nem, akkor lehet tovább gondolkodni, hogy kinek van igaza. Ha nem tudnak ilyet küldeni, és nem látszik nyoma az emailnek, akkor meg egész más kérdések merülnek fel. Ez már nem IT probléma valszin.
A biztos itt van a hiba, meg biztosan nem náluk van dolgot el kell felejteni. Hiszen ha náluk biztosan minden jó, (itt jó, hiszen a logokat látjuk), akkor nem probléma elküldeni azt a logrészletet, amitől úgy gondolják, hogy náluk minden jó.
Egyébként amilyen hajmeresztő emailes beállításokat, megoldásokat, SPF rekord elfelejtést, hekkeléseket látok heti szinten, igazából semmi sem meglepő. Arról már csak halkan szólok, hogy milyen fantasztikus legendák, és képzetek keringenek, hogy mi hogy befolyásol egy email kézbesítést. Addig nem jutnak el, hogy az IP címüket megnézzék, legalábbis probléma esetén, hogy fekete listán van-e, és hogy ha már listán van, akkor legalább nagyjából visszakövessék, hogy miért.
A túloldal a gmail.
Ha Google Apps, akkor ahhoz talán van egy O365 szerű message trace. Ha privát gmail, akkor nehezebb ügy valszin, de legalább az elküldött elemekben lévő email feladóját/címzettjét meg kéne tudnia mutatni. Ez persze azt jelenti, hogy a küldött fiókba IMAP-pal bemásolásra került az email, nem azt, hogy SMTP-n is kiküldésre került.
Az a baj, hogy @gmail.com os levelet küldhetek a saját szerveremről is :D A fogadón múlik elfogadja-e.
A kérdés, hogy a bíróságon mire mennek azzal:
Tisztelt Bíró úr itt a log, hogy a joska@gamil.com os címemről de a saját szerveremről elkdültem a címre a levelet és itt a log is hogy a szerverük átvette ...
Ugye ekkor kell azt mondani a fogadó oldalnak, hogy ide kérem nem jött semmi, mutatom is a semmit :D
Visszes dolgok ezek ...
Fedora 41, Thinkpad x280
Bármilyen levelet bárhonnan küldhetsz. Ha már jogi út van, akkor az egy másik szint. Most vagy valóban keresik a levelet, vagy már hisztérikusak. Utóbbi nem IT probléma.
Egyébként külső szakértőt, igazságügyit, fel lehet kérni, hogy márpedig ilyenkor auditálja. Persze ha volt annyi lélekjelenlét, hogy valami tuti módon el van rakva a log. Időbélyeg, aláírva, közjegyző... Nem túl életszerű.
Van valamilyen archiválás, de azért hogy azt egy bölcsész bíró mennyire érti meg?
Amúgy van valakinek tapasztalata az ilyen igazságügyi szakértőkkel kapcsolatban?
Na igen, lényegében ez a probléma.
Gondolom privát gmail, de ha nem az lenne, akkor sem férnék hozzá.
Bead egy hamis screenshotot, amit előállítani könnyű, de ellenbizonyítani sokkal nehezebb.
Egy dolog felett nem szabad elsiklani:
Az hogy nálad valamiről nincs log, az soha nem fogja bizonyítani egy esemény meg nem történtét - főleg ha külső eseményről van szó-, mégha a logod önmagában hiteles.
Kérdések amikre választ kellhet adnod:
Tudja ezt a fogadó szerver akkori verziója megbízhatóan logolni egyáltalán? Pl gyártói támogatás nélkül ez lehet már önmagában kérdéses, hogy ki igazolja.
Az adott időpillanatban bizonyíthatóan úgy volt az eszköz felkonfigurálva hogy ezeket logolja?
A log agent-ed bizonyíthatóan úgy volt felkonfigurálva hogy ezeket az eseményeket letárolásra továbbítsa lényeges módosítás nélkül?
Tamperproof a tárolásod? (Nem "szerinted", a gyártója pecsétes papírja szerint)
Van hivatalos időbélyeged a logokon?
...
Itt arról van szó, hogy küldött egy levelet a log szerint adott időbélyeggel a@b.hu címre, de a bíróságon olyan papírt lobogtat, hogy ugyanazzal az időbélyeggel a c@b.hu címre küldte a levelet. Persze, elméletileg lehetséges, hogy ugyanabban a másodpercben 2 helyre küldte el, de nem ez a gyakorlat.
Ezt szerintem te nem fogod tudni bizonyítani a fogadó logból, mivel több ok miatt nem lehet róla logod.
- Tényleg elküldte c@-ra, de te bármi miatt nem logoltad, szándékosan kitörölted a logból,... mert megtehetted technikailag bármelyiket
- Nem küldte el valójában
Ha neki van _hiteles_ logja,(pl google nyilatkozik erről) hogy a te szervered nyugtázta a sikeres elküldés tényét c@-ra, akkor van gond.
Csak 1 kérdés:
Aliasok, átirányítások,... nincsenek nálad estleg? c@->a@
Az átirányítás látszik a logban, nem kerül eldobásra. Ezen aranyos lovagolni, hogy dehát biztosan logolta-e, de azért ezt logolja. Egy adott rendszerből egy hozzáértő oda tudja adni, hogy ez van itt, ezt látjuk, és ezt egy igazságügyi szakértő vagy megerősíti, vagy körbehümmögi. Mindenféle jogászkodásos csűrés csavarás utána jön, mert ezt a "dehát időbélyeg, meg jujjbiztostörölte", ez már védekező álláspont, bármennyire is valódinak tűnnek.
Erre írtam korábban, hogy semmi probléma, hogy nem hiszik el, hogy mi van, és mi nincs itt, akkor tessék hozni a küldő oldali szerverről naplót, és olyan naplót, amit nem lehet ugyanazzal a készlettel szétszedni, mint ezt.
Ez nem jogászkodás, ez a való élet. Az "ilyen eseményeket tuti-tuti szokta logolni", kicsit gyenge érv + ez hülye helyzet mert azt kéne bizonyítanod hogy valami nem történt meg de te logot csak arról tudsz gyártani ami megtörtént.
Az ilyen magadnak épített, free komponensekből összerakott rendszereknek ez az egyik nagy hátránya sajnos és ezért nem szívesen használják nagy, enterprise környezetben, ahol ilyenekből gond, felelősségi vita lehet, hogy semmi háttered nincs amire támaszkodni tudsz. "Asscovering." Sokszor ez jóval fontosabb szempont, mint az hogy pl mennyibe kerül. (Nem azt írom, hogy rosszak!)
A "hozzáértés" meg elég relatív dolog, magadnak nem adhatsz pecsétes papírt, más meg nem fog ilyenre és ott állsz letolt gatyával.
Lassan 20 éve vagyok secu tanácsadási területen, nem egy hasonló ügyünk volt. Kollégám között van igazságügyi szakértő is.
Ha nem így tervezel, gondolkodsz, építed fel a rendszereidet ahol ez szempont, akkor amikor baj van nem fogod tudni bevédeni.
Nem tuti tuti, hanem ott van, és ennyi, oder nincs ott, esetleg lehet tesztelni, meg igazságügyi szakival nézegetni. A helyzet az, hogy van egy műszaki működési mód, amihez képest próbálsz jogászkodni. Hiába a letolt gatya vagy bármi, azért az nem úgy lesz sehol, hogy bemondják, hogy hát én pedig küldtem emailt, mert ennél több kell tőlük is, legalább annyi, mint a fogadó oldalon. Ráadásul ami mégsúlyosabb, hogy ugye az email tartalmáról nincs log, esetleg méretéről, akár az is lehetett benne, hogy "Pampalini", és közben meg millió eurókra hivatkozik.
Ahol ez a visszakövethetőség fontos, ott ez már nem IT igény valójában. Persze a megvalósítás valamilyen archivummal, meg auditált, meg időbélyeges csodával ellátva az IT alapú. Ahol ez fontos, hogy ott lesz rá zseton, ahol pedig nem fontos, ott marad az, amit mondok.
Egy enterprise bárminél sem lesz mindenható a log, pláne ha felhős. Esetleg a felhősnél a független fél jöhet elő, mint pozitívum.
Hány hazárdos kódot láttam már, tesztelheted akármeddig, de 100% biztos nem lehetsz benne, hogy minden esetben ugyanarra az eredményre jut. Ez önmagában nem bizonyíték sajnos.
Itt a levél küldéséről/fogadásáról van szó és az abban részt vevő komponensek megbízhatóságáról, _adott időpontbeli_ beállításáról, ezek bizonyíthatóságáról, amit kapásból meg fognak jogilag kérdőjelezni egy free komponensekből, saját magadnak összerakott megoldásnál. Egyébként én is ezt tenném. + a google van a másik oldalon. Ha neki lesz erről logja (befogadás nyugtázása), akkor vége a történetnek jogilag.
pl: Egy tértivevénnyel sem bizonyítod, hogy nem Pampalini volt a levélben, mégis elég sok helyre, hogy te elküldted, beadtad, válaszoltál,....
Egyébként így van. Vagy csinálnak egy teljes audit-ot a szoftveren (én common criteria-t csinálnék és esetleg keresnék egy kapcsolódó protection profile-t) vagy pedig külsős cég termékét
használják, akinek van erről auditja, de legalábbis valamiféle bizonyítékot tud adni, hogy az audit logságot betartják.
Én tennék rá nagyívben, erre vannak az igazságügyi szakértő "kollégák", én nem törlök logból. Auditálja akinek van ehhez kedve és szabad kapacitása. Rá kell nézni a köztisztviselői bértáblára, aztán az IT-re adott (és amúgy új dolog) évi 1 milliós költségvetési tételre amiben minden is benne van.
Ugyanitt valaki megpatchelhetné a kibaszott Nessus plugint hogy ne zaklasson az itseces false positive miatt ( én A-s vagyok az ssl teszten az NKI A-), attól hogy a nyomi autoscan képtelen felfogni mi az a multiple certificate path (és sajna az itseces csávó is) kurvára nem én tehetek.
Ugye itt jön elő az, amiről a kolléga beszélt. Ha kell bizonyító erő, akkor ehhez olyan rendszert kell építeni. Ha meg nem, akkor ennyiből mehet a log a /dev/null-ba.
Ehhez a küldő szerver logja kell, amit fent vázoltam.
Ehhez meg a fogadó szerver.
A kettőt együtt érdemes vizsgálni szerintem, bár hogy mit lehet és mit nem egy bíróságon ezekkel bizonyítani az már más kérdés.
Fedora 41, Thinkpad x280
Igen, pont az utóbbi a kérdés.
Józan paraszti ésszel bíróságon én csak olyan dolgot vennék alapul ami időbélyeggel van ellátva, legyen az egy email / documentum vagy egy logsor ...
Bár a józan paraszti ész és a jog nem mindig fedi egymást :D
Fedora 41, Thinkpad x280
törölve
Fedora 41, Thinkpad x280
írtad, hogy szolgáltatót keresel - van ilyen - nekünk partnerünk volt egy ilyen cég - de utólag nem tudják auditálni.
A logokat egy általuk kifejlesztett és telepített hosszú távú és hitelesített archiváló rendszerben tároltuk (időbélyeg, titkosítást kulcsot külön cél eszköz generálta 2 chipkártya járt hozzá, ujjnyomat olvasó a zárt rack-szekrényen stb..)
1.) Vagyis most neked azt kell körül bástyázni első sorban, hogy a logok hitelesek - gondolom nincs ilyen rendszered - így marad valamilyen - pl. logok archiválási szabályzata - írása és annak utólagos bevezetése. pl. logok archiválás, hash stb.
2.) Szépen le kell írni logikusan, hogy mi van a logban és mellékelni a logot
Nem az ügyfelet kell meggyőzni, hanem az ügyfél szakértőjét/ügyvédjét. Ők nem a logok tartalmát fogják elsőre támadni, hanem annak hitelességét..
WOKEBUSTERS
https://www.cpachungary.com/wokebusters
Kérhetek contact-ot? Csak hogy legalább rá tudjak nézni, hogy milyen cég. Nyilván utólagosan elég nehéz.
megküldtem közvetlen üzenetben.
szivesen.
WOKEBUSTERS
https://www.cpachungary.com/wokebusters
Nem kell ehhez nagy varázslat.
A tamperproof tárolás alapvető követelmény minden logmanagement esetén. Digitálisan aláírt (+ ha kell titkosított) formában Ha ezt megfejeled egy külső, hitelesített timestamp szolgáltatással (TSA) kész is vagy.
Nem reklám, de pl. egy syslog-ng Store Box (SSB) is tudja a TSA kezelést évek óta. Jó pár bevezetésen túl vagyunk, ahol nem a SIEM funkcióra kell, hanem a biztos, rugalmas, hiteles logtárolásra, ott igen jó megoldás. Házon belül marad a log (sok helyen fontos szempont), csak a hiteles időbélyeg kell kívülről.
Kaphatod ezt a timestampet hitelesített külső forrásból -TSA provider -(vagy a saját belsőjétől - de ez itt nem játszik most) és mivel a logstore chunk-onként digitálisan aláírt és titkosított a tamperproof-ság innentől megáll mint bizonyíték bárhol.
Egy sima text alapú logot sehol nem fogják elfogadni mint hiteles forrás amit a saját szervereden kupacolsz. Házon belül jó lehet sokmindenre, de hivatalos dolgokhoz kevés.
Nem egy egetverő költség - ha meg nem "fér bele", akkor maga a dolog nem olyan fontos hogy ezzel időt kelljen tölteni. Enélkül kétes kimenetelű a dolog, inkább már vízgereblyézés a te oldaladról bármit hitelt érdemlően bizonyítani bíróság előtt.
Maga a termék: https://www.syslog-ng.com/products/log-management-appliance/
Ha komolyan érdekel, tudok segíteni.
Tegyük hozzá, hogy a külső TSA provider pénzbe kerül. Nem is kevésbe ha sok a logod...
Amúgy a SSB-t még fejlesztik érdemben? Én úgy látom nagyon takarékon van. A 7.0 megjelent januárban és az OS cserén kívül semmi sem történt....
Ez relatív, de enélkül mégis hogy tudsz hiteles, bíróság előtt megálló evidenciát szolgáltatni?
(kb. a self signed vs CA issued certificate esete)
Ahogy mondni szokták:
Aki majmot vesz, annak legyen pénze banánra is. :-)
Komolyan:
Ha ez az ügy (vagy ügyek előfordulási valószínűséggel felszorozva éves szintre) nagyobb veszteséget (pénzügyi, reputációs,..) tud neki okozni, mint amibe ez a megoldás kerül 1 évre, akkor meg kell venni. Ha nem, akkor nem kell ezzel foglalkozni, be kell vállalni a buktát.
Viszonylag 1xűen eldönthető kérdés. Szerintem....
A gmail user milyen TSA-s mókát tud felmutatni ?
Ugye van feladó és van címzett , ha a címzett elzavarja picsába a levelet, hogy nálunk nincs ilyen user és ezt közli a feladóval (ok-val átveszi a gmail szervere) jogilag hol pattog a labda?
Teljesen mind1.
Itt arról van szó, hogy az általa üzemeltetett infrában hitelesnek lehessen tekinteni a keletkezett logokat.
Erre ez a megoldás.
Ha timestamp lenne minden log bejegyzésen még a baráti nisz is csődbe vinne minket. Felhős bohóckodásnál (gapps, office 365) ezt amúgy , hogy oldják meg?
Nincs is. Nem logsoronként van időbélyegezve, chunk-onként az SSB-ben.
Azt ők ismerik pontosan belülről, de az O365/Azure logolása több, mint katasztrófa.
pl. van egy csomó SaaS-os event amiről nem tud adni értékelhető logot. + ha annak az árát megnézed komolyabb legmennyiségre pl 1 éves retention-nel, akkor a TSA kb. "ingyen" lesz egy saját SSB-vel .:-)
Persze hogy fejlesztik, bár sok minden én pl. már nem tudnék beletenni. Ami logmanagementben létezik és gyakran használt funkció az kb. benne van.
Jönnek ki LTS és FR verziók folyamatosan és van OS upgrade is a secu patchek miatt.
Te mit hiányolsz belőle?
Például a mai napig nem tudsz TSA-t kérni ha basic auth van a TSA service-n vagy HTTPS illetve kliens cert auth kéne a TSA kéréshez. :)
De ugyanez elmondható a syslog-ng PE-re is... Meg kell proxyznom mindig még a kérést.
Ezek megoldhatók pl ahogy írtad - proxyzod - vagy olyan szolgáltatót használsz amit támogat.
Ha égető, add fel feature requestnek. Nekem is volt már néhány és belekerültek idővel. Bár olyan business reason-t kell adnod, ami viszonylag tágabb felhasználói kört érint.
Amit a kolléga ír, ez a korrekt megoldás.
Ahogy fentebb is írtam, én azon a vonalon indulnék el, hogy egy e-mail bármilyen bizonyító erővel bír-e és milyen feltételek teljesülése mellett. Ez jogi kérdés, nem műszaki. Ha a válasz az, hogy nem (ezt tartom a legvalószínűbbnek), akkor teljesen felesleges tovább keresni a megoldást (ami nem lesz meg, mert kell hozzá a hiteles feladó oldali napló is, nem elég a fogadó oldal akkor sem, ha az történetesen hiteles lenne).
Meg úgy paraszti logikával felmerül bennem, hogy ki reklamál és mit ebben az esetben, aki ennyira fontos, akár jogi útra terelhető dolgot kizárólag e-mail formában akar levezényelni, ráadásul ingyenes e-mail szolgáltatós fiókkal...
a túloldalnál van gmail, nálunk rendes, saját domaines levelezés.
Így értettem. Hogy a feladó free szolgáltatásról küld rettentő fontos levelet rettentő fontos ügyben ami bíróságon is kiköthet, ha valami nem stimmel. Ez az amatőrség a részéről. Meg szerintem - a műszaki oldalt ismerve - egyszerűen nevetséges e-mail fejléc vagy tartalmi adatokra hivatkozni bármelyik félnek bíróságon...
Szerintem az ügy szempontjából nehezítés és könnyítés is egyben, ha ilyen szolgáltató akár küldő, akár fogadó. A bíróság ugyan kikérheti tőlük az adatot, de ez az adatkérés sem zökkenőmentes, sem gyors nem lesz. Cserébe valószínűnek tartom, hogy a bíró azt mondja, hogy "ha a Google azt mondja így van, akkor így van", míg ha egy random magyar cégtől kérne naplót, akkor nem fogadná el ugyan így "hitelesnek" a cíg bemondására, hanem szakértőt rendelne ki az eldöntésre (hogy hiteles-e a napló részlet).
Szerintem a fogadó oldalon, bármilyen részletes és akár jogilag is hiteles naplózása van, nem lehet bizonyítani e-mail esetében semmi módon, hogy nem lett a levél elküldve egy levél. Az, hogy elküldte, csak nem jó címre ment, sem feltétlen bizonyítható, mert a tartalmat jellemzően nem naplózza (pláne hitelesen) senki, aki nem készül kifejezetten ilyen ügyekre. Így hiába jött azonos feladótól más címre levél, semmi módon nem derül ki, ugyan az a levél volt-e csak rossz címre, vagy egy tök másik levél...
A tartalmát, hogy ellenőrizné mikor az "rcpt to" -nál elküldi a szerver a p*cs*bá, hogy nincs ilyen cím. Akár hiteles a log akár nem. :)
Ha meg átvette annak a logba látszani kell :)
Hát épp azt mondom, hogy ha még meg is érkezne valami címükre a levél (nem arra, amire várják/kellene, hanem másikra, és ez benne lenne a log-ban is), a tartalma akkor sem lenne bizonyítható valószínűleg, ergo akár egy tök más tartalmú levelet is küldhetett a nem jó e-mail címre, így az azonos időpont nem bizonyít sokat...
Úgy általában, erre a digitális aláírás, illetve a valódi audit log jelenti a megoldást. Lehet fejleszteni saját audit loggoló megoldást amely teljesíti ezeket a követelményeket (nem lehet meghamisítani, törlést észreveszi, stb.) viszont szükség lesz egy joghatással rendelkező digitális aláírásra.
Azt tudom javasolni, hogy írd össze a követelményeket, és a követelmények mentén keress technikai megoldást.
Kezdetnek a Common Criteria szabványt tudom javasolni, Class FAU: Security audit része eléggé részletesen leírja, hogy egy audit loggal kapcsolatosan milyen biztonsági követelményeket érdemes megfogalmazni.
https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART2R1.pdf