Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to analyze Drupal configuration. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

Drupal configuration

Drupal is an open source PHP content management system with a rather complex architecture. It also has a powerful security model. Thanks to the contribution and maintenance of developers in the community, there is a lot of detailed documentation and ways to enhance the security configuration of Drupal sites.

Keep in mind that Drupal is a necessary part of running the site. In order to protect the whole system from hackers, we need to deal with the whole system. It includes some common server settings, Web server configuration, PHP and database. In addition, any other services on the server need to be configured correctly.

It provides some tips and key points to help servers and webmasters audit the security of the entire system. We should understand that it is impossible to build an absolutely secure system, but if you adhere to some principles, it will help your system security.

Safety principle

Let's start with common safety rules. Most of them apply not only to Drupal development and support the security of the Drupal site running infrastructure, but also to many other situations:

Use a solution developed by a community with a large user base. It maintains open source libraries, popular Linux distributions, and so on. Always check the integrity of the downloaded code.

Follow the principle of minimization and try not to use any other services. If you really need it, please install the new software and uninstall all unwanted services.

Avoid writing custom code. Before you begin, please carefully consider whether this situation can be avoided. The real situation related to Drupal development is to search for off-the-shelf solutions on drupal.org before writing custom modules.

Access is denied by default. The relevant access should be granted only if necessary.

Add a role with the required permissions. Each role must have a detailed record. In this way, it should be easy to support and extend the entire permissions framework.

Do not use root permissions. On Linux-based operating systems, use root access only when needed, and do so through sudo. In other words, you should not log in and run as root.

Carry out regular security inspection and maintenance of the system. You should carefully analyze all suspicious situations and analyze them.

Backup! You must always be able to restore the system to any previous state. In addition, you need to make sure that the system makes valid and available backups.

Do not expose the server to the public network until the server is properly maintained.

These principles can be applied to any system and service, no matter what software and hardware it uses. Let's further discuss more specific key points.

Important security maintenance objects:

In addition to running the Drupal of the Web site, you also need to configure the PHP,Web server and database. You may also need to install some service plug-ins to extend the search function, use caching, etc.

As you can see, there are many things that need to be properly configured and maintained on a regular basis. Based on the above, we can distinguish to some extent the following services that need to ensure security:

Server (common configuration)

Web server

PHP

Database

Drupal

Server (common settings)

The security of any service available on the Internet begins with the basic configuration of the server. For Linux-based servers, it can be configured using the following methods:

Change the configuration of remote login

Use iptables to set up a firewall

Change the configuration of remote login

By changing the configuration of logging in to the server. The main goal is to distinguish this process from the general default process.

For example, any Linux system has a superuser named root. Attackers can explode the default password of root through ssh, etc. However, if the server administrator closes the root login, such attempts will fail. We can create a new user instead of the root user and grant him the necessary permissions.

Most of the changes to this are related to the ssh setting. They are usually located in the / etc/ssh/ sshd_config file. Related configuration:

Port 2345Protocol 2PermitRootLogin noPasswordAuthentication noUseDNS noAllowUsers user

It allows you to connect to the server using a valid user name via ssh using port 2345 (non-default, default 22). It also disables root login and password authentication.

Disabling password authentication is an important step to improve the security of the entire system. Password-less authentication is more secure. To log in to the server, you need to generate the ssh key on the local computer and copy the public key to the server. It's more secure.

Use iptables to set up a firewall

Iptables is the default firewall for Linux systems. It can be used to manage connections to designated ports. If we want to keep the website on the server, we need to open the http and / or https ports in addition to the ssh port.

By default, no rules are established on the operating system. Typing the sudo iptables-L command (Ubuntu) returns the following:

Chain INPUT (policy ACCEPT) target prot opt source destinationChain FORWARD (policy ACCEPT) target prot opt source destinationChain OUTPUT (policy ACCEPT) target prot opt source destination

This means that the server accepts anything from anyone on any port (policy defaults to ACCEPT). We can only open the necessary ports and close other unnecessary ports.

