Re: ip contrack problem, not strictly followed RFC, DoS very much possible

From: gj (gj_at_pointblue.com.pl)
Date: 12/06/04

  • Next message: H. Peter Anvin: "Re: [RFC] dynamic syscalls revisited"
    Date:	Mon,  6 Dec 2004 23:20:26 +0100
    To: <Valdis.Kletnieks@vt.edu>, Grzegorz Piotr Jaskiewicz <gj@pointblue.com.pl>
    
    

    On Mon, 6 Dec 2004 at 20:48:45, Valdis.Kletnieks@vt.edu wrote:

    > On Mon, 06 Dec 2004 14:54:59 +0100, Grzegorz Piotr Jaskiewicz said:
    >
    > > There is little bug, eversince, no author would agree to correct it
    > > (dunno why) in ip_conntrack_proto_tcp.c:91:
    > > unsigned long ip_ct_tcp_timeout_established = 5 DAYS;
    >
    > If you so desire, you can probably workaround this by doing:
    >
    > echo 100 >
    > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
    >
    > Of course, then if you don't type in an SSH window for 5 minutes, it
    > evaporates
    > on you - and even SSH keepalives don't help if a router takes a nose dive
    > and
    > it takes 2 minutes for our NOC to slap it upside the head. This is a case
    > *against* keepalives there - if a router hiccups and drops a keepalive on
    > an
    > otherwise idle session, you nuke a perfectly good idle session for reasons
    > totally contrary to the original purpose of TCP, namely to *survive* such a
    > router burp.

    Shouldn't it be protocols thingie to take care about connections ?
    Ussualy some protocols are sending ping packet to peer.
    This value as it is now, keeps too many connections in memory, which often leads
    to conntrack overflow, that blocks litteraly whole machine up. That is nothing
    more than DoS, and besides, there is no fallback routine, something that uppon
    error would react. Like, flush very likely to be dead connections, etc.

    -- 
    Grzegorz Jaskiewicz
    K4 Labs
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: H. Peter Anvin: "Re: [RFC] dynamic syscalls revisited"

    Relevant Pages

    • Re: file as a directory
      ... And network connections, and pipes are files ... You can't just go around pretending an element in an array is the ... recursion _has_ to stop somewhere. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: oops reiserfs / kernel
      ... > The server has started to refuse all connections after several days of ... After a reboot it worked well during 5 hours ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: /proc/net/tcp not updated fast enough?
      ... > of the connections - and thus not totally ignorable) I had to read ... the seqfile interface. ... send the line "unsubscribe linux-kernel" in ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • Re: epoll reporting events when it hasnt been asked to
      ... > I don't normally see this behaviour for most connections, ... the user sets the event mask to zero, it can still know when something ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)