Feature Request: Endpoint for searching past analyzed PCAPs

[deadbits]

Add an API endpoint to search and return Bro results by job UUID.

Idea I had is using something simple like TinyDB to store any job UUID as the db's primary key and the bro log path in path key or similar. A user could hit /search/<job_uuid> and get back the zipped logs from the job_logs_bro path or an JSON API error message if the job isn't found.

I started a test of this TinyDB and it works pretty OK for a quick starter. Expanding the TinyDB use further a tiny bit, adding an API route for /jobs/count (for example) and returning the number of all jobs analyzed would be trivial.

Is this something desired I can put in a PR for?

[arollyson]

I definitely like the idea, it has been on my personal todo list for awhile but never got around to implementing it.

You could probably get away with doing it without a DB too possibly if you were just concatenating the configured storage directory with the job UUID and just counting the folders in the dir on demand. But maybe a DB would be better in the long run, I haven't really given the implementation too much thought. Probably best to limit dependencies in any case.

[deadbits]

Yeah that's a good point.. The dir structure does lend itself nice to something like this. it should work just fine without tinydb or whatever. Same idea of building directory location on demand could also work for my other ticket of optional S3 storage. If users decided to send everything there, the Bucket structure could be built exactly the same way. I'll test this out tonight or tomorrow morning and hopefully get a PR in soon.

…

-- Adam M. Swanda PGP: keybase.io/deadbits

On Dec 26, 2017, 7:50 PM -0700, Alek ***@***.***>, wrote: I definitely like the idea, it has been on my personal todo list for awhile but never got around to implementing it. You could probably get away with doing it without a DB too possibly if you were just concatenating the configured storage directory with the job UUID and just counting the folders in the dir on demand. But maybe a DB would be better in the long run, I haven't really given the implementation too much thought. Probably best to limit dependencies in any case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.