Resolved Firewall ports for updating

[Pleskie]

Hello,

In this list https://kb.plesk.com/en/391 I see a lot of firewall ports that Plesk uses.

I would like to know which of there ports MUST be opened for Plesk to be able to update all of the services and components (also third-party).

I like to set the firewall rules (policy) of incoming traffic to Deny and only open required ports, but I'm not 100% sure which ports are required for the complete update process. (so I'm not talking about ftp, ssh, vpn, http and so on ... I'm just talking about ports that are involved with the (automatic) update process).

So far I opened port 6308 (Plesk Web Server) and port 8447 (Updates en upgrades) but I would like to know if more ports should be opened. I see in my logs that at night some automatic updates occur which sometimes fail, so I wonder if it has to do something with firewall ports that should be opened (but are closed at the moment).

So basically my question is: are there other ports, besides 6308 and 8447, I should open for the update process to succeed?

 

[Pleskie]

Hello, I'm new here ... can someone read this message?

 

[Pleskie]

Is my question too difficult?

Let's try again ... I want to change the firewall policy so that by default incoming traffic is denied. I would like to open only the ports that are actually required.

I would like to know which of the ports are involved with all of the updating that Plesk does. I already opened port 6308 and 8447. Are there other ports I should open?

 

[UFHH01]

Hi Pleskie,

the Plesk Control Panel itself uses the port "8443" ( or "8880" if you desire non-https connections to your Plesk Control Panel ) and port "6308".
The Plesk autoinstaller uses port "8447" to communicate with update - servers.
The licences for Plesk are configured to use port "5224" ( outgoing ).

If you deny other ports on your server ( as suggested at the mentioned KB - article ), you will notice errors/failures/problems, that's why Plesk lists all necessary ports at the KB - article.
Just a simple example: If you would like to use the Plesk Filemanager and didn't open port "20" and port "21" ( and port "990" for secure connections ), the Filemanager is not usable.
Another example: If you don't open port "110", "143", "465", "587", "993", "995" and "12768", your mail-server will not be able to work as expected.
And a third example: If you don't open ports "80", "443", "7080" and "7081", your webserver ( apache and nginx ) can't serve websites as expected.

 

[Pleskie]

Thanks UFHH01.

The second part I totally understand. I can choose the appropriate ports to correspond with my specific needs.

However I would like to know which ports are required for the update process. So besides specific services like FTP/SSH/mail/http and so on, which ports should I open for Plesk to be able to perform all the required updates?

So if I understand correctly, Plesk panel itself uses port 8443 and 6308, and for updates 8447. These ports are open so that's good. You also mention port 5224 ... but this is for OUTGOING connections only, correct? So for incoming connections port 5224 can be closed?

SUMMARY:
1. in the firewall I set the default policy for incoming traffic to 'Deny'.
2. the default policy for outgoing traffic I leave unchanged (accept)
3. I open the ports for services that I need (for example ssh, apache and mail, plesk panel interface)
4. in order for Plesk to be able to update all of its components/services I open (by adding custom rules) port 6308(tcp) and 8447(tcp) for incoming traffic

At point 4 are there any more ports that I should open for Plesk being able to update all of its components (also third-party like phpmayadmin, mysql and so on)?

(Besides firewall ports are there perhpas also specific services that should be enabled at all times for Plesk being able to update?)

 

[UFHH01]

Hi Pleskie,

So if I understand correctly, Plesk panel itself uses port 8443 and 6308, and for updates 8447. These ports are open so that's good. You also mention port 5224 ... but this is for OUTGOING connections only, correct? So for incoming connections port 5224 can be closed?

correct.

At point 4 are there any more ports that I should open for Plesk being able to update all of its components (also third-party like phpmayadmin, mysql and so on)?

no.

(Besides firewall ports are there perhpas also specific services that should be enabled at all times for Plesk being able to update?)

well sure, if the Plesk services and the depending services services are not running, your updates won't work.... I really don't undestand this question, because I'm not sure, what you are trying to achieve... a "minimalistic" server, running services by requests?
As a final note, pls. be aware, that switching of services, which Plesk depends on, can cause issues/problems/failures, which you may investigate with your error - logs, or as well with errors over the Plesk GUI, or the command line. Just as an example: If you switch off your database-server, Plesk won't work at all and if for example you switch off "pc-remote", you will notice issues with your mail-server. You might notice as well, that some functions are not available over the Plesk, if you insist of switching off a depending service.

 

[Pleskie]

Thanks ... so the firewall ports are correct ... that's good.

I will explain a bit better ... on my server I want to open only ports and services that I need myself or that Plesk needs to function properly. I would like to close/disable all other ports and services that are not being used by me or by Plesk.

