Nginx Security Hardening and Rules

[Maxim Dounin]

Hello!

On Sat, Oct 18, 2014 at 10:51:20PM -0400, c0nw0nk wrote:

> So since i searched the Nginx Forum i can't find anyone who has posted a
> topic for Nginx security rules or examples so i will be the first to share
> my examples regardless of how bad of a idea some people may think that is.
> 
> So the first security addition is to block direct IP access to my server
> connecting via IP instead of a assigned domain name will result in a error
> or denied request.
> 
> server {
> listen 80;
> listen [::]:80;
> location / {
> #deny  all;
> return 404;
> }

This is mostly matchies the server{} block suggested here:

http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names

It may also be a good idea to configure a default server to return 
error, to prevent processing of requests with names not explicitly 
specified in the configuration:

    server {
        listen 80 default_server;
        return 404;
    }

> Hide your Nginx version / Information by turning of server tokens and
> restrict upload file sizes.
> 
> server_tokens off;

I always wonder why people think that hiding versions improves 
security.

http://en.wikipedia.org/wiki/Security_through_obscurity

> # File uploads
> client_max_body_size 10M;

This will _increase_ allowed upload size from 1m to 10m, as 
client_max_body_size defaults to 1m.  See 
http://nginx.org/r/client_max_body_size.

> Another thing is to block access to certain directories or config files even
> file paths or locations that could be resource extensive or contain
> sensative data allowing access to only your IP.
> 
> location ~
> ^/(xampp|security|phpmyadmin|licenses|webalizer|server-status|server-info|cpanel|configuration.php|htaccess)
> {
> #deny  all;
> #return 404;
> allow 192.168.1.5;
> }

This snippet has the "allow" directive, but no "deny" ones.  That 
is, it will not block anything.  See here for docs:

http://nginx.org/en/docs/http/ngx_http_access_module.html

It's alwo important to note that it will also prevent execution of 
other handlers if configured in other locations (e.g., 
"/configuration.php" will be downloaded, if any, not passed to php 
via fastcgi).  In general, you can't just thow such a location 
into your configuration - it will cause more harm than good.

> Deny running scripts inside writable directories unless your own IP.
> 
> location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$
> {
> #return 403;
> allow 192.168.1.5;
> }

See above about allow/deny.

> Only allow these request methods GET|HEAD|POST Do not accept DELETE, SEARCH
> and other methods.
> 
> if ($request_method !~ ^(GET|HEAD|POST)$ ) {
> return 444;
> }

For nginx itself this is not needed.  Something like this may be 
useful if you are protecting your backends.  See also limit_except 
which can be used on a per-location level:

    limit_except GET POST {
        deny all;
    }

http://nginx.org/r/limit_except

> Apparently itpp2012 told me in another post the zero day exploit was fixed
> but i see no harm in having it in here. (And some people still run outdated
> PHP versions.)
> 
> location ~ \.php$ {
> # Zero-day exploit defense.
> # http://forum.nginx.org/read.php?2,88845,page=3
> # Won't work properly (404 error) if the file is not stored on this server,
> which is entirely possible with php-fpm/php-fcgi.
> # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another
> machine. And then cross your fingers that you won't get hacked.
> try_files $uri =404;
> fastcgi_split_path_info ^(.+\.php)(/.+)$;
> }

That's more about php-side misconfiguration, cgi.fix_pathinfo 
should be set to 0 in php.ini.

There are something about this here on wiki:

http://wiki.nginx.org/Pitfalls#Passing_Uncontrolled_Requests_to_PHP

> Password restrict directories you only want yourself or admins to access.
> 
> location ~ /administrator/.*) {
> auth_basic "Restricted";
> auth_basic_user_file C:/www/vhosts/passwd;
> }

That's very bad snippet.  You really shouldn't use regular 
expressions instead of prefix locations.  And, if there are 
locations given by regular expressions, it is important to make 
sure the location will have precedence.  So it should be:

    location ^~ /administrator/ {
        auth_basic "Restricted";
        auth_basic_user_file /path/to/file;
 
        ... additional configs as needed, e.g., "location ~ \.php$"
    }

See some tips about location matching here in the docs:

http://nginx.org/r/location

-- 
Maxim Dounin
http://nginx.org/