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 over 9 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 over 9 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 over 9 years ago
I think 'unlimited' can have serious drawbacks on high traffic. The suggestion before seems sane.
Updated by Duane Howard about 9 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 over 8 years ago
This seems like something that would be reasonable to target for 3.1, yes?
Updated by Victor Julien over 8 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 8 years ago
What's the status of this feature request? It would be useful in my organization too. Thanks.
Updated by Victor Julien about 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.2beta1