The Linux Letter: Linux Unplugged

Linux / Open Source
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

There is no doubt that the siren song of wireless networks is becoming louder and more compelling as the maximum data rates climb. While the current breed of wireless can't as yet hold a candle to the data rates of a wired network, many users find trading speed for mobility an acceptable exchange.

If you're like me, you probably cringe at the thought of introducing wireless into your network. With all of the security issues that you have to manage with a wired network, it seems masochistic to introduce a technology that is infamous for security breaches. (Ask any technologically inclined teenager what "war driving" is.) One thing is certain, though. If your users want wireless and you don't provide it, they will. And they won't be doing so with network security in mind. Instead, they'll be using whatever they purchase at the local office supply store, which, by default, will be open access points, broadcasting ESSIDs like "Linksys" and "Belkin" to the world. They may not even take the time to enable the minimal security provided by Wired Equivalent Privacy (WEP) encryption.

Like it or not, you fall into one of two categories: those who already have adopted wireless technology or those who will. If you're in the latter category, you may want to look at a Linux-based solution.

It's Abysmal

Before bringing up the topic of wireless security, I do need to report the current state of wireless technology support in Linux. In a word, it's abysmal—at least when measured against the standard set by wireless support in Windows. It's not that way because Linux software developers don't have the talent to support wireless—far from it. Wireless support is lacking because the manufacturers of the networking cards are loathe to release the specifications for their hardware, thus making the task of writing a driver difficult.

Hardware manufacturers cite two primary reasons for withholding the information. The first is the standard disclaimer used by companies: that the information would expose trade secrets. I might actually buy this excuse were it not for the fact that anyone who wants those trade secrets can certainly disassemble any binary-only driver and discern the inner workings of the hardware it supports, legalities notwithstanding. Besides, the companies could follow the path blazed by graphics card manufacturers such as ATI and nVidia, who provide binary drivers that use GPLed hooks into the Linux kernel to give excellent support for their products.

The second reason is based on the fact that the frequencies on which wireless networking operates and the power output permitted the devices is governed in the United States by the FCC. Worldwide, there are more channels available than what is permissible in the U.S., so manufacturers limit radiated power and channels through their drivers. They argue that by releasing the technical details of their hardware to the open-source community, they expose themselves to possible legal problems should their hardware be operated outside the limitations imposed by the FCC. To me, this reason seems more plausible, albeit tenuous, but I'll give that one to them.

Suffice it to say that Linux support for wireless is spotty. Cards with readily available specifications are well-supported. Cards with scant information will require special voodoo to make them work, and sometimes no amount of chicken sacrifices will coax them to life. You can do a quick Google search on "Linux" and your card model number to see if the card you possess or are considering is supported.

Despite my gloomy report of Linux wireless support, I urge you not to give up on a Linux solution for your wireless needs. The support (or lack thereof) for wireless doesn't necessarily have to negatively affect your ability to employ the great networking features of the Linux kernel, as we shall soon see.

Seamless Transition

Configuring a wireless network for security is really not all that different from configuring a wired network for security. You want some kind of access control to the inbound network connection, and you want the data that traverses the wire (or in this case, the ether) to be encrypted. Those inexpensive wireless routers and access points accomplish this via Wi-Fi Protected Access (WPA) or WEP encryption. You configure your router with a given key and provide to any clients that key and the ESSID you are using for your router. When clients attempt to connect, the key they present will be used for validation and subsequent encryption. Of the two, WEP is older and less secure yet more compatible with Linux because the WEP-only cards are older and better supported. WPA is a relative newcomer that allegedly offers better security than WEP. Beyond that, high-end wireless gear can offer even more sophisticated authentication and encryption than the mass-market stuff, assuming that your budget can withstand the onslaught.

If you apply your knowledge of wired network security (with special regard to the security you apply at your borders) to a wireless network, you'll find that there is very little you need to change to adapt to wireless. The characteristics of a wireless network make it just as untrustworthy as your connection to the Internet, and if you treat it the same, you'll find the transition seamless. In other words, consider the wireless connection to be equivalent to the Internet, and suddenly all of what you already know about security is directly applicable.

Do you have road warriors in your company? Do they connect via IPSec or another VPN solution from their hotel room to your company's network? They can just as easily do that over a wireless network as they can over the wired version (and in some hotels, they are using a wireless network). All of the security measures that you provide for these travelers are applicable to your own internal wireless networks. The trick is to envision your wireless connections as coming from outside your fortified walls, in spite of the fact that the connection may be originating from the office next to yours.

The $100 Solution

While Linux may not directly support many of the wireless cards, it does have superb networking capabilities. How do we take advantage of them? The answer is surprisingly easy and straightforward. You can do your homework and pick a wireless network card that is well-supported, you can delegate the task of managing the wireless connection to a device that was built for the purpose (a wireless access point), or you can purchase a wireless router that is capable of hosting a custom Linux configuration, such as the Linksys WRT54GL.

For the first two suggestions, you need an installation of Linux that has been configured especially for this duty. All the box needs to provide is a DHCP server so that clients can be assigned an IP address, an appropriately tuned firewall/router, and a VPN server (unless you want to route this traffic to another internal server configured for this purpose). Creating an instance of Linux for this is straightforward, but if you want a turnkey solution, you can turn to one of the firewall Linux distributions, such as IPCop. Whether you use a wireless access point or a Linux-supported wireless card in the Linux box itself is irrelevant; the results are the same. I tend toward using wireless access points for two reasons: 1) I don't have to spend huge amounts of time trying to research which of the currently available PCI wireless cards are supported, and 2) I can actually hook multiple access points to the Linux box via a switch. This makes it easy to provide wireless access in multiple areas yet have only one box to administer.

Another interesting solution is to combine the aforementioned Linksys wireless router with a copy of Sveasoft's drop-in firmware. In this scenario, we have what amounts to an appliance; it's physically smaller than what you'd get with a PC-based solution and costs around $100 yet provides the same features available in hardware costing so much more. I have employed this solution in a couple of client locations with great success—even where no wireless access was desired. The firmware makes it easy to disable the wireless interface, so what you end up with is an excellent little firewall/router/VPN server at minimal cost. The only downside is that you have a greater administrative burden should you need to deploy more than one of these in your network.

No Worse Off

When I first started considering wireless, I evaluated the threats I'd be introducing and came to the conclusion that, with the right configuration, I'd be no worse off from a security standpoint than I am by providing inbound access through my Internet connection. The threats are all the same. The only major difference is that I have a much more difficult time keeping people from eavesdropping on a wireless connection than I have on a wired connection. As a result, I have almost completely given up on the modicum of security provided by WEP/WPA encryption and have, instead, decided to redirect the burden of security back onto the Linux box I built for the purpose. While I don't run an open wireless access point (I have to make it a bit sporting for the war drivers, after all), I really could. Connecting to one of my access points isn't going to get you anywhere other than to the interface of my Linux box, and that's no more dangerous than having access to my wired firewall interface. Should the war drivers collect enough packets to deduce my encryption key, they'll only find themselves looking at the encrypted data stream provided by my VPN solution, just like anyone who managed to sniff wire-bound packets on the Internet would.

All That You Need

If you need to provide wireless access to your networks, I recommend you look at a Linux-powered solution. The cost can be significantly less than the cost of a proprietary solution, and it might provide a better fit for your company's needs as well. While Linux may not provide the latest bells and whistles that the expensive, proprietary solutions provide (e.g., hardware keys or biometrics), it may be all that you need to keep the gang in accounting from taking matters into their own hands.

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

BLOG COMMENTS POWERED BY DISQUS