|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Andreas.Haug
si-bw.deDate: Mon Apr 30 2001 - 08:42:00 CDT
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
-----------------------------------------------------------------------------
On 30.04.2001 20:40:12 Jeff Nathan wrote
>Come on, give me a break it's 4:15am
No, it's two in the afternoon. But feel free to reply tomorrow.
>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.
I'm not sure if tcpdump logs are the best possible solution. I would like
to have a reference to the event id in the evidence stream (since I might
get two attacks at the same time). Don't know if this is possible with
tcpdump format.
>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.
Even if you know if the packet was accepted by the end node; how can you be
sure that the packet was processed at the application layer as the IDS
thinks it was?
What if (ok, we're talking about big "if"s here) someone took the time to
load the latest patch?
No IDS can be entirely accurate detect what an end node will do with a
packet. Sorry.
But it would be enough for me (in a first step) if the IDS would alert on
ambuguous data potentially leading to an exploit.
>> 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.
Unfortunately, I have to think in terms of "entire enterprise". The
unfortunate truth is that even devices like firewalls aren't static if you
have many of them, managed by some other departement at some other
location. In times of mergers and outsourcing, it is very hard to even get
an idea of what the network looks like today. Inside swaps with outside
quite regularly. If I guess an life cycle of two years per end node, we
have around 350 changed/replaced end nodes per day in our network.
>In any case, the fact that the defragmentation method changed at
>ALL should generate some sort of event as using NIDS systems to protect
The ids can not see if the defragmentation method changed. The scanner
could, though. Don't know how long it will take to scan some 10e5 hosts
(anybody has numbers?)
>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?
I'm sorry but either my english is as bad as I think it is, or I'm still
missing something.
My point is this:
1. Ptacek and Newsham were right at that time.
2. But any decent IDS using protocol decode should be able to detect an
evasion scheme even if it is unable to defeat it.
3. If attack detection is enough, an IDS doesn not need to know anything
about the end node.
>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.
You only have to do it for overlapping fragments containing ambiguous data.
This should not happen very often.
> 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.
It's not more insane than asking the IDS to just show one event for an
portscan to multiple hosts.
andreas
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]