Resolved Plesk - The Mysterious Location Of Plesk's Official IP Addresses / CIDR Addresses

[learning_curve]

Server operating system version

Ubuntu 22.04.2 LTS

Plesk version and microupdate number

Obsidian 18.0.53

We use the Juggernaut Firewall on our Cloud Servers, not the Plesk Firewall (you can't use both at the same time). Very happy with the performance from this Application, especially for its active use against DDoS attacks and geo-location banning, but the issue that we have, ironically, is with Plesk IP Adresses...

Back in the days of Plesk Onyx, it was possible to look up & therefore not ban, any of the Plesk IP Addresses in the list, provided and stated by Plesk. With the arrival of Plesk Obsidian / Plesk 360, there appears to be NO accessable list any more and when previously asked, the Plesk response was: "...will be published soon..." but of course it hasn't been or, if it has, it's being held in some secret location somewhere and there's no clues as to that location (unless we've missed it!).

Below is a sanitized, shortened example, of a Plesk IP address that was temporarily banned due to the number of consecutive connections - 237 - all within a short space of time.

So Plesk... Can you provide the (url location) of the list of Plesk IPs / CIDRs / CDNs that are used for both Plesk itself and Plesk 360?
If you can't (or won't), then please explain how, we're supposed to accommodate these regular sets of Plesk multiple connections? ("..just use Plesk Firewall..." is not a usable answer!)

2023-06-13 06:39:19

89.***.***.***

Datacamp Limited

United Kingdom, Tower Hamlets, Tower Hamlets | ********.lon.cdn77.com (CDN Platform)

*

in / out

Connections: 237

 

[Peter Debik]

Thanks for this interesting question. It is a valid request. I'll try to find out more.

 

[Peter Debik]

https://support.plesk.com/hc/en-us/...he-firewall-to-connect-a-server-to-Plesk-360- in combination with https://monitoring.platform360.io/whitelist.php probably provides a complete list.

 

[Peter Debik]

We also have autoinstall.plesk.com that is on 89.187.164.38, 89.187.164.52. But the number of requests to those IPs is low so probably no need to allowlist them.

 

[learning_curve]

Thanks @Peter Debik That's a great starting point!
Yes, the two 89 prefix ID's are both located in the UK via CDN77 so in our case, we'll add those as well.
We'll keep a close eye on the autoinstall.plesk.com area, as there might have been other IP's used previously (but now discontinued / swapped etc maybe)
So this is resolved now, but if there's any further additions / queries, we'll post them on this thread again

 

[larryk]

@Peter Debik are those IPs updated?
So in theory, I can whitelist those IPs and then block Germany as a country on my firewall?
if so, will Plesk and monitor360 work?
thanks

 

[Peter Debik]

It's unpredictable, because Plesk uses Cloudflare. Depending on the routing of your ISP the response for request to Plesk services could come from different Cloudflare IPs. It will probably come from their nearest peering points, but this is not guaranteed.

 

[learning_curve]

It's unpredictable, because Plesk uses Cloudflare. Depending on the routing of your ISP the response for request to Plesk services could come from different Cloudflare IPs. It will probably come from their nearest peering points, but this is not guaranteed.

Hi @Peter Debik is this ^^ a change of tactics from those that you kindly illustrated in post #3 and post #4 in this thread?

If it is... would that then mean that we're back to post #1 in this thread again?

Or...

Do all of the IP addresses covered in post #3 and post #4 in this thread already include all of the Plesk utilised, Cloudfare IP's anyway, so we, who don't have any current requirements, to block ALL Germany Geo-Locations, can just continue being happy campers with our existing Server / Juggernaut Firewall setups?

 

[Peter Debik]

I probably mixed my response with something I had in mind that another user recently posted where blocking Germany also blocked some license server connection or so. In that case I first thought that it must be due to some Plesk servers hosted on German ip addresses, but it turned out that it can also mean that when CDNs come from there, they are blocked, too. You can try to add all public cloudflare endpoints, too, that should do the trick.

 

[learning_curve]

I probably mixed my response with something I had in mind that another user recently posted where blocking Germany also blocked some license server connection or so. In that case I first thought that it must be due to some Plesk servers hosted on German ip addresses, but it turned out that it can also mean that when CDNs come from there, they are blocked, too. You can try to add all public cloudflare endpoints, too, that should do the trick.

Thanks @Peter Debik Sometimes... Plesk do make things a little over complicated

Okay, so.... our updated understanding of IP's that Plesk do (or may) utilise, is as follows:

Post #4 in this thread
The three IPv4 addresses listed this page - Plesk 360
All of the IPv4 addresses listed on this page - Plesk 360 Monitoring
All of the IPv6 addresses listed on this page - Plesk 360 Monitoring
All of the IP addresses that are covered by the IPv4 and IPv6 CIDR ranges listed on this page - Cloudfare

