In my last post I discussed the problems with deploying WPA in an enterprise environment. Let’s back up a bit and list why we secure wireless networks:

• Permitting uncontrolled access can lead to compromise
• Authentication is required to verify the person connecting in
• Data can be sniffed so encryption is needed for data privacy

Pretty straight forward reasoning, but now stop and consider why we secure remote users when they connect in from the Internet:

• Permitting uncontrolled access can lead to compromise
• Authentication is required to verify the person connecting in
• Data can be sniffed so encryption is needed for data privacy

Note the reasons are the same. I’m big on root cause analysis, and the reason so many of us jump though hoops with WPA is that we’re trying to fit a square peg into a round hole. In other words, rather than recognize that a wireless signal is a separate uncontrolled entity, we try really hard to slap on a quick fix so it can be trusted at the same level as the wired segments secured behind our office walls. Not a surprise really, given that the first protocol we were given to secure wireless was called the Wired Equivalent Privacy (WEP) protocol. Needless to say the name directly implies that wireless can be made to be as secure as a wired switch port. History has shown, and continues to show otherwise however.

Consider the network drawing in Figure #1. Note that we have reconfigured the network to better address the root cause problems with wireless. Wireless is no longer considered as trustworthy as a wired switch port. Its treated in a similar fashion to its closest matching security zone, the Internet. We simply hang our access points off of another firewall port and apply a similar security posture.

So when someone connects to the access point, what happens? The connection is made in the clear with no security enabled. Simply connect to the proper SSID and go. The local DHCP server then hands the system an IP address. At this point our setup acts like any other non-secured network.

Look what a wireless system gets access to however. Through the firewall, the only permitted point of access is the VPN gateway. This is the same as when the user connects in from the Internet. So rather than having to trust a single security implementation (WPA) with its single choice for data privacy (AES), you can deploy what ever you feel is appropriate. The robustness and flexibility of SSH, SSL and IPSec all become possibilities for securing your datastream. While each solution supports AES for data privacy, they open up a plethora of other, some feel better, options like Blowfish and Twofish.

But wait, couldn’t an attacker connect to my access point and go after the laptops that are connecting in? Absolutely. Again, this zone has the same security level as the Internet so the same rules apply. Think about your typical wireless user however. They tend to be road warriors, who also connect in from the Internet. This means their system should already have the required VPN software and a personal firewall system. So if the laptop is configured to connect in from the Internet, its ready to go in this wireless configuration as well.

One of the things I really like about this configuration is that it not only reduces back end administration (no more WPA management), but help desk support time as well. Users just want their laptop to work and are more effective when they can follow a consistent process. When we tell them “Perform steps A, then B, then C to connect in from the Internet, but steps D, then E then F if you are at the office”, some will inevitability become confused. With the setup above they always follow the same connection process, regardless of physical location.

Since no security solution is ever perfect, there has to be some down sides, right? First, we are putting a slightly higher load on the firewall. Internal communications between a wireless system and a server would normally not involve the firewall, but now it does. This problem could easily be resolved with a second firewall however.

The second issue is security related but is dependent on how we deploy the above configuration. In an ideal world all access points would be connected to a single isolated switch. Reality in a large environment however might necessitate the use of VLANs because the access points are geographically dispersed from each other. The use of VLANs opens up the possibility of VLAN hopping. While this author does not think an attacker could mess with DTP through an access point in order to gain access to the trunk, its certainly possible from a directly connected system so eventually someone smarter than I may figure it out. In short, remember that this security zone has the same trust level as the Internet and handle it accordingly. Shut off DTP or any other auto VLAN negotiation capability the vendor has turned on by default.

Finally, rogue access points are still an issue. This solution does nothing to stop an end user from bringing in an access point from home and plugging it in. You still need to keep a watchful eye for this activity. About the only thing this solution does for you is now you know any access point plugged into the wired network is rogue and needs to be addressed.

Hope this is helpful!

C

Related posts:

1. Eliminating The Need For WPA In The Enterprise – Part 1

• Previous Entry: Eliminating The Need For WPA In The Enterprise – Part 1
• Next Entry: Why Firewall Reject Rules Are Better Than Firewall Drop Rules