[Bro-Dev] Remove application/pkix-cert from files.log?
klehigh at iu.edu
Fri Jul 15 09:58:13 PDT 2016
I agree that having the certs logged to files.log creates a lot of noise that can be painful to wade through. The downside to placing the hashes in x509.log is that would require a 2nd step of turning the fuid’s into cuid’s when searching for activity involving a given cert hash. What about the idea of having files.x509.log & simply diverting pkix-cert to that log by default? Keeping “files” in the name, allows one to search for <hash> in files*.log and use unix tools to grab the conn details. Quite useful when you have a mixed list of cert hashes and other hashes of interest.
> On Jul 15, 2016, at 11:54, Johanna Amann <johanna at icir.org> wrote:
> I think kind of like having the certificates being handled as files by
> default. However, I see that most people who run clusters in production
> do not want that information in files.log. So - from my point of view,
> it might make sense to have a policy script that filters certificates
> from files.log and adds the hashes to x509.log; and we have that
> auto-loaded by default in local.bro.
> Would that make sense?
> On 15 Jul 2016, at 8:08, Seth Hall wrote:
>> What does everyone think of making some change for 2.5 so that
>> certificates from SSL aren't logged in the files.log by default? I've
>> heard grumblings about the number of certs that show up from quite a
>> few people and personally noticed that the number of certificates will
>> dwarf all other files types pretty badly which makes the output look a
>> bit weird since very few people are ever interested in looking at
>> those files in the files.log.
>> Certificates would still be passed through the files framework, so
>> it's not an architectural change, it would all be related to just not
>> doing the log. There is one minor issue that this brings up though in
>> that right now certificate hashes are all given in the files.log. We
>> could move them elsewhere like x509.log or ssl.log, but I'm curious if
>> anyone had thoughts on what they think would be most useful?
>> Seth Hall
>> International Computer Science Institute
>> (Bro) because everyone has a network
>> bro-dev mailing list
>> bro-dev at bro.org
> bro-dev mailing list
> bro-dev at bro.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3569 bytes
Desc: not available
Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20160715/741a3b8e/attachment.bin
More information about the bro-dev