How to set up a safe and Secure Web Server


The hardware
You'll need some hardware, and fortunately, a personal Web server doesn't require a lot of juice. You can cobble together a server out of spare parts and it will almost certainly be enough to do the job. If you're starting from scratch, consider something like an E-350-powered Foxconn NTA350. Coupled with 4GB of RAM and a 64GB SSD, you can get rolling for about $270. There are cheaper options, too, but I used just such a setup for more than a year and I can attest to its suitability.

If you're cannibalizing or cobbling, you really don't need much. We're going to be using a Linux server distro as our server operating system, so the hardware can be minimal. An old Core 2 Duo or Pentium box gathering dust in the corner should work fine. You don't need more than 1GB of RAM, and in fact 512MB would work without issue. Ten gigabytes of storage is more than you'll ever fill unless you're going to use the server for lots of other stuff as well, so a creaky old hard drive is fine. As long as you can install your Linux distro of choice on it, it will work without issue.

Faking it with a virtual machine
If you don't have hardware available or you don't want yet another computer clogging up your closet, fear not. For home use, a virtual machine works perfectly well. In fact, a VM is exactly what you'd be issued if you go with just about any hosting provider on the planet, unless you pony up some serious dollars to have your own dedicated server. Having your own physical machine is nice, but it's not always practical. Feel free to follow along at home inside a VM.

If you don't already own a desktop virtualization product of some sort (VMware Workstation for Windows, or VMware Fusion or Parallels for OS X), there are free alternatives: VMware VSphere is full-featured and rich, but it requires you to dedicate an entire computer as a virtualization host. The company's older standalone product, VMware Server, is still available but rapidly approaching its end-of-life for support. Windows 8 and Windows Server 2012 come with a built-in hypervisor, but you need to purchase the operating systems. There's also a standalone product, Hyper-V Server, but like VSphere it requires you to dedicate a whole computer to virtualization.

The least-complex, free solution is to download and install VirtualBox. That will run on an existing Windows or OS X or Linux host and will let you run a virtualized Linux server with a minimum of fuss. I won't go through the steps of downloading and installing a virtualization solution, but it's not terribly hard.

The operating system
I've already given away the operating system choice a couple of times: the correct operating system for building a Web server is Linux or BSD. It's as simple as that. Windows Server is the correct tool for many things (particularly with Active Directory, which frankly is peerless for managing accounts, objects, and policies—OpenDirectory and other competitors are just laughably bad at scale) but building a Windows-based Web server is like bringing a blunt butter knife to a gunfight. The Internet and the services that make it run are fundamentally Unix-grown and Unix-oriented. Playing in this playground means you need a Linux or a BSD server, full stop.

Technical issues aside, it's also a practical choice. You can acquire a Linux or BSD server installation ISO for free, whereas you need to spend some amount of money to (legally) get a hold of Windows Server, either through TechNet or through buying it outright. You can grab a time-limited trial of Windows Server 2012, but even so, being locked to IIS as a Web server (or dependent on crippled Windows ports of better Web servers) means you'll be playing in the bush leagues. IIS is found running many huge and powerful websites in the world, but it's rarely selected in a vacuum; most big installations of IIS are what they are because of external dependencies or other overriding reasons. We have none of those, and so there is no reason to use IIS.

So, Linux or BSD? That choice is probably an entire article in and of itself, but I'll keep it short: I'll be talking about using a Linux distro (that is, a Unix-style operating system composed of the Linux kernel and a curated collection of tools and packages) instead of a BSD variant (that is, a Unix-style operating system composed of a unified base system and tools and packages). There are a number of reasons for choosing to go with a Linux distro over a BSD variant but the most relevant factor is that Linux distros will be easier to install because of broader, better hardware support.

Ubuntu Server it is!
I'm a fan of grabbing the current long-term release of Ubuntu Server, which as of this writing is version 12.04. A Debian-based distro like Ubuntu has an excellent and well-maintained package management system (which is the primary way you'll be installing software) and the LTS releases will continue to receive regular security patches and kernel updates for many years.

