Re: Question about content

[Alex Kirk <akirk () sourcefire com>]

I'm the person who manages the spyware rules here on the VRT, so let me step
in here to respond to this particular issue.

I remember getting that particular message, and I thought I had responded to
it. Looking at my sent-mail folder, it looks like I replied to you directly
and cc'd snort-sigs the next day, saying "That sounds reasonable, we'll make
that change in an upcoming SEU." While my reply seems to have not made the
archives - I've had some issues with the list and aliases on my address here
- I also checked our internal CVS repository for rules, and sure enough, I
made the exact update you suggested the very next day. Since it's been over
30 days since the release of an SEU containing that update, anyone who goes
and downloads the current ruleset - registered or subscriber - can go verify
that if they like.

Much like Matt Olney said, if there are problems with our rules, we want to
know about them. In fact, an explicit part of my job description these days
is to go out and solicit information from our users - be they open-source or
corporate - about how our rules are working for them, and what we can do to
improve things. So if you're reading this, and you've got issues with our
rules - either false positives, false negatives, or simply things we don't
cover that you think we should - please let me or someone else on the VRT
know, so that we can do something about it.

On Tue, Dec 1, 2009 at 11:47 AM, evilghost () packetmail net <
evilghost () packetmail net> wrote:

> I have issues with someone shooting from the hip making accusations of
> "It's a homework assignment".  SF must have some type of dousing rod and
> divining pendulum that they use to determine the motive behind a
> question.  It looked like a valid non-homework question and the OP got
> jumped by three SF heroes.
>
> I did not use http_method because the author did not indicate their
> version.  I'm not really sure if I prefer the content-only match coupled
> with a depth statement or http_method.
>
> Matt, since you offered, here's one I pointed out:
>
>
> http://sourceforge.net/mailarchive/message.php?msg_name=4ACBA83C.7090505%40packetmail.net
>
> If SF is going to publicly insult participants on this list, either
> subtly or directly, my comments will be public as well.  The trading of
> insults privately does sound like fun though, feel free to mail me
> directly.
>
> -evilghost
>
>
> Matt Olney wrote:
> > Mr. Ghost,
> >
> > This list has a long standing policy of not doing homework for people.
> >  This maintains the integrity of the educational process and cuts down
> > on unnecessary questions on the list.
> >
> > But, since you put together a rule, some commentary:
> >
> > Actually the rule performance of this would be pretty good.  4
> > sequential As is a fairly unique content match in HTML traffic.
> > Because this is the longest content match in your rule, it will be
> > placed into the fast pattern matcher.  However, that being said, if
> > you're going to require this be a GET request, I'd consider using the
> > following construct:
> >
> > content:"GET"; http_method; nocase;
> >
> > This constrains the GET to the http_method buffer, created by the
> > http_inspect preprocessor.  However, http_inspect does not normalize
> > this buffer, and the match is case sensitive, so you need to ensure
> > that it is nocased.  Note this is also true for uricontent, so when
> > protecting servers with case insensitive matching or when writing
> > rules for servers of unknown type, always use the uricontent in
> > combination with the nocase modifier.
> >
> > Other than that, that is a sold rule.  I particularly like the check
> > for the AAAA even though the pcre includes it.  In a rule where a
> > different pattern was in the fast pattern matcher, this might
> > potentially save an unnecessary call to the PCRE engine.
> >
> > Now, both you and Guise have demonstrated that you have a problem with
> > Sourcefire.  I'm fine with that, and I'm fine with trading monkey
> > insults with you privately.  However, I'd ask that you try and keep a
> > somewhat genial approach to this list.
> >
> > Finally, if there are VRT rules you have an issue with you have two
> choices:
> > 1)  You can bitch here about unnamed rules that make you laugh.
> > 2)  Or you can name a SID here, and call us out and point to details.
> >
> > I'm more than willing to defend the VRT ruleset.  A lot of very smart
> > people with some very good data have put it together.  We understand
> > how the internals of the Snort engine work, we have a great deal of in
> > house expertise and external intelligence feeds, we work to balance
> > performance and detection quality.  After that we test our ruleset.
> > If there is a problem, I want to know about it.
> >
> > As a matter of fact, I'll make you a deal, you name a SID, detail your
> > issues and if I wrote it and there is something wrong I'll own up to
> > it.  If I didn't write it, I'll fix it and explain the changes so the
> > list as a whole learns something.  I'm proud of my work here, I'm
> > humbled to be able to work with the quality folks both in the VRT and
> > in Sourcefire as a whole.
> >
> > Matthew Olney
> > Research Engineer
> > Sourcefire VRT
> >
> > On Tue, Dec 1, 2009 at 9:47 AM, evilghost () packetmail net
> > <evilghost () packetmail net> wrote:
> >
> > > ...1245643577AAAA
> > >
> > > > > how can I verify that it contains "AAAA"
> > > Making assumptions about direction, protocol, and content I would try
> something like this:
> > > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"AAAA
> detected"; flow:established,to_server; content:"GET "; depth:4;
> content:"AAAA"; pcre:"/\d+AAAA$/"; classtype:suspicious-activity;
> sid:20091201; rev:1;)
> > > As it stands the signature is costly but you would need to supply
> additional criteria for us to narrow it down.  For example, are you looking
> in the uribuffer or http_headers?  Content body?  What layer 7 protocol?
>  Any other identifying factors that could add to the precision?
> > > Note - SourceFire shouldn't be allowed to interface with the public,
> especially if the responses are accusatory in nature.  Some of the quality
> in VRT signatures I've seen make me laugh when they respond like they do
> here.  It's always funny to watch the baboons throwing rocks from their
> glass houses.
> > > Matt Olney wrote:
> > >
> > > > Yep...but I'm feeling uber generous this morning, so I'll give you a
> tip:
> > > > PCRE$
> > > >
> > > > On Tue, Dec 1, 2009 at 8:33 AM, Nigel Houghton <
> nhoughton () sourcefire com> wrote:
> > > > > On Tue, Dec 1, 2009 at 4:11 AM, sofia insat <sofia.insat () yahoo fr>
> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I want to detect the last word in the content
> > > > > > for exemple if I have this bytes: ....1245643577AAAA
> > > > > > how can I verify that it contains "AAAA" at the end without knowing
> the total size of bytes
> > > > > >
> ------------------------------------------------------------------------------
> > > > > > Join us December 9, 2009 for the Red Hat Virtual Experience,
> > > > > > a free event focused on virtualization and cloud computing.
> > > > > > Attend in-depth sessions from your desk. Your couch. Anywhere.
> > > > > > http://p.sf.net/sfu/redhat-sfdev2dev
> > > > > > _______________________________________________
> > > > > > Snort-sigs mailing list
> > > > > > Snort-sigs () lists sourceforge net
> > > > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > > > > Again, this looks like a homework assignment. This list is not the
> > > > > place for homework questions.
> > > > >
> > > > > The answers you seek can be found in the Snort manual and the
> > > > > associated README files in the Snort tarball. You need to do some work
> > > > > and read the documentation.
> > > > >
> > > > > --
> > > > > Nigel Houghton
> > > > > Head Mentalist
> > > > > SF VRT
> > > > > http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/
> ------------------------------------------------------------------------------
> > > > > Join us December 9, 2009 for the Red Hat Virtual Experience,
> > > > > a free event focused on virtualization and cloud computing.
> > > > > Attend in-depth sessions from your desk. Your couch. Anywhere.
> > > > > http://p.sf.net/sfu/redhat-sfdev2dev
> > > > > _______________________________________________
> > > > > Snort-sigs mailing list
> > > > > Snort-sigs () lists sourceforge net
> > > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> ------------------------------------------------------------------------------
> > > > Join us December 9, 2009 for the Red Hat Virtual Experience,
> > > > a free event focused on virtualization and cloud computing.
> > > > Attend in-depth sessions from your desk. Your couch. Anywhere.
> > > > http://p.sf.net/sfu/redhat-sfdev2dev
> > > > _______________________________________________
> > > > Snort-sigs mailing list
> > > > Snort-sigs () lists sourceforge net
> > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> ------------------------------------------------------------------------------
> > > Join us December 9, 2009 for the Red Hat Virtual Experience,
> > > a free event focused on virtualization and cloud computing.
> > > Attend in-depth sessions from your desk. Your couch. Anywhere.
> > > http://p.sf.net/sfu/redhat-sfdev2dev
> > > _______________________________________________
> > > Snort-sigs mailing list
> > > Snort-sigs () lists sourceforge net
> > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk () sourcefire com

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs