Project

General

Profile

Actions

Feature #2486

open

Task #4380: tracking: improvements to bits, ints, vars

prefilter/fast_pattern logic for flowbits

Added by Jason Williams about 6 years ago. Updated over 1 year ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

It would be useful to have a way to indicate that a rule with a flowbit check should only be checked in the event that the set flowbit appears in the flow.

This could reduce the number of checks on signatures with poor fast_pattern candidates and time spent matching only to throw away the match because the flowbit was not present.

For example:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET CURRENT_EVENTS HTTP POST Form Observed After Successful Credential Theft"; flowbits:isset,ET.genericphish; file_data; content:"method=|22|post|22|"; nocase; sid:123; rev:1;)

This rule can be very useful for generic phish detection, but because the only content we're looking for is the post, we incur lots and lots of checks as thats the only available match for fast_pattern


Related issues 3 (3 open0 closed)

Related to Suricata - Task #2685: SuriCon 2018 brainstormAssignedVictor JulienActions
Related to Suricata - Task #3288: Suricon 2019 brainstormAssignedVictor JulienActions
Related to Suricata - Task #4097: Suricon 2020 brainstormAssignedVictor JulienActions
Actions #1

Updated by Andreas Herz about 6 years ago

  • Target version set to TBD
Actions #2

Updated by Victor Julien over 5 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Victor Julien

I think this can be done with some limitations. Since prefilter runs before the actual rules, it could FN if one of the rules sets a flowbit after the prefilter has run.

A simple solution could be to simply limit the prefilter support to flowbits that are set in one direction, and checked in the other direction.

Another more complex setup could be that when setting a flowbit the rules that depend on it (and use it as a prefilter) are added to the rule 'candidate' list. Here the rule order would probably have to be taken into account.

Actions #3

Updated by Victor Julien over 5 years ago

  • Related to Task #2685: SuriCon 2018 brainstorm added
Actions #4

Updated by Victor Julien over 4 years ago

  • Related to Task #3288: Suricon 2019 brainstorm added
Actions #5

Updated by Victor Julien over 4 years ago

At Suricon 2019 there was still interest for this.

Actions #6

Updated by Jeff Lucovsky over 3 years ago

  • Related to Task #4097: Suricon 2020 brainstorm added
Actions #7

Updated by Victor Julien over 3 years ago

  • Target version changed from TBD to 7.0.0-beta1
Actions #8

Updated by Victor Julien about 3 years ago

  • Parent task set to #4380
Actions #9

Updated by Victor Julien over 2 years ago

  • Status changed from Assigned to In Progress
Actions #10

Updated by Victor Julien over 1 year ago

  • Target version changed from 7.0.0-beta1 to 8.0.0-beta1
Actions

Also available in: Atom PDF