Nginx include php conf

Best practice secure NGINX configuration for WordPress

We have by far the largest RPM repository with NGINX module packages and VMODs for Varnish. If you want to install NGINX, Varnish, and lots of useful performance/security software with smooth yum upgrades for production use, this is the repository for you.
Active subscription is required.

WordPress Security

WordPress is the most popular CMS for running a website. As such, it is the target for all kinds of malicious bots.

The most effective way of reducing security risks associated with WordPress is the proper server configuration.

Secure WordPress NGINX configuration must be built on the assumption that any unknown script is malicious.
User-uploaded scripts should not be allowed for execution as their execution is #1 of a defaced website.

Thus our configuration example is built upon a whitelist approach.

Pre-requisites

WordPress settings

Pretty Permalinks in WordPress must be enabled.

NGINX modules

There are some NGINX modules required for achieving higher security.

For CentOS/RHEL servers without control panels

sudo yum -y install https://extras.getpagespeed.com/release-latest.rpm sudo yum -y install nginx-module-length-hiding nginx-module-immutable nginx-module-security-headers 

Enable the modules in /etc/nginx/nginx.conf by placing at the top of the file:

load_module modules/ngx_http_length_hiding_filter_module.so; load_module modules/ngx_http_immutable_module.so; load_module modules/ngx_http_security_headers_module.so; 

Alternatively, these modules can be installed from source, which is, however, only advisable for testing, on a development system.

Our secure NGINX configuration relies on a typical structure and file naming conventions.
As we go ahead with creating and modifying, we’ll review their purpose.

/etc/nginx/includes/php-example.com.conf

Create directory /etc/nginx/includes if it doesn’t exist. The file php-example.com.conf serves as a connecting point between NGINX and PHP-FPM.
In there, we specify the path to the UNIX socket file, which should match your PHP-FPM pool configuration.

 fastcgi_pass unix:/var/run/php-fpm/example.com.sock; include fastcgi_params; 

/etc/nginx/sites-available/example.com.conf

NGINX configuration is typically organized in a way that website-specific is stored in its own configuration file under directory /etc/nginx/sites-available .
Let’s create a secure configuration for the website example.com .
We’re not touching upon TLS configuration, as we want to concentrate on WordPress security requirements:

server < server_name example.com; root /srv/www/example.com/public; security_headers on; # do not load WordPress when redirecting /index.php to / location = /index.php < return 301 /; ># do not load WordPress when redirecting /wp-admin to to /wp-admin/ location = /wp-admin < return 301 /wp-admin/; >location / < # any URI without extension is routed through PHP-FPM (WordPress controller) location ~ ^[^.]*$ < length_hiding on; fastcgi_param SCRIPT_FILENAME $document_root/index.php; include includes/php-example.com.conf; ># allow only a handful of PHP files in root directory to be interpreted # wp-cron.php ommited on purpose as it should *not* be web accessible, see proper setup # https://www.getpagespeed.com/web-apps/wordpress/wordpress-cron-optimization location ~ ^/wp-(?:comments-post|links-opml|login|mail|signup|trackback)\.php$ < length_hiding on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include includes/php-example.com.conf; >location ^~ /wp-json/ < fastcgi_param SCRIPT_FILENAME $document_root/index.php; include includes/php-example.com.conf; ># other PHP files "do not exist" location ~ \.php$ < return 404; >> location = /xmlrpc.php < # allows JetPack servers only allow 192.0.0.0/16; deny all; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include includes/php-example.com.conf; >location /wp-admin/ < index index.html index.php; location = /wp-admin/admin-ajax.php < # this location often spits json, which will be broken if length hiding is used # so no length hiding here fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include includes/php-example.com.conf; ># numerous files under wp-admin are allowed to be interpreted # no fancy filenames allowed (lowercase with hyphens are OK) # only /wp-admin/foo.php or /wp-admin//foo.php allowed location ~ ^/wp-admin/(?:network/|user/)?[\w-]+\.php$ < length_hiding on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include includes/php-example.com.conf; >> location /wp-content/ < # contents under wp-content are typically highly cacheable immutable on; # hide and do not interpret internal plugin or user uploaded scripts location ~ \.php$ < return 404; >> # hide any hidden files location ~ /\. < deny all; ># hide any backup or SQL dump files location ~ ^.+\.(sql|bak|php~|php#|php.save|php.swp|php.swo)$ < return 404; >> 

After editing your configuration, don’ forget to reload NGINX, e.g.:

Verification

• Access a known PHP script that is not meant for web browser access, e.g. example.com/wp-blog-header.php. On successful configuration, you will get a 404 (Not Found) error.
• Pretty permalink URLs are fully functional
• Open HTML source of any page, and locate random-length HTML comment . It should be present.

How it works

Let’s review all the pieces of our secure WordPress configuration.

