Building a Debian Linux Web Server

A recent client of mine often deals with controversial free speech and wanted to move their web server in-house to maintain better control over the website. Apparently, an excitable ISP had pulled the plug on them following some unwarranted accusations and they wanted to avoid that happening again.

After consulting with them about their requirements for the website, I provided some recommendations and the client returned with some inexpensive, but very nice off-the-shelf hardware. The computer had all of the most important features for a web server: a fast processor, large, fast SCSI hard drive, and most importantly, lots of fast DDR RAM. Of course, it came factory pre-loaded with Windows - but we fixed that soon enough.

After burning recovery DVDs and backing up all of the pre-loaded software, I wiped the harddrive and installed the latest production version of the free, open-source Debian operating system, which is a distribution of Linux. The difference in speed was noticable right away. Linux is lean and fast. It's built on the principle that each command should do one thing and do it well, and that works. Linux, in all of its various distributions, is by far the most popular choice in operating system for web server hardware on the Internet.

Once Debian was running smoothly, it was easy to download the rest of the LAMP stack: (the combination of the Linux operating system, Apache web server, MySQL database system and PHP scripting language is so popular that it is refered to by its own acronym - LAMP). Those programs are among tens of thousands that have been tested, configured and vetted by the Debian community, and they are available in "packages" that install easily and take care of much of the configuration work. This is one of the beautiful things about open-source communities: since that work has been done before, I get to take advantage of the contributions of others to speed my work along.

Things slowed down, though, when it came to configuring Apache virtual host definitions. Because I usually build Drupal projects as a multi-site within a subdirectory of the webroot, the configuration is non-standard. I get enormous flexibility this way, since it allows other Drupal and non-Drupal projects to be integrated as subdomains and/or subdirectories of the main project. In other words - unlimited growth potential. I eventually worked out an .htaccess file that acts as a switchboard for web requests, and that has proven effective in several projects. I wrote about that technique in another article.

I spent quite a bit of time hardening the system against potential attack. Linux includes a very effective firewall and I narrowed its definitions to only allow traffic that is necessary for the website. I shutdown any services that are not needed, limited user accounts to only be able to do what they are expected to do and reduced permissions on the website files. One particularly fun security feature to configure was a "port knocking" daemon that allows me to completely remove access to some vulnerable services. You can't attack what isn't there. Yet, when I initiate a particular sequence of events, the port knocker recognizes me, whitelists only the IP that I knocked from and then opens a port for a short time to allow me to access the requested service.

Add new comment