Maxim Dounin
October 20, 2014 01:48AM
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/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Nginx Security Hardening and Rules

c0nw0nk October 18, 2014 10:51PM

Re: Nginx Security Hardening and Rules

c0nw0nk October 18, 2014 11:21PM

Re: Nginx Security Hardening and Rules

mex October 19, 2014 11:00AM

Re: Nginx Security Hardening and Rules

c0nw0nk October 19, 2014 12:14PM

Re: Nginx Security Hardening and Rules

mex October 19, 2014 12:57PM

Re: Nginx Security Hardening and Rules

itpp2012 October 19, 2014 01:31PM

Re: Nginx Security Hardening and Rules

c0nw0nk October 19, 2014 01:47PM

Re: Nginx Security Hardening and Rules

sarahnovotny October 19, 2014 12:22PM

Re: Nginx Security Hardening and Rules

Maxim Dounin October 20, 2014 01:48AM

Re: Nginx Security Hardening and Rules

c0nw0nk October 20, 2014 09:37AM

Re: Nginx Security Hardening and Rules

c0nw0nk October 20, 2014 09:42AM

Re: Nginx Security Hardening and Rules

Maxim Dounin October 20, 2014 09:46AM

Re: Nginx Security Hardening and Rules

Stefanita Rares Dumitrescu October 20, 2014 01:26PM

Re: Nginx Security Hardening and Rules

mex October 20, 2014 02:13PM

Re: Nginx Security Hardening and Rules

Maxim Dounin October 20, 2014 02:24PM

Re: Nginx Security Hardening and Rules

c0nw0nk October 21, 2014 09:16AM

Re: Nginx Security Hardening and Rules

itpp2012 October 21, 2014 10:47AM

Re: Nginx Security Hardening and Rules

c0nw0nk October 21, 2014 02:01PM

Re: Nginx Security Hardening and Rules

c0nw0nk October 23, 2014 11:43AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 135
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready