Proof of Concept: Build my own Web Provider at home I – The idea

The idea

I’ve run web servers at home for a quite long time. I used to have my LAMP system (compiled to fit my needs) running on Slackware and it covered all my needs for many years. But during the last years I found myself running very different flavors of Application Servers and I found that my LAMP setup was not flexible enough to deal with such an heterogeneous systems.

I wanted to have a solution that would allow me to run different web servers (apache, nginx, Jetty, flask…), different Application Servers (tomcat, WebLogic, JBoss, Django, perl scripts, etc..) all of them isolated as much as possible from the others.

Since this is a home solution and I cannot afford to have a rack full of blades at home, all these services should run in commodity hardware. I’ve chosen to run it on a laptop, that gives me a UPS service (battery) although it has the drawback of not much CPU power and (most important)  not much RAM. Of course, the solution could be extrapolated to multiple machines, having the ability to grow either horizontally or vertically. But for now, this solution will be confined into a single server 🙁

My ideal solution should, if possible, cover these needs:

• Minimize the administration time & effort, using – if possible  – a standard, updated, with a good life cycle and well documented Operating System.
• Federate each Web Instance in such a way that it should be independent from any other:
• Each Web Instance can run its own software product (We can have Apache 2.2, Jetty, iPlanet etc. as Web Servers serving content)
• Each Web instance should run under its own UNIX account and should run in its the userspace.
• Each Web instance that use the same product (say Apache or nginx) should share the same binaries (easy upgrade process) but should use its own configuration (for instance, each apache instance can load only the modules it needs)
• ach Apache instance can load only the modules it needs. The idea of Debian’s VirtualHosts solution is not desirable, as all the VHosts will have the modules loaded. It makes no sense to me that an Apache instance used as a Tomcat front-end (using mod_jk) should also need to load the PHP5 module, only b/c other VHost uses it.
• Each Web instance, if using PHP, should have its own php.ini file.
• The UNIX accounts used to run the instances should be either not accessible or only accessible via SFTP
• Two networks, one for the service and a second one for administration, backups, etc.
• Two sshd daemons, the one that comes with the OS and a secondary one (static) to be used only in case of issues with the first one.
• A Software Load Balancer (haproxy)
• SSL offloading (stunnel)
• Cache service (varnish, but the lack of RAM may not allow it)
• SQL Cache system (memcached) for those applications that can benefit from it (again, the RAM constrictions can be an issue here)
• Multiple MySQL instances (either manually done or using multi-mysql)
• Optional: File system encryption

This solution adds also a extra burden. We are not using a single web server with multiple Virtual Hosts, so we need to add a software that gives us that ability. Our candidate is HAProxy. It will take care of the multiple domain names and also will be a good solution for doing load balancing/failover solutions.

Let’s have a look at a diagram to get an idea of who the elements interact:

The reader will realize there are some elements that have been added to avoid single point of failures (as the redundant router) that will be quite hard to implement in a home network; Other services as stunnel, HAProxy, Web servers and DB backends are easier to  set up in high availability. But since I’m going to install all of this into a single server, there is a HUGE SPOF : The server itself! I just wanted to demonstrate that, having the necessary resources, the setup can be built in a a high-availability fashion.

So, what are the requirements?

Requirements

• A Server. I’ve chosen a Laptop (its batteries are my UPS system 😉  (the more memory, the better!) It may be desireable to have two NICs (my second one is a JME 1xGigabit installed in the ExpressCard expansion slot). If you want to play in a more controlled environment, any virtual setup will work too.
• A Linux/UNIX distro. I’ve chosen Ubutu 10.04 LTS Server because it worked fine with my laptop hw. Slackware, Debian Stable, Fedora, or any other Linux Distro will work fine too. Of course, the BSD  family is an excellent choice too.
• Have that distro installed on the server.
• An Internet connection (DSL will work, don’t expect to be fast if your upload is low).
• Redirect some ports from your router to the Server.
• A DNS domain working (we will cover other day how to run tinydns). If you have a dynamic IP,you may want to use any of the free dynamic DNS solutions available in the net.
• A bit of free time.
• Coffee, tea, lemonade…

Operating System

If you have chosen Ubuntu, make sure you install the Apache, PHP and MySQL packages. You will find yourself with an Apache web server running on port 80 and all its config files located at /etc/apache2. These files will be used as our foundation for our setup.

If you have chosen to have two networks, configure them and do not setup any kind on NAT over them. This is not really necessary but it is always good to have an administration network that can be used for monitoring (Zabbix? Hyperic?), backup (bacula?) and general management.

A bit of security

The following lines just give you some extra features that I recommend to tighten a bit more the security of a Linux setup. Please note that your system may not be secure by only following these instructions. There are many places int he web where you can find very useful documentation about to create a SOX or SAS70 complaint system.

Firewall

Configure your firewall to allow only TCP access to, at least, only the following ports:

• TCP 80 HTTP (to redirect traffic to 443)
• TCP 443 HTTPS
• TCP 22 SSH
• TCP 2222 for an SSH static daemon

If you don’t want to allow access to SSH from the outside, just open the HTTP and HTTPS ports, or allow SSH only to your trusted IPs. I also recommend to add a ny extra IPTables setup to avoid flood attacks, port scannings, etc.

DenyHosts

I’d recommend to install this simple but powerful HIPS service that audits the ssh accesses and blocks IPs if a user tried to access incorrectly several times. Follow your distribution instructions to install it. In Ubuntu, it is easy:

sudo apt-get install denyhosts

Configure it editing the file /etc/denyhosts.conf

You can block all services:

BLOCK_SERVICE = ALL

…but also to add your internal network IPs to the white list file:

/var/lib/denyhosts/allowed-hosts</code>

accton

This tool keeps a log of the commands executed in the server. Quite useful if you need to find clues after suffering a security event.

lastcomm

Next chapter : the SSHD daemon setup!