Date: Wed, 9 Feb 2000 14:33:58 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: John <papalia@udel.edu> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: ICMP_BANDLIM Message-ID: <20000209143358.I17536@fw.wintelcom.net> In-Reply-To: <4.1.20000209164521.0094f660@mail.udel.edu>; from papalia@udel.edu on Wed, Feb 09, 2000 at 04:48:40PM -0500 References: <4.1.20000209140745.009d5810@mail.udel.edu> <4.1.20000209133845.0094c1c0@mail.udel.edu> <4.1.20000209133845.0094c1c0@mail.udel.edu> <20000209112923.Y17536@fw.wintelcom.net> <4.1.20000209140745.009d5810@mail.udel.edu> <20000209114558.B17536@fw.wintelcom.net> <4.1.20000209164521.0094f660@mail.udel.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
* John <papalia@udel.edu> [000209 14:18] wrote: > >> >> With all the attacks going on on yahoo, ebay, etrade, etc, it reminded > >of a > >> >> question I had a while back but forgot to ask... > >> >> > >> >> What exactly does the "ICMP_BANDLIM" kernel option do to provide > >> >> 'protection'? Not much in the LINT file on it, and I can't search, so I > >> >> thought I'd ask :) > >> > > >> >It restricts the amount of responces you will send in responce to bad > >> >packets. > >> > > >> >If someone is sending you 100mbit of grabage down your pipe, you don't > >> >want to overload the system and connection by forcing it to respond > >> >to each and every packet. > >> > >> So, in other words, it's pretty much a choke you put on your reponse (ex: > >> answer only 1 in every 1,000 ping requests you get from a particular IP ?). > > > >more like X per second, you'll only respond to the first 100/200/whatever > >packets you get in a second, see: > > > >~ % sysctl -a | grep icmp > >net.inet.icmp.maskrepl: 0 > >net.inet.icmp.icmplim: 200 <------ here > >net.inet.icmp.drop_redirect: 0 > >net.inet.icmp.log_redirect: 0 > >net.inet.icmp.bmcastecho: 0 > > > >> If so, are there dynamic settings to it? Or is just a single kernel option > >> with no settings? And I'm also assuming that ICMP_BANDLIM is also a > >> stopper for ALL network traffic (overload), not just particular items? > > > >You can use sysctl to twiddle the limit. > > I guess this raises another question though - how do you tell what kind of > limit would be a "correct" setting for your particular server? In other > words, how do I know what my equipment can handle adequately? I'm also > working on the assumption that all packets beyond the X per second are > merely dropped? Well the ICMP responces are generated for invalid packets, it's error reporting that's required by various RFCs, I haven't committed this stuff to memory and don't really have time to look it up for you, but basically the defaults for this limiting are pretty sane, if anything is causing you to exceed the limit here, it's probably some sort of DoS attempt. It's sort of like an office with a 2 doors, one for employees and one for new job applicants along with directions for new applicants to use a specific door. If someone rings the employee door you want to get up and answer it telling the person that the door isn't for them, but if the door is ringing 200 times a second you probably won't want to keep getting up to redirect people as you won't be able to get any of your work done. > >You can also try a patch I have for 3.x which is Warner's work backported > >from 4.0, I'd like to know if this 'helps' at all: > > > >http://www.freebsd.org/~alfred/releng3_tcp_fix.diff > > I would like to try the patch, just to see if there's a difference. I'm > actually not (yet) experiencing any problems - I just wanted to make sure I > fully understood everything that I had put into my kernel =) > > Your .diff raises another question for me though - how would I go about > "manually" integrating that diff into my source tree? And then, could i > just build that one file, or do you build the whole sys directory, or must > you rebuild the world? This last item would cause another problem, which > I'll post in a separate posting..... You'd only need to patch tcp_input.c, something like: cd /usr/src/sys/netinet ; patch < releng3_tcp_fix.diff then all you need to do is recompile the kernel, a new world is not required. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] 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?20000209143358.I17536>