North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: smurf amp nets
- From: Michael Shields
- Date: Sat Jun 13 17:28:09 1998
In article <Pine.LNX.3.95.980613100514.4911Bemail@example.com>,
Mikael Abrahamsson <firstname.lastname@example.org> 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.
diff -u kernel-source/net/ipv4/icmp.c:220.127.116.11 kernel-source/net/ipv4/icmp.c:1.2
--- kernel-source/net/ipv4/icmp.c:18.104.22.168 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: 22.214.171.124 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: 126.96.36.199 An ICMP_TIMESTAMP MAY be silently discarded if to broadcast/multicast.
if (icmph->type != ICMP_ECHO)
- kfree_skb(skb, FREE_READ);
- * Reply the multicast/broadcast using a legal
- * interface - in this case the device we got
- * it from.
+ kfree_skb(skb, FREE_READ);