Suricata

replied to in the github pull request.

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.

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.

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.

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 -

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?

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

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
-------------------------------------------------------------------

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.

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

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

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!

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.

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.

https://github.com/inliniac/suricata/pull/121