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.
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.
Add IP to allowed hosts:
apf -a 184.108.40.206 “Home IP”
Block IP from server:
apf -d 220.127.116.11 “Hitting login.php again and again”
Unblock a blocked IP:
apf -u 18.104.22.168
Block IP ranges:
apf -d 22.214.171.124/24 Not recommended
vi /etc/apf/deny_hosts.rules d=80:s=126.96.36.199/24 Recommended way to block IP range from accessing port 80
/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.
Allow an IP:
csf -a 188.8.131.52
Temp allow an IP:
csf -ta 184.108.40.206 15s (s – seconds / h – hours / m – minutes / d – day)
Block an IP:
csf -d 220.127.116.11
Temp block an IP
csf -td 18.104.22.168 15s (s – seconds / h – hours / m – minutes / d – day)
Unblock a permanent blocked IP:
csf -dr 22.214.171.124
Unblock a temporary blocked IP:
csf -tr 126.96.36.199
List temporary blocked IPs and durations:
Remove all temporary IP blocks:
Log all SYN packets from an IP
csf -w 188.8.131.52
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:
service csf restart
When the attack stops, disable the SYN flood protection so you don’t accidentally block legitimate connections.
By default all outbound ports are blocked. To disable this you can open the range [1:65535] in the following file:
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:
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:
Example dropped packet message:
Aug 15 07:14:39 server kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=78:2b:cb:1c:00:1d:00:02:17:2c:6c:00:08:00 SRC=184.108.40.206 DST=220.127.116.11 LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=1155 DF PROTO=TCP SPT=49528 DPT=2525 WINDOW=8192 RES=0x00 SYN URGP=0
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
In order to install CSF, the first thing you’d want to do is remove the APF installation on your server first:
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
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.
/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.