Linux Server Security – Best Practices for 2021

Linux Server Security

Linux server security is on sufficient level from the moment you install the OS. And that’s great to know because… hackers never sleep! They’re kind of like digital vandals. Taking pleasure – and sometimes money too – as they inflict misery on random strangers all over the planet.

Anyone who looks after their own server appreciates the fact that Linux is highly secure right out the box. Naturally, it isn’t completely watertight. But it does do a better job of keeping you safe than most other operating systems.

Still, there are plenty of ways you can improve it further. So here are some practical ways how you can keep the evil hordes from the gates. It will probably help if you’ve tinkered under the hood of a web server before. But don’t think that you have to be a tech guru or anything like that.

Deactivate network ports when not in use

Deactivate network ports when not in use

Leave a network port open and you might as well put out the welcome mat for hackers. To maintain web host security you can use the “netstat” command to inform you which network ports are currently open. And also which services are making use of them. This should close off another avenue of attack for hackers.

You also might want to set up “iptables” to deactivate open ports. Or simply use the “chkconfig” command to shut down services you won’t need. Firewalls like CSF let you automate the iptables rules, so you could just do that. If you use Plesk platform as your hosting management software – please pay attention to this article about Plesk ports.

The SSH port is usually 22, and that’s where hackers will expect to find it. To enhance Linux server security, change it to some other port number you’re not already using for another service. This way, you’ll be making it harder for the bad guys to inject malware into your server. To make the change, just go to /etc/ssh/sshd_config and enter the appropriate number.

Update Linux Software and Kernel

Update software for better Linux server security

Half of the Linux security battle is keeping everything up to date because updates frequently add extra security features. Linux offers all the tools you need to do this, and upgrading between versions is simple too. Every time a new security update becomes available, you need to review it and install it as soon as you can. Again, you can use an RPM package manager like yum and/or apt-get and/or dpkg to handle this.

# yum update


# apt-get update && apt-get upgrade

It’s possible to set up RedHat / CentOS / Fedora Linux so that you get yum package update notifications sent to your email. This is great for Linux security and you can also apply all security updates using a cron job. Apticron can be used to send security mitigations under Debian / Ubuntu Linux. You can also use the apt-get command/apt command to configure unattended-upgrades for your Debian/Ubuntu Linux server:

$ sudo apt-get install unattended-upgrades apt-listchanges bsd-mailx

Reduce Redundant Software to Increase Linux Security

For greater Linux server security hardening It’s worth doing a spring clean (at any time of the year) on your installed web services. It’s easy for surplus apps to accumulate and you will probably find that you don’t need half of them. In the future, for better Linux server security try not to install software that you don’t need. It’s a simple and effective way to reduce potential security holes. Use an RPM package manager like yum or apt-get and/or dpkg to go through your installed software and remove any that you don’t need any more.

# yum list installed
# yum list packageName
# yum remove packageName


# dpkg --list
# dpkg --info packageName
# apt-get remove packageName

Turn off IPv6 to boost Linux server security

Turn off IPv6

IPv6 is better than IPv4, but you probably aren’t getting much out of it – because neither is anyone else. Hackers get something from it though – because they use it to send malicious traffic. So shutting down IPv6 will close the door in their faces. Go to edit /etc/sysconfig/ network and change the settings to read NETWORKING_ IPV6=no and IPV6INIT=no. Simple as that.

Turn off root logins to improve Linux server security

Linux servers the world over allow the use of “root” as a username. Knowing this, hackers will often try subverting web host security to discover your password before slithering inside. It’s because of this that you should not sign in as the root user. In fact, you really ought to remove it as an option, creating one more level of difficulty for hackers. And thus, stopping them from being able to get past your security with just a lucky guess.

So, all it takes is for you to create a separate username. Then use the “sudo” special access command to execute root level commands. Sudo is great because you can give it to any users  you want to have admin commands, but not root access. Because you don’t want to compromise security by giving them both.

So you deactivate the root account, but before, check you’ve created and authorized your new user. Next, go to /etc/ssh/sshd_config in nano or vi, then locate the “PermitRootLogin” parameter. Change the default setting of “yes” to “no” and then save your changes.

GnuPG encryption for web host security

GnuPG encryption

When data is on the move across your network, hackers will frequently attempt to compromise Linux server security by intercepting it. Always make sure anything going to and from your server has password encryption, certificates and keys. One way to do this is with an encryption tool like GnuPG. It uses a system of keys to ensure nobody can snoop on your info when in transit.

Change/boot to read-only

All files related to the kernel on a Linux server are in the “/boot” directory. The standard access level for the directory is “read-write”, but it’s a good idea to change it to “read-only”. This stops anyone from modifying your extremely important boot files.

Just edit the /etc/fstab file and add LABEL=/boot /boot ext2 defaults, rows 1 2 to the bottom. It is completely reversible, so you can make future changes to the kernel by changing it back to “read-write” mode. Then, once you’re done, you can revert back to “read only”.

A better password policy enhances Web Host Security

better password policy - linux server security

Passwords are always a security problem because humans are. People can’t be bothered to come up with a lot of different passwords – or maybe they can’t. So what happens? They use the same ones in different places. Or worse yet – combinations that are easy to remember, like “password” or “abcde”. Basically, a gift to hackers.

Make it a requirement for passwords to contain a mix of upper AND lower case letters, numbers, and symbols. You can enable password ageing to make users discard previous passwords at fixed intervals. Also think about banning old passwords, so once people use one, it’s gone forever. The “faillog” command lets you put a limit on the amount of failed login attempts allowed and lock user accounts. This is ideal to prevent brute force attacks.

So just use a strong password all the time

Passwords are your first line of defense, so make sure they’re strong. Many people don’t really know what a good password looks like. That it needs to be complex, but also long enough to make it the strongest it can be.

At admin level, you can help users by securing Plesk Obsidian and enforcing the use of strong passwords which expire after a fixed period. Users may not like it, but you need to make them understand that it saves them a lot of possible heartache.

So what are the ‘best practices’ when setting up passwords?

  1. Use passwords that are as long as you can manage
  2. Avoid words that appear in the dictionary (like “blue grapes”)
  3. Steer clear of number replacements that are easy to guess (like “h3ll0”)
  4. Don’t reference pop culture (such as “TARDIS”)
  5. Never use a password in more than once place
  6. Change your password regularly and use a different one for every website
  7.  Don’t write passwords down, and don’t share them. Not with anybody. Ever!

The passwords you choose should increase Web Host Security by being obscure and not easy to work out. You’ll also help your security efforts if you give your root (Linux) or RDP (Windows) login its own unique password.

Linux security security needs a firewall

Firewall helps Linux server security - Plesk

A firewall is a must have for web host security, because it’s your first line of defense against attackers, and you are spoiled for choice. NetFilter is built into the Linux kernel. Combined with iptables, you can use it to resist DDos attacks.

TCPWrapper is a host-based access control list (ACL) system that filters network access for different programs. It has host name verification, standardized logging and protection from spoofing. Firewalls like CSF and APF are also widely used, and they also come with plugins for popular panels like cPanel and Plesk.

Locking User Accounts After Unsuccessful Logins

For Linux security, the faillog command shows unsuccessful login attempts and can assign limits to how many times a user can get their login credentials wrong before the account is locked. faillog formats the contents of the failure log from the /var/log/faillog database/log file. To view unsuccessful login attempts, enter:


To open up an account locked in this way, run:

faillog -r -u userName

With Linux security in mind be aware that you can use the passwd command to lock and unlock accounts:

lock Linux account

passwd -l userName

unlock Linux account

passwd -u userName

Try disk partitions for better Web host security

disk partitions - linux server security

If you partition your disks then you’ll be separating OS files from user files, tmp files and programs. Try disabling SUID/SGID access (nosuid) along with binaries (noexec) on the operating system partition

Avoid Using Telnet, FTP and Rlogin/Rsh Services

With the majority of network configurations, anyone on the same network with a packet sniffer can intercept FTP, telnet, or rsh commands, usernames, passwords, and transferred files. To avoid compromising Linux server security try using either OpenSSH, SFTP, or FTPS (FTP over SSL), which gives FTP the benefit of SSL or TLS encryption. To move outdated services like NIS or rsh enter this yum command:

# yum erase xinetd ypserv tftp-server telnet-server rsh-server

For Debian/Ubuntu Linux server security, give the apt-get command/apt command a try to get rid of non-secure services:

$ sudo apt-get --purge remove xinetd nis yp-tools tftpd atftpd tftpd-hpa telnetd rsh-server rsh-redone-server

Use an Intrusion Detection System

NIDS or Network intrusion detection systems keep watch for malevolent activity against Linux server security like DOS attacks, port scans, and intrusion attempts.

For greater Linux server security hardening it’s recommended that you use integrity checking software before you take a system into a production environment online. You should install AIDE software before connecting the system to a network if possible. AIDE is a host-based intrusion detection system (HIDS) which monitors and analyses a computing system’s internals. You would be wise to use rkhunter rootkit detection software as well.

Logs and Audits

You can’t manage what you don’t measure, so if you want to stop hackers then your system needs to log every single time that intruders try to find a way in. Syslog is set up to store data in the /var/log/ directory by default and it can also help you to identify the potential surreptitious routes inside that misconfigured software can present.

Secure Apache/PHP/NGINX server

Edit httpd.conf file and add:

ServerTokens Prod
ServerSignature Off
TraceEnable Off
Options all -Indexes
Header always unset X-Powered-By

Restart the httpd/apache2 server on Linux, run:

$ sudo systemctl restart apache2.service


$ sudo systemctl restart httpd.service

Activate CMS auto-updates

Activate CMS auto-updates

