Skip to main content

You are here

Nginx

Hide Server and Web Application Information

First and foremost, this is security over obscurity. No relevant security improvement is gained by this, but rather just annoy or hopefully prevent automated bots or script kiddies from doing any future damage. By NO means it should be the only defensive mechanism for any site!

This site runs on Drupal. Drupal, by default returns Drupal specific http headers on every request. So I wanted to disabled this completely at the server level, in addition to the PHP and Apache information that is part of a typical stock LAMP configuration.

First, we start with PHP. The PHP X-Powered-By header can be disabled by disabling the expose_php option:

expose_php = Off

Next, is updating the default Server header set by Apache:

ServerTokens Prod

Finally, it's time to remove the X-Generator and X-Drupal-Cache specific Drupal headers.
Using Apache via mod_headers module:

<IfModule mod_headers.c>
     Header unset X-Generator
     Header unset X-Drupal-Cache
</IfModule>

Using Nginx via the headers more module:

more_clear_headers 'x-generator';
more_clear_headers 'x-drupal-cache';

Why stop here when I can set custom headers. So as a joke, I want to tell the world that my sites are powered by Unicors and I’m the hacker being it. Doing so is dead simple.

Nginx

add_header              X-Powered-By "Unicorns";
add_header              X-hacker "Alpha01";

Varnish (vcl_deliver)

set resp.http.X-Powered-By = "Unicorns";
set resp.http.X-hacker = "Alpha01";

Now, let's view my new http headers

alpha03:~ tony$ curl -I https://www.rubysecurity.org
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2016 03:53:40 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: __cfduid=d8fbf8e2a27fac74e782224db3fd3c86c1479959620; expires=Fri, 24-Nov-17 03:53:40 GMT; path=/; domain=.rubysecurity.org; HttpOnly
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: public, max-age=300
X-Content-Type-Options: nosniff
Content-Language: en
X-Frame-Options: SAMEORIGIN
Last-Modified: Tue, 22 Nov 2016 06:55:27 GMT
Vary: Cookie,Accept-Encoding
Front-End-Https: on
X-Powered-By: Unicorns
X-hacker: Alpha01
Server: cloudflare-nginx
CF-RAY: 3069ea499a6320ba-LAX

References:
http://php.net/manual/en/ini.core.php#ini.expose-php
http://httpd.apache.org/docs/2.4/mod/core.html#servertokens
https://www.drupal.org/node/982034#comment-4719282
http://nginx.org/en/docs/http/ngx_http_headers_module.html

Programming: 

Awesome Applications: 

Compiling Nginx dynamically loadable modules

I’ve compiled plenty of dynamic loadable modules for Apache, but never for Nginx up until now. I must say compiling modules for Apache is a much easier process compared to Nginx.

I use Nginx as a SSL reverse proxy/terminator. I wanted to be able to remove certain http headers at the Nginx level rather than on my Apache backend. The way to achieve this is using a module called headers more , which is not part of core Nginx.

My Setup:
I’m using the nginx package installed via by the epel repository for CentOS 6.x. So compiling the module was a bit tricky initially.

Compilation Process:
1). Download the source code for the module, from https://github.com/openresty/headers-more-nginx-module/tags

2). You need to find out the running version of Nginx:

$ nginx -v
nginx version: nginx/1.10.1

3). Download and extract the source code for that version of Nginx:

$ wget 'http://nginx.org/download/nginx-1.10.1.tar.gz'

4). Compilation:
On my first initial compilation, I mistakenly compiled the module using the following:

./configure --prefix=/opt/nginx \
--add-dynamic-module=/opt/headers-more-nginx-module/headers-more-nginx-module-0.32

Even though the module compiled successfully, when trying to load the module, it gave me the following error:

$ nginx -t
nginx: [emerg] module "/usr/lib64/nginx/modules/ngx_http_headers_more_filter_module.so" is not binary compatible in /etc/nginx/nginx.conf:9
nginx: configuration file /etc/nginx/nginx.conf test failed

