NGINX: rewrite non-www to www for multi domain virtual hosts

If you have NGINX virtual host that has a multi different domains pointing to same document root (multi server_name), and you want to automatically redirect non-www to www, than bellow is simple solution. I also wanted to redirect to https with www.

If you don’t need https redirection, than you can simply use variable $scheme instead of “https:”. 

if ( $host !~ ^www\. ) {
            return 302 https://www.$host$request_uri;
}

So virtual host should look something like this:

server {
      listen 1.1.1.1:80;
      server_name domain1.com www.domain1.com domain2.com www.domain2.com;

      if ( $host !~ ^www\. ) {
           return 302 https://www.$host$request_uri;
      }
      return 302 https://$host$request_uri;
}

You should also make this redirect in your https server definition. otherwise request for https://domain1.com won’t redirect to www.

server {
      listen 1.1.1.1:443;
      server_name domain1.com www.domain1.com domain2.com www.domain2.com;
      if ( $host !~ ^www\. ) {
              return 302 https://www.$host$request_uri;
      }

      ssl on;
      ssl_certificate /etc/letsencrypt/live/domains.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/domains.com/privkey.pem;

      .... //other nginx configuration ....
}

Multidomain webroot for Letsencrypt with NGINX

If you have web server on which there is a lot of virtual hosts, you may want to have one webroot directory for Letsencrypt SSL certificates only. So when Letsencrypt will make the requests for SSL registration or renewal, it will look in this directory. In this case I did this on CentOS 7 with NGINX web server.

First, let’s create directory what will be used for letsencrypt purposes. It must be writable by your web server user. You can define different path.

[root@machine ~]# mkdir -p /var/www/le-certs
[root@machine ~]# chown -R wwwuser:wwwgroup /var/www/le-certs

Letsencrypt will need access in “.well-known/acme-challenge”. For NGINX add something like this in your server block for desired virtual host.

location ~ /.well-known/acme-challenge/ {
             root /var/www/le-certs/;
             break;
}

You can also create new file named, for example le-config.conf and add block above in to it. Then you can simply include this line in your virtual hosts. 

server {
             listen :443 ssl http2;
             server_name mywebsite.com www.mywebsite.com;
             root /var/www/mywebsite/;

             include le-config.conf;
              ...
}

 

 

WordPress returning 404 Error on all subpages

In this case I used NGINX as reverse proxy for ssl offloading in front of Apache. On this WordPress installation I was getting 404 on all subpages. Htaccess syntax was correct as it was nginx configuration. In this case, problem was caused because of missing “AllowOverride” Apache directive which didn’t allow htaccess to be processed. I added “AllowOverride ALL” in apache configuration for this virtual host. Subpages started to work.

Example:

<VirtualHost *:8080>
DocumentRoot /var/www/mysite.com/
ServerName mysite.com
ServerAlias www.mysite.com

<Directory "/var/www/mysite.com/">
AllowOverride All
</Directory>
</VirtualHost>

WordPress: Too Many Redirects Issue when NGINX reverse proxy to Apache

I installed NGINX and put it in front of Apache for SSL offloading and caching static content. Traffic is proxied from Nginx to Apache.  When I tried to open site via https, it returned this painful error “Too Many Redirects”.

Try to add this in your wp-config.php – if you have everything else configured correctly, it should work:

$_SERVER['HTTPS'] = 'On';

Limit xmlrpc.php to only specific web clients

Xmlrpc.php is very common target of attacks. In most cases you don’t need xmlrpc, but if you use third-party apps like WordPress for iPhone or android or other editors, then xmlrpc is the one who communicates between them and your WordPress installation. If you’ll be using it, it can be good idea to limit access to it only from “browsers” that you are using to access it. In case bellow, I’m using iPhone WordPress app.

When access to xmlrpc.php via iphone app, you’ll see that access log looks like this:

[11/Jun/2017:19:45:08 +0200] "POST /xmlrpc.php HTTP/2.0" 200 462 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Mobile/14F89 wp-iphone/7.7"

From this you can see that wp-iphone/7.7 is named as client. So this will be our key for nginx configuration. We’ll make rule that will only accept requests to xmlrpc.php from clients containing string “wp-iphone”. Other clients will be denied. This is not bulletproof of as web client can be easily spoofed, but it should block majority of attacks.

location = /xmlrpc.php {
if ($http_user_agent !~* "wp-iphone")
{
return 403;
}
include fastcgi_params;
fastcgi_pass 127.0.0.1:<your_php_fpm_port>;
}

WordPress bruteforce protection with NGINX and limit_req / request limitation

WordPress installations are very common targets of brute force attacks. With this attacks, attacker tries countless username and password variations in order to guess login informations. As you can imagine that such abusive behavior on your WordPress can cause collapse of server. Very common are attacks on wp-login.php and xmlrpc.php. There is a simple way to limit allowed number of requests on specific file with limit_req. This module can limit processing rate of requests coming from a single IP address on your web server.

In order to protect your WordPress administration you can do something like this:

# prevent brute force attacks on wp-login.php
 location = /wp-login.php {
        limit_req zone=one burst=5 nodelay;
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
 }

This will allow 5 request in 5 second “window”. When there’ll be more than 5 request in 5 seconds, Nginx will return 503 error until request rate slows down:

$ curl -I https://www.yourwebsite.com/wp-login.php 
HTTP/1.1 503 Service Temporarily Unavailable
Server: nginx

Of course, you can use limit_req to protect other systems besides WordPress to.

Ultimate NGINX configuration for WordPress

Most of the sites that I created are based on WordPress. WordPress is great platform for your sites if you take a little care for it. different kind of abusive behavior on Wordpress systems is very common. Weak points are in most cases plugins, themes and outdated code in general. Many times people think, that security of their websites is all about hosting provider, firewalls… It’s true to some point. But one of the most fundamental steps to better WordPress security is up to the end-user. Take care of your site, update it regularly, use only good plugins and themes… It’s so important that you take care for regular updates and fixes. Also, try to use as least plugins as possible. If you are using only one theme, delete the ones that you don’t use. If you’ll  use theme downloaded from internet, only use themes from good providers.

NGINX in combination with good configuration and cache system can make your website lightning fast and super responsive. Memcached, Redis, Opcache are also great for optimizing your site. You definitely want to check into them too. W3 Total Cache plugin is great and easy to configure. More about this another time.

Continue Reading

Generate NGINX virtual hosts script

I created simple script for creating NGINX virtual hosts so that you don’t have to do it manualy for every new website. Script was created for Linux – CentOS 7 – operating system but it should work on other distributions too. It is written in bash. You will also need wget and tar installed for script to work – wordpress install option.

What it does is pretty straightforward. On input side it will ask you for domain name, SSL option and WordPress installation. You can choose between http and https virtual host definition. By default it will create document root for your domain and NGINX configuration file for that domain. If you choose option for WordPress installation, then it will also download latest wordpress version and unpack files to your newly created document root. You’ll still need to create database manually and finish WordPress installation. This script is suitable for basic NGINX website configurations

Just download script here and template files. Put script createsite to your /usr/sbin/ directory and make it executable. Of corse you can change virtual host templates according to your needs too.

Continue Reading

© 2018 geegkytuts.net
Hosted by Hosterdam


About author