Re: IDS: Snort detecting distributed syn floods

From: Mike Frantzen (frantzen_at_nfr.com)
Date: 01/24/05

  • Next message: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods" 
    Date: Mon, 24 Jan 2005 11:50:06 -0500
To: James Eaton-Lee <james.mailing@gmail.com>

    > If I'm understanding you correctly, for a 'good' TCP connection (ie. an
    > actual connection rather than a (spoofed) SYN packet), your IPS
    > essentially establishes the three-way-handshake with the originating
    > host and sets up a connection *before* actually establishing this
    > three-way handshake with the *real* destination host. Purely out of
    > (academic) interest, have you considered the implications of this to the
    > client host, as this is a non-standard use of TCP/IP?
    > As a purely hypothetical example (which I do have a fair amount
    > experience with the underlying technology of), it's assumptions such as
    > the above (that the successful negotiation of a three-way handshake
    > indicates that the host I'm wanting to talk to is there)

    That isn't a purely valid assumption. TCP allows for reliable data
    transport between hosts. But it doesn't guarantee reliable transport
    between applications. Just because a host has completed the 3whs does
    not mean the application serving the port is alive (it could be swapped
    out permanently, the listen backlog may be full, it might be in the
    process of dumping core...)

    When you do protocol design that uses TCP as a transport layer you have
    to build in messages over the TCP to indicated "upness" or "message
    received". e.g. just because the host ACKd the data does not mean the
    actual application has processed it or will ever process it.

    > A trivial example - and one which would almost certainly be considered
    > by savvy IT staff at any site with an IPS of this type installed, but
    > still. I'm more interested if you've considered the issue than anything
    > else, as I'm sure it's quite possible that this could be a more serious
    > issue than a few hours of wasted support time in some instances!

    The achilles heal of syn-proxying are the TCP options. When the
    firewall/IPS doing the syn-proxying spoofs the SYN|ACK as if it came
    from the server it can not predict the actual TCP options the real
    server would use. There are hacks to cache and re-use the server's last
    "Maximum Segment Size" option and to allow the timestamp option to work
    (for round-trip time estimation). But there is no good way to get TCP
    MD5 Signatures to work with a syn-proxy. Hint: that means BGP is pretty
    much screwed unless you're willing to trust the syn-proxy with the key.

    .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

    --------------------------------------------------------------------------
    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: James Eaton-Lee: "Re: IDS: Snort detecting distributed syn floods"

    Relevant Pages

    • Re: Whats the difference between UDP and TCP packets?
      ... TCP is a connection oriented protocol. ... The host that wants to send data sends a SYN ...
      (comp.security.firewalls)
    • Re: TCP options order changed in FreeBSD 7, incompatible with some routers
      ... it's really the ordering of tcp options and not the bad padding. ... users complain that they cannot connect to these servers any more. ...
      (freebsd-net)
    • Re: Spoofing question?
      ... TCP and UDP, operate. ... TCP spoofing is a bit more difficult since there has to be a connection ... Attack host - The wily hacker. ... Spoofed host - The host packets will appear to be spoofed from. ...
      (Security-Basics)
    • Re: IDS: Snort detecting distributed syn floods
      ... TCP allows for reliable data ... But it doesn't guarantee reliable transport ... Just because a host has completed the 3whs does ... reliability of TCP is coded based on a set of valid assumptions! ...
      (Focus-IDS)
    • Could this be implemented with an NDIS or TDI driver?
      ... asked to find out the feasability of creating a Windows client that ... * Sits above TCP/UDP, but below the applications ... Is able to write to disk all TCP or UDP traffic on selected ports ... Is able to pass selected TCP or UDP traffic to the host applications ...
      (microsoft.public.development.device.drivers)