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.
- Keith > On Jul 15, 2016, at 11:54, Johanna Amann <[email protected]> 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? > > Johanna > > 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 >> >> -- >> Seth Hall >> International Computer Science Institute >> (Bro) because everyone has a network >> http://www.bro.org/ >> >> >> _______________________________________________ >> bro-dev mailing list >> [email protected] >> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
