Webspace at ALL-INKL Hacked - Virus Found in the Account - Tips
Photo © ALL-INKL.COM
Has the ALL-INKL virus scanner reported malware findings? ALL-INKL is one of the best web hosts in Germany, with exemplary malware handling. Learn here how to improve your account security after your webspace has been hacked - or proactively before that happens.
Webspace Hacked - The Virus Scanner Notification
As soon as the ALL-INKL virus scanner detects a virus or malicious files in the account, you will receive this email:
Sehr geehrte Damen und Herren, Sie erhalten diese automatische E-Mail von unserem Virenüberwachungssystem. Ihre E-Mail-Adresse wurde von Ihnen als Kontakt für den betreffenden Account hinterlegt. * VIRENFUND * Bei einem routinemäßigen Virenscan wurden in Ihrem Account wXXXXXXX (example.org) Dateien mit Schadcode gefunden. Um die Besucher Ihrer Webseite zu schützen, haben wir diese Dateien nach Möglichkeit umbenannt und gesperrt. * URSACHEN * Häufige Ursachen für Virenbefall im FTP-Account sind Sicherheitslücken in oft nicht aktualisierten Scripten wie CMS, Shop, Forum, Gästebücher usw., oder ein Befall mit Schadcode auf dem PC, mit dem die Webseite bearbeitet wurde. * MASSNAHMEN * Loggen Sie sich bitte umgehend in die technische Verwaltung Ihres Accounts ein und folgen Sie den Anweisungen im Menüpunkt 'Wartungscenter'. * ACHTUNG * Nicht alle Dateien konnten automatisch gesperrt werden. Bitte desinfizieren Sie diese manuell!
Unlike many other web hosts that lock the entire webspace after a successful hacker attack, ALL-INKL only blocks the files containing malicious code. This makes securing and restoring the hacked account significantly easier.
Based on the creation or modification dates of the virus scanner findings, a backup date is even suggested.
Important: Just because the ALL-INKL virus scan did not previously detect any malicious files does not necessarily mean that the suggested backup is clean. This should also be checked carefully.
Webspace Security - Recommended Measures at ALL-INKL
In addition to the usual measures after a hacker attack, meaning backup restoration, a complete rebuild, or cleanup of the website(s), the following points should be observed at ALL-INKL.
1. Enable access logs with a long retention period
In order to analyze a hack and trace what happened on the webspace, it is important that access logs are available. For a clear evaluation of access logs, our Logfile Analysis Tool is a useful option. In the KAS under Settings -> Logs & Statistics make sure that logs are being generated.
The screenshot shows the recommended settings.

2. Disable external database access
Especially in recent months, many hacks have aimed to extract database credentials from the CMS configuration files. For example, in the past, some plugin security vulnerabilities on WordPress sites made it possible to read the wp-config.php file.
If database access from everywhere is allowed (formerly the default setting at ALL-INKL), this is a critical vulnerability.
Attackers can directly access the database from outside and manipulate its contents at will - create users, inject malicious scripts, or add spam links.
Therefore, make absolutely sure that only local access to the database is possible. In addition, after the webspace has been hacked, always all database passwords should be changed.

3. Separate individual websites into subaccounts
The last, but by far the most important security tip, is to never run multiple websites in the same account. If everything runs under the same system user, a single security vulnerability in one installation is enough for all websites in the same account to be hacked.
At ALL-INKL, there is therefore the option to create a separate subaccount for each individual domain.
To apply this isolation afterwards, a useful account transfer tool is available in the KAS. The isolation can be carried out with the following steps:
- Accounts -> + Create New Account.
- Select 'without host' in the top tab.
- Enter the domain name in the account comment for assignment purposes.
- Assign the resources accordingly.
- From the account overview, log in to the newly created subaccount.
- Im Menü des neuen Unteraccounts Tools -> Account-Übertragung -> FTP-Daten öffnen.
- Enter the FTP access data of the main account.
- Enter the source path of the domain to be transferred (for simplicity, use the same path for the target path).
- On the next page, enter a confirmation email address to be notified when the copying process has been completed successfully.
- Anschließend im Hauptaccount Tools -> Hosts verschieben öffnen.
- In the main account, select the domain that is to be moved to the new subaccount.
-> This now connects the domain to the subaccount.
- In the main account, select the domain that is to be moved to the new subaccount.
- If necessary, adjust the absolute server path in configuration files.
- This may be necessary, for example, for common caching plugins or, if you use Joomla, $log_path and $tmp_path would need to be adjusted in configuration.php.
(At ALL-INKL, the server path starts with /www/htdocs/wXXXXXX/...)
- This may be necessary, for example, for common caching plugins or, if you use Joomla, $log_path and $tmp_path would need to be adjusted in configuration.php.
- Delete the directory that was successfully moved to the subaccount from the main account.
The databases can all remain in the main account for a clear overall overview. Moving them to the subaccount afterwards is not necessary - and would not provide any security advantage either.
All email addresses assigned to the respective domains are moved to the subaccount fully automatically by 'Move Hosts' and can from then on only be managed there. No further adjustments are necessary. In this context, you should simply ensure that sufficient quota is assigned in the subaccount resource allocation.
These best practices create the foundation for secure webspace. If something should go wrong from a security perspective and the virus scanner is triggered, the impact will be kept to a minimum. If multiple websites are operated within the same hosting package, separating them into subaccounts helps prevent the entire webspace from being hacked. The spread of a virus is effectively prevented by separate system users.
If you have any questions or suggestions, feel free to use the comment function.
- Details
- Last Updated: 16 June 2020
