Based on this post, haproxy has provided mitigation acls rules that can be used to help fight against log4j attack requests getting proxied to the affected log4j apps.
In reading some of the users comments, It came to my attention that many Enterprise Linux Haproxy system out there might be running an older haproxy version 1.5 which doesn't have the option http-buffer-request directive. This directive is critical to any CVE you are trying to mitigate, even more so if this is your only option until you can upgrade the affected applications.
what is the easiest way to upgrade and to what version?
Answering my own question...
Haproxy 1.6 is needed, however RH provides haproxy 1.8 from the RHSCL repo
Make sure these repos are active on the system and install haproxy1.8
subscription-manager repos --enable=rhel-7-server-optional-rpms --enable=rhel-7-server-rpms --enable=rhel-server-rhscl-7-rpms
yum install -y rh-haproxy18.x86_64
cat the current config into the 1.8 cfg file and run a quick test config
cat /etc/haproxy/haproxy.cfg > /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
/opt/rh/rh-haproxy18/root/usr/sbin/haproxy -c -V -f /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
^ correct any warns or alert errors, In my experience, its mainly directive order or check port strings on your backend services. this is relatively simple to search the net for and correct
nano /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg
Add the ACLS Rules, use unique names if using more than one listener/frontend in the cfg so they don't overlap
systemctl disable --now haproxy && systemctl enable --now rh-haproxy18-haproxy
yum remove -y haproxy && yum install -y rh-haproxy18-haproxy-syspaths.x86_64
^ the rh-haproxy18-haproxy-syspaths.x86_64 package replaced the haproxy service name so you do not have to update the systemctl scripts or even keepalived if you are using it to monitor haproxy service
I use this within keepalived which works before and after
killall -0 haproxy
