Re: Curious: syncookies ready for distributed syn flooding?

From: B. James Phillippe (bryan@terran.org)
Date: Sat Jun 10 2000 - 16:59:25 EDT

  • Next message: Alan Cox: "Re: Curious: syncookies ready for distributed syn flooding?"

    On Sat, 10 Jun 2000, Alan Cox wrote:

    > > Now the question: Are syncookies exactly that without need for an extra
    > > firewall? Are they only destination-port and not
    ...
    > Syn cookies will basically cut the effect of a synflood to a load test.

    My understanding of the syncookies implementation (in 2.0, at least) is
    that it only protects the host which is using it; not the hosts _behind_ it
    (ie. acting as a firewall). Is this not the case?

    FWIW, I'm researching ways to prevent SYN flooding _though_ a firewall.
    One of the approaches I'm interested in hearing feedback on goes something
    like this:

    1.) The firewall maintains a "Max SYN's per port per sec" value,
    configurable in some way.

    2.) The firewall tracks SYN's passing through it, watching to see if this
    value is ever exceeded (on a per-port basis).

    3.) If the value is exceeded, the firewall goes into "SYN flood protection"
    mode (for that port), where it begins storing the sender's IP address in a
    temp hash table of hosts which require validation. It does _not_ yet try
    to validate the sender.*

    4.) When a SYN arrives, it is compared to the value in the temp hash table:
    if there is not an entry, one is added (as above). If there is an entry,
    and it hasn't been validated, a validation request is sent. If there is an
    entry and it has already been validated, any more SYN's from this host will
    be accepted right away.**

    5.) To validate the sender, the firewall sends back a cookie of some
    kind*** to validate that the sending system is indeed on the net and has a
    listening socket for that connection request.

    * Rely on TCP retransmit to cut down on the likelihood of filling the pipe
    on outgoing SYN validation attempts.

    ** Entries in the table expire after just a handful of seconds (20, say) so
    that connections like web clients only have a short initial delay for the
    first connection, but the rest for that _session_ are unimpeded.

    *** Something like an ACK with a bogus seq. number, and the firewall
    watches for RST's to update the validation table.

    Does this sound reasonable?

    -bp

    --
    # bryan at terran dot org
    # http://www.terran.org/~bryan
    

    - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



    This archive was generated by hypermail 2b29 : Sat Jun 10 2000 - 17:04:13 EDT