George Ou of ZDNet reports that the 802.1X authentication techniques used on some Wi-Fi handsets may be vulnerable. The problem is that these handsets may not validate the certificate from the authentication server. This design choice speeds up roaming, but means that the handset could disclose user login credentials to a sophisticated, determined attacker. Ou suggests using WPA-PSK with a long password instead of 802.1X with these handsets.
Vocera’s documentation, which Ou references, has more depth on the performance trade-offs of various Wi-Fi security options.
QoS metrics are important, and several companies have products that measure packet loss, jitter, latency and so on. But you can have perfect QoS, and your VoIP system can still be defective for all sorts of reasons.
I spoke with Gurmeet Lamba, VP of Engineering, at Clarus Systems at the Internet Telephony Expo this week. He said that even if a VoIP system is perfectly configured on installation, it can decay over time to the point of unusability. Routers go down and are brought up again with minor misconfigurations; moves, adds and changes accumulate bad settings and policy violations.
VoIP systems are rarely configured perfectly even on installation. For example, IP phones have built-in switches so you can plug your PC into your desk phone. Those ports are unlocked by default. But some phones are installed in public areas like lobbies. It’s easy for installers to forget to lock those ports, so anybody sitting in the lobby can plug their laptop into the LAN. There are numerous common errors of this kind. Clarus has an interesting product that actively and passively tests for them; it monitors policy compliance and triggers alarms on policy violations.
Clarus uses CTI to do active testing of your VoIP system, looking for badly configured devices and network bottlenecks. Currently it works only on Cisco voice networks, but Clarus plans to support other manufacturers.
Clarus started out focusing on automated testing of latency, jitter and packet loss for IP phone systems. It went on to add help desk support with remote control of handsets, and the ability to roll back phone settings to known good configurations.
The next step was to add “Business Information,” certifying deployment configurations, and helping to manage ongoing operations with change management and vulnerability reports. Clarus’ most recent announcement added passive monitoring based on a policy-based rules engine.
Clarus claims to have tested over 350 thousand endpoints to date. It has partners that offer network monitoring services.
Instat published a report today, predicting that corporate spending on wireless voice and data services will outstrip spending on wireline services by 2010. The report is pitched at service providers, pointing out that corporate users are more profitable. Of course some service providers, like Sotto, already pin their strategy on this. The report also encourages corporations to unify their wireless spending, rather than have employees get their service piecemeal and expense it. I wrote about this in an earlier posting.
As cell phones get smarter and as they get more tightly bound into corporate networks, security becomes a major concern. This is the subject of two stories in today’s Wall Street Journal. The first tells how the iPhone is precipitating a standoff between IT managers who don’t want it on their networks, and users who want to use it as a corporate email client. The second explains how iPods, iPhones and any device with storage and a USB connector constitute network security threats.
My May column in Internet Telephony Magazine is about the Jericho Forum, which proposes a radical solution to the security concerns of the wireless enterprise.
Ray Naraine talks about exploits on Wi-Fi networks, how easy they are, first with a tool called Silica, then with free software running on a Nokia N800.
Exploits of this type can be prevented by elementary network hygiene, using the authentication and encryption techniques of 802.11i.
A different kind of vulnerability has been described by “Johnny Cache.” This type of vulnerability is more insidious.
In lab tests it has been possible for a device masquerading as an access point to respond to probe frames (which must always be sent in the clear before any authentication can take place) with a mal-formed packet that causes a buffer overrun in the computer that is looking for a network. Because these buffer overruns are in the 802.11 driver they can be designed to execute hostile code in kernel mode.
Of course this type of vulnerability is specific to particular implementations of the Wi-Fi driver, and all the reported ones have been fixed. More reassuring, there is no reported case of this type of exploit actually being done in the wild. But the principle remains that a badly written network driver can compromise your security regardless of the higher level measures you take, and that wireless networks are more vulnerable to this type of exploit than wired.
So, is Wi-Fi too insecure for corporate use? Neither of the two classes of vulnerability discussed here seem to be stoppers. The Naraine exploits are addressed by simple common sense; the known driver vulnerabilities were repaired before anybody exploited them in the wild. There are almost certainly more like that waiting to be found, but on the scale of risks, this has so far ranked low compared to the many widely publicized instances of physical theft of a laptop.