Calling All Devices – What’s on the network?

Author
Terry Slattery
Principal Architect

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

infoblox-logo

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.