Hi, Tamper detection could be seen as file checking: for each message you can compute their md5sum and store the resulting object (message id, graylog index name, md5sum) into another Elasticsearch or database.
Mathieu Le 10 juil. 2015 02:22, "Pete GS" <[email protected]> a écrit : > I think you'll find the potential tampering is actually on the > ElasticSearch side rather than Graylog. > > Graylog simply sends the data to ElasticSearch and the most it can do once > the data is indexed is delete an index, so any tampering as such would need > to be done directly on the ElasticSearch cluster I would think. > > I'd suggest you look there, you may need to use the new Shield product > they have now for this functionality. > > Cheers, Pete > > On Thursday, 9 July 2015 20:49:10 UTC+10, Gianfilippo wrote: >> >> Hi all, >> I'm evaluating graylog2, between other solutions, for the access log >> management of some application storing personal users data. >> Because of our local regulations, one of requirements for the treatment >> of such data is the "immutability" - or at least, the possibility to detect >> tampering on the stored logs. >> Did anybody experienced any solution to achieve this with Graylog2? i.e., >> has found a solution in order to be able to detect if the stored logs have >> been tampered with. >> I have found this feature in several commercial products, but not in any >> open source alternative yet. >> >> Thank you all for your help and for any helpful hint, or path to follow. >> >> -- > You received this message because you are subscribed to the Google Groups > "graylog2" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "graylog2" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
