Server security best practices

A server is connected to the outside world and is open to a variety of attacks and exploits due to this. Some server security best practices can go a long way in ensuring your server does not fall victim to an attack.

A new server comes with the latest versions of software. This can help with previously found security risks. Security is an evolving process and you’ll want to follow these best practices to make sure your server is secure.

Although some of the information applies to shared, Reseller hosting, VPS, and Dedicaed plans. In order to follow some of these guidelines you would need to have root access first on your server.

Strong passwords

The first line of defense for most services that run on your server will be the password strength of your passwords.

Ensure that you are always using a strong password for anything that accesses your server. Don’t let these important credentials just lay around for anyone to see.

If you have root access on your server, if an unauthorized user logs into your server via the root user, this can be very bad. Sometimes this requires an evacuation to a new server to ensure nothing malicious was left behind.

Limit server access

Limit server access to only those that need it with the iptables firewall available on most Linux servers.

The default APF (Advanced Policy Firewall) allows easy management of your iptables rules. There is also the more advanced CSF (ConfigServer Firewall) that also controls your iptables but has a more robust feature set.

One common thing to do is close open ports in your server firewall. That way only the ports your server need to communicate to the outside world on will be accessible.

You can also enable cPHulk brute force protection on your server to automatically block users that repeatedly try to login with invalid credentials to various services.

APF – Advanced Policy Firewall

APF or Advanced Policy Firewall should be installed on your server by default. APF allows for easy management of your iptables firewall rules for things such as opening ports in your firewall.

Example commands:

Add IP to allowed hosts:

apf -a 123.123.123.123 "Home IP"

Block IP from server:

apf -d 123.123.123.123 "Hitting login.php again and again"

Unblock a blocked IP:

apf -u 123.123.123.123

Block IP ranges:

Note recommended:

apf -d 123.123.123.123/24

Recommended way to block IP range from accessing port 80:

vi /etc/apf/deny_hosts.rules d=80:s=123.123.123.123/24

APF File Locations:

• /etc/apf – Location of APF core files
• /etc/apf/conf.apf – Main APF config file, contains options and allowed port definitions
• /etc/apf/allow_hosts.rules – List of allowed IP addresses and ranges
• /etc/apf/deny_hosts.rules – List of denies (blocked) IP addresses and ranges
• /etc/apf/bt.rules – Rules based on conditions set in conf.apf, should not be edited manually unless required
• /var/log/apf_log – Logs the output of APF start/stop/restart processes only

CSF – ConfigServer Firewall

CSF or ConfigServer Firewall is also allows for easy iptables management. CSF is more recent and a bit more robust than APF. It allows for temporary blocking of IPs, and has both SYN flood protection to help against SYN flood DDoS attacks, as well as LFD which is the built-in module that deals with brute-force login protection.

Example commands:

Allow an IP:

csf -a 123.123.123.123

Temp allow an IP:

csf -ta 123.123.123.123 15s (s - seconds / h - hours / m - minutes / d - day)

Block an IP:

csf -d 123.123.123.123

Temp block an IP

csf -td 123.123.123.123 15s (s - seconds / h - hours / m - minutes / d - day)

Unblock a permanent blocked IP:

csf -dr 123.123.123.123

Unblock a temporary blocked IP:

csf -tr 123.123.123.123

List temporary blocked IPs and durations:

csf -t

Remove all temporary IP blocks:

csf -tf

Log all SYN packets from an IP:

csf -w 123.123.123.123

SYN flood protection

CSF’s SYN flood protection counts the number of SYN packets of each TCP connection, if it hits the default limit of 10 per second it will close the connection. This should free the network tables on the server from maintaining a bunch of half-open connections which could lead to additional connections to the server being denied.

To enable CSF SYN flood protection while a suspected attack is going on:

vi /etc/csf/csf.conf

Then add this:

SYNFLOOD=1

Run this command to restart CSF:

service csf restart

When the attack stops, disable the SYN flood protection so you don’t accidentally block legitimate connections.

Opening Ports

By default all outbound ports are blocked. To disable this you can open the range [1:65535] in the following file:

• /etc/csf/csf.conf

Port ranges are separated by colons 1:100 in the following areas: TCP_IN, UDP_IN, UDP_OUT, and TCP_OUT.

Enable LFD Brute Force protection

You can enable the LFD brute force protection by editing:

vi /etc/csf/csf.conf

Then adding this:

LF_DAEMON=1

You can use the LF_* settings down further in the file to set the login limits for each service on the server.

Reading the CSF log

When an IP has a packet dropped, it should be logged to:

• /var/log/messages

Example dropped packet message:

Log key:

• IN – The interface
• SRC – The IP attempting to connect
• DST – The IP being connected to (the local server)
• PROTO – Protocol used (TCP/UDP)
• SPT – Source port DPT : Destination port

Install CSF

