Securing Wireless Networks

Abhishek Kant, had recently visited Pune. We were discussin about WiFi Security. He said he was lookin forward to session on those.. So here is my blog dedicated to Abhishek

IEEE 802.11b, also known as the "Wi-Fi Standard," is an 11-megabit Ethernet-compatible, wireless network technology (http://standards.ieee.org/getieee802/). Early on, its developers acknowledged security issues with Wi-Fi and came up with Wired Equivalency Privacy (WEP) to make wireless LANs as secure as wired ones. WEP, however, is not without its problems. Through passive and active attacks, for instance, WEP can allow unauthorized use of wireless networks and real-time decryption of traffic on wireless networks. This presents a threat, especially in metropolitan areas with dense proliferation of wireless networks.

It comes as no surprise that there are a number of available techniques to exploit WEP's deficiencies. On the upside, however, these same techniques also let you test wireless networks. One such technique for securing wireless networks using a combination of hardware and the Free Secure Wide Area Network (FreeS/WAN), a freely available IPsec implementation for Linux that integrates with the IPsec functionality built into Windows
(http://www.freeswan.org/).

This technique lets you completely disable WEP (which you should for performance reasons anyway), so that all packets transmitted over the wireless network are encrypted using the secure IPsec protocol (http://www.ietf.org/rfc/rfc2401.txt). IPsec is a protocol for securing IP traffic at a low level—layer 3 of the OSI network model (http://www.netc.org/network_guide/c.html). IPsec is required in IPv6 (the new version of the TCP/IP Standard) and optional in IPv4 (the current Standard on which the Internet runs).

All this underscores an important point: The wireless access point is the wrong place to secure the wireless network. Not only do algorithmic flaws make WEP ineffective, but the concept itself is lacking. When you can have someone (potentially) miles away examining your network packets, there is no possibility of "wired equivalency." The solution to such problems is to assume that wireless traffic is inherently insecure, then use tried-and-true techniques for securing these insecure networks.


Because IPsec operates at a low level in the protocol stack, it can protect almost any type of traffic that has IP at its base—basically all the traffic on the Internet. Strong higher layer security protocols (such as SSH and SSL) require special configurations or applications that explicitly support them. The Opera browser, for instance, does not explicitly support IPsec. However, if an IPsec connection has been established, all traffic generated by the Opera browser traveling on that connection would automatically be encrypted.

The IPsec Standard has three protocols:

1. Internet Key Exchange (IKE) negotiates connections and is responsible for exchanging keys.
2. Authentication Header (AH) provides packet-level authentication once a secure connection has been established.
3. Encapsulating Security Payload (ESP) is used for encryption/authentication.

FreeS/WAN implements IPsec through: KLIPS (kernel IPsec), which handles AH and ESP within the kernel; Pluto, which handles IKE; and various scripts to administer the system. FreeS/WAN extends the IPsec Standard to include an operational mode called "opportunistic encryption," in which all traffic between two gateways is automatically and seamlessly encrypted. One of the goals of the FreeS/WAN project is to have this extension integrated into the Standard. Opportunistic encryption uses public keys embedded in DNS records to automatically enable IPsec connections.

Technically speaking, two machines involved in an IPsec negotiation are both client and server at different stages of the connection. In terms of FreeS/WAN, a client is a machine that wants to establish a secure connection, while a security gateway is one to which the client connects. Both the client and the security gateway run the same software and have similar configurations.

Once you've installed FreeS/WAN (per the documentation), you need to configure it. Setting up an IPsec tunnel between two machines requires that they authenticate to each other. By default, FreeS/WAN uses public-key authentication with RSA. FreeS/WAN supports other authentication methods, including X.509 certificates with a patch.

Machines that want to establish IPsec connections must have each other's public keys. The client machine uses the security gateway's public key for authentication and the security gateway uses the client's public key for authentication. Ordinarily, key exchange is tricky when establishing secure communications between machines. In this case, it is more straightforward because everything is happening locally. If you're paranoid, put the public keys on floppy disks and walk them between the machines.

The client and security gateway machines need to have key pairs generated and exchange public keys. To generate a key pair from scratch, issue the command (on each machine): ipsec newhostkey --output /etc/ipsec.secrets. Be careful when using this command; if an ipsec.secrets file already exists, it appends another set of keys that causes confusion with other IPsec commands. (The documentation shows the command differently: ipsec newhostkey > /etc/ipsec.secrets. This is an older style of the command line and doesn't work with the recent versions.)

Next, extract and exchange the public key on each machine. When establishing an IPsec connection, FreeS/WAN needs to know which participant is left and which is right. The choice is arbitrary, but must be configured consistently. To extract the public key for the security gateway, execute ipsec showhostkey --right > SecGW.txt on the security gateway machine. To extract the public key for the client, execute ipsec showhostkey --left > Client.txt on the client machine

All traffic between individual nodes is encrypted using the IPsec protocol. Only authorized machines can establish IPsec connections because a client and security gateway need each other's public keys in their configuration files.