The security_headers on; enable sending security headers via ngx_security_headers module. This one-liner configuration allows sending them “the right away”, as in while required only and according to their specification

Next up, we created a couple of locations:

 # do not load WordPress when redirecting /index.php to / location = /index.php < return 301 /; ># do not load WordPress when redirecting /wp-admin to to /wp-admin/ location = /wp-admin < return 301 /wp-admin/; >

The comments are self-explanatory. When WordPress sees URIs /index.php , it redirects to the base URL of your website.
It helps with SEO content duplication reduction.
Having those redirects in NGINX allows reducing CPU use by avoiding a load of heavy WordPress stack for the simple task of redirecting.

Next up, you’ll note the use of nested locations wherever possible. This is as per the NGINX author’s recommendation.
Nested locations allow isolating the use of regular expressions and an NGINX configuration that can scale well, in terms of maintenance.

Our key location which handles SEO-friendly URLs builds on a simple assumption that they do not include dots, which typically indicates an actual file with an extension.
Thus we default to serving URIs without dots through the WordPress’ front-controller file, /index.php :

The length_hiding on; enables insertion of randomly generated HTML comment:

This is a measure that eliminates the possibility of a BREACH attack.

Next, we specify which .php files are allowed for execution, other than index.php :

 # allow only a handful of PHP files in root directory to be interpreted # wp-cron.php ommited on purpose, see proper setup location ~ ^/wp-(?:links-opml|login|mail|signup|trackback)\.php$ < length_hiding on; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include includes/php-example.com.conf; ># other PHP files "do not exist" location ~ \.php$

The secure configuration only allows a few well-known PHP files to be executed.
Unlisted PHP are silently discarded with HTTP status code 404 , thus preserving information disclosure wherever possible.

The /wp-content/ directory is the primary source of user-uploaded images, plugins, and their scripts.

A well-coded plugin never needs to be executed by its direct URI under /wp-content//foo.php .
If you find that such a plugin is present in your WordPress instance, it is a candidate for removal, and in very exceptional cases, whitelisting in NGINX configuration.

A perfect WordPress website allows no execution of PHP scripts under /wp-content/ directory.

Once you know you have no bad players (plugins) in your /wp-content , you can apply the honeypot approach to it.
Add all the necessary configuration from the linked article, then update the location ~ \.php$ < in a way that instead of returning 404 , it will include the honeypot configuration.
This will make any bad bots trying to access plugins’s PHP files under wp-content immediately blocked:

 # other PHP files cause automatic ban: location ~ \.php$ < include includes/honeypot.conf; >

The publicly accessible files in wp-content are highly cacheable (images). The immutable on; enables sending caching headers with Far Future Expiration, as well as the immutable attribute.
This ensures the highest browser cachability for your WordPress while reducing network usage on both the server and client-side.

Источник

Nginx include php conf

• Haskell vs. PureScript: The difference is complexity Haskell and PureScript each provide their own unique development advantages, so how should developers choose between these two .
• A quick intro to the MACH architecture strategy While not particularly prescriptive, alignment with a MACH architecture strategy can help software teams ensure application .
• How to maintain polyglot persistence for microservices Managing microservice data may be difficult without polyglot persistence in place. Examine how the strategy works, its challenges.

• GitHub Copilot Chat aims to replace Googling for devs GitHub’s public beta of Copilot Chat rolls out GPT-4 integration that embeds a chat assistant into Visual Studio, but concerns .
• The basics of implementing an API testing framework With an increasing need for API testing, having an efficient test strategy is a big concern for testers. How can teams evaluate .
• The potential of ChatGPT for software testing ChatGPT can help software testers write tests and plan coverage. How can teams anticipate both AI’s future testing capabilities .

• 5 Google Cloud cost optimization best practices Cost is always a top priority for enterprises. For those considering Google Cloud, or current users, discover these optimization .
• How to create and manage Amazon EBS snapshots via AWS CLI EBS snapshots are an essential part of any data backup and recovery strategy in EC2-based deployments. Become familiar with how .
• Prices for cloud infrastructure soar 30% Tough macroeconomic conditions as well as high average selling prices for cloud computing and storage servers have forced .

• API keys: Weaknesses and security best practices API keys are not a replacement for API security. They only offer a first step in authentication — and they require additional .
• Risk & Repeat: Are data extortion attacks ransomware? Ransomware gangs are focusing more on data theft and extortion while skipping the encryption of networks. But should these .
• Cyber insurers adapting to data-centric ransomware threats Cyber insurance carriers and infosec vendors weigh in on how the shift in ransomware tactics is affecting policies and coverage, .

• AWS Control Tower aims to simplify multi-account management Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates .
• Break down the Amazon EKS pricing model There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service .
• Compare EKS vs. self-managed Kubernetes on AWS AWS users face a choice when deploying Kubernetes: run it themselves on EC2 or let Amazon do the heavy lifting with EKS. See .

Источник