« Previous Next »

Thread: Can requests appear to come from the original client?

Last post 11-05-2009 6:21 PM by anilr. 27 replies.

Average Rating Rate It (5)

RSS

Page 1 of 2 (28 items) 1 2 Next >

Sort Posts:

  • 02-02-2009, 5:14 PM

    • Jinkinz
    • Not Ranked
    • Joined on 07-30-2007, 6:33 PM
    • Posts 6

    Can requests appear to come from the original client?

    In the proxy settings of a server farm there is the option to preserve the client IP in a custom header.  My question is can requests appear to come from the original client?  The reason I would like this functionality is because we have log parsers that have already been set up to run reports on each server and IP address but the IP addresses for all the requests are the ARR server's IP address, not the client's.  In the CTP1 version of the feature, this was possible.  See the following screenshot: http://images.ddti.net/capture.jpg

  • 02-02-2009, 6:22 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    You would have to run some code in the destination server to replace the information being logged with the client ip in the header you chose in ARR - same as TP1 - we are planning to release a helper module you can install on the destination server to make this possible.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 02-03-2009, 2:49 PM In reply to

    • Jinkinz
    • Not Ranked
    • Joined on 07-30-2007, 6:33 PM
    • Posts 6

    Re: Can requests appear to come from the original client?

    anilr:

    You would have to run some code in the destination server to replace the information being logged with the client ip in the header you chose in ARR - same as TP1 - we are planning to release a helper module you can install on the destination server to make this possible.

    I've started a new module and I was hoping I could overwrite the Request.UserHostAddress with context.Request.Headers["X-Forwarded-For"] and let the logging module pick it up later in the pipeline.  But it is a read-only property.  How do you suggest I proceed here?  Will your helper module be available soon?  Thanks for your time.

    Kelly

  • 02-04-2009, 1:44 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    I don't think it is possible from a managed module - you would have to write a native module.  The helper module will be available soon.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 02-24-2009, 3:46 PM In reply to

    • Jinkinz
    • Not Ranked
    • Joined on 07-30-2007, 6:33 PM
    • Posts 6

    Re: Can requests appear to come from the original client?

    Any update on this now that we've got a RTW?  Thanks so much.

  • 02-25-2009, 7:20 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    It will be very soon.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 03-03-2009, 8:25 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    The helper module is released here.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 03-03-2009, 10:41 PM In reply to

    • Jinkinz
    • Not Ranked
    • Joined on 07-30-2007, 6:33 PM
    • Posts 6

    Re: Can requests appear to come from the original client?

    Works great...thanks for your support.

  • 04-13-2009, 12:04 PM In reply to

    • Rolle
    • Not Ranked
    • Joined on 04-13-2009, 3:57 PM
    • Posts 4

    Re: Can requests appear to come from the original client?

    Hi,
    The ARR Helper Module is just what I was looking for to replace an old ISAPI Filter.

    While testing the module on our development system (IIS 7) I have come across a problem.
    When using the X-Forwarded-For functionality to capture the client IP from the Loadbalancer all is well as long as the entered value from the Loadbalancer is a valid IP, which can also be split using a Comma.

    When the IP is no longer valid, for Example (192.168.1 or unknown) the ARR Helper Module seems to still try and pass this value to the IIS Core. In this case the IIS Web Core rejects with an Exception (500; Internal Server Error) and therefore the entire Request fails.

    Now I am not using the ARR Helper Module in conjunction with the IIS ARR but as stated in the Post any Loadbalancer can be used and in this scenario the Loadbalancer passes the value “unknown” in the X-Fowarded-For Header when no client IP can be determined.

    Is this a problem which can be fixed in the ARR Helper Module maybe using a RegEx to filter the value or is this filtering not to be supported by the ARR Helper? Or am I just missing something?

    Thanks in advance for any help

  • 04-13-2009, 2:57 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    I can look at fixing this issue and re-releasing the helper module - btw, in what case can the load-balancer not determine the client IP address?  The client IP address is part of the tcp handshake and no dns query is needed for that.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 04-14-2009, 12:35 PM In reply to

    • Rolle
    • Not Ranked
    • Joined on 04-13-2009, 3:57 PM
    • Posts 4

    Re: Can requests appear to come from the original client?

    Hi,

    I know that the client IP should always be passed and thats why this is quite interesting. Some requests to the Loadbalancer are passed directly to the Backend IIS Servers, this is due to the current rebuild of the system that we are in at the moment. Due to this I started a Trace and found Requests coming from upstream Proxies directly to the Backendservers and setting the X-Forwarded-For Header to uknown due to probably having some sort of acl's set on IP level. In this case the ARR Helper is doing what it is supposed to...

    Therefore an update of the ARR Helper would be of help for such a situation without having to create new sites excluding the Module in the IIS Servers, but strictly spoken this is also not the required functionality of the ARR Helper Module so I suppose an update to include such a filter would be purely good will :-)

     

    Thanks again for the quick reply.

     

  • 04-15-2009, 4:36 AM In reply to

    • Rolle
    • Not Ranked
    • Joined on 04-13-2009, 3:57 PM
    • Posts 4

    Re: Can requests appear to come from the original client?

    Another scenario I have been able to reproduce this problem in, is as follows:

    Using a squid proxy for example and disabling the client IP forwarding, the proxy sets the X-Forwarded-For to unknown in the request header. The load balancer then sends the IP of the requesting proxy and if set the value of the X-Forwarded-For in the request header comma separated to the IIS backend server. In this case the ARR Helper extracts the last value after the comma being unknown and sends this to the IIS Web Core which causes an Exception and terminates the entire request.

  • 04-19-2009, 7:48 PM In reply to

    • ShqTth
    • Not Ranked
    • Joined on 09-15-2008, 3:04 AM
    • Posts 7

    Re: Can requests appear to come from the original client?

    Sometimes squid likes to make one http get request on behalf of many client requests.

     So X-FORWARDED-FOR contrains the ips of the many clients seperated by ",".

     So I get that a lot when I used F5XForwardedFor.dll. But that doesnt work with Vista.

     Also, it would be nice it your module checked the remote address to verify its from a specific source before using the X-FORWARDED-FOR header.

     

    The reason being, is a client can fake X-FORWARDED-FOR header to fool a script.

    If your module checked the REMOTE_ADDR or REMOTE_HOST to make sure it matched a specific value or if the REMOTE_ADDR is of the same network as LOCAL_ADDR (you can tell if local addr is 192.168.x.x or 127.0.0.1 etc) then HTTP_X-FORWARDED-FOR header would be used and trusted, if its not trusted then only REMORE_ADDR is used.

     the HTTP_VIA indicated that a proxy server is used, but that can be spoofed too. Usually that header contains the name of the pc and port of the proxy server. So the machine name of the proxy has to resolve to the REMOTE_ADDR.

     

    Anyways my IIS server can be accessed with or without a proxy. (proxy runs on a different PC), so it would be good to make sure the IP in X-FORWARDED-FOR is really the IP of the client and not a spoofed ip

  • 04-20-2009, 2:20 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Can requests appear to come from the original client?

    How can you verify that the X-Forwarded-For is not spoofed?  It is never going to be the IP of the client, but an arbitrary IP that connected to the load-balancer.  Any validation of the client should be done by the load-balancer connecting to ARR.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 04-20-2009, 2:48 PM In reply to

    • ShqTth
    • Not Ranked
    • Joined on 09-15-2008, 3:04 AM
    • Posts 7

    Re: Can requests appear to come from the original client?

    1)You can check to make sure REMOTE_ADDR matches one of the ip address defined in the config file.

     If there is a match, then you know the request came from the load balancer / proxy srrver in reverse mode meaning X-FORWARDED-FOR can be trusted.

     - This option should be an option to turn off or on.
     - if LOCAL_ADDR matches REMOTE_ADDR then its trusted.
     - network range or netmask would be nice such as y.y.y.x or x.x.x.x/y (example 192.168.1. or 192.168.1.0/24)

     2) Or if REMOTE_ADDR matches 127.0.0.1 or 192.168.X.X or LOCAL_ADDR you pretty much can assume that X-FORWARDED-FOR can be trusted as the request came from a local server.

     

    3) Advanced option (will be slower as it requires a lookup, but result can be cached):
     Or the VIA header cantains the name of the proxy server. oviously the name much resolve to the REMOTE_ADDR to be valid.

    4) REMOTE_HOST can be matched. it is usually the ip addres or name of the proxy server. But information in REMOTE_HOST isn't always reliable. (I never seen it set to an actual host name to date)

    Anyways

    options 1 & 2 seem like a good way to make sure X-FORWARDED-FOR can be trusted or not. but if an option like that is implemented it should be optional as some people wont need it.

Page 1 of 2 (28 items) 1 2 Next >
Microsoft Communities