CODEWITHSUNDEEP
ruby-on-railsspoofing
sergserg
sergserg

Reputation: 22254

How to disable IP Spoofing check in Rails 4 application?

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?

Upvotes: 12

Views: 6867

Answers (5)

Artem Vasilev
Artem Vasilev

Reputation: 2211

I can confirm that config.action_dispatch.ip_spoofing_check = false still works (Rails 7).

Upvotes: 1

Bill Lipa
Bill Lipa

Reputation: 2079

If you know which of X-Forwarded-For or Client-Ip you want, you can delete the other one in a rack middleware (here for nginx):

# the Client-Ip header can come from misconfigured remote proxies.  Filter it out
# since we know nginx always uses X-Forwarded-For to avoid IpSpoofAttackError.
config.middleware.insert_before ActionDispatch::RemoteIp, Rack::Config do |env|
  env.delete 'HTTP_CLIENT_IP'
end

Upvotes: 1

wjordan
wjordan

Reputation: 20390

config.action_dispatch.ip_spoofing_check = false is still the correct setting.

However, web-console (included in Rails development environment by default since Rails 4.2) doesn't respect this setting and raises IpSpoofAttackError whenever it's included in the application stack, even when spoofing_check is false. A workaround for this issue is to remove web-console from your environment's application stack.

See rails/rails#32379 and rails/web-console#254 for more details on this issue and a proposed fix.

Upvotes: 2

James Mason
James Mason

Reputation: 4296

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.

Upvotes: 16

fylooi
fylooi

Reputation: 3870

config.action_dispatch.ip_spoofing_check should work based on the calling chain for RemoteIp.

You should be able to achieve the same effect by setting config.action_dispatch.trusted_proxies to a regex matching all IPv4 addresses.

Upvotes: 5

Related Questions