Feature #1373
closed
Allow different reassembly depth for filestore rules
Added by Duane Howard about 9 years ago.
Updated over 7 years ago.
Description
In order to capture full files, stream reassembly depth needs to be > file length, in many cases this would mean expanding stream reassembly to several MB. However for non-filestore rules most badness and detection can happen in the first few KB, so reassembling seems wasteful. It could be interesting to have a distinct option to reassemble streams that match of filestore rules to a different depth than those that are not filestore rules.
I guess setting those flows/sessions to 'unlimited' would be good enough? Or would a more gradual approach be better?
It could be good enough, but it could cause other issues (DoS comes to mind, filling up a disk). It'd be helpful to be able to say:
for all alert type rules, inspect up to 2MB
For files, extract up to 15MB or similar.
I think 'unlimited' can have serious drawbacks on high traffic. The suggestion before seems sane.
As discussed during the user conference a solid way forward with this might be to be able to specify a unique depth in the filestore rule itself. (maybe we could reuse the 'tag' keyword?) This would allow a lot of flexibility in defining how long to track and write stream content based on each file type, etc.
This seems like something that would be reasonable to target for 3.1, yes?
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Giuseppe Longo
Eric and Giuseppe are working on this.
What's the status of this feature request? It would be useful in my organization too. Thanks.
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.2beta1
Also available in: Atom
PDF