Lock Down Your Web Server: 10 Easy Steps to Stop Hackers from Attacking

You want to put out a live web server, but you don't want to be owned in the process. An expert eye for security is not needed if you take a few basic steps in locking down the hatches. Most successful attacks today are not the complex, time-consuming tasks you might think, but simple lapses in policy that a hacker can take advantage of to compromise your server.

You don't want to be the guy that gets rooted on something easy, now do you? Let's take a look at steps that can be taken at the entry level to start throwing up walls before your attackers.

Allen Freeman's Big Easy Guide to Not Getting Owned

You can look at the following list one of two ways. The first as a checklist of sorts when you are setting up your first web server. If you're already a Zen Ninja Master at doing this, obviously this guide was not written for you!

On the other hand, you could use this as a list of items to look for or keep in mind when rooting a web server—the common security issues that new users tend to overlook. Remember, one man's mistake is another man's entry point.

Step 1 Patches! Get Them!

You should be absolutely patch crazy, and this cannot be stressed enough. You should wake up in the morning, grab your coffee and look for new patches. This is the number one issue I find in the wild—unpatched services. In my Nmap article, I showed how attackers can see just what services and versions are running on target servers, and it's not hard to cross reference that with new exploits and vulnerabilities.

Debian based systems can keep current by typing:

# apt-get update && apt-get upgrade

RPM based systems can use:

# yum update

This is arguably the most simple security step you can take, outside of avoiding lame passwords. That leads us to...

Step 2 Lame Passwords: Don't Use Them

Does your password have words in it? Is it shorter then ten characters? Do you use that password in several other places? If you shook your head to any of those questions, you are doing it wrong. Fear not, because you can still do it right.

If I was the cracker, a good, solid hashed password I would hate to see would:

1. Contain no words. Using a dictionary attack will smash your password if you use words and names.
2. Be longer then 10 characters. From ten and up it becomes significantly more difficult to brute force a password. While it can be done, you are making it harder and harder. Most attackers would give up.
3. Use special characters and alternating case. This ties into the last one, as you are adding more options the cracker must try before he reaches the correct password. Again, if we make this long enough, most people will simply give up.

Step 3 Minimize Installed Software and Services to Lessen Vulnerabilities

You should get into the habit of being skeptical over all the software you have installed. I do not mean to say you should not trust it, but be mindful that new holes are discovered each day. The more you slack on Step 1 above, the more risky installed software becomes. The simple answer is to take a good look at what is there and delete or otherwise remove anything that is not needed for the function of your server.

On Debian-based systems, from the command line, you can use:

# dpkg --list
# dpkg --info [package]
# apt-get remove [package]

On RPM-based systems, you can use:

# yum list installed
# yum list [package]
# yum remove [package]

There are also a large variety of GUI programs to interface with your package managers. The usual trade off between the command line and a GUI version is functionality vs. ease of use.

Step 4 Encryption: Do You Speak It?

In my GPG article, I spoke about how to encrypt your personal files for storage or secure transfer. This applies for everyone on their home computers, but even more so on an Internet facing server. You have to make the assumption of a worst case situation at all times. If attackers are able to compromise your server and gain access to the files inside, it's another road block for them if those files are also encrypted. This is called defense-in-depth and is a key idea in protecting your network.

In fact, it's useful to compare the defense of your network and servers inside to the defense of a walled city as the same. Make your attackers have to break several layers of protection before they get to the real data. And then make them fight to get that.

Step 5 Disable All Unwanted Services from Running

Remember when I lamented about removing unwanted programs? This is the other side to that coin. Disable all unnecessary services and daemons (services that runs in the background). You need to remove all unwanted services from the system start-up. Here, we're going to use a great tool called chkconfig to take a look.

Don't have chkconfig on a Debian-based system?

$ sudo apt-get install chkconfig

Or download the source and compile with:

# ./configure
# make
# make install

Then we want to take a look at all services which are started at boot time in run level #3:

$ chkconfig --list | grep '3:on'

This runs the command with the 'list' option to format. It then pipes the output through grep with the search string of '3:on'.

As you can see here, I am running Apache as well as Tor and I2P. If this were a forward-facing web server, I would want to make sure that nothing I did not start myself and nothing that's unneeded was listed here.

Tip

• You can pipe output from one command as input into another!

You Said Ten Steps!

I know I did, but I am leaving the other five steps up to you, Null Byte! Share with me and the community the good ideas you have been using! What works? What doesn't? Our more advanced users can use this as a great opportunity to help our newer members get started.

As always, I am looking for your questions and comments! Leave me a message or visit our forum!