Livingston needs to update CERT regarding smurfing

[swagman () SWAGMAN COM (Patrick J. McEvoy)]

Livingston,

> From the recent CERT advisory about "smurfing" [CA-98.01 - smurf]:

>       III. Solution
>
>       A. Solutions for the Intermediary
>
>       1. Disable IP-directed broadcasts at your router.
>
>       One solution to prevent your site from being used as an
>       intermediary in this attack is to disable IP-directed broadcasts
>       at your router. By disabling these broadcasts, you configure your
>       router to deny IP broadcast traffic onto your network from other
>       networks. In almost all cases, IP-directed broadcast functionality
>       is not needed.
>
>       Appendix A contains details on how to disable IP-directed
>       broadcasts for some router vendors
>
>       ...
>
>       Appendix A - Vendor Information
>
>       ...
>
>       Livingston Enterprises, Inc.
>       ============================
>       Livingston Enterprises products discard any ICMP packets directed to
>       broadcast addresses, so we protect against this form of attack.
>       No special configuration is required.

Unfortunately, this is not true. In the following "ping -s" (names and
IP addresses changed to protect the innocent), the packets take the
following path:

        Sparcstation  ==> ethernet    ==> IRX 211 (Livingston Firewall)
        IRX 211       ==> frame relay ==> PM2ER   (Livingston Portmaster)
        PM2ER         ==> ethernet    ==> IRX 211 (Livingston Firewall)
        IRX 211       ==> ethernet broadcast

None of the three pieces of Livingston equipment dropped the packet. All are
running ComOS 3.7.x. The Class C network in question is not subnetted or
supernetted anywhere along the path.

Sooooo, I thing CERT has some incorrect (or at least misleading) information
about you.

[As it turns out, none of the seven pieces of Livingston equipment on the
end net responded to the ICMP broadcast packets, but all the pieces along
the way were happy to forward them.]

Cheers,
swagman

 =============================================================================
% ping -s 192.192.192.0
PING 192.192.192.0: 56 data bytes
64 bytes from news1.test.org (192.192.192.17): icmp_seq=0. time=44. ms
64 bytes from news1.test.org (192.192.192.17): icmp_seq=0. time=92. ms
64 bytes from relay1.test.org (192.192.192.18): icmp_seq=0. time=167. ms
64 bytes from 192.192.192.1: icmp_seq=0. time=265. ms
64 bytes from ns1.test.org (192.192.192.19): icmp_seq=0. time=285. ms
64 bytes from ns2.test.org (192.192.192.20): icmp_seq=0. time=336. ms
64 bytes from 192.192.192.1: icmp_seq=0. time=360. ms
64 bytes from ns2.test.org (192.192.192.20): icmp_seq=0. time=376. ms
64 bytes from relay1.test.org (192.192.192.18): icmp_seq=0. time=387. ms
64 bytes from ns1.test.org (192.192.192.19): icmp_seq=0. time=406. ms
64 bytes from news1.test.org (192.192.192.17): icmp_seq=1. time=45. ms
64 bytes from news1.test.org (192.192.192.17): icmp_seq=1. time=76. ms
64 bytes from 192.192.192.1: icmp_seq=1. time=129. ms
64 bytes from relay1.test.org (192.192.192.18): icmp_seq=1. time=159. ms
64 bytes from ns2.test.org (192.192.192.20): icmp_seq=1. time=187. ms
64 bytes from ns1.test.org (192.192.192.19): icmp_seq=1. time=207. ms
64 bytes from 192.192.192.1: icmp_seq=1. time=227. ms
64 bytes from ns2.test.org (192.192.192.20): icmp_seq=1. time=247. ms
64 bytes from relay1.test.org (192.192.192.18): icmp_seq=1. time=267. ms
64 bytes from ns1.test.org (192.192.192.19): icmp_seq=1. time=287. ms
^C
----192.192.192.0 PING Statistics----
2 packets transmitted, 20 packets received, -900% packet loss
round-trip (ms)  min/avg/max = 44/227/406
%