Hi Ionel,
> On 8 Dec 2023, at 17:28, Ionel GARDAIS <ionel.gard...@tech-advantage.com>
> wrote:
>
>
> Hi all,
>
> Regarding a public facing haproxy, what would you recommend about headers
> like X-Forwarded-* and Forwarded ?
> Delete them with http-request del-header ?
> Replace them with http-request set-header ?
Always delete, or replace. You have to be careful to *never* only append.
Otherwise the client sends X-Forwarded-For: foo, and your backend sees
X-Forwarded-For: foo, 1.2.3.4
In that case your backend would likely (wrongfully) decide the client ip is «
foo » (or whatever IP the client puts).
So typically I’d say to add to every single http frontend:
http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Host %[hdr(Host)]
http-request set-header X-Forwarded-Proto %[ssl_fc,iif(https,http)]
http-request set-header Forwarded
"by=${HOSTNAME};for=%[src];host=%[hdr(Host)];proto=%[ssl_fc,iif(https,http)]"
Another one to be careful with is the difference between hdr(…) and fhdr(…).
The first one splits on ",", which can give surprising results sometimes.
Finally, you might want to deny requests with a Via header. This typically
indicates usage of a proxy. Maybe your clients legitimately use those, but more
often than not this is just abuse of compromised routers for DoS attacks (at
least in our case, it is).
>
> Do the options forwardfor and forwarded behave like a set-header or a
> add-header directive ?
If I remember correctly, the baked-in directives work by *appending*, so
they’re only ok for intermediate proxies, not for edge ones.
Tristan
