By Jeff Orloff
It was the day before the state’s standardized testing day, and I received a call from the assistant principal. At the school district where I was working, standardized testing is done mostly online, so it was certainly bad news when the assistant principal told me that half of the computers in the facility were not working. The school, located in a juvenile detention facility, had about 60 students using computers in eight different rooms with three servers; a domain controller, an application server, and a media server for online courses that the students could take.
When I arrived at the school, one of the teachers showed me the strange problem. The teachers could not access any of the practice tests, retrieve documents, or access data from other network based applications. They could, however, get online and students could access their online courses — but the videos that delivered lectures were lagging.
Rogue Device to Blame
The computers were obviously attached to a network, since they were able to access the Internet. But running the simple IPCONFIG test on the computers showed a Class C network address opposed to the Class A block that was given out to all computers on the district network. Immediately, I thought that somehow our computers were connecting to the detention facility’s network. Checking one of their computers, I noticed that they, too, were using Class A IP addresses. Now I was starting to worry.
Clearly, something was on the network that was acting as a DHCP server. It would have been easy to ask the teachers if they had brought in a device that they shouldn’t have, but by this time everyone was gone for the day with the exception of myself, the administrator, and the one teacher who was helping me out. Using a laptop with RogueChecker installed on it, I was able to connect to the network and immediately find a server that was pushing out addresses to roughly half the campus. Now I just needed to find it.
RogueChecker in action
Using NetStumbler, I was able to look at the IP address of the server with the different wireless access points in the building. Sure enough, the server IP address of the rogue device shown in RogueChecker matched up with one found in NetStumbler. Using the signal strength indicator we could now narrow down our search to one wing of the building.
Identifying Rogue Devices
Sure enough, one of the classrooms had an off-the-shelf brand wireless router plugged into the network jack which was promptly removed. Once all the computers were restarted, we were able to restore access to network folders, data and most importantly the application that would run the assessment for the students the next day.
For a school this size, the process of finding the exact location of the rogue device was not that difficult a task. On a large secondary school, or university, the search would be more problematic and would take the efforts of many more people. In fact, one of the best methods I have seen to handle this task involves crowdsourcing.
The methodology is similar to this case. First the rogue device needs to be verified and then the location narrowed down using technology, generally more than one person searching for the device’s signal. Once you can eliminate a majority of the campus you need to enlist the help of as many willing participants as you can find to help search for the device by assigning each a geographic location that they are responsible for making sure that the assignments overlap as much as possible to ensure nothing is left unturned.