The Usefulness of WEP, Closed ESSIDs, MAC Filtering, and SSH Port Forwarding

This brings us to the topic of enabling WEP, closed ESSIDs, and MAC filtering as protective measures. Such defenses are "bypassable" and after going through the previous chapters of this book, you know how to do it. However, there are still sound reasons to enable these safeguards. One such reason is legal. An attacker who bypasses any of these countermeasures cannot plead ignorance and claim that his or her association with the network was purely accidental. Thus, WEP or closed ESSID can serve as a form of warning saying, "We expect a certain level of privacy on this network; keep your hands off." An organization losing valuable data or assets after a wireless-based attack can be sued for insufficient due diligence if no security safeguards were deployed. However, if baseline countermeasures were implemented, the blame can be shifted somewhere else (manufacturers, standards designers, literature sources claiming that "static WEP is enough," etc.).

Another reason is raising the bar. Penetrating any defenses requires time and effort. Time equals battery power and the higher possibility of being spotted. A large proportion of wireless crackers are the "bandwidth leech" type. They use laptops with preinstalled Windows and Netstumbler to find open wireless networks for a free Internet connection, which they might use to download pornography and warez or send spam. With the system and tools at their disposal, they usually cannot crack WEP, generate custom frames to disclose hidden ESSIDs, or launch Layer 2 man-in-the-middle or DoS attacks. With their knowledge they might not even know how to change the MAC address of their wireless interface. Thus, the baseline safeguards will protect you from this kind of attacker, but never assume that all crackers are this unqualified. At some crucial point it might not be the case.

On the contrary, properly implemented SSH port forwarding can raise the bar by a significant margin. A good idea is to compile your sshd with the TCP Wrappers support and deny all non-SSH traffic on the wireless network while filtering out SSH traffic from unknown IP addresses (don't forget to turn off DHCP). This can be successfully combined with MAC address filtering and static ARP caches where possible. A typical example of SSH port forwarding use is exporting X Window applications via SSH:

Apart from providing data encryption and user authentication, this would preserve the CPU cycles and battery power on the mobile host. Another common example is browsing the Web or shopping online via a proxy on the wireless gateway protecting your browsing session with SSH:

Then set up your browser to use localhost:5777 as the HTTP proxy and you are done (providing that the proxy does listen on port 3128 on the other side). The choice of port 5777 on a local host is completely random, whereas the Squid proxy listens on port 3128 on one of our wireless gateways. If your mobile host is a Windows box, you can use the third-party applications for SSH tunneling. For instance, in PuTTY, do the following:

From the menu on the left side of the Configuration window, select Connection -> SSH -> Tunnels.
Under Add new forwarded port, enter the port number that your computer is going to listen to as the Source port.
For the Destination, enter localhost:5777.
Make sure the Local button is selected and click the Add button.
The newly added port forwarding rule should show up in the Forwarded ports box. If you need to remove the forwarded port, select it and click the Remove button.
Save your changes by going back to the Session page and clicking Save.
Now we have defined the port forwarding tunnel. To make it active, simply log in to the SSH server.

The number of possible examples of SSH port forwarding use is endless and we won't dwell on it any further. Just make sure that you use SSHv2 protocol if you can and your SSH server and clients are up to date and don't have known security holes (or face the possibility of being r00ted by Trinity in years to come). Be as paranoid as we are. We have mentioned that the default ciphers selection in the Linux/etc/ssh/ssh_config is

The reasons behind such advice are revealed in the next chapter, where practically all of the ciphers involved are discussed and compared in detail. Of course, there will be cryptographers who will find our suggestions subjective, but this is expected.

To summarize, SSH port forwarding provides a quick and easy add-on to the traditional weak wireless safeguards such as WEP and MAC filtering. Although for some specific environments this might be sufficient (compare it to the use of protocol filtering, as mentioned in Chapter 8), if you are looking for a more complete wireless security solution above the data link layer, we strongly recommend considering IPSec.