A bit more digging:
It looks like this commit broke it:
http://git.haproxy.org/?p=haproxy-2.0.git;a=commitdiff;h=8ab2a364a8c8adf0965e74a41a2ff3cebd43e7a9
Re-adding the following block on line 2826 in cfgparse.c in 2.0.25 "solves"
the issue but I have no idea if that is the right thing to do:
- /* move any "block" rules at the beginning of the
http-request rules */
- if (!LIST_ISEMPTY(&curproxy->block_rules)) {
- /* insert block_rules into http_req_rules at
the beginning */
- curproxy->block_rules.p->n =
curproxy->http_req_rules.n;
- curproxy->http_req_rules.n->p = curproxy->block_rules.p;
- curproxy->block_rules.n->p =
&curproxy->http_req_rules;
- curproxy->http_req_rules.n = curproxy->block_rules.n;
- LIST_INIT(&curproxy->block_rules);
- }
Thanks
Bart
On Thu, Nov 18, 2021 at 5:47 PM Bart van der Schans <[email protected]>
wrote:
> Hi good folks!
>
> We ran into an issue with 2.0.25 that it ignores the "block" (deprecated
> but still valid) statement. The following works in 2.0.24 but not in 2.0.25:
>
> frontend http-in
> bind :80
> mode http
> log global
> // snip, all the usual stuff
>
> # block any unwanted source IP addresses or networks
> acl forbidden_src src 127.0.0.1
> block if forbidden_src
>
> With 2.0.24 as expected:
> $ curl http://localhost/adsf
> <html><body><h1>403 Forbidden</h1>
> Request forbidden by administrative rules.
> </body></html>
>
> With 2.0.25 (503 because no real backend in my test setup):
> $ curl http://localhost/adsf
> <html><body><h1>503 Service Unavailable</h1>
> No server is available to handle this request.
> </body></html>
>
> Wondering if I'm missing something or if this is a security issue. For now
> we are have quickly "patched" our prod servers by replacing "block" with
> "http-request deny" which does show the correct behavior.
>
> Any comments or suggestions?
>
> Thanks
> Bart
>
>
