Wireless Security on the Road Without a VPN
Pages: 1, 2
Anything that you cannot secure should not be used during your travel. Why? Because any information can be used, whether it is against you or not. That family site login you do through HTTP (why enable SSL on such a site, right?), that XML-RPC posting interface for your blog, that special FeedBurner URL, all allow an attacker to learn something about you.
Forget about them, update them, do whatever you need to but do not assume that something is "unimportant." Open the service door and the entrance hall will get invaded, one way or the other -- many a castle was burned down that way in the Middle Ages.
Of course, sometimes, there is nothing to be done. Most applications, for example, will always contact their update servers over HTTP as part of their daily or weekly "phoning home" scheme. If you do not wish to block these connections with LittleSnitch (or disable the corresponding preference), systematically refuse any update that is offered to you while browsing on the untrusted network.
Make It a Snap
Of course, we all know that security exists. But being secure is a different matter. This is why it is important to make it easy for you to use these secure protocols: update your Mail configuration, update your browser bookmarks to point toward to the HTTPS URLs, and setup your weak email accounts to forward to stronger ones.
With the exception of public site browsing (such as the O'Reilly Network, FJZone.org, TheDigitalStory.com, etc.), no insecure URLs should subsist in your bookmarks or aggregator. It takes a while, of course, but it is worth it!
The idea here is to "port," so to speak, your entire computing routing into the secure area without changing your habits. Whatever cannot be secured needs either to be disabled during your travels or altered so that you can secure it somehow.
The most careful among us will want to keep two user accounts on their machines, each with a matching application selection in the dock. Others will simply want to remove their chat application, XML-RPC blog updater, etc. from their dock while traveling so as to avoid opening them by mistake.
Securing your communications with the outside won't do you much good if your computer and the servers you connect to are full of holes. In that light, be sure to secure your Mac properly (but prefer a more modern anti-virus solution to what is described in our 2004 article).
If some of the servers you connect to are yours, make sure they are up to date and patched. Remember that anyone who wants to can see what you are connecting to and even get a list automatically compiled on his machine. Hence, every time you make a connection to a server that looks interesting, so to speak, you are offering good target points to your neighbors on a silver platter. In circumstances like this, you often wish you hadn't named a server "staff.example.com" or "accounting.example.com," since such names are the equivalent of leaving a cherry pie to cool down on the window ledge -- cartoon fanatics will understand.
Before leaving, it may be a good idea to rotate all your passwords too and make sure they would resist a brute force attack. Keychain Access' Password Assistant will help you greatly in that task. The same should be done once you come back. If someone gained access to some of your passwords, the good rotation at the end will help kick them out, unless, of course, the account they gained access to has administrative privileges. If that is the case, they could just use it to open an account of their own or, worse, a backdoor somewhere.
Mind the DNS
Although some may deem this precaution exaggerated, it cannot hurt to rely as little as possible on the DNS of the network you are connecting to. Indeed, it is not out of the realm of possibilities that someone would poison the network's DNS to redirect popular banking or auction sites to a destination of their own.
Of course, the use of authenticated protocols should raise an error or a warning, which you should read especially carefully when traveling. But what if something fails? What if the attack is particularly well executed and relies on a weakness within the legitimate site? For such attacks, using your own DNS server might help.
Some companies provide high-quality hardened recursive DNS services that may be worth looking into. Once subscribed, you usually need to keep your Mac pointed toward these DNS servers, which you do through the "Network" preference pane (the TCP/IP tab of your port configuration of choice, more precisely). Most such systems require that your computer sends an authenticated message to the servers first to ascertain that you can use the account you subscribed to, which, as long as no passwords are transmitted in the clear, should be reasonably safe.
If at all possible (and especially if using an updating mechanism as described above), try replacing URLs by IP addresses. For example, if you connect to your server through "myserver.example.com," try replacing this line in your SFTP client with the IP address of that machine. The most reliable way to know the address is to ask the machine's administrator, although LittleSnitch and the Terminal's "dig" command should provide you with this information too.
When you are not traveling, a good recursive DNS service may considerably speed up your connections since most ISPs do not invest heavily in the DNS service they provide to their users.
Before returning to your wired network, quit all your web applications and enter
lookupd -flushcache in your Terminal, which will clear your Mac's DNS cache, potentially leaving in the dust any incorrect entries it may have handled.
In most WiFi-enabled areas, you will see little signs inviting you to "just open your browser" or, worse, you may be tempted to go ahead and pick a plausible-sounding network in your AirPort menu at random. This, unfortunately, is the wireless equivalent of Russian Roulette since absolutely nothing guarantees your computer is using the right network. Even I can, on a whim, create a network called "T-Mobile", "Orange," or "O'Reilly's Free WiFi" wherever I go.
Hence, it is essential you rely as much on alternate means of authentication before connecting to the network for the first time. This is not always possible but there are a few simple ways to go about it.
First, ascertain the name of the network you need to connect to -- and once again, don't make any assumptions. Although someone could indeed create a rogue network with the same SSID (name) as the one of the legitimate network, it would require using antennas powerful enough to fool your computer into thinking their network provides a better signal than the genuine one. Doable, certainly, easy if someone wants to target you personally (they could rent the room next door) but then, if you are working for the Secret Service, you're probably not strolling around a hotel using their WiFi network.
What is one supposed to do? In some places, the name of the network will be written somewhere on a plaque or a sign. Most of the time however, you will have to locate the customer support phone number printed on whatever leaflet the hotel has given you or left in your room and ask the friendly attendant. Sounds silly? Well, it often helps avoiding mistakes and it doesn't cost much to place a 10 second call. Some companies operate under different names at different locations so, again, knowing the name of a network in one place doesn't mean you know what it is called in others.
Then there is the question of purchasing your access. Usually, you are instructed to login, let the provider's catch-all firewall block you, and instruct you to punch in your credit card number. Very convenient indeed -- to steal credit card numbers, that is. Instead, prefer purchasing a pass at the front desk or through the telephone. Also, pay cash if you can since your credit card number will not be kept on file. Then, should the catch-all fail to accept your login, this may well mean you have hit a fake login page but all your attacker will have in its possession are 90 minutes of wireless access.
Of course, this changes dramatically if your login is linked to an email service or offers personalized pages, in which case your attacker could gain access to those too. Another reason to not use an ISP's email servers.
Sure, one could create a successful man-in-the-middle attack by creating a fake login page then passing the login on to the real one and transparently routing your connections. This is why it is essential you make sure the page uses SSL -- here comes Opera again. Also, verify that it is a catch-all. If the leaflets left in the hotel room specify you should type "wifi.oreillynet.com" to login, try entering something else like "apple.com." Yes, any pirate worth its salt could operate its own catch-all system but that is one extra step to go through and it is a lot more difficult than enabling web sharing and setting up a website that answers to the correct URL.
We have, in these few lines, brushed the surface of precautions that should be taken when using WiFi networks. These are inherently insecure and, unless you invest in a VPN, any attempt to turn them around will fail. However, you can make them more secure, perhaps even secure enough to work for you, at least from time to time.
All in all, the best advice I can give you is to be on the lookout. Social engineering with a dash of technology can be highly effective, especially on networks where the vast majority of users just do not care. Hence, a little thinking will go a long way, especially as you login.
When in doubt, think tarsier and snails. Oh, and have fun!
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to the Mac DevCenter.
802.1X any good?
2006-10-08 16:33:19 theocmg [View]
2006-06-24 11:23:21 EmiratesMac [View]
Use your own DNS
2006-06-20 23:24:19 tegbains [View]
2006-06-20 17:54:07 chris_barker [View]
2006-06-20 15:53:04 brocklee [View]
I don't understand....
2006-06-20 23:59:21 FJ de Kermadec | [View]
I don't understand....
2006-06-20 15:57:54 Derrick Story | [View]