Re: using Dummynet to rate limit ftp
On Sat, Feb 15, 2003 at 08:24:58AM +0800, Paul Hamilton wrote: I have played around with dummynet a bit. Very nice! However, it would be nice to be able to rate limit ftp. The control channel port 21 is easy, and not really necessary to rate limit it, but as fas as I can see there would be no way to rate limit the data channel, as it could be different every time, even in passive mode. Am I missing something? No, you are entirely correct. In order to properly filter (or for that matter, rate limit) FTP and some other annoying protocols like IRC DCC or Microsoft Media Streaming, you need to have a firewall that understands at least part of the protocol, so that it can discover what ports are being used for supplementary channels. Or in other words, the firewall has to start parsing the payload of packets, rather than just the headers. 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. Combine that with the requirement that the firewall works speedily and efficiently, and you can see that implementing such a system is by no means trivial. As far as I know, the only software available to do protocol aware filtering with the native FreeBSD firewalls is natd(8), with it's '-punch_fw' option. (That also appears as the 'nat punch_fw' command built into ppp(8), but it's the same code really). Unfortunately that doesn't help with your requirement to rate limit traffic on the punched connection. Now, there are some commercial firewalls that provide this sort of functionality: Checkpoint FW-1 does, and you could feed your FreeBSD habit by running it on one of those Nokia appliances based on FreeBSD 3.2... Having a natd-like process that can hang off a divert socket, interpret the FTP (or other) protocol traffic passed to it and open up dynamic rules in ipfw(8) to permit traffic through the data channel or push the data traffic through a dummynet rate limiter would be exceedingly cool. If only I had both the time and the talent to implement such a thing. 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: using Dummynet to rate limit ftp
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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: using Dummynet to rate limit ftp
Matthew Seaman wrote: On Sat, Feb 15, 2003 at 01:54:20PM -0500, Chuck Swiger wrote: [ ... ] 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? While you need to identify traffic somehow in order to apply QoS, I don't see why you have to identify traffic by port alone. Set up different priorities for other hosts versus this FTP server's IP; or match other traffic types first and leave the generic high ports to high ports for the lowest priority. [ I'm still at the tinkering stage of using bandwidth shaping myself, but bandwidth limits are appropriate when you pay by the byte or have usage limits in place. QoS is better (more useful?) when you've got unlimited connectivity, or busy pipes, or both. ] -Chuck To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
using Dummynet to rate limit ftp
Hi, I have played around with dummynet a bit. Very nice! However, it would be nice to be able to rate limit ftp. The control channel port 21 is easy, and not really necessary to rate limit it, but as fas as I can see there would be no way to rate limit the data channel, as it could be different every time, even in passive mode. Am I missing something? Cheers, Paul Hamilton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
