Question Security, security and more security!

[Tr3Mendo]

Hi!

I've been working with servers and plesk for two years, but learning from tutorials.

Now I'm going to set up my own dedicated server, but I'm pretty scared about security.

There are tutorials that say I need to install ClamAV and RKhunter on my server, regardless of the security of plesk. Within plesk, just the configuration of Fail2ban and Firewall, but ... Where is the truth of all this?

I am in your hands to advise me on the security of my new plesk server.

- What do I need to install on my server?
- What should be changed on the server (ssh, firewall)?
- Inside the plesk panel, what is the best configuration?


I think someone should do a good tutorial on security, it would be very acclaimed by all. Thank you very much community!

 

[Ovi]

I am in your hands to advise me on the security of my new plesk server.
- What do I need to install on my server?
- What should be changed on the server (ssh, firewall)?
- Inside the plesk panel, what is the best configuration?

Hey there,
I'm no expert in Plesk or cybersecurity, but here are my 7 cents:

1) Start at Plesk University - Security course:
Plesk University

2) Step 2: follow the Advisor's recommendations and then:
How to secure a Plesk server

3) Step 3: BACKUP your settings and your server instance (if on cloud) or image your full OS (if you're on bare metal), and then:
https://support.plesk.com/hc/en-us/articles/213928005-Plesk-security-best-practices

4) Step 4: BACKUP and then install Google Authenticator and enable 2FA on your Plesk admin.
Use 2FA and optionally IP filter on ALL logins.
Create and use only SSH keys for logining into Plesk and your domains.
Install "SSH Keys Manager" extension. Use it on all domains and disable FTP login.
+Set passwords to all your ssh keys.
+Backup again.

5) Step 5: BACKUP, and depending on what you're actually going to use Plesk for (at the beginning I recommend you nginx as proxy to apache so modsecurity works as well; later on feel free to just use and customize only nginx if you use it for pure domain management and webhosting) :
5.1) Secure your MySQL and don't make your DBs public unless you're running apps that require public access. IF you do, use a dedicated VPS DB on a private cloud.
5.2) Same with mail, use a dedicated server / VPS / instance for mail.
5.3) Secure Apache with modsecurity and then don't touch modsecurity ever again. (it broke on me 2x and I had to completely restore the instance on AWS).
5.4) Secure Nginx:
Top 25 Nginx Web Server Best Security Practices - nixCraft
Nginx Web Server Security and Hardening Guide
HTTP Strict Transport Security (HSTS) and NGINX - NGINX
+Backup again.

6) Optimize and further secure your webserver against hackers and bots with various lists:
This is just an example of lists: mitchellkrogza - Overview
+Backup again.

7) ..did I mention Backup? Ok, I think you got it Now set a backup schedule every night on Plesk and as often as you want on your instance/server. Good luck!

Edit:
7.1) Make sure you also backup off-site and keep your off-site backups encrypted (and don't lose the encryption password or else all the passwords for all the accounts in the backup will be reset).

8) In addition to his reply below, also see @trialotto 's post in the other thread on how to block bad traffic:
Resolved - Keep changes in nginx.conf

9) More official info on securing plesk:
Securing Plesk and Enhancing Security

 

[trialotto]

@Ovi,

This

Install "SSH Keys Manager" extension.

is not a good idea : using any kind of "manager" narrows down the attack surface and makes hack attempts more rewarding, since any succesful attempt to fiddle with a Key Manager is allowing a hacker to gain (very easy) access to all keys managed by the Key manager and hence access to all services and servers managed by keys.

Neither is

+Set passwords to all your ssh keys.

a good idea : the whole point of using SSH keys is getting rid of passwords - in essence, using SSH keys with passwords is a lazy and very vulnerable way of increasing the security level of SSH keys.

And the whole point of increasing the security level is just increasing the number of bits - in this case, the number of bits of the associated SSH key - nothing else.

