It is rather tempting to say that on BSD, and OpenBSD in particular, there’s no need to “make wireless networking easy,” because it already is. Getting a wireless network running is not very different from getting a wired one up and running, but there are some issues that turn up simply because we are dealing with radio waves and not wires. We will look briefly at some of the issues before moving on to the practical steps involved in creating a usable setup.
Once we have covered the basics of getting a wireless network up and running, we’ll turn to some of the options for making your wireless network more interesting and harder to break.
Setting up any network interface, in principle, is a two-step process: you establish a link, and then you move on to configuring the interface for TCP/IP traffic.
In the case of wired Ethernet-type interfaces, establishing the link usually consists of plugging in a cable and seeing the link indicator light up. However, some interfaces require extra steps. Networking over dial-up connections, for example, requires telephony steps such as dialing a number to get a carrier signal.
In the case of IEEE 802.11-style wireless networks, getting the carrier signal involves quite a few steps at the lowest level. First, you need to select the proper channel in the assigned frequency spectrum. Once you find a signal, you need to set a few link-level network identification parameters. Finally, if the station you want to link to uses some form of link-level encryption, you need to set the correct kind and probably negotiate some additional parameters.
Fortunately, on BSD systems, all configuration of wireless network devices happens via ifconfig commands and options, as with any other network interface.[19] Still, since we are introducing wireless networks here, we need to look at security at various levels in the networking stack from this new perspective.
There are basically three kinds of popular and simple IEEE 802.11 security mechanisms, and we will discuss them briefly over the next sections.
Note
For a more complete overview of issues surrounding security in wireless networks, see Professor Kjell Jørgen Hole’s articles and slides at http://www.kjhole.com/ and http://www.kjhole.com/Standards/WiFi/WiFiDownloads.html. For fresh developments in the Wi-Fi field, the Wi-Fi Net News site (http://wifinetnews.com/archives/cat_security.html) and The Unofficial 802.11 Security Web Page (http://www.drizzle.com/~aboba/IEEE/) are highly recommended.
The short version of the story about PF and MAC address filtering is that we don’t do it.
A number of consumer-grade, off-the-shelf wireless access points offer MAC address filtering, but contrary to common belief, they don’t really add much security. The marketing succeeds largely because most consumers are unaware that it’s possible to change the MAC address of essentially any wireless network adapter on the market today.[20]
Note
If you really want to try MAC address filtering, you could look into using the bridge(4) facility and the MAC filtering features offered by brconfig(8) (on OpenBSD 4.6 and earlier) or the bridge-related rule options in ifconfig(8) (OpenBSD 4.7 and later). We’ll look at bridges and some of the more useful ways to use them with packet filtering in Chapter 5.
One consequence of using radio waves instead of wires to move data is that it is comparatively easy for outsiders to capture data in transit over radio waves. The designers of the 802.11 family of wireless network standards seem to have been aware of this fact, and they came up with a solution that they went on to market under the name Wired Equivalent Privacy, or WEP.
Unfortunately, the WEP designers came up with their wired equivalent encryption without actually reading up on recent research or consulting active researchers in the field. So, the link-level encryption scheme they recommended is considered a pretty primitive homebrew among cryptography professionals. It was no great surprise when WEP encryption was reverse-engineered and cracked within a few months after the first products were released.
Even though you can download free tools to descramble WEP-encoded traffic in a matter of minutes, for a variety of reasons, WEP is still widely supported and used. Essentially, all IEEE 802.11 equipment available today has support for at least WEP, and a surprising number offer MAC address filtering, too.
You should consider network traffic protected only by WEP to be just marginally more secure than data broadcast in the clear. Then again, the token effort needed to crack into a WEP network may be sufficient to deter lazy and unsophisticated attackers.
It dawned on the 802.11 designers fairly quickly that their WEP system was not quite what it was cracked up to be, so they came up with a revised and slightly more comprehensive solution called Wi-Fi Protected Access, or WPA.
WPA looks better than WEP, at least on paper, but the specification is complicated enough that its widespread implementation was delayed. In addition, WPA has attracted its share of criticism over design issues and bugs. Combined with the familiar issues of access to documentation and hardware, free software support varies. Most free systems have WPA support, but you may find that it is not available for all devices. If your project specification includes WPA, look carefully at your operating system and driver documentation.
And, of course, it goes almost without saying that you will need further security measures, such as SSH or SSL encryption, to maintain any significant level of confidentiality for your data stream.
Picking the right hardware is not necessarily a daunting task. On a BSD system, the following simple command is all you need to enter to see a listing of all manual pages with the word wireless in their subject lines.[21]
$ apropos wirelessEven on a freshly installed system, this command will give you a complete list of all wireless network drivers available in the operating system.
The next step is to read the driver manual pages and compare the lists of compatible devices with what is available as parts or built into the systems you are considering. Take some time to think through your specific requirements. For test purposes, low-end rum or ural USB dongles will work. Later, when you are about to build a more permanent infrastructure, you may want to look into higher-end gear. You may also want to read Appendix B of this book.
[19] On some systems, the older, device-specific programs such as wicontrol and ancontrol are still around, but for the most part, they are deprecated and in the process of being replaced with ifconfig functionality. On OpenBSD, the consolidation into ifconfig has been completed.
[20] A quick man page lookup on OpenBSD will tell you that the command to change the MAC address for the interface rum0 is simply ifconfig rum0 lladdr 00:ba:ad:f0:0d:11.
[21] In addition, it is possible to look up man pages on the Web. Check http://www.openbsd.org/ and the other project websites. They offer keyword-based man page searching.