Therefore, it would be beneficial to whitelist / not block any of these. If that ^ is all correct, that's fine. Thank you

Only comment is: ^^ that's a huge amount of individual IP addresses within the Cloudfare area.
Is it really ALL of those? Or could Plesk be a little more specific? e.g. Their own endpoint rules / their own specific sets / Plesk API extracted data etc?

 

[Peter Debik]

Cloudflare determines through which ip they deliver content, it's nothing that Plesk or other Cloudflare users can influence. So, yes, probably you need to whitelist all.

 

[mow]

Cloudflare determines through which ip they deliver content, it's nothing that Plesk or other Cloudflare users can influence. So, yes, probably you need to whitelist all.

So an ugly workaround would be to take a list of FQDNs Plesk uses, resolve IPs for those, and add them to /etc/hosts and the whitelist.

 

[larryk]

@Peter Debik @learning_curve

thanks for trying to make this all clear, easy, and valid

I'm using Juggernaut, which is where I'm whitelisting them. Juggernaut has Allow vs Ignore.

question: I'm seeing LOTS of log file entries from monitoring360 ???
I',m assuming that is because I have allow and not Ignore?
as in, I don't need to log each monitoring360 log entry... is that correct?

PS. While I love plesk, this type of thing is a joke. Why can't there be a simple page that plesk users can view to copy/paste, etc
AND have it be updated (or valid)....

surely the following is 150% true!!!
1) it would help EVERY SINGLE Plesk user
2) if Plesk company spent a couple hours writing this nice, simple, document ... it can't take more than a couple hours?
3) and maybe a couple hours a month to maintain?

wow... SO LITTLE cost to Plesk, but SO MUCH benefit to Plesk's Users

why has this never been done?

 

[learning_curve]

I'm using Juggernaut, which is where I'm whitelisting them. Juggernaut has Allow vs Ignore.

FWIW - We also use Juggernaut (Danami)

question: I'm seeing LOTS of log file entries from monitoring360 ???
I',m assuming that is because I have allow and not Ignore?
as in, I don't need to log each monitoring360 log entry... is that correct?

Freedom of choice.
A) You don't have to use Plesk 360 Monitoring (it's not compulsory)
B) If you do use it ^ then you can choose, exactly what you are monitoring, within Plesk 360 Monitoring itself
C) Then within Juggernaut, you also have many selective options, as to what you want to monitor / log / allow / deny / ignore etc

PS. While I love plesk, this type of thing is a joke. Why can't there be a simple page that plesk users can view to copy/paste, etc
AND have it be updated (or valid)....

From the above paragraph, not exactly sure what you want to appear on your "...simple page that plesk users can view to copy/paste. etc" (sic)
It might probably help, if you can explain what issues you're having, with which specific logs, plus when & where, together with your current log configs etc

surely the following is 150% true!!!
1) it would help EVERY SINGLE Plesk user
2) if Plesk company spent a couple hours writing this nice, simple, document ... it can't take more than a couple hours?
3) and maybe a couple hours a month to maintain?

wow... SO LITTLE cost to Plesk, but SO MUCH benefit to Plesk's Users

why has this never been done?

See previous comment, but once that's clear, only somebody from Plesk, can answer that.

 

[regenix]

https://support.plesk.com/hc/en-us/...he-firewall-to-connect-a-server-to-Plesk-360- in combination with https://monitoring.platform360.io/whitelist.php probably provides a complete list.

So just to confirm, these are the IP addresses that we need to whitelist in our firewall in order for ordinary Plesk licensing to work? I did a who.is on a few of the IP's and the ones I looked at were all just listed as Vultr servers. Also (since I saw you mention Cloudflare) could I just get away with whitelisting all traffic from Cloudflares ranges? It would be nice not to have to add all these IP's to a whitelist incase you guys ever decide to drop them and they get recycled by vultr to a less that friendly user if you know what I'm saying.

 

[learning_curve]

So just to confirm, these are the IP addresses that we need to whitelist in our firewall in order for ordinary Plesk licensing to work? I did a who.is on a few of the IP's and the ones I looked at were all just listed as Vultr servers. Also (since I saw you mention Cloudflare) could I just get away with whitelisting all traffic from Cloudflares ranges? It would be nice not to have to add all these IP's to a whitelist incase you guys ever decide to drop them and they get recycled by vultr to a less that friendly user if you know what I'm saying.

Our current opinion, is that Platform 360 Monitoring is now becoming a tedious, unnecessary waste of time and effort, in order to make it function correctly, in any potential users' interest, all because of a loose, vague, and seemingly security compromising approach, to make it operate correctly / without creating lots of spurious log entries about connection issues / api issues etc etc This part: "... a huge amount of individual IP addresses within the Cloudfare area...." are all to be whitelisted.... really does appear to be pure Mickey Mouse Application Management.