Damien
My feedback
8 results found
-
5 votes
An error occurred while saving the comment -
543 votes
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…
Damien
supported this idea
·
-
37 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.
—
IGDamien
supported this idea
·
-
98 votes
Hi everyone,
This seems to be important, so we’ll address it in one of the upcoming Plesk releases.
Please continue to vote so we can accurately assess the popularity of this request.
— AK
Damien
supported this idea
·
-
220 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.
— AY
Damien
supported this idea
·
-
30 votes
An error occurred while saving the comment Damien
commented
ARC is already implemented / supported at major mail providers: http://arc-spec.org/?page_id=79 (e.g. Gmail, Office 365) and Mailman.
Postfix compatible implementations exist via (at least) OpenARC (Trusted Domain Project) and Rspamd
Damien
supported this idea
·
-
41 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.
—
IGDamien
supported this idea
·
-
69 votesDamien
supported this idea
·
An error occurred while saving the comment Damien
commented
These are remote services, so they can only scan webpage output. They are defacement monitors.
The feature here is filesystem based, so it would identify new unknown files, or backend changes to files that may not cause any change to generated HTML)
Logging is essential - especially because:
* git actions are executed using a different shell (/bin/sh) vs. whatever is configured for the system user (so environment or other nuances may cause unexpected errors)
* errors are silent and fatal (the commands appear to executed as "command1 && command2", so command2 will only be executed if command1 has a clean exit code)
* execution starts from the git deploy directory (not the system user home directory), so again this can be a source of user error when specifying the commands
* troubleshooting and debugging all of the above is awkward: you have to write your own log files (e.g. redirecting command output) which is not at all elegant or intuitive for a typical developer who just wants to get their stuff deployed and working!