问题
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?
回答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 theX_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.
回答2:
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.
回答3:
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.
来源:https://stackoverflow.com/questions/27934352/how-to-disable-ip-spoofing-check-in-rails-4-application