I see sometimes some traffic pattern which I don't fully understand, and I hope I can get some help.

Let's say I run a website. I look at the logs coming in for my http site and I see a request proxied by squid (header Via is telling me about squid). No problem there, someone is being proxied via squid.

But then I look at the IPs. The connecting IP (1.2.3.4) is consistent to where the end-user is actually physically located. However, the X-Forwarded-For header shows an IP which is -- for the sake of discussion -- EC2 (2.3.4.5).

So this could tell me that someone using 2.3.4.5 is being proxied to a squid running on 1.2.3.4. But this doesn't make sense because I know the person is located at 1.2.3.4. So overall it looks like someone at 1.2.3.4 is using a squid on EC2, which does something (maybe security?) which adds a XFF and Via header and then tunnels back to 1.2.3.4 and goes out to the internet.

This last scenario seems convoluted (and very slow adding an extra "hop") but maybe I am missing some use-case or setup which some IT might decide to do.

Does anyone know what's going on? Thanks!

PS: let's assume none is spoofing headers! As this does happen regularly, although I would call it a corner-case.

I can think of two cases.

  1. you or your hosting provider is using a reverse proxy
  2. your client is behind a "corporate" proxy (or emulating a vpn exit node through a ec2 instance with squid -- aka a sophisticated poor man's vpn)

And a third, combining the two above:

  1. Someone is behind a corporate proxy connecting to your webserver through a reverse proxy.

The X-Forwarded-For may be displaying the client along with the proxies IP address, as in: X-Forwarded-For: client, proxy1, proxy2. Usually, this header is useful for log analyzers and such, to have the origin IP for analytics or other purposes, if you have a reverse proxy you have to set it right so you don't log everything as coming from it. The last IP on that line should be the previous to-last proxy. If you are getting only one IP there, it's either badly configured or only one hop.

In case the request already comes from a corporate proxy (case 2), depending on configuration, it might arrive at your reverse proxy (case 1), and end with confusing headers (case 3) if the reverse proxy didn't clean the headers prior to adding it's own headers.

In my opinion, the most probable case might be that someone is using an EC2 instance (if you were referring to the Amazon service, but any VPS will do) as a proxy to avoid some kind of blocking.

Sources:

  • Thanks Leo. All the scenarios you list might happen, but I fail to see how they 100% apply, since in my case since the connecting IP is the physical location of the end-user. In all your cases (afaik) I should see the connecting ip as one of the proxy, which i don't. To further elaborate, I don't have a problem imagining how the XFF is populated/rewritten/messed-up .. but I don't understand the use-case in which the connecting ip is not EC2. – JoeSlav May 14 at 6:13
  • Could you clarify posting a portion of the logs? – Leo May 14 at 6:37
  • what are you looking for exactly? there are no additional info in the logs compared to what I posted in my original question. By connecting ip I mean the actual network IP making a connection, then I have an XFF with the single EC2 IP. – JoeSlav May 14 at 9:59
  • If you know your server is getting the request from a reverse proxy with XFF headers like: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; with the 2.3.4.5 as the proxy and you should be getting the client IP (as in 1.2.3.4 according to your example), not the proxy IP (ec2 2.3.4.5), in the apache logs: 1.2.3.4 - - [14/May/2018:06:28:37 -0000] "GET ... I'm trying to understand where you see the 2.3.4.5 and 1.2.3.4 IPs in the logs, or if you are looking at the HTTP headers. – Leo May 14 at 19:58
  • I know, that's why it's confusing. the connecting ip (network level ip, however you want to call it) is the physical location and the XFF ip is the proxy location. they are inverted. unless the proxy has a tunnel back to the physical location and then goes out to the internet. My initial question was therefore to understand if someone is familiar with such use case. – JoeSlav May 14 at 20:19
up vote 0 down vote accepted

After some digging, I can conclude that such scenario doesn't normally exist and it is due to a wrong network or squid configuration:

  • squid always inserts a random XFF
  • the network internal addressing is using public ip instead of private ips

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.