Re: Unknown rule option sip_header

[James Lay <jlay () slave-tothe-box net>]

On 2014-10-01 11:21, Joel Esler (jesler) wrote:
> > On Oct 1, 2014, at 12:35 PM, James Lay <jlay () slave-tothe-box net
> > [4]> wrote:
> >
> > On 2014-10-01 10:26, Jeremy Hoel wrote:
> >
> > > We had this bite us.. we came in the morning and found the sensors
> > >
> > > all
> > > off. We just disabled the rule, since like you, sip doesnt
> > > transverse
> > > our links.
> > > On Oct 1, 2014 10:07 AM, "James Lay" <jlay () slave-tothe-box net
> > > [3] [8]>
> > > wrote:
> > >
> > > > On 2014-10-01 09:40, Y M wrote:
> > > >
> > > > > > To: snort-users () lists sourceforge net [1] [1]
> > > > > > Date: Wed, 1 Oct 2014 08:09:10 -0600
> > > > > > From: jlay () slave-tothe-box net [2] [2]
> > > > > > Subject: [Snort-users] Unknown rule option sip_header
> > > > > >
> > > > > > Oct 1 14:02:31 192.168.1.1 snort[5722]: FATAL ERROR:
> > > > > > /etc/snort/rules/snort.rules(31729) Unknown rule option:
> > > > > sip_header.
> > > > >
> > > > > > alert udp $EXTERNAL_NET any -> $SIP_SERVERS $SIP_PORTS
> > > > > (msg:"OS-OTHER
> > > > > Bash environment variable injection attempt"; flow:stateless;
> > > > > sip_header; content:"() {"; metadata:policy balanced-ips
> > > > > drop,
> > > >
> > > > It is not....SIP will never traverse this specific link, so in
> > > > an
> > > > effort to optimize and remove unneeded functionality I disabled
> > > > it. Are
> > > > we saying that I MUST have this preprocessor running? Thanks
> > > > YM.
> > > >
> > > > James
> >
> > Thanks Jeremy...that's what I had to do in the short term...next
> > step
> > is to add those two rules to these specific disablesids. Long term
> > though, every time a new one of these comes out, this is going to
> > break
> > stuff. Joel, can we get a feature request or something...a command
> > line
> > flag that will allow running with errors. So if a specific rule is
> > borked, snort will just skip that rule and continue on? Thank you.
>
> This is a catch 22.. If you load silently, then people think that a
> rule that was supposed to be turned on, but failed to load for
> whatever reason (for instance the opposite of what you experienced
> today), then we get hollered at for NOT failing. Then when we fail, 
> we
> get hollered at for failing.
>
> But your idea of a command line argument or something is interesting.
> I’ll ask.
>
> --
>  JOEL ESLER
>  Open Source Manager
>  Threat Intelligence Team Lead
>  Talos

Thanks for all the chatter and solutions on this gents...really 
appreciate it.

James

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&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!