From owner-freebsd-current@FreeBSD.ORG Sun Nov 9 14:47:10 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA91D16A4CE for ; Sun, 9 Nov 2003 14:47:10 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2466A43FBD for ; Sun, 9 Nov 2003 14:47:08 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 7568 invoked from network); 9 Nov 2003 22:49:55 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2003 22:49:55 -0000 Message-ID: <3FAEC407.F10E7BA@pipeline.ch> Date: Sun, 09 Nov 2003 23:47:35 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Mini References: <3FAE68FB.64D262FF@pipeline.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: mb@imp.ch cc: freebsd-current@freebsd.org cc: ume@freebsd.org cc: sam@errno.com cc: freebsd-net@freebsd.org Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2003 22:47:11 -0000 Jonathan Mini wrote: > > On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > > > - DoS attack 2: make MSS very low on local side of connection > > and send maaaany small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > > > This sounds as if it might be worthwhile to add a delay to > the TF_NODELAY case for receive processing as well. Unfortunatly it is not that easy. We can't just do that unconditionally to all connections. It would probably break or delay many things. You never know how much data is outstanding and whether it's just this packet with 2 bytes outstanding... As an application aware of this problematic you have currently two options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some higher value than the default 1 byte. Only the first one is workable if you don't know what and how much the clients send to you. Relying on the application to activate any such option to prevent this kind of DoS is unfortunatly whishful thinking. The code I've put in here simply caps off the extreme cases. It counts all packets and bytes in any given second and computes the average payload size per packet. If that is less than we have defined for minmss it will reset and drop the connection. However it will only start to compute the average if there are more than 1'000 packets per second on the same tcp connection. I've chosen this quite high value to never disconnect any ligitimate connection which just happens to send many small packets. In my tests I've seen telnet/ssh sending close to 100 small packets per second (some large copy-pasting and cat'ing of many small files). Probably 500 packets per second is a better cut-off value but I just want to be sure to never hit a false positive. -- Andre