Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


What Broadcast Traffic Reveals

by David M. Piscitello, President, Core Competence, Inc.

Imagine accompanying the Dilbert character Loud Howard to the grocery store. You're in aisle seven. From the adjacent aisle (pharmacy products), Howard booms, "Which laxative did you say gave you cramps last night? Should I pick up more cortisone creme for that awful looking rash you have under your armpits? Do you still use 4571 as your debit card PIN?" In this embarrassing scenario, Loud Howard's spontaneous and inappropriate outbursts broadcast intimate details about you in a public forum, specifics you truly did not want disclosed. Howard's shouting also distracts you and everyone within earshot from your tasks at hand.

Messages broadcast over Ethernet LANs can also reveal too much -- and inhibit network performance. Let's look at a sample of what broadcast Ethernet traffic reveals, and see what measures you can take in different scenarios to protect yourself from protocols that behave like Loud Howard on your LANs.

Ethernet and Broadcast Frames

The Ethernet LAN standards reserve a special MAC address, the broadcast address, which is to be used for delivering a frame to all stations listening on the LAN medium. A frame is the chunk of data that includes Ethernet delivery information and payload (for example, an IP packet). By sending a frame to a broadcast destination address, the transmitting station reaches all nodes on a network segment by generating only one frame, instead of one frame for every node on the LAN -- an efficient operation. Every station on an Ethernet LAN listens for frames containing broadcast destination addresses as well as its own unique MAC address. This is true for shared medium or switched access within the same VLAN, wired or wireless, and (unless filtered) bridged Ethernet LANs as well.

Broadcast-addressed frames have numerous uses: Address resolution (ARP, RARP), router discovery (e.g., Cisco's Router Discovery Protocol, OSPF's designated router election), routing protocol advertisements, and DHCP, for example. Many network operating system (NOS) protocols IPX, AppleTalk, Windows NetBIOS/SMB, and others broadcast "service" advertisements to identify servers and the resources (files, printers, directories) they maintain.

When we don security caps, we sometimes focus too exclusively on our vulnerabilities to external attacks. We should pay closer attention to everything that's running on internal LANs, with a holistic rather than security-focused perspective. Misconfigured systems are not only worrisome because they create security risks: they can inhibit overall LAN performance as well. So if you are already routinely conducting security audits, consider performing a network inventory as well.

Passive Discovery Using Broadcast Traffic: The Internal Audit

Many auditing tools inventory networks "actively," using address and port scans. They intentionally make connection attempts to applications, issue malformed protocol headers, and more. These can be intrusive: not only do they generate patterns different from "normal" traffic for your network, but the added traffic load on a network is counterproductive, especially if you are trying to isolate a performance problem.

A subtler approach is to use LAN traffic analyzers (Ethereal or a commercial package) or a specific passive discovery tool like passifist to inventory many of the protocols operating on your LANs, using the broadcast traffic they generate. Broadcast messages are often very revealing sources of information. For example:

  • ARP, DHCP, and routing broadcasts reveal MAC and IP addresses, subnet masks, default gateways, and of course, reachability and routing information. You only need a modest understanding of the routing protocol you operate -- and a good protocol parser --  to construct your network topology from these exchanges and answer the question, "Is the network in production the one I designed?" You can also identify a misconfigured system that's causing routing problems, or a host that is using a duplicate IP or MAC address (the latter merits your immediate attention).
  • NetBIOS/SMB broadcasts reveal server names and addresses, services offered (file and print sharing, terminal services and SQL) and more. Server and service enumeration obtained in this manner help you confirm whether authorized servers are operating as intended. You can also identify unauthorized servers or services in this manner.

  • NOS protocol broadcasts reveal much of what NetBIOS/SMB broadcasts do. Many LANs today are entirely TCP/IP-based, so the mere presence of NOS-related broadcasts can reveal misconfigured systems or rogue applications (clever employees may try to skirt "no gaming" rules by using IPX rather than IP, imagining that no one will notice or worry about non-IP traffic on LANs).

These are but a sample of the insights you can obtain using passive rather than active auditing techniques.

The value of this exercise extends to employee personal computers as well as routers and servers. Use broadcast information you observed during your audit to reduce the risk introduced to your company network by home office and mobile employees. For example, consider an employee who brings an office laptop home and connects to a cable modem, or travels and connects to a broadband or wireless LAN in a hotel or cafe. Few employees actually have home and work profiles for My Network Places, and unfortunately, cable modem and public access WLANs are perilous network neighborhoods. So employees may inadvertently broadcast and reveal information about your company network. Worse, an attacker may gain access to a shared folder and upload an infected file or Trojan horse. Using broadcast information, you can identify laptops that are vulnerable and encourage employees to protect them with personal firewall software or a SOHO firewall (and use this evidence as a means to justify an investment in MUVPN).

Pruning Broadcast Traffic Improves Performance

Loud Howard interrupted everyone's train of thought in the grocery store. On an Ethernet, a broadcast packet interrupts processing at every LAN station. Many people incorrectly conclude that broadcast packets are small so the impact on bandwidth is negligible. The truth is that interrupt and packet processing overhead affects LAN performance most adversely, and the impact grows as you increase LAN rates. Best practices to improve LAN performance begin with optimizing broadcast domains. Accomplish this by using segmentation and switching to reduce the number of LAN stations that must process broadcasts. Next, eliminate superfluous broadcast packets. Analyzing broadcast traffic helps you achieve this objective, and helps you with such nasty, difficult-to-isolate problems as broadcast storms and faulty NICs. If possible, design any custom applications to use multicast rather than broadcast communication (multicast communications are only processed by members of the multicast group).

Conclusion

Examining broadcast traffic is a manageable practice you can apply with simple, easy to obtain tools. If nothing else, it is a wonderful learning exercise. It's important to note that all passive discovery and monitoring methods do not rely exclusively on broadcast traffic. You can learn considerably more about what's happening on your network if you examine "all-cast" traffic (unicast, broadcast, multicast). Many methods for passive mapping, passive IP discovery (e.g., Disco), and network analysis through passive monitoring can be applied. As you might expect, this notion has detractors; some experts don't view passive initiatives impassively. 

But in my opinion, mapping and discovery using more than broadcast packets is best left to automated systems: at today's LAN rates, you had better be prepared to look at LOTS of packets! You can learn enough through broadcast traffic to prune and tune common vulnerabilities and whittle away performance sapping applications, so keep it simple. But -- unless you want to wind up as shunned as Loud Howard -- do pay attention to how loudly your network broadcasts its personal details. ##

Copyright© 2003, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.



Copyright © 1996 - 2003 WatchGuard Technologies, Inc. All rights reserved.