Re: Feasibility of one off rule

[Martin Holste <mcholste () gmail com>]

I'll also add that 51.la has a very mixed past as it is not
technically malicious in and of itself, but it is frequently used by
bad guys.  It's actually a very large site run by a (mostly) legit
business that is used for analytics (click tracking), much like
cnzz.com.  Most orgs can block without losing anything of value, but
don't make the mistake of believing anyone going to that site is
infected or is in the process of becoming infected.  As such, a sig
for 51.la will yield a high FP rate.

On Mon, Jun 13, 2011 at 11:53 AM, Alex Kirk <akirk () sourcefire com> wrote:
> In principle, probably not a bad idea. In practice, there's a bit of an
> implementation challenge.
> The issue is performance. You'd need something to stick in the fast pattern
> matcher - thus, a fixed string that shouldn't be too common - to make it
> more than "if I see traffic on these ports, fire", and thus make it not
> slow. I suppose you would't see "GET" very often on off ports, so that might
> work; I'd just wonder if there's a more consistent piece of the HTTP headers
> that's a bit longer than 3 characters that we could expect to be able to use
> in a rule like this.
> I don't suppose you've got more data than just the URL in question, do you?
>
> On Mon, Jun 13, 2011 at 9:25 AM, Lay, James <james.lay () wincofoods com>
> wrote:
> > Hey all!
> >
> > Looking through logs today....have come across:
> >
> > http://web1.51.la:82/go.asp
> >
> > Which according to malwaredomains.com is no good.  I was wondering if it
> > was feasible or a good idea to even create a rule that would fire on one
> > or two offs from the standard port?  I do see that msn.com uses port 81
> > for an item:
> >
> > http://apnxscm.ac3.msn.com:81/CACMSH.ashx?&t=1
> >
> > These are all blocked anyway, but eh...was curious if this could be a
> > worthwhile idea.  Thanks.
> >
> > James
> >
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > http://www.snort.org
>
>
>
> --
> Alex Kirk
> AEGIS Program Lead
> Sourcefire Vulnerability Research Team
> +1-410-423-1937
> alex.kirk () sourcefire com
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org