How to disable IP Spoofing check in Rails 4 application?

Question

I'm getting the following error on my Rails 4 application:

ActionDispatch::RemoteIp::IpSpoofAttackError: IP spoofing attack?! HTTP_CLIENT_IP="xx.xx.xx.xx" HTTP_X_FORWARDED_FOR="xx.xx.xx.xx"

We don't need this type of security check, so after some Googling around I found this:

https://github.com/rails/rails/issues/10780

When an intermediate proxy inserts the user IP address both in the HTTP_CLIENT_IP and the HTTP_X_FORWARDED_FOR, and this address is private, ActionDispatch::RemoteIp raises an IpSpoofAttackError exception.

When an enterprise proxy includes the user's IP address in a header, this will commonly be private. Removing private IP addresses from the chain contained in HTTP_X_FORWARDED_FOR should probably be done only when the address is not an exact match of the one found in HTTP_CLIENT_IP. If it is a match, that should be the user's IP address.

This happens for example with the following environment:

HTTP_CLIENT_IP: 172.17.19.51 HTTP_X_BLUECOAT_VIA: ffffffffffffffff HTTP_X_FORWARDED_FOR: 172.17.19.51 REMOTE_ADDR: xxx.xxx.xxx.xxx (this would be a public IP address)

---

A fix presented here:

As a work-around, I've disabled this check in config/application.rb:

config.action_dispatch.ip_spoofing_check = false

However this doens't seem to work in Rails 4. What is the new call and how do I set it site wide?

Answer 1

Rather than turning off the warning, it might be better to fix the actual problem. Here's my rephrasing of what Rails is telling you:

This request seems to have come through two different reverse proxies. One of them set the CLIENT_IP header to the user's IP address; the other set the X_FORWARDED_FOR header. One of those values is probably correct, the other probably contains the IP of a reverse proxy, and I have no way to tell which is which. I can't reliably determine this user's IP address, so I'm going to reject the request.

The "correct" solution is to stop setting both headers. For that you'll need to track down where they're coming from (I'd start with your Bluecoat device) and find out if they're both needed. Usually you'll only use one or the other.

If it turns out they are both needed (I've seen stranger things), then you'll need to find out which header is being set first (assuming there are two proxies in the chain). Then you can write a custom middleware that deletes the other HTTP header.

See Rails 3 middleware modify request headers for pointers on how to create your own middleware. Insert it before the RemoteIp middleware, clear out whichever header has the "bad" value, and you should be good.