smurf amp nets

Sat Jun 13 21:13:14 UTC 1998

In article <Pine.LNX.3.95.980613100514.4911B-100000 at uplift.sparta.lu.se>,
Mikael Abrahamsson <swmike at swm.pp.se> wrote:
> 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);

-- 
Shields, CrossLink.