Re: RE: sequence No.

[Jeff Nathan <jeff () wwti com>]

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-owner () uow 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 majordomo () uow edu au
-----------------------------------------------------------------------------
Dug Song wrote:

>

> -----------------------------------------------------------------------------

> On Thu, May 03, 2001 at 02:38:39AM -0700, Jeff Nathan wrote:

>

> > 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".

>

> if you normalize traffic upstream, you won't ever see "non-normalized"

> traffic downstream... ?



Whatchu talkin' about, Willis?  I meant downstream traffic, I don't know

of any reasonable way to prevent fragmentation between one network and

another based upon layer 2 technologies.

 

> > 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.

>

> sure it is. my coworker Rob Malan presented this paper last year:

>

>         http://www.eecs.umich.edu/~rmalan/publications/mwjhInfocomm2000.ps.gz

>

> eventually, someone with lots of time to kill will implement this in

> IP Filter, and that will be that (transparent scrubbing on the OpenBSD

> bridge would be neat)...



I can't think of a platform I'd rather see it on.  I've got some reading

to do I guess.



>

> > 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...

>

> um, routers and firewalls do the same...  



Yeah, but we've got mechanisms to provide redundancy for those devices,

we'd need the same for the IDS it seems.



>

> > 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).

>

> most of this specialized processing can be half-duplex, if the

> internal network is to be trusted.



I'll give you that one.  There really isn't much benefit to outbound

scrubbing.

 

> > Third, any application layer gateway would have to be properly coupled

> > with the applications it's being used with.

>

> this is already true of application proxy firewalls. easy enough to

> just implement the lowest common denominator...



Ewwww..

 

> > Neither approach is particularly easy in the end.  I'm just more up for

> > the challenge of doing it within an IDS.

>

> easier, more reliable, and safer to do this in an active gateway (or

> firewall) which enforces proper (well, consistent) semantics than to

> have a passive network IDS try to guess at what's really going on...



Both you and Marty have now pointed out the advantages of a gateway

device doing this work over a firewall.  IDS development seems to really
be pushing the envelope that was originally pushed by firewall
development.  While there are still a lot of hurtles to jump over in the
land of hardware, I'm interested in seeing how this plays out.

-Jeff


>

> -d.

>

> ---

> http://www.monkey.org/~dugsong/





-- 

http://jeff.wwti.com            (pgp key available)

"Common sense is the collection of prejudices acquired by age eighteen."

- Albert Einstein