
Nginx WebServer Best Security Practices - sant0sk1
http://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html
======
swombat
Some of those tips won't be applicable to any real-life server set-up. I mean,
for example:

    
    
      ## Start: Size Limits & Buffer Overflows ##
      client_body_buffer_size  1K;
      client_header_buffer_size 1k;
      client_max_body_size 1k;
      large_client_header_buffers 2 1k;
    

Many web-apps will need larger request and body sizes than this! And I'm not
sure why setting a buffer size protects from buffer overflows. Why does a 1k
size work better than a 16k size? If the buffer is used correctly, it
shouldn't overflow, no matter its size...

Seems to me that cargo-culting this set of "best practices" is a good way to
DoS your own server. Who needs crackers when you can do it all yourself?

------
viraptor
Although most of the pro-tips are good (in general), some look like put
together without understanding... Especially this fragment got my attention:

    
    
        # Drop sync
        $IPT -A INPUT -i ${PUB_IF} -p tcp ! --syn -m state --state NEW -j DROP
        
        # Drop Fragments
        $IPT -A INPUT -i ${PUB_IF} -f -j DROP
    

1\. First rule drops everything _apart from_ SYN on unknown connection, so the
comment is wrong.

2\. Why would anyone drop fragmented packets? Good luck with people on strange
/ misconfigured links.

3\. spoof ips looks very dodgy... why would anyone drop localhost?

4\. (own rule) You should never ever follow anything that mentions "SSL" and
"Type the following commands" without reading the openssl docs and
understanding how certificates work.

------
mikewest
Labeling this article a list of "Nginx" security best practices is probably a
bit misleading. Of the 20 tips listed, only half really deal specifically with
Nginx (and half of those feel like filler: hotlinking, for instance, is
decidedly not a security issue). The remainder are more general-purpose *nix-
lockdown mechanisms. That's not to say that they're not worth reading, as
there are some interesting nuggets in the list, but it's not what I was
expecting from the title.

------
CoreDumpling
> You can't use traditional chroot kind of setup with nginx.

I'm curious why this is the case. If even a beast like apache can be run from
a chroot jail, shouldn't it be easier to do it with something lightweight like
nginx?

~~~
silentbicycle

        $ ldd `which nginx`
        /usr/local/sbin/nginx:
            Start            End              Type Open Ref GrpRef Name
            0000000000400000 000000000089c000 exe  1    0   0      /usr/local/sbin/nginx
            0000000206c17000 0000000207042000 rlib 0    1   0      /usr/local/lib/libpcre.so.2.3
            00000002082fd000 000000020874b000 rlib 0    1   0      /usr/lib/libssl.so.15.1
            000000020874b000 0000000208cd7000 rlib 0    1   0      /usr/lib/libcrypto.so.18.0
            0000000204a0e000 0000000204e22000 rlib 0    1   0      /usr/lib/libz.so.4.1
            00000002017b8000 0000000201c99000 rlib 0    1   0      /usr/lib/libc.so.53.1
            0000000204600000 0000000204600000 rtld 0    1   0      /usr/libexec/ld.so
    

Doesn't look too bad. Start by copying the relevant libraries and config
directory to the appropriate places within the chroot jail, then test. (Those
paths are on OpenBSD 4.7-beta, probably different on your system.)

~~~
akl
.. and by 'moving those libraries' you mean 'copying' them, right? :)

A quick look at nginx's ./configure script doesn't show any options that
enable static linking on the libraries, but that would be useful for looking
into chrooting it.

~~~
silentbicycle
Yeah, whoops. Copying.

~~~
munctional
You could also hardlink them.

~~~
spc476
You don't want to do that. If there is an exploit and an ability to gain root
access, those libraries could be modified and affect everything else that uses
those libraries outside the chroot jail. Best to just copy them.

------
hasanove
Re: #10

I find it much more clean and convenient to simply create a default website
with blank webpage (or return error if preferred) that will respond to all
non-matched queries.

