smurf attack.

i think i was used as an intermediary in a bunch of smurf attacks early
yesterday morning. i've got about four megabytes of tcpdump output of
echo requests from different hosts to 255.255.255.255.

[root@colin /root]# tcpdump icmp -i eth0 | grep request
tcpdump: listening on eth0
01:27:21.409738 rsfq1.physics.sunysb.edu > 255.255.255.255: icmp: echo request (ttl 246, id 55851)
01:27:21.429738 c2.constant.com > 255.255.255.255: icmp: echo request (ttl 246, id 55877)
01:27:21.439738 c2.constant.com > 255.255.255.255: icmp: echo request (ttl 246, id 55887)
01:27:21.449738 rsfq1.physics.sunysb.edu > 255.255.255.255: icmp: echo request (ttl 246, id 55894)
01:27:21.469738 rsfq1.physics.sunysb.edu > 255.255.255.255: icmp: echo request (ttl 246, id 55921)
01:27:21.489738 rsfq1.physics.sunysb.edu > 255.255.255.255: icmp: echo request (ttl 246, id 55951)

i talked to the administrator of sunysb.edu and he said that there had
been some silliness on the #shells channel that evening. i can only
assume that some idiot with adsl was kicked off of #shells and decided to
smurf everyone else on the channel.

for those of you who don't know what a smurf attack is, it involves
forging an icmp echo request from the host to attack, sending it to a
broadcast address and letting all of the hosts who receive the icmp
echo request send an icmp echo reply back. it's a magnified ping flood
which disguises the real attacker.

did anyone notice anything else unusual yesterday morning at about 1:00?

can anyone see how this might impact those of us with adsl who are going
to be restricted to one gigabyte of bandwidth every month and then have
to pay per megabyte? i already have a rant in to sasktel about this.

can anyone see how we might prevent this sort of thing? i've already
firewalled icmp traffic, so i'm not sending icmp echo replies, but i'd
hate to be mistaken for an attacker and firewalled from useful services
because everyone else in my subnet is.

colin
Received on Mon Dec 29 11:32:51 1997