You have just bought tickets to an exotic vacation spot. You board the flight, you land safely, you pull your netbook from your backpack, fire it up, and then check if there are any available Wireless networks. Indeed there are, unencrypted, passwordless, waiting for you. So you connect to the most convenient hotspot and start surfing. Being addicted as you are, you want to login into your email or social network just to check if something cardinal happened in the world during your four-hour flight. You’re about to hit the sign in button. Stop. What you’re about to do might not be safe.
This super-dramatic introduction is supposed to highlight
today’s topic: How to stay safe on the road. And I’m not implying
anything you may do in your person, like getting robbed or kidnapped or
drinking local tap water, but rather the security involving your
electronic gadgets and your online habits. Because if you bring your
computer with you, you will want to connect it to the outside world.
And this is where troubles begin. Or not. Hopefully, the article will
highlight all the perils and pitfalls of unsafe hex and how you can
What’s all this fearmongering?
There’s none really. But you have probably read a million
articles and scare posts telling you how this or that person’s email
credentials or credit card details where stolen. You will hear a lot of
warnings about not connecting to insecure networks. You will be warned
about using public hotspots and Internet cafes.
All right, let’s try to analyze the situation one byte [sic] at a
First of all, it all comes down to trust. In a nutshell, you
trust your own computing device and you trust your ISP, at the very
least. This means the chain of communication at home is safe. Once you
leave that cushty enclave, things change.
There are several layers of potential dangers that might
compromise the security, privacy and integrity of your online
activities outside your home. We will start with the bottom layer.
Whenever your computer connects to a new network, it tries to obtain an IP address. In most cases, your computer’s network device
will be configured to use DHCP, so it will broadcast a request for an
address. The available DHCP server on your network will respond, a
short exchange of information will occur, and you will become a member
of the network.
At this point, your machine will become a visible node in the
local network. This means that other clients will be able to
communicate with you. They might ping you or try to connect to
available services running on your machine. And here’s the interesting
part. If your machine has running services configured to listen on
external networks and accept unauthenticated requests, you may
inadvertently compromise your data. Moreover, if you are running
outdated versions of programs with known and easily exploitable
vulnerabilities, it may also be possible for determined and skilled
attackers, if present on your network, to try to gain elevated
privileges through the exploit and become administrative users on your
Examples that highlight these possibilities include sharing of
drives via Samba, being logged in as root/admin and running an ancient,
buggy version of a P2P client, having SSH with a trivial 123456 for
password, and more. How do you go about protecting against network problems?
The simplest solution: firewall.
This is the easiest way of ensuring your operating system is
inaccessible by other peers on your network. By default, the firewall
will block all incoming connections to your ports, unless you
specifically create exclusion rules. And you’re done.
Now, advanced users may want to try to minimize the exposure
vector of their machines, regardless of the firewall. This means
disabling unneeded services, like turning off file and printer sharing
when traveling or not using BitTorrent at the airport, and running as a
user with limited privileges, so even if there are problems, they will
A good example would be Ubuntu – it comes with no services
listening on external networks, so the firewall is not even necessary,
and you work as a normal user without root privileges.
We’re still talking about network, but one level higher. DNS
stands for Domain Name System, a protocol designed to translate domain
names, like websites, into IP addresses. For example, when you enter
osnews.com into the address bar of a browser, your DNS server, most
likely the one provided by your ISP and automatically configured for
you, will translate the query into an IP address. There will be a long
chain of packets being sent back and forth, but eventually, you will
end up reading the content as you expected, without knowing anything
about any numbers.
Whenever you connect to a network, you’re assigned a DNS
server. You can check this by examining your network information. In
Windows, for instance, open the command prompt and type
ipconfig /all. In Linux, take
a look at
The IP addresses will change based on what network you connect to.
If you want to use only specific, trusted DNS server, then you
will want to use static DNS servers that are not overriden by
DHCP assignments, by this requires changing some configuration files on
your machine. More importantly, this means having IP addresses of known
and trusted DNS servers available. Worldwide public services include
Google Public DNS and Open DNS, but whether you want or trust them is a
different story altogether.
Assuming you go with the default option, you will be relying
on whatever DNS server is assigned to you for name to IP address
translation. In theory, a rogue server could malform your requests and
return bogus information. So what do you do?
There are several things you can do. First, normal web
browsing. Connecting to non-secure websites, the ones you normally see
http://, unless you’re using one of the modern, fancy browsers that hide the
information from you, you will not know if you’re being forwarded to
bogus sites or not. Or rather, not without some extra work, but then,
you don’t need this article.
But just browsing is not really important. Things become
interesting when you need to input your username and password into a
login field, or better yet, provide your credit card details.
My recommendations is not to login into non-secure sites when
connected to untrusted networks outside your home. This probably
extends to your social network, so you might be hard tempted. We will
discuss that later on.
For secure websites, the ones starting with
https://, things are a little
different. Secure connections are all about creating an encrypted
tunnel between your browser and the remote server so that anyone
sniffing the exchange of information will see meaningless, random
packets rather than streams of clear text containing private data. But
there’s a catch. How do you know you’re connected to the site you think
you’re connected to?
This is the reason why secure connections are always
accompanied with certificates. Connecting to an HTTPS site is not
enough; you also need to be sure that the site is what it claims to be.
To that end, the idea of worldwide-trusted Certificate Authorities (CA)
was created, with the sole pupose of issuing identification cards to
websites. When you connect to a site, it offers its certificate. Your
browser compares the certificate to its own list. If the two match, you
proceed to login. If not, you are warned that you are connecting to an
Now, the word untrusted does not imply bad or malicious. It
merely means that your brwoser does not know whether the site is what
it claims to be. There are two potential reasons. One, it has a
certificate that differs from the one it is supposed to have. Two, it
has a self-signed certificate.
In this situation, you need to make the decision whether to
trust the site or not. For most people, the best choice is to stop and
consult an expert. However, there are several ways common users might
help themselves distinguish between true and bogus sites.
One of the best ways of doing this is to keep bookmarks of
important sites. This way, there’s less of a chance of being offered a
wrong site when you search for it. Moreover, if your bookmarked sites
are trusted but have self-signed certificates, then you should write
down the site’s certificate checksum, so that when you connect from
an untrusted network, you can compare the certificate presented to you with
your saved list. In theory, it is possible to forge certificate
fingerprints to match those of genuine sites, but this is extremely
Another way of keeping track of certificates is a handy
Firefox extension called Perspectives.
This extension uses several online databases, known as notaries, to
compare the current site’s fingerprint with results taken in the
last 30 days. If the fingerprint appears unchanged, you may assume that
the site is ok, despite the warning. If the certificate seems to be
different or has changed many times recently, you might assume that
you’re possibly connecting to a wrong site. This should help you decide
whether to proceed.
Therefore, when you go about surfing somewhere outside your
home, like the restaurant or the airport Wi-Fi spot, you will know with
a very good degree of confidence whether you can connect to the sites
you need. This also extends to providing your credit card details and
other sensitive information. As long as your machine is your own, it
has a firewall, and the Web connections are secure and trusted, you’re
There are other ways you can connect safely to your sites,
including non-encrypted ones. This can be done by using tunneling. Your
current device becomes a viewing terminal, and all your confidential
activities happen on a trusted remote machine. For example, you may
connect to your home box using SSH. Of course, this implies being able
to connect to your home box, but we will discuss that shortly.
There are several methods you can use to establish secure
remote connections. Indeed, one of these is SSH. Encrypted VNC sessions are another possibility. You can also use a Virtual Private Network
(VPN) service like OpenVPN.
However, all of these solutions require a somewhat higher technical
To be able to achieve this, you will require a second machine
in a secure location, like your home or office, up and running. It must
also be accessible from outside, which means using a static, externally routable IP address
or maybe Dynamic DNS (DNS). It also requires opening ports in your home
network firewall, either the router or the box itself, with all the
additional security precautions. Your ISP must also allow that kind of
remote connectivity. Next, we come down to configuring the remote
sharing services properly, including robust passwords, limited
connection attempts, non-standard ports, and other settings.
Now we come to your personal data. Having a firewall will
prevent external access, but what if your laptop, netbook or smartphone
gets stolen? There’s always a possibility someone might steal your
gadgets, but when traveling, the risk increases. To that end, you might
want to considering keeping your data inside encrypted containers on
your disk, or even encrypting the entire hard disk. For most people,
having a file container inside which the data is kept is sufficient in
most cases. The simplest way you can configure encrypted file
containers is using a program like TrueCrypt.
You may also want to consider moving your user profile or home
directory into the encrypted container, so that application settings,
browser links, saved passwords, and possibly other sensitive data are
also not available if the gadget gets compromised. This method makes
work a little more complicated, and there’s the risk of a permanent
data loss if the encrypted container gets deleted or corrupted, but it
outweighs the dangers and risks of damage in the case of theft.
Naturally, you should have multiple backups of your data in safe,
trusted locations, but this is true regardless of your travel plans.
You can learn more about TrueCrypt in this
Using a computer other than your own
All of the above only applies to your personal computing
devices. And none of these apply if you must use a public computer. In
that case, all bets are off. You have no way of knowing whether your
activities are recorded or logged in any way, even if you appear to be
savvy and can examine various settings to try to determine if
keyloggers, network sniffers or other tools might be active.
My recommendation is to refrain from providing any personal
information on public computers, including seemingly innocent logins
into forums and social network, especially if they are not encrypted.
The recommendation also extends to not plugging in your removable
devices, like digital camera smart cards, USB thumb drives, external
disks, and other gadgets into these public computers. It’s more than
just viruses and whatnot, and frankly, these are overrated. It’s the
simple fact of making your data accessible on machines other than your
own. If you do not trust the machine, then simply don’t use it.
Best travel option
Now, let’s see what your optimal traveling computing set
should look like.
Ideally, you would want to use a Linux-based operating system
for your travel machine. Normally, almost all efforts to compromise
your machine will be focused on Windows, so you will gain by just being
different. Moreover, Linux is easier to secure out of the box, because
of its least-privilege principle, allowing you to work as a limited
user with no ill side effects.
You will have your browser with several important, secure
sites bookmarked, and a list of sites’ fingerprints saved in a text
file for comparison in the case of discrepancies,
or alternatively, run Firefox with Perspectives. You will also
keep an encrypted container for your data, and possibly the entire home
directory. You will be running a firewall to make sure there are
no ports left open by mistake.
Last but not the least: YOU
No technology in the world can protect you from yourself.
There’s nothing that can stop you from divulging important personal
data in web forms, chat rooms, forums, social networks, and other
sites. If you decide you want to install software, share fires or input
your private information somewhere online, then firewall, encryption
and all other solutions become meaningless.
The safety of your digital travel starts with the concept of
discipline. If you cannot adhere to that, then you will have a hard
time ensuring the integrity and privacy of your data. But if you are
willing to follow simple principles, firewall, secure connections and
data encryption will cover some 80-90% of your needs.
Travel security seems complicated, but it narrows down to a
small number of protection layers – firewall for basic network
filtering, secure sites control against rogue redirection and
misidentification, data encryption, and basic discipline. Everything
else comes secondary.
Hopefully, this article clears away some of the fear mist that
shrouded your mind. It is all too easy to get lost in the media panic
generated around the risks and perils of travel, as if you’re going to
Mordor on your own. But things are much simpler. There you go.
About the author:
Igor Ljubuncic aka Dedoimedo is the guy behind dedoimedo.com. He makes a
living out of his very hobby – Linux, and holds a bunch of certifications
that make a nice pile in the bottom drawer.
From the title I thought this was going to be something completely different and was even thinking “why on earth would OSnews be posting an article like this??”
Nice article … but setting up a secure Windows 7 box using SRP and Limited User Account is really trivial these days; more so than Linux I would say.
As the author suggests, using a VPN provides the best available security while travelling and on others’ networks, whether open or secured. Unfortunately most OSes these days tend to do a lot of phoning home before they even allow you to establish a VPN connection, and on most open hotspots you’ll have to go through a captive portal before being able to establish your VPN tunnel.
What I’ve done on my personal Linux systems is to set up HTTP and SOCKS proxies on the VPN server and point everything on the local machine at those proxies. Be sure to use the system firewall to prevent traffic to those proxies from escaping unencrypted when the VPN link is not up! When I encounter a hotspot with a captive portal, I run a separate instance of Firefox with a different profile that is configured to always use private browsing, has plugins disabled, and has no proxy set. Once I log in, the OpenVPN tunnel establishes automatically. I do not have the tunnel take over the default route, since almost everything is configured to use the proxies; however, you can set that up easily enough too.
This configuration has the advantage that it is fail safe; that is, if I happen to leave a program running and connect to an untrusted network, the program won’t automatically start communicating on that network until the VPN link is up. I could imagine other ways to obtain this fail-safe configuration, but any of them would be much more difficult to implement.
Here’s how I accomplished this on Ubuntu; these instructions should work on Debian too, and will be very similar on other distributions.
To prevent VPN traffic from escaping on the wireless interface when the VPN is not up using the “ufw” firewall management script:
ufw deny out on wlan0 from any to 192.168.202.0/24
Adjust as appropriate for your VPN address range and network interface.
Place your OpenVPN configuration in /etc/openvpn/myvpn.conf , then edit /etc/default/openvpn and set AUTOSTART=”myvpn”. Be sure to use proto udp in your OpenVPN configuration if possible.
I use squid and dante on my VPN host to provide HTTP and SOCKS proxies, respectively. On the client side, these proxies are configured as the default through the desktop environment’s controls. To make Thunderbird use a SOCKS proxy, go to Edit -> Preferences -> Advanced -> General and choose Config Editor. In the config editor, set network.proxy.socks and network.proxy.socks_port as appropriate, then enable network.proxy.socks_remote_dns and set network.proxy.type to 1. All other proxy settings should be the default.
For SSH, I use a program called connect-proxy which is available in the Debian and Ubuntu repositories. Instructions on configuring it are available in the man page.
I’ve added the proxy to /etc/environment so that programs like curl automatically use it on all user accounts:
In addition, I’ve configured sudo to use a separate environment file /etc/environment.sudo so that commands like sudo apt-get update use the proxy as well. The contents of /etc/environment.sudo are the same as what I added to /etc/environment. To configure sudo, run visudo and add the following line near the beginning of the file:
Be careful when editing the sudo configuration, since one mis-edit can ruin your day.
Using OpenSSH’s -D flag and a high port number (I usually use something in 8xxx), you can hack together your own SOCKS proxy with a shell one-liner. This is great if, like me, everything you use but HTTP is secure by default anyway (IMAPS, SSH, IRC over SSL) and you don’t have OpenVPN running on your server. I can then use FoxyProxy Standard, a great FOSS Firefox add-on, to tunnel my web traffic.