Skip to content

Hostasaurus

My feedback

8 results found

  1. 341 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Hostasaurus commented  · 

    The size of a ddos that can be mitigated by a single server is rather small, especially if it's an application-layer attack (i.e. https web application).

    There are cheap and easy CDN's to mitigate these types of attacks, that will do a far better job of it.

  2. 558 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We have serious doubts this function can really increase server security:
    1) Plesk has built-in protection against brute-force on login – it will lock the login form. So no one can try multiple attempts
    2) Arbitrary login name adds very little guess-complexity to a proper password. If you have concerns for your login brute-forced – add another 5-7 characters into your password and feel safe.

    As changed login name is still very likely to be some sort of vocabulary word or derived from your other account name – this function would only give a false sense of better security. Your security strength is in complex password, not in a complex login name. If you have one good password, you don’t need to treat login as your “second password” – one good password is enough.

    As for concerns that default password requirement is set in “weak”, that fail2ban module is not…

    An error occurred while saving the comment
    Hostasaurus commented  · 

    Interesting that PCI requires changing default usernames, yet Plesk considers it not worthy of spending time on. Of course they also have been requested to offer a better two factor option than totp, and haven't done that either in nine years.

  3. 221 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  4. 26 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Hostasaurus commented  · 

    Five years later, instead of caring about security, they provide a way to gain root access through the UI that you have to explicitly disable instead of enable... and still no syslog of such activity.

    An error occurred while saving the comment
    Hostasaurus commented  · 

    I'd like to see this as well. Anything that goes into Action Log should also be able to be sent to syslog, which would allow it to immediately leave the server to one or more additional destinations to ensure the logs are preserved through a server compromise or malicious Plesk 'Additional Administrator' behavior.

    I suspect this is the kind of feature that larger customers of Plesk want. I also suspect it will never get the votes necessary for Plesk to care, because this stupid way of requesting features means nothing that appeals to people managing a very large number of servers ever receives enough votes, as all the popular requests are things that appeal to people running one copy of Plesk. They're clearly headed in a direction of not placing any value on enterprise customers, because few, if any, features of the past few years seem to be of interest to that type of customer.

    Hostasaurus supported this idea  · 
  5. 69 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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.

  6. 105 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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  · 
  7. 9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    open discussion  ·  IgorG responded

    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.

    IG

    An 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.

  8. 35 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An 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  · 

Feedback and Knowledge Base