It’s getting easier and easier to set up and run your own web server these days. Popular service provider’s such as Rackspace, Amazon and VPS.net (UK based) make it incredibly quick and simple to set up your own server in the cloud within minutes. Once you’ve set up an account you will often find the ability to install a popular Linux distro with a basic LAMP set-up. Things that seem to be frequently overlooked by newer users however is security and optimisation, as these will not be set-up for you.

I will mention no specifics to what leads me to believe this, as doing so could alert the world to such sites I know to be at risk, but I know for a fact that there are a fair few servers that are remarkably vulnerable. This article/guide (your choice) will provide simple steps to ensure that your server isn’t compromised or taken down.

Batten down the hatches

Firewalls were created for a reason, to close off unused ports and prevent Brute Force attacks. Now, for different servers I have different methods of closing off connections. For live servers I would recommend using iptables. There’s no great explanation to follow iptables, it is simply a tool which allows you to specify which ports you wish to close and leave open. I won’t go into details about obtaining iptables, but it will most likely be in your distro’s repos (apt-get install iptables, yum install iptables etc etc). The command can be used directly from CLI, however and commands you enter will be lost upon a reboot, as such I would suggest writing a script. The code below is an example of what runs on one machine that I use:

#!/bin/bash
# Flush all current rules from iptables, useful if running script without reboot
 iptables -F

# Allow all connections from trusted IP Addresses

iptables -A INPUT -s (ipaddress here) -j ACCEPT # Home
iptables -A INPUT -s (ipaddress here) -j ACCEPT # Friend's house
iptables -A INPUT -s (ipaddress here) -j ACCEPT # Other random static IP

# Open Services Here

iptables -A INPUT -p tcp --dport 80 -j ACCEPT # Your web server, Nginx, Apache, lighttpd etc
iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -m state --state  NEW,ESTABLISHED,RELATED -j ACCEPT # Ping

# Block anything else inbound, but allow all outbound connections

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Set access for localhost

iptables -A INPUT -i lo -j ACCEPT

# Accept packets belonging to established and related connections

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Save settings

iptables-save

# List rules

iptables -L

Now we have our script ready (assuming you’ve edited it to meet your needs) save it somewhere on your server. The process for making a script run on boot differs between Linux Distros, I mainly use Debian & Ubuntu so I assume you are too, if not try searching for some info.

Open up /etc/rc.local:

sudo nano /etc/rc.local

Once opened, add the following line before “exit 0″:

sh *location to script*

That’s it, sorted. However iptables won’t be too useful if you’re non a Dynamic IP address as you can’t predict what address you will have at a specific time. Although I do have a static IP address, I do find it useful to have one box that I can connect to at all times (which I don’t allow access to any of my other machines). To secure this machine, I use Fail2Ban.

Fail2Ban

Unlike iptables, where a connection is refused outright, Fail2Ban will allow a user only a limited number of chances to connect to your services. For example, you could allow a user only 3 chances of getting the login correct for SSH, if they cannot they get added to the Jail (via iptables).

Installation should be fairly straight-forward, I can’t vouch for this one being in your repo’s but it seems to be in Ubuntu! Once installed, locate your config file (usually /etc/fail2ban/jail.conf). I can’t be bothered to explain how this config file works, as it is fairly self-explanatory. One thing I must mention about Fail2Ban is that on reboot of your server, the record of banned IP’s will be lost! This is a rather large anoyance, one that I will attempt to resolve in another article shortly.

P.S This was going to also include optimisation information for your web server, this will branch off into another guide.