shift / pulledpork

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

flowbits being automatically enabled #82

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. add a sid to disablesid that contains a flowbit being set
2. run pulled pork
3. rule is still enabled in pulledpork's snort.rules output

What is the expected output? What do you see instead?
Signatures with flowbits should be managed like any other kind of rules.

What version of the product are you using? On what operating system?
0.6.1

Please provide any additional information below.
I understand that this is functionality built in to pulledpork, however there 
are several sigs that may set the same flowbit for other sigs that check that 
flowbit. 

I would reccomend that this functionality be removed so that the rules are not 
enabled. Perhaps adding code to check for flowbits that are checked but never 
set by another rule and just just alerting on that and disabling those rules 
that never have their flowbits checked. The alerting should be enough to leave 
the control of the enabled/disabled sigs up to the IDS admin with the tool.

Original issue reported on code.google.com by eoin.mil...@gmail.com on 16 Jun 2011 at 3:00

GoogleCodeExporter commented 9 years ago
Eoin,

I will be leaving this functionality in here, I will, however review and see if 
there is a way that it could be better handled.  The problem with disabling is 
that then many rules would be silently disabled.  The other problem is that 
often there are multiple ways for a flowbit to be set, and of course there is 
no logical way to determine what is correct in terms of what needs to be looked 
for.  I'll put some additional thought into this though..

In the meantime, I would suggest that you can do the following:  Set modifysid 
to run before disablesid.. modify the flowbit:set sid that you want to disable 
(to remove the flowbit set for example) and then disable that sid.. make sense?

Original comment by Cummin...@gmail.com on 16 Jun 2011 at 3:11

GoogleCodeExporter commented 9 years ago
JJ, the steps you outlined doesn't seem to work. Hopefully I am just missing 
something with escaping and PCRE?

pulledpork.conf
---snip---
enablesid=/nids/pulledpork/etc/enablesid.conf
dropsid=/nids/pulledpork/etc/dropsid.conf
modifysid=/nids/pulledpork/etc/modifysid.conf
disablesid=/nids/pulledpork/etc/disablesid.conf
---snip---

modifysid.conf
---snip---
2007670 "flowbits" "disable"
---snip---

disabledsid.conf
---snip---
1:2007670
---snip---

rerun pulledpork.pl. This still shows up in snort.rules unmodified and still 
enabled:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET POLICY Likely 
Binary in HTTP by Type Flowbit"; flow:established,from_server; 
flowbits:isnotset,ET.http.binary; content:"HTTP/1"; depth:6; 
content:"Content-Type|3a| application/"; nocase; http_header; flowbits:noalert; 
flowbits:set,ET.http.binary; classtype:not-suspicious; 
reference:url,doc.emergingthreats.net/2007670; 
reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/POLICY/POLICY_Smal
l_Binary_Downloads; sid:2007670; rev:6;)

I've tried several different types of content matching within modifysid.conf, 
but this most generic one should really handle it. Is there something you have 
to do with state_order?

state_order=disable,drop,enable

There isn't a valid option for modify in there. Are you supposed to make 
modifysid run before disable sid by rewriting the script to call the 
subroutines in a different order? 

Original comment by eoin.mil...@gmail.com on 16 Jun 2011 at 5:50

GoogleCodeExporter commented 9 years ago
I'll have a look, sounds like I lept before I looked haha

Original comment by Cummin...@gmail.com on 16 Jun 2011 at 5:55

GoogleCodeExporter commented 9 years ago
Could we just be notified with a warning when signatures are enabled which 
depend on flowbits that have not been set anywhere?  As opposed to 
automatically enabling signatures...

Original comment by Rob.Vin...@gmail.com on 28 Jul 2011 at 4:09

GoogleCodeExporter commented 9 years ago
This already exists, if it's re enabled a warn will be thrown

Original comment by Cummin...@gmail.com on 28 Jul 2011 at 4:32

GoogleCodeExporter commented 9 years ago
Has there been an update to this issue? modifysid workaround yet?

Thanks

Original comment by joshbro...@gmail.com on 1 Feb 2012 at 11:56

GoogleCodeExporter commented 9 years ago
I will be setting modifysid to act before all other sid operations.. thus you 
can modify and (remove) flobits sets in rules that you do not want pulledpork 
to re-enable.  It should be noted however, that this is a slippery slope (YMMV 
etc...) and that doing so will likely negatively impact your detection 
capabilities.

Original comment by Cummin...@gmail.com on 6 Feb 2012 at 5:00

GoogleCodeExporter commented 9 years ago
Committed Revision #238

Original comment by Cummin...@gmail.com on 6 Feb 2012 at 5:04

GoogleCodeExporter commented 9 years ago
Hi, 

I don't think your commit solves the original issue as the flowbit_set function 
uses the $$href{$k1}{$k2}{$flowbit} variable to test if a rule must be 
re-enabled. And, this variable seems to be set in the read_rules function, 
which is still called before.

Cheers,

Cyrille

Original comment by cyrille....@gmail.com on 10 Jan 2014 at 10:16