Hostasaurus
My feedback
5 results found
-
235 votes
Thank you for your input. We will explore the possibility of implementing YubiKey in upcoming releases.
An error occurred while saving the comment An error occurred while saving the comment Hostasaurus
commented
Coming up on NINE YEARS later and we're still stuck with only mediocre totp-based security.
Hostasaurus
supported this idea
·
-
70 votes
An error occurred while saving the comment Hostasaurus
commented
This can be easily accomplished with OSSEC, and in fact, you would ideally implement it with something like ossec outside of Plesk, because you don't want an unauthorized Plesk access resulting in the monitoring being disabled without your knowledge. You could even run it from a different server to ensure the agent hasn't been tampered with.
-
112 votes
Thank you for your input. We will consider the possibility of implementing this feature in upcoming releases.
— ES
An error occurred while saving the comment Hostasaurus
commented
This would be such an incredibly useful feature. Left over temporary third party developer accounts are a constant source of website compromise. Plesk won't even show you the date the accounts were created.
Hostasaurus
supported this idea
·
-
9 votes
Thank you for your input. We will consider this functionality in upcoming releases if it is popular. Everyone, please continue voting for this feature if you consider it important.
—
IGAn error occurred while saving the comment Hostasaurus
commented
This request should extend to Event Manager events as well, and the log should reflect both what was added and what was removed. If you define an 'Additional Administrator' with the intent on not giving them root access to the server, well now they've just gained the equivalent of root access with no logging of any activities they perform. They could add an event handler called on add physical hosting, whatever command they feel like, and then just add/remove a site, to have that command run as root. Or, they can add/remove a root cron job to execute whatever command they want, with no log of what the command was. This info should really be logged to syslog as well as action log, because once someone has gained the ability to execute commands as root, having those logs go remote in real time is the only thing keeping the log history safe.
-
40 votes
Thank you for your input! We will consider this functionality in upcoming releases if it will be popular.
Everyone, please continue voting for this feature if you consider it important.
—
IGAn error occurred while saving the comment Hostasaurus
commented
This really needs to be built for both the admin side and 'customer' / 'reseller' sides. Hosts deploying Plesk in a re-sold environment, where they provision it and hand it over to a customer, may need to retain access to it if it's being sold as a managed solution, and tying it into an SSO system ensures timely and secure access, not the current useless single password for the 'admin' user. On the customer side, many there also expect a higher level of security than a user/pass stored internal to Plesk; they want to tie it into their existing SSO system to gain access to policy enforcement, hardware token 2fa, etc.
Hostasaurus
supported this idea
·
Not only coming up on almost ten years, the current one and only 2fa option doesn't even have logging of when it is or isn't configured. We've had customers find that it has become unset, unbeknownst to them. Inquiries to Plesk support reveal the extension does no logging of any type about when it's configured, unconfigured, etc. so there's simply no way to ever have confidence it's even working.
And now they're trying to get into ecommerce?! LOL