Wednesday, August 15, 2001

Wireless Ethernet Security

Uh, that's an oxymoron right? Seriously, with all of the security holes found recently in the protocol and the encryption we're having to reconsider how we have wireless 802.11b deployed (fortunately it's a small company with only a handful of wireless users). Most of us have a wireless access point in our houses (and there's not much you can do to that setup); but I'm more concerned with using wireless at the two offices. In the home office setups, these users are using VPN tunnels to get out through the broadband routers and into our network; so their business traffic is already encrypted. The only other thing to do in that setup is to run personal firewalls and antivirus software.

The business environment is both easier and more difficult to secure. I want to switch to requiring wireless users to VPN into the network across the wireless LAN, but I don't want to have the expense of a second dedicated box (with it's own set of firewall rules and VPN rules). So for the past week I've been testing out ideas on my home office network (which is tied in to the rest of the company and I have my own proxy/firewall server).

First up is a diagram of the old network setup. The only security in place was the use of SSIDs and 40bit WEP encryption. Not the best setup, but more secure than the default configuration. We're playing the odds that nobody will target our particular system (especially since the home office is in a residential neighborhood). This is a very standard setup that uses only one public IP address and has a private IP address range (with a DHCP server) setup on the inside of the firewall/proxy server.



Here is my new network profile. Wireless LAN users are required to know the SSID (like before), but WEP has been disabled in preference for using a VPN to connect into the network and get use of internet/intranet resources. I found that the combination of WEP and PPTP was causing the PPTP tunnel to be unstable (sometimes it would just hang and no packets would flow, othertimes it would drop connection). This may just be related to using 3com in the laptop and LinkSys access points.



Throughput speeds with WEP and PPTP both being used topped out around 2.5 or 3.0 Mbps (802.11b is capable of 11Mbps), so there was a noticable performance hit, but I've never measure 802.11b performance in other settings so that may be reasonable performance levels.

The way this works (without requiring additional public IPs, which would expose your laptop users directly to the internet) is to create another private IP address range (such as 192.168.108.0/24). Configure the external port of the firewall/proxy server with both it's normal public IP and an address from the new private IP range (e.g. 192.168.108.1). You'll need to manually configure an IP address on any wireless access points as well (since we're not running DHCP on the public ethernet hub and we don't want to mistakenly grab a public IP off of the ISPs DHCP server), I used 192.168.108.2 and 192.168.108.3 for my access points. Then, you'll need to assign static IPs to the wireless lan interfaces on all of your wireless users (this does make it more difficult for users who go between sites, but you could standardize this). I usually start with .50 and just go right on upwards through the range of addresses. There's no need to configure default gateways on the wireless users.

Now you're treating your wireless users just like the untrusted systems that they have become because they're using 802.11b. All the users have to do is VPN into the private IP of the external port of the firewall proxy (192.168.108.1) and they will have full access to the LAN services as if they were actually connected via a normal ethernet cable. You could also put additional traffic filters in place, just for your wireless users.

posted by Wuphon's at 7:17 AM