Re: Help needed to modify drop rules to reject rules with pulledpork modifysid.conf

[Y M <snort () outlook com>]

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

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
<snip>
        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....
<snip>
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?

Thanksalex


------------------------------------------------------------------------------ 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@lists.sourceforge.netGo 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!

------------------------------------------------------------------------------
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 () lists sourceforge net
Go 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 visit http://blog.snort.org to stay current on all the latest Snort news!