OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Andreas.Haugsi-bw.de
Date: Mon Apr 30 2001 - 08:42:00 CDT

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

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

    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