Wireless networking has great potential for improving access to services at Rutgers. For this reason, it has been spreading rapidly around the campus. Unfortunately, many implementations are being done without attention to issues of security and authentication. As a result, most wireless networks at Rutgers are set up so that anyone with proper equipment can access the Rutgers network, even from outside the building. Anyone with the proper equipment can also spy on traffic. They can see users' passwords as well as other data. As Rutgers moves more and more services online, the amount of damage that can be done by having unauthorized people who learn passwords of Rutgers users is increasing.
These dangers are not just theoretical. Tools to tap nearby wireless networks are widely available, even for palmtop devices. A whole subculture has sprung up of people going around, scanning for open wireless nodes, and publicizing them to people who want free wireless access.
Note that there are two primary security issues:
- Access - making sure that only authorized people can use the wireless network. Without proper access control anyone in the vicinity of the building can use the wireless network, and thus get access to RUnet.
- Privacy - making sure that no one can watch your communications. Without this, anyone any the vicinity of the building can watch everything you do on a wireless network. This will let them steal your passwords and look at everything you are doing.
You will need to adopt solutions that cover both of these issues. Some of the approaches address only one, other address both. As a quick summary, there are two approaches commonly used at Rutgers:
- WPA or possibly WEP for access control and some level of privacy; supplemented by end to end encryption for privacy
- End to end encryption (typically SSL) for privacy, and special gateway systems for access control
Generally small installations use the first approach with WPA in "personal" mode, and larger ones the second approach. While it is not common at Rutgers, another possible approach for larger installations would be to use WPA in "enterprise" mode. (However there is a significant user support implication to that, because WPA in enterprise mode requires all of your users to have 802.1x supplicant software on their systems and know how to use it.)
This document will present WPA, then end to end encryption, and finally the services appropriate for larger installations. If you are planning to set up something for yourself or a few people in a department, we recommend reading about WPA and end to end encryption.
A few installations use MAC address checks for access control and end to end encryption for privacy. While this probably meets the requirements of the Wireless policy, we do not recommend it. Managing MAC addresses is difficult. It's generally better to use one of the two approaches listed above.
WPA and WEP
WPA and WEP are technologies that "encrypt" the traffic on your network. That is, they scramble it so that an attacker can't make any sense of it. To unscramble it at the other end, all systems using it must know a "key" or password.
Note that WPA is now in a second generation, referred to as WPA2. Unless otherwise specified, this document uses "WPA" to refer to both.
WPA and WEP provide both access control and privacy. Privacy comes from the encryption. Access control comes from the fact that someone must know the password to use your network.
For this reason, for small networks, using WPA is enough to meet the requirements of the Wireless policy. However you will still want to make sure that any services that use a password or other private information use SSL or some other type of end to end encryption.
WEP is significantly less secure than WPA, but can be used until your equipment can be upgraded to support WPA. While WEP is widely regarded as insecure, it is still a lot better than nothing.
WPA has two modes, personal and enterprise. For small installations you'll want to use personal mode. It just requires a password. Enterprise mode is for larger installations, that have a Radius server that will support WPA.
The primary problem with WPA in personal mode is that it has a single password, which you must tell to all users. That becomes impractical for larger installations.
WPA in enterprise mode requires each user to login with their own username and password. That simplifies management in large installations, because you don't have to distribute a common password to all your users. However it is a bit more complex to implement:
- Each user's system must have special software to let the user login to the network. This software is referred to as an "802.1x supplicant".
- The access point must support WPA enterprise mode. The access point is configured to talk to a RADIUS server, which is a central server that actually checks the password.
- You must have a RADIUS server that supports WPA enterprise mode. While the RADIUS server may have its own list of usernames and passwords, it would be more common for it to talk to an LDAP or Active Directory server, so that users login to the network with the same password that they use for other services.
For this reason, most large implementations at Rutgers do not use enterprise mode. Instead they use separate gateway boxes for access control, and depend upon end to end encryption for privacy. One can argue that this is not as secure as WPA enterprise mode, but it avoids the support implications of requiring users to login to the network with an 802.1x supplicant.
Choosing a good password
It is critical to use a good password. There are attacks against WPA that will break your security if your password uses words or any other well-known sequences. WPA allows passwords as long as 63 characters. We strongly recommend using a long random password, or at the very least a long phrase (at least 20 characters, but preferably longer). The phrase should not be taken from any web site or published work. Most software saves the password, so you only need to type it once on each system.
Even better than a long phrase is a truly random password.
WEP "Wireless Equivalent Privacy" was part of the original wireless specifications, so almost all hardware supports it. Unfortunately it is also fairly insecure. Hackers can easily find out the password and then do anything they want with your network. The software for doing this is widely available.
WPA "Wifi Protected Access" is a modified version of WEP, which changes the effective key quite often. It is much more secure than WEP. While there are theoretical attacks, it is currently believed that they are not practical as long as you use a good password .
As of Sept 31, 2003, all new 802.11b and g hardware that is tested for Wi-Fi certification must implement WPA. Thus WPA should now be fairly widely available.
WPA2 is a second-generation implementation, based on new encryption technology. The original WPA used the WEP encryption, improved by frequent key changes. In contrast, WPA2 is based on new encryption technology, the Advanced Encryption Standard (AES). Certification for WPA2 started in September, 2004. As of March 13, 2006, all equipment using the WiFi trademark must be certified for WPA2.
It is possible to mix WPA and WPA2 clients on a single network. As long as the access point supports WPA2 mixed mode, systems that support WPA2 will use AES and older systems will use WPA (except for broadcast or multicast traffic).
Other common precautions
There are two other security precautions available in most wireless hardware:
- MAC address control
- disabling SSID broadcast
MAC address control is a feature -- available on most access points -- that causes the access point only to talk to specific wireless devices. Each device (e.g. the wireless card that you put in your laptop) has a "MAC address" assigned to it. This address should be shown on the card. It will be a 12-digit hex number. Sometimes it is shown with punctuation, e.g. 00:07:50:03:6b:c0. Other times it is simply 12 hex digits, e.g. 000750036bc0. You register this address with the access point. The access point will only talk to cards that are registered.
In my opinion this is not necessary if you are using WPA with reasonably good passwords, at least not if you have just a few users. If you have a large user community, your password is likely to get out. For larger installations, we recommend a gateway box with login controls rather than MAC address control.
"SSID" is the technical term for the network name. You enter this into the access point when you set it up. (Don't leave the name as the default, or you are likely to conflict with other access points in your area. Normally you use your name or some name associated with your department.) Access points normally advertise this name by broadcasting it regularly.
This broadcast is used by people as a starting point to find networks to attack. For that reason, most access points let you turn off broadcast of the SSID. Often this is called making it a "closed network." In theory, closed networks are more secure, because an attacker won't notice them.
However in practice it is probably not a good idea. First, hacker software has other ways of locating closed networks. Anyone who can break WEP or WPA will be using tools that do not depend upon SSID broadcasts.
Second, disabling SSID broadcasts makes it more difficult for other people to set up and manage nearby networks. It's useful to see how many networks are operating on each channel, without having to go to hacker tools.
End to end encryption: SSL, SSH, etc
The approaches described in the previous section all work at the network level. That is, they are based on features of the network cards and access points. This is extremely useful protection, particluarly if you can use WPA or WPA2.
However most security experts believe that encrypting at the network level isn't enough. Thus we strongly urge you to use end to end encryption. In fact our larger installations depend upon end to end encryption, and do not use WPA. (However they then need a separate method to control access.)
End to end encrytion means that the whole conversation is encrypted, from your PC to the service you talking to. The most commonly used end to end encryption is SSL. As long as you are using SSL to talk to a web server, your conversation is private. It doesn't matter whether someone can watch your wireless network. They won't be able to make sense of what they are seeing, because it is encrypted. It is possible to use SSL with other services such as email.
SSH is another common end to end method of encryption. SSH is often used as a replacement for telnet: there are SSH clients that let you log into systems just as telnet would. The difference is that the SSH connection is encrypted. SSH can also be used with other services, such as copying files (a replacement for FTP in many circumstances).
Thus one way to deal with the privacy problem is to make sure that users only use services that are secured with SSL, SSH, or some other encryption technology. In particular, you would need to make sure that any service that requires a password uses encryption.
While possible, this solution is going to require great care. You will need to
- Examine every network service used by your users
- Verify that they can all be accessed using a secure protocol such as SSL and SSH
- Verify that your users have configured their systems to use the secure protocol. (In many cases access is insecure by default -- users need to enable encryption.)
OIT has largely finished this process for its public services. As of July, 2003, all email and web services using the standard Rutgers password must be handled using SSL or SSH.
However if you are going to depend upon end to end encryption, you will need to implement similar precautions for your departmental services, and any other services used by your users.
Using Valid Certificates
If you are going to depend upon end to end encryption, you will need to caution users to pay attention to security warnings. As noted above, it is particularly easy to impersonate a well-known server on a wireless network, or to do what is called a "man in the middle attack." The best protection against this is the fact that SSH and SSL use digital certificates to verify the identify of the server.
Unfortunately the user has to pay attention in order to get the benefits of this protection. If you are talking to a fake server, the user will normally see an error message saying that there is something wrong with the certificate presented by the server. If users commonly click through error messages, they may end up talking to a rogue server. That server can then steal their password. If the rogue server passes the transaction through to the real server, the user may never know that their password has been stolen. More ambitious attacks could steal any information that the user has access to, and even change data on servers.
If we're going to ask users to start paying attention to messages about certificates, this means we are going to have to start using valid certificates on all servers. Currently OIT buys commercial certificates from Verisign or Thawte for our major servers. However experimental or small-scale services may use "self-signed" certificates. These certificates will generate warning messages.
Access control means limiting who can use your network. This is important for two primary reasons:
- If others are using your network, it is likely to be slower for your authorized users.
- The University periodically receives reports of abuse from systems on the network. E.g. someone may be sending spam or threatening email. Those reports will be sent to department that operates the network from which the problem originated. If you don't have any way to limit access to your network, you have no way to know who might have done it, nor any way to prevent reoccurrence.
WPA is intended primarily to protect privacy. However it also provides a reasonable degree of access control, as long as you have few enough users that you can control who has access to the password, or you use WPA in enterprise mode.
For larger installations, we suggest using a wireless gateway, or WPA operating in enterprise mode. Both of these require the user to login before they get access. Both let you use departmental accounts or the Rutgers NetID.
Wireless gateways are boxes placed between the wireless network and the rest of RUNet. They keep track of active users (by MAC address), and require a login for a new user. Normally they use a web interface. They trap attempts to access any web site, and put up a login screen.
Rutgers uses two different types of wireless gateway:
- Bluesocket systems
- Linux systems using special-purpose software, such as the system from the New Brunswick computer science department
Both provide essentialy the same features, although the Bluesocket systems are easier to manage. The OIT campus divisions are prepared to provide Bluesocket-based service to any department that needs it, on a contract basis.
The discussion above has focused on issues that are specific to wireless technology. You also need to make sure that all systems you use have good basic security. If you are using general-purpose systems (e.g. Windows or Linux) in any part of your infrastructure, they need to be hardened. If you are using "appliances" or other sorts of dedicated hardware, look carefully at their security. Do they have any remote management, e.g. a web interface? If so, make sure you change any default passwords, and restrict access as much as possible (e.g. just to workstations from which you will actually be doing management, if this is possible).
These days even access points are "intelligent", so you need to do the same kind of security checks that you would with any other component. Make sure you have complete documentation for all ways to manage your access points.
Many devices, including both access points and appliances, permit management using SNMP (Simple Network Management Protocol). This is a standard protocol for managing a variety of devices. There are common tools for dealing with SNMP devices. SNMP management has both good points and dangers. You can sometimes do things using SNMP that you can't using the vendor's GUI interface. E.g. with some products you can disable SSID broadcasts using SNMP but not with their normal interface. However SNMP is also a security issue: it is often shipped using a default password. When you are changing passwords, make sure you change the SNMP password (often called the "community") as well as the more visible ones. Indeed I would normally disable SNMP unless I'm actually using it.
Unfortunately SSL and SSH are not yet sufficiently widespread that we can be sure all activity is covered by one or the other of them. Another approach is to use VPN ("virtual private network") technology. This creates another layer of networking on top of the wireless network. This layer is encrypted. Because VPNs are implemented in software (at least on the user's end), they are independent of any weaknesses in the network technology, and they can be used with any vendor's network cards. Windows and several other operating systems come with the software needed to use a VPN. However you will need to supply something on the other end.
There are similarities between SSL/SSH and a VPN: both encrypt your communications. The difference is that SSL and SSH are used for individual connections. E.g. when you are talking to a web server using SSL, the specific connection between you and the web server is encrypted using SSL. With a VPN, all of your traffic goes through a single encrypted connection. If every service you talk to supports SSL or SSH, the result is the same.
A typical VPN setup will look like this:
| |*access point user laptop normal | | user laptop dept |--- VPN box -----|*access point user laptop network | | air user laptop | wireless |*access point user laptop | support | user laptop | network |*access point user laptop
The two vertical lines represent wired networks. The one on the left is a normal departmental network, part of RUnet. The one to its right is the wireless support network, a separate wired network or VLAN used just to connect access points. Its only connection to RUnet is through the VPN box. The wireless access points are connected to that wireless support network.
In order to access any system at Rutgers or the Internet, users must first establish a VPN connection to the box. Once the VPN is established, all of their communcations are encrypted. In fact all of their communications go over a single connection to the VPN box. That box then separates out the various connections and sends them to appropriate places within RUnet or the Internet. Because all access to RUnet goes through the VPN box, intruders can't access RUnet.
The VPN box should be configured so that users must establish a VPN from their laptop to it. In the process of establishing the VPN, they need a username and a password. Thus this approach deals with both access and privacy issues. It deals with access issues, because users must specify a username and password in order to establish the VPN. It deals with privacy issues because all traffic is encrypted.
The significant drawbacks to VPNs are
- All users will need to set up VPN software. This may require significant user support.
- There are situations where this approach is probably not practical. The primary one involves guests.
If you take this approach, you need to think about how you will handle guests. E.g. if you host a conference, and attendees expect to use laptops, it may not be practical to get all of them to set up VPN software. You may also have people from other institutions that need to access their home institutions using a corporate firewall. It is normally not practical to use two VPN's at once. So if someone needs to use VPN software to get into their home network, they probably will not be able to use your wireless VPN. For these reasons people implementing this approach should plan on having the ability for selected users to bypass the VPN. However this bypass needs to be controlled so that normal Rutgers users don't use it. Otherwise their passwords will be compromised.
During 2003, OIT implemented wireless networking in a number of locations using hardware from Bluesocket. This hardware was configured to require all connections to use a VPN. Unfortunately, we found that there were serious problems configuring client software to use the VPN's. We have run into endless configuration and compatibility problems. Thus as of late October, 2003, we made VPN use optional. We suspect most users will not enable it. Thus OIT will be relying upon end to end encryption for privacy, and on the login system implemented by the Bluesocket systems for access control.