CMSs are quite complex, so hackers are always trying to exploit security loopholes with them. Joomla!, Drupal and WordPress, are all hugely popular platforms, so developers are constantly working on new security fixes. This means updates are important and should be applied straight away. The best way to ensure this happens is to activate auto-updates, so you won’t even have to think about it. Your host isn’t responsible for the content of your website. So it’s up to you to ensure you update it regularly. And it won’t hurt to back it up once in a while either.

Backup regularly

Backup regularly - linux server security - cloud

Regular and thorough backups are probably your most important security measure. Backups can help you recover from a security disaster. Typical UNIX backup programs use dump and restore, and these are we recommend them. For maximum Linux security, you need to backup to external storage with encryption, which means something like a NAS server or cloud-based service.

Protect Email Directories and Files

These Linux security tips wouldn’t be complete without telling you that Linux has some great ways to protect data against unauthorized access. File permissions and MAC are great at stopping intruders from getting at your data, but all the Linux permissions in the world don’t count for anything if they can be circumvented—for instance, by transplanting a hard drive to another machine. In such a case you need to protect Linux files and partitions with these tools:

  • For password-protected file encryption and decryption, use the gpg
  • Both Linux and UNIX can add password protection to files using openssl and other tools.
  • The majority of Linux distributions support full disk encryption. You should ensure that swap is encrypted too, and only allow bootloader editing via a password.
  • Make sure root mail is forwarded to an account that you check.

System Accounting with auditd

Auditd is used for system audits. Its job is to write audit records to the disk. This daemon reads the rules in /etc/audit.rules at start-up. You have various options for amending the /etc/audit.rules file such as setting up the location for the audit file log. Auditd will help you gain insight into these common events:

  • Occurrences at system startup and shutdown (reboot/halt).
  • Date and time an event happened.
  • The user who instigated the event (for example, perhaps they were attempting to access /path/to/topsecret.dat file).
  • Type of event (edit, access, delete, write, update file, and commands).
  • Whether the event succeeded or failed.
  • Records events that Modify time and date.
  • Discover who modified network settings.
  • Record actions that change user or group information.
  • Show who changed a file etc.

Use Kerberos

Kerberos is a third-party service offering authentication that aids Linux security hardening. It uses shared secret cryptography and assumes that packets moving on a non-secure network are readable and writable. Kerberos is based on symmetric-key cryptography and so needs a key distribution center. Kerberos lets you make remote login, remote copy, secure inter-system file copying, and other risky actions safer and it also gives you more control over them. Kerberos authentication prevents unauthorized users from spying on network traffic and grabbing passwords.

Hardening Security Of Your Linux Server Using Plesk

Linux Server Security Summary

That’s a lot of tips, but you need to keep your linux server security updated in a world of thieves and vandals. These despicable beings are hard at work all the time, always looking to exploit any chink in a website’s armor. If you give them the slimmest opportunity to disrupt your business, they will happily take advantage of it. Since there’s such a huge army of them, you need to make sure that your castle has extremely strong defenses.

Let us know how many of these tips you have implemented, or if you have any questions in the comments below.

Using Fail2ban to Secure Your Server

Fail2Ban guide Plesk blog

Meet Fail2ban. This log-parsing application is designed to monitor system logs and recognize signs that indicate automated attacks on your VPS instance.

By the time you reach the last line of this tutorial, you’ll have a better understanding of how to use Fail2ban to keep your server secure.

When Fail2ban identifies and locates an attempted compromise using your chosen parameters, it will add a new rule to iptables to block the IP address from which the attack originates. This restriction will stay in effect for a specific length of time or on a long-term basis. You can also set your Fail2ban configuration to ensure you’re notified of attacks via email as they occur.

While Fail2ban is mainly designed to focus on SSH attacks, you can also experiment with Fail2ban configuration to suit any service that utilizes log files and is at potential risk of being compromised.

Fail2ban Installation – A Step-By-Step Walkthrough

Setup on CentOS 7

  1. Make sure that your system has been updated as required and start the EPEL repository installation:

  2. yum update && yum install epel-release

  3. Proceed with the Fail2Ban installation:

  4. yum install fail2ban

  5. If you want to receive email support, begin the Sendmail installation. But be aware: Sendmail is not mandatory if you wish to take advantage of Fail2Ban.:

  6. yum install sendmail

  7. Start and enable Fail2ban (as well as Sendmail, if you want to use that too):

  8. systemctl start fail2ban

  9. systemctl enable fail2ban

  10. systemctl start sendmail

  11. systemctl enable sendmail

Please be aware:

In case you’re confronted by this error: no directory /var/run/fail2ban to contain the socket file /var/run/fail2ban/fail2ban.sock, you’ll need to set up the directory through a manual process instead:

mkdir /var/run/fail2ban

Setup on Debian

  1. Confirm that your system is updated and ready:

  2. apt-get update && apt-get upgrade -y

  3. Proceed with Fail2ban installation:

  4. apt-get install fail2ban

Now, the service will start automatically.

  1. (Optional step) For email support, start the Sendmail installation:

  2. apt-get install sendmail-bin sendmail

Please be aware:

In its present iteration, Sendmail in Debian Jessie includes an upstream bug known to trigger a number of errors (see below) as a result of installing sendmail-bin. The installation will pause for a brief period before it reaches completion. Errors:

Creating /etc/mail/

ERROR: FEATURE() should be before MAILER() MAILER('local') must appear after FEATURE('always_add_domain')

ERROR: FEATURE() should be before MAILER() MAILER('local') must appear after FEATURE('allmasquerade')

Setup on Fedora

  1. Ensure that your system has been updated before you proceed, with:

  2. dnf update

  3. Start the Fail2ban installation:

  4. dnf install fail2ban

  5. (Optional step) You can proceed with the Sendmail installation step if you would prefer email support:

  6. dnf install sendmail

  7. Start and enable Fail2ban (along with Sendmail, as you see fit):

  8. systemctl start fail2ban

  9. systemctl enable fail2ban

  10. systemctl start sendmail

  11. systemctl enable sendmail

Setup on Ubuntu

  1. Check that your system has been updated:

  2. apt-get update && apt-get upgrade -y

  3. Continue with the Fail2ban installation:

  4. apt-get install fail2ban

You’ll see that the service will start automatically.

  1. (Optional step) Install Sendmail if you want email support:

  2. apt-get install sendmail

  3. Grant SSH access via UFW before you proceed with enabling the firewall:

  4. ufw allow ssh

  5. ufw enable


The Fail2ban Configuration Process

In this next part of this tutorial, you’ll find a number of examples exploring popular Fail2ban configurations utilizing fail2ban.local and jail.local files. Fail2ban will read.conf configuration files initially before .local files override any settings.

As a result, any configuration adjustments tend to be performed in .local files while the .conf files remain unaffected.

How to Configure fail2ban.local

  1. fail2ban.conf carries the default configuration profile, and these standard settings offer a decent working setup. However, if you would prefer to create any edits, you should do this in a separate file (fail2ban.local). This will override fail2ban.conf. Be sure to rename a copy fail2ban.conf to fail2ban.local.

  2. cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local

  3. From this point, you may choose to adjust the definitions located within fail2ban.local to align with the configuration you want to set up. You can change the following values:

    • loglevel: You can set the detail level provided by the Fail2ban logs to: 1 (error), 2 (warn), 3 (info), or 4 (debug).

    • logtarget: This will log actions in a defined file (the default value of /var/log/fail2ban.log adds all logging into it). On the other hand, you could edit the value to:

      • STDOUT: output any data

      • STDERR: output any errors

      • SYSLOG: message-based logging

      • FILE: output to a file

    • socket: The socket file’s location.

    • pidfile: The PID file’s location.

How to Configure the Fail2ban Backend

  1. By default, the jail.conf file enables Fail2ban for SSH for Debian and Ubuntu, though not for CentOS. Alternative protocols and configurations (such as FTP, HTTP, and so on) will be commented out. You can adjust this if you wish. You’ll need to make a jail.local for editing:

  2. cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

  3. Do you use Fedora or CentOS? You’ll have to switch the backend option in jail.local from auto  to systemd . Be aware, though, that this isn’t needed on Debian 8 or Ubuntu 16.04, despite both being capable of using systemd too.

File: /etc/fail2ban/jail.local

# "backend" specifies the backend used to get files modification.

# Available options are "pyinotify", "gamin", "polling", "systemd" and "auto".

# This option can be overridden in each jail as well.

. . .

backend = systemd

Please be aware:

When the backend configuration has been set to auto, Fail2ban will monitor log files by utilizing pyinotify first. After this, Fail2ban will attempt gamin. However, if neither is available, a polling algorithm will choose the next attempt.

By default, there are no jails enabled in CentOS 7. For instance, if you wish to proceed with enabling the SSH daemon jail, you should uncomment these lines in jail.local:

File: /etc/fail2ban/jail.local


enabled = true

How to Configure Fail2ban jail.local

Want to familiarize yourself with the settings available in Fail2ban? Start by opening your jail.local file and locate the configurations available:

File: /etc/fail2ban/jail.local


ignoreip =

bantime = 600

findtime = 600

maxretry = 3

backend = auto

usedns = warn

destemail = [email protected]

sendername = Fail2Ban

banaction = iptables-multiport

mta = sendmail

protocol = tcp

chain = INPUT

action_ = %(banaction)...

action_mw = %(banaction)...


action_mwl = %(banaction)s...

Let’s consider an example. If you were to switch the usedns setting to no, Fail2ban will not utilize reverse DNS to implement its bans. It will ban the IP address instead. When you set it as warn, Fail2ban will undertake a reverse lookup to find the hostname and utilize that to initiate a ban.

What does the chain setting relate to? The range of iptables rules where jumps can be added in ban-actions. This has been set to the INPUT chain by default. If you want to learn more about iptables chains, feel free to check out our comprehensive What is iptables resource.

How to Configure Fail2ban Chain Traffic Drop

