From owner-freebsd-questions Sat Feb 15 16:27:48 2003 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2557137B401 for ; Sat, 15 Feb 2003 16:27:46 -0800 (PST) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EBB543FCB for ; Sat, 15 Feb 2003 16:27:42 -0800 (PST) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.12.6/8.12.6) with ESMTP id h1G0Ranh074750 for ; Sun, 16 Feb 2003 00:27:36 GMT (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost) by happy-idiot-talk.infracaninophile.co.uk (8.12.6/8.12.6/Submit) id h1G0Rado074749 for freebsd-questions@FreeBSD.ORG; Sun, 16 Feb 2003 00:27:36 GMT Date: Sun, 16 Feb 2003 00:27:36 +0000 From: Matthew Seaman To: Freebsd-Questions Subject: Re: using Dummynet to rate limit ftp Message-ID: <20030216002736.GA73692@happy-idiot-talk.infracaninophi> Mail-Followup-To: Matthew Seaman , Freebsd-Questions References: <20030215104024.GB68671@happy-idiot-talk.infracaninophi> <3E4E8CDC.1090404@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E4E8CDC.1090404@mac.com> User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, TO_LOCALPART_EQ_REAL,USER_AGENT,USER_AGENT_MUTT version=2.44 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Feb 15, 2003 at 01:54:20PM -0500, Chuck Swiger wrote: > Matthew Seaman wrote: > [ ... ] > >Now, that sounds quite reasonable, but it's really quite a minefield. > >Consider that the TCP stream could be fragmented --- unlikely in > >normal usage, but something a potential attacker might try --- or that > >an attacker might be able to persuade your firewall to open up access > >to ports or addresses it really shouldn't by sending a cunningly > >modified FTP control exchange. > > While I agree with this and the points you've made, let me suggest that > the problem the original poster had is better solved by prioritizing > traffic, rather than by setting fixed bandwidth limits in place. Or > perhaps "in addition to fixed BW limits" The question of QoS rather than bandwidth capping is valid, but how do you prioritise data traffic if you can't identify at least one of the port numbers used for the TCP or UDP streams? FTP isn't always so bad in this respect, unless mixed with NAT, as FTP data streams usually involve port 20 somewhere. A normal FTP PORT command results in opening a channel from port 20 on the server back to an arbitrary port number specified by the client --- that makes firewalling the server easy, but means you would have to poke holes in a client side firewall that you could drive a bus through. Hence the commonly used alternative: the FTP PASV command results in the client opening a connection from port 20 on the client to the specified but arbitrary port on the server. Easy enough to firewall correctly on the client side. Of course, if it's the server you're concerned with running, life isn't so good. Especially if your clients connect from behind a NAT gateway which feels free to munge the originating port number for outgoing connections. That means you've got the tricky situation where the server sees port numbers at either end of the connection which are arbitrary, and the only way the server's firewall could possibly identify FTP data streams would be by listening in on the FTP control channel. The same sort of thing happens for some other protocols. For instance MS Media Streaming opens a TCP and/or UDP control channel to port 1755 on the server --- that's all fine and dandy, and easy enough to write firewall rules for. However the actual data streaming occurs as a unidirectional stream of UDP packets from the server to the client using a random port number between 1024 and 5000 at either end of the connection. Horrible design from the p.o.v. of firewalling or controlling bandwidth usage. http://www.microsoft.com/windows/windowsmedia/serve/firewall.aspx Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message