Project

General

Profile

Bug #635

Some keywords missing in list-keyword command

Added by Eric Leblond almost 7 years ago. Updated 5 days ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
low
Difficulty:
low
Label:

Description

A keyword like 'tcp-pkt' does not appear in list-keyword output because it is only defined by a string match in detect-engine-proto.c

We should find a way to declare this keyword and have them displayed in list-keyword option.


Related issues

Related to Optimization #2602: add keywords to --list-keywords outputClosedActions
Related to Feature #1872: add --list-decoder-protos or similarAssignedActions

History

#1

Updated by Victor Julien almost 7 years ago

  • Status changed from New to Assigned
  • Assignee set to Eric Leblond
  • Target version set to TBD
#2

Updated by Victor Julien over 1 year ago

  • Target version changed from TBD to Documentation
#3

Updated by Victor Julien over 1 year ago

  • Assignee changed from Eric Leblond to OISF Dev
#4

Updated by Victor Julien over 1 year ago

  • Assignee deleted (OISF Dev)
  • Effort set to low
  • Difficulty set to low
#5

Updated by Travis Green 11 months ago

  • Assignee set to Travis Green
#6

Updated by Travis Green 11 months ago

  • Assignee deleted (Travis Green)
#7

Updated by Travis Green 11 months ago

Also tcp-stream

Did not find a place to add to sigmatch_table.

#8

Updated by Victor Julien 8 months ago

#9

Updated by Victor Julien 8 months ago

  • Assignee set to Travis Green
  • Target version changed from Documentation to 5.0beta1

These could be hardcoded into the list-keywords output. Travis can you take a stab at this?

#10

Updated by Victor Julien 6 months ago

  • Target version changed from 5.0beta1 to 5.0rc1
#11

Updated by Victor Julien 5 months ago

  • Assignee changed from Travis Green to OISF Dev
#12

Updated by Andreas Herz 5 months ago

AFAICS this is true for all of those defined in detect-engine-proto.c so is it still the better approach to go for hardcoding them?

#13

Updated by Andreas Herz 5 months ago

https://github.com/OISF/suricata/pull/3902

Although we can also go for the suggestion from #1872 what do you prefer?

#14

Updated by Andreas Herz 5 months ago

  • Related to Feature #1872: add --list-decoder-protos or similar added
#15

Updated by Philippe Antoine 4 months ago

One solution may be to add a test that will do a diff between the output of `suricata --list-keyword` and `grep strcasecmp src/detect-engine-proto.c | cut -d'"' -f2`

#16

Updated by Victor Julien 4 months ago

  • Assignee changed from OISF Dev to Andreas Herz

Andreas I think I like #1872 better for solving this indeed.

#17

Updated by Andreas Herz 4 months ago

I agree.

Should we add another line at the "Supported Keywords" output to make sure folks know that there are more specific keywords available as well?

Just want to avoid people missing keywords cause they missed they are listed in another section.

#18

Updated by Victor Julien 3 months ago

You can experiment with what that could look like. In general having all the options nicely grouped in suricata -h and the man page would go a long way too I think.

#19

Updated by Andreas Herz about 2 months ago

I played around with it and also saw that I forgot to add the output for the options =all and =csv. I don't think it should be solved different as it makes sense for the case in #1872 where we have some protos that aren't a keyword while we have only keywords here. So as a user I would expect to see really all keywords. This list might grow huge and so far we don't have a nice sorting or logical split between the keyword list. So I have some ideas:

1. Just add the missing keywords hardcoded to have those in the same output. This is easy but a bit ugly due to the hardcoding
1.1. I don't see how it get be done like all the other keywords without a bigger rewrite of the code of this part. I don't think we will add many in the future but the more generic way looks much nicer. So maybe a rewrite might be worth it.

2. Rewrite the whole "list-keywords" part to restructure the ouput to make it easier to read/parse instead of just a plain list. The most difficult part is to define how it should look like, how we want to sort and group and make it clear how it would behave for new keywords.

3. You mentioned the man page as well. Wouldn't it be enough to have the keywords listed and explained in the documentation and also in the manpage so you have it local? This also means more effort.
3.1. Currently we have 192 lines of output in --list-keywords, with =all even 694 lines. IMHO that's not perfect for outputs.
3.2. We can still keep the command line options and link to the docs and/or manpage

Please let me know what you think about that, idea 1 is quite easy and can be easily added to 5.0.

#20

Updated by Victor Julien 27 days ago

  • Target version changed from 5.0rc1 to 5.0.0
#21

Updated by Victor Julien 5 days ago

  • Target version changed from 5.0.0 to 6.0beta1
#22

Updated by Victor Julien 5 days ago

I think we can create a table in the code that is used to parse rules instead of the current hard coded DetectProtoParse() logic. E.g. something like:

struct {
    const char *name;
    uint8_t proto;
    uint8_t flags;
} proto_table[] = {
    { "tcp", IPPROTO_TCP, 0 },
    { "tcp-pkt", IPPROTO_TCP, DETECT_PROTO_ONLY_PKT },
    { "tcp-stream", IPPROTO_TCP, DETECT_PROTO_ONLY_STREAM },
}

Then walk this table both in parsing and for parsing output.

Also available in: Atom PDF