Date: Sat, 27 Feb 1999 21:15:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: rch@iserve.net (Robert Hough) Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD & Sendmail Message-ID: <199902272115.OAA15310@usr09.primenet.com> In-Reply-To: <199902261552.KAA16033@zoe.iserve.net> from "Robert Hough" at Feb 26, 99 10:53:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902272115.OAA15310>