Issue Plesk, what’s going on here? - Imunify auto installation

[s.kazimierczak]

One more question. Is the uninstall button in plesk works correctly now? Or still we need to remove files and other stuff manually?

 

[trialotto]

I understand what your saying. Just wondering as we pay for licenses for a 'control panel' who is in 'control ' of the control panel....

For example Site jet was pushed . In the WP toolkit some external option was pushed. And now Immunify with out any notification and perhaps
that was a misunderstanding or something. But the Immunify scan (in the free version) which was pushed takes cpu processing power.
It would be nice if these kind of weird things would not be pushed.

/dev/null

@/dev/null

I firmly belief that a distinction should be made between a "good push" and a "bad push" - to stay in your terminology.

Some things we really cannot object to.

Nevertheless, Plesk has the history of adding "things" (of all sorts, being either extensions, components, upgrades, packages, etc) without being prepared for the future and/or without having thought about a solid implementation or a solid design infrastructure.

Despite this history, the simple fact is that the addition of those (bad) "things" does not happen frequently - not at all, at least in the bigger picture.

However, when it happens, there is some reluctance, delay, "bureaucracy" or whatever that prevents that (bad) "things" are discarded or removed permanently.

The issue here is primarily that Imunify is a (very) bad "thing" ........ gradually introduced during more than 3 years (if I am not mistaken) and ALSO causing issues during a similar period of (many) years.

I can only belief that Imunify is a "bad push", to use your terminology.

Plesk should simply be aware of the fact that an extension that is not optimal during many years, should NOT be "pushed".

That is not a mistake, one can only define that as a bad business decision - for both Plesk and Imunify.

Nevertheless, the problem here is not Plesk : the Plesk decision is to implement an extension as provided by Imunify.


In short, Imunify is the root cause of the problem here.

In the context of "pushes", you are absolutely right : Plesk should not have pushed the extension.

In the context of "development", there is this prolongated issue of Imunify extension not being up-to-standard or just playing nicely with Plesk.


In my humble opinion, the best action is to do nothing with Imunify (as far as possible), since that will simply lead to Plesk deciding to discard Imunify.

After all, Plesk also has the history of discarding extensions that are not providing substantial revenue and/or that are associated with conderable costs due to improper functioning of those extensions.

It is just an educated guess, but I firmly belief that Imunify will be replaced, as soon as a valid alternative will become available!


Kind regards.....

 

[trialotto]

Hello everyone.

My name is Ekaterina and I am product manager of Imunify extension in Plesk.

I investigated this matter with CloudLinux and would like to share with you the findings.
Thank you for your patience.

Imunify is widely acknowledged as a reputable and trusted security extension, consistently demonstrating its effectiveness and reliability across a broad user base.To further ensure data protection, I conducted an internal review in collaboration with the CloudLinux team.

As result of internal check conducted with CloudLinux team they confirmed that extension does not use personal or sensitive data for security analysis and it is removed instantly once found while still being on the server. It means that the personal/sensitive data is not transferred externally or stored on their analysis server.

CloudLinux team has no intent and do not use any personal or sensitive data and only suspicious/malicious information is analysed in order to provide security on the server.

Appreciate your understanding.

@Ekaterina Babenko

There might be some persons reading your message as a relief that data leaks are not present and/or cannot occur and/or are minimized.


The strange thing is that you suggest that "specific data" is not used and also not uploaded.

The above implies, if and only if TRUE, that the whole Imunify extension uses data from other sources than the Plesk instances it should be protecting.

The latter would also imply that

1 - CloudLinux has obtained the data from other sources, analyses that data from other sources and uses the data on instances with Imunify, (and)

2 - CloudLinux therefore must use and upload data for analysis, although being it from other sources than those instances running Plesk, (and)

and that would simply mean that

3 - data leakages, if any, might occur at the level of those "other sources" not running Plesk, (and)

4 - data gathering is not the result from Imunify, but from other tools used by CloudLinux on those "other sources" not running Plesk, (and)

5 - Imunify can be deemed to be less effective, since security / protection data is obtained from "other sources" not running Plesk, (and)

6 - Imunify can be or become highly inefficient, given the fact that Plesk instances are protected with security / protection data that originate from "other sources" that are not running Plesk, (and)

7 - Imunify will never be dynamic in the meaning of self-learning or self-improving, since security / protection data is not obtained from Plesk, (and)

8 - Imunify will only be static in terms of development, taking into consideration the fact that development can only go as far as the "other sources" not running Plesk will allow development, (and)

