Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'd like to dedicate a low-power Debian/Ubuntu box to set up a personal wiki (namely Instiki) on it. The information I'm looking to store in it will obviously be of a very confidential nature; anyone except me accessing it would be disaster. And my network administration and security skills are pretty weak. High requirements, low skills; not a good combination.

I know that by its nature, setting up a listening app and opening a port to the outside world exposes me to a certain level of danger. But how do I minimize that danger?

  • My understanding is that as long as it's running behind my router, which has a built-in firewall, it's not accessible to the outside world by default; correct?
  • And if I do explicitly open a port to the machine (set up a "Virtual server" entry in my router's config), I'm basically at the mercy of the strength of my username/password combination, which theoretically any script kiddie scanning for open ports could guess by brute force.

Is there any practical middle ground between disabling outside access altogether, and relying on a port/username/password combination? I could live with only accessing my wiki when I'm at home, but it would be an inconvenience.

What are my other options? SSH tunneling? Key pair authentication? Please advise. I would especially like further advice regarding setting up a tunnel or VPN via SSH.

share|improve this question

migrated from Sep 17 '11 at 8:53

This question came from our site for system and network administrators.

No it doesn't. This is as much as server question as any other I've seen. – David Z Aug 2 '09 at 8:11
up vote 4 down vote accepted

Here's the approach I'd take:

step 1 (local security)

  • read up on Instiki, make sure you harden the webserver it uses
  • choose good passwords for root, admin and personal accounts, keep them in a password manager, not on paper!
  • make sure only the web-server (no other, e.g. guest) users can read data locally [not sure how that aplies to rails]
  • learn how to encrypt local files (e.g. truecrypt)
  • learn how to make encrypted backups (no backup => no data)

step 2 (access restrictions)

  • make server accessible over https only (nobody reads your traffic in transit)
  • allow login to Ubuntu only via ssh [port 22] or local console
  • to securely access you home network from the wild internets, look into OpenVpn
share|improve this answer
That's the kind of advice I was looking for; thank you. Do you think SSH tunneling as described in would be a good solution? I mean only the basics you've mentioned, plus setting up SSH with key pair authentication; no HTTPS, as SSH will take care of in-transit encryption as well. – Jonas Trevor Aug 2 '09 at 6:55
I'd use ssh and key-pairs for login only, no SSH-tunnel to the wiki (but a VPN to the home router would make sense), so I've added it to my answer. – lexu Aug 2 '09 at 7:36
Why exactly would you not recommend tunneling to the wiki directly? While it would be a useful bonus to administer the machine remotely via SSH, it's not really my end goal. – Jonas Trevor Aug 2 '09 at 15:51
One more thing you may wish to consider adding in addition to everything above is to throw an .htaccess file in your web root so that you have to authenticate TWICE. This way, if the script/wiki itself has a vulnerability at least its not a sitting duck. You can also set up your .htaccess to reject connections from anyone other than a specific IP/range. – KPWINC Aug 2 '09 at 15:56

I'd do HTTP authentication over HTTPS and redirect any HTTP traffic to HTTPS. Restrict access to particular IP addresses or networks if you don't need access from everywhere. You could use a HTTPS client certificate, but you'd need to have that certificate installed on any computer you need to access from. You could use some sort of USB device to store it on, but you'd need to make sure it was removed after you're done. Depending on your paranoia, you may not be able to trust any computer you've not got under your control, and even then how secure are they?

There's only so much effort you can put in where gaining access becomes a huge headache, only to find your security is ruined by someone reading your display over your shoulder. People tend to over-estimate both the informations value and the likelihood of being attacked remotely, and underestimate the non-technical ways of the security failing.

share|improve this answer
Thanks for your thoughtful answer, David. I only intend to access the server from my own laptop, so carrying around an SSH key or SSL certificate will be no problem, since I trust my aptitude regarding physically securing my computer and the sensitive stuff in it more than my network administration and security skills. Is there a particular reason you'd prefer HTTPS to SSH tunneling? – Jonas Trevor Aug 2 '09 at 15:54

If I am going to be in control of the off-network browsers that I will be using to access resources at home, I use X.509 client certificate authentication over SSL. That way even if someone had my username and password, the web server will refuse to talk to them because they don't have my client cert.

This is a little bit trickier to set up, and if you're using a thin webserver built into some of the wiki products might be impossible. I use nginx as my webserver and my wiki (WikkaWiki) runs on php-fastcgi.

The problem is that you may have multiple sites you need to access, and due to the way that SSL works you can't have multiple virtual hosts on the same IP and port combination. You can address this by putting the sites all under one host and have a subdirectory for each (, or have separate domain names and use different ports.

In the latter case, you may run into problems sending traffic out of corporate networks to arbitrary ports that you're running SSL on (they block all but known traffic in an attempt to prevent people from opening up tunnels into their network using SSH)

share|improve this answer

You must log in to answer this question.