Archive: http://msgs.securepoint.com/ids
FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owneruow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
-----------------------------------------------------------------------------
That point is valid, to a degree. And in practice, doing a lot of the
work at the border solves many issues with regards to ambiguities.
However, there are a few separate threads going on in all these messages
so I wanted to touch on a few right here.

First, if we use normalize traffic at the network border and then
configure the IDS to alert on traffic that is non normalized does indeed
resolve some of the "gotchas". However, in the case of a stateful IDS,
it doesn't address any of Ptacek and Newsham's comments. Also, packet
scrubbing (I hate to use that term but I don't have a better one) isn't
exactly feasible at this point in time such that IP and TCP are handled
and packets are then handed off to application layer normalizers.

One could argue it's just six of one and half a dozen of the other. In
the case of an IDS, it's a generally passive device that does not take
out the entire network if it dies. In the case of a packet scrubber, it
becomes a point of network failure if it dies... just something to
consider.
Second, all of this has to work in reverse too, such that all outbound
traffic has to be funneled through this single proxying/packet scrubbing
device (logically single, I don't literally mean one device).

Third, any application layer gateway would have to be properly coupled
with the applications it's being used with. Since vendors aren't always
happy to explain how they've implemented certain application layer
decoders, you might just be forced to use a certain mail server software
package based upon what your proxy/packet scrubber product has done
internally.

Neither approach is particularly easy in the end. I'm just more up for
the challenge of doing it within an IDS.

-Jeff

Bill Royds wrote:
>
> Archive: http://msgs.securepoint.com/ids
> FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
> FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html
> IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
> HELP: Having problems... email questions to ids-owneruow.edu.au
> NOTE: Remove this section from reply msgs otherwise the msg will bounce.
> SPAM: DO NOT send unsolicted mail to this list.
> UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
> -----------------------------------------------------------------------------
> I would think that a proper network architecture would have a border router that (heresy, heresy) de-fragments packets before they enter the local network. Then any IDS would be looking at a canonical format for packets. This might not be the format that a particular host would get if the host did the defragmentation but it would eliminate many of the Ptacek/Newsham gotchas in IDS.
> The situation with canonical forms for HTTP Unicode strings is more problematical. But a good application layer gateway firewall should be doing this when the streams go through. How can a ALG properly handle proxying if it does not form a canonical stream to parse? So an IDS on a network behind a firewall can assume that any packet with Unicode hex or fragmented packets is, by that fact alone, an anomaly that should be alerted on.
>
> -----Original Message-----
> From: owner-idsuow.edu.au [mailto:owner-idsuow.edu.au]On Behalf Of
> mhtclark.net
> Sent: Wednesday, May 02, 2001 14:06
> To: Aaron Bawcom; 'nitin gupta'; idsuow.edu.au
> Subject: Re: IDS: RE: sequence No.
>
> Archive: http://msgs.securepoint.com/ids
> FAQ IDS: http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm
> FAQ NIDS: http://www.ticm.com/kb/faq/idsfaq.html
> IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
> HELP: Having problems... email questions to ids-owneruow.edu.au
> NOTE: Remove this section from reply msgs otherwise the msg will bounce.
> SPAM: DO NOT send unsolicted mail to this list.
> UNSUBSCRIBE: email "unsubscribe ids" to majordomouow.edu.au
> -----------------------------------------------------------------------------
> Most of the currently available IDS products address the issues in this
> paper. A majority of IDS applications still do not handle TCP/IP packet
> obfuscation as well as they should, but that is just a matter of adjusting
> the protocol decodes to detect the various variations (i.e. RFP CGI-PHF bin
> scripts).
>
> /mark

-- 
http://jeff.wwti.com	 	(pgp key available)
"Common sense is the collection of prejudices acquired by age eighteen."
- Albert Einstein

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]