google / gonids

gonids is a library to parse IDS rules, with a focus primarily on Suricata rule compatibility. There is a discussion forum available that you can join on Google Groups: https://groups.google.com/forum/#!topic/gonids/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Nested network info parsing unsupported

satta opened this issue · comments

Suricata allows multiple nested levels of network and port grouping, e.g.

[1:80,![2,4]]

which would specify a port range from 1-80, except ports 2 and 4. See https://suricata.readthedocs.io/en/latest/rules/intro.html#ports-source-and-destination for more examples.

I have read the code in parser.go and it looks due to the way the current parser handles these entries (only one level of grouping) this would not be parsable:

some or all destination ports are invalid: [1:80 ![2 4]

There is also a problem with negated groups in general: Parsing

![25,110,143,465,587,2525]

leads to

some or all destination ports are invalid: [![25 110 143 465 587 2525]

since the leading ! is not clipped before checking the validity of the port entries. Port group parsing is currently the biggest problem when trying to parse the entirety of the ETPRO rule set, and while the latter issue is easy to patch for one level of group items, it feels like it should be implemented correctly for all cases.

There are other issues with parsing ETPRO at the moment, such as missing support for noalert without values in some places, transformations (such as dotprefix) and missing protocols (icmpv6, ftp-data, etc.) and more. These seem to be smaller in nature and probably easy to fix.

commented

Thanks for the report Sascha!
I suspect that this regression was added with #153

To be 100% transparent, I'm not going to be able to dig into this myself in the near future, work and normal life are a bit chaotic at the moment. I'm happy to review pull requests though if you want to take a stab at this fix.

If this ends up being too complex we may just be better removing this validation and going back to raw strings for these values.

commented

I think I may have some time to poke at this next weekend. I have a prototype hack that seems to work for the ports, I'll need to replicate the logic for the networks and then perform a bit of extra testing. I'm optimistic that this will be fixed (if ugly) soon.

Nice, thanks! 👍🏻

commented

@satta I seem unable to tag you in a new issue.
I've forked the issue for missing protocols and transformations into issue #156 and I'd like your input if possible.