Contents
Contents
Introduction
WirelessAccessControl for the 802.11a/b/g protocols has been a big issue for CommunityWireless networks. Because the physical layer is broadcast over the air you don't have the normal methods of physical control that you do in conventional wired network (ie. making sure that people can't pysically connect a cable to your network).
Like all security it comes down to a personal decision based on what you have at risk and how likely you are to be deliberately attacked. Personally I don't bother securing my AccessPoint at all, but I'm not your average user and lots of people aren't comfortable with my choices:
- I keep the configurations on my computers locked down.
- I keep all my computers up to date with security patches
- Most of my data is encrypted (my email goes over SSL, everything else goes over SSH).
- I don't have much sensitive data (the most sensitive data on my home network is cached email and pictures).
The traditional wireless security option is WEP, and there's been lots of publicity about how it's not secure. WEP is not cryptographically strong and all the tools required to access an AccessPoint secured with only WEP are available for download, however it does require significant effort and knowledge on the part of the attacker to get in. For most purposes WEP is probably an okay choice.
WEP+ or WPA solve the cryptographic problems with WEP. The downside with WEP+/WPA is that it requires support at both the AP and the client card. In my case my AP supports WPA but one of my client cards doesn't so I can't use it.
Finally there is 802.1x, which offers the best security available for your wireless network. Due to the amount of work required to deploy it I'd suggest that it is probably over kill for your home network.
If you what you want is to lock down your AccessPoint as tight as possible, as conveniently as possible, my personaly recommendation would be:
- Disable beacons - This makes it harder for people to "find" your AP.
- Enable MAC filtering - Restrict access to known client cards.
- Enable WEP or WEP+/WPA - This encrypts all wireless traffic.
With all this said, I generally encourage people to leave their AccessPoint open. Community based AccessPoints which share out internet access, local services or data contribute to many of the goals of WirelessCommonsManifesto and can be a great way to get involved and contribute. If you're interested in the growing worldwide CommunityWireless movement get in touch with your local community wireless group.
Security Options
In approximate order of easiest (and least secure) to hardest (and most secure).
Disable Beacons
All 802.11x networks have a name called an ESSID (Extended Service Set ID) which you configure. The ESSID is constantly being broadcast via a beacon frame so that clients can easily find and use the network. The simplist, and least effective, way of securing your wireless network is to disable this beacon. Now, in order for a client to connect to your network they must know the exact name of the network (or use a program like NetStumbler to discover it).
Pros:
- It's very simple and easy to use.
Cons:
Unless you are using an WEP, an unauthorized client can use a WirelessSniffer to discover the ESSID of the network without knowing it.
- It's a shared key system so it won't scale (you have to tell people the ESSID and the only way to disable their access to to change it which breaks everyone's access).
- It provides no encryption of traffic on the network.
MAC Address Filtering
All ethernet, and wireless ethernet, devices have an unique identifying number called a MAC address. Some access points allow you to configure a filter which will only permits certain MAC address to use the network.
Pros:
- It's not a shared key system so it will scale better.
- It's relatively simple.
Cons:
- You manually have to maintain the list of client MAC addresses that can use your wireless network. Depending on how many clients you have this may or may not be an issue.
- It provides no encryption of traffic on the network.
- An unauthorized client can sniff the MAC addresses of authorized clients from the air.
- Many wireless cards allow you to change their MAC adderess with a software tool that comes with the card. Combined with the above flaw this provides a fairly trivial hack.
WEP (Wired Equivalent Privacy)
This is a security method built into the 802.11 protocol. It uses a shared key system, this means that you configure a key (basically a password) into your access point. In order for a wireless client to connect to your network they must know the key and type it into their software.
Pros:
- It's simple and comes with almost all 802.11 cards.
- In addition to providing access control it also provides link encryption which keeps your data safe(er) from people snooping on it.
40 bit WEP is a standard that will work with all WiFi certified cards (which is most of them), many cards also support 104 bit WEP.
Cons:
- Though 40 bit encryption is certainly better then nothing it is not considered safe anymore and is vulnerable to brute force attacks.
- The more secure 104 bit WEP is not a standard and will not work between cards made by different vendors.
- Some people at Berkeley have demonstrated a hack which utilizes flaws in the WEP protocol to break the encryption. Again it's not trivial but it has been proved that it can be done.
It doesn't scale. In a community setting WEP means that if you want to remove access from someone (because you don't like them, they've abused your network or whatever) the only way to do it is to change the shared key. However by doing this you also break everybody else that is using your network. Before they can use your network again you have to contact them and tell them the new key.
Note: WEP+ and WPA are basically the same as WEP only with work arounds for the encryption problems. Basically what they do is force rekeying to occur faster then the minimum amount of time required to gather sufficent entropy to break the key. In short it's an ugly but fairly effective solution.
Captive (or Forced) Portal
While WEP and MAC filtering will probably deter all but the dedicated hacker they still have significant issues when it comes to usability. Neither will scale very well, neither allow for self provisioning via a web page (or any other method) and both have known, and usable, ways around them.
One possible answer to these problems is a CaptivePortal solution. Captive portals (also referred to as forced portals) have been used for a while by vendors like Nortel and Cisco for controlling DSL customers access to the Internet. Basically how they work is by providing connectivity to the client without any authentication (no password or anything), however the client is firewalled at a point so they can't get to anything interesting or useful. As soon as the client trys to connect to a web site they are forced (or captured) to a web site. At the web site they can log in with their username and password, if this authentication is successful then portal connects to the firewall and grants access to the clients IP address.
Pros:
- No client software or configuration is necessary other then sensible defaults (DHCP). This means that everything from a desktop to a palm pilot could potentially use this as a method of getting on the internet.
- Very flexible, the portal can authenticate the client from any type of database (System, LDAP, Radius, SSL Certificates, TACACS, SQL etc).
- The authentication can happen over a SSL protected web site which means that the clients username and password is safe from potential hackers.
- Can provide link encryption (like WEP) between the client and the access point, without a shared key.
- Can differentiate network services on a per user basis. This means that you can say that one client gets full access to the internet, yet another can only use up to 64k of bandwidth.
- Can provide options based on the time of day (eg. anonymous access is only allowed during off peak hours, 9:00am to 5:00pm).
- The portal can potentially provide other services. Bandwidth control, traffic shaping, file serving, email and community web pages are all realistic options.
There are several OpenSource version of PortalSoftware packages do this this already including NoCatAuth.
Cons:
- By using something other then the access point to control access you introduce a new point of failure.
- This would probably run on an computer running one of the free Unixes (most likely Linux, FreeBSD or OpenBSD). These boxes are complicated and can be tricky to fix if/when they break.
- The more features you offer, the more complicated the box. The more complicated the box, the more likely it is to break and the harder it is to fix.
VPN or Proxy
Need to write this ... (RefactorMe)
Pros:
- It's capable of being very secure and providing strong authentication.
- Very flexible, since the service can authenticate the client from any type of database (System, LDAP, Radius, SSL Certificates, TACACS, SQL etc).
- Provides end to end encryption.
Cons:
- It requires client side software which can be difficult to configure and troubleshoot.
- It is quite complicated to setup.
802.1x
This is the truely "secure" option however I've never actually deployed it. Basically 802.1x provides a way of using client side certificates to provide authentication with end to end encryption for wireless networks. By using LDAP/Radius as authentication backends it's possible to create scalable and secure networks. Unfortunately the early implementations of the algorithms had flaws so it wasn't a huge improvement initially.
Pros:
- It is capable of being very secure and providing strong authentication.
- Very flexible, the portal can authenticate the client from any type of database (System, LDAP, Radius, SSL Certificates, TACACS, SQL etc).
Cons:
- It requires client side drivers which aren't yet in wide adoption.
- It's really complicated to setup.
There are no (good?) OpenSource systems to implement it. (FreeRadius?)
This page was originally written for the PersonalTelco wiki.