Sudo iptables-An INPUT-p tcp-- dport 2345-j ACCEPT sudo iptables-An INPUT-p tcp-- dport 80-j ACCEPT sudo iptables-An INPUT-p tcp-- dport 443-j ACCEPT

These commands accept connections to ports 2345, 80 and 443. However, we still have no other restrictions on other ports. Therefore, you need to add a rule at the end to reject all unwanted packets.

Sudo iptables-An INPUT-j DROP

That's all. It should be kept in mind that the above configuration may make you use different systems and vary greatly. The main objective here is only the interpretation of the basic principles. Be careful when changing the network configuration! Sometimes, it rejects any connection when you are not careful. For example, you accidentally drop your ssh port, 2333.

Web server

Some general principles for setting up a Web server. Using these rules is very important for your website to run. Through a vulnerability in the server, an attacker can execute files arbitrarily, upload malicious scripts, and run them with some kind of coquettish operation.

Ability to access running website files

The main principle is that website files should be run by non-root users and should not be written by Web servers (knock on the blackboard and highlight! ). In some cases, the Drupal directory is available to Web server users. For more information about protecting file permissions and ownership, see the "related links" at the end of this article.

Restrict access to certain functions of the Web server

Sometimes, it may be useful to restrict access to some functions of a Web site on a Web server. For example, if you have a demo site or a site that doesn't have a registration feature. You can restrict / user and / admin/ *. For Apache Web servers, this can be done using the mod_authz_host and mod_rewrite modules. Keep in mind that http authentication is not a secure method. Therefore, the method described is more applicable in specific situations.

Remove unused Web server plug-ins

All other services on the server have potential security risks. Therefore, you should follow the principle of minimization. If you don't need anything, just delete it.

The same applies to Web servers. Apache and Nginx Web servers have many additional plug-ins, so double-check the list of enabled extensions and remove all unused extensions.

Use HTTPS

The use of HTTPS protocol can make access to websites and private user data more secure. Nowadays, when some online stores do not use encryption on their payment transactions, this is absolutely wrong. Moreover, Google has set HTTPS as the ranking indicator. This means that sites that do not use the HTTPS protocol but can still run, some important information (credit cards, payment transactions, etc.) will have a negative impact on search rankings.

Ideally, if you encrypt all sites that interact with users. For example, login and registration. The user enters the password. Even if these passwords are not visible in all browsers (such as *), they are passed over the network in an unencrypted form. Therefore, attackers can easily intercept input data through man-in-the-middle, etc. Users usually use common passwords. This means that it may also affect your account on other sites.

HTTP certification

It should be clear under what circumstances HTTP authentication can be used. In most cases, you need it to protect the caching of the site and disable the crawler's index of the site. However, HTTP authentication is inherently insecure. It does not use any encryption algorithm. As a result, traffic between the browser and the website is not encrypted, and an attacker can access the website simply by copying the available HTTP headers and sending packets to the Web server.

In addition, it is strongly recommended that you keep the htpasswd file outside the document root. Set read-only permissions for this file (440).

PHP

PHP can contain vulnerabilities like other services on the server. This largely depends on the settings of PHP itself and the version of PHP currently in use. Of course, you always need to check for all available updates and keep PHP updates. However, in some cases, this can be very difficult or even impossible.

In general, all the work of optimizing PHP security on the server can be divided into three parts:

Update the PHP version regularly

Avoid using unsafe code, features, etc.

Optimize PHP settin

Update the PHP version regularly

This is easy to understand, but as I mentioned, in some cases, updates can be very difficult or even impossible. It's important when you have a lot of ancestral code in your application (it doesn't work in the new PHP version) and the current business doesn't allow you to take the time to update this code, because it's a time-consuming operation. In this case, you can try using some of the following suggestions.

Avoid using unsafe code

Writing security code is an important step in server security. You should spend some time reviewing all your custom code on a regular basis. In addition, there is no guarantee that third-party libraries will not contain any vulnerabilities. As I mentioned, even PHP itself has security issues (using unsafe functions, buffer overflows, etc.).

