Description of problem: fedora hosts by default will happily participate as smurf amps. we are seeing this on a disturbingly increasing frequency. Version-Release number of selected component (if applicable): FC4T3 How reproducible: Always Steps to Reproduce: 1.ping broadcast of a subnet of fedora machines. 2.watch them all respond to a single ping packet. 3.profit (ddos)! Actual results: fedora boxen happily participate in smurf amping Expected results: they should ignore broadcast ping. Additional info: This should probably be added to the default /etc/sysctl.conf: # Prevents host from being abused as a smurf amp net.ipv4.icmp_echo_ignore_broadcasts = 1
Broadcast pings are a useful network diagnostic for many people. Turning it off is a local decision you can make for yourself, but not really something that should be imposed by default for every user.
They also cause problems. One possibility would be to provide an option to reply to them with a low ttl only. Alternatively we should default to blocking broadcast icmp ping in the firewall rules. I disagree with DaveM for two reasons 1. Broadcast ping abuse is a serious problem 2. Mapping by broadcast ping doesn't work reliably nowdays because many other OS's and setups ignore them for the same reason Dan proposes we do.
i guess davem has never had to deal with 500mbit/s smurfs. :) broadcast ping means fedora core is a ddos-enabler out of the box, even with all services disabled. this is terrible policy. every security organization (CERT, etc) recommends disabling broadcast ping by default. cisco ios ships with it disabled by default. http://www.cert.org/advisories/CA-1998-01.html http://www.ja.net/CERT/JANET-CERT/prevention/cisco/private_addresses.html#smurf http://www.ciac.org/ciac/bulletins/i-021a.shtml you can achieve what you need almost always with controlled unicast ping. there's no good reason to ship broadcast enabled out of the box. anyone who absolutely needs it (probably 1 or 2 people on the entire planet? besides skript kiddies) can enable it manually. low ttl means you can still totally remotely nuke someones network with ease, you just cant use them to relay the attack to a third party victim. tis best to disable by default.
Ok. There is another side effect to consider however. In current kernels turning on icmp_echo_ignore_broadcasts also has the effect of ignoring broadcast TIMESTAMP icmp messages as well. To be honest, all of this suggests that it should be disabled by default in the kernel.
This bugzilla has provided enough strong evidence that I've decided to turn this thing off by default in the upstream 2.6.x kernel. I'll likely do the same for 2.4.x as well.
status: closed ? resolved? etc
one might also argue that accept_source_route should default 0 as this has not worked anywhere on the internet for the past 15 years ... ? it's deader than classful routing.
should probably be a knob somewhere for udp to ignore directed broadcasts too. something like udp_ignore_broadcasts papasmurf achieves much the same effect as icmp echo by sending udp broadcasts. even if the target port is closed (udp/7) the flood of port unreachables has much the same effect on the victim. http://www.netscan.org/papasmurf.c cisco has a knob 'no ip directed-broadcast' for interfaces which disables all directed broadcasts -- icmp and udp, thus preventing both attacks. 'no ip directed-broadcast' is the cisco default now.
I'll close this as UPSTREAM, as it will be fixed in the upstream kernel and then trickle back into Fedora that way.