kern/76966: udp/520 reply packets when routed is not running

Emil Cazamir emil.cazamir at galati.rdsnet.ro
Tue Feb 1 07:50:18 PST 2005


>Number:         76966
>Category:       kern
>Synopsis:       udp/520 reply packets when routed is not running
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 01 15:50:17 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Emil Cazamir
>Release:        FreeBSD 4.11-PRERELEASE i386
>Organization:
none
>Environment:
System: FreeBSD mail.martens.ro 4.11-PRERELEASE FreeBSD 4.11-PRERELEASE #2: Tue Dec 14 11:58:06 EET 2004 root at mail.martens.ro:/usr/src/sys/compile/MARTENS i386
>Description:
	The FreeBSD kernel seems to respond to udp/520 packets even when
there is no such daemon running. A host in an ethernet network is sending
this type of packets, sending them to ethernet broadcast address and his
subnet's broadcast address and this machine send answer packets, sending
them to the default gateway's MAC address. I believe that this kind of
replies should be send only if this machine is running a routing daemon,
such as "routed", which is not the case.
	
>How-To-Repeat:
	
tcpdump -nvi [interface] -p udp and port 520:
0:0:0:0:0:1 is my gateway's MAC address, 0:0:0:0:0:2 is my external
interface's MAC address
17:03:32.185977 0:f:3d:47:8b:de ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.186153 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.186172 0:f:3d:47:8c:9b ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.186325 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.189453 0:f:3d:47:8b:de ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.189620 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.189644 0:f:3d:47:8c:9b ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.189800 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.190279 0:f:3d:47:8b:de ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.190447 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.190486 0:f:3d:47:8c:9b ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.190659 0:0:0:0:0:2 0:0:0:0:0:1 0800 60: 192.168.1.33.520 >
192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
17:03:32.190698 0:f:3d:47:8b:de ff:ff:ff:ff:ff:ff 0800 60: 192.168.0.10.520
> 192.168.0.255.520:  RIPv1-resp [items 0]: (DF)
[root at mail] ~# ps ax | grep routed
 7390  p0  R+     0:00.00 grep routed
 [root at mail] ~# sockstat | grep 520
 [root at mail] ~# lsof | grep 520
 master     446    root   14u  PIPE 0xca3f2520      16384
->0xca3f2480
 master     446    root   15u  PIPE 0xca3f2480      16384
->0xca3f2520
 snmpd      468    root    8u  PIPE 0xca6475c0      16384
->0xca647520
 snmpd      468    root    9u  PIPE 0xca647520      16384
->0xca6475c0
 grep      7396    root  txt   VREG 116,131078      52000 202581
/usr/bin/grep

this may lead to network problems if there is a mis-configured "routed" in a
network with a large number of FreeBSD 4.x machines by generating a large 
number of packets, possibly directed to the default router of each machine. 
If the source machine will send 300 packets/second (to ethernet broadcast) 
every FreeBSD 4.x machine will generate a reply which will be sent back to 
the network, directed to the subnet's broadcast address directly or through 
the default router, generating what we know as "braodcast storm" or "denial of
service" similar to smurf.


>Fix:

	
	Temporary fix: 
		ipfw add 1 deny udp from any to any via _if_ 520
	The real solution to the problem: 
		unknown
>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list