This article addresses security measures in shared hosting environments. It emphasizes that security is an ongoing process that requires thorough goal assessment. To minimize vulnerabilities, one should deviate from defaults, such as changing administrator access and database prefixes. It is important to always use current software versions and remove unused programs. FastCGI is recommended for web servers, while FTP and mail servers should only use encrypted connections. Passwords should be changed regularly and be complex. Legal foundations are also discussed.
The following article covers the key points regarding security in a shared hosting environment and provides measures and advice to be taken.
Security as an ongoing process requires a prior assessment of your own goals. This means the more secure the environment is to be designed, the more complex the implementation and maintenance become.
A publicly accessible presence inherently offers a number of possible vulnerabilities, as it is meant to be accessible by everyone. It must therefore be ensured that the various access methods are well protected against external influences.
The following important point applies to all components:
- Deviate from defaults
Every web application operates with a corresponding administrator access, which is by default accessible with a predefined username. Change this at the latest when switching to production operation.
Many applications also use predefined database table prefixes and directory paths. Change these during installation as well to render automated attacks (exploit scans) ineffective.
Web Application
Web Server
FTP Server
Mail Server
Database Server
Passwords
Legal Foundations (Excerpt)
Web Application
- Ensure that you always use the current version of the software
- Install only modules/components that you really need. Every additional module increases the attack surface. It is important that these modules are regularly updated. Components that are no longer maintained are very insecure.
- Programs/applications that are no longer active and maintained must not be publicly accessible. That is, if, for example, a CMS is installed for testing purposes in a subdirectory and then no longer used, this can also affect the active presence – similarly with replaced programs/web applications (example: the active WordPress installation is in the /wp subdirectory and the old one is renamed to /wp_old). The old environment and thus also the new one remain vulnerable in this form.
Web Server
- Use FastCGI for PHP execution to be able to run PHP under the FTP username
- Change the permissions of critical configuration files (password files) without exception to 600.
- Prevent web access to security-relevant scripts and Git repositories via .htaccess (Deny from all)
- Prevent unprivileged web access to non-public areas with a password protection.
Mail Server
- Connect exclusively encrypted to both the incoming and outgoing mail servers.
SMTP over SSL = Port 465 or Port 587 (Submission)
POP3 over SSL = Port 995
IMAP over SSL = Port 993
Database Server
- Avoid standard database names like typo3, wordpress, joomla, etc.
- If not needed, restrict external connections to the database by allowing only local connections.
Passwords
Also make sure to regularly change the passwords for the Plesk panel, backend access, FTP access, email address, and database user, either by generating them with a password generator or by following the scheme below:
The generated password …
- fully utilizes the possibility of at least 16 (preferably 32 or more) characters
- contains at least 2 letters using both uppercase and lowercase letters
- contains at least 2 digits or special characters
- contains no (recognizable) pattern, i.e., appears as a randomly generated string
- is not a word from a known language
- contains no names, especially none related to the domain/user account
- is known only to the owner of the account
- is changed at appropriate intervals.