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

10 Easy Steps to Stop Hackers from Attacking

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!

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

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'.

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

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.


  • 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!

Image by SiliconAngle, Technews


It is worth noting that a password containing characters from the 95 standard visible ascii characters that is 10 characters long is marginally less secure than a character containing only the 26 lowercase alphabet letters with a length of 14. It is in fact a LOT less secure than something with just lowercase and 15 characters. Length means more than character set, considerably so.

It may also be worth mentioning that there is a difference between "contains a dictionary word", "is based on a dictionary word", and "is a dictionary word". This is directly related to the post above. Cracking the hash of "Cracking" will take mere moments with a dictionary attack, and "Cr@ck1n9" while better may still be in an augmented dictionary, and while it could take about 49 days to bruteforce, "lolthisisasillylongpassword" will probably not be in a dictionary and could take about 20 sextillion years to bruteforce.

Just something to think about while making passwords.

This. An excellent point.

6. Restrict outbound traffic from your server with an external firewall. If there is no reason that your server needs to initiate connections to anything other than a handful of external resources (DNS, patching servers, etc) then restrict access to those hosts/services alone.

7.Use the tools that your distro provides:

Enable the host based firewall and lock down access to the non-public services on your box (e.g. SSH, SNMP).You can use a front end tool to simplify configuration should you wish (e.g. APF - http://www.rfxn.com/projects/advanced-policy-firewall/)
Enable AppArmor/SELinux or your distros equivalent. These packages restrict the actions that installed applications may take. In the case of those examples you may put the product in a 'learning mode' and iron out any problems before switching to enforcing mode. A bit of general overview may be seen here:

8. Run a regular scan for malware/viruses. If the server does get compromised then this has a chance at detecting it. Rkhunter: http://www.rootkit.nl/projects/rootkit_hunter.html, ClamAV: http://www.clamav.net/

9. Check for file changes on a regular (at least daily) basis. This is another excellent way of detecting if someone has gained access to your server. AFICK is one of many possible tools - http://afick.sourceforge.net/

10. Check your logs. You don't necessarily need to do that by hand and can export a copy of log data to a central server and set that up to alert you for non-standard log entries or specific events (e.g. login failures). Splunk (www.splunk.com) provide a free version of their logging server software that allows you to log up to 500 MB per day, though you need to go for version 3.x if you want it to email triggered alerts.

11. If using Apache webserver then check out mod_security, an essential application layer firewall - http://www.modsecurity.org/projects/modsecurity/apache/

Expanding on BirdandBear's (admittedly pretty comprehensive) comment: https://www.grc.com/haystack.htm - the two and a half minute video linked there is worth watching.

Oops wrong link - it's the 37 minute audio file that's the interesting bit. http://media.grc.com/Padded-Passwords-lq.mp3

Share Your Thoughts

  • Hot
  • Latest