Feature Request

[MichaelS]

JJ,

 

I would like to see a couple of items added to PP on the next release.

 

1) A way for PP to process the sig.msg.map file only. I'm using the the 'create-sidmap.pl' from the Oinkmaster releases, and it takes about 2 seconds to process the sig.msg.map file.

 

I'm now using the 'create-sidmap.pl'  to process the sig.msg.map file, and there is no active rules in the local.rules. I would like to add PP to my guides to only process the sig.msg.map file for the initial guide setup, and give the end user the option of adding the automated rule updating later.

 

2) Isn't there a way to have PP process the rules in the original naming convention? This takes care of two problems; not having to make any changes to the snort.conf include statements, and wiping any existing rule sets out in the rules folder. This also seems to be a much cleaner and transparent way to auto process the original rules from snort.org. Plus, all the end user would need to do is configure the PP.conf file and run PP.

 

  Michael...

[JJC]

Inline...

On Sun, Sep 9, 2012 at 8:55 PM, MichaelS <zips...@gmail.com> wrote:

JJ,

 

I would like to see a couple of items added to PP on the next release.

 

1) A way for PP to process the sig.msg.map file only. I'm using the the 'create-sidmap.pl' from the Oinkmaster releases, and it takes about 2 seconds to process the sig.msg.map file.

This could be useful, I'll look into it.

 

 

I'm now using the 'create-sidmap.pl'  to process the sig.msg.map file, and there is no active rules in the local.rules. I would like to add PP to my guides to only process the sig.msg.map file for the initial guide setup, and give the end user the option of adding the automated rule updating later.

 

2) Isn't there a way to have PP process the rules in the original naming convention? This takes care of two problems; not having to make any changes to the snort.conf include statements, and wiping any existing rule sets out in the rules folder. This also seems to be a much cleaner and transparent way to auto process the original rules from snort.org. Plus, all the end user would need to do is configure the PP.conf file and run PP.

You can keep the files but it will always pre-pend to the name for ET and VRT rulesets.  This is by design as there was much confusion and file overwrites occurring when people were trying to use multiple rulesets previously.  As such, and by popular demand, this will not change.

Ideally the only change that should need to take place is removal of all of the includes and addition / changing to only have up to three:

local.rules

snort.rules

so_rules.rules

done...

JJC

 

 

  Michael...

--
You received this message because you are subscribed to the Google Groups "pulledpork users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pulledpork-users/-/QbNjl9oeqfQJ.
To post to this group, send email to pulledpo...@googlegroups.com.
To unsubscribe from this group, send email to pulledpork-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pulledpork-users?hl=en.

[Michael Steele]

What you have done is selected the easy way out, and creating a single snort.rules is the best for experianced users that have dealt with the rules.

 

What about the new user or the user that wants some sort visual organizational structure to the rules. The way you describe would just bulk dump all the rules into one file.

 

I guess you could place seperators in the snort.rules file during the process?

 

---------------------------------------------
Snort Rules - attack-responses.rules
---------------------------------------------

 

---------------------------------------------
Snort Rules - backdoor.rules
---------------------------------------------
alert tcp ...
alert tcp ...

 

---------------------------------------------
Snort SO_Rules - bad-traffic.rules
---------------------------------------------
alert ip ...
alert udp ...

 

 

When PP dumps original Snort individule rulesets; Why not keep the original snort configuration intact, and keep the original ruleset names. Use the original snort folders for the original snort rules processing, and if the end user wants the ET rules or whatever have a new folder designated for that process. This could be done in the PP configuration. It't just makes since to leave the snort.conf, and ruleset names in their original form when your dealing with individual rulesets. I's going to get confusing for new users. If they ever had to update manually, it would be as easy moving the rules from the tarball to the approperate folders, and updating the sig.msg.map file.

 

For my purposes What I'd like to do do in my guides is; place a new ruleset tarball into a designated folder, run PP, and process everything locally. This way everything has to work, even if they have no outside connection, or they are having problems reaching the snort.org site.

 

I'm just looking for something that will cause less confusion.

 

Dumping everything into one folder when PP is creating a single.rules file seems appropriate. 

 

Just a thought...

 

Michael...

[JJC]

That is actually not a bad idea and dooable... can you please open some feature requests for these and I'll make sure that they make it into an upcoming release.. the separators that is...  

# ----- Begin compromise-indicator category 

alert...

# ----- End compromise-indicator category

[Michael Steele]

Whre do I do that at?

[JJC]

pulledpork.googlecode.com enter a ticket for me