Project

General

Profile

Actions
Copy link

Feature #4394

closed

HAproxy and use ACLs from UI to perform a "block"/"http-request deny"

Added by Stéphane Lapie about 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
haproxy
Target version:
-
Start date:
02/08/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:

Description

HAproxy currently allows to define ACLs to redirect to specific backends, and to define several frontend -> backend relationships.
When no ACL is matched, HAproxy comes to the conclusion "503 no server is available", which for most purposes is quite fine, but a bit misleading as in most cases people would expect a "403 Forbidden"

It is possible to include custom frontend configuration, but only "before" UI-generated ACLs are declared, so it is not possible to reference them (not to mention the ACL numbers and names might change), so it is not possible to do things like :

# UI-Generated code
acl 1_AllowedClient    src -f /var/etc/haproxy/ipalias_Clients.lst
http-request deny if ! 1_AllowedClient

I could certainly declare custom pass-through configuration :

acl custom_allowed_client src -f /var/etc/haproxy/ipalias_Clients.lst
http-request deny if ! custom_allowed_client
# UI Generated ACLs
# ...

However, then, I run the risk of the file name not being correct anymore once I change the firewall aliases, and I have to modify it in two places.

What I would propose is to allow for a given collection of ACLs, to choose several courses of action :
  • use_backend <configuredBackEnd> if ...
  • http-request allow if ...
  • http-request deny if ...
  • http-request tarpit if ...

This would make the UI considerably more complex, but I think it would allow for proper error codes when building proxies, and be quite valuable to make the HAproxy package feature complete.

Actions
Copy link

Also available in: Atom PDF