Nginx WebServer Best Security Practices

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?

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.