Bug #635
openSome keywords missing in list-keyword command (like 'tcp-pkt')
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.
Updated by Victor Julien almost 12 years ago
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Target version set to TBD
Updated by Victor Julien over 6 years ago
- Target version changed from TBD to Documentation
Updated by Victor Julien over 6 years ago
- Assignee changed from Eric Leblond to OISF Dev
Updated by Victor Julien over 6 years ago
- Assignee deleted (
OISF Dev) - Effort set to low
- Difficulty set to low
Updated by Travis Green almost 6 years ago
Also tcp-stream
Did not find a place to add to sigmatch_table.
Updated by Victor Julien over 5 years ago
- Related to Optimization #2602: add keywords to --list-keywords output added
Updated by Victor Julien over 5 years 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?
Updated by Victor Julien over 5 years ago
- Target version changed from 5.0beta1 to 5.0rc1
Updated by Victor Julien over 5 years ago
- Assignee changed from Travis Green to OISF Dev
Updated by Andreas Herz over 5 years 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?
Updated by Andreas Herz over 5 years ago
https://github.com/OISF/suricata/pull/3902
Although we can also go for the suggestion from #1872 what do you prefer?
Updated by Andreas Herz over 5 years ago
- Related to Feature #1872: add --list-decoder-protos or similar added
Updated by Philippe Antoine over 5 years 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`
Updated by Victor Julien over 5 years ago
- Assignee changed from OISF Dev to Andreas Herz
Andreas I think I like #1872 better for solving this indeed.
Updated by Andreas Herz over 5 years 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.
Updated by Victor Julien about 5 years 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.
Updated by Andreas Herz about 5 years 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.
Updated by Victor Julien about 5 years ago
- Target version changed from 5.0rc1 to 5.0.0
Updated by Victor Julien almost 5 years ago
- Target version changed from 5.0.0 to 6.0.0beta1
Updated by Victor Julien almost 5 years 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.
Updated by Victor Julien over 4 years ago
- Target version changed from 6.0.0beta1 to 7.0.0-beta1
Updated by Victor Julien over 3 years ago
- Status changed from Assigned to In Review
Updated by Andreas Herz about 2 years ago
- Status changed from In Review to In Progress
Updated by Andreas Herz about 2 years ago
- Status changed from In Progress to In Review
Updated by Andreas Herz about 2 years ago
- Status changed from In Review to In Progress
Updated by Victor Julien almost 2 years ago
- Status changed from In Progress to Assigned
- Assignee changed from Andreas Herz to OISF Dev
- Target version changed from 7.0.0-beta1 to 7.0.0-rc1
Updated by Victor Julien almost 2 years ago
- Target version changed from 7.0.0-rc1 to 8.0.0-beta1
Updated by Philippe Antoine about 1 year ago
- Subject changed from Some keywords missing in list-keyword command to Some keywords missing in list-keyword command (like 'tcp-pkt')