When (in Plesk panel) I go to Tools & Settings -> Services Management I can disable certain services. For example I can disable PostgreSQL or Tomcat Java since I won't be using them. But are there any services in this list that MUST be enabled for Plesk to be able to update properly? For example if I turn of mail related services (for example SMTP server) will this cause a problem for the normal behavior of Plesk? For example does Plesk use mail sometimes (for example to report errors when updating fails)? So which of these services on the Services Management page must be ALWAYS enabled for Plesk to function properly? Or could they all be turned off and will Plesk still be able to update properly?

Hope this clarifies and sorry if I wasn't very clear in the first place.

 

[UFHH01]

Hi Pleskie,

For example I can disable PostgreSQL or Tomcat Java since I won't be using them.

There is no need to install these services on your server, if you don't use them. Please uninstall unessecary services and Plesk won't offer corresponding configurations ( and Plesk-modules ) for it. Consider to uninstall as well corresponding modules from a Plesk template installation ( mostly offered as image - file from your hosting company, to make it easier to install a standard operating system and the Plesk software ).

If you want a non-standard operating system and Plesk version, pls. consider NOT TO USE the images from your hosting provider, but install a server completely on your own and afterwards install Plesk on it, as described at:

[HOW TO] Install Plesk for Linux ( KB - article 119521 )​

This way you can be sure, that you have only services and Plesk modules installed, which you really need, because YOU choose on your very own, what you want to install.

 

[Pleskie]

>> There is no need to install these services on your server, if you don't use them. Please uninstall unessecary services and Plesk won't offer corresponding configurations ( and Plesk-modules ) for it.

These services were already there. I installed an image from the hosting company and these services (and more) were already available.

The hosting company provides and integrates also automatic licenses, so I think it's better to use their images than to experience on my own, since the license-system might fail then.

 

[UFHH01]

Hi Pleskie,

it is far easier, if you just "play around", to use a free "TRIAL KEY", if you just want to learn how things work with Plesk, or want to learn something about linux administration:

=> Download Your Plesk Free Trial

Pls. read as well:

=> license: License Keys ( Plesk online documentation for Plesk 12.5 )

=> How can I find out my Plesk license key number on my Plesk installation? ( KB - article 5207 )​

 

[Pleskie]

Thanks, for now I'm doing quite well. Have used cPanel in the past, long time ago. Already I like Plesk much better ... but it's just some small things you have to learn

 

[Pleskie]

One last question. Earlier you shortly mentioned port 12768. In the description it says "psa-pc-remote (for localhost only)".

Does this port have to accept incoming traffic? (since it says "localhost only") ... As I said earlier, I set default policy for incoming traffic to 'Deny'. Should I add custom rule for port 12768 to accept incoming traffic? Or is it not necessary because it is localhost only?

 

[UFHH01]

Hi Pleskie,

Does this port have to accept incoming traffic? (since it says "localhost only")

Let's re-question your question: What will happen, if you deny all traffic ( incl. localhost!!! ) for port 12768 ? Well, it's the same situation, as stopping the service : the port can not be used and traffic, routed with the help of your postfix configuration files for your mail-server, won't reach that service.

If you would like to allow localhost for port 12768, because you set a global policy "Deny from all" you have to add a "custom rule" for the IP "127.0.0.1" on that port ( in this case for TCP connections ). "Deny from All" doesn't exclude localhost.

 

[Pleskie]

Thanks, that answers my question.

I thought that Denying incoming traffic only meant "traffic from outside the server". I didn't know it also blocks localhost

I will add custom rule then for ip 127.0.0.1 on port port 12768 tcp. Thanks for clarifying!

 

[trialotto]

@Pleskie,

It has taken you some posts to get you somewhere, but actually, your questions are not completely answered.

In fact, what you really aim to do is "closing" ports for all USED services.

Well, in the answers, I do not read a lot of practical tips and answers.

It is quite simple, let´s start with some golden rules:

a) do not edit iptables via the command line, instead use something with a GUI, his is less error-prone and will hence prevent some issues (like locking yourself out of the system)

b) use the Plesk Firewall Extension: it already contains some preconfigured firewall rules for specific services, like Tomcat, PostgreSql etc.

Just disable (rule: deny) the following:

- Customer & Business Manager payment gateways
- Single Sign-On
- Mail password change service
- Tomcat administrative interface
- Samba (file sharing in Windows networks) (an extension that you should not use!)
- Plesk VPN (again, an extension that you should not use)

Just limit (rule: allow for, deny all others) the following:

- FTP server (limit to your personal IP and other IPs that should have FTP access)
- Plesk Installer (limit to your personal IP)
- Plesk administrative interface (limit to your personal IP and those IPs of your customers)
- MySQL server (limit to 127.0.0.1, see note 1 below)
- PostgreSQL server (limit to 127.0.0.1 or completely deny, because you will probably not use this)
- SSH (secure shell) server (limit to your personal IP, but see note 2 below!)