In order to install CSF, the first thing you’d want to do is remove the APF installation on your server first:

Remove APF

service apf stop chkconfig --del apf rm -f /etc/init.d/apf rm -f /usr/local/sbin/apf rm -rf /etc/apf

Remove WHM Add IP to firewall feature

rm -rf /usr/local/cpanel/whostmgr/cgi/apfadd rm -f /usr/local/cpanel/whostmgr/cgi/addon_add2apf.cgi

Install CSF

InMotion Hosting customers:

yum install -y csf-ded

On any server:

• Download CSF source from ConfigServer CSF.

Lost server access

In some cases CSF might lock out your access to the server. If this happens, you should be able to log into WHM and navigate to ConfigServer Security & Firewall, and temporarily disable CSF/LFD so you can log back in.

CSF File Locations:

• /etc/csf – Location of CSF core files
• /etc/csf/csf.conf – Main CSF config file, contains options and allowed port definitions
• /etc/csf/csf.allow – List of allowed IP addresses and ranges
• /etc/csf/csf.deny – List of denies (blocked) IP addresses and ranges
• /etc/csf/csf.tempban – Dynamically-updated list of temporarily-blocked IPs
• /var/log/messages – Where CSF logs its actions
• /etc/csf/csf.gallow – Global allow list (is generated automatically)
• /etc/csf/csf.gdeny – Global deny list (is generated automatically)
• /etc/csf/csf.gignore – Global ignore list (is generated automatically)

Limit website access

You should review website access logs for unwanted activity and to block unwanted users from your website if you find any. Blocking bad users at the website level is a good step before blocking them in your server’s firewall.

We have an entire section dedicated to keeping tabs on server usage and for ways of finding and taking care of malicious activity that you will probably want to review and bookmark.

If you are using a CMS such as WordPress to run your website, make sure you’re protected from things like a WordPress Brute Force attack so you admin dashboard is safe as well.

Login to your server securely

To securely connect to your server directly, you can use SSH (Secure Shell) which encrypts your data.

By default, no outside IP addresses will be allowed to connect via SSH to your server for better security. So you will first want to add your IP to the server firewall so that you are able to connect.

Secure file management

When working with files on your server especially from a shared network, it’s important to encrypt your login credentials so they are not passed in clear-text. You can also always disable FTP clear/plain-text authentication server-wide to force everyone connecting to your server to use a secure protocol.

You can use the underlying SSH technology to securely connect over port 22 on the server with SCP and SFTP.

You can also securely use FTP over SSL with the FTPS protocol.

Secure application logins

On a server some common applications you might access would be cPanel, WHM, and webmail. Each service can be connected to securely so you’re not transmitting any plain-text data between your computer and the server.

Insecure cPanel application logins

These default server application’s can be accessed from any web-browser and pass credential data in plan-text when accessed from one of these insecure URLs:

• https://example.com/cpanel – cPanel
• https://cpanel.example.com – cPanel
• https://example.com/whm – WHM
• https://whm.example.com – WHM
• https://example.com/webmail – Webmail
• https://webmail.example.com – Webmail

Secure cPanel application logins

To access these same services on your server over https, so that your credentials are encrypted and transmitted securely you would use these URLs:

• https://example.com:2083 – cPanel
• https://example.com:2087 – WHM
• https://example.com:2096 – Webmail

You can login to WHM and then navigate to Tweak Settings > Redirection and turn on Always redirect to SSL to force all cPanel applications to use https by default.

If you didn’t buy a SSL certificate for your server, you might get a self-signed SSL certificate warning which is fine, your connection is still encrypted.

Other server application logins

Anytime you install another application on your server, which could be as simple as a PHP script you’ve uploaded. You could possibly be opening up a way for attackers to get into your server.

Always make sure that any application you’re using on your server is locked down with at least a username and password, and if possible try to access those applications via a secure login form over https.

Make your server secure enough to handle credit card data

It’s recommended to follow the PCI DSS (Payment Card Industry Data Security Standard) guidelines for server security as well. These are the requirements that your server must meet security wise in order to pass a PCI scan, which allows you to accept credit cards and store that information directly on your server securely.

In some cases the security recommendations could be overkill for general purpose websites. But when it comes to the security of your server it’s always better to be safe than sorry. You can look at our article on how to pass PCI compliance scans for more information on the common things you can do to help further secure your server.

General application security and updates

The most common way that a server’s security is compromised is actually by the 3rd party applications that you load onto your server having an exploit in them. It’s important to stay very vigilant in keeping up with your application’s security updates, as well as any plugins, themes, or other add-on updates that you’re using for that application.

Because these applications are on the Internet and accessible from anywhere, they typically are targeted again and again by hackers until they’re able to find an exploit that allows them access. Once this information is known to the public the application’s developer will typically patch the exploit with a newer version, when you don’t upgrade to the latest version provided by your application you run the risk of being hacked.