cloud-hosting-platform/haproxy-manager-base
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
186 Commits 3 Branches 0 Tags
b07278619215ea2443d8ecded511efcfc0b3aeea
Commit Graph
5 Commits
Author SHA1 Message Date
Claude b2f835a88c fix(logging): capture the full User-Agent, drop per-request SPOE log noise
HAProxy Manager Build and Push / Build-and-Push (push) Successful in 1m19s
Details 
Two defects caught by watching the real production access log on whp01 in the
minutes after 2026.08.7 made access logging work for the first time.

1. User-Agent was being truncated to its tail.

   `http-request capture req.hdr(User-Agent)` treats the header as a
   comma-separated list and returns only the LAST element. Real User-Agent
   strings contain commas, so

     Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
     (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

   logged as

     ua=like Gecko) Chrome/131.0.0.0 Safari/537.36

   losing the platform half -- exactly the half needed to tell a spoofed
   crawler from a real browser, which is one of the main reasons the field was
   added. Switched to req.fhdr(), which returns the full unsplit header value.

2. SPOE was writing one log line per inspected request.

   `log global` inside the spoe-agent block emitted

     SPOE: [coraza] <GROUP:coraza-req> sid=537 st=0 0/0/0/0/0 32/32 0/0 0/467

   for every single request. Measured on whp01: 618 SPOE lines against 669 real
   access lines -- ~48% of the log volume, roughly doubling the edge's log
   footprint (~400 MB/day extra) to record `st=0` over and over.

   It carries nothing incident response needs. The WAF verdict is already in
   the access line (status 403 plus the id= UUID, which joins to
   /var/log/coraza/audit.log for the rule_id), and per-transaction WAF detail
   is written by the SPOA itself to /var/log/coraza/spoa.log. Agent-level
   failures still surface through `option set-on-error error` ->
   var(txn.coraza.error) and the fail-open path in hap_listener.tpl.

Verified: scripts/validate-rendered-config.py passes `haproxy -c` on both the
"default" and "full" scenarios against the real 3.0.11 binary; wp-admin gate,
trusted-proxy gate and xmlrpc rate-limit suites all still pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-22 10:17:07 -07:00
shadowdao 47b9c87e1d coraza: pass var(txn.real_ip) instead of src to Coraza (real client IP in WAF logs) 2026-05-14 08:52:01 -07:00
shadowdaoandClaude Opus 4.7 ddb4c20073 fix(coraza-spoe): match upstream's required spoe shape (groups, arg order, names) 
Three real bugs in the SPOE config caught when HAProxy validated the
generated file:

1. spoe-agent must declare `groups` not `messages`. The `messages` form
   doesn't make the message reachable via `send-spoe-group`; HAProxy
   complained:
     unable to find SPOE group 'coraza-check' into SPOE engine 'coraza'

2. send-spoe-group references a spoe-GROUP name, which needs its own
   block. Added `spoe-group coraza-req { messages coraza-req }` as
   the indirection layer.

3. Arg names + ORDER are required to match what Coraza-SPOA parses
   positionally. My version had `dest-ip`/`dest-port`; upstream's
   example/haproxy/coraza.cfg (v0.7.1) uses `dst-ip`/`dst-port`.
   Renamed and reordered to match upstream verbatim, including the
   `app=str(haproxy)` literal that matches our config.yaml application
   name.

Also corrected misleading comment about `set-on-error continue`: that
option actually sets a variable on error; the fail-open behavior comes
from us deliberately NOT adding a `http-request deny if errored` rule
in the frontend. Renamed the variable to `error` (matching upstream)
and updated comments to be accurate.

Listener template's send-spoe-group action updated to reference the
new group name `coraza-req`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-12 17:12:09 -07:00
shadowdaoandClaude Opus 4.7 69bed61697 fix(coraza-spoe): collapse args to one line + ensure trailing LF on spoe cfg 
Two HAProxy parse errors caught in staging functional test:

1. coraza-spoe.cfg:39 'args': missing fetch method
   The args directive had backslash line continuations. HAProxy doesn't
   support those in SPOE configs — args must be one physical line.
   Collapsed to a single line.

2. coraza-spoe.cfg:50 Missing LF on last line
   Same trailing-LF issue we hit on haproxy.cfg one commit ago. The
   Jinja2 template ends with content rather than a newline, and write()
   doesn't add one. Belt-and-suspenders: explicitly append '\n' before
   writing if not already there.

After this commit HAProxy validates the generated config cleanly. Will
verify on staging now (combined SPOE injection + fail-open + active
attack-detection tests).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-12 17:07:12 -07:00
shadowdaoandClaude Opus 4.7 a89cdab886 PR 2/3: opt-in SPOE integration for Coraza WAF 
Adds the plumbing that lets haproxy-manager talk to the coraza-spoa sidecar
added in PR 1, while keeping the default behavior bit-identical for any
deployment that doesn't set the new env var (the home network / standalone
use cases).

Single gate: HAPROXY_CORAZA_SPOE_BACKEND env var on the haproxy-manager
container. Unset (default) = generate_config() renders zero SPOE-related
output. Set (e.g. "coraza-spoa:9000") = three things happen at config
generation time:

  1. hap_listener.tpl injects 5 lines at the end of the frontend block:
       filter spoe engine coraza config /etc/haproxy/coraza-spoe.cfg
       http-request send-spoe-group coraza coraza-check
     ...placed AFTER rate-limit and IP-block guards so we don't waste WAF
     calls on requests we were going to drop anyway.

  2. A new TCP backend (hap_coraza_spoa_backend.tpl) is appended:
       backend coraza-spoa-backend
           mode tcp
           server coraza-spoa <env-var-target> check ...

  3. The SPOE engine config (hap_coraza_spoe_engine.tpl) is rendered and
     written to /etc/haproxy/coraza-spoe.cfg, defining the spoe-agent
     "coraza" + spoe-message "coraza-check". This sets:
       - option set-on-error continue   (FAIL-OPEN if SPOA is unreachable)
       - timeout processing 100ms       (per-request inspection budget)
       - app=str(haproxy)               (matches sidecar's application name)

Verification (template render only, before staging deploy):
  - hap_listener.tpl with no env var: 55 lines, zero SPOE references
  - hap_listener.tpl with env var:    62 lines, filter + send-spoe-group present
  - Engine cfg + backend block render with correct agent_target substitution

Next: PR 3 wires this into WHP (sidecar deploy via container-manager.sh
extension, server-settings UI for on/off, AI Monitor source for the audit
log). Staging verification of PR 1 + PR 2 together happens after PR 3.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-12 16:49:29 -07:00