Note 1: strictly, this is not necessary, you can do this via "Tools & Settings > Applications & Databases > Database Hosting Preferences". However, a firewall based limit to localhost is something that can be recommended, it just enhances security.
Note 2: only you or a sysadmin should have SSH access. However, the Plesk Migrator has the nasty habit of using ssh. So, whenever trying to migrate domains to another server, just add the IP of the target server (and do the same in the firewall on the target server: add the IP of the source server).

That is about it, everything else can be "open".

However, it is always good to

- create custom rules with "bad" and "notorious" IPs (there is one specific reason why this is good, I will explain later, in point c)
- apply strict security settings for the entire server, for instance, at least at the level provided with the command line utility called pci_compliance_resolver

Note that one can discuss each individual port, but that really makes no sense and/or is completely inefficient.

For instance, port 12768 is ONLY relevant if you use Postfix (and otherwise it is not) AND custom firewall rules for port 12768 are barely relevant, when PCI compliant settings apply.

As another illustration, one can spend a lot of time on firewall rules for "outgoing traffic", but that actually is not worth the time. All trouble is inbound, at least that is often the case.

c) Enable Fail2Ban !!!!!

Fail2Ban is a log scanner, resulting in an automated adjustment of iptables rules: specific IPs are blocked during a specific interval.

Well, you can imagine by now that Fail2Ban becomes rather busy when the custom rules "bad" and "notorious" are not explicitly present in the Plesk Firewall.

Those bad/notorious IPs are essentially IPs that try to brute force (read: try over and over again) and Fail2Ban has little power over them, except for blocking them temporarily.

Using Fail2Ban in the case of bad/notorious IPs is not only ineffective, it will also cause a performance penalty.

So, creating the custom "bad" and "notorious" rules simply results in those IPs in being blocked permanently, not even entering the logs, that are scanned by Fail2Ban.

Your system is safer and Fail2Ban gets a holiday.

However, you cannot do everything by hand, you cannot enter all bad/notorious IPs in the Plesk Firewall (there are literally millions of those IPs), so Fail2Ban fine tuning is also required.

Go to "Tools & Settings > Security > Fail2Ban > Jails > Recidive (select jail) > Change Settings (click)" and

- change the number for maxretry to a lower value (3 is often a good value)
- increase the ban period (for instance, take a month, which should be 2419200 seconds)
- keep track of fail2ban.log and look for the IPs with the text "recidive" and "ban" (if one IP is recurring, even after previous bans with the recidive jail, add the IP to Plesk Firewall: add them manually to the "bad" or "notorious" custom rule)

and that is about it.

Hope the above helps a bit........

Ciao!

 

[Pleskie]

@trialotto Many thanks for your extensive reply! I already had installed the Plesk firewall (it was installed out of the box) and I installed Fail2Ban manually

>> MySQL server (limit to 127.0.0.1, see note 1 below)

Good one, this is required for mysql/mariadb to function properly, correct? I don't know why, but in my configuration it was by default denied for all incoming connections. A bit strange actually ...

>> Using Fail2Ban in the case of bad/notorious IPs is not only ineffective, it will also cause a performance penalty.
>> So, creating the custom "bad" and "notorious" rules simply results in those IPs in being blocked permanently, not even entering the logs, that are scanned by Fail2Ban.

I understand what you mean ... but I wonder if it's a good idea to block IPs permanently. I DO understand what you are saying, but let's say that a server is infected with a virus. Eventually you put that IP address for ever in your Plesk firewall. Couple of weeks later that specific server is reinstalled and the virus is gone. However the IP address will exist in your firewall forever. You could end up with hundreds of permanently blocked IPs of which maybe half of them are not relevant anymore. Using only Fail2Ban to temporary block these IPs (as long as necessary) might be more effective in the end. It keeps your firewall as clean as possible depending on the current situation. Only the bad IP adresses at that current moment/period will be blocked. In the end, wouldn't that be better for performance? If you use only Fail2Ban, then you can be sure that blocked IP addresses are indeed bad IP addresses at that moment in time. If you add IP addresses manually you could end up with hundreds of permanently blocked IP addresses that were notorious 3 years ago, but haven't been notorious since 2,5 years anymore. So yes I see and understand your point ... but maybe using only Fail2Ban would suffice.

>> - apply strict security settings for the entire server, for instance, at least at the level provided with the command line utility called pci_compliance_resolver

Could you tell me more about this? This is some sort of tool ... ? What should I do with it and how? Will it make my server safer?

 

[IgorG]

Could you tell me more about this? This is some sort of tool ... ? What should I do with it and how? Will it make my server safer?

http://docs.plesk.com/en-US/12.5/ad...ce/tune-plesk-to-meet-pci-dss-on-linux.65871/

 

