Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I recently set up my own home server, running Ubuntu linux. The intent I'm having for this is to have a private wiki for my family, so we can have a place to collect information like phone numbers, and other relevant information. Currently, access is limited to my LAN, essentially prohibiting outside access, but I'm considering allowing external access, if I can figure out how to meet a level of security. Specifically, I'm looking for a solution which:

  1. Prevents read access of any web content without some kind of authentication.
  2. The authentication should be passed in such a way to prevent packet sniffing to allow permanent access to the network.
  3. Ideally, I don't want this to cost anything, or if it costs something, to be a small one time cost.
  4. As one of the most common locations I will be accessing this will be work, I would prefer a solution which does not require any additional software on the client end.
  5. Access to within the LAN must be unrestricted, ie, no password required.
  6. I would like to be able to access the site occasionally from my Android phone, so any solution should not prevent that from working.
  7. I would like to expand this someday to allow more than just wiki software, but if there's a clever way to do this with the wiki software, I'll consider it.

My current thought is leaning towards producing a self-signed SSL certificate, and using apache authentication, either basic or digest, but requiring it to be passed over HTTPS, but I'm opened to alternative solutions.

My full config:

  • Ubuntu 11.10
  • Apache 2.2
  • Media Wiki 1.18
share|improve this question
3  
"Producing a self-signed SSL certificate, and using apache authentication, either basic or digest, but requiring it to be passed over HTTPS" Bingo. Do that and write in an exception block for your LAN. –  Jeff Ferland Feb 21 '12 at 14:09

3 Answers 3

up vote 4 down vote accepted

Jeff's comment gets it right. Producing an SSL certificate is necessary. If you have a domain name registered, you could skip the self-signed and go with a free SSL certificate so every new web browser you try will not complain about the certificate being untrusted (reducing the likelihood of MITM attacks). If you don't have a domain name, you can use openssl to create your own self signed certificate.

This allows you to login to your computer over HTTPS.

Next you'll probably want to add apache authentication along with exceptions for the local LAN block (192.168.0.0/16 or whatever). This can be done with a simple set of rules defined at: http://httpd.apache.org/docs/2.0/howto/auth.html

share|improve this answer

I have recently done the same thing with a Doku Wiki (for secure, offline research storage) on my home desktop (An Arch Linux Box). Only instead of using Ubuntu directly, I ran my server through Virtualbox and Turnkey-Doku Wiki and only turn on Vbox when I need to add/remove things from it. I also have it setup with a bridged connection so it can still be accessed across my lan while in Vbox.

Considerations I suggest:

  1. Full system encryption with LVM ontop of LUKS is fairly painless and works well with my setup while at rest.

  2. Doku-Wiki can be setup force HTTPS login (but I'm not sure about persistent ssl after logging in)

  3. For VPN I'd recommend using OpenVPN which has full encryption over the wire to help you with packet sniffing... This will also allow you to VPN through a regular web browser (to include your phone).

  4. As far as your looking to expand... You should really check out the turnkey linux solutions... Everything is stupid easy to use and prebuilt. They range from wiki's, webservers, collaboration sites, databases, note taking, you name it, they probably got it.

Best of luck.

share|improve this answer

How to secure a web server by the use of transport encryption has been answered already. But I would like to point out, that from what you wrote I would guess that you are still not aware about the major security concern for your installation. This is the list of security problems of PHP of the last two years:

  • CVE-2010-0397
  • CVE-2010-1128
  • CVE-2010-1129
  • CVE-2010-1130
  • CVE-2010-1860
  • CVE-2010-1862
  • CVE-2010-1864
  • CVE-2010-2097
  • CVE-2010-2100
  • CVE-2010-2101
  • CVE-2010-2190
  • CVE-2010-2191
  • CVE-2010-2225
  • CVE-2010-2484
  • CVE-2010-2531
  • CVE-2010-3065
  • CVE-2010-3436
  • CVE-2010-3709
  • CVE-2010-4150
  • CVE-2010-4645
  • CVE-2010-4697
  • CVE-2010-4698
  • CVE-2011-0421
  • CVE-2011-0708
  • CVE-2011-0752
  • CVE-2011-1092
  • CVE-2011-1148
  • CVE-2011-1153
  • CVE-2011-1938
  • CVE-2011-2202
  • CVE-2011-2483
  • CVE-2011-4566
  • CVE-2011-4885
  • CVE-2012-0830

As you can see the major problem is neither Apache nor MediaWiki but PHP.

I would never expose my private data with PHP to the public. I would suggest as a minimum requirement preventing any unauthorized access to the site from the public. Furthermore I would suggest the use of a client certificate and prevent any other access. This can be done with the SSLRequire directive of Apache. See the Strong Encryption Howto for further information.

share|improve this answer
    
Hi @ceving - can I ask why you are deleting multiple posts that don't appear to have anything wrong with them? –  Rory Alsop Oct 26 '12 at 18:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.