[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ids
Subject:    Re: IDS: Distinguishing/unique features
From:       Jeff Nathan <jeff () wwti ! com>
Date:       2001-04-30 17:15:31
[Download RAW message or body]

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


Andreas.Haug@si-bw.de wrote:
<snip>
> 
> I think this specific example wouldn't be a problem. Most (if not all)
> interaction between "internal" systems use a very limited command set. Once
> tuned, the IDS should not false alarm (I'm still waiting for my sensors to
> proove this assertion in a 'big' network). I'm pretty sure a stock 8.9.12
> sendmail will not "vrfy" anything. It will just "ehlo", "mail", "rcpt"*x,
> "data", "quit".
 
Come on, give me a break it's 4:15am

> I will probably want to tell my ids to flag any use of vrfy, expn, help and
> any command causing an error on the smtp server side.
> 
> >If the IDS can't be
> >flexible enough to account for multiple application implementations and
> >allow for such variances and even adapt, then it's limited.
> 
> And that's the main point: The IDS has to be tuned to allow some "special"
> machines to do "special" things. Example: During our IDS tests, I found
> some people using a tool which allows FTP transfers from server a to server
> b. Now I have to tune the IDS to ignore this, but flag everyone else doing
> the same.
> 
> >haha, indeed.  On my checklist I made sure to clue people in to this.
> >An exposed signature base is definitely helpful in debugging.  So is
> >actually storing offensive packets in their entirety for future
> >examination.
> 
> Ask a leading vendor about the definition of "LogWithRaw". Ask how one
> should decode the "raw" part (if it isn't ASCII).
> 
> Then ask same vendor for a feature
> "LogWithRawIncludingWholePacketHeaderToFile".

More like, please log to tcpdump style binary logs and save us the
overhead of exploding the data 3 or 4 times from binary to ascii before
it's stored on the disk. 


> >What is ambiguous data, then?  Depending on the network topology between
> >me and and end point I have no idea about how many different layer 2
> >technologies might be implemented, so say I loose a fragment or my UDP
> >packets get fragmented and refragmented.  You'd argue that an IDS should
> >alert on all overlapping fragments even though RFC 791 is quite clear on
> >this behavior?
> 
> No.
> 
> An IDS must not alert on overlapping fragments except for the case in which
> overlapping fragments might cause two hosts to reassemble the fragments to
> different datagrams and/or one of the potential reassembled streams matches
> a signature in a higher layer.
> 
> The first part is pretty easy. The second part doubles/multiplies the
> workload though there is nothing magic within.

But that's my point in its entirety and a large point made within Ptacek
and Newsham's paper.  IDS systems are passive and simply fail open.  If
the IDS can't accurately determine of a packet was accepted by an end
system and exactly how the end system accepted it, it can't be entirely
accurate.

> >In order to provide accurate
> >coverage and in order to qualify attacks, unless you defragment at the
> >border, if fragments can make it to and end host you must defragment in
> >the same manner as the end host.  ESPECIALLY in the case of the behavior
> >of the NT IP stack having changed so many times, your IDS generally
> >picks a method for defragmentation (as specified in the RFC most likely)
> >and just runs with it.  But this is not a way to make NIDS systems more
> >accurate.
> 
> Using a scanner to find out the host type to choose the "right"
> defragmentation mechanisms is even more flawed as a failover firewall
> "syncing" a state table between primary and standby every 500ms.
> 
> What if the IDS thinks I'm using W2k but Service Pack 1103 decides to
> change the defragmentation routine to "unix like"?

I'm not sure how this even matters?  Static devices (such as firewalls
like this) would have entries that are equally as static.  I'm also not
arguing for the use of NIDS sensors across an entire enterprise, and in
in the case of protecting the most critical systems on your network,
hell you can point and click the type of system the end host is through
an interface for all I care, but it DOES matter.  And, in most
enterprises do you have the spare cycles to look at who is knocking on
the door or do you utilize your resources as intelligently as possible
and deploy NIDS behind your firewalls.  Personally, the larger the
enterprise the more targeted the approach should be otherwise the signal
to noise ratio becomes unmanageable without a highly tuned rule set. 
And, even in the case of a highly tuned rule set it still requires full
time staff to monitor the output if you attempt to deploy enterprise
wide.  In any case, the fact that the defragmentation method changed at
ALL should generate some sort of event as using NIDS systems to protect
DHCP net blocks is futile for the most part.  I hate to beat this point
into the ground, but I didn't even make the point to begin with, I just
happen to think Ptacek and Newsham were right and this is still a
problem, we've just made it more and more complex over time.  This is
essentially desynchronization, no?  

> 
> >NIDS systems should be able to defragment and perform stream
> >reassembly at a minimum (ahem vendors).
> 
> Replace "should" with "must". If I start writing an IDS, it might be ok for
> me to not do defragmentation. But there is no excuse for an commercial
> sensor costing some US$10.000 to not de-anything. Period.
> 
> >  In a perfect world, they must
> >do this in the same manner as the target host or it's an
> >insertion/evasion attack waiting to happen if the attacker can make an
> >educated guess or worse yet actually determine which product you're
> >using and then abuse the defragmentation scheme/reassembly scheme
> >employed within the IDS (or even DoS it if they've done a bit of
> >research).
> 
> See above. The IDS must flag the evasion scheme (which is easy, isn't it?)
> and it might/may/should (depends on your faith in your vendor) flag any
> matching signature in any of the possible reassembled streams/datagrams.
> 
> Didn't someone say that Dragon or SNP would defragment/desegment _every_
> possible interpretation and match within each one?

I'd like to verify any such claims before I buy in on them. 
Implementing a detection engine that can choose a defragmentation/stream
reassembly scheme for a given target host is one thing, but the
additional CPU/memory cost on the detection engine for having to do this
for each and every possible fragment is ludicrous.  Plus, does this mean
I get a multiple of the number of permutations IP defragmentation
schemes as the total number of alerts I see for an attack that could
match a signature?  That's even more insane.

> 
> Wouldn't this whole "IDS Checklist" be an great topic for an BOF at the
> upcoming SANS2001?
> 
> andreas

If only I were going, I'd emphatically say yes, but alas I'm not
planning on going at this point.

> 
> P.S.: If someone is going to SANS2001, please drop me a line off-list.

-Jeff

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

[prev in list] [next in list] [prev in thread] [next in thread]