Date: Sat, 27 Jan 2001 14:53:40 -0500 From: David <habeeb@cfl.rr.com> To: freebsd-security@FreeBSD.org Subject: Re: Re: ICMP attacks Message-ID: <01012714534001.22722@fortress> In-Reply-To: <20010127170042.A737@basildon.homerun> References: <NEBBIEGPMLMKDBMMICFNOEHBECAA.mit@mitayai.net> <20010127170042.A737@basildon.homerun>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 27 January 2001 11:00, you wrote: > On Fr , Jan 26, 2001 at 04:44:51am -0500, Will Mitayai Keeso Rowe wrote: > > > icmp-response bandwidth limit 205/200 pps > > > icmp-response bandwidth limit 264/200 pps > > > icmp-response bandwidth limit 269/200 pps > > > icmp-response bandwidth limit 273/200 pps > > > icmp-response bandwidth limit 273/200 pps > > > icmp-response bandwidth limit 271/200 pps > > > icmp-response bandwidth limit 261/200 pps > > > icmp-response bandwidth limit 268/200 pps > > > icmp-response bandwidth limit 205/200 pps > > > icmp-response bandwidth limit 223/200 pps > > > > Is there any way to trace the people that are causing this? It's becoming > > a daily occurance and it's beginning to irritate me. > > One is probably just running a portscan against you. > > The reason you see these messages is because a well behaving system > generates an ICMP "port unreachable" message for every port that does > not listen for incoming connections. > > To prevent you from generic ICMP based attacks that try to eat up your > bandwidth, the ICMP_BANDLIM parameter was introduced in the GENERIC > kernel. Some scanning programs, e.g. nmap, generate a large number of > requests, thus triggering more replies than ICMP_BANDLIM allows to get > out. [1] > > This is nothing to worry about, imho. > > Regards, > Thomas Seck > > [1] If this is in any way not precise enough, do not beat me - I am not > a kernel hacker. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message I would suggest you setup some sort of local firewall. Using ipfw(8) with a dummynet(4) to help limit ICMP and SYN. Also i find it useful to use the following sysctl options so when a UDP or TCP packet is sent to a closed port on your box or there is no connection the kernel will discard the packet instead of sending back a reply (usually an RST): net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 Hope it can help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01012714534001.22722>