cloud-hosting-platform/haproxy-manager-base
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
615044fa14fb7ff03969865e3662b40d6ac46bde
haproxy-manager-base/templates/hap_header.tpl

76 lines
2.5 KiB
Smarty
Raw Normal View History

Not fully working, but saving progress
2025-02-19 07:53:26 -08:00
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2
chroot /var/lib/haproxy
Fix resolvers block placement — must be outside global section The resolvers section was inserted inside the global section, causing HAProxy to parse global directives (pidfile, maxconn, etc.) as resolver keywords. Moved resolvers to its own top-level section between global and defaults where HAProxy expects it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-02 05:18:48 -07:00
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
# SSL and Performance
tune.ssl.default-dh-param 2048
Add DNS resolver for automatic container IP re-resolution When Docker containers restart, they can get new IPs on the bridge network. HAProxy caches DNS at config load time, so stale IPs cause 503s until config is regenerated. Added a 'docker_dns' resolvers section pointing to Docker's embedded DNS (127.0.0.11) with 10s hold time. Backend servers now use 'resolvers docker_dns init-addr last,libc,none' so HAProxy: - Re-resolves container names every 10 seconds - Falls back to last known IP if DNS is temporarily unavailable - Starts even if a backend can't be resolved yet (init-addr none) This eliminates 503s from container restarts, scaling, and recreation without requiring a HAProxy config regeneration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-01 22:27:07 -07:00
Fix resolvers block placement — must be outside global section The resolvers section was inserted inside the global section, causing HAProxy to parse global directives (pidfile, maxconn, etc.) as resolver keywords. Moved resolvers to its own top-level section between global and defaults where HAProxy expects it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-02 05:18:48 -07:00
# HTTP/2 protection against Rapid Reset (CVE-2023-44487) and stream abuse
tune.h2.fe.max-total-streams 2000
tune.h2.fe.glitches-threshold 50
# Stats persistence for zero-downtime reloads
stats-file /var/lib/haproxy/stats.dat
#---------------------------------------------------------------------
Add DNS resolver for automatic container IP re-resolution When Docker containers restart, they can get new IPs on the bridge network. HAProxy caches DNS at config load time, so stale IPs cause 503s until config is regenerated. Added a 'docker_dns' resolvers section pointing to Docker's embedded DNS (127.0.0.11) with 10s hold time. Backend servers now use 'resolvers docker_dns init-addr last,libc,none' so HAProxy: - Re-resolves container names every 10 seconds - Falls back to last known IP if DNS is temporarily unavailable - Starts even if a backend can't be resolved yet (init-addr none) This eliminates 503s from container restarts, scaling, and recreation without requiring a HAProxy config regeneration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-01 22:27:07 -07:00
# DNS resolver for Docker container name resolution
# Re-resolves backend server addresses so container IP changes
# (from restarts, recreations, scaling) are picked up automatically
Fix resolvers block placement — must be outside global section The resolvers section was inserted inside the global section, causing HAProxy to parse global directives (pidfile, maxconn, etc.) as resolver keywords. Moved resolvers to its own top-level section between global and defaults where HAProxy expects it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-02 05:18:48 -07:00
#---------------------------------------------------------------------
Add DNS resolver for automatic container IP re-resolution When Docker containers restart, they can get new IPs on the bridge network. HAProxy caches DNS at config load time, so stale IPs cause 503s until config is regenerated. Added a 'docker_dns' resolvers section pointing to Docker's embedded DNS (127.0.0.11) with 10s hold time. Backend servers now use 'resolvers docker_dns init-addr last,libc,none' so HAProxy: - Re-resolves container names every 10 seconds - Falls back to last known IP if DNS is temporarily unavailable - Starts even if a backend can't be resolved yet (init-addr none) This eliminates 503s from container restarts, scaling, and recreation without requiring a HAProxy config regeneration. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-01 22:27:07 -07:00
resolvers docker_dns
nameserver dns1 127.0.0.11:53
resolve_retries 3
timeout resolve 1s
timeout retry 1s
hold valid 10s
hold other 10s
hold refused 10s
hold nx 10s
hold timeout 10s
hold obsolete 10s
Not fully working, but saving progress
2025-02-19 07:53:26 -08:00
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor #except 127.0.0.0/8
option redispatch
retries 3
Add rate limiting, connection limits, and timeout hardening Activate HAProxy's built-in attack prevention to stop floods that cause the container to become unresponsive: - Stick table tracks per-IP: conn_cur, conn_rate, http_req_rate, http_err_rate - Rate limit rules: deny at 50 req/s, tarpit at 20 req/s, connection rate limit at 60/10s, concurrent connection cap at 100, error rate tarpit at 20 errors/30s - Harden timeouts: http-request 300s→30s, connect 120s→10s, client 10m→5m, keep-alive 120s→30s - HTTP/2 Rapid Reset protection (CVE-2023-44487): stream and glitch limits - Stats frontend on localhost:8404 for monitoring - HEALTHCHECK now validates both port 80 (HAProxy) and 8000 (API) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 10:00:53 -07:00
timeout http-request 30s
Not fully working, but saving progress
2025-02-19 07:53:26 -08:00
timeout queue 2m
Add rate limiting, connection limits, and timeout hardening Activate HAProxy's built-in attack prevention to stop floods that cause the container to become unresponsive: - Stick table tracks per-IP: conn_cur, conn_rate, http_req_rate, http_err_rate - Rate limit rules: deny at 50 req/s, tarpit at 20 req/s, connection rate limit at 60/10s, concurrent connection cap at 100, error rate tarpit at 20 errors/30s - Harden timeouts: http-request 300s→30s, connect 120s→10s, client 10m→5m, keep-alive 120s→30s - HTTP/2 Rapid Reset protection (CVE-2023-44487): stream and glitch limits - Stats frontend on localhost:8404 for monitoring - HEALTHCHECK now validates both port 80 (HAProxy) and 8000 (API) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 10:00:53 -07:00
timeout connect 10s
timeout client 5m
Not fully working, but saving progress
2025-02-19 07:53:26 -08:00
timeout server 10m
Add rate limiting, connection limits, and timeout hardening Activate HAProxy's built-in attack prevention to stop floods that cause the container to become unresponsive: - Stick table tracks per-IP: conn_cur, conn_rate, http_req_rate, http_err_rate - Rate limit rules: deny at 50 req/s, tarpit at 20 req/s, connection rate limit at 60/10s, concurrent connection cap at 100, error rate tarpit at 20 errors/30s - Harden timeouts: http-request 300s→30s, connect 120s→10s, client 10m→5m, keep-alive 120s→30s - HTTP/2 Rapid Reset protection (CVE-2023-44487): stream and glitch limits - Stats frontend on localhost:8404 for monitoring - HEALTHCHECK now validates both port 80 (HAProxy) and 8000 (API) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-31 10:00:53 -07:00
timeout http-keep-alive 30s
Not fully working, but saving progress
2025-02-19 07:53:26 -08:00
timeout check 10s
Implement progressive protection: tarpit → silent-drop → block - Set tarpit timeout to 10 seconds for initial offenders - Use silent-drop for obvious scanners (35+ errors) and repeat offenders - Silent-drop immediately closes connection without response - Keep 429 block for critical threats (50+ errors) Protection levels: - 10-19 errors: 10s tarpit - 20-34 errors: 10s tarpit (first), silent-drop (repeat) - 35-49 errors: silent-drop - 50+ errors: 429 block - Burst attacks: 10s tarpit (first), silent-drop (repeat) Updated monitoring script to show correct status based on new logic. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-25 06:42:09 -07:00
timeout tarpit 10s # Tarpit delay for low-level scanners (before silent-drop)
Fix Templates from causing errors with haproxy when added, Fix add notice when haproxy fails check
2025-02-21 06:28:51 -08:00
maxconn 3000
Reference in New Issue Copy Permalink