Date: Sun, 16 Feb 2003 00:27:36 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Freebsd-Questions <freebsd-questions@FreeBSD.ORG> Subject: Re: using Dummynet to rate limit ftp Message-ID: <20030216002736.GA73692@happy-idiot-talk.infracaninophi> In-Reply-To: <3E4E8CDC.1090404@mac.com> References: <AGEHIFHGNEMPFNCPLONMEEPKEDAA.paul@compwest.com.au> <20030215104024.GB68671@happy-idiot-talk.infracaninophi> <3E4E8CDC.1090404@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030216002736.GA73692>