From owner-freebsd-questions@FreeBSD.ORG Thu Sep 14 19:53:21 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org 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 C7CB316A403 for ; Thu, 14 Sep 2006 19:53:21 +0000 (UTC) (envelope-from pnestora@ee.duth.gr) Received: from mail.duth.gr (mail.duth.gr [192.108.114.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94D943D5A for ; Thu, 14 Sep 2006 19:53:20 +0000 (GMT) (envelope-from pnestora@ee.duth.gr) Received: from [192.168.8.10] (r-esties.xan.duth.gr [193.92.238.254]) (authenticated bits=0) by mail.duth.gr (8.13.6/8.13.6) with ESMTP id k8EJr7ol001022 for ; Thu, 14 Sep 2006 22:53:16 +0300 (EEST) (envelope-from pnestora@ee.duth.gr) Message-ID: <4509B33B.80604@ee.duth.gr> Date: Thu, 14 Sep 2006 22:53:31 +0300 From: Panagiotis User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 192.108.114.110 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.duth.gr [192.108.114.110]); Thu, 14 Sep 2006 22:53:18 +0300 (EEST) Subject: Re: Under Attack: Bandwidth throttling on 5.2.1? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2006 19:53:22 -0000 Chris wrote: > This is probably going to tax the memory. I'm sorry in advance. > > We observed 2 hangs and 3 crashes in the last 5 hours and finally > after looking at the nature of the traffic, it appears to be little > infested windows spybots from all over targeting our forums to > attempt to reply to all messages with gambling and other spam. The > referer in every case is a few obvious spam sites. We measured 33 > pages per second and all invoking perl (well you can image the load). > It's killed the system in several was I've never even seen. We > shutdown on purpose for the first time in years which is pretty bad > for business. I'm readying the quad opteron tyan to take down and > shove in it's place since the T1 can't swamp it, but still building. > The machine is a dual 3.0 xeon with 4G and Intel 1000/Pro on 5.2.1 > with IPFW enabled. If I can configure throttling on this old a > system, we could come back up I think and try ride out the attack. > I've never done this before but in an earlier thread I saw where you > configure a pipe such as: > > ipfw pipe 1 config bw 256Kbit/s > ipfw add pipe 1 tcp from 192.168.1.2 80 > > then set sysctl.conf > net.inet.ip.fw.one_pass=1 > > Is that is all that's necessary for this old a system or is there > anything else. If this is correct, would this keep this fellow from > crashing To use traffic shaping with IPFW you have to compile the kernel with the following options: options DUMMYNET options HZ=1000 then you can add some lines like these to make your bandwidth limit to work: #first flush all the previous pipes ipfw -q -f pipe flush ipfw pipe 1 config bw 256Kbit/s ipfw add pipe 1 tcp from any to any usually we use two pipes, one for download and one for upload so you can try something like this: #first flush all the previous pipes ipfw -q -f pipe flush #upload bandwidth+download bandwidth=total bandwidth #pipe for upload ipfw pipe 1 config bw 128Kbit/s #pipe for download ipfw pipe 2 config bw 256Kbit/s server_port="20,21,80,443,995,...,etc" internal_network="192.168.0.0" #config upload ipfw add pipe 1 tcp from $internal_network to any $server_port #config upload ipfw add pipe 2 tcp from any $server_port to $internal_network The variables "server_port" and "internal_network" are examples of course... :-) If you are running natd on your machine the you have to put rules AFTER the divert natd rule like these: ipfw add pipe 1 tcp from {external_ip} to any $server_port ipfw add pipe 2 tcp from any $server_port to $internal_network The net.inet.ip.fw.one_pass=1 must be set if you want your traffic to pass from pipes and not continue at next rules.... Sorry for my bad english....