From owner-freebsd-stable Thu Feb 22 20:58:46 2001 Delivered-To: freebsd-stable@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 0ADF037B503 for ; Thu, 22 Feb 2001 20:58:44 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f1N4wZD72398; Thu, 22 Feb 2001 23:58:36 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200102230458.f1N4wZD72398@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Matthew Emmerton" Cc: "Alexandr Kovalenko" , freebsd-stable@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: ipfw drop syn+fin References: <4346812337.20010222115242@yahoo.com> <004501c09ce8$f1cfd850$1200a8c0@gsicomp.on.ca> In-reply-to: Your message of "Thu, 22 Feb 2001 11:03:06 EST." <004501c09ce8$f1cfd850$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Feb 2001 23:58:35 -0500 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > # TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. > This > > # prevents nmap et al. from identifying the TCP/IP stack, but breaks > support > > # for RFC1644 extensions and is not recommended for web servers. > > > > I'm wondering _why_ it is not recommended for web servers? > > I may not be 100% on this, but I'll give it a shot. > > One of the "features" of TCP is to bundle multiple commands in one > transmission. > > Say a web client has a few connections to a web server. One of those > connections is retriving an image (for example). When it's finished, it > will send a FIN to the server to close that connection. However, at the > same time, the web client wants to open a new connection to the same > machine, which requires a SYN to be sent. The smart TCP/IP stack on the web > client will set both the SYN and FIN bits in one packet, which means "close > this connection, and open a new one." No, that's not what it means at all. What a TCP segment with both a SYN and a FIN flag set means is that you're opening a new connection, you have a small amount of data to send (which fits into the same segment), and that you have no other data to send. This means that the remote TCP stack can return one ACK segment for the FIN (which also acks the SYN and the data), rather than requiring a seperate handshake to ACK the syn, some data, and the FIN if they were all not to arrive at the same time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message