Project

General

Profile

Actions

Bug #558

closed

rule analyzer: print fast_pattern and it's buffer

Added by Victor Julien almost 12 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

== Sid: 2000499 ==
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg: "ET ATTACK RESPONSE FTP inaccessible directory access COM1"; flow: established; content:"/COM1/"; nocase; classtype: string-detect; sid: 2000499; rev:6; )
    Rule matches on reassembled stream.
    Fast_pattern: "/COM1/" in reassembled stream
    Rule contains 1 content options, 0 http content options, 0 pcre options, and 0 pcre options with http modifiers.
    No warnings for this rule.

Additionally, if a signature matches on http, we should warn if the fast pattern is not in a http buffer.

Actions #1

Updated by Anoop Saldanha almost 12 years ago

  • Status changed from Assigned to Resolved
Actions #2

Updated by Victor Julien almost 12 years ago

  • Status changed from Resolved to Assigned

The pull request makes the assumption of removing the old fast pattern analysis, but this is not what this ticket specified. Only adding the fast pattern and warnings to the rule analysis is what should happen. The detailed fp analysis should be kept separate like how it is now. It has it's own use. Adding everything to the rule analysis clutters it's output too much.

Actions #3

Updated by Anoop Saldanha almost 12 years ago

replied to in the github pull request.

Actions #4

Updated by Victor Julien almost 12 years ago

Anoop Saldanha wrote:

replied to in the github pull request.

Please reply here. Here we discuss what needs to be done for a ticket. In the PR it's about code implementation details.

Actions #5

Updated by Anoop Saldanha almost 12 years ago

Yes. If the rule analysis requires printing fast_pattern and the buffer it works on, we might as well print another 3-4 lines and describe the fast_pattern. And it's also indented to show it's a separate section. This is much better imo. If you are inspecting 1000 rules and you are in the middle of a rule_analysis_file checking out sid xx. Now you want to check the fast pattern analysis for xx, you will have to open the other file, and search for sid xx in the file. It's much simpler now imo.

Actions #6

Updated by Victor Julien almost 12 years ago

My reason exactly for not adding it. 3 to 4 lines per rule for a 1000 rules results in 3000 to 4000 extra output and will clutter the output too much.

Actions #7

Updated by Anoop Saldanha almost 12 years ago

Victor Julien wrote:

My reason exactly for not adding it. 3 to 4 lines per rule for a 1000 rules results in 3000 to 4000 extra output and will clutter the output too much.

This is the output -

Sid: 2000499
alert http $EXTERNAL_NET any -> $HOME_NET 21 (msg: "ET ATTACK RESPONSE FTP inaccessible directory access COM1"; flow: established; uricontent:"/COM1/"; nocase; classtype: string-detect; sid: 2000499; rev:6; )
Rule matches on reassembled stream.
Rule matches on http uri buffer.
App layer protocol is ALPROTO_HTTP.
Rule contains 0 content options, 1 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern analysis:
Fast pattern matcher: http uri content
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Content negated: no
Original content: /COM1/
Final content: /COM1/
No warnings for this rule.

You have 1000s of lines for the analysis printed for all the rules, but you inspect the analysis per rule and next move to the next rule.

You don't even have to jump to another file like before to read the fast pattern analysis. All at the same place, within 8 - 10 lines. How is this even clutter?

Actions #8

Updated by Peter Manev almost 12 years ago

just a suggestion - in this particular example there is no fast_pattern - so maybe do not print the fast pattern analysis... ?
But if there is - i like how the output looks

Actions #9

Updated by Anoop Saldanha almost 12 years ago

Peter Manev wrote:

just a suggestion - in this particular example there is no fast_pattern - so maybe do not print the fast pattern analysis... ?
But if there is - i like how the output looks

We do that currently. If no fast pattern's set, we don't print it. Check this out

-------------------------------------------------------------------
Date: 26/9/2012 -- 13:47:01
-------------------------------------------------------------------

