chrisdevette / pulledpork

Automatically exported from code.google.com/p/pulledpork
GNU General Public License v2.0
0 stars 0 forks source link

Warn on duplicate sid #95

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Will add to warn output for stdout and syslog, possibly changelog

Original comment by Cummin...@gmail.com on 26 Jan 2012 at 7:04

GoogleCodeExporter commented 9 years ago

Original comment by shirk...@gmail.com on 22 Mar 2013 at 3:46