PRIMER: WiFi sniffers

The high-profile aspect of the Google StreetView / WiFi data-gathering story is the bit we all know about.

Google denies then admits to capturing WiFi payloads when it thought it was looking for SSIDs to help its geo-location efforts; various government bodies around the world launch investigations. In the meanwhile, there are furious arguments about how and why Google got itself into trouble, and the Australian Privacy Commissioner determines that Google’s capture of private information was in breach of privacy law.

There is, however, a second thread to this story that’s received less attention – the role of WiFi “sniffers”, not just in Google, but in the industry at large.

Sniffers aren’t just vital tools for the hack-and-crack crowd. They’re also vital for network professionals. If you want to diagnose the kinds of problems that happen lower down in the protocol stack – the physical layer, for example – then you need to look at things the ordinary user doesn’t see when all they’re interested in is a connection to the LAN.

In general – and without putting forward an entire WiFi 101 course – what you see on a wireless network is only that data that’s addressed to your computer.

That’s because the WiFi interface discards data that doesn’t carry either your address or a broadcast address (meaning “this is for everybody”). The interface finds out what wireless networks are present because access points send a “beacon” – a broadcast that identifies the network, rather like a ham radio operator might announce himself to all the world as “VL2K”.

With the SSID – the “network name” – your WiFi interface now has enough information to try and initiate a connection (it may not succeed: the network might, for example, be encrypted).

A quick heritage of sniffers

The original “snffers” weren’t a generic class of software, but a specific vendor brand of tool that ignored the (wired) Ethernet standard which mandated packets be dropped if they had the “wrong” MAC address. As processing power increased, it was no longer necessary to build a specialist piece of hardware to capture packets from a network, and the class of software known as the sniffer was born.

The basis of the sniffer’s function is the same as ever, though: instead of retaining only those packets whose address allows the receiver to read them, the software sniffer keeps all packets, and hands them up to the host computer to be processed.

If there’s some kind of network problem, the ability to see what’s traversing the network is important. You might find that someone’s workstation is excessively busy, either for an innocent reason like a faulty network interface, or it may indicate an infected machine or a user misusing the business network in some way.

Only, however, if you have access to a shared medium. On a wired Ethernet switch, my workstation no longer sees everybody’s traffic (in fact, it’s probably so long since wired Ethernet was a fully shared medium that most people have never seen a coaxial network cable!).

Wireless Ethernet – the various flavours of WiFi – is a shared medium, and moreover, it’s a subject to a host of problems on the medium itself. The wireless signal may be weak or suffering interference, or there may be too many networks trying to use the same radio channels. Or, of course, a network host may have a problem that’s causing it to dominate the network.

CYA – cover your access!

That potential misuse, which has been there for more than ten years, gained possibly its highest-ever public profile courtesy of the Google StreetView / WiFi story, and therein lies a problem for legitimate users: what if an enthusiastic lawmaker were to start a push to ban tools like sniffers? Moreover, legitimate users also need to protect themselves against accusations that they’ve intruded where they weren’t wanted.

A good start would be for the industry to start formalizing at least a basic view of the “right” way to deploy and use network sniffers.

Tech Target discussed this with Steve Chung, a consultant in the Australian office of US wireless vendor Ruckus Wireless.

It may seem obvious that a network expert is going to use diagnostic tools – but Chung believes network professionals should seek explicit permission to use tools like a sniffer.

“If you’re doing a legitimate service for a client, declare that you’re going to do it – ‘we will do intrusive data gathering’,” he said.

Second, if your work discovers neighbouring networks – and particularly if diagnosing a problem creates a risk that you’ll intrude on someone else’s network – then they also need to know what’s going on.

The third piece of the puzzle, Chung said, is documentation. The network professional needs to make sure that, under accusation, both the activities undertaken and the approval for those activities can be demonstrated.

“Look at Google – that wasn’t the case. It looked bad, because they did not openly say they would be gathering the wireless data.”