Date: Tue, 1 Feb 2005 17:35:28 +0200 (EET) From: Emil Cazamir <emil.cazamir@galati.rdsnet.ro> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/76966: udp/520 reply packets when routed is not running Message-ID: <20050201153528.415C82A6A6@mail.martens.ro> Resent-Message-ID: <200502011550.j11FoI91086275@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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@mail] ~# ps ax | grep routed 7390 p0 R+ 0:00.00 grep routed [root@mail] ~# sockstat | grep 520 [root@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050201153528.415C82A6A6>