Sid: 20004991
alert http $EXTERNAL_NET any -> $HOME_NET 21 (msg: "ET ATTACK RESPONSE FTP inaccessible directory access COM1"; sid: 20004991; rev:6; )
App layer protocol is ALPROTO_HTTP.
Fast Pattern analysis:
No content present
No warnings for this rule.

This is the output from the analysis file for 2 rules loaded from the rules file.

-------------------------------------------------------------------
Date: 26/9/2012 -- 13:48:12
-------------------------------------------------------------------
Sid: 2000499
alert http $EXTERNAL_NET any -> $HOME_NET 21 (msg: "ET ATTACK RESPONSE FTP inaccessible directory access COM1"; flow: established; uricontent:"/COM1/"; nocase; classtype: string-detect; sid: 2000499; rev:6; )
Rule matches on reassembled stream.
Rule matches on http uri buffer.
App layer protocol is ALPROTO_HTTP.
Rule contains 0 content options, 1 http content options, 0 pcre options, and 0 pcre options with http modifiers.
Fast Pattern analysis:
Fast pattern matcher: http uri content
Fast pattern set: no
Fast pattern only set: no
Fast pattern chop set: no
Content negated: no
Original content: /COM1/
Final content: /COM1/
No warnings for this rule.

Sid: 20004991
alert http $EXTERNAL_NET any -> $HOME_NET 21 (msg: "ET ATTACK RESPONSE FTP inaccessible directory access COM1"; sid: 20004991; rev:6; )
App layer protocol is ALPROTO_HTTP.
Fast Pattern analysis:
No content present
No warnings for this rule.
Actions #10

Updated by Anoop Saldanha almost 12 years ago

the formatting seems to be screwed up in redmine. The mail should have it properly formatted like in the output file.

Actions #11

Updated by Victor Julien almost 12 years ago

Yes I think the output is cluttered. Please stick to the original requirements of this ticket.

Actions #12

Updated by Anoop Saldanha almost 12 years ago

Victor Julien wrote:

Yes I think the output is cluttered. Please stick to the original requirements of this ticket.

I would sure have veto'ed you, if I had the chance. But hey, you are the boss!

Actions #13

Updated by Victor Julien almost 12 years ago

My rationale is that the rule analyzer is meant to give basic info + warnings. It's not meant to go into a lot of detail. The problem with adding detailed fp info and consequently all kinds of other signature details is that the file will become huge and hard to quickly pass over. I think there is definitely a use for an increased detail level, but in a separate output.

In my mind the typical use of this rule analyzer output will be with "warnings-only" where rule writers can quickly see how to improve/fix sigs.

Actions #14

Updated by Anoop Saldanha almost 12 years ago

Victor Julien wrote:

My rationale is that the rule analyzer is meant to give basic info + warnings. It's not meant to go into a lot of detail. The problem with adding detailed fp info and consequently all kinds of other signature details is that the file will become huge and hard to quickly pass over. I think there is definitely a use for an increased detail level, but in a separate output.

In my mind the typical use of this rule analyzer output will be with "warnings-only" where rule writers can quickly see how to improve/fix sigs.

8-10 lines isn't much, at least for now. Even if it's 20 lines it would fit in a page and with neatly formatted output a rule writer can choose to read the section he wants to.

If you want to have one file per section, you'd have the rule writer open 5 output analysis file, search for the sig id amongst 1000s of sigs in each of those files, and read out the analysis for that rule? Isn't it easy to have output formatted section wise and the rule writer can choose to read the section he wants? Even the warnings would be in a section of its own.

And I certainly don't want to second guess when and what rule details we will print in the future. When that happens we can think if moving to a different file makes sense.

Appreciate if some rule writers read out the present output format(from the mail and not from redmine) and give out their preference.

Actions #16

Updated by Anoop Saldanha almost 12 years ago

  • Status changed from Assigned to Resolved
Actions #17

Updated by Victor Julien over 11 years ago

  • Status changed from Resolved to Closed
  • Target version changed from 2.0rc2 to 1.4beta3
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF