Following that guide works fine, there are a number of intel hits on Tor activity within minutes of restarting Bro. When we add in the giant list of intel from CriticalStack the Tor intel hits no longer trigger which suggests an issue with that file. Commenting out the tor.intel file sort of narrows it down to the CriticalStack file but it also suggests that a bad intel file somehow corrupts previously read files. (they both use a list of Tor exit nodes from the Suricata project.)
I’ve checked the files for correct headers, no spaces, and tab formatting all which seem to be OK.
Nothing stands out. Looking at base/frameworks/intel/input.bro is there a way to hook Input::add_event and have those events written to a log file ? I tried moving a new intel file into place but didn’t notice anything in reporter.log or stderr.
Thanks, that linter is finding errors. I just started using CriticalStack with Bro 2.5 so I can’t comment on prior issues.
If the linter is working as expected then it appears the problem is with a few URIs from PhishTank with odd URL encoding, maybe they are mistakenly being interpreted as tabs during parsing or corrupting some internal state within Bro.
If the linter is working as expected then it appears the problem is with a
few URIs from PhishTank with odd URL encoding, maybe they are mistakenly
being interpreted as tabs during parsing or corrupting some internal state
within Bro.
Theoretically malformed items should not affect previously loaded intel
files. If you can reproduce this issue and provide something like a
minimal example it would be good to open a ticket.