[Snort-users] Help needed to modify drop rules to reject rules with pulledpork modifysid.conf

Y M snort at ...15979...
Wed Sep 10 13:30:31 EDT 2014

Subject: Re: [Snort-users] Help needed to modify drop rules to reject rules with pulledpork modifysid.conf
From: alexcklam at ...11827...
Date: Wed, 10 Sep 2014 10:11:57 -0700
CC: snort-users at lists.sourceforge.net
To: snort at ...15979...

More inline...I tried this line in modifysid.conf 
* "^\s*drop" “reject"
but it did not work even when my pulledpork.conf already has this line:-
state_order = enable,drop,modify,disable
# I do not believe that modify is an allowed value for state_order. You probably have already read the comments in pulledpork.conf : "# the valid values are disable, drop, and enable.", and hence the reason it may be not running as you are expecting.
<ALEX>  I am not sure if “modify” is an allowed value for state_order here. Interestingly, I see modifysid.conf getting processed just before disablesid.conf in my pulledpork log.
## That's because PulledPork processes modifysid before anything else, see below (Bug #82 ...).
# In the changes document, there is this: "Bug #82 - Modified run order to force modifysid to run before all other sid state modification routines".  So,  in your modifysid.conf you are changing from "drop" to "reject", however,  since modifysid is run first, then there will be no changes since the the rules tarball does not ship with "drop" state. In other words, PulledPork does not find anything to change.

<ALEX> Yes, that’s possible. It seems like modify is done twice - once before enablesid.conf, once after dropsid.conf. I suspect rules that get are enabled from dropsid.conf failed to match the “\s*drop” regex.
## I do not see this in my logs. Probably it is because you have explicitly added the "modify" to the state_order. That said, logically speaking, PulledPork processes the rule from the original rules tarball. If the state_order change you have made causes PulledPork to run "modify" again after "disabled", it would still not find anything to change since the rules ship with the "alert" action.

<ALEX> Yes, that's goes back to my original query -- when PulledPork process those XXXXsid.conf files, does it base on rule state in tarball? Or the running rule state based on the output from the processed XXXXsid.conf file.The fact that README file mentioned "precedence", I assume it's baed on the latter.
### Correct. However, PulledPork starts with rules having the rule action of "alert", that's why the initial "modify" does not actually change anything, since you are specifying to change the action from "drop" which does not exist.

Here are extracts from my pulledpork run log:
Modifying Sids....	Modifying ALL SIDS from:^\s*drop to:reject	Done!Processing /root/pulledpork-0.7.0/etc/enablesid.conf....	Enabled 1:2005283	Enabled 1:2010514
	Will drop 124:8	Will drop 131:3	Modified 12783 rules	DoneProcessing /root/pulledpork-0.7.0/etc/modifysid.conf....	Modified 0 rules	DoneProcessing /root/pulledpork-0.7.0/etc/disablesid.conf....
Any ideas how I can turn dropsid.conf-enabled rules from “drop” to “reject”??
# An idea would be to create a backup of your disablesid.conf, and then start with a fresh/empty disablesid.conf, then in your modifysid.conf just modify "alert" to "reject".
<ALEX> Sorry. I lost your logic here. Why would a fresh disablesid.conf help?
## From what I understood from your original post, you want to change the action from "drop" to "reject", correct? If so, and since PulledPork is not finding any rules with "drop" action from the original tarball, simply add the modifications into modifysid.conf. If you keep sids in dropsid.conf, then the respective rules will change to drop, since "drop" happens after the "modify" stage. I hope this makes since :) 
<ALEX> Ideally, pulledport supports "rejectsid.conf" and I will move all my "dropsid.conf" rules to it. However, it does not. So I am faking it by selecting my rules in "dropsid.conf" followed by "modifysid.conf" to convert them to "reject".
### Why not change the rule action from "alert" to "reject" immediately at the first "modify", instead of changing "alert" to "drop" to "reject", saving you an additional layer of processing?


------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable.http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________ Snort-users mailing list Snort-users at ...7448... to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visithttp://blog.snort.org to stay current on all the latest Snort news!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20140910/26069e61/attachment.html>

More information about the Snort-users mailing list