Find and Block a Rogue WiFi Device

I manage a small network that uses a router running Tomato firmware to host a guest wireless network on separate VLAN (setup guide). The modest 3000/512 DSL connection is easy to overload but after a recent speed complaint, I started noticing some odd traffic.

On Tomato’s QoS > View Details page, I could see that there was UDP traffic going to and from TLDs all over the world (.au, .ar, .ua, .is, .ru, ..su, .za). Much of the inbound was to port 62416, but it looked like it stopped at the router—that port is not open—so I once I determined it wasn’t a UDP flood, I wasn’t too concerned.

However, a few days later, I noticed something odd:  Tomato’s Bandwidth graph for the Last 24 Hours showed a near-constant outbound of over 300 kbits/second (in blue below), effectively using most of the available upload bandwidth:

I also confirmed on the Bandwidth > Daily page that the router was seeing a sudden 3-6 times increase in total traffic compared to its average of about 1.3GB per day. (That average may actually be high since I rebooted the router not long ago.)

Finding the Rogue Device

So which device is causing this sudden increase in traffic? Tomato’s IP Traffic > Last 24 Hours graph can help find it, but the graph seems to stop working after a while, maybe because there is a limit to the number of devices it can display. Here’s what worked this time:

1. Reboot the router. Under Status > Device List, check which device connects first. In this case, the first unknown device was named 5CD2431DLM and has a MAC address starting with 20:68:9D. That’s made by Lite-On Technology Corp., which unfortunately tells me nothing about what kind of device it is in. It is listed with an IP address on the public WiFi network, so we’re looking for a wireless device.

2. Install Nmap on a computer that is on the WiFi network. The Intense Scan tells me the device is probably running Windows 7/2008:

Port 3389 (RDP) was not open. I tried browsing the network share but failed the authentication challenge.

3. The wireless access points are all fed off a Cisco SG200-08P switch behind the Tomato router. I turned on port mirroring on the switch and used Wireshark to capture some packets to and from the rogue device. There was a lot of UDP traffic and some TCP. I thought this might tell me what the device was trying to do but it was not obvious at first glance. I did confirm IP addresses in foreign countries (Sweden and Australia to name two).

4. Figure out which wireless access point the device is using. I pulled up Tomato’s IP Traffic > Real-Time graph and highlighted the rogue device. I could see active outbound packets. Then I unplugged all the access points from the switch. Sure enough, the bandwidth dropped to zero. Then I plugged the access points back in to the switch until I figured out which one the rogue device was using.

5. Look around for rogue devices in range of the access point. Unplugging a couple of printers didn’t help. Staff devices (phones and tablets) were identified and did not match the rogue device’s IP. Wishing for a gizmo that could physically locate the offending machine by giving a “hot/cold” reading on the source of traffic to/from a particular IP address. Most tools seem designed to find rogue access points, not individual devices.

6. Log in to the Cisco 1130AG access point and drill down to the connected device. The only thing interesting here was that its signal strength was –85 dB, a fairly weak signal.

My hunch is that this means one of the residential neighbors has learned the loosely-kept WiFi password. Unfortunately it seems their computer has some kind of virus that is phoning home to servers all over the world, and chewing up the client’s limited bandwidth in the process. (In later analysis, I found some BitTorrent packets in the Wireshark capture, so this may have been “normal” BitTorrent traffic, but it was still not welcome on this network.)

7. Oddly, Tomato does not seem to have a way to block a device from receiving a DHCP lease. Adding a block under Basic > Wireless Filter doesn’t help, because we’re not using the wireless in the router; we’re using access points. The best I could do is go to Access Restriction and add a full-time block on the the rogue MAC address:

This blocks Internet access, which solves the main issue (bandwidth use). However the rogue device is still attached to the WiFi network, which I’m not too keen on. We may wind up changing the WiFi password.