[Pleskie]

Thanks Igor ... that was fast (I should learn to use the search-function more often, haha)

So all I do is type this in the terminal: plesk sbin pci_compliance_resolver --enable

That's it? And this will make my server more secure? Correct?

Are there any catches? This won't disturb the normal behavior of (services on) the server?

(Maybe a stupid question, but if it makes the server safer why isn't it enabled by default?)

In addition: is executing this command one time enough to keep the protection up to date for ever, or do you manually have to trigger this command once in a while?

 

[trialotto]

@Pleskie,

In response to your statement(s)

It keeps your firewall as clean as possible depending on the current situation. Only the bad IP adresses at that current moment/period will be blocked. In the end, wouldn't that be better for performance? If you use only Fail2Ban, then you can be sure that blocked IP addresses are indeed bad IP addresses at that moment in time. If you add IP addresses manually you could end up with hundreds of permanently blocked IP addresses that were notorious 3 years ago, but haven't been notorious since 2,5 years anymore. So yes I see and understand your point ... but maybe using only Fail2Ban would suffice.

I can respond with a number of remarks:

a) the firewall is never "clean", if you use Fail2Ban: in fact, a whole lot of IPs will be added through Fail2Ban within a short period of time. Moreover, the process of "adding and removing" IPs by Fail2Ban is a continuous process.

In essence, the above is not my definition of "clean".

b) Fail2Ban is associated with a potential on a huge penalty for performance, any firewall (or iptables) is not.

The golden rule is: let Fail2Ban do as little work as possible, since it will consume resources.

One particular reason for this golden rule is that attackers can shut your server down with an distributed type of attack, simply by causing a memory and CPU overload.

Another particular reason for this golden rule is that Fail2Ban, with the standard jails shipped with Plesk, is not really efficient (and hence, not really safe), see point c.

c) "Only using Fail2Ban" will not suffice, for many reasons.

However, to keep it practical, let´s illustrate by mentioning the fact that the default Plesk jails for mail related services do not really stop brute-force attack attempts: have a look at the fail2ban.log, look for a mail related jail and you will notice that bad IPs are detected, but in most cases:

- the bad IPs are not banned, due to specific maxretry settings AND the scanning interval settings (which cannot be set via the Plesk Panel, as such a "design flaw"): most of the mail related brute-force scripts are simply retrying just "outside" the scanning interval, in order to work-around Fail2Ban detection
- bad IPs are banned for a short period and, in the end, identical bad IPs will retry over and over again, after those bad IPs have been unbanned

Sure, one can tweak Fail2Ban settings, but that does not always make sense: just block some bad IPs manually and most of the problems go away.

d) with respect to "If you add IP addresses manually you could end up with hundreds of permanently blocked IP addresses that were notorious 3 years ago, but haven't been notorious since 2,5 years anymore." I can say that you must be aware of the fact that most "notorious" IPs are never changing owners.

This is one of the reasons why I recommended to use a "bad" and "notorious" custom rule in the Plesk Firewall.

And, in addition, it is always better to protect against malicious traffic than allowing for traffic and afterwards concluding that it actually was bad traffic: be pro-active, prevent issues.


Hope the above helps a bit...

Regards

 

[trialotto]

@Pleskie,

The post below requires a separate response.

Thanks Igor ... that was fast (I should learn to use the search-function more often, haha)

So all I do is type this in the terminal: plesk sbin pci_compliance_resolver --enable

That's it? And this will make my server more secure? Correct?

Are there any catches? This won't disturb the normal behavior of (services on) the server?

(Maybe a stupid question, but if it makes the server safer why isn't it enabled by default?)

In addition: is executing this command one time enough to keep the protection up to date for ever, or do you manually have to trigger this command once in a while?

There are no real "catches", at least none that you should worry about.

However, you have to make sure that you tweak your Plesk instance a bit, for instance

- use Postfix + Dovecot (the pci_compliance_resolver has no effect on Qmail based mail servers, so no security enforcement in the case of Qmail)
- use TLS/SSL for FTP (this requires some adjustments, see my tips at https://talk.plesk.com/threads/tips...tp-with-tls-and-ftp-backup-repository.332166/)

and so on, the above is just a summary of the most important things to take into account.

Particularly note that applying the pci_compliance_resolver before you changed setup (let´s say, you did run the tool with Qmail activated) will not be enough: one has to rerun the command (in the case of "let´s say", you would be required to rerun the tool with flags --enable mail, from the top of my head).

In essence, the general idea behind PCI compliant settings is not that these particular settings are helping you in the process of banning bad IPs.

Actually, it is helping you to mitigate malicious traffic, due to the implementation of (relatively strict) TLS/SSL enforcement, which most hack attempts do not account for (yet).

That is all, hope the above explains a bit.

Regards......