<div dir="ltr"><div>Hi,<br><br>I have applied the pull request as suggested providing the reverse and forward deployment mode and it has worked a treat fixing this issue for my specific use case. <br><br>While traditionally many would not actually have X-Forwarded-For in a forward mode in our case it was was provided as default by our vendor and then in various scenarios has become useful due to chained proxy scenario originally in allowing others to determine origin in a simpler way. Now in this case where this is enabled client IPs is displayed I will be reassessing this (although being able to link by client IP events to real internet "hiding" proxy could be useful) will need to be done now the option is provided and can be assessed for benefits vs negatives as the option is there.<br><br>I imagine others may also utilize this depending on their specific requirements and having this certainly provides the choice and flexibility so thank you very much for providing this fix.<br><br><br>Kind Regards,<br>Kevin Ross<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 October 2014 20:17, Duarte Silva <span dir="ltr"><<a href="mailto:duarte.silva@serializing.me" target="_blank">duarte.silva@serializing.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday 28 October 2014 17:49:58 Peter Manev wrote:<br>
> On Tue, Oct 28, 2014 at 3:32 PM, Kevin Ross <<a href="mailto:kevross33@googlemail.com">kevross33@googlemail.com</a>><br>
wrote:<br>
> > Hi,<br>
> ><br>
> > I use X-Forwarded-For overwriting. I have new proxies though and before it<br>
> > would be typically a single IP but now it is X-Forwarded-For: CLIENT_IP,<br>
> > 127.0.0.1.<br>
<br>
</span>With those new proxies you are using, the vendor is actually implementing the<br>
XFF specification correctly where the left-most value is the original client<br>
and where each successive proxy that passed the request adds it's IP address<br>
to the right.<br>
<br>
In Suricata, the XFF code will use the last entry because it has been designed<br>
to be used in a reverse proxy environment, meaning, in an environment where<br>
you have a reverse proxy (Apache, F5, etc.), routing traffic to the internal web<br>
servers where the last IP address of the XFF header is the actual IP from the<br>
client that requested the page, image, etc.<br>
<br>
This is so to avoid spoofing, the last IP is the one added by the reverse proxy<br>
and the one that should be trusted.<br>
<br>
One way I could see this being fixed is by adding a configuration option in<br>
order for the XFF code to behave differently depending on the deployment,<br>
allowing the user to choose.<br>
<br>
Cheers,<br>
Duarte<br>
<div class="HOEnZb"><div class="h5"><br>
> ><br>
> > I have no idea why this is the case it would add that in but basically<br>
> > Suricata is taking the loopback as the overwrite address. Can I specify<br>
> > which which one to use? If not I will need to disable this which I would<br>
> > prefer not to until vendor responds :(<br>
> ><br>
> ><br>
> > Thanks,<br>
> > Kevin<br>
><br>
> I am not sure I understand - could you give an example of a log entry<br>
> or something ?<br>
<br>
</div></div></blockquote></div><br></div>