From owner-freebsd-hackers Sat Feb 27 13:15:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 05C741508C for ; Sat, 27 Feb 1999 13:15:33 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA05743; Sat, 27 Feb 1999 14:15:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpd005694; Sat Feb 27 14:15:07 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id OAA15310; Sat, 27 Feb 1999 14:15:05 -0700 (MST) From: Terry Lambert Message-Id: <199902272115.OAA15310@usr09.primenet.com> Subject: Re: FreeBSD & Sendmail To: rch@iserve.net (Robert Hough) Date: Sat, 27 Feb 1999 21:15:03 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902261552.KAA16033@zoe.iserve.net> from "Robert Hough" at Feb 26, 99 10:53:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anyone know what this message means? I've got like 2-3 people with > this problem, and cant seem to figure out what it is. > > NOQUEUE: Null connection from cthulu.iserve.net [207.250.219.24] Your loglevel is greater than 5? 8-) 8-). No, wait... you enabled "lognullconnection"? 8-) 8-). It means that whoever connected you you either immediately disconnected, or sent a quit command and caused you to disconnect. If the message immediately before this in the log is "lost input channel..." Then it's a disconnect; otherwise it's a quit. Are you seeing a lot of processes in FIN_WAIT_2? It's pretty easy to stage a denial of service attack against a FreeBSD machine by using a Windows box and writing a program that: 1) Opens the SMTP port 2) Sends a "quit" 3) Waits for the "221" disconnect 4) Waits for the server shutdown. 5) Does *not* call "shutdown" on the socket 6) Calls "close" on the socket to discard the local context 7) Go to (1) This is because the socket resource tracking that results in the CTL,ACK is based on an explicit call to "shutdown" in WinSock... in other words, a close of a socket on Windows will not result in a proper shutdown. This is actually a bug in the design of the TCP/IP protocol, in that it requires two response packets from the client for one packet from the server, and places no limitations on the time it takes to send it. FreeBSD and a number of other OS's hack around the problem by putting a time-to-live on FIN_WAIT_2 state, but of course these are just hacks to limit the damage from broken clients. The hacks are pretty useless in the face of an intentional denial of service attack. NT server's TCP/IP stack fixes this by, after 2 MSL, pretending it "lost" the ACK that caused the FIN_WAIT_1 to FIN_WAIT_2 transition on the server. As a result, it resends the solicitation. If you sniff the wire on any relatively busy office connected to the Internet, you will see NT servers from all over "attACKing" you; this is what they are doing. If the remote machine ACK's again, it means that it knows about the TCP/IP session, and that it wasn't closed. If, however, it RST's you, then you treat it as if the FIN,ACK had been sent, and close down the connection. This should probably be implemeneted as an official change to the TCP/IP specification to deal with denial of service attacks (worst case, the attacker is DOS'ed back and required to ACK you to keep the attack up). So far, despite multiple reports, FreeBSD and other OS's seem to not care about preventing this attack. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message