On Thu, Feb 28, 2002 at 05:53:15PM -0800, Don Cohen wrote: > It doesn't seem very important to shape the incoming traffic that will > be forwarded, since the same shaping can be done at output. Obviously ... > However, it does seem useful to be able to shape the incoming traffic > destined for the local machine. ... the only other option, besides rejection of course ;-) > For example, suppose this machine is running a server that you want > to limit to 10 connections/minute. It seems reasonable to do this > by limiting the rate at which syns are delivered to that server. > That might be a lot easier than trying to modify the server. I use application-level software for that (iplimit in conjunction with tcpserver allows me to limit per-service connection rates on a per-source basis). > You might argue that doing it in the server would have the advantage > of being able to make more intelligent decisions about which ones to > accept and which to drop, but in fact the opposite could also be the > case. (I'm working on a project that provides an example.) I agree with the Unix-way of doing things usually, not the emacs way -- don't build it into the program if it works just as well outside the program; thus iplimit. Programs that accept their own connections, like Apache, can't use an external program of course (yet), so it would make sense to build this in although I proxy my incoming connections through a Squid service set up as an accelerator with bandwidth pools turned on. > What I find frustrating is that, as a firewall, I can already do this > stuff for the servers (and clients) running on OTHER hosts, but I > can't do it for those running on the local machine! I've got around that in some situations by teaching myself to treat the gateway/firewall box as a non-service box -- it runs nothing but the firewalls, tunneling, forwarding and shaping. This allows it to work as desired (all traffic goes out one of the two interfaces; none goes to the local host). -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/
