[Oisf-users] Suricata X-Forwarded For Question

[Kevin Ross]

Hi,

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.

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.

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.


Kind Regards,
Kevin Ross

On 28 October 2014 20:17, Duarte Silva <duarte.silva at serializing.me> wrote:

> On Tuesday 28 October 2014 17:49:58 Peter Manev wrote:
> > On Tue, Oct 28, 2014 at 3:32 PM, Kevin Ross <kevross33 at googlemail.com>
> wrote:
> > > Hi,
> > >
> > > I use X-Forwarded-For overwriting. I have new proxies though and
> before it
> > > would be typically a single IP but now it is X-Forwarded-For:
> CLIENT_IP,
> > > 127.0.0.1.
>
> With those new proxies you are using, the vendor is actually implementing
> the
> XFF specification correctly where the left-most value is the original
> client
> and where each successive proxy that passed the request adds it's IP
> address
> to the right.
>
> In Suricata, the XFF code will use the last entry because it has been
> designed
> to be used in a reverse proxy environment, meaning, in an environment where
> you have a reverse proxy (Apache, F5, etc.), routing traffic to the
> internal web
> servers where the last IP address of the XFF header is the actual IP from
> the
> client that requested the page, image, etc.
>
> This is so to avoid spoofing, the last IP is the one added by the reverse
> proxy
> and the one that should be trusted.
>
> One way I could see this being fixed is by adding a configuration option in
> order for the XFF code to behave differently depending on the deployment,
> allowing the user to choose.
>
> Cheers,
> Duarte
>
> > >
> > > I have no idea why this is the case it would add that in but basically
> > > Suricata is taking the loopback as the overwrite address. Can I specify
> > > which which one to use? If not I will need to disable this which I
> would
> > > prefer not to until vendor responds :(
> > >
> > >
> > > Thanks,
> > > Kevin
> >
> > I am not sure I understand - could you give an example of a log entry
> > or something ?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20141030/255001f1/attachment-0005.html>