Project

General

Profile

Actions
Copy link

Feature #1373

closed
DH GL

Allow different reassembly depth for filestore rules

Feature #1373: Allow different reassembly depth for filestore rules

Added by Duane Howard about 11 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Giuseppe Longo
Target version:
3.2beta1
Effort:
Difficulty:
Label:

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.

VJ Updated by Victor Julien about 11 years ago Actions
Copy link
 #1

I guess setting those flows/sessions to 'unlimited' would be good enough? Or would a more gradual approach be better?

DH Updated by Duane Howard about 11 years ago Actions
Copy link
 #2

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.

PM Updated by Peter Manev almost 11 years ago Actions
Copy link
 #3

I think 'unlimited' can have serious drawbacks on high traffic. The suggestion before seems sane.

DH Updated by Duane Howard over 10 years ago Actions
Copy link
 #4

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.

VJ Updated by Victor Julien over 10 years ago Actions
Copy link
 #5

  • Target version set to 70

AH Updated by Andreas Herz over 10 years ago Actions
Copy link
 #6

  • Assignee set to OISF Dev

DH Updated by Duane Howard about 10 years ago Actions
Copy link
 #7

This seems like something that would be reasonable to target for 3.1, yes?

VJ Updated by Victor Julien almost 10 years ago Actions
Copy link
 #8

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Giuseppe Longo

Eric and Giuseppe are working on this.

CK Updated by chris K. over 9 years ago Actions
Copy link
 #9

What's the status of this feature request? It would be useful in my organization too. Thanks.

VJ Updated by Victor Julien over 9 years ago Actions
Copy link
 #10

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 3.2beta1
Actions
Copy link

Also available in: PDF Atom