We also briefly describe the means Drupal provides to protect itself as well as possible against a website hack.
Contents:
1. update the Drupal core and modules used
Both the Drupal core and all extensions should be kept up to date. Hackers target older versions because the security precautions and standards are not up to date. This is why there are regular updates that are easy to recognize and install.
You should also make it a habit to create regular backups. If, despite all security precautions, one of your sites is attacked, you can restore your data from the backup.
2. strong passwords, smart usernames
A large proportion of attacks on a website are due to weak login data. This is a fact.
Take the time to do this. A username should not be 'admin' or similar, because hackers attack common and simple usernames first.
Avoid using passwords that are too simple and easy to remember, as easier password structures are cracked more quickly by attack programs. For this purpose, there are programs that create strong passwords according to common security criteria. However, there are also plenty of instructions online on what a secure password should look like.
We have also already published an article on how to create secure passwords that are easy to remember despite their complexity.
3. security modules
The Drupal community recognizes the importance of data security and has created security modules that you should use! Here are a few examples.
1. login security:
To confuse attackers, this module can be used to disable standard error messages when logging in. This normally indicates whether a user name exists. This error message is deactivated with the Login Security module.
You can find all further information about the module at https://www.drupal.org/project/login_security
2. password policy:
One way for attackers to gain access to your site is to create a new password for a random user. This module helps to define certain requirements for the creation of a password. For example:
An uppercase condition with the value 2
and a digit condition with the value 4This means that a new password must contain at least 2 capital letters and 4 digits. Otherwise the password will not be created.
You can find more information at https://www.drupal.org/project/password_policy
3. security review
Common security risks are automatically checked here and evaluated using a color system. This simplifies the search for errors and reduces the time required.
This module comes with several features, including the determination of file authorizations (see point 6), failed login attempts or the visibility of error messages.
You can find more information about this module at https://www.drupal.org/project/security_review
4. two-factor authentication (TFA)
This module adds a second step to the usual authentication via user name and password. For example, a confirmation code is sent to a verified end device. You can only view this code and continue with the authentication process if you have this end device.
You can find more information on this at https://www.drupal.org/project/tfa
Although some of these modules are still in the development phase, it is advisable to follow the development or even install one or more on a trial basis.
4. block bad bots
Another option is to manually block certain user agents. There are numerous modules for Drupal 7 for this purpose, one of which is Bad Behavior.
There will certainly be modules of this type for Drupal 8 in the future. However, it should be noted here that these act on the S-layer , i.e. after the request has already passed through the server and the .htaccess file.
Accordingly, it is more effective to set up bot blockades as early as possible. At http://www.botreports.com/ there is a list of known bots and their user agent string. This could already be blocked in the .htaccess file as follows:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(agent1|Wget|Catall Spider).*$ [NC]
RewriteRule .* - [F,L]Where agent1, Wget and Catall Spider each represent a bot.
However, it is even better to incorporate this filtering even earlier. This can be done on a proxy server, for example, which means that significantly fewer suspicious requests reach the actual web server.
5. use secure connections during deployment
If your hoster supports it, you should always use SFTP encryption. A secure shell (ssh) connection is even better.
To run the FTP client via SFTP, it is sufficient to enter port 22.
Attention: Some FTP clients store passwords on your computer, sometimes even unencrypted.
6. file permissions
Each file has its own permissions for reading, executing and writing. Too loose permissions can open doors for intruders, while too strict can cause a Drupal site to not run, because various files need to be accessible to the Drupal core or modules.
A good documentation on permission settings can be found here: https://www.drupal.org/node/244924
7. block access
For important files such as authorize.php, upgrade.php, cron.php or install.php, access can generally be blocked in the .htaccess. This then looks like this:
Order deny, allow
deny from all
Allow from 127.0.0.1
This means that only you are allowed to view and execute these files.
8. database table prefix
Another way to increase the security of your site is to define table prefixes. The table 'node' would then be called 'prefix_node' and access for intruders is immediately made more difficult. This is because unconventional table names are difficult to guess. Such prefixes should be added when the page is created or afterwards using a suitable database tool.
9 SSL certificate
If your site does not run over HTTPS, your user name and password are sent as text over the Internet and can be intercepted by anyone.
You should therefore always use an SSL certificate. This also has SEO advantages and gives your visitors a sense of security.
10.custom code
It is well known that many paths lead to the same goal when programming. However, coding standards must be observed with regard to security:
1. use the Drupal API!
For example, you can read the current user name string using the global PHP variable $_GET['user']. This is not masked ('escaped') and therefore goes as plain text from browser to server and vice versa. This simplifies cross-site scripting (XSS).
Via Drupal 8 API this would work as follows:
$current_user = Drupal::currentUser();
$user_name = $$current_user->getDisplayName();The user object is requested first, which provides all possible information with additional methods such as getDisplayName(). The important difference here is that all strings are masked and therefore not sent as plain text.
This method of text masking has been a clear standard since Drupal 8.
Twig templates, for example, are used for all output. These generally mask everything inside the curly brackets "{{ }}".
Text generated in PHP can also be escaped via API:
Html::escape($text)
2. database abstraction layer
Direct database queries such as db_query('SELECT foo FROM {table} t WHERE t.name = $user_name); should be avoided. Sensitive data is transmitted unsecured here.
The database abstraction layer replaces these with simple placeholders that do not point directly to the data:
db_query("SELECT foo FROM {table} t WHERE t.name = :name", [':name' => $user_name]);In principle, it is also better to use the Drupal API here. This is done by requesting a "database connection object" and applying the query to it:
$connection = Database::getConnection();
$connection->select({table}, 't')
->fields('gs', ['foo'])
->condition('name', $user, '=')Conclusion
As briefly outlined above, most successful attacks on websites occur due to negligent handling of personal data. This may be because website operators do not see themselves as the target of attacks, or because they consider the cost of security precautions to be higher than the actual risk of an attack itself.
Well, that's wrong.
There are numerous attack methods and mechanisms. A "bot" does not decide who it attacks. So it can hit either side.
We hope this brief explanation of the procedures for increasing the security of your site will help you in future decisions about the effort you wish to put into this and wish you every success in securing your site.
If you have any questions about the security of your Drupal website, please do not hesitate to call us: 0711 - 633 779 60
