Personal wiki in my home network - how do I secure it?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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 (https://my.domain.com/wiki, https://my.domain.com/blog) 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)