Date: Thu, 24 Jul 1997 16:30:20 -0400 (EDT) From: spork <spork@super-g.com> To: questions@freebsd.org Subject: Re: ICMP ECHO_REQUEST on BROADCAST--HOWTO Filter! (fwd) Message-ID: <Pine.BSF.3.95q.970724162323.18548A-100000@super-g.inch.com>
next in thread | raw e-mail | index | archive | help
Hello,
There's been talk on Bugtraq and NANOG about routers passing broadcast
requests (x.x.x.255 or x.x.x.0) and the resulting storm of broadcasts some
malicious person can cause on your lan... In the attached message, the
poster mentions that if you block at the router, you will stop outside
attacks, but if you have a public access machine on your lan, there's no
stopping someone from launching something like ping -s 4000 x.x.x.255 from
a local machine. Is anyone considering either a) making FBSD not respond
to broadcast ICMP or b) making a patched version of ping to put on
public-access machines that can't send to broadcast addresses?
The latter seems more "correct" and would help protect your local site as
protecting remote sites that are unaware of the fix...
Any thoughts?
Charles
---------- Forwarded message ----------
Date: Thu, 24 Jul 1997 18:50:37 -0000
From: Michael Shields <shields@CROSSLINK.NET>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: ICMP ECHO_REQUEST on BROADCAST--HOWTO Filter!
> The real purpose of the `ip directed-broadcast' command is to
> allow the filtering of server visibility and reachability
> (for example, allowing departmentally-maintained BOOTP servers).
>
> It does not prevent translation of a generic 'ping 1.2.3.255' to
> an ethernet broadcast.
It prevents the Cisco from doing so, yes. Here is an example, pinging
from one side of a Cisco (206.246.124.0/24) to another
(206.246.88.192/26).
ip directed-broadcast:
~$ ping 206.246.88.255
PING 206.246.88.255 (206.246.88.255): 56 data bytes
64 bytes from 206.246.124.1: icmp_seq=0 ttl=255 time=16.6 ms
64 bytes from 206.246.88.203: icmp_seq=0 ttl=254 time=17.4 ms (DUP!)
64 bytes from 206.246.88.230: icmp_seq=0 ttl=254 time=18.2 ms (DUP!)
64 bytes from 206.246.88.195: icmp_seq=0 ttl=63 time=18.5 ms (DUP!)
64 bytes from 206.246.88.202: icmp_seq=0 ttl=254 time=18.7 ms (DUP!)
64 bytes from 206.246.88.231: icmp_seq=0 ttl=254 time=19.0 ms (DUP!)
--- 206.246.88.255 ping statistics ---
1 packets transmitted, 1 packets received, +5 duplicates, 0% packet loss
round-trip min/avg/max = 16.6/18.0/19.0 ms
no ip directed-broadcast:
~$ ping 206.246.88.255
PING 206.246.88.255 (206.246.88.255): 56 data bytes
64 bytes from 206.246.124.1: icmp_seq=0 ttl=255 time=2.9 ms
--- 206.246.88.255 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2.9/2.9/2.9 ms
Of course you can still launch an attack from a machine on local
ethernet. Here's a Linux 2.0.30 patch to stop it from answering
broadcast pings.
Index: net/ipv4/icmp.c
===================================================================
RCS file: /usr/src/master/linux/net/ipv4/icmp.c,v
retrieving revision 1.1.1.8
retrieving revision 1.2
diff -u -r1.1.1.8 -r1.2
--- icmp.c 1997/07/08 21:55:18 1.1.1.8
+++ icmp.c 1997/07/23 00:25:13 1.2
@@ -1114,20 +1114,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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970724162323.18548A-100000>