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?

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.

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.

> 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?

    $ 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.)

.. 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.

Yeah, whoops. Copying.

You could also hardlink them.

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.

You can chroot any user process. Some processes are harder to chroot than others.

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.