Simply stated, RSA 2048-bits SSH keys with passwords is still less secure than RSA 4096-bits keys without passwords.

In addition, SSH keys are very prone to be "lying around the place" - meaning : if certain SSH keys are re-used multiple times, just cracking one password is enough to gain access to a (relatively) huge number of systems - and hackers know that, they tend to search for password-protected SSH keys.

For the remainder - I do like your rough guidelines to security, even though there are many pitfalls in just "following instructions, written by others" (one has to think!).

For instance, there are many security hazards that are present by default in Plesk : one will not find them in any manual....... so why follow these manuals to the letter?

Anyway, I appreciate your contribution - many thanks!

Regards......

 

[TomBoB]

Now that SSH is mentioned, change the port away from the standard 22 to something non-standard, somewhere beyond 10000 for example. Stops your server getting blasted with login attempts. And helps Fail2Ban by not having to deal with it.

 

[trialotto]

Now that SSH is mentioned, change the port away from the standard 22 to something non-standard, somewhere beyond 10000 for example. Stops your server getting blasted with login attempts. And helps Fail2Ban by not having to deal with it.

@TomBoB

Again, this is an idea - but the idea is flawed in many ways.

First of all, just using a high port number is not a solution - it can even become a problem, since the higher port numbers are often used for different purposes.

Second and in general, using a different port number might be effective from a perspective that only looks at the port that is attacked most - a script kiddie would indeed use the default SSH port, but any advanced hacker will do a port scan and target the effective port used by SSH : so, a different port number does not resolve anything.

A small note : most people with other than default SSH ports often tend to forget to restructure the entire system, leading to a situation in which the system is still insecure - for instance, when changing the SSH port, one still has to change the Fail2Ban (and many other) settings (and forgetting to do so would imply that the sysadmin is being "blind" for any hack attempt, which is even worse than the situation in which one uses default ports).

Third, there are many options to make SSH more secure, from very simple and basic to more advanced, like port knocking.

Nevertheless, anything different than default SSH settings is quite a fuzz, if

- one considers the fact that is not always about (secure) SSH settings, but more about (secure) access to SSH,
- specific basic access restrictions are just as good or even better then complex options to secure SSH,
- specific changes in SSH settings or settings to access SSH makes the sysadmin effectively "blind" for what actually happens in the system,
- specific changes in SSH settings should also be reflected in many other settings within the system,
- and so on

and all of the above is simply the equivalent of saying "the more complex the solution, the more the sysadmin has to change and maintain on the entire system".

Simply stated, improvements in SSH are not a stand-alone improvement : they should be accompanied by other improvements in settings and config.

Fourth and a bit explanatory of the term "blind" used before, any hack attempt on SSH should be visible, but not succesful.

Increasing the level of SSH security by fiddling with SSH or SSH related settings is not always the best idea : one should want to know the basic information - such as the offending IP - in order to take appropriate action on all levels - such as blocking the IP for access to the FTP server, database server and so on.

Really, SSH access obtained by a hacker is not the biggest nightmare of a sysadmin - it is only one of the many big nightmares.

Fifth and in conclusion, I would recommend to

- block all traffic to SSH port(s), with the exception of traffic originating from the IPs of the sysadmin(s), (and)
- if possible, use SSH keys

and that is a clean, simple and very effective solution, involving a small amount of work and maintenance.

Sure, that is a recommendation for the case that a sysadmin manages one or a couple of servers - in all other cases I would recommend something different.


Anyway, I hope the above helps a bit.....

Regards...........

 

[learning_curve]

- one considers the fact that is not always about (secure) SSH settings, but more about (secure) access to SSH

Plus

I would recommend to
- block all traffic to SSH port(s), with the exception of traffic originating from the IPs of the sysadmin(s), (and)
- if possible, use SSH keys

A great post. Fully agree and support very all these valid points ^^
By pure chance (good luck / happenstance) this is exactly how we have dealt with SSH security, since we started using Plesk