RE: IPS comparison

From: Ron Gula (rgula_at_tenablesecurity.com)
Date: 08/31/05

  • Next message: Joseph Hamm: "NADS ( was RE: IPS comparison)"
    Date: Tue, 30 Aug 2005 20:59:31 -0400
    To: "Focus-Ids Mailing List" <focus-ids@securityfocus.com>
    
    

    OK, here goes a real long post from Ron. Sorry if this gets off topic
    but I hope folks find it informative. For anyone just scanning these
    emails, let me summarize by saying: "anomaly detection" != "zero day
    detection".

    At 05:15 PM 8/30/2005, Joseph Hamm wrote:
    > >- I agree that "anomaly detection" != "zero day" detection. Just
    >because
    > > my DNS server starts to connect to all the other hosts on my
    >network,
    > > doesn't mean it has got a worm on it.
    >
    >It might if your DNS server doesn't normally do this.

    It might, but it might not. All that the anomaly says is that something
    has changed. Don't get me wrong, that is useful, but it's not a zero
    day exploit. It could be:

    - a 1000 day old exploit
    - someone upgrading the DNS server to also be a WINS server
    - some script that got executed which failed over a DNS server to some
       sort of Tivilo software distribution server
    - some sort of switch/hub/network issue which causes UDP broadcast
       addresses to leak out and 'spike' traffic
    - maybe someone decides to bulk update some zone records in the DNS
       server with HTTP, SCP or possibly TFTP. Since it doesn't normally
       do this, this is flagged as an anomaly.
    - maybe one day, the 'new guy' telnets into the box from his house
       and ends up running ntop on the DNS pinning the session open for a
       long time and this gets flagged because it's not normal
    - maybe one day, the hard drive crashes, and all the network starts
       doing DNS requests to the backup DNS server which looks like some
       sort of DNS worm since you have a large flash crowd going to the
       same place at the same time.

    Don't get me wrong, I'm a big fan of Lancope's Stealthwatch product
    and anomaly detection. We built an anomaly engine into our Thunder log
    analysis tool for network traffic, netflow, firewall logs, host logs, .etc,
    but anomaly detection is just that -- anomalies. It's not the end-all
    solution to finding zero days.

    >Consider a
    >network anomaly detection system that profiled your network and created
    >unique usage/behavioral profiles for each host (including Ron's DNS
    >server). You've told the box how your internal address space is defined
    >so now the box also knows your network's "dark" or unused address space.
    >
    >(Defined internal address space) - (active hosts seen) = Unused or
    >"Dark" IP space

    Tenable has got a lot of experience in this space with both active and
    passive solutions. Well managed networks are extremely well behaved and
    any anomaly is an interesting thing. Unmanaged networks are chaotic,
    random and unpredictable. You get legitimate dark IP addresses lighting
    up all the time.

    My point here is scale. Unless your NBAD is hooked into your network's
    change control process, you won't really know when a new host, network
    trace or an entirely new route is a legitimate thing or not. It simply
    wasn't there the day before and is now.

    >Now consider that your DNS server gets infected with a new worm and
    >starts scanning nearby hosts. A smart NADS (network anomaly detection
    >system) will be able to quickly determine that this host is scanning
    >your dark address space (honeynet concept). Any activity being directed
    >at this unused space can be assumed to be suspect.

    This is useful, but a lot of this functionality is already in a NIDS.
    They may not profile my network, but they can tell me if my DNS server
    is launching port scans.

    I agree that honeypots are a useful detection concept. I'd be curious to
    look at how much fidelity these NDABs (I don't like that acronym any more
    than NADS) have at seeing if a host is truly alive, especially in this day
    of DHCP and host-based firewalls.

    I have a lot of "by definition" honeypot horror stories though. For example,
    consider Windows DHCP laptops that hop from wireless NIC, to VPN, to ethernet,
    .etc. Lots of these guys will make various UDP protocol probes for whatever
    private RFC1918 address they were last on, or misconfigured for. I've also
    seen more than one "NDAB" system get really confused if a system was alive
    or not because a firewall was silently dropping the TCP connection attempts.

    >Also, consider the port being used. If this is not a port that the DNS
    >server normally uses, then that would be suspect as well.

    I normally don't need to download to patch my DNS server, but right
    around the time a worm for DNS is going to come around, I'll have to fire
    up my infrequently used VNC, SSH, terminal services, Telnet or rlogin. I
    might even have to grab a patch with a web fetch on port 80, port 443, or
    even go through the new corporate web proxy on some other god-forsaken-port.
    I may even have a system admin who's arguably lazy or efficient and batch
    process this with a TFTP fetch.

    The classic example I see a lot of NBAD, IDS and SIM vendors (I've seen
    more than one Tenable SE guilty of this too) is to demonstrate to
    potential customers when a perfectly 'normal' host gets an 'anomaly' of a
    web fetch to the network or an IRC session or some TFTP requests. This is
    cool, but something easily blocked by a firewall or router policy.

    >Not to
    >mention all of the tcp resets or icmp port unreachables (in the case of
    >UDP) that the DNS server will receive as it scans across your network.

    Agreed, but I most likely already have port scanning detection algorithms
    in my firewalls and NIDS.

    >Check out the whitepapers published by NADS vendors that outline cases
    >where new "zero-day" worms were detected before signatures became
    >available. I agree that marketing departments squeeze all they can out
    >of zero-day, but I can at least vouch that our SteatlhWatch products
    >detected Zotob (and its variants) without the need for any signature
    >updates. This means customers had early detection before signatures
    >were available. I'm sure there are some other vendors out there that
    >can report the same.

    Many NIDS, SIMs, .etc (even Tenable's NeVO) caught various hits and
    indications of Zotob. What they didn't do is say, "this trace right
    here is the one that is taking your network down right now and will
    cause you loss of sleep for the next three days".

    With all the network phone-home spyware, custom trojans, custom worms,
    constant new forms of P2P chat/share, .etc, on 'unmanaged' networks,
    I see so many 'annomalies' each day, it's like running a signature
    NIDS. On a well managed, firewalled, change-controlled server farm,
    it's a different story.

    >Even signature based solutions can tout this if
    >they write sigs for the vulnerability as opposed to the exploit.

    Sure. Anyone can tout just about anything in this industry. However,
    some things remain to be seen in this industry.

    I've yet to see any NBAD vendor call CERT, a product vendor or whoever
    and say "Gee, our anomaly engine caught a zero-day worm exploiting
    application XYZ. We think you should do a patch and release an advisory".
    And it wouldn't even need to be the vendor. Why aren't any of the
    customers running these NBAD sensors seeing zero-day exploits and
    posting to the SANS GIAC watch, this IDS list, or even vuln-dev? I
    think that NBADs are seeing anomalies just fine, but it's hard to
    discriminate an "ignorable" anomaly from a real threat.

    Ron Gula, CTO
    Tenable Network Security

    ------------------------------------------------------------------------
    Test Your IDS

    Is your IDS deployed correctly?
    Find out quickly and easily by testing it
    with real-world attacks from CORE IMPACT.
    Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
    to learn more.
    ------------------------------------------------------------------------


  • Next message: Joseph Hamm: "NADS ( was RE: IPS comparison)"

    Relevant Pages

    • RE: IPS comparison
      ... >- maybe one day, the hard drive crashes, and all the network starts ... > doing DNS requests to the backup DNS server which looks like some ... >traffic, netflow, firewall logs, host logs, .etc, but anomaly detection ... That's why having a NADS to prioritize these anomalies could save you ...
      (Focus-IDS)
    • RE: Neural Net based Host/Application Anomaly detection systems
      ... Interesting enough however, anomaly detection is ... >> behavior on their given network. ... >> base data set is one way to solve the problem. ... >> anomalies on one network would be completely ...
      (Focus-IDS)
    • Re: Neural Net based Host/Application Anomaly detection systems
      ... > base data set is one way to solve the problem. ... > course, is the more granular the anomaly detection becomes, the less generic ... > anomalies on one network would be completely different that another). ...
      (Focus-IDS)
    • RE: DC Issues
      ... DCs are imputable to DNS server problems. ... For your replication, you should be aware that you will be needing two ... maintain the DCs connected in this network updated. ... Server is not responding or is not considered suitable. ...
      (microsoft.public.windows.server.active_directory)
    • Re: How is DNS resolution working?
      ... >> and our DNS server on machine B is only on a private network, ... host on the external network ... It just happens that on the external network, there is a Windows domain ...
      (microsoft.public.win2000.networking)