If you want to look at your Fail2ban rules, use the iptables’ –line-numbers option.

iptables -L f2b-sshd -v -n --line-numbers

You should see an output that’s similar:

Chain fail2ban-SSH (1 references)

num pkts bytes target prot opt in out source destination

1 19 2332 DROP all -- * *

2 16 1704 DROP all -- * *

3 15 980 DROP all -- * *

4 6 360 DROP all -- * *

5 8504 581K RETURN all -- * *

If you would like to, you may utilize the iptables -D chain rulenum command to remove a rule that has been applied to a specific IP address. Swap rulenum with the corresponding IP address rule number found in the num column. For instance, you can remove the IP address by issuing this command:

iptables -D fail2ban-SSH 2

How to Configure Ban Time and Retry Amount Fail2Ban

Set bantime, findtime, and maxretry to configure a ban’s circumstances and the amount of time it lasts:

File: /etc/fail2ban/jail.local

# “bantime” is the number of seconds that a host is banned.

bantime = 600

# A host is banned if it has generated "maxretry" during the last "findtime"

# seconds.

findtime = 600

maxretry = 3

  • findtime: This relates to how much time will pass between login attempts before a ban is implemented. As an example, let’s say Fail2ban is set to ban an IP following four (4) failed log-in attempts. These four attempts must take place during the predefined findtime limit of 10 minutes, and the findtime value should be a set number of seconds.

  • maxretry: To determine if a certain ban will be justified, Fail2ban uses findtime and maxretry. Should the amount of attempts be higher than the limit set at maxretry and fall within the findtime time limit, Fail2ban will set a band. The default is set at 3.

  • bantime: This applies to the duration of time (in seconds) an IP will be banned for, and this will be permanent if set to a negative number. The default value is 600, which will ban an IP for a period lasting 10 minutes.

How to Configure ignoreip for Fail2ban

You can add specific IPs you wish to ignore by adding them to the ignoreip line. This won’t ban the localhost by default. Adding the ignore list may be to your benefit if you tend to frequently leverage an individual IP address:

File: /etc/fail2ban/jail.local


# "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not

# ban a host which matches an address in this list. Several addresses can be

# defined using space separator.

ignoreip =

ignoreip: With this setting, you can define which IP addresses are to be excluded from Fail2ban rules. You should add specific IPs you want to ignore to the ignoreip configuration (as per the example). This command doesn’t band the localhost by default. If you regularly work from a single IP address, you may want to add it to the ignore list.

Want to whitelist IPs only for specific jails? Utilize the fail2ban-client command. Just switch JAIL with your jail’s name, and with the IP you intend to be whitelisted.

fail2ban-client set JAIL addignoreip

How to Set up Fail2ban Email Alerts

You may want to get email alerts whenever something triggers Fail2ban. You can do this by changing the email settings:

  • destemail: The address at which you want to get your emails.

  • sendername: The name attributed to the email.

  • sender: The address which Fail2ban sends emails from.

Pleas e be aware:

Run the command sendmail -t [email protected], switching [email protected] with your email address if you’re not what to put under sender. Look at your email, along with spam folders if required, and check the sender email. You can use that address for the configuration above.

You’re also required to edit the action setting. This defines the actions undertaken if the band threshold is met. The default, %(action_)s, will only ban the user. %(action_mw)s will ban and distribute an email including a WhoIs report. With %(action_mwl)s, a ban is implemented and an email with the WhoIs report (and any relevant lines in the log file) will be sent. You can also adjust this on a jail-specific basis.

How to Configure Fail2ban banaction and ports

Outside of the above basic settings address, jail.local also has numerous jail configurations for multiple common services (such as iptables and SSH). Just SSH is enabled by default, and the action is to ban the problematic host/IP address through modification of the iptables firewall rules.

Expect the standard jail configuration to look like this:

File: /etc/fail2ban/jail.local

# Default banning action (e.g. iptables, iptables-new,

# iptables-multiport, shorewall, etc) It is used to define

# action_* variables. Can be overridden globally or per

# section within jail.local file

banaction = iptables-multiport

banaction_allports = iptables-allports


enabled = true

port = ssh

filter = sshd

logpath = /var/log/auth.log

maxretry = 6

  • banaction: This defines the action that should be taken if the threshold is met. When you configure the firewall to use firewalld, set the value to firewallcmd-ipset. If you configure the firewall to use UFW, then the value should be set to ufw.

  • banaction_allports: This will block a remote IP in each port. If you configure the firewall to use firewalld, the value should be set to firewallcmd-ipset.

  • enabled: Determine if the filter should be activated or not.

  • port: This is the port that Fail2ban should reference in regards to the service. If you utilize the default port, you can put the service name here. But if you opt for a port that’s not traditional, this must be the port number instead. E.g. if you changed your SSH port to 3775, you would replace ssh with that number.

  • filter: This is the name of the file found in /etc/fail2ban/filter.d containing the failregex information used for parsing log files correctly. You don’t need to include the .conf suffix.

  • logpath: Provides the service’s logs location.

  • maxretry: This overrides the global maxretry for the service you define. You may also add findtime and bantime.

  • action: You may add this as an extra setting when the default action is inappropriate for the jail. You can find other in the action.d folder.

Please be aware:

You may choose to configure jails as individual .conf files withing the jail.d directory. But the format will stay the same.

Securing Servers with Fail2ban Filters

Now, we’ll explore your system’s Fail2ban filters defined within their respective configuration files.

You will see your system’s filters in the /etc/fail2ban/jail.conf file or the /etc/fail2ban/jail.d/defaults-*.conf file, depending on your version of Fail2ban.

Look up your /etc/fail2ban/jail.conf file and check out the ssh/sshd filter:

File: /etc/fail2ban/jail.conf


enabled = true

port = ssh

filter = sshd

logpath = /var/log/auth.log

maxretry = 5

When you use a version of Fail2ban higher than 0.8, examine your defaults-*.conf and jail.conf files.

If you have version 0.8 of Fail2ban or higher, your jail.conf file will look like this:

File: /etc/fail2ban/jail.conf


port = ssh

logpath = %(sshd_log)s

Next, if your system uses Fail2ban 0.8 or beyond, it will have a defaults-*.conf including these filters:

File: /etc/fail2ban/jail.d/defaults-*.conf


enabled = true

maxretry = 3

If you want to try testing current filters, run the example command and switch logfile, failregex, and ignoreregex with your preferred values.

fail2ban-regex logfile failregex ignoreregex

If we use those examples from this section’s start, the command will look like this:

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Your Fail2ban filters will need to work with:

  1. Different logs types created by varied software

  2. Varied configurations and a number of operating systems

Alongside the above, your filters should be log-format agnostic too. They should also be protected against DDoS attacks, and must be compatible with other versions of the software to be released in the future.

How to Customize ignoreregex Configurations

Before you can make adjustments to the failregex configuration, customization of ignoreregex is required. Fail2ban needs to understand what server activity is regarded as normal, and what isn’t.

For instance: you may exclude activity cron from running on your server or MySQL if you set up ignoreregex to filter logs created by those programs:

File: /etc/fail2ban/filter.d/sshd.conf

ignoreregex = : pam_unix\((cron|sshd):session\): session (open|clos)ed for user (daemon|munin|mysql|root)( by \(uid=0\))?$

: Successful su for (mysql) by root$

New session \d+ of user (mysql)\.$

Removed session \d+\.$

You’re free to tweak failregexs to block whatever you like now that you’ve filtered for each program’s logs.

How to Customize Failregexs

Fail2ban includes numerous filters, but you might prefer to customize them further or make your own based on your personal needs. Fail2ban utilizes regular expressions (regex) for log files parsing, searching for password failures and attempted break-ins. Python’s regex extensions are used by Fail2ban.

What’s the most effective way to learn how failregex functions? Write one yourself. While we don’t recommend letting Fail2ban monitor your WordPress’s access.log on websites with heavy traffic because of CPU concerns, it does give an instance of an easily-understood log file that you can utilize to learn about any failregex creation.