To solve these problems, there is a good thing called Suhosin, which can help you get rid of many security problems. Suhosin is designed to protect servers and users from known and unknown defects in the PHP and PHP cores. It consists of two parts. The first part is a patch for the PHP core, which provides some low-level protection against buffer overflows or formatted string vulnerabilities. The second part is the PHP extension, which implements some additional protection.

Suhosin is a very powerful tool to protect your server from many vulnerabilities. What hurts is that it doesn't apply to PHP7. In fact, Suhosin7 is under development, but it's not finished yet. The author does not recommend using Suhosin7 on production servers.

Optimize PHP settin

To optimize the PHP security configuration, the two easiest steps we can take is to disable unused modules and minimize the information available to users about the current PHP installation.

To view all compiled PHP modules, run the following command:

$php-m

It is recommended that you use only the necessary modules to improve security. Carefully check the entire list of modules that you don't need. Delete it.

Protect PHP from hackers and hide information about the system. Look at this configuration in the php.ini file:

Expose_php = Off

Make sure this parameter is configured. Otherwise, PHP will send the version number to the X-Powered-Byhttp header.

It also applies to the PHP error report on the website. They can provide some additional information about your server (Web server version, directory structure, etc.). Therefore, it is strongly recommended that you disable this feature on the production server.

Display_errors = Off log_errors = On error_log = / var/log/httpd/php_scripts_error.log

The above settings allow you to turn off the display of errors that occur on the site. In addition, they log errors to the specified log.

These are preliminary steps that can help you improve the security of using PHP on your server, even without any major changes to the system. Now let's talk about some specific configurations that you can add to the PHP configuration (php.ini file):

File_uploads = Off # disable file upload

But if you need the ability to upload files, it's best to limit the file size.

File_uploads = on upload_max_filesize = 1M2. Control system resources max_execution_time = 30 max_input_time = 30 memory_limit = 50m

You can specify the maximum execution time, the maximum amount of memory and the maximum big data read time for each script.

3. Turn off the PHP function allow_url_include = Off allow_url_fopen = Off that allows the script to contain other URL

File functions, such as file_get_contents, can be used if allow_url_fopen,PHP is enabled. With it, PHP can download files from a remote server.

4. Disable the hazardous feature disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Before disabling it, make sure that your site does not need any of these functions.

5. Restrict access to files open_basedir = "/ var/www" # directories allowed to access

The configuration of the open_basedir allows you to set up directories in PHP where files can be accessed using functions such as fopen,file_get_contents, etc. If the file is outside this directory, PHP will refuse to open it.

6. Temporary path session.save_path = "/ tmp"

Make sure that the temporary path is outside the root of the site. In addition, it cannot be read or written by other system users.

Database

What measures are taken to ensure database security depends largely on the infrastructure of the application. For example, Drupal's database abstraction layer allows you to choose between different databases. It can be MySQL,SQLite or PostgreSQL. In addition, Drupal supports popular MySQL branches, such as MariaDB and Percona. You should be aware that each system may have different security specifications.

It also depends on where you put the database. The simplest (in terms of security) is to install the database on the same server that owns the Web site. However, this approach may affect the performance of the entire system, so the server administrator may decide to install the database on another server (station library separation). This is especially true for high-load applications.

After completing the configuration of the server environment, the first thing you should do is to check that your architecture is strong enough and not vulnerable to DoS attacks. In fact, even at the peak of its workload, the server should have some resource reserves.

As I mentioned earlier, the details of the database security settings depend on the selected database. In this article, let's take a look at some general measures:

Database access

If the database is installed locally, you can disable access to it from the network. If your database is on a separate server, you should be able to set the IP address it will listen on. If LAN is shared between the Web server and the database server, only the LAN IP address is set (not accessible through Internet). This can be done by editing the my.conf file. The following is an example of a configuration when using the same server for a database and a Web site.

Bind-address=127.0.0.1

Database, users and permissions

Check the database, users, and permissions to find any security flaws. Do not provide users with more permissions than they actually need

