Monday, November 23, 2009

Basic cPanel Server Hardening - Part 2

In Part 1 I explained why securing a server is important and the general steps I would take you through to secure your server. In this installment I will go into detail about installing and configuring a software firewall. A dedicated firewall device can give you added security, but they are often not an option for the small web hosting providers this series is targeted at.

A properly configured firewall is literally a defensive wall between a server and the internet. You can poke small holes in the wall to allow traffic to flow only where you want it to, and you can prevent traffic from specific addresses from accessing the server at all.

I use Advanced Policy Firewall (APF) which makes installation and configuration simple. Execute these commands to download and install it. You may need to change the version number in the third command if APF has been updated.

wget http://www.rfxn.com/downloads/apf-current.tar.gz
tar -xzf apf-current.tar.gz
cd apf-9.7-1  # current version number as of this post
sh install.sh

Initially APF is configured to block all services except SSH. To enable a service you must open the port the service uses for communication. I like to document which services I have enabled and what ports they use right in the configuration file so I can tell quickly what is and what is not enabled when I need to make changes.

Open the file /etc/apf/conf.apf in a text editor then find the line that sets the allowed TCP inbound ports by searching for IG_TCP_CPORTS. Replace this line with the following:

# Common inbound (ingress) TCP ports
# 20    ftp
# 21    ftp
# 22    ssh
# 25    smtp
# 53    dns
# 80    http
# 110   pop3
# 143   imap
# 443   https
# 465   smtps
# 993   imaps
# 995   pop3s
# 2083  cpanel secure
# 2096  webmail

IG_TCP_CPORTS="20, 21, 22, 25, 53, 80, 110, 143, 443, 465, 993, 995, 2083, 2096"

I have intentionally kept cPanel's WHM interface blocked by the firewall. WHM provides a web interface with control over almost the entire server, so keeping it blocked by the firewall helps reduce the risk to the server. I will show you how your can access it later in this article.

Next find the line that sets the allowed UDP inbound ports by searching for IG_UDP_CPORTS and replace it with the following:

# Common inbound (ingress) UDP ports
# 53    dns

IG_UDP_CPORTS="53"

By default the firewall allows all outbound traffic, but it is more secure to restrict outbound traffic as well. To enable outbound filtering find the line EGF="0" and change it to EGF="1". You do not have to allow all the inbound services you defined, once a connection is established two way traffic is allowed. Find the line that sets the allowed TCP outbound ports by searching for EG_TCP_CPORTS and replace it with the following:

# Common outbound (egress) TCP ports
# 21    ftp
# 25    smtp
# 37    rdate
# 43    whois
# 53    dns
# 80    http
# 443   https

EG_TCP_CPORTS="21, 25, 37, 43, 53, 80, 443"

Next find the line that sets the allowed UDP outbound ports by searching for EG_UDP_CPORTS and replace it with the following:

# Common outbound (egress) UDP ports
# 20    ftp
# 21    ftp
# 53    dns
# 123   ntpd

EG_UDP_CPORTS="20, 21, 53, 123"

Now it is time to test the changes to the firewall configuration you have made. To start APF execute the command /etc/init.d/apf restart. By default when you start APF it will only run for about 5 minutes and then shut itself off. This allows you to test your configuration without completely locking yourself out of the server if something is wrong. If you are unable to access your server after starting APF for the first time just wait a few minutes and try again.

When you are done testing your configuration edit the file /etc/apf/allowed_hosts.rules and add your IP address. This tells APF to always allow you full access to the server so you don't get locked out. 

The final configuration change is to switch APF from development mode to production mode. Edit /etc/apf/conf.apf again and change DEVEL_MODE="1" to DEVEL_MODE="0".

If you have followed the instructions in this article you now have a firewall protecting your server. This is just a basic firewall configuration, but it is better than no firewall at all. In the next article I will show you how to detect brute force intrusion attempts and block them using the firewall.

Wednesday, November 18, 2009

I'd Rather Be There



I'd much rather be sitting by the water on Ocracoke Island. I am naturally drawn to water, especially the ocean. I've been going almost every year since my first trip in 2004. When I am there I spend a lot of time enjoying views like this one. Watching the Windfall make it's regular journeys, the ferries bringing loads of excited tourists to the island and leaving with fully relaxed ones.

For me relaxation is the name of the game on Ocracoke. Sure, I like playing in the water and the great burgers at SMackNally's, but I like sitting on the beach or on my rented deck watching the water just as much. I miss the island as soon as I start heading for the ferry docks to head home. After about 6 months I really start looking forward to my next trip, and if I go more than a year without some island time I become very tempted to get in the Jeep and head east.

Saturday, November 14, 2009

Basic cPanel Server Hardening - Part 1

A friend of mine who runs a small web hosting company recently had his server taken offline by his provider. It was taken offline due to the server hosting "several" phishing sites. He had no idea that he was hosting these phishing sites, only that an account had been compromised and a site defaced, which is all that many people notice when this happens to them.

I am not a security expert, far from it in fact. I am however the only person my friend had to turn to for help in this situation. I've set up many Linux servers over the years, many of them dedicated single purpose servers and a few for shared hosting like my friend's. One thing I do know about server security is that there is no such thing as a truly secure server. It is a balancing act between keeping the server secure and allowing users to make use of it.

The hosting provider insisted we rebuild the server, which makes sense. Hackers generally try to cover their tracks once they compromise a system. To be certain all of the damage done by the hacker a full re-install of the operating system is the best way to go. Since we needed to re-install and the hardware was at the End of Life stage we decided to replace it with newer hardware instead of rebuilding on the out dated hardware. Once the hosting provider had finished installing Linux with cPanel for us and turned it over to us the process of securing the server began.

In upcoming posts I will be detailing the steps I took to secure the new server. I will go over installing a Firewall, important system tweaks, detecting brute force login attempts, detecting root kits when they get installed, and adjusting cPanel for security. I will only be going over the basic steps of securing a server, if you are interested in security there are many books available, or for more up to date information use Google.