Hacker News Reader

Comment by bigdubs | Hacker News Reader

Something that is pretty important, and is missing from this guide, is to make sure you add headers indicating what the original IP address for the requests were (either in x-forwarded-for or x-real-ip or something else common.)

Can do this in the root location "/" with:

proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Also good to remember to put another header in for the forwarded protocol (if you're terminating an ssl tunnel at the balancer.)

View on HN

On a security note - your application code should only trust those headers (X-Forwarded-For, X-Real-Ip, etc) for IP lookup if you control the load balancer and strip it from incoming requests.

There is nothing to stop a malicious client adding the header themselves and if you rely on IP lookup (i.e. Dev Mode active for 127.0.0.1) for access control you can leave yourself wide open. While I can't find the article at the moment, Stack Overflow accidentally gave admin level access to the site because of this over sight.

In my experience if a client adds their own X-Forwarded-For header trying to spoof their IP, nginx simply prepends it to the X-Forwarded-For header like "1.2.3.4, 33.33.33.1", where 1.2.3.4 is the address the client supplied in their spoofing attempt, and 33.33.33.1 is the actual IP address forwarded by nginx.

So you can choose to trust only the rightmost one, if there are several entries in the list.

For backend nginx instances (we use nginx to balance application servers, and nginx right in front of Unicorn on those application servers) use the Real IP module to have logs transparently show the original request IP not the load balancer's IP.

http://wiki.nginx.org/HttpRealipModule

Agreed, and also the host header

  proxy_set_header Host $host;

Reply on news.ycombinator.com