9 - Imunify will only be static in terms of security, given the facts mentioned in points 7 and 8.


Now I am worried, if your message contains facts and aforementioned points 1 to 9 coincide with reality to a very high degree.

Not only am I worried due to the poor condition of the Imunify extension - the packages and maintenance thereof is an issue for many years now.

I am also worried because

a) the level of protection offered by Imunify can be deemed to be fairly static : there is no value for "static protection" in the world of security with constantly changing threats - one does not even need Imunify, one can also use the public databases to obtain the same level of protection,

b) protection levels are determined or even limited by the nature of sources that are not even running Plesk : this is like training a goat to protect a Ferrari.


In short, I sincerely hope that the nature and contents of your message are not true.

Otherwise, it would be completely odd to have Imunify as an extension and certainly would not justify a paid-for Imunify extension.


In my humble opinion, Plesk should see the proverbial lighbulb and get that "Aha erlebnis".

There is this simple fact that, by law, one can use data under specific circumstances and the best solution would be that Plesk develops a tool / package that is feeded by (very) specific Plesk data to protect (very) specific Plesk data.

The additional advantage is that the tool / package would be more effective and more secure than can be guaranteed by any external developer.


Again, it is just some food for thought.


Kind regards....

 

[Fede Marsell]

There might be some persons reading your message as a relief that data leaks are not present and/or cannot occur and/or are minimized.

This is absolutely false and any user can prove it by viewing the Imunify logs: Issue - Important: Imunify auto installation and possible data leak

 

[trialotto]

This is absolutely false and any user can prove it by viewing the Imunify logs: Issue - Important: Imunify auto installation and possible data leak

@Fede Marsell

The words "might" and the condition "IF AND ONLY IF TRUE" should be read in the way they are intended : it is sarcasm.


It is almost impossible that the message posted by @Ekaterina Babenko is "true", in the sense of "being adequate".

In addition, whether or not data is uploaded, is an entirely different story with many associated questions and answers.


One of the issues here is that a lot of noise is present in this topic thread, due to the fact that subjective interpretations exist with respect to this topic.

For instance, you might have your own subjective or objective objections to Imunify and your own objectives when it comes to participating in this topic.

As another example, Plesk has their own objectives with participation in this topic thread and even opinions, hence not being facts.


In my humble opinion, you should stay on topic and refrain from subjective opinions and barely relevant facts.

It is more important to focus on the "gray matter" that is used and abused to justify actions and/or extensions like Imunify.


Yes, it is a fact that Imunify uploads specific data.

Yes, it is allowed by law that specific data is uploaded or used for analysis in the context of fraud detection and even prevention.

No, it is not desirable - however, this is a subjective opinion.

No, one cannot build a legal case against Plesk.

Yes, one can build a legal case against CloudLinux / Imunify - however, nobody is doing that.


In essence, the gray matter here is the challenge, with this gray matter consisting of amongst others (but not exclusively limited to)

1 - Plesk is allowed to offer and even install extensions, including those extensions that we find disagreeable,

2 - CloudLinux / Imunify is allowed, in legal terms, to use data for the purpose of fraud detection and/or fraud prevention, as defined in a legal context,

3 - CloudLinux / Imunify is NOT allowed to use data if one did not explicitly agree with usage of that data,

4 - data belongs to the owner of the site (and not the hosting provider),

5 - legal definitions that are rather broad (the term "fraud" is defined rather broad in a legal sense) or even obscure (the term "data leakage" is not described in a clear way, in the sense that there is no exhaustive summary of what should be considered to be "leaked data"),

and all of the above, even though it is a non-exhaustive summary, already points out that the gray matter is used and abused in the sense that there is no way that a clear-cut agreement or disagreement in the legal sense will exist with respect to the usage of data.


The above is one of the reasons why I am trying to convince you that you should not focus on the "obvious".

It simply will result in a discussion that cannot be won.

One can state something, Plesk will state the opposite.

One can object, Plesk will provide a - allegedly - reassuring message like that of @Ekaterina Babenko.


I am not propagating that we should stop the discussion.

I am only saying that Plesk has to be convinced that there is no space for Imunfy on Plesk instances.


A good way to convince Plesk is to keep hammering about issues with the Imunify extension - it is simply a warning that Plesk will encounter considerable development costs in order to have Imunify working properly and playing nicely with Plesk.

The best way is to convince Plesk that Imunify is - factually - determining what is "suspicious".

