I just recorded 4.5mb of a smurf attack directed at one of my servers.
Here's a list of the networks used as amplifiers and the number of
different hosts responding from each network.
If you received this message and did not get it via the NANOG mailing list
(or received multiple copies of this message), then you are listed with an
IP registry as being the maintainer of one of the networks near the top of
the list below.
If you do no know what smurf is or why being a smurf amplifier is bad,
please read http://www.quadrunner.com/~chuegen/smurf.txt. By continuing
to be a smurf amplifier, you will risk portions of the Internet cutting
off connectivity to your network, and may provoke attacks on your
networks or hosts.
207.164.49: 87
205.68.128: 80
131.179.96: 63
206.39.81: 58
207.137.77: 46
207.123.94: 41
208.133.51: 33
207.141.205: 31
205.225.15: 29
206.39.75: 27
193.118.192: 26
192.208.46: 24
204.163.200: 23
207.102.100: 23
194.153.0: 23
194.72.186: 19
194.205.4: 19
195.224.29: 19
194.193.110: 19
192.86.78: 18
207.141.179: 17
207.204.135: 17
164.38.16: 17
193.117.190: 16
192.149.109: 16
207.87.98: 16
194.238.48: 16
204.215.181: 15
195.216.16: 15
205.225.30: 15
209.36.0: 14
195.188.206: 14
199.95.207: 14
144.85.10: 14
193.164.172: 14
198.82.184: 13
198.76.172: 13
207.243.60: 13
204.249.16: 12
140.222.56: 12
195.166.32: 12
129.210.8: 12
205.184.109: 12
207.243.45: 12
205.226.153: 12
128.11.27: 12
194.73.141: 12
206.28.165: 11
207.141.24: 11
193.115.32: 10
207.243.15: 10
204.164.100: 10
204.97.148: 10
204.107.162: 10
198.76.181: 10
194.88.77: 10
128.11.24: 10
199.242.245: 9
206.243.214: 9
198.112.240: 9
205.232.33: 9
207.233.86: 9
204.107.163: 9
206.39.78: 8
206.39.79: 8
206.119.82: 8
208.133.50: 8
140.89.18: 7
204.250.54: 7
206.39.82: 7
207.141.96: 7
192.65.144: 7
207.60.44: 7
205.225.27: 7
193.123.31: 7
164.38.19: 7
140.89.16: 6
164.67.128: 6
206.105.235: 6
206.105.236: 6
206.105.238: 6
205.181.168: 6
207.121.155: 6
129.210.11: 6
4.1.107: 6
192.216.247: 6
194.72.123: 6
207.121.91: 6
205.181.101: 6
207.243.240: 6
205.244.34: 6
207.236.112: 6
205.227.44: 6
207.87.20: 5
206.105.239: 5
207.28.162: 5
206.149.201: 5
199.240.110: 5
207.28.174: 5
166.77.235: 5
205.225.26: 5
206.119.169: 5
199.251.133: 5
207.120.147: 5
128.173.100: 4
206.39.72: 4
206.39.76: 4
207.28.163: 4
206.149.204: 4
162.127.7: 4
204.119.165: 4
207.0.88: 4
207.0.91: 4
205.218.18: 4
164.38.17: 4
164.38.18: 4
206.39.93: 3
206.149.228: 3
206.149.229: 3
195.216.24: 3
205.225.28: 3
207.233.88: 3
193.164.160: 3
205.226.152: 3
194.88.75: 3
209.178.0: 2
207.244.95: 2
194.126.66: 2
206.39.77: 2
206.34.74: 2
207.155.151: 2
206.149.208: 2
206.34.80: 2
172.16.99: 2
164.67.160: 2
206.34.91: 2
154.32.18: 2
204.167.134: 2
4.1.25: 2
12.127.147: 2
131.192.100: 2
207.21.26: 2
206.85.107: 2
206.250.100: 2
207.242.71: 2
209.155.16: 2
206.34.100: 2
206.34.101: 2
194.51.203: 2
195.92.210: 2
144.85.14: 2
193.164.161: 2
205.244.33: 2
195.200.12: 2
207.122.94: 2
207.240.2: 2
206.34.46: 1
195.50.72: 1
193.115.33: 1
128.97.251: 1
206.105.227: 1
164.38.32: 1
4.1.1: 1
206.105.231: 1
194.247.64: 1
206.39.70: 1
199.93.199: 1
144.85.200: 1
194.154.13: 1
137.52.109: 1
165.113.56: 1
144.85.207: 1
206.34.78: 1
206.98.32: 1
12.127.114: 1
128.97.46: 1
205.125.0: 1
157.130.0: 1
195.5.1: 1
206.39.92: 1
206.39.94: 1
206.39.98: 1
204.70.226: 1
12.127.209: 1
205.68.129: 1
205.202.164: 1
206.34.95: 1
204.59.1: 1
195.15.6: 1
195.89.160: 1
207.60.45: 1
195.89.163: 1
193.118.193: 1
204.70.164: 1
128.97.79: 1
4.0.128: 1
154.32.26: 1
195.99.124: 1
192.221.137: 1
4.0.63: 1
4.0.64: 1
12.127.232: 1
194.177.180: 1
144.85.1: 1
4.0.132: 1
194.80.132: 1
4.0.135: 1
206.41.10: 1
166.48.6: 1
137.39.135: 1
207.123.112: 1
196.7.77: 1
131.32.39: 1
209.4.206: 1
166.77.10: 1
204.119.168: 1
194.74.17: 1
207.165.237: 1
255.255.255: 1
12.127.163: 1
207.87.97: 1
4.0.144: 1
12.127.37: 1
149.142.122: 1
207.140.148: 1
4.0.80: 1
196.7.126: 1
192.216.246: 1
195.166.6: 1
207.0.84: 1
131.192.31: 1
131.192.32: 1
12.127.177: 1
207.233.85: 1
12.127.179: 1
204.97.134: 1
149.142.76: 1
169.139.60: 1
193.36.37: 1
4.1.66: 1
207.0.90: 1
206.149.195: 1
12.127.180: 1
207.217.50: 1
207.123.29: 1
4.0.240: 1
4.0.160: 1
194.72.131: 1
195.92.201: 1
128.97.113: 1
137.145.112: 1
207.68.13: 1
198.247.230: 1
194.205.68: 1
195.232.0: 1
157.130.193: 1
172.16.0: 1
172.16.1: 1
194.38.93: 1
131.119.18: 1
4.0.182: 1
192.221.96: 1
131.119.26: 1
131.119.28: 1
12.127.81: 1
128.97.147: 1
12.127.83: 1
164.67.72: 1
131.119.36: 1
131.119.38: 1
204.59.224: 1
128.97.230: 1
193.118.200: 1
194.164.1: 1
194.88.82: 1
131.119.49: 1
207.240.1: 1
207.137.76: 1
205.182.0: 1
I just recorded 4.5mb of a smurf attack directed at one of my servers.
Here's a list of the networks used as amplifiers and the number of
different hosts responding from each network.
This is not true! According to your list the following networks are
*NOT* smurf amplifiers. Please check your data before blacklisting
innocent people!!!
When did I blacklist anyone? Jim Flemming _is_ in my .procmailrc...so are
you taking over for him?
All I said was "here's a list of the networks used as amplifiers and the
number of different hosts responding..." Obviously, any network
responding with 1 ip is not terribly effective as an amplifier, but that
doesn't alter the fact that the attacker attempted to use them as smurf
amps.
I should probably have trimmed all nets responding with fewer than 2 IPs
since even a cisco with "no ip directed-broadcast" will generally respond
with a source ip of the interface on which the echo request arrived.
OTOH, these nets might want to consider additional filtering since they
probably get abused in this way with some frequency. Every version of
smurf.c I've seen has all the amplifier network addresses hardcoded.
BTW...I have a theory for a way to get all or most of the big smurf amp
networks fixed real fast...but doing it would probably get me in big
trouble.
Also...all the people cc'd on that message had nets with numbers of hosts
responding in the dozens or more.
I should probably have trimmed all nets responding with fewer than 2 IPs
since even a cisco with "no ip directed-broadcast" will generally respond
with a source ip of the interface on which the echo request arrived.
Exactly! And folks who are supernetting adjacent /24s into a single /23
could be using the .255 address as a host address.
BTW...I have a theory for a way to get all or most of the big smurf amp
networks fixed real fast...but doing it would probably get me in big
trouble.
Just find the amplifier nets and post their addresses here. Let someone
else get in big trouble. The net result will be roughly the same. You do
realize that 3l33t KrAkKeR d00dz monitor this list, don't you?
I actually hope that isn't what happens with my list that I
posted a link to, I hope everyone just fixes their problems.
but that's a bit too much wishful thinking, i realize.
I in no way am condoning DoS attacks, they're very evil,
(not counting the legality part). I hope that we can get ingress
filters on people, and fix these both.
One other thing, it would be interesting if someone started
a smurf at a smurf amp. (I'm tired, but believe that can be
done, but not going to think too much about it. The loop
would be interesting, and require some fun intervention to fix).
- Jared
I think this is the way of the future when smurf amps get fixed. People
will put these kind of things on hacked machines, sending spoofed floods
to broadcast adresses locally. Since everybody seems to be going to
switched nets this can create substantial amount of data.
I think the only way to solve this more permanently is to remove the
response of ICMP data to broadcast adresses in the OS. Is anyone
preassuring for this to happen? Is there a list of OS that actually does
respond to ICMP to broadcast adresses?
We've been checking the networks on the posted list, not only for ourselves but
for our downstream customers, and attempting contact with customers where
necessary to have them configure 'no ip directed-broadcast' or an equivalent.
The administrator of the 205.227.44.0/24 network has asked that we post a
confirmation that their network has been fixed.
Thanks,
Eric McClelland
GTE Internetworking
Recent FreeBSD versions have an option to disable response to a broadcast
ICMP.
Publishing information about smurf amplifier networks seems to work fine
for now, albeit slowly. I've been running the Smurf Amplifier Registry
for some time now, and it seems we have actually helped fix some networks.
Here are the current statistics:
1119 networks have been probed with the SAR
369 of them are currently broken
61 have been fixed after being listed here
I'm happy to report that the most severe smurf amplifier network I've seen
until now today changed status to "fixed" in the registry (~1100 responses
per packet)! 
I think we are making a difference.
And this is even before the more advanced functionality of the SAR has
been implemented. In a short while it will be providing an incident
reporting system as well as automated nag-mailing to potential contacts
etc. of the listed smurf amplifier networks.
I again urge those of you who want to participate in fighting against
smurfing to please use this tool for all that it's worth. Please visit us
and check out the listings and probe networks. If you see a network in
there that you can help fix, then do it!
The URL is:
http://www.powertech.no/smurf/
And btw: A big hand to those of you out there who have helped me by
showing interest in this, coming up with ideas and by actually using the
SAR.
Oystein Homelien | oystein@powertech.no
PowerTech Information Systems AS | http://www.powertech.no/
Nedre Slottsgate 5, N-0157 OSLO | tel: +47-23-010-010, fax: +47-2220-0333
Solaris also has this ability. You need to use /usr/sbin/ndd utility to
turn this off. The RFC's say that responding to directed broadcast should
be on (this has been hashed out here before) so the *nix vendors leave it
enabled in the default config. On Solaris 2.5.1 the following should
turn off response to directed broadcasts:
ndd -set /dev/ip ip_forward_directed_broadcasts 0
There are also settings for other types of ICMP broadcast packets. The response
to these types of packets may be turned off with the following:
ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
Things could possibly be different on versions of Solaris other than 2.5.1
and different patch levels can effect these things also. So be careful
when you are doing this.
bye,
ken emery
==>I think the only way to solve this more permanently is to remove the
==>response of ICMP data to broadcast adresses in the OS. Is anyone
==>preassuring for this to happen? Is there a list of OS that actually does
==>respond to ICMP to broadcast adresses?
http://www.quadrunner.com/~chuegen/smurf.txt
(I do need to add a couple more that were sent me last week.)
/cah
==>Solaris also has this ability. You need to use /usr/sbin/ndd utility to
==>turn this off. The RFC's say that responding to directed broadcast should
==>be on (this has been hashed out here before) so the *nix vendors leave it
==>enabled in the default config.
This is incorrect. The RFC (1122, section 3.2.2.6), states:
In article <Pine.LNX.3.95.980613100514.4911B-100000@uplift.sparta.lu.se>,
I think the only way to solve this more permanently is to remove the
response of ICMP data to broadcast adresses in the OS. Is anyone
preassuring for this to happen? Is there a list of OS that actually does
respond to ICMP to broadcast adresses?
Most of them do, because otherwise people complain about simpleminded
network autodiscovery tools not working. That's the same complaint
people made about directed broadcasts so I think that after a few
people suffer from cracked machines launching attacks at undirected
broadcasts, those will get turned off too.
Here is a trivial patch against Linux 2.0.34.
And disable your echo/chargen ports. UDP works as well as ICMP.
Index: kernel-source/net/ipv4/icmp.c
diff -u kernel-source/net/ipv4/icmp.c:1.1.1.2 kernel-source/net/ipv4/icmp.c:1.2
--- kernel-source/net/ipv4/icmp.c:1.1.1.2 Thu Jun 11 01:18:53 1998
+++ kernel-source/net/ipv4/icmp.c Thu Jun 11 04:05:46 1998
@@ -1108,20 +1108,13 @@
/*
* RFC 1122: 3.2.2.6 An ICMP_ECHO to broadcast MAY be silently ignored (we don't as it is used
* by some network mapping tools).
+ * [But I've decided to ignore it anyway. --Shields 1997-07-22]
* RFC 1122: 3.2.2.8 An ICMP_TIMESTAMP MAY be silently discarded if to broadcast/multicast.
*/
if (icmph->type != ICMP_ECHO)
- {
icmp_statistics.IcmpInErrors++;
- kfree_skb(skb, FREE_READ);
- return(0);
- }
- /*
- * Reply the multicast/broadcast using a legal
- * interface - in this case the device we got
- * it from.
- */
- daddr=dev->pa_addr;
+ kfree_skb(skb, FREE_READ);
+ return(0);
}
len-=sizeof(struct icmphdr);