|
|||||||||||
|
[Users] Securing wireless networks through IPsec
From: Per von Zweigbergk <pvz(at)e.kth.se>
Date: Tue Apr 29 2003 - 20:58:56 EDT
Hello. I'm going to be deploying a wireless network. The network isn't going to transport top secret information or anything, but still all the options I have researched have come up lacking in one way or another. After all, the network doesn't really require encryption. What it needs is a good way to authenticate users. I'm going to start from the simplest solution involving wireless networks and work my way upwards to more and more secure solutions. DISCLAIMER: I also must point out that I'm not a cryptographer nor a security expert, but that I've done my best to understand the bigger picture behind network security.
The security features in 802.11b are more of deterrents than anything. First of all, you can set your network to be a "closed network". This makes the base station simply ignore any requests to associate with the network unless the network name is specified explicitly. The security benifits of this setup are completely nonexistent, since the network name is sent in plaintext with every single packet anyway. Then, you can activate MAC address control. While this effectively acts as a deterrent, since the MAC address is simply sent over the air, one can just spoof ones own MAC address in order to gain access. Then you can activate WEP. WEP contains cryptographic weaknesses, that I won't even pretend to understand in detail. I'll however try to express what little I know. It contains numerous problems.
The first two can be overcome, the first by patching the firmware of all stations on the network (I think), the second by not using the vendor-provided applications to hash passwords to hexadecimal hashes, and instead use a better third-party program. The third cannot be overcome to my knowledge, except by rotating keys often enough for initialisation vectors not to be re-used. However, the largest flaw with WEP is its key management. A key leaks, you have to change the key on all systems, and you have no way to track the leaked key. My assessment is that WEP is not an insurmountable barrier to get past for the determined cracker, even at long key lengths. It is in fact also very susceptible to social engineering, especially in large networks. This rules out the access control methods commonly provided by wireless access points. 2. Use software to secure the link further. 2.1. Captive portals Whenever an unauthenticated user attempts to log on to a network, he is presented with a web page asking him to log in to continue using the network. This approach however is, from what I've understood, far from perfect. It's susceptible both to man-in-the-middle attacks, as well as IP hijacking. 2.2. VPN (IPsec tunnels, PPTP, PPPoE, CIPE, PPP over SSH, etc) This seems like a good option. All clients connect to a central server on the network with an encrypted and authenticated connection. However, what about communication between two hosts? Here there are two options. 2.2.1. Use unsecured IP to communicate between hosts on the same subnet This is clearly unacceptable. An intruder may break into a host on the network, and piggyback on it's VPN tunnel in order to get into the trusted network. This places the point of intrusion on any one of perhaps hundreds of laptops, one of which may be running an unpatched version of some software or be backdoored. 2.2.2. Refuse all IP traffic that's not coming through the VPN This is finally becoming acceptable security-wise. But what's happening to the traffic on the network? It's going to the gateway, becoming decrypted, re-encrypted and sent back. This is an unneccecary waste of backbone bandwidth, as well as CPU time on the gateway. (This is the method described in your FAQ from what I've understood.) 2.3 IPsec in "transport mode" rather than tunnels This is what I'm trying to achieve. It has all the advantages of point 2.2.2, as well as fixing the issue with wasted system resources. In transport mode, from what I've understood, the packets are sent as normal using IP without any tunnels, but are encapsulated in order to authenticate and encrypt the packet.
I have found very little information regarding IPsec in transport mode. There are a few issues that have to be ironed out. Is there any software, that together with FreeS/WAN on the Linux gateway, runs on Windows XP and does IPsec in transport mode? Also, in order for this not to become configuration hell, is there any tool to automatically negotiate keys between these hosts? Failing that, it's maybe a special case of opportunistic tunnelling I'm looking for, with one machine per tunnel, but here again the operating system is an issue. Windows XP software supporting FreeS/WAN opportunistic tunneling? I'd also appreciate comments on my analysis above. After all, it could be useful to someone else. Thank you in advance! -- Per von ZweigbergkReceived on Thu May 1 15:24:57 2003 This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 13:01:28 EDT |
||||||||||
|
|||||||||||