It is configuration checking time. Do you know where all your devices are? How do you know that there’s not a rogue device lurking in your network? How do you know that the configuration collection mechanism has discovered all the devices in your network?
I just finished working on a security assessment and on a network baseline. One of the big questions that came up at the start is “how do we know that we haven’t missed a key device? It is relatively easy to perform a manual inventory verification in a small network or a security assessment of a small piece of a larger network. But as the network size increases, these manual processes don’t scale up.
What discovery mechanisms make sense? Obviously, CDP and LLDP are easy candiates as long as they are enabled on the network. Routing protocol neighbors from routing protocols or from the next-hop in routing tables provide data about Layer 3 neighbors. A list of routing neighbors and next hops that are not accessible from the NMS should be investigated.
Another mechanism for finding Layer 3 subnets is to use Netflow. Filter out all the source and destination subnets that are known and investigate any remaining addresses and subnets. Of course, some addresses may be due to spoofed addresses from compromised machines, a good thing to discover during a security assessment so that they can be fixed.
Transparent bridging makes discovery of Layer 2 neighbors more interesting. One approach is to look at the OUI field of the MAC addresses found in the switch forwarding tables. I am not sure that this is a very reliable method because many vendors like HP and Dell now build both networking and end system devices. I like to look for switch ports that are receiving BPDUs, which can be done on Cisco with show spanning-tree int gi 0/1 detail (see example output below). Another Layer 2 indicator is finding switch ports that have multiple MAC addresses associated with them, filtering out Cisco phones with attached computers as necessary. Multiple MAC addresses implies a downstream hub or switch. A MAC address check for OUI on the set of addresses may result in a clue about which device may be a switch. Hubs will be transparent so you may need to visit the site to find out what’s going on there.
The other factor in doing a Layer 2 discovery is finding switch ports that are up/up but have no associated MAC address in the forwarding table, making it difficult to determine what is connected to the port. Such ports may typically be span ports used by IDS/IPS systems. Physical inspection is typically required to determine what is connected to these ports.
-Terry
_____________________________________________________________________________________________
Sample output showing BPDUs sent and received on an interface. See the last line of the output.
SW1#show spanning-tree int gi 0/1 detail Port 1 (GigabitEthernet0/1) of VLAN0010 is designated forwarding Port path cost 4, Port priority 128, Port Identifier 128.1. Designated root has priority 32778, address 0011.5c6b.f580 Designated bridge has priority 32778, address 0011.5c6b.f580 Designated port id is 128.1, designated path cost 0 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 1 The port is in the portfast mode Link type is point-to-point by default BPDU: sent 203410, received 0
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
