Archive | Nginx

Diffie–Hellman (DHE) Ciphers On Nginx

By admin on November 6, 2020 in Nginx, Plesk

In some cases you may wish to allow Diffie–Hellman (DHE) ciphers in order to support older clients like IE on Windows 7. On Plesk we often use the “intermediate” level in the Mozilla cipher set as described here:

https://wiki.mozilla.org/Security/Server_Side_TLS

The “intermediate” level includes:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384

Of course the “ECDSA” or “Elliptic Curve Digital Signature Algorithm” ciphers will only be available if you are using ECC signed certificates.

Additionally the “DHE” ciphers will not be available by default if you are using Nginx releases greater then 1.11. With the 1.11 release Nginx moved the DHE key to an external setting instead of an internally generated key. The stock Nginx packages on Ubuntu and CentoOS do not setup a DHE key which results in the DHE ciphers not being available.

To address this problem, start by generating a key:

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

1 2	cd /etc/ssl/certs openssl dhparam -out dhparam.pem 4096

Next tell Nginx where to find the key:

echo "ssl_dhparam /etc/ssl/certs/dhparam.pem;" > /etc/nginx/conf.d/ssl_dh.conf

1	echo "ssl_dhparam /etc/ssl/certs/dhparam.pem;" > /etc/nginx/conf.d/ssl_dh.conf

Verify Nginx config and restart:

nginx -t
systemctl restart nginx

1 2	nginx -t systemctl restart nginx

Now the DHE ciphers will be offered to clients and Window 7 / IE clients will be able to connect to the sites hosted on the server.

Disable OPTIONS method in NGINX

By admin on January 2, 2019 in Nginx

To disable the OPTIONS method in Nginx add the following config:

if ($request_method ~ ^(OPTIONS)$ )
{
	return 403;
}

if ($request_method ~ ^(OPTIONS)$ )

{

return 403;

}

The result can be tested with curl:

curl -X OPTIONS https://domain.com

1	curl -X OPTIONS https://domain.com

Disable Basic Auth For Virtual Path On Plesk

By admin on February 16, 2018 in Apache, Nginx, Plesk

In a recent case we needed to allow request to a particular virtual URL path on a site that was password protected with HTTP Basic Auth. The site was hosted on a Linux server with Plesk, nginx and Apache. Typically this problem is solved by adding a “Satisfy Any” to the .htaccess in the directory that you want to remove authentication. But this does not work if the path is virtual instead of a physical directory path. Additionally we needed to allow access for a list of IP addresses. We tried an number of different solutions and ended up with the following:

Step 1 – The HTTP Basic Auth and IP access controls are configured in the .htaccess file like this:

# basic auth
AuthName "Authorized Only"
AuthType Basic
# password file is maintained from Plesk
AuthUserFile /var/www/vhosts/system/stage.acme.com/pd/d..httpdocs@donotremove
require valid-user

# set an environment variable if there is an AUTH_OVERRIDE header
SetEnvIf AUTH_OVERRIDE ^true AUTH_REQUEST

# set IP controls
order deny,allow
deny from all
allow from 1.1.1.1
allow from 2.2.2.2
# allow request if the environment variable is set
allow from env=AUTH_REQUEST

# require either Basic Auth or IP controls
Satisfy Any

# basic auth

AuthName "Authorized Only"

AuthType Basic

# password file is maintained from Plesk

AuthUserFile /var/www/vhosts/system/stage.acme.com/pd/d..httpdocs@donotremove

require valid-user

# set an environment variable if there is an AUTH_OVERRIDE header

SetEnvIf AUTH_OVERRIDE ^true AUTH_REQUEST

# set IP controls

order deny,allow

deny from all

allow from 1.1.1.1

allow from 2.2.2.2

# allow request if the environment variable is set

allow from env=AUTH_REQUEST

# require either Basic Auth or IP controls

Satisfy Any

Step 2 – In Plesk under:

Subscriptions -> stage.acme.com -> Apache & nginx settings -> Additional nginx directives

1	Subscriptions -> stage.acme.com -> Apache & nginx settings -> Additional nginx directives

Add the following block:

location ~ /excluded/path {
  proxy_set_header AUTH_OVERRIDE true;
  proxy_pass http://x.x.x.x:7080;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Accel-Internal /internal-nginx-static-location;
  access_log on;
}

location ~ /excluded/path {

proxy_set_header AUTH_OVERRIDE true;

proxy_pass http://x.x.x.x:7080;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Accel-Internal /internal-nginx-static-location;

access_log on;

}

where “/excluded/path” is the virtual URL to be allowed access and “x.x.x.x” is the IP address assigned to the site.

When a request comes is received, nginx looks for the path and adds the AUTH_OVERRIDE header. Then the request is passed to Apache which processes the .htaccess file. The AUTH_OVERRIDE header is converted to an “AUTH_REQUEST” environment variable and allow without authentication by the “allow from env=” rule.

There may be better ways to accomplish this solution but this is one that we successfully implemented.

Mixing Basic Auth And IP Access Controls

By admin on February 10, 2016 in Apache, Nginx

In some cases you might want to require HTTP Basic authentication to a site but allow specific IP addresses to skip the username/password. For Apache this can be configured with:

Order deny,allow
Deny from all
AuthType Basic
AuthUserFile .htpass
AuthName "Protected Area"
require valid-user
allow from x.x.x.x
allow from y.y.y.y
Satisfy Any

Order deny,allow

Deny from all

AuthType Basic

AuthUserFile .htpass

AuthName "Protected Area"

require valid-user

allow from x.x.x.x

allow from y.y.y.y

Satisfy Any

For nginx the configuration is:

satisfy any;
allow x.x.x.x;
allow y.y.y.y;
deny all;
auth_basic "Protected Area";
auth_basic_user_file .htpass;

satisfy any;

allow x.x.x.x;

allow y.y.y.y;

deny all;

auth_basic "Protected Area";

auth_basic_user_file .htpass;

Plesk 12.5 Protected Directories Break Nginx/PHP-FPM

By admin on November 27, 2015 in Nginx, Plesk

On Plesk 12.5, when using PHP-FPM with Nginx there’s a problem with the way protected directories are implemented. Each protected directory creates a “location” block in the Nginx config that proxies to Apache. So protected directories are implemented in Apache only. Nginx just passes through to Apache. This is not a great design choice in our opinion. Instead protected directories should be implemented directly in Nginx.

One of the side effects of the 12.5 implementation is that inside protected directories Apache handles PHP even if you have the domain configured to use Nginx with PHP-FPM. This is especially problematic if you have the entire site password protected. The “location /” block takes precedence over the “location *.php” block so the entire sites ends up using Apache instead going directly to PHP-FPM.

To get around this problem I do the following in Plesk:

Create a protected directory for “/protected”. Add users as needed.
On the “Apache & nginx Settings” screen, add the following to the “Additional nginx directives” field:

auth_basic "Restricted"; auth_basic_user_file /var/www/vhosts/system/acme.com/pd/d..httpdocs@protected;

1
2

auth_basic "Restricted";
auth_basic_user_file /var/www/vhosts/system/acme.com/pd/d..httpdocs@protected;
In your .htaccess file add:

AuthType Basic AuthUserFile "/var/www/vhosts/system/acme.com/pd/d..httpdocs@protected" Require valid-user

1
2
3

AuthType Basic
AuthUserFile "/var/www/vhosts/system/acme.com/pd/d..httpdocs@protected"
Require valid-user

The last step is important because we need both Apache and Nginx to enforce the protected directory.

1 2 … 4 Next →

Need help immediately?

$100/hour
Satisfaction Guaranteed

Top Nav

Navigation