Date: Wed, 01 Oct 1997 10:56:17 +1000 From: Richard Jones <richard@a42.deep-thought.org> To: hackers@freebsd.org Subject: FreeBSD TCP stack SUX big juicy ones. Message-ID: <m0xGD5O-0024w4C@a42.deep-thought.org>
next in thread | raw e-mail | index | archive | help
Well it seems the original subject for this email: "TCP connection initiation problem?" was not technical enough for the hackers@freebsd.org list and got lost amongst techno-gems such as "Our *NIX is better than their *NIX" and "The number of the beast is vi vi vi". Now as important as these issues are I was hoping I could get some feedback on the following situation: Could someone explain what lies behind the packet exchange shown below. 204.216.27.18 is FreeBSD's smtp port and port 8000 is a non-existent port on aaa.bbb.ccc.ddd (i.e. the initial packet from aaa.bbb.ccc.ddd to freebsd.org is forged). 20:42:56.116714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: S 667:667(0) win 4096 (ttl 200, id 666) 20:42:56.686714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 <mss 1460> (DF) (ttl 53, id 16513) 20:42:56.686714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5507) Now at this point SunOS, Linux and NetBSD all take no for an answer, but FreeBSD just won't quit. It takes FreeBSD another 1min15secs to decide its SYN's are not wanted (i.e the connection establishment timers kicks in). It should be noted that the initial packet can have its source faked and the packet exchange will occur between the FreeBSD host and the unsuspecting other. 20:43:02.266714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 <mss 1460> (DF) (ttl 53, id 16672) 20:43:02.266714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5508) 20:43:26.236714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: S 856239105:856239105(0) ack 668 win 16384 <mss 1460> (DF) (ttl 53, id 17083) 20:43:26.236714 aaa.bbb.ccc.ddd.8000 > 204.216.27.18.25: R 668:668(0) win 0 (ttl 255, id 5509) Ok, so in the next packet FreeBSD finally decides to give up: 20:44:11.236714 204.216.27.18.25 > aaa.bbb.ccc.ddd.8000: R 1:1(0) ack 1 win 16384 (DF) (ttl 53, id 18235) Note the RST's from aaa.bbb.ccc.ddd are not getting lost on the network, I've verified on another host that these packets get through (the timings really tell that story anyways). Is this broken SYN-Flood protection? Does it allow Evil others to cause a large exchange of data between a FreeBSD host and any other at just the cost of a single packet to Mrs/Mr Evil? Or am I completely missing the point? Does this exchange have a use which is beyond my ken? Richard Jones
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0xGD5O-0024w4C>