Date: Tue, 15 Jan 2002 02:58:27 -0000 From: Matthew Whelan <muttley@gotadsl.co.uk> To: Richard Nyberg <rnyberg@it.su.se>, nate@yogotech.com (Nate Williams) Cc: Nate Williams <nate@yogotech.com>, Ian <freebsd@damnhippie.dyndns.org>, Rolandas Naujikas <rolnauj@delfi.lt>, stable@FreeBSD.ORG Subject: Re: tcp keepalive and dynamic ipfw rules Message-ID: <GCA67273WQ2HBXUKHUOB6JNLOFDKF.3c439ad3@VicNBob> In-Reply-To: <15427.13548.266651.846138@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> My solution to keep my ssh sessions from hanging because I made a cup >> of coffe was to up the syctl MIB 'net.inet.ip.fw.dyn_ack_lifetime' to >> a more reasonable value. > >So, non-active TCP sessions can now get packets through since the >lifetime of the rules now exceed the lifetime of many of your TCP >sessions, so I can now watch your firewall and punch packets through it >by analyzing the data. > >(In short, anyone good enough to punch through packets using the other >firewall setup is also capable of punching through packets with extended >lifetime TCP dynamic rules.) Is ipfw really that dumb? I admit I've never really fiddled with it as, being a gamer, I wanted NAT not to have to do the kernel->userland->kernel transitions so chose ipf/ipnat... I'm pretty sure from watching the ipfstat output that ipf is picking up the FINs and dropping the TTL on dynamic rules when TCP sockets are properly closed (admittedly UDP still presents the possibility of problems but the default timeout there is rather shorter). I haven't seen any ipfw vs ipf comparisons mention this; if ipfw genuinely is incapable of spotting the end of a TCP connection (assuming the FINs are seen both ways), personally I'd think that a strong reason to advocate ipf as being preferable to ipfw where dynamic rules are needed But then, I'm a firewall newb :) Besides, it seems to me that given the sort of hacker/script capable of exploiting such a weakness, 5 minutes' vulnerability is pretty much as bad as 10 days'... after all, they must be recording the traffic as it happens to know which port to attack. Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?GCA67273WQ2HBXUKHUOB6JNLOFDKF.3c439ad3>