Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
Committed Revision #238
Original comment by Cummin...@gmail.com
on 6 Feb 2012 at 5:04
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
Original issue reported on code.google.com by
eoin.mil...@gmail.com
on 16 Jun 2011 at 3:00