Writing a Fail2ban Regex

  1. Go to your website’s access.log (usually found at /var/www/ and locate a failed login attempt. This will look like:

File: /var/www/ - - [01/Oct/2015:12:46:34 -0400] "POST /wp-login.php HTTP/1.1" 200 1906 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0"

You just need to track up to the 200:

File: /var/www/ - - [01/Oct/2015:12:46:34 -0400] "POST /wp-login.php HTTP/1.1" 200

  1. The IP address that the unsuccessful attempt came from will always be defined as . The few characters after never change and you can enter them as literals:

  2. - - \[

The \ before the [ indicates that you should read the square bracket literally.

  1. You can use regex expressions to write the subsequent section (the date on which the login attempt occurred) as grouped expressions. So, as per this example, the first portion (here, 01) may be written as (\d{2}): The parentheses form the expression group and \d searches for numerical digits. However, {2} notes that the expression is searching for a pair of digits in a row (e.g. the date, as in 24, 25, etc.).

By this point, you will have:

- - \[(\d{2})

The following forward slash is called using a literal forward slash. This is followed by \w{3}: this is looking for a series of three alpha-numeric characters (such as A-Z, 0-5, in any case). The next forward slash will also be literal:

- - \[(\d{2})/\w{3}/

The year section will be written in a similar way to the day but you don’t require a capture group, and for four characters in a row along with a literal colon:

- - \[(\d{2})/\w{3}/\d{4}:

  1. The subsequent sequence consists of a run of two-digit numbers that represent the time. As we defined the day of the month as a two-digit number in a capture group (in the parentheses), we’re able to backreference it with \1. This is because it’s the first capture group. The colons will be literals again:

  2. - - \[(\d{2})/\w{3}/\d{4}:\1:\1:\1

If you prefer not to utilize backreferences, you can also write this as:

- - \[\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2}

  1. Write the -0400 segment in a similar way to the year, including the extra literal -: -\d{4}. You should close the square bracket (escaping with a backslash first) and end the rest with the literal string:

  2. - - \[(\d{2})/\w{3}/\d{4}:\1:\1:\1 -\d{4}\] "POST /wp-login.php HTTP/1.1" 200


- - \[\d{2}/\w{3}/\d{4}:\d{2}:\d{2}:\d{2} -\d{4}\] "POST /wp-login.php HTTP/1.1" 200

How to Apply the Failregex

Now that the failregex has been set up, it should be added to a filter:

  1. Go to Fail2ban’s filter.d directory:

  2. cd /etc/fail2ban/filter.d

  3. Make a file named wordpress.conf then add your failregex:

File: /etc/fail2ban/filter.d/wordpress.conf

# Fail2Ban filter for WordPress


failregex = - - \[(\d{2})/\w{3}/\d{4}:\1:\1:\1 -\d{4}\] "POST /wp-login.php HTTP/1.1" 200

ignoreregex =

Save and quit.

  1. Add a WordPress section to jail.local:

File: /etc/fail2ban/jail.local


enabled = true

filter = wordpress

logpath = /var/www/html/andromeda/logs/access.log

port = 80,443

This utilizes the default ban and email action, though you may define additional actions if you add an action = line.

Save and exit. Restart Fail2ban.

How to Use the Fail2ban Client

Fail2ban gives you a command fail2ban-client, and you can utilize this for running Fail2ban from the command line:

fail2ban-client COMMAND

  • start: For starting the Fail2ban server and jails.

  • reload: To reload the Fail2ban configuration files.

  • reload JAIL: For switching JAIL with a Fail2ban jail’s name; this causes the jail to reload.

  • stop: To terminate the server.

  • status: For displaying the server status and enabling jails.

  • status JAIL: For displaying the jail status, including IPs that are banned currently.

If you wanted to check that the Fail2Ban is operating and the SSHd jail has been enabled, for example, you would run:

fail2ban-client status

The output would be:


Number of jail: 1

Jail list: sshd

You can find more on fail2ban-client commands in the Fail2ban wiki.

Understanding Lockout Recovery

Imagine that you lock yourself out of your vps instance because of Fail2ban. But don’t worry: you’ll still be able to get entry via console access.

From here, you’re able to check your firewall rules to make sure Fail2ban blocked your IP, rather than something else. You can do this by inputting:

iptables -n -L

Search for your IP address within the source column of any Fail2ban chains (which are prefixed by fail2ban or fail2ban) to verify whether the Fail2ban service blocked you:

Chain f2b-sshd (1 references)

target prot opt source destination

REJECT all -- reject-with icmp-e

If you want to take your IP address from a jail, you can enter the following command (but switch and jailname with the IP address and jail name you intend to unban:

fail2ban-client set jailname unbanip

Please be aware:

If you’re unable to recall the name of your jail, you can list all jails with the following:

fail2ban-client status

You may input the following if you decide that you want to stop utilizing your Fail2ban service at any point:

fail2ban-client stop

However, with CentOS 7 and Fedora, two additional commands are required for fully stopping and disabling:

systemctl stop fail2ban

systemctl disable fail2ban

How Plesk and Fail2ban Work Together

In this section, we’ll look at how Plesk and Fail2ban work together.

Fail2Ban is enabled by default in Plesk Obsidian: every jail available will be turned on and Fail2Ban’s default settings will be utilized.

You can safeguard your server from brute force attacks through IP address banning ( Fail2Ban ). Fail2Ban utilizes regular expressions for monitoring log files and spotting patterns that may correspond to authentication failures, looking for exploits, and additional entries that may appear to be suspicious.

Log entries of these types are counted, and when their number reaches a predefined value, Fail2Ban will issue a notification email or ban the offending IP for a set period. But the IP address will be automatically unbanned when the ban period ends.

A number of jails determine Fail2Ban logic. A jail is a rule set related to a specific scenario. The jail settings define what will be done when an attack has been detected according to a preset filter (a set of one or more regular expressions for log monitoring).

You can adjust Fail2Ban settings like so:

  1. Navigate to Tools & Settings > IP Address Banning (Fail2Ban) (under “Security”).

  2. Make your way to the “Settings” tab, where you can tweak:

    • IP address ban period – the time interval that an IP address is banned for (in seconds). The IP address is automatically unbanned once this period has ended.

    • Time interval for detection of subsequent attacks – the time interval during which the system will count the amount of failed sign-in attempts and additional undesirable behaviors from an IP address (in seconds).

    • Number of failures before the IP address is banned – the amount of unsuccessful login attempts connected to the IP address.

  3. Click on OK .

You’ll see these limitations and peculiarities in Fail2Ban in Plesk:

  • Fail2Ban defends against attacks with IPv4 and IPv6 addresses.

  • Fail2Ban depends entirely on IPs (without hostname lookups) unless it’s reconfigured.

  • Fail2Ban is unable to safeguard against distributed brute force attacks, as it recognizes intruders through their IP address.

  • The VPS iptables records limit (numiptent) could have an impact on Fail2ban’s work if your Plesk is installed on a VPS. Fail2Ban will cease operating as it should once this limited is exceeded, and you’ll find a line like this in the Fail2ban log: fail2ban.actions.action: ERROR iptables -I fail2ban-plesk-proftpd 1 -s -j REJECT --reject-with icmp-port-unreachable returned 100 In this situation, you should get in touch with your VPS hosting provider for a resolution.

If you don’t want to block an IP address:

  1. Navigate to Tools & Settings > IP Address Banning (Fail2 b an) > Trusted IP Addresses > Add Trusted IP .

  2. Next, enter an IP address n the IP address field, along with an IP range or a DNS host name before clicking OK .

You can look at (and download) Fail2ban log files by going to Tools & Settings > IP Address Banning (Fail2 b an) > the Logs tab.

You’re free to look at the banned IP addresses, unban them, or add them to your trusted address list in Tools & Settings > IP Address Banning (Fail2 b an) > the Banned IP Addresses tab.

You may check out your list of IP addresses you never want to be banned, add/remove IP addresses to/from this list in Tools & Settings > IP Address Banning (Fail2 b an) > the Trusted IP Addresses tab.

Thank you for reading this comprehensive Fail2ban configuration tutorial. Now, you should have all the insights you need to take advantage of Fail2ban to fully secure your server.

How to Install and Configure CSF

CSF installation guide Plesk blog

As a firewall application suite designed for Linux servers, Config Server Firewall ( CSF ) is a Login/Intrusion Detection that’s effective for such applications as SSH, Pop3, IMAP, SMTP and others.

CSF will recognize when a user is signing into the server through SSH and send you an alert if they attempt to utilize the “su” command to attain higher privileges on the server.

Another key function of CSF is that it will check for failed login authentications on mail servers (IMAP, Exim, uw-imap, Dovecot, Kerio), Ftp servers (Pure-ftpd, Proftpd, vsftpd), OpenSSH servers, and Plesk & cPanel servers for replacing software such as fail2ban.

CSF is a solid security solution for server hosting, and it can be integrated easily into Plesk and WHM/cPanel’s user interface.

Steps to follow:

Step One – Install CSF Dependencies

As CSF is based on Perl, you’ll need to install this on our server to begin. You should have wget for downloading the CSF installer as well as vim (or an editor of your choosing) to make changes to the CSF configuration file.

When ready, you should install the packages using the following command:

yum install wget vim perl-libwww-perl.noarch perl-Time-HiRes

Step Two – CSF Installation

Navigate to the “/usr/src/” directory to download CSF using this wget command:

cd /usr/src/

Extract the tar.gz file and head to the CSF directory. Then, install the tar.gz file:

tar -xzf csf.tgz
cd csf

If this has gone smoothly, you’ll be presented with a message stating that the CSF installation has been completed. Next, check that CSG actually works as required on this server. How? Make your way to the “/usr/local/csf/bin/” directory. Then, you’ll need to run “”, like so:

cd /usr/local/csf/bin/

You’ll know that CSF is operating on your server with no issues if you see the following response:

RESULT: csf should function on this server

Step Three – Configuration of CSF

There’s one thing you should know before you dive into the process of configuring CSF: CentOS 7’s default firewall application (“firewalld”) must be stopped and removed from the startup.

To stop it:

systemctl stop firewalld

To disable and remove firewalld from the startup:

systemctl disable firewalld

Next, head to the CSF Configuration directory “/etc/csf/” and change the file “csf.conf” using the vim editor:

cd /etc/csf/
vim csf.conf

To apply the CSF firewall configuration, change line 11 “TESTING” to “0”.


CSF enables traffic (incoming and outgoing) for the SSH standard port 22 by default. If you choose to utilize an alternative SSH port, add your port of choice to the configuration in line 139 “TCP_IN”.

Next, start CSF and LFD with the following command:

systemctl start csf
systemctl start lfd

Set up the csf and lfd services to start when booting:

systemctl enable csf
systemctl enable lfd

Now, you’ll see the CSF list default rules with command:

csf -l

Step Four – Basic CSF Commands

1. Starting the CSF firewall (enabling firewall rules):

csf -s

2. Flushing/stopping firewall rules.

csf -f

3. Reloading firewall rules.

csf -r

4. To allow an IP and add it to csf.allow.

csf -a

Here are the results:

Adding to csf.allow and iptables ACCEPT...
ACCEPT all opt -- in !lo out * ->
ACCEPT all opt -- in * out !lo ->

5. Removal and deletion of an IP from csf.allow.

csf -ar

Here are the results:

Removing rule...
ACCEPT all opt -- in !lo out * ->
ACCEPT all opt -- in * out !lo ->

6. Denial of an IP and adding to csf.deny:

csf -d

Here are the results:

Adding to csf.deny and iptables DROP...
DROP all opt -- in !lo out * ->
LOGDROPOUT all opt -- in * out !lo ->

7. Removal and deletion of an IP from csf.deny.

csf -dr


Removing rule...
DROP all opt -- in !lo out * ->
LOGDROPOUT all opt -- in * out !lo ->

8. Removal and unblocking every entry from csf.deny.

csf -df


DROP all opt -- in !lo out * ->
LOGDROPOUT all opt -- in * out !lo ->
DROP all opt -- in !lo out * ->
LOGDROPOUT all opt -- in * out !lo ->
csf: all entries removed from csf.deny

9. Searching for a pattern match on iptables (such as CIDR, IP, Port Number)

csf -g

Step Five – Advanced Configuration

Want to configure as and when you need to? Check out these CSF tweaks.

Go back to the csf configuration directory and change the csf.conf configuration file like so:

cd /etc/csf/
vim csf.conf

1. Non-blocking of IP addresses in your csf.allow files:

By default, LFD will block IPs under csf.allow files. But if you’re looking to make sure that a certain IP in csf.allow will never be blocked by LFD, navigate to the line 272 and edit “IGNORE_ALLOW” to “1”.

This can be helpful when you use a static IP at work or home and would like to make sure that the internet server or firewall never blocks it.


2. Enable incoming and outgoing ICMP

Head to the line 152 for incoming ping/ICMP:

ICMP_IN = "1"

And for outgoing ping ping/ICMP, go to line 159:

ICMP_OUT = "1"

3. Blocking specific countries

CSF gives you the option to deny or allow access to certain countries, through the CIDR (Country Code).

How? Go to line 836 and add the codes of those countries you want to allow or deny:


4. Emailing the Su and SSH Login log

Another trick you can try is setting an address that LFD can use for sending alert emails about “SSH login” events and occasions when users run the “su” command.

To do this, find the line 1069 and edit the value to “1”:



Input the email address you would like to use for this in line 588:

LF_ALERT_TO = "[email protected]"

Looking for extra changes you can make? Take a look at the options in the “/etc/csf/csf.conf” configuration files.


CSF is a valuable application-based firewall for iptables available Linux servers, offering a number of features. It is supported by Plesk, cPanel/WHM, DirectAdmin and Webmin.

Fortunately, CSF installation and configuration is simple, and it’s easy to use on the server, so it has the power to make security management much more efficient for sysadmins.

ModSecurity Comprehensive Guide

Modsecurity guide Plesk

What is ModSecurity? It’s a toolkit designed for real-time web application monitoring, logging, and access control. If it sounds complex, don’t worry. Anyone with experience of ModSecurity will attest that it’s a flexible toolkit, with no hard and fast rules telling you how you should use it.

Generally, ModSecurity leaves you free to decide how you take advantage of the features available instead. This flexibility is a core element of ModSecurity’s identity, and complements its open source structure. In fact, you can enjoy complete access to its source code, which empowers you to customize the tool to suit your unique needs.

And that’s crucial for anyone who wants tools to enable them to achieve what they have to with minimal restrictions. Which is probably all of us, right? ModSecurity is a versatile creation ideal for numerous usage scenarios. Let’s look at some of the most important:

Security monitoring and access control for applications

ModSecurity provides you with the ability to access and inspect streams of HTTP traffic, so you can monitor application security in real-time.

ModSecurity’s persistent storage mechanism allows you to keep track of system elements and conduct event correlation over time. You can also implement blocks efficiently, if you need to, thanks to ModSecurity’s full request and response buffering.

Comprehensive logging of HTTP traffic

When logging for security reasons, web servers are generally known to do less than first-timers may expect. Actually, they tend to log little fundamentally — so you may still struggle to get all that you’re looking for even with some adjustments here and there.

But with ModSecurity, you can log whatever you need to (such as raw transaction data for forensics) and you can determine:

  • what transactions will be logged
  • which aspects of transactions will be logged
  • which elements undergo sanitization

Hardening web applications

One of the most impressive ModSecurity uses is attack surface reduction: here, you can streamline HTTP features you’re happy to accept, such as content types, request methods, etc.

ModSecurity will help you to enforce numerous similar reductions, through additional Apache modules (collaboratively or directly). This is all under the umbrella of web application hardening.

A more personal solution

ModSecurity’s immense flexibility comes to the fore when you’re faced with an unexpected problem. This could be a security issue, for example, or something entirely different.

For instance, some users utilize it as an XML web service router by blending its capabilities to parse XML and apply XPath expressions with its proxy-request abilities. That might not occur to some users, which only shows the deep flexibility at ModSecurity’s core.

Basically, it may prove helpful to you in ways you can’t predict until you start to truly explore.

Continuous passive security assessments

Traditionally, security assessment can be viewed as an active event which is scheduled in advance, involving an independent team trying to undertake a fake attack. But a continuous passive security assessment is a variation on real-time monitoring that concentrates on system behavior rather than that of outside parties.

Continuous passive security assessments serve as a form of early warning system, capable of detecting security weaknesses before attackers can take advantage.

ModSecurity’s Core Principles

ModSecurity is based on four main principles:


If you’re concerned about letting tools make decisions for you, particularly when conducting transactions, ModSecurity makes things a little easier for you.

Why? Because it’ll never initiate changes to transaction data without you instructing to do so first.

Of course, it’ll provide you with a wealth of information. But it’ll leave choices up to you, for your complete peace of mind.


As we’ve already mentioned, ModSecurity is remarkably flexible. It’s actually fairly mind-blowing in its flexibility, to be frank.

That’s because it was created by a security expert who wanted to intercept and analyze HTTP traffic for safety purposes, yet realized that everyone had to do things their own way sometimes. Not everything has to work exactly the same for each user.

So, ModSecurity offers such high flexibility by providing a rule language that enables you to achieve what you need to, along with the freedom to apply rules only where necessary.

Quality, not quantity

During the lengthy development and fine-tuning of ModSecurity, the team explored numerous ideas for what it could actually do. They chose not to act on a lot of these, and put them aside for a later time.

They did so because they knew they had fewer resources than they needed  to make those ideas a reality effectively. So, they decided to limit the functionality available to users, but to focus on making the ideas they actually implemented the best they could be.


We all know the “perfect” tool doesn’t exist, and possibly never will. But a predictable tool could be the next best thing — and that’s where ModSecurity shines yet again.

When you’re equipped with the crucial facts, you’ll be able to understand ModSecurity’s weakest areas and find workarounds yourself.

However, let’s be clear: certain aspects of ModSecurity can be considered to be beyond the scope of these guiding principles.

For instance, ModSecurity is capable of adjusting the way in which Apache identifies itself to others, keeping the ModSecurity Apache process contained, and implementing an efficient plan to deal with that well-known XSS weakness in Adobe Reader.

It’s fair to say, though, that these features could be seen as a distraction from the core intent behind ModSecurity’s creation: to serve as a predictable tool for inspecting HTTP traffic efficiently.

Choices of Deployment

Two different deployment options are supported by ModSecurity: embedded deployment and reverse proxy deployment. But there’s no single correct or incorrect approach.

Just pick the most appropriate option based on your goals, requirements, and situation.

Let’s look at the benefits and drawbacks of each:

Embedded deployment

You can add ModSecurity to any version of Apache that’s compatible, as it’s an Apache module. At the present time, this means that a fairly recent version of Apache from the 2.0x branch should suffice (though a more up-to-date 2.2x is the typical recommendation).

Embedded deployment is terrific for users who have already established their architecture and are reluctant to make changes. It’s the only option if you want to keep a high number of web servers protected, even hundreds of them.

In a situation like this, though, it’s not practical to create a separate proxy-based security layer. Not only are new failure points not introduced with embedded deployment, but ModSecurity also offers seamless scaling to match the underlying infrastructure as it scales.

With embedded ModSecurity deployment, the primary obstacle is that server resources will be shared between ModSecurity and the web server.

Reverse proxy deployment

A reverse proxy is basically an HTTP router made to sit between a web server and its clients. Installing a Apache reverse proxy with ModSecurity added will bring you an effective network web application firewall. You can implement this to safeguard any amount of web servers all running on a shared network.

A lot of security professionals opt to initiate a separate security layer, as you’ll enjoy total isolation from those systems being protected.

In terms of performance, a standalone ModSecurity has resources dedicated to it, which enables you to get more out of it (such as utilizing rules that are more complex).

However, there’s a big potential disadvantage to consider with this deployment approach: the new point of failure. This will have to be addressed using a high-availability configuration of at least two reverse proxies.

Understanding ModSecurity and Plesk

ModSecurity is switched on by default starting from the early versions of Plesk Obsidian. In the same time, if you install Plesk using the images provided by your hoster, situation may be different.

To identify and defend web applications against attacks, ModSecurity will run checks on any request to the web server and all associated responses from the server against the set of rules.

Should checks succeed, the HTTP request will be sent to the website to retrieve the relevant content. But if checks fail instead, the appropriate predefined actions will be initiated.

Both Plesk for Windows and Linux offer support for ModSecurity. This functions as a web server (IIS or Apache) module.

How to turn on ModSecurity

To activate the web application firewall, follow these steps:

  • Navigate to Tools & Settings > Web Application Firewall (ModSecurity) (located within the Security group).

Don’t see this link? Don’t panic. Just install the ModSecurity component here: Tools & Settings > Updates > Add/Remove Components > Web hosting group.

  • Switch the web application firewall mode to either On or Detection only, to make sure all incoming HTTP requests and associated responses are checked against a rule set. When checks succeed, the HTTP request will be directed to the website to retrieve the necessary content. Alternatively, the event will be logged if checks fail. When in the Detection only mode, no additional actions will be undertaken. But in the On mode, HTTP responses will be given with a suitable error code.

Firewall modes for web applications can only be set on the server and domain levels. But the domain level mode can’t be higher than that of the mode set for the web server. So, if the firewall is running in Detection only mode on the server level, you’ll be unable to switch it to On for domains — just Off and Detection only modes will be displayed.

Choose the set of rules to be checked by the firewall engine for every HTTP request incoming, or feel free to upload your own set of rules instead. You can opt for one of these rule sets:

  • Atomic Basic ModSecurity: This is a free version of the Atomic ModSecurity rules for beginners, packaged with Plesk. It includes key security features and bug fixes are released monthly.
  • OWASP ModSecurity Core Rule Set (CRS): This gives you generic defense against unknown weaknesses that can be found in many web applications. It’s shipped free, but it’s recognized as being restrictive, so much so that additional tuning is necessary for production use. When you choose this set of rules, WordPress partly won’t work, nor will webmail and fire sharing. You can take advantage of the Comodo or Atomic rule sets instead.
  • Advanced ModSecurity Rules by Atomicorp: This is the most recent version of the rules, including all the performance improvements, bug fixes, and latest security features created by Atomicorp GotRoot every day. This commercial set of rules is supported completely and advised for production use. Plesk offers the Security Core Complete by Atomicorp extra feature, which enables you to implement this set of rules in Plesk. You can access this in multiple ways:
    • Purchase the Atomicorp Advanced ModSecurity Rules available in the Plesk Online Store
    • Have a Plesk license already? You can implement the extra feature through the Plesk Partner Central UI or the Partner API.
    • If you hold a Plesk license but you can’t access the Plesk Partner Central, please contact your provider.

    If you have an account on the Atomic website already, you’ll be able to simply enter your username and password to activate this set of rules.

    Linux users please be aware: If you choose the Atomic set of rules, follow these steps to make sure your ModSecurity performs as it should. Start by running the aum -u command on the server, and the Plesk modsecurity package will be switched for that from Atomic’s repository. Next, run these commands:

    • plesk sbin modsecurity_ctl --disable
    • plesk sbin modsecurity_ctl --enable
    • service httpd restart
  • Comodo ModSecurity Rule Set (Linux): This rules-based traffic control system is easy to use and can be tailored. It offers effective protection for your web applications and combats emerging hacking methods, through a rules database that receives regular updates. This set of rules is shipped for free, and you can activate it in Plesk by following these steps: register on the Comodo site, and once there, submit the username and password you use on this website. It’s easy.
  • Custom: You have the ability to upload custom web application firewall rule sets, such as an Atomic trial package or a Comodo free package. The following formats are supported: zip; tar.gz; tgz; tar.bz2; conf.
    • Pick the Update rule set checkbox and choose the relevant update period to update your selected set of rules automatically.
    • Choose a predefined range of parameters or specify your bespoke ModSecurity directives. The following preset parameter sets are available:
    • Fast: For when the HTTP request URI and parts of the headers undergo analysis. The least CPU is required for this mode.
    • Tradeoff: For when the HTTP request URI, headers, and request POST data will be subject to analysis. This is a solid balance between performance and quality.
    • Thorough: For when full HTTP request headers, request POST data, and HTTP response body content will be analyzed. This mode does consume the biggest range of CPU resources, though it can be an effective option for websites demanding special security protections (such as online stores facilitating card transactions).


Please note: Web application firewalls need a local DNS server with request caching enabled to provide the best performance. Without this, your websites will be more likely to load slowly when the firewall is in effect.

Finding Log Files on Linux Systems

ModSecurity utilizes two locations for logging on Linux systems:

  • Modsecurity audit log, which can be found in /var/log/modsec_audit.log. This is a highly-detailed option used by the entire Plesk server. An entry in the audit log file will be generated when ModSecurity recognizes that an event has taken place. You can view the ModSecurity audit log for yourself if you navigate to Tools & Settings > Web Application Firewall (ModSecurity) > click the Logs Archive link located within the ModSecurity audit log You can explore (and download) the log files and modification dates here.
  • The Apache error log for a domain, which can be found in /var/www/vhosts/DOMAIN.TLD/logs/error_log. This offers just brief details about site errors, but you can check out the error log for specific websites in the Customer Panel on the Websites & Domains > <domain_name> > Logs > choose Apache error and nginx error rather than All logs positioned on the right.

Finding Log Files on Windows Systems

ModSecurity audit logs are domain-specific on Windows. They’re found in %plesk_dir%\ModSecurity\vhosts\<domain’s GUID>\logs ( %plesk_dir% is Plesk’s default installation directory).

How to Switch Rules Off

Once you switch the web application firewall mode from Off or Detection Only to On, a website could start functioning in an unexpected way. You can check error codes (404s, 403s, 500s) in the site error log, and they’ll stop displaying once you switch the firewall mode back to Off or Detection Only.

In this event, check the ModSecurity audit log to identify the cause. You’ll be able to deactivate excessively-restrictive rules or tweak the website as required.

Follow these steps to determine why a site’s HTTP requests can’t be completed:

  • Check the audit log file for the site.

When using Plesk for Linux systems, you can take view the log through Plesk’s UI: navigate to Tools & Settings > Web Application Firewall (ModSecurity), then click on the ModSecurity Log File link to start downloading the relevant audit log. This will open in a new window in your browser.

  • To find events for a website (domain name) that may be responsible for issues, leverage the Search function (just hit Ctrl+F in the majority of browsers) — such as your_domain.tld. Your browser will then highlight certain entries, e.g. HOST: your_domain.tld. Look for a string such as –eece3116-B– in the three lines positioned above the highlighted entry. Those symbols between the hyphens show you the ID of the event which was triggered by the HTTP request.
  • Look deeper for additional entries with the identical event ID, specifically an entry featuring a H after the event ID. This carries the ID and description of the security rule that was activated while checking the relevant HTTP request. The security rule ID is an integer number positioned with quotation marks. It will begin with a 3 and will be displayed with the prefix ID in square brackets. This may look something like [id “340003”].
  • Locate a security rule ID in the event with the substring [id “3. You can use this ID when you turn rules off.

To deactivate a rule:

  • Make your way to Tools & Settings > Web Application Firewall (ModSecurity)
  • Once you’re in the Switch off security rules area, choose the security rule based on its ID (e.g. 340003), its tag (such as CVE-2013-4589), or a standard expression (e.g. XSS) and hit OK.

Final Notes for Nginx and ModSecurity

Let’s end by covering the issue of request checks with NGINX and ModSecurity, and how it connects to ModSecurity Apache issues.

ModSecurity is an Apache module on Linux systems, and it can run checks on HTTP requests reaching Apache only. But you can supplement Apache with an alternative web server, specifically nginx.

If you switch on the ‘Process PHP by NGINX option’ of the NGINX web server for dynamic website content (in a site’s Apache and NGINX settings), the web application firewall will be unable to check any HTTP requests as they’ll never actually reach Apache.

In the case of static content, HTTP requests won’t reach Apache if the ‘serve static files directly by NGINX option’ is switched on. That means ModSecurity won’t be able to check them.

We hope this detailed guide gave you a clear answer to “what is ModSecurity?” and helps you understand how it works. Because now it’s time to explore its possibilities for yourself!

ModSecurity offers a lot of advantages, so follow the tips and steps covered above to find out what ModSecurity can do for you.

Next Level Ops Podcast: Tips for Keeping Your Server Secure with Igor Antipkin

Hello Pleskians! This week we’re back with the fourth episode of the Official Plesk Podcast: Next Level Ops. In this installment, Superhost Joe speaks to Igor Antipkin, Plesk’s Security Warlock. Igor shares his philosophy on the multifaceted role security plays in projects. And sheds light on how users can reduce security risks.

In This Episode: Threat Modelling, Thinking About Risks and How to Not Become a Security Engineer

In This Episode: Threat Modelling, Thinking About Risks and How to Not Become a Security Engineer - Next Level Ops Podcast: Tips for Keeping Your Server Secure with Igor Antipkin - Plesk

What are some of the common security issues that end users encounter? How can users protect their servers against security vulnerabilities? According to Igor, there are no easy steps when it comes to server security. Instead, users can follow some general recommendations to identify and deal with risks. 

“Security is a process,” says Igor, “It’s an approach that should be taken into account when you work on a project.” The first step is to identify potential security risks in the design phase of the project. Think, think and think some more. What kind of risks can you encounter? What should you best protect yourself from? “Just don’t think so much, otherwise you face the risk of becoming a security engineer,” says Igor. 

Thank you Igor, we’ll make sure our listeners heed this piece of advice!

“Security is a process. It’s an approach that should be taken into account when you work on a project.”

Igor Antipkin

Key Takeaways

  • Use threat modeling to identify potential security risks. Consider possible security risks in the project design phase. The kinds of threats and risks you might have – list them, write them down (and hopefully don’t leave your notebook lying around). One advantage of using this approach is minimizing the likelihood of security breaches. And it reduces rework in the later stages of your project.
  • Educate your users about security risks. End users today should care more about security. Outdated software is the most common problem in this scenario. It’s important to keep your software up to date. And making sure that you install all the latest updates.
  • Use the principle of least privileges. Limit user permissions based on individual roles to give access where it’s needed. This limits the amount of damage any single individual can do to a website or server.
  • Be informed about the software you use. Inform yourself about software security as much as you can. Stay involved in the community to stay up to date about potential issues.

…Alright Pleskians, it’s time to hit the play button if you want to hear the rest. If you’re interested in Plesk extensions, check out our previous episode. If you want to check out some tools to spruce up your security, take a look at this guide. We’ll be back soon with the next installment.

The Official Plesk Podcast: Next Level Ops Featuring

Joe Casabona

Joe is a college-accredited course developer. He is the founder of Creator Courses.

Igor Antipkin

Igor is a Security Engineer at Plesk.

As always, remember to update your daily podcast playlist with Next Level Ops. And stay on the lookout for our next episode!

How to manually remove website malware

Remove website malware

We all face daily cybersecurity challenges. No matter how hard you try, you’ll never reduce the chances of being hacked to zero. But server security solutions are here to help prevent and detect unauthorized access. Do you need help learning how to remove website malware?

There are always comfortable automated ways to manage these threats, like one of our most appreciated extensions for this purpose, ImunifyAV.

Alternatively, let us help you get one step ahead of the hackers with our guide to manually removing website malware.

File with malware

Main malware strains

Main malware strains

Hackers can get into your systems in various ways. One popular way is via injections attacks. Injections happen when an attacker inserts a file, in-memory cache or database entry into a system component.

Code injection

  • You can insert code into existing PHP or Perl programs to create backdoors or automated uploaders.
  • You can modify the contents of the .htaccess file to redirect visitors to other sites for the purpose of phishing or SEO hijacking.
  • You can alter JavaScript (.js) and HTML files to insert unwanted advertising scripts or content (so-called malvertising).
  • An attacker can modify and use Exif information (meta-data to add info to image files eg. JPG) to carry malicious payloads to other parts of the file system or other sites.

Hackers will often take full advantage of their position, and plant malicious code in multiple places.

Cache injection

A cache is a small, high-performance store of memory. If you don’t secure the server that maintains the caches, then memory can be overwritten in situ. If the affected portion of memory is a cached version of a web page, then a hacker can inject code or malicious content without changing website functionality.

Hacker scripts

Hacker scripts can take many forms, and serve many purposes. Scripts for back doors, uploaders, spammers, and phishing links can create web doorways, or site entry points to manipulate search engine indexes. Hackers can also create defacement scripts simply to cause damage, or prop up their own ego.

Replacing system components

Every hacker wants root access to your server, so they can replace any web server component with their own malicious version. Attackers can control entire sites, and add or modify their behavior as they need. They can also remotely control the script to issue redirects or new portions of malicious code. If an attacker hides this component carefully, then it’s difficult to detect. Because the website appears to be working normally.

How to manually remove malware and repair your website

Manually removing malware

Now let’s assume you’re scanning your site with your favorite cybersecurity software, like Imunify360 or ImunifyAV. Use the following manual inspection techniques to make sure it’s doing a good job and start to manually remove malware.

IMPORTANT: Before continuing, ensure you have a full and working backup of your entire system.

File scanning

Traditionally, Linux-type systems have limited facilities for detailed file scanning and inspection. So let’s use what we have, in the form of find and grep. First, by searching the file system for all modified files within the past 7 days, where the file name extension begins with ph (to cover .php and .phtml):

find . -name '*.ph*' -mtime -7

However, what if a hacker considers this first? And resets file modification dates. Then check to see if file attributes have changed. Here’s how to do that for .phtml and .php files.

find . -name '*.ph*' -ctime -7

We can narrow down the period we’re looking at, by using the newermt option of find. Eg. To look for a file changed between the 25th and 30th of January 2019:

find . -name '*.ph*' -newermt 2019-01-25 ! -newermt 2019-01-30 -ls

Now we can introduce the grep command. This can recursively scan for and report patterns in files. Eg. To look for a portion of a URL in any file in the current directory, or any within it:

grep -ril '' *

Permissions checks

If you suspect a breach in your web server or file system, check file permissions. You can do this with the following command:

sudo find / -perm -4000 -o -perm -2000

Check for active processes

If a file system scan shows nothing unusual, take a look at what’s running on the system. See what PHP scripts are running using:

lsof +r 1 -p `ps axww | grep httpd | grep -v grep | awk '{ if(!str) { str=$1 } else { str=str","}} END{print str}'` | grep vhosts | grep php

Analyzing malicious code: what to look for

You now know some of the basic techniques to search for files and file content. To go deeper when you manually remove site malware, you need to know what to look for. Here’s a helpful checklist.

Check rarely visited directories

System administrators rarely look in directories like upload, cache, tmp, backup, log, and images, making them ideal locations for hackers to hide malicious files.

Note: On PHP-based CMSes such as Joomla, check directories for .php files in the wrong places. If you’re on a WordPress site, check the wp-content/uploads, and the backup and theme cache directories.

Here’s an example of a command that checks for PHP files in an images folder:

find ./images -name '*.ph*'

Treat any similar files in such places suspiciously.

Files with strange names

Even though file names come in a wide variety, certain names should raise a red flag. Here are some examples:

  • php (no extension)
  • fyi.php
  • n2fd2.php

Note any unusual patterns or combinations in file names, letters, symbols and numbers. File names that are naturally unreadable are:

  • srrfwz.php
  • ath.php
  • kirill.php
  • b374k.php.php (double extension)
  • tryag.php

Hackers also exploit the habit of some programs that append numbers to copies of existing files. So lookout for files like:

  • index9.php
  • wp3-login.php

Look for unusual file name extensions

You don’t normally associate certain file name extensions with CMSes like WordPress. So if you see any of these, take note:

  • .py (Python code extension)
  • .rb (Ruby code extension)
  • .pl (Perl code extension)
  • .cgi (CGI code extension)
  • .so (Shared object extension)
  • .c (C source code extension)

Moreover, you also wouldn’t expect to find files with extensions like .phtml or .php3. If you discover any of the above on a PHP-based CMS website, then you should inspect it closely.

Look for non-standard attributes and creation dates on files

Another sign of suspicious files involves the file owner attribute. So you need to watch out for the following:

If you see a number of .php files sent to a server via ftp or sftp were transferred with the owner attribute set to myuser. But in the same directory you see files where the owner attribute is www-data.

You must also check script creation dates. If the date is earlier than website creation, then you need to be suspicious.

Look for large numbers of files

Directories containing hundreds or thousands of files are good places for a hacker to hide malicious scripts and payloads. Such large numbers of files indicate a doorway, or a form of blackhat SEO.

You can detect such directories with the find command. We recommend you start in a specific directory to limit your search and avoid loading a system. The following example helps you find the top 25 directories with the largest number of files.

find ./ -xdev -type d -print0 | while IFS= read -d '' dir; do echo "$(find "$dir" -maxdepth 1 -print0 | grep -zc .) $dir"; done | sort -rn | head -25

(You can read more about file (inode) searching at StackExchange.)

Checking your server logs

Check server logs

You can also check any system through an inspection of the server log files. Here you can learn many things. For example:

  • You can tell how the spam email was sent (when and where it was sent from, the access_log file, and what script invoked the mail command).
  • You can check FTP logging. Tools such as xferlog tell you what was uploaded or changed, and who did it.
  • You can discover the location of any mail-sending PHP scripts with the correct configuration of your mail and PHP servers.
  • You can check to see whether your CMS has additional logs to help you track down the source of an attack. This might help you determine whether an attack was external or came in via a CMS plugin.

Both access_log and error_log files are good sources of information. If you know which scripts are the attack vectors, you may be able to find the source IP address, or the HTTP user agent value. You may also be able to see if a POST request was made at the same time of the attack.

Checking the integrity of files

You deal with attacks more easily if you have adequate preparations in place, like recording the state of files in their pristine state. You can then compare them to the same files after an attack. You can do this in various ways:

Use source code control systems such as git, SVN or CVS. In the case of git, you can simply utilize these commands:

git status 

git diff

Using source code control ensures you have a backup copy of server files. You can restore these easily in the event of a cyber attack.

Tools that can alert you when anything on a file system changes include:

In some cases, version control isn’t possible. For example, when using shared hosting. One workaround is to use CMS extensions or plugins to monitor file changes. Some CMSes even have their own built-in file integrity.

You can keep track of what files you have at any one time with the command to catalog all the files on a system:

ls -lahR > original_file.txt

You can compare this file later with a fresher copy using comparison tools like WinDiff, AraxisMerge Tool, BeyondCompare, the Linux diff command, or even compare snapshots online. This lets you see what files have been added or removed.

This whole process certainly looks pretty complex. You can always choose to fully automatize it – using for this purpose ImunifyAV.

Comfortable Alternative to a Day’s Work – ImunifyAV


For added confidence, it’s good to know how to manually check your system for problems. And it’s a good way to learn some system administration techniques, like how to manually remove malware. Having a comprehensive server security solution such as ImunifyAV, a free antivirus and anti-malware scanner, is the first step towards a safe and secure website. You can easily upgrade to ImunifyAV+ and get a built-in, one-click, fully automated cleanup feature.

Software Tools to Prevent Attacks on Servers and Sites

Software tools to prevent attacks on servers and sites - Plesk

As hackers find more sophisticated ways of accessing your data, security is becoming a day-to-day struggle for businesses. Since 2018, security breaches have increased by 11%. And in the first half of 2019 alone, 4.1 billion personal records were exposed. And losses due to data exfiltration, stolen IP, and ransomware are also accelerating at a fast pace. Although nearly two-thirds of business leaders recognize the increasing security risks, only a small percentage have enough server security and website security.

Being fully protected means having multiple layers of security in place. With each layer addressing a different type of threat – and combining to form an impenetrable barrier. This becomes a difficult task for sysadmins, because just uncovering and blocking individual threats isn’t enough. It’s also important to defend against complex threats and take preventative action all the time.

To effectively manage cybersecurity, businesses outsource and use free and premium security tools. Here we’re going to look at some of the field’s top tools. And explain how they can help you enforce the seven key security layers every business needs to stay secure.

Network Firewalls

Firewall helps Linux server security - Plesk

A firewall is a system that prevents unauthorized access to or from a private network. It’s basically like the door to a house: an outer layer of security that determines what can and cannot enter. Of course, you also need the door to be closed, sturdy, and under your control in order to protect you. Most computers come with inbuilt firewall software, typically enough to shield against viruses, malware, and other unwanted content.

However, default firewalls are generic and limited, and so enterprises regularly use hardware firewalls as well. While the default Plesk firewall provides basic server protection, extensions like Juggernaut further secure your server against today’s threats. Juggernaut features include an SPI firewall, brute-force protection, real-time connection tracking, intrusion detection, and dynamic blocklists. Such features give you extra control and allow you to prevent inappropriate communications. Also, take a holistic view of your network, and even scan encrypted data for threats.

A firewall is considered the first line of defense in preventing attacks on servers. However, it’s not the only measure you should take.

Antivirus Software

Install antimalware/antivirus software

If a firewall is the door to your house, your antivirus software is the door to your bedroom. Whereas a firewall protects unwanted content and threats from getting in, antivirus software protects against threats already in your system. It does this by constantly monitoring files, looking for certain signatures to identify malware, and removing viruses and potential threats.

There’s no such thing as too much protection when it comes to antivirus software. The key is finding a tool that suits your needs while being easy to use, lightweight, and regularly updated. Premium antivirus by Dr. Web is an award-winning virus scanning and filtering software that protects mailboxes from many types of malware. Including viruses, worms, and trojans.

More great options are the Plesk Premium Antivirus or Kaspersky Antivirus extensions. Both extensions scan server mail traffic in real-time. But only Kaspersky allows fine-tuning and filtering of specific file types from attachments. Then there’s ImunifyAV – the leading malware-scanning tool. It ensures you keep malicious code away through antivirus, security and domain monitoring, blacklist status check, and one-click malware removal.

Endpoint Detection and Response (EDR) Software

EDR software - end point detection software - Plesk

EDR is a technology that addresses the need for continuous checking of file signatures. Checking for signs of malignancy and rapid responsiveness to advanced threats.

Whether it’s a Mac, PC, or a server, a good EDR system can detect suspicious activity running on any endpoint. This is especially important as even if a hacker has entered your system, for the hack to have a serious impact they must be able to siphon information out of your network. EDR software prevents this from happening by essentially placing compromised devices in quarantine, so no intel can be sent/received.

EDR is an advanced step in server security and so it typically comes at a cost. Kaspersky EDR provides full endpoint protection, from automatic threat blocking to complex incident response. It’s particularly popular for its comprehensive visibility across corporate networks and capacity to discover, prioritize, investigate, and neutralize advanced threats.

Anti-Phishing Tools

phishing - anti-phishing tools - Plesk

Phishing is a way of finding and gathering personal information using deceptive emails and websites. Techniques typically involve persuading people to click on malicious links by suggesting they are important and/or safe. It happens mostly through messaging platforms like email and chat apps. Built-in spam filters block most generic phishing attempts sent out to thousands of people. However, targeted phishing attempts, which may target specific individuals or organizations, can be harder to block.

Phishing is a particularly tricky form of cyberattack to protect against and it can appear so real. Neutralizing such scams, which have tricked even the savviest of CEOs, requires special anti-phishing tools. Warden Anti-spam and Virus Protection is a paid extension designed for power users and service providers. Besides providing high-performance and simple antivirus tests, it also offers support for nearly 30 SpamAssassin plugins. And is therefore one of the most robust anti-virus and anti-spam tools around.

Encryption Tools

encryption tools - Plesk

Encryption tools are software that use cryptography to prevent unauthorized access to sensitive information. It works by encoding data from “plaintext” into “ciphertext”. This process turns unencrypted information into an encrypted form for which you need a key to decode. Typically a password, making it harder for outsiders to access.

There are two main types of encryption: software and hardware encryption. Software encryption is more selective and focuses on encrypting individual files and folders. Hardware encryption involves encrypting entire devices.

Linux users will be used to connecting to servers using SSH keys. SSH (Secure Shell) keys are access credentials used in the SSH protocol. A secure and widely used standard for strong authentication, secure connection, and encrypted file transfers. Using SSH keys is more convenient and secure than traditional passwords.

From Plesk 12.0 onwards, you can use SSH Keys Manager to effectively manage SSH keys from the Plesk UI.

Specific Server Security Tools

specific server security tools - server security software - plesk

Some of the most popular Plesk extensions are those which improve your server’s security. Here are some of the most powerful ones which help combat server threats.

Sentinel Anti-malware

Sentinel Anti-malware is a scanner that combines the open-source principles from Linux Malware Detect and ClamAV. This extension especially serves power users and service providers who want to ensure they have protection from a variety of malware.


This premium extension (free trial for 30 days) protects Linux servers against critical vulnerabilities. Mainly by automatically installing security updates to running kernels. This avoids rebooting servers and planning scheduled downtime for your customers. And it also ensures kernels are updated within hours of patch releases for uninterrupted security.


The BitNinja extension prevents 99% of malicious attacks. This can consequently reduce your server alerts and customer complaints by just as much. It actually provides protection against nine different aspects of attacks – including malicious port scans and infections. You can even set it up and start automatically protecting your server in as quick as five minutes.


Cloudbric provides award-winning enterprise WAF and DDoS protection. Firstly, it has a threat detection system for real-time security against hacking attempts, website defacement, DDoS attacks, and spambots. Secondly, you can activate it with one click and try it for two weeks for free. While also benefiting from Cloudbric’s free and expert technical/security support.

DDoS Protection by Variti

DDoS Protection by Variti protects sites from DDoS – one of the most popular online attacks. As well as other types of sophisticated bot attacks. It does this by analyzing real-time traffic and passing it through a distributed network of VARITI filtering nodes. This extension is ideal for companies that depend on online traffic protection for their business.

Atomic Secured Linux

The Atomic Secured Linux extension provides the same level of protection that typically comes with an expert security team. It can prevent, detect, and respond to today’s greatest cybersecurity challenges. In particular, it features host and kernel intrusion prevention systems, brute force protection, and automated malware removal.

(D)DoS Deflate Interface

(D)DoS Deflate Interface is a lightweight shell script that helps deflect DDoS attacks automatically. The script runs in the background, blocking incoming connections from multiple IPs from which connections exceed the configured threshold. And above that – It’s simple to install and operate.

Penetration Testing Software

Password policy vs Hacking Techniques

Penetration testing software is the final line of defense in your security arsenal. Professional ethical hackers simulate a cyberattack (penetration testing), allowing enterprises to find weaknesses in corporate networks long before attackers do.

Rather than just software, penetration testing is often handled by human experts. Once your systems are in place, this added level of security helps you answer two questions in particular. First – does your security system have enough layers? And second – do those layers actually work?

In penetration testing, certain tests can, however, run autonomously. For example, Burp Suite’s vulnerability scanner autonomously crawls an enterprise’s web presence in search of common security holes. Including cross-site scripting, SQL injections, and volatile content. Admins can schedule Burp scans and see the resulting analysis in the form of detailed visual maps. Allowing for the ultimate control and protection of your business’s data.

How tight is your server security against attack? Do you use these tools or different ones? Let us know in the comments below!

Best practices to strengthen Plesk server security

Best practices to Strengthen Plesk server securty - Ples

Server security is the core of server management for any web hoster and server admin. Any online business should take server security seriously. Here we’ll explore the most important aspects at hardening Plesk servers and monitoring them for security vulnerabilities.

Plesk server security hardening

Plesk Server Security Hardening – Generic Steps

Latest Plesk has enhanced level of security right after the installation. Recently, Plesk launched Advisor, which unifies the best possible security practices and performance tune-up of the server and hosted websites. At the same time, it’s a good idea to ensure the following routine steps:

  • Insure regular Plesk updates
  • Change password strength to Strong
  • Use two step verification by installing Google Authenticator
  • Use SSL/TLS to secure mail server
  • Set sFTP connection
  • Limit administrative access to the system
  • Limit remote access via XML API
  • Actively use Web Application Firewall
  • Actively use WordPress Toolkit Security Check
  • Set automatic updates for WordPress instances
  • Insure outdated web applications are not used or update them on regular basis. The failure to comply this rule may result unexpected security vulnerabilities
  • Use VirusTotal Website Check to check existing websites

Block all ports which are not in use with the help of firewall.

server security tips for Plesk under Linux

Server Security Tips for Plesk under Linux

  • Use keyfile to allow SSH access
  • Use custom port to establish SSH connections
  • No SSH authentication for root user
  • Turn off Perl/Python for the website if these languages are not used as well as do no use mod_perl/mod_python
  • Use Opsani vulnerability scanner
  • Set Fail2Ban to prevent hacking attempts
  • Avoid PHP handler served as Apache module – not a secure practice
  • Ensure automatic updates of system packages are on
Server Security Tips for Plesk under Windows

Server Security Tips for Plesk under Windows

  • Custom port usage for RDP connections is a must
  • Get rid of unused programming languages
  • Make sure you install the latest Windows updates
  • Restrict users from overriding  handlers via web.config files
  • Keep DDoS protection enabled
What to do if server security is compromised - Plesk

What to do if server security is compromised

What we suggest here is migration to the new server. With a successful attack, intruders raise their privileges to root level – meaning they can do anything with the server. And just because you find malware/rootkits during investigation and clean it, doesn’t guarantee no others inside your system. It’s possible to load malware directly into RAM. There can be backdoors enabled or even common cronjobs for wget to download rootkits from already infected servers.

Try to restore the server using a previous snapshot doesn’t mean no server problems. Because in many cases, it’s not clear when exactly the server was hacked and rootkits  uploaded to the server.

How to identify the source of the problem

How to identify the source of the problem

While using security solutions dedicated to scanning for rootkits/malware you need to understand the following – these solutions use only already known patterns to identify the presence of malware and can be completely useless for new malicious software. To be 100% sure on how the server was hacked please contact security audit company which specializes on such cases. Please do not change anything before investigation to avoid the loss of traces.