 
802 is a registered trademark of the Institute of Electrical and Electronic Engineers, Inc. ( IEEE ). 802.11 Planet is not affiliated with the IEEE
|
By Michael Hall
As with 802.11b in general, the world of wireless LANs as experienced through Linux is an interesting and challenging mix of implementations and approaches. Setting up access to a wireless network in Linux isn't a difficult undertaking to a motivated enthusiast, but it is somewhat complex. In this article, we'll look at some common stops for setting up an 802.11b PCMCIA card on a Linux laptop, provide a general guide to preparing to set up wireless support, and discuss rudimentary ways to secure connections using OpenSSH -- a standard method of providing an encrypted tunnel for common TCP-based protocols. It's important to keep in mind that since support for the assorted families of 802.11b chipsets in use and available off the shelf is varied and handled by different groups of developers in the Linux world, deciding which hardware to purchase isn't quite as simple a matter as it is for Windows users: not all driver implementations are created equal. Also at issue is the depth of support one requires. In our experience, a fairly modern Linux distribution will "do wireless" out of the box, but may not provide support for WEP or other features of a given WLAN. As a result, it's important to track the major projects available fairly closely, since this area of Linux development is still fast-moving. Support for 802.11b Under Linux Taking up wireless networking with Linux is still something of a mixed bag in terms of ease of use and how featureful the provided solutions are. The two most prominent chipsets supported are provided by Lucent and Intersil. The most robust support for wireless PCMCIA under Linux exists for the Lucent Wavelan chipset. These cards are carried under a variety of names, including the popular Orinoco line, and they form the basis of Apple's Airport offerings. The majority of software tools available for configuration and connection monitoring are configured to use Jean Tourrilhes' Wireless Tools (see Resources at the end of this article), a suite of packages that provide basic, textual access to a copious amount of information regarding connection quality, rates, and basic configuration patterns. The tools are designed to integrate easily with the existing Linux PCMCIA configuration scheme, allowing users to build them easily and get up and running with little time invested. A second layer of graphical applications for the popular GNOME and KDE desktops exist that provide more accessible presentation of the information these tools produce in the form of small monitoring applets. Excellent support also exists for the Intersil PrismII chipset, but it's a little more convoluted to get a PrismII card working under Linux and the majority of the graphical front-ends are not built to access or use the information the drivers for these chipsets provide. The home for PrismII support under Linux is maintained by AbsoluteValue Systems, which hosts a variety of e-mail lists and drives development of the linux-wlan project (see Resources at the end of this article), which in turn provides drivers that work with cards provided by LinkSys, Compaq, SMC, Samsung, Nokia, and D-Link, to name a few. In either case, a third factor also exists besides the hardware and the software built for supporting it: support in the Linux kernel for PCMCIA-based cards, which is generally very good (as easy as Windows for some of the more common cards). In order to get full 802.11b support, users will at least need to be aware of which version of the PCMCIA tools their computer has and may have to have a working build of the pcmcia-cs package available on which to base the compilation of their wireless drives. (See Resources at the end of this article for links to the pcmcia-cs project). What we hope to have made clear at this point is that while Linux is fully supported for connections to 802.11b WLANs, it isn't necessarily a plug-n-play proposition. It requires a little time to verify the chipset in use by a given card and matching the appropriate driver project to that hardware. Getting Set Up For Building Wireless Drivers Proper preparation is an important part of setting up any device support under Linux that doesn't come with a generic kernel. As we mentioned earlier, building 802.11b drivers requires coordination between the basic kernel configuration, the pcmcia-cs tools, and the actual drivers for a given wireless card. Step 1: Kernel support Since most users who have built their own kernels are familiar with where they've kept their build trees, we'll leave our discussion of custom-built kernel configurations to this: it's helpful to at least have a link set from the build tree to the /usr/src/ directory. Most of the software involved in building wireless drivers expects to find the directory /usr/src/linux or something similar (some distributors use the complete version of the kernel for naming the source directory: /usr/src/linux-2.4.10, for instance). Systems where the default kernel package is in use are easy enough to set up. On our Red Hat 7.2 laptop, the following packages are installed: kernel-headers-2.4.7-10, kernel-2.4.7-10, and kernel-source-2.4.7-10. We also have the basic kernel pcmcia drivers installed: kernel-pcmcia-cs-3.1.27-10. Finding out which kernel packages are in use on a given Red Hat (or any RPM-based system) can done by issuing the command: rpm -qa|grep kernelwhich queries the RPM database for its entire list of packages and searches for the ones with kernel in their name. Users of other distributions will need to consult the documentation for their distribution's package management tool to learn how to issue similar commands. If the kernel-headers, kernel-source, and kernel-pcmcia-cs packages aren't installed, they can be located on the distribution CDs or via the Internet. RPM-based systems have an excellent resource in the form of RPM Find. In the case of kernel-related packages, it's important to match the distribution the laptop is running exactly: distributors all have different approaches to patching and distributing the kernel. Step 2: pcmcia-cs support The best way to verify which pcmcia-cs package is in use on a given laptop for Red Hat and RPM-based distributions is to simply issue the command: rpm -qa|grep pcmciawhich will return the name of the RPM installed that provides these drivers. Unfortunately, some older Red Hat distributions aren't reported correctly, which causes trouble later down the line. It's helpful to look in the package's documentation directory (usually either /usr/doc or /usr/share/doc) and consult the CHANGES directory to verify the correct version of pcmcia-cs in use on a given system. Once that has been determined, a visit to the pcmcia-cs archive will net the proper version of the package to use. (See Resources, below.) Building these drivers is fairly simple, and we'll repeat our caveat: do not install this package once you've successfully configured and built it, it's only in use to provide headers on which to build the appropriate wireless tools. To build the pcmcia-cs package, unpack the archive in a directory like /usr/local/src, change to the newly created directory, and issue the following command: ./ConfigureNote that the "C" in "Configure" is capitalized, unlike most source packages users will be familiar with. The Configure script will ask for the location of the Linux source directory, which is where either the build tree for the kernel in use or the kernel headers are located. Under Red Hat 7.2, this directory is /usr/src/linux-2.4. Other distributions will vary, and this information should have been discovered during the last step of this guide. The default options provided in the remaining are generally acceptable. Once the Configure script is done discovering the basic system configuration, the pcmcia-cs source is ready to build by issuing the command make allOnce this build completes, you're assured of complete support for installation of whichever Linux drivers are appropriate for 802.11b support on the laptop. Consult the Linux Wireless HOWTO (see Resources, below) to decide on a package to download. In our experience, the bulk of difficulties in setting up wireless support come from making sure the kernel and pcmcia-cs packages are appropriately configured, so installation of a given set of drivers should prove a simple matter of following instructions provided in each package. The pages in the Resources section below provide access to documentation and mailing lists that will address the myriad configuration options that exist for each card and possible configuration. It will also be necessary to learn how access is configured on your local WLAN: factors that play in include whether DHCP is required, and whether WEP is in use. Basic Security for Linux WLAN Clients We're going to skip ahead now, to providing a few tips on securing wireless communications between a Linux client and a given server. As most are aware by now, the WEP encryption provided by vendors for their 802.11b offerings is not bulletproof by any means. Given a suitably active network and a little time, programs like Airsnort (see Resources, below) can easily crack WEP keys, providing intruders the ability to sniff traffic over a WLAN. Trusting the physical layer of a network has never been considered good practice, but with a wireless layer that can effectively extend the "physical" presence of the LAN out to a sidewalk or neighboring building, it's even more important to make sure that services are adequately secured. The immediate implication here is that traditional Linux/Unix services that relied on a modicum of physical security, most notably NFS, are much more dangerous on a network with a wireless component. Consider, for instance, basic NFS configurations, which rely on a combination of IP address and user id to authenticate clients. Viewed as an acceptable risk in a network with reasonable physical security, NFS becomes more problematic. Efforts are underway to tunnel NFS transactions via SSH (see Resources, below), but it's important to remember that a security scheme built on the physical security of a network and WEP simply isn't a security scheme at all in the wireless world. Fortunately, there are ways to provide more security in the form of traffic encryption. As a springboard to further investigation we'll offer a quick example with OpenSSH, the open source implementation of the ssh protocol. Through use of OpenSSH, common network protocols can be routed through an encrypted tunnel, providing a much harder nut to crack for potential intruders. Consider, for instance, accessing SMTP and IMAP server. Under ordinary circumstances, these protocols pass traffic back and forth between server and client unencrypted. An intruder who's already compromised a wireless network can sniff the traffic passed back and forth between client and server with impunity, harvesting passwords and the content of messages with ease. With an ssh tunnel, though, the traffic is encrypted and routed from ssh client to ssh server, making it much harder for the sort of passive attacks that have spread in notoriety. The basic recipe for creating a tunnel between client and server is to decide on an unprivileged port on the client to route a given protocol to, and identification of the remote port the given tunnel should access. Returning to IMAP as an example, for instance, it's possible to create an encrypted tunnel to a given server by opening an X terminal and issuing the following command: ssh -L 1234:imap.server.com:143 imap.server.comThe laptop's IMAP client can then be directed to access its own port 1234, which will, in turn tunnel traffic to port 143 of the machine imap.server.com. This tunnel will stay open until the user terminates the ssh session. Another way to set up a tunnel for a given period of time (much more dangerous if the laptop or client is going to be left unattended) is to fork the ssh session to the background: ssh -f -L 1234:imap.server.com:143 server.imap.com sleep 1hThis directs ssh to open the tunnel, then, once the tunnel is open, issue the command sleep 360, which essentially tells the computer to do nothing for one hour while traffic is passed back and forth over the tunnel. Using the popular Evolution client, and having created this tunnel, under the tools/mailsettings menu, one would set the IMAP host to be localhost:1234. Using the equally popular console-based mutt, placing the following commands in the .muttrc file will create and utilize a tunnel for each connection: set tunnel="ssh -q imap.server.com /usr/sbin/imapd" set preconnect="ssh -f -q -L 1234:imap.server.com:143 imap.server.com sleep 5 This is by no means the be-all and end-all of security or Linux 802.11b clients, but SSH is a flexible and secure way to encrypt many common protocols such as POP3, IMAP, and SMTP. Wrapping Up In this article, we convered the basics of setting up a laptop to build 802.11b drivers and provided a hint of how SSH can be used to secure basic services. Because of the wide variety of possible hardware and software configurations, we avoided a specific discussion of configuration for each package, preferring instead to leave that to the projects themselves, which provide mailing lists and documentation on their own. The Resources section is a collection of the very best starting points for each area we touched on and should fill in the gaps we've left. Resources:
|
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
.gif){kind=small}