PHPMyAdmin and similar tools, make sure you disable the graphics tool before using the database after you have finished using it. If you plan to continue using these tools, try to be as difficult as possible to access them. For example, you can restrict access to PHPMyAdmin via .htaccess and allow access from certain trusted IP addresses via whitelist. In addition, you can try using local tools such as MySQL Workbench instead of using the Web type.

Drupal

Drupal has a very complex architecture. In order to ensure the security of this complex system, it is best to divide all related work into small parts. During this operation, you will encounter configurations that need to be executed only once (setting file permissions, configuring settings.php files, etc.). There will be some tasks that require regular attention (updating Drupal and modules). Maybe others will ask you to work closely with the Drupal community.

Here are two critical moments you should remember:

Ensuring the security of Drupal is not an easy task, but it is very important to any website. So, you must try to do this. Security requires your careful attention.

File

Ensure that the Web server does not have write permission to the Drupal file. Only cache files, uploads, session and temporary directories require write permissions. The following command grants write access to the public file directory (Ubuntu or Debian):

$chown-R www-data:www-data sites / default / files

If your site allows files to be uploaded, please pay attention to the process of ensuring that these files are used. Only certain file types are allowed to upload. The relatively safe ones are text files and pictures. However, this does not change the things that users can upload malicious code, such as files with .jpg or .txt extensions. To avoid this problem, you can try to install the ClamAV module, which can scan uploaded files for viruses and other malicious code.

Settings.php

After the initial installation, make sure that the settings.php file does not have write permissions. This information can be found in the relevant bulletin (admin/reports/status in Drupal 8).

In settings.php, you can set an important option to prevent special attacks (https://www.drupal.org/node/1992030). This type of attack is called a HTTP POST Header attack. To protect the Drupal 7 website from them, please add basic URL parameters to your settings:

$base_url = 'http://www.example.com';

A similar configuration in Drupal 8 is:

$settings ['hash_salt'] = file_get_contents (' / home/example/salt.txt'); error log

Drupal provides a mechanism for monitoring the status of websites. Here I mean the latest log messages and reports. Try to check these logs periodically and fix the problems found. The report is very useful, especially after the website is installed. For example, if you forget to add trusted host settings or have write access to settings.php files, it can notify you.

Just look at the recent Log messages page to track some types of suspicious activity. For example, imagine what happens when you notice a surge in new user registrations.

Don't forget to disable the echo of PHP errors. Ordinary users should not see them. Although you may see these errors on the recent Log messages page, keep in mind that it does not catch all PHP errors. Therefore, sometimes please check your server log files.

Changes in the core and contribution modules of Drupal

This part is about the hacker attack of Drupal core and contribution module. In fact, it is a well-known fact that new developers may cut corners and put their code or some changes directly into the Drupal core or installed contribution modules. This can lead to unpredictable behavior of Drupal itself, as well as vulnerabilities, or malicious storage of backdoors.

To get rid of these problems, I recommend using Hacked! Module. This module scans the currently installed Drupal, contributed modules and topics, and compares everything to the corresponding version in drupal.org. If you have installed the Diff module, please use Hacked! Will tell you what has changed. This makes hacked! The module is a valuable analysis tool for any website.

Users and permissions

Drupal has an intuitive and customizable permission model. Permissions are the simplest element in such a system. A set of permissions can be grouped by role type. You can then assign this role type to a specific user. New permissions and role types may appear during updates to the Drupal core and contribution modules. You should regularly check (for example, after updates) the types of roles assigned to each user on your site and the permissions contained in these role types. Try to minimize the permissions contained in each role. Do not provide users with more permissions than they actually need.

A good configuration is to use a non-default user name (for example, not admin or root), because the hacker will try the default user name first. For greater security, the administrator account can even be disabled completely.

Another good thing is to check user activity on your site and lock out inactive accounts. The user expiration module provides the ability to define that a specific user account will be locked out. In addition, it can lock accounts that are inactive for a period of time.

After reading the above, do you have any further understanding of how to analyze the Drupal configuration? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.