Re: Swen.A results with Snort-inline (protocol anomaly detection)

[pieter claassen <pieter () countersnipe com>]

Hi Jason,

Do you make use of flexresponse/react? I had a look through the code and
it looks like the react code in sp_react.c used libnet to close the
connections (I am not sure if libnet can send tcp with a spoofed src ip?
I am also not sure if you can inject packets via libipq). It seems that
it will only return a message to the browser when the destination port
was 80 or a proxy port, but it does not partake in the protocol (HTTP is
asynchronous so nothing to partake in). So it looks like that sp_react.c
code is a good place to start, but it does not contain any intelligence
to do protocol anomaly detection.

I am intrigued by your statement that network based scanning cannot
replace AV. I assume you are touching on the question as to which
security functions can be handled on the perimeter and which ones can
only be done end-to-end?

My opinion on this is that because of the potential benefits of
centralised management, there is a strong drive for these central
machines to get with the program (so to speak).

Here are good reasons why centralised management is a good idea:
1. Economies of scale. One device services many.
2. Economies of scale (reverse that is). Devices can be more expensive
because there are less of them (we assume here that more expensive
equals better performance)
3. A single place of failure.
4. A single point of responsibility.
5. Operational expertise is situated in a single device. With the
end-to-end approach you need experts in each protocol (application) to
configure them securely. Also, from a security point of few, each
application has to be hardened and many times you need dedicated
products to protect each one of them. You also have to watch each
application individually for a security violation (or use snort to do
them all at once)
6. Risk management in the broader sense. You can now choke all bad
traffic at your border, rather then let it in and then try to contain
the damage (an example is any worm/virus. Even if you have AV on each MS
desktop, there is no way that you can feel confident that they are ALL
up to date on signatures).

However, this means that your border device must be able in effect to
track the state of many protocols that depend on a complex asynchronous
handshake where the detection of bad traffic might only happen some time
into the conversation and where the high level protocols have to be
taken down gracefully. This would require an action table to be
associated with conversation state because there are different actions
to be taken at different stages of the conversation.

A security device can only do one of a few things:
1. Alert|log activity.
2. Terminate a broader more general lower level service (drop IP
connection on bad signature)
3. Terminate the specific service gracefully (Use protocol specific
method of shutdown or reject transactions).
4. Any combination of the above.

Can you think of any other actions that security devices are supposed to
be able to take?

Based on this analysis, the question is not to be all things to all men,
but to see if one can implement these orthogonal actions based on
specific signature matches. It would probably not be a bad idea to make
snort's actions more orthogonal from the matches (most relevant to
things like inline use).

We currently have a device that does action 1 and 2 pretty well and that
certainly has significant benefit to organisations. I conceded that the
current implementation of action 3 is very limited and that is what this
mail is about, to consider making it better.

The questions are:
1. How difficult will it be really (how many protocols should be catered
for and how to cater for them) to implement action 3?
2. Can you think of a reason why this is not a good idea?

Apologies for the verbose email.

Thanks,
Pieter

On Fri, 2003-09-26 at 01:58, Jason Haar wrote:
> On Thu, Sep 25, 2003 at 09:45:57PM +0100, pieter claassen wrote:
> > However, this raised another question. All the snort plugins are focused
> > on detection. In this specific case, it would have been great to have a
> > snort plugin that could partake in the SMTP conversation and bring the
> > line down a little bit more gracefully (eg. remember the message id of
>
> There's already some precedence for that - Snort already has code for doing
> "HTTP Resets" for want of a better word - the "react" function.
>
> However, although I too make good use of some of Snort's antivirus
> functionality (the SMB rules), the real way of dealing with viruses and
> trojans is with an antivirus package - not an IDS. Network scanner-based
> technology will NEVER be able to replace AV systems...
-- 
Pieter Claassen
CounterSnipe Technologies
www.countersnipe.com


Highview House
Charles Square
Bracknell
Berskhire
RG12 1DF
United Kingdom


Tel: +44(0) 1344 390 530
Fax: +44(0) 1344 390 700
Mobile: +44 (0) 776 6656 924
email: pieter () countersnipe com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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://www.geocrawler.com/redir-sf.php3?list=snort-users