How to Avoid Security Risks for Mobile Computing on Public WLANs

 
 
By John Gates  |  Posted 2008-07-11 Email Print this article Print
 
 
 
 
 
 
 

The good news about public hotspots is that they're everywhere. The bad news is that they're not secure. John Gates explains how to get past their problems and still be able to conduct secure computing over an insecure hotspot.

Wireless broadband Internet access via hotspots is convenient for both the casual surfer and the Internet-dependent teleworker. Unfortunately, current security technologies integrated into wireless LAN products offer insufficient protection here, and mobile users must be wary when accessing the central company network via a hotspot.

What is necessary is a security solution that protects the teleworkers' place in all phases of connection construction on hotspots-without risky, foreboding configurations and without the help of users or administrators. This article will illuminate the effectiveness of VPN security mechanisms, data encryption, strong authentication and personal firewalls. Plus, it will show how optimal protection can be achieved by dynamically integrating each of these technologies.

Risks in the WLAN

Each user can access public WLANs with correspondingly equipped terminals. The terminals automatically obtain an IP address, in the sense that they recognize the SSID (service set identifier) of the WLAN. Thus, they put themselves within range of the access points and are able to gain access permission onto the WLAN. Data security, or protection of participating devices from attacks, is not guaranteed by the WLAN operator. Security is limited to monitoring authorized network access in order to eliminate misuse of the server administration. User identification serves solely for the acquisition and the accounting of time online.

However, how does it look regarding the protection of sensitive information during data transmission? How can the PC optimally seal itself off from attacks from the WLAN and the Internet? Because the actual security risk on the hotspot originates from having to register with the operator outside the protected area of a VPN, as a rule it has to take place by means of the browser. During this time frame, the terminal device is unprotected. This stands in opposition to a company security policy that prohibits direct surfing on the Internet and that only permits certain protocols.

Basically, VPN mechanisms and data encryption serve to protect confidentiality. The corresponding security standards are IP Security tunneling and AES (Advanced Encryption Standard) encryption for data, and X.509 v3 for access protection. Additional security mechanisms such as certificates in a PKI (public-key infrastructure) or onetime password tokens complement or replace the usual user ID and password. A personal firewall offers the required protective mechanisms against attacks from the Internet and from the public WLAN. Here, stateful packet inspection is critical. If this is not provided, it is not advised to use a hotspot for mobile computing.

VPN client and external personal firewall

For a VPN solution with a separately installed firewall, the ports for HTTP/HTTPS data traffic to the personal firewall must be activated during hotspot registration. This can take place in three different ways:

1. The firewall rules for HTTP/HTTPS are firmly preconfigured in order to guarantee the functionality with the desired hotspots.

2. The configuration allows that the ports are opened for HTTP/HTTPS as needed for a certain time window (such as 2 minutes).

3. The user has administration rights and independently changes the firewall rules.

In all three cases there exists the risk that the user may surf outside of the secure VPN tunnel on the Internet and encounter destructive software such as viruses, worms or Trojans. Temporarily opening the firewall creates the danger of deliberate misuse by the user on the basis of multiple actuations of the time window. If the personal firewall fundamentally permits no communication outside of the configuration, then the user has to activate the corresponding firewall rules for the duration of registration on the hotspot. This requirements-based opening of the personal firewall involves the greatest risk of misconfigurations. The user must have a firm grasp of the exact changes being made and the exact environment in which they are made. Employee security awareness and technical know-how determine the security level quality.

A large security risk also exists when user data (user ID and password) is spied out externally on the hotspot during the registration process. With the aid of a notebook computer, a hacker can simulate both the hotspot and the WLAN SSIDs. If a user then registers on a hotspot, he does not land at the access point of the provider but rather on the notebook of the hacker. Because of the previously mirrored access point Web pages, the user assumes that he is authenticated on the hotspot. However, in reality, he is on the notebook of the hacker and his personal registration data is now exposed.

Providers always attempt to protect the hotspot registration pages through SSL (Secure Sockets Layer) processing (HTTPS), but that does not always succeed. For example, a user who arrives at a manipulated hotspot obtains the following report from the browser: "A problem exists with the security certificate on the Web site." In the background of this report, the attacker has only recreated the hotspot registration page and does not use the original certificate. For the lay person, this may not be recognizable at first glance, and it is incumbent to him to decide whether or not he should trust the certificate. To avoid placing a user in the position of having to make this decision, the hotspot registration should flow transparently before construction of the VPN. A solution that has proven itself in practice is the so-called registration script that takes over the transmission of registration and the inspection of the certificate at the hotspot.

The requirements for the functionality of a personal firewall with mobile computing on WLANs are multilayered. They also apply to the critical phases during the registration and sign-off process on the hotspot. Requirements must be known at the earliest possible time and should be in place from system start. They also must remain when no VPN connection exists or when it has been deactivated. Furthermore, the user should be safeguarded against arbitrarily reconfiguring or completely shutting off the personal firewall.



 
 
 
 
John Gates is a programmer and private consultant with over eight years of experience in the information technology field. He is owner of Dimante Computer Services LLC. He also serves as manager of information systems for a high school district in Illinois. Over the years, John has worked as a consultant for financial institutions and small businesses. He specializes in the deployment of secure remote access solutions for numerous client locations. John can be reached at dimante@dimante.net.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel