Slashdot Mirror
A Field Guide To Wireless LANs for Administrators and Power Users
This book starts out an excellent historical overview of the evolution of local area networks and the migration of TCP/IP technology to a wireless environment. In the process, it provides a definitive reference manual on the 802.11 protocol stack, discussing the evolution and future direction of this standard. The issues associated with reliably transmitting data in the very chaotic wireless world are discussed, but the real meat comes in the book's addressing of the logic behind the radio circuitry in WLANs. Along with these insights that an RF engineer will love, the book is a great guide for anyone with protocol analysis tools looking at wireless traffic, especially given the clear illustrations in the text.
Acknowledging the rapid evolution of 802.11 standards over the last few years, an excellent summary is provided, from the venerable 802.11b standard through the -a and -g standards, and moving into future standards being developed by the 802.11 TGs. Maufer provides some key insights on future directions and capabilities of WLANs, too.
The book covers the principal areas of wireless networking, including security, the hot topic for every LAN administrator. While the book does a great job of addressing the theoretical security issues (and other aspects of wireless LANs operation), it is light on practical recommendations in day-to-day WLAN management. The Guide delves into creating strong passwords for use with WLANs, though, and addresses the strengths and weaknesses of the WEP architecture. It is especially rich in providing insights into the handshake and authentication procedures within WEP. A number of proposed security enhancements are discussed, including the deployment of RADIUS servers to provide authentication in enterprise WLANs. In closing on this section, Thomas provides good insights into WPA, which is becoming the future standard to WLAN security.
For a WLAN component designer, this is probably one of the best reference guides available, and this is also true for power users who really want to get under the hood of today's WLAN systems. However, for a network administrator seeking advice on how to address a herd of WLAN devices, my recommendation would be to seek elsewhere. Maufer offers little information about vendors' product types/models, making the detailed technology discussions independent of real-world products. For the administrator able to glean the technical details of their chosen WLAN products elsewhere, though, this book can be an invaluable guide in deciding the pros and cons of a particular product solution.
Along the way, Maufer provides a series of helpful screenshots, as guides to the technical discussions addressed in the various chapters. He provides a very balanced overview in the use of WLAN technologies for Apple, Linux and Windows platforms.
I recommend this Guide as an excellent text, rich in technical details, and protocol/logic illustrations. A "must read" for understanding WLAN technology in depth. With the rapid advances in WLAN technology, this book represents a excellent benchmark on 802.11 technology, from the perspective of its 2004 timeframe, and a sequel from the author would be an excellent additional resource for WLAN system designers and architects.
You can purchase A Field Guide To Wireless LANs for Administrators and Power Users from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
One of the most common methods of protecting a WLAN, that I think is ignored by most people and this text, is not protecting it much at all, but restricting the use so that its unusable for anyone other than an authorized user. You turn on WAP or MAC-Address filtering to make it inconvinient to attach (though since both of these are vulnerable, this is not enough security in itself). Then you only allow access from the WLAN to your corporate VPN servers. Most machines (laptops) that make use of this will already be equipped for corporate VPN access, and so you rely on the security of your VPN in an unsecured (or relatively unsecure) network. Why are we working on all sorts of new standards when a simple combination of available standards will do just as well? Its not like using Radius auth (via SecureID or password) to your VPN is any harder for the user than any of the other suggestions coming out. Truthfully, its easier for IT since you don't have to build new security infrastructure, and you don't have to retrain users.
"Have you wondered about how the magic of wireless networks for PC's happens?"
Duh, it's magic...
Actually with the current WPA using AES or even TKIP along with a radius backend your pretty safe. really paranoid use ttls-eap instaed of peap and authenticate with certificates. Remember the challange of wireless is to make it as secure as the wired network not to solve every security issue.
Consider this:
You threats are minimal, limited to those people close enough to pick up a signal. Real but nothing compared to exposure from the internet.
The encryption is now really good. I am sure someone can break it with enough time but not a serious enough threat to worry. It would be much easier to hop on the wired network and sniff.
Authentication is now good to excellent depending on the protocol you use.
Man in the middle is now impossible as long as you are properly verifying the certificates and keep your CA safe.
Most wireless access that I do and my co-workers do is outside the office. Maybe at a Starbucks, at a hotel, or even at home on my couch. The VPN could secure my data going to my office, but what about the data going elsewhere? What about my POP3 password for my personal email account that I just transmitted through the air? A lot of "road warriors" put way too much trust in to their VPN and connect to insecure wireless networks and do very stupid things. A co-worker of mine was confused when he got an email from someone else at his hotel that had his password to his personal pop3 account in it. He asked me "But the VPN was on, how did they get my password?" And personally, I hate the VPN at my office. It's buggy and it's extremely slow. I'd hate to be forced through it if I wanted to go wireless while I was actually sitting inside my office. If VPN was the answer, new standards wouldn't be coming out... but VPN just doesn't cut it for the majority of wireless users.
Rather than succumbing to the hassle of the various emerging authentication schemes, I've had good luck in convincing my clients to deploy their WiFi networks behind a VPN concentrator. (Or in cases where they wanted WiFi internet access for guests, putting the WiFi outside their firewall, and having the corporate users come in through a VPN concentrator.)
This is a far simpler, and equally secure method.
For those that would die defending it, Freedom
has a sweet taste that the protected will never know.
My belief for securing access points in this day and age is to just make yourself secure enough that the attacker decides that it'd just be easier to look for an unsecured AP. If you have such critical information on your network that you need super-secure wireless access, you probably shouldn't be using wireless in the first place.
Casual war-driving studies have been done in the past, and if I remember correctly, on average 60% of APs that were broadcasting were still in their default out-of-box configuration (no WAP, no MAC filtering, default password for adminstration). If you just enable WAP (please use a good random key generator, folks), and MAC filtering, more than likely it just won't be worth it for somebody to try to break in to access your network.
Also, just in case somebody does break into your AP and does something nasty, this is what the daily logs are for, so enable logging on your AP and back them up to disk regularly. Because, yes, you are responsible what goes through your connection, so you better be able to prove there was unauthorized entry, limiting your liability.
ce n'est pas un Sig.
[...W]e associate our VPN client with a personal firewall, so that when you're VPN-ed in, ALL data flows the VPN to the corporate network before getting out to the internet. So your POP3 password is securely transmitted (over the IPSec tunnel) to the inside, and then goes out from there. Similarly web broswing goes inside, then through our corporate proxy server and then outside.
That's the way to go: Use an encrypted tunnel to work (or home or wherever) and use the site at the other end of the tunnel as your forwarder/proxy for everything.
[...]VPN [rather than other fancy stuff] should [also] be the right answer [for in-building wireless].
Again dead on. In-building wireless doesn't STAY in-building. So treat it like the general internet, put it on the OUTSIDE of your firewall, and secure-tunnel through for access inside.
Option 1: You can treat your APs and the general Internet as TWO separate external nets, both outside your firewall. Then your laptop has to tunnel in and authenticate to make any use of the AP, effectively becoming wired to your lan.
Option 2: You can treat them as ONE outside-the-firewall net, routing packets between them as well as from each to your firewall. Then you become a hot-spot, and visitors (customers, vendors, partners) can also use THEIR laptops to VPN to THEIR private nets (or surf the web B-) ) without having privileges on YOUR local net.
For option 2 you can use WEP as a no-tresspassing sign (post the netname and current password or have them get it from security or their inside contact), set up some other authentication mechanism, or leave your APs open (if you want to do your neighbors a service).
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
A long time ago I was playing Sega Genesis with my friend. He pointed at the console and said "Do you know how that thing works?" I was in CS at the time, but didn't know the specs of this machine, so I said "No." So he informs me, "There's actually a little computer in there."
word.