Going with the server flavor of the distro instead of a desktop flavor means that you'll end up without a GUI on the system when you're done installing it. This is a good thing. Don't fear the command line! It's faster and more efficient to edit a few configuration files to get things up and running than it is to wade through screens and screens of preference panes, clicking on options that you have to visually identify, crippled by the lack of a quick way to search for what you want. GUIs are available for the server distros if you need that crutch, but we're not going to get into them the command line is the best way to interact with your Web server and that's what we're going to use here.

You don't have to use Ubuntu, though some folks have philosophical differences with Canonical and their operating system packaging choices, and there are alternatives. Linux Mint is another Debian-based Linux distro which is easy to use, though it doesn't have a separate server variant so its default installation will include a bunch of stuff you won't need for your Web server. You could also go straight to the horse's mouth and grab Debian, though distros like Ubuntu and Mint exist at least in part because of Debian's extremely slow update cadence. The rest of this guide is going to assume you're using Ubuntu Server 12.04 LTS.


1. Use separate servers for internal and external applications.
Given that organizations typically have two, separate classes of Web applications, those serving internal users and those serving external users, it's prudent to place those applications on different servers. Doing so reduces the risk of a malicious user penetrating the external server to gain access to sensitive internal information. If you don't have the resources to implement this at your disposal, you should at least consider using technical controls (such as process isolation) to keep internal and external applications from interacting with each other.

2. Use a separate development server for testing and debugging apps.
Testing applications on a stand-alone Web server sounds like common sense -- and it is! Unfortunately, many organizations don't follow this basic principle and, instead, allow developers to "tweak" code or even develop new applications on a production server. This is a horrible idea for both reliability and security reasons. Testing code on production systems could cause users to experience malfunctions (possibly, a complete outage) and could also introduce security vulnerabilities as developers post untested code that might be vulnerable to attack. Most modern version control systems (such as Microsoft's Visual SourceSafe) can help automate the coding/testing/debugging process.

3. Audit Web site activity and store logs in a secure location.
Every security professional knows the importance of maintaining server activity logs. Since most Web servers are public facing it's critical that you perform this task for all Internet-based services. These audit trails will help you detect and react to attacks, and will enable you to troubleshoot server performance issues. In high-security environments, make sure that your logs are stored in a physically secure location the safest (but least convenient) technique is to have a line printer print the trail as it gets logged, thereby creating a permanent paper record that can't be modified by an intruder who doesn't have physical access to the premises. You may also want to consider the use of electronic equivalents, such as logging to a secure host that implements encryption with digital signatures to prevent against log snooping and modification.

4. Educate developers on sound security coding practices.
Software developers, focused on creating apps that meet business requirements, often overlook the fact that information security is a critical business requirement. As a security pro, it's your role to educate developers on the security issues that affect Web servers. You should make developers aware of the security mechanisms in place on your network to ensure that the software they create doesn't circumvent those mechanisms; also offer training on concepts such as buffer overflow attacks and process isolation -- all of which will go a long way towards ensuring sound coding practices that result in secure applications.

5. Keep your operating system and Web server patched.
This is another "common sense" item that often slips through the cracks when administrators become overburdened with other tasks. Security bulletins, such as those issued by CERT or Microsoft, are a constant reminder of how often software vendors release patches for specific security vulnerabilities. It's critical to keep your Web servers patched with current security fixes. Tools like Microsoft's Software Update Service (SUS) and RedHat's up2date service can help to automate this task. After all, once a flaw is published, if you don't fix it, someone will eventually find it and exploit it.

6. Use application scanners.
If affordable, you might want to consider the use of an application scanner to validate internally developed code. Tools like Watchfire's AppScan can help ensure that exploitable code doesn't slip through the cracks and into a production environment.