Hello, all,
I have a question about the intel framework: if a flow matches both an Intel::ADDR and Intel::CERT_HASH (for example), will the intel framework generate notice logs for both matches, or just one?
Right now it looks like it's just flagging on one, but I'd like to make sure I haven't done something wrong.
Thanks.
aaron
It should definitely match both. That's a problem if it's not.
.Seth
Thanks, Seth.
I've done some more digging on this, and I'm a bit more confused than when I started (not the first time that's been true). I have put a cert for a server I control into the intel framework with a line like this:
62e00e51aaf306e7738a50d7c1f4746d271f9a12 Intel::CERT_HASH blacklist_test https://testingurl/ T -
Bro's intel framework never fires for connections to the host with this cert. I do see the cert's hash in files.log, so it is being passed over the wire past bro. If I add the host's IP to the intel file, the intel framework generates notices properly, so I know the intel framework is loaded & generally working.
The thing that confuses me is that when I look at the scripts in policy/frameworks/intel/seen, I can see scripts that will generate source information for every Intel type *except* for Intel::USER_NAME and Intel::CERT_HASH. Am I barking up a wrong tree here, or did those two not get implemented in the intel framework scripts?
If they did get implemented, then I'm not sure what I'm doing wrong...I just can't get bro to fire for SSL cert hashes. I'm running bro 2.3.1 (just updated today), if that makes any difference.
Thanks.
Aaron
Sorry, that's my mistake. I never actually implemented a script that used CERT_HASH. Just make those FILE_HASH instead. That's more proper anyway now that certs are handled as files.
.Seth
There also aren't scripts that use USER_NAME, but I have some
additions to fix that. 
No worries. That's fixed it. I'm seeing hits for certs when I change to use FILE_HASH.
Thanks for your help.
aaron