What steps will reproduce the problem?
1. Configure pulled-pork to Download the ET ruleset that includes GPL sigs, and
the VRT ruleset.
2. Run pulledpork.
3. Check for duplicated sids and find none. This is reasonable, pulled-pork
detects that there are duplicate sids in the rulesets, knows that this isn't
allowed by snort, and picks one to take priority.
4. Look for log messages to explain what sids conflicted, and which versions
took priority, there are no such log messages.
What is the expected output? What do you see instead?
Expected to find some messages telling me what the duplicate sids are, and
which version took precedence. Instead there were none, so if I wasn't aware
that the sid was duplicated, and if I wasn't aware of PP's behavior, I'd have a
tough time troubleshooting why the rule-content is different than I expected.
What version of the product are you using? On what operating system?
0.6.1, RHEL6
Please provide any additional information below.
Rules with sids of approximately 103-3460 are duplicated in both the VRT and ET
rulesets. Pulledpork handles this by ensuring duplicate sids never get written
to the final rulefile, and it chooses whichever ruleset was specified last in
the config-file to take precendence. This is sensible behavior, however if you
aren't aware of it you can become confused when the PP output contains
different rule-content from one of the input tarballs.
PP should emit a warning (less severe than an error, but in my opinion should
be more severe than debug output) when a duplicate sid is encountered. It
should note the duplicate sid, the 2 ruleset-sources that contained it, and it
should state which ruleset-source is taking precedence.
This is a low-priority feature-request, not a true bug. It should be
relatively straightforward to implement, though, by checking to see if the
rule-hashtable is populated before writing to it.
Enhanced and mikelococo discussed this on IRC at 16:17 EST on 11/17.
Original issue reported on code.google.com by m...@nyu.edu on 17 Oct 2011 at 9:15
Original issue reported on code.google.com by
m...@nyu.edu
on 17 Oct 2011 at 9:15