Most network admins might have faced a “finding Waldo” situation – where Waldo is an unknown device that sometimes appears in your reports or logs: in your ‘ACL Deny’ logs as using non-business applications, in your NetFlow report as a bandwidth hog, as a problematic server in the cluster, as an unapproved NAS device in your campus, or for some extra drama, as that “forgotten server”. And you have no idea who the user is, where the device is located or to what it is connected.


It is somewhere out there, part of a VLAN with multiple member ports, connected through all those “x, y and z layer switches”, in a daisy chain, and with the Ethernet cables behind the wall! You of course cannot locate such a device by walking around the office and datacenter, looking for that distinctive red and white striped shirt. So, Where’s Waldo?


The Traditional Method :


The first step for the network admin to take on finding an unknown IP Address in his reports or logs is to block it. This is necessary until you find out if the device is safe and approved or not. Though you can block traffic from its IP Address using ACLs, it definitely is not the best solution because it could be an IP could be from your network DHCP range. Due to possible security risks associated with such devices, it is imperative that you find where in the network the device is and the switch port to which it is connected.


The process starts with a ping! Login into your core switch and ping the unknown IP Address. This lets your core switch learn the MAC Address of the device and add an entry about it to its ARP table. You can then do an ARP lookup to find the IP to MAC mapping. The ARP table shows the MAC Address mapped to that IP as well as the port on the switch which points to the MAC address. Find what is connected to the port and if it is another switch, repeat the process till you find the device.


ARP Table.pngIf you happen to have Layer 3 as well as Layer 2 switches in your network, remember that an ARP table is available only on your Layer 3 switch whereas on a Layer 2 switch, you have to look up the MAC Address table. The reason is that an ARP table is used for Layer 3 to Layer 2 mapping which is needed only by a Layer 3 switch. On the other hand, the MAC Address table holds the mapping for Layer 2 to switch port, and that is usually seen on a Layer 2 switch. Once you reach the rogue device going through all the different layers and switches, you know what your action ought to be.


Now, to add a bonus difficulty level to the game –what if you don’t find the unknown device when you search for it in the morning, after seeing its IP Address in the logs? So, Where was Waldo?


The Alternative:


What we discussed is the traditional, widely-used, time-trusted and time consuming method for finding a rogue device from your network. There are alternatives like using scripts that grabs the output of “show arp” or “show mac address-table” from each switch at different time intervals and storing them as logs. Not the best and easiest again.


In an era of advanced threats, data theft and zero day malware, you cannot afford to play the waiting game. As soon as you see an unknown device in the network, you first need to block it from the network by shutting down the port it is connected to. Only then comes the part of trying to find who the device belongs to, whether it was an approved device or not and what was it actually doing in your network. Methods like manual or script based ARP and MAC Address table lookup are neither the fastest nor the easiest solution. And if this device is a bot taking part in a DDoS attack or sending out SPAM emails, you really need to act fast.


This is why network administrators should deploy tools that can help detect unauthorized network devices, shut down ports as soon as you find a rogue device, track suspicious activity or even create a whitelist for trusted devices. With a user device tracking tool for the network, you can be sure of finding unknown devices within minutes. So, There’s Waldo!


To overcome that bonus difficulty level we added, the tool should also be capable of storing history of the device, like where it was connected prior to disappearing. Even more importantly, if you see that the device is wreaking havoc in your network or if you think the device to be suspicious, rather than having to open putty, login into the switch, search the port and then perform the shutdown action from the switch, you should be able to do a remote shut down with a click from the tracking tool. And finally, if the tool can integrate with your DDI solution to help with IP Address management, even better!


UDT-without SW logo.png

Remember to use a tool that is feature rich and meets all your requirements. You not only ensure that an unknown device will not be a hindrance to network uptime, you could also spend some time playing the real game. For more information on protecting your network, take a look at our “Detecting and Preventing Rogue Devices” whitepaper.


 

30 Day Full Feature Trial | Live Product Demo | Product Overview Video | Twitter