There was a time when the network was flat – everything was interconnected, anyone could access everything and security was not a serious problem. And when security problems began to crop up, options like three-layered hierarchical model, firewalls and Intrusion Detection Systems helped you secure the network. Finally, when you were battling viruses, zero day threats and malware, along came a few technologies that increased your woes – open Wi-Fi networks, telecommuting, BYOD, and the Internet of Things. These technologies helped the “RoDeNt” (Rogue Devices in Network) problem grow in the enterprise.
The adoption of BYOD (Bring Your Own Device) in enterprise networks not only added to the operational and management issues an admin has to deal with, but it has also put a big hole into the wall called network security. While the original idea of BYOD was to allow employees to bring their personal devices to work and use them for increased productivity, the actual practice has been that employees bring their personal devices to work and use them as they wish – for social media, personal and non-business apps, downloads, and even mobile versions of peer-to-peer apps. An even bigger problem with BYOD is what happens to the device after it leaves the enterprise network perimeter. A BYOD user may connect to an open Wi-Fi network on their way home, inadvertently pick up a malware and then bring it into enterprise network the next day, leaving your network vulnerable. If the mobile device is company-approved and you see its IP Address or MAC Address in reports from your monitoring tool, you know who you need to talk to. But BYOD is rarely practiced as it should be – employees quietly share Wi-Fi PSK passwords not only for guest networks but also for enterprise SSID’s.
The rodent problem has always existed and there are numerous examples for when a network admin has been left stranded trying to find out to whom the IP Address he sees in a report belong to – in ACL Deny logs for peer-to-peer app usage, in NetFlow and syslog reports as anomalous traffic behavior,
The first step a network admin needs to do on seeing rogue network devices is to block or remove them from the network. You cannot afford to let the device run free while you try to verify if the device is a security risk or not. There is only one problem here – physical cable traces aren’t possible. When we moved from the flat network model to the hierarchical model and then went on to adopt VPN, MPLS, and more, we also made the network complex. Today, if you see a rogue device in your network you may not have an idea where it is connected to – it could be plugged into a socket whose cables run through the wall, to one of the 48 port Layer 2 switches you have, which in turn is daisy chained with another switch before it connects to a VLAN with multiple member ports set up on a core Layer 3 switch with 3 modules. This really is not an ideal situation for cable tracing! So, let us look at the most widely used solution for such a situation.
How do network admins greet an unknown IP Address? With a ping! And that is what you do here too. You login to your core switch and ping the IP Address you just met. When you ping an unknown IP Address, your core switch tries to reach it and during this process adds an entry for the MAC Address of the device to its ARP table. You then do an ARP lookup and finds the IP to MAC address mapping and the port it is plugged into.
But you will not find a happy rogue device plugged right into your core switch on the port you found in the ARP table. What you most probably will encounter is the Layer 2 switch to which the rogue device is actually connected. So, repeat the process on the next switch and so on until you reach the actual device.
Something you need to remember here is that an ARP table is available only on your Layer 3 switch whereas with a Layer 2 switch, you need to look up the MAC Address table.
The reason is that an ARP table holds the Layer 3 to Layer 2 mapping – only available on a Layer 3 device – whereas the MAC Address table – available on L2 or L3 switches – holds the Layer 2 to switch port mapping. So, after you have gone through multiple layers and switches and find the rogue device, you can block it, unplug it, or maybe even hide it!
But, the time-trusted and time-consuming method we just saw works only when the device is plugged into the network or its MAC address was learned by the network devices. What if the IP address you see appears only in reports and not when you are checking the ARP and MAC tables? That’s a bonus level of difficulty we just added.
An Alternate Solution:
Rogue devices can be the cause of data theft, malwares, viruses, Advance Persistent Threats and even industrial espionage, and so you cannot afford to spend all that time looking up the tables. You need to greet that unknown IP Address with a roundhouse kick and not a ping. The answer lies in deploying a switch port mapping tool similar to what SolarWinds has with User Device Tracker or in the Engineer’s Toolset.
An efficient switch port mapping tool can help detect unauthorized network devices, remotely shut down ports as soon as you find a rogue device, track suspicious activity, store a history of connections and even create a whitelist for trusted devices, all leading to a huge reduction in the MTTR. So the next time you see a network rodent, don’t ping – just click!
Don Thomas Jacob is a Head Geek at SolarWinds, an IT management software provider based in Austin, Texas. He worked as a tech support engineer, product blogger, product evangelist, and tech marketing lead for close to eight years until he joined SolarWinds in 2013. Don’s experience and interests lie in network performance monitoring, security analytics, packet inspection solutions, flow-based technologies like NetFlow, sFlow and IPFIX, and technologies such as QoS, NBAR, IPSLA, and Cisco Medianet and MediaTrace.