GottaBeSecure: More WiFi and the Rookie (Part 2 of 5)

In Part 1 of this series about mobile security, I described the dangers of having your web connection intercepted through a technique known as wireless ““sniffing.” Although I only discussed the problem of web browsing being intercepted, the problem really applies to any network traffic that isn’t encrypted. So, other common applications like email, file transfer, and remote login are also, potentially, vulnerable to interception.

In the expanded chart below, I’ve outlined a growing list of ““secure” and ““not secure” applications and protocols:

 

 

 

 

 

 

 

 

 

 

Notice that some insecure protocols can be made ““secure” by using SSL to encrypt them (e.g., POP via SSL). To use these protocols in a secure fashion, you’ll need to check with your Internet Service Provider (ISP) or corporate system administrator to see if they support the secure versions of these protocols over SSL. Simply switching your network settings without checking to see if the secure connection is supported may cause your application to stop working.

Another popular way to securely transmit sensitive data across a public WiFi network is by using a Virtual Private Network (VPN). A VPN sends your data from your computer to your company’s network through an encrypted tunnel, securing the data from point A to point B. The VPN endpoint is usually located safely behind your company’s firewall. Contact your company’s help desk to find out if your company supports VPN connections. Usually you’ll need to receive VPN client software from your company’s help desk and assistance configuring the software to connect in for remote access via the VPN.

At the bottom section of the table you’ll notice an entry for ““remote login.” Remote logins are often used by system or network administrators to manage servers, routers, or switches. Sadly, this is often done using the insecure TELNET protocol, which transmits the username and password in the clear across the network. In most cases, organizations limit the use of TELNET to internal networks, where it is assumed that employees can either be trusted not to intercept the administrative passwords or don’t have the technical expertise to do so. Such reasoning fails to account for the very real possibility of a malicious insider threat within the organization. Even within a switched network environment, TELNET provides an easy means for an attacker to collect login credentials to servers, routers, or switches. A much better technique for remote management of computer resources is the use of Secure Shell (SSH). SSH not only encrypts the transmission administrative usernames and passwords, but also encrypts all the information transmitted (for instance the commands being executed) to the remote computer. Using SSH to perform remote login will end up costing an organization some time and money (time to configure the software and money for software licenses, unless you use the free OpenSSH), but it is a security investment that is absolutely essential if you intend to remotely manage servers, switches, or routers across a network.

Finally, a friend emailed a great tip to me this week. If you use Gmail and Firefox, try the Firefox extension CustomizeGoogle. By default, one of the settings is to force Firefox to ““go secure” (HTTPS) every time you connect to Gmail.

In the next part of this series, we’ll examine the next level of security threats on public networks—hackers who go beyond passive network sniffing and actively attack your computer in your mobile environment. My goal is to convince you of this one thing: if you ““gotta be mobile,” you ““gotta be secure.”