Re: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)

From: Mike Frantzen (frantzen_at_nfr.com)
Date: 08/31/04

  • Next message: Bob Walder: "RE: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)" 
    Date: Mon, 30 Aug 2004 23:43:12 -0400
To: dank@reflexsecurity.com

    > Hehhehe, while my job at Reflex is leading our IPS development, my
    > research at the GTISC is a bit more pure -- I hope my somewhat
    > theoretically-minded answer earlier didn't paint me an ivory
    > towerist :D

    Nah. I think my eyes just glazed over after the first few greek
    letters ;-)

    > > The real benefit of a full fledged TCP state machine is knowing when to
    > > expire an idle connection. If we expire a connection too early, then
    > > the next packet that comes in on it will appear to be a new connection
    > > and several things may happen:
    > You list several problems with timing out sessions too early, but none
    > with timing them out too late. For the sake of argument, what problems
    > do you see with simply idling out via necessities of LRU applied to a
    > fixed-size flow cache (obviously, sessions could still be closed based
    > on 4-way TCP teardown, RST abortion or SYN/OOW xmit, modulo the guesswork
    > typically involved in such)? A much less intensive state machine can be
    > developed in this case, if one's merely concerned with the problems
    > you've raised (I noted several other benefits from a detection
    > standpoint in my earlier answer).

    Fixed-sized state tables are absolutely awful when done in software.
    They're trivial to DoS if you can predict the re-hash path or if they
    degenerate to a linked list off a hack bucket. My classic example was
    on a Sun Ultra 10 440Mhz with a meg of cache. Ten packets a second took
    the box to its knees when the rehash path was 4,000 elements long.

    They can be great if done right in hardware (yes, I'd be Intel or AMD's
    bestest friend if they put a general purpose CAM table in their
    chipsets, and especially for a TCAM). There were some great debates a
    few years ago about syn-flood handling that directly apply here; they
    culminated in the ideas of random early drop and syn cookies. A LRU
    replacement policy gives the worst behavior since an attacker can flood
    your state table with new connections and all of the previous valid
    connections will be discarded. For beefy state size to bandwidth
    numbers, it takes less than 10% of the bandwith to DoS the state table.

    To be honest, there is only one problem with timing out states too late.
    You risk running out of memory.

    The way we solved this at NFR is to never expire idle TCP states. If we
    have the memory to hold fifty bazillion states in a red-black tree, then
    we'll hold onto fifty bazillion states even though they have been idle
    for months. Then when we run out of memory, we'll pressure the TCP
    state table to throw away some connections. It makes it much harder for
    an attacker evade the IDS with attacks against the state table when he
    doesn't know how much he has to send and can't predict what will get
    thrown away.

    In the OpenBSD's PF firewall we solved it a different way. The timeout
    expiration values can adapt to how full the state table is. The closer
    the state table is to being full, the quicker states will expire. And
    the timeouts are heavily skewed in favor of fully established
    connections. For example the timeout for the SYN|ACK may have been
    reduced all the way down to one second but the idle timeout for a fully
    established session will only be down to about 45 minutes.
     
    > > 3) you lose the TCP window scale value
    > > 4) the connection will break if you only allow state creation on a SYN
    > > 5) any sequence number modulation will break the connection
    > > 6) any TCP timestamp modulation will probably break the connection
    > Are these not issues arising from the use of a half-hearted attempt at
    > TCP tracking, as opposed to a lack thereof in toto?

    #3 is necessary to do any sequence number tracking. Which you need to
    do in order to safely deal with ICMP error messages that correspond to a
    TCP connection. There was an RFC about the security affects of these on
    Aug 4th or 6th.

    #4 ya, that one is for half-hearted TCP tracking. But it is necessary
    for little things like NAT.

    5 and 6 are enforcing basic TCP security for host TCP stacks which don't
    do it good enough. Michal Zalewski has a few great papers out on how
    bad most peoples' TCP initial sequence number generation is.
     
    .mike
    frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
    PGP: CC A4 E2 E8 0C F8 42 F0 BC 26 85 5B 6F 9E ED 28

  • Next message: Bob Walder: "RE: Firewall vs. IPS - Differences now (ISS, Intrushield 2.1?)"

    Relevant Pages
    • Quantcast