How can I log client Ip in postclientflow?

sunin_shah
Participant II

Apologies, but this subject keeps cropping up and most of the posts I have come across are now too old so I will ask again. I want to log the originating client IP address in the postclientflow of my API proxy. There are a number of things that I need clarification on.

1. If I log 'client.ip' value, this always seems to contain an address from the internal IP range (e.g

192.168.81.85). Where is this being populated?

2. If I set the 'X-Forwarded-For' header to some value, then this gets populated into the 'client.ip' and will be logged with one exception - if a node.js target is called, the client.ip address again contains an internal IP address.

This is a bit problematic since at the moment, the 'X-Forwarded-For' header can to set to any value and the edge platform will accept it and use it (it seems). It also appears, the original X-Forwarded-For value is then thrown away if a node.js target is called.

How is it possible to reliably log the originating Client IP address?

0 6 1,435
6 REPLIES 6

Hi @Sunin Shah

What I generally do is read the value of X-Forwarded-For in PreFlow, extract the last ip in the chain and save that ip value to a new custom variable. That way I know the client's ip address throughout the flow whatever happens to X-Forwarded-For header during the flow execution.

Cheers

Ozan

@oseymen@apigee.com

I don't see a list of values in this header -- only one value which I set to some arbitrary string. I can see this when I trace through my API proxy.

Why is it the last value? Doesn't that relate to the last network equipment the message passed before it got to the edge processor?

In any case, I am not seeing a list of values -- only 1 value. Is this possibly an issue with how our proxies may be configured?


Ideally Client IP address will be the first entry in X-Forwarded-For: header.

Every time your Client goes through a proxy, IP address of the proxy gets appended to this list. E.g. after the 2 proxies, the structure of this header will be -

X-Forwarded-For: OriginatingClientIPAddress, proxy1-IPAddress, proxy2-IPAddress

As @Ozan Seymen suggested, you could extract the first value & store it in a local variable in Pre-flow. Then use it in your Post-Client flow to log it.

Regarding whether to pick the last or first IP:

Following on from the chain structure in @sudheendra1's reply, I generally pick the last ip and the reason is that the chain before the last ip can be "played with" by the clients. I guess this is the second part of your question that we haven't really answered.

Try it for yourself (my ip is 82.8.64.79):

curl https://abcd -H "X-Forwarded-For: 1.1.1.1,2.2.2.2"

Will give you:

X-Forwarded-For: 1.1.1.1,2.2.2.2,82.8.64.79

Obviously you will need to make the decision yourself but you understand the general structure.

If you are particularly worried about the fact that IP chain can be spoofed, you might be doing something wrong or putting too much trust in IP addresses. Setting up proxies to hide originating IP addresses, or configuring/using VPN on another country, etc is pretty easy nowadays... I am not even counting TOR...

sunin_shah
Participant II

Thanks @oseymen@apigee.com and @sudheendra1. Given that IP address is not reliable as it can easily be spoofed, what are the alternatives -- besides consumer key which can also be compromised?

Hi @Sunin Shah - please see section 2.1 Client Types on OAuth specification (https://tools.ietf.org/html/rfc6749#page-14) which is a great source of information on client identification. Basically your use of client id/secret combo depends on the capability of the client to keep its credentials secure.

So the options are:

  • Client id - for identification only, not authentication
  • Client id + secret - only if client is of confidential type
  • Client certificates for mutual SSL - pain to generate and manage certs for each client but secure as it relies on existing TLS infrastructure