Feature #1373
closedAllow different reassembly depth for filestore rules
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.
Updated by Victor Julien almost 11 years ago
I guess setting those flows/sessions to 'unlimited' would be good enough? Or would a more gradual approach be better?
Updated by Duane Howard almost 11 years ago
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.
Updated by Peter Manev almost 11 years ago
I think 'unlimited' can have serious drawbacks on high traffic. The suggestion before seems sane.
Updated by Duane Howard about 10 years ago
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.
Updated by Duane Howard almost 10 years ago
This seems like something that would be reasonable to target for 3.1, yes?
Updated by Victor Julien almost 10 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Giuseppe Longo
Eric and Giuseppe are working on this.
Updated by chris K. over 9 years ago
What's the status of this feature request? It would be useful in my organization too. Thanks.
Updated by Victor Julien over 9 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.2beta1