This is also the main problem here : Imunify is that kind of extension that flags (almost) everything as "suspicious".

And there we have it : if Plesk does nothing and allows a malcoded extension to create false positives that result in uploads to external servers on the grounds of fraud protection or fraud prevention, then Plesk will become FULLY LIABLE, since false positives are not a legal ground to share data.

Each and every false positive found is PROOF that there is no legal ground for sharing data for the purpose of fraud protection or fraud prevention.

Each and every false positive found is PROOF that the Imunify extension is not allowed to upload data to external servers.

Each and every false positive found is PROOF that Plesk is responsible to remove the Imunify extension immediately.

A failure to remove the Imunify extension will make Plesk fully liable for each and every false positive.


In summary, @Fede Marsell, build your case by providing (sufficient) evidence that multiple false positives are present and created by Imunify.

While doing so, please do not hesitate to create humbug files that will be uploaded to Imunify related servers - this is not about revenge, but only to amplify the proof that can be provided in order to establish that Imunify really is a (very) bad extension.


I hope that you will post your findings soon!


Kind regards ....

PS I did my part in the past already, but to no avail. However, it is kind of funny though that "humbug" files can make Imunify confused in such a way that it will even flag default Plesk files as "suspicious" - just saying, it is a tip. It should still work.

 

[Fede Marsell]

If you find this case worthy of sarcasm, you really have little interest.

 

[trialotto]

If you find this case worthy of sarcasm, you really have little interest.

@Fede Marsell

Wrong conclusion, I have more interest in this matter than most people.

In fact, I have asked a legal team to investigate the matter and to determine the competent court.

As opposed to talking about this topic, I am investing serious money to determine which kind of actions can be and should be taken.


Again, please note that it has to be emphasized that the legal quintessence of this matter is one of the scenario's consisting of

1 - a "not very well coded extension", (or)

2 - a "malcoded extenion", (or)

3 - an "intentionally coded extension that is willing and knowingly creating false positives to create a false legal ground to harvest data".


You are primarily talking about data leakages.

As from the legal perspective, if there is any obvious proof of data leakages in the legal sense, then there is always the very simple option to report this to the relevant authorities that exist in each and every European countries (and also in the US, for that matter).

This will only result in lengthy research and, if you are lucky, fines of either Plesk or CloudLinux / Imunufy.

Nevertheless, I have already submitted my report to the relevant authorities - did you?


I am primarily talking about the simple fact that Imunify is not coded properly.

As from the legal perspective, it is highly illegal to harvest data for fraud detection and/or fraud prevention purposes as a result of an extension that consists of or involves either scenario 2 or scenario 3, as mentioned above.

These latter two scenarios, especially scenario 3, are very important.

That is why I do take proper action.


As a final remark and as you might have noticed, I have changed this topic thread from "resolved" to "issue".

I am not the enemy, no need to be angry.


Kind regards....

 

[Fede Marsell]

Thank you.

I'm sorry if my comment wasn't appropriate, but English isn't my language, and I have language limitations when it comes to expressing very complicated topics (like this one).

Nevertheless, I have already submitted my report to the relevant authorities - did you?

I wouldn't know where to start.

I have many servers, on all of which this extension was installed without authorization. In all cases, it's clear how the extension sends files to third-party servers.

I have the logs for all the servers saved.

Please let me know how I can help.

 

[Fede Marsell]

I'd like to add that PLESK has crossed a red line.

For some time now, some providers (including some very large ones in Europe) have stopped working with PLESK.

The official version is due to the pricing policy (abusive in my opinion), but I believe that behind these decisions are the latest modifications to PLESK, including options (always enabled by default) that attempt to sell services/products through the panel, profiting in questionable ways from clients who are not PLESK customers (they are customers of the company that uses PLESK).

But that's another topic.

 

[trialotto]

I'd like to add that PLESK has crossed a red line.

For some time now, some providers (including some very large ones in Europe) have stopped working with PLESK.

The official version is due to the pricing policy (abusive in my opinion), but I believe that behind these decisions are the latest modifications to PLESK, including options (always enabled by default) that attempt to sell services/products through the panel, profiting in questionable ways from clients who are not PLESK customers (they are customers of the company that uses PLESK).

But that's another topic.

@Fede Marsell

Red lines are difficult to determine, in the sense that it is difficult to say what it is : a subjective opinion or a red line that cannot be crossed in a legal sense.

The discussion about "hosting providers" stopping with using or offering Plesk is a bit off-topic.

Let's focus on what matters.

Kind regards....