It turns out the module has to be compiled using the same ./configure flags as my running version of Nginx, in addition to the --add-dynamic-module=/opt/headers-more-nginx-module/headers-more-nginx-module-0.32 flag. Luckily, this can easily been obtained by running the following:

$ nginx -V
nginx version: nginx/1.10.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ld-opt=' -Wl,-E'

This is the tricky and annoying part. Since, the epel repo packaged binary of nginx was compiled with support of additional modules, the identical manual compilation that I was trying to do required some dependencies to be installed. In my case I just had to installed the following dependencies:

# yum install libxslt-devel perl-ExtUtils-Embed GeoIP-devel

After compilation completes. Then it's just a matter of adding the module to the nginx.conf config. In my case, I manually copied over the compiled module to /usr/lib64/nginx/modules, so my config looks like this:

load_module "/usr/lib64/nginx/modules/ngx_http_headers_more_filter_module.so";

It is worth mentioning that Nginx is very picky on the order in which its configuration is set. For example. load_module option has be set before the events configuration block like this:

load_module "/usr/lib64/nginx/modules/ngx_http_headers_more_filter_module.so";

events {
    worker_connections  1024;
}

Otherwise, you'll get the following error when trying to load the module.

# nginx -t
nginx: [emerg] "load_module" directive is specified too late in /etc/nginx/nginx.conf:14
nginx: configuration file /etc/nginx/nginx.conf test failed

One really important thing to keep in mind, is that you'll need to recompile the module each time Nginx gets updated.

Linux: 

Awesome Applications: 

Locking Down WordPress Access with Varnish 3.x

I have Varnish in front of all my WordPress sites and configured all /wp-admin traffic use https via Nginx. See https://www.rubysecurity.org/wordpress_admin-ssl

So to lock down access to my WordPress site's requires both Varnish and Nginx configs to be modified.

Block at the http Varnish level:

sub vcl_recv {
    if ((req.url ~ "wp-(login|admin)") && (client.ip !~ MY-IP-ADDRESS)) {
                error 403 "Fuck off";
        }
}

Block at the https Nginx level (using shit.alpha01.org as an example):

                location /wp-admin {
                        allow   MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-admin;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }
                location /wp-login.php {
                        allow MY-IP-ADDRESS;
                        deny all;
                        proxy_pass https://shit.alpha01.org/wp-login.php;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $http_host;
                }

Linux: 

Awesome Applications: 

Locking Down Drupal Access with Nginx

This site is powered by Drupal. Drupal and WordPress for that matter, are well targeted platforms, mainly because of their large install base on the internet. Quite frankly the reason I bother using both Drupal and WordPress instead of a flat-file based CMS is because I have to deal with these web applications at work on a daily basis, so it's a great way to keep myself current with the technology that's paying my bills.

I have Nginx acting as an SSL proxy for www.rubysecurity.org, which is hosted on an Apache back-end. So I have a few configs that I've enabled to lock down access to my Drupal site. The configs are made at the Nginx proxy level, so they can never reach Apache.

Firstly, I have all of Drupal's /admin locked out from outside access:

        location = /admin {
                allow MY-HOME-IP-ADDRESS;
                deny all;
                return 403;
        }

Next, I only allow login access from my home ip address:

        location = /user {
                allow MY-HOME-IP-ADDRESS;
                deny all;

                proxy_pass https://www.rubysecurity.org/user;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
        }

Lastly, since Nginx is unable to process query strings at the location block level, I've setup an additional config to drop all user login query requests.

       if ($args ~* "q=user") {
                set $blockme  M;
        }
        if ($remote_addr != MY-HOME-IP-ADDRESS) {
                set $blockme  "${blockme}E";
        }
        if ($blockme = ME) {
                return 403;
       }

Linux: 

Awesome Applications: 

Reverse SSL Proxy with Nginx

Nginx is turning to be an awesome SSL reverse proxy server, although I can't say I've really put it to real heavy duty use or how it well scale since my sites have relatively slow traffic. Thus said, a reverse SSL proxy using Nginx is working flawless in my environment!

Since all of my sites are being served within a KVM guest using NAT networking, all SSL traffic has to go through the KVM host of which Nginx is being used to proxy the requests to the guest KVM. Nginx is awesome since it supports specifying multiple server blocks (think of virtul hosts in Apache) set to listen on port 443 within the main http block. With this configuration available, it is possible to specify different reverse proxy end points.

On my server I have enabled SSL for www.rubysecurity.org and www.rubyninja.org.

First thing I needed to do is to map the sites local IPs to the KVM hosts file.

192.168.100.208 rubysecurity.org www.rubysecurity.org
192.168.100.209 rubyninja.org www.rubyninja.org

Then configure nginx.conf (sample server blocks):

server {
        listen       443;
        server_name  www.rubysecurity.org;
        ssl                 on;
        ssl_certificate     /etc/nginx/certs/www.rubysecurity.org.bundled.crt;
        ssl_certificate_key /etc/nginx/certs/www.rubysecurity.org.key;


        location / {
            proxy_pass   https://www.rubysecurity.org;
	    
		    ### Set headers ####
            proxy_set_header        Accept-Encoding   "";
	        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-Forwarded-Proto https;##
		    #This is better##
	        proxy_set_header        X-Forwarded-Proto $scheme;
		    add_header              Front-End-Https   on;
 
            # We expect the downsteam servers to redirect to the right hostname, so don't do any rewrites here.
            proxy_redirect     off;
        }
    }

 	server {
        	listen   443;
        	server_name www.rubyninja.org;
        	ssl on;
        	ssl_certificate     /etc/nginx/certs/www.rubyninja.org.bundled.crt;
        	ssl_certificate_key /etc/nginx/certs/www.rubyninja.org.key;

	    location / {
            proxy_pass   https://www.rubyninja.org;

            ### Set headers ####
            proxy_set_header        Accept-Encoding   "";
            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-Forwarded-Proto https;##
            #This is better##
            proxy_set_header        X-Forwarded-Proto $scheme;
            #add_header              Front-End-Https   on;

            # We expect the downsteam servers to redirect to the right hostname, so don't do any rewrites here.
            proxy_redirect     off;
        }

One interesting thing in Nginx with SSL is that it doesn't have a dedicated Certificate Authority (CA) ssl certificate directive, unlike SSLCACertificateFile in Apache. Instead the CA certificate has to be bundled with the public ssl certificate, which it's really not a big deal given that multiple CA's tend to bundle their intermediate CA certificates similarly.

Linux: 

Awesome Applications: 

Leaving Gmail and Google Apps: Part I

Since I'm paying for essentially unmaged dedicated hosting so I can run my mail server. I opted to consolidate my personal web applications to the same physical box. This is why I created a KVM guest that would solely be used for my web traffic. One of the main challenges I'm faced is the fact that I only have one public IP address. This means that all of my KVM guests have been configured using the default NAT networking.

For all http traffic I'm using Varnish as the proxy and caching server and for https traffic I'm using Nginx.
http_architecture

First thing that broke using this different architecture on my sites are the mod_access IP restrictions that I originally had set in place previously. This is becuase the Apache backend see's all requests originating from the Varnish and Nginx proxies. Luckily both Varnish and Nginx have really simple access control mechanism built in them.

For example, in Varnish I can create a list of IPs that I can use to their block or grant access to certain URLs.

acl admin {
   "localhost";
    "MyPublicIPAddress";
} 

sub vcl_recv {
  # Only allow access to the admin ACL
  if (req.url ~ "^/secureshit" && req.http.host ~ "rubysecurity.org") {
    if (client.ip ~ admin) {
      return(pass);
    } else {
      error 403 "Not allowed in admin area.";
    }
  }
}

Nginx acl

location  /secureshit {
  allow MyPublicIPAddres;
  deny all;
  proxy_pass https://www.rubysecurity.org/secureshit;
}

Linux: 

Awesome Applications: 

Premium Drupal Themes by Adaptivethemes