@Seba,
I am not sure in which context I have to place the line
even if you can see which ports are open how easy will be to emulate a connection from the specified IP that is allowed to connect to it?
and it might be relevant to specify that context.
With respect to pentesting, you have to be aware that a full or thorough pentest of Plesk Panel is not really possible, for many obvious reasons - I will give some explanation.
For the sake of convenience, I will abbreviate penetration testing to something like "pentesting".
First, there is the issue of zero-days and/or server vulnerabilities that are not related to a Plesk instance - they are related to hardware, firmware and/or OS.
Second, every Plesk instance is a Nginx based server application - which application is unrelated to Apache web server, Nginx (stand-alone or as a reverse proxy) and any kind of other application hosted via the Plesk (hosting) Panel : it is good practice to perform pentests
per application.
Third, even when "peeling the onion of applications that compose Plesk and the server it is hosted on", one still can get the tears in the eyes - any pentest can be causing a lot of related and unrelated problems, allowing succesful penetration : in this scenario, it is not the pentest that is succesful, it is just the combination of applications, server layers, configuration applied (and so on) that fails, with this failure resulting in succes for a pentest.
The last point must be clarified a bit and I will do so with two examples.
One simple example : if Nginx based security measures fail, that does not mean that Apache is insecure - it is just the combination of Nginx + Apache that fails (and without Nginx as a reverse proxy, it can be the case that an identical pentest will not succeed when only aiming at Apache).
Another
important example : combining attacks, such as an DDoS or brute force attack with a separate attack on Apache or SSH, can be very valuable for hackers - due to the overload of the system, a lot of security measures will fail to work properly..... and one of the main culprits is Fail2Ban (and if Fail2Ban is not working properly, then the "overload attack" is creating circumstances that allow more easy access to other services or ports, which are attacked by the second type of attack).
Fourth, everything "in memory" is the most important vector of the attack surface - it is hard to detect and difficult to resolve : any "staged attack" that creates an entry that is cached or stored in memory can be used in a later stage to execute malicious code, without the sysadmin knowing it or being able to detect it properly.
In short, you should just pentest each server level (Apache, Nginx etc) separately, followed by a pentest for common applications on the server (WordPress and similar) and afterwards, one could do a pentest of the entire system, OS, memory and/or such alike.
At least, that is the most easy method, when taking into account that a full pentest is almost impossible.
I hope the above helps a tiny bit.
Kind regards.........
PS When doing a pentest,
always create a separate machine containing all relevant hack tools that are there and freely available - that will cover 90% of the attacks. Please discard the machine with hacking tools installed, as soon as possible - it is not good to have such a machine on your name (read: reputation considerations)
or not good to continue usage of this machine (read: any automated check could also result in the "hacking machine" ending up on a blocklist of some kind, hence making your pentests a bit biased - if the IP ends up by accident on a blocklist, then some tests would be invalidated)
or not good to keep the machine open (read: any "hacking machine" with a lot of freely available hacking tools is
vulnerable itself, implying that indirect access to the server that has been pentested can be easily obtained!).