Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

RE: [Snort-sigs] Suggestions for new attack response rules

Subject: RE: [Snort-sigs] Suggestions for new attack response rules
Date: Tue, 7 Dec 2004 09:48:59 -0500
-----Original Message-----
From: Jason [mailto:security@brvenik.com]
Sent: Tuesday, December 07, 2004 12:11 AM
To: Joe Patterson
Cc: Brian caswell; snort-sigs@lists.sourceforge.net
Subject: Re: [Snort-sigs] Suggestions for new attack response rules
...
I would be interested in hearing what your issues with the current tag
functionality are. I suspect that there is anything wrong that cannot be
remedied easily as it relates to tag functionality. There might be
features that are desired but that is a different question.

I have to plead some ignorance on this.  Long ago I looked at tagging, and
found it woefully inadequate, and IIRC, slated for deprecation.  I ignored
it for quite some time after that, while looking for something better.
While I wasn't looking, tagging got better.

Looking at the *current* implementation of tagging, it is *far* better.  It
does what I would want it to do, it tags a flow.  The thing that I am
somewhat unsure of at this point is how the various front-ends to snort deal
with tagged data.  How does it show up in sguil, acid, base, etc?  I
honestly don't know, I haven't played around with tagging using those
front-ends.  It may be that they handle that data wonderfully, and if so,
great, that's one less reason to add in the flowbits-based rules (although
there is still some reason - because tagging is limited to capturing only a
certain number of bytes or time interval, it doesn't do content matching.
An attacker could, as you pointed out, send a pipelined request for a large
document, and then his exploit code, and tagging would only catch the
document, not any of the response to the exploit.  If you look for content
{such as something that looks like an http response code} you *should* get a
little bit of both.)

So, I don't know how well the front ends handle tagged data, but I *know*
they handle alerts well.  That's why my first attempts were alert-based.
Perhaps tagging is a better way to do it, even if it is a bit less flexible.

-Joe



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>