Connecting to a wireless network puts your computer at risk. Eavesdroppers may intercept traffic sent between client stations and the access point. Malicious access points may attempt to force associations in order to perform man-in-the-middle attacks. Hackers using the same access point may try to exploit your computer. Due to the shared, physically unsecured nature of an 802.11 network, client stations are more likely to be the target of an attack.
Establishing proper security on stations connecting to a wireless network is the first step to creating a secure wireless infrastructure. The security of an entire infrastructure is like a chain; it is only as secure as its weakest link. Typically, wireless stations are laptops or workstations controlled by an individual, not by a team of security professionals. These stations may not be under the same scrutiny as a fileserver or firewall would be. Unfortunately, an unsecured wireless workstation can be an excellent vector for an attack on an entire infrastructure.
There are two main security considerations for safe usage of a client computer on a wireless network. The first is preventing a compromise of the client itself. A compromise of the client could lead to stolen or corrupted data, and provide an entry point for the attacker into the wider network. The second main consideration is using secure methods to communicate with other network services from the client.
The client needs to be protected from attack over the network. The primary means of accomplishing this is through the use of a firewall. A firewall on a client should block all unknown incoming traffic and allow for outbound connections. Connections directly to or from other computers on the wireless network should also be blocked. The exact means of accomplishing this for a specific OS will be covered in the five chapters that follow.
In addition to establishing a firewall, unneeded services on the client should be disabled. If there is a pressing reason to run a specific service from a client, firewall rules need to be modified to allow traffic to that service. It is vital that any exposed services are run using up-to-date software. Outdated software with security vulnerabilities is the primary entry point for attackers.
In addition, we’ll discuss the use of static ARP to protect against layer 2 man-in-the-middle attacks. These attacks can lead to eavesdropping or manipulation of network sessions. The use of static ARP entries can prevent these attacks from succeeding, since the host will not modify its ARP table when it receives malicious information. Static ARP tables can be overwhelmingly complex to administer in large networks but can be a useful and easy tool in a smaller network. For more information on ARP attacks, see ARP Poisoning.
The manner in which you access services across the network is just as important as host security. It does not matter how bulletproof your firewall is if send your username and password in the clear every time you check your email with an IMAP request. Remember that an attacker can be passively listening to the network and not necessarily actively attacking your host.
At the time of this writing, WEP is not an
acceptable solution for preserving the confidentiality of data
traversing a wireless network. There are several problems with WEP
that greatly weaken its effectiveness. WEP is better than
cleartext; it raises the bar for an attacker to
obtain transmitted data. However, a sophisticated attacker may still
be able to bypass the encryption provided by WEP, thereby exposing
your data.
In order to prevent sensitive data from being compromised, you need to provide for encryption at a higher level in the stack. Note that we did not say it was necessary to protect all of your data, just your sensitive data. Different users define sensitive information differently. While one user may think all data sent or received is sensitive, another may feel that there is no risk in an attacker seeing what web pages they are surfing. In general, you should work to protect usernames, passwords, credit-card information, and other unique, personal information. Whether or not you feel your DNS requests and Slashdot trolling are worthy of higher levels of encryption is up to you.
Secure Socket Layer (SSL) is a public-key, cryptography-based confidentiality mechanism. It is historically associated with web pages accessed via secure HTTP (HTTPS). However, any protocol can be encapsulated in SSL for secure network transit. SSL is great for protecting transaction-based protocols such as web traffic and mail transactions.
When surfing the Web using a wireless connection, you should pay special attention to pages that require you to authenticate yourself or that you have reached via authentication. Your initial authentication will involve sending your authentication credentials (i.e., username/password combinations) to the remote server. Unfortunately, subsequent pages accessed on the site after authentication may contain sensitive data, including your credentials or a cookie representing successful authentication. An attacker may be able to replay your authentication or your cookie to gain access to the same resources. Access to those pages and subsequent pages on the site should be accessed via HTTPS. The same advice goes for submission of credit-card information.
Web traffic is
not the only candidate for SSL protection. Many mail clients allow
for some form of SSL access to mail stores including
Netscape’s Messenger and the console-based mail
reader pine. The most popular access mechanism
is IMAP over SSL. When receiving mail via IMAP, your username and
password must be sent to the remote mail server. Using SSL for this
connection allows you to maintain the confidentiality of your mail
access credentials. Some mail clients also support SMTP over SSL.
However, since no authentication credentials are sent during an SMTP
session, this practice is not as common. The use of SSL does increase
the computational burden on the mail server and may not be feasible
in high-volume mail systems. We value the privacy of our email and
advise using SMTP or IMAP over SSL if available.
Secure Shell (SSH) is a
secure replacement for the r-commands such as
rlogin, rcmd, and
rshell. SSH also uses public-key cryptography
like SSL, but does not rely on a trusted authority to issue the
public/private key pairs. SSH can use several symmetric ciphers when
passing data between hosts to allow users to choose the appropriate
level of security based on their situation. If it is not installed on
your workstation, check your distribution media or http://www.openssh.orgfor links to the source code or precompiled binaries of
OpenSSH.
When accessing a command shell on a remote machine over a wireless network, you should use SSH rather than telnet or the r-commands. When SSH is properly used, it will help ensure your credentials and traffic is protected from eavesdroppers.
SSH also provides a tunneling mechanism. A port on a local machine can be forwarded to a port on a remote machine. This allows secure access to remote services that are normally accessible in an insecure manner. This can be useful for accessing one particular service, but is not practical for tunneling many different types of traffic. The syntax for SSH local port forwarding is:
ssh -L localport:remotehost:remoteport username@remotehost
As an example, assume we are on a wireless network and want to access our IMAP server over SSH. Normally, IMAP credentials and email is sent in the clear. Due to the constant data stream involved in IMAP connections, they are ideal targets for eavesdroppers. By tunneling over SSH, the sensitive information is protected from malicious neighbors, as shown in Figure 3-1.
In order to set up the tunnel, forward all local IMAP connections on the client (TCP port 143) to the IMAP port on the mail server. The following command performs the necessary remote port forwarding to achieve this:
ssh -f -L 143:mail.example.com:143 [email protected] sleep 3600
In order to use this tunnel, configure your mail client to use
localhost as the IMAP server. The -f flag tells
SSH to go into the background after the authentication process is
over. The command sleep 3600 is executed on the
remote host. Once the sleep command terminates, the SSH session will
be torn down. This example can be modified to forward POP connections
rather than IMAP by changing the port information to port 110.
Note
that, by default, SSH will only forward connections that originate
from localhost. Connections to forwarded ports from remote stations
will be denied by default. In order to allow other machines to access
the forwarded port, use the -g flag. Only do this
if there is a reason for external connections.