From 3f51d6016ea1dc6c8d1a1c4caf4611edf90bc6e2 Mon Sep 17 00:00:00 2001 From: Jens Ahrensfeld Date: Sat, 25 Jul 2026 20:43:19 +0200 Subject: [PATCH] Add per-vhost CustomLog directives; document access-log root cause Real root cause turned out to differ from the original TODO: there was no broken global CustomLog, mod_vhost_combined was already logging every vhost without its own CustomLog into other_vhosts_access.log. Added a dedicated CustomLog per real site anyway for easier incident review, verified live with curl against all 7 domains after reload. Co-Authored-By: Claude Sonnet 5 --- README.md | 2 ++ TODO.md | 38 ++++++++++++++++++++++++-------------- 2 files changed, 26 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index 4b8855b..79ed9ca 100644 --- a/README.md +++ b/README.md @@ -380,3 +380,5 @@ that key file, not group membership, since the `bind` group also owns `rndc.key` — and (b) that access logging for every real vhost on this host is currently a no-op, and (c) that the dyndns app has no real per-user auth binding. (b) and (c) are left open — see `TODO.md`.) +(b) fixed 2026-07-25 — see `TODO.md` for the root cause and the +per-vhost `CustomLog` fix; (c) remains open. diff --git a/TODO.md b/TODO.md index dd0d113..0095656 100644 --- a/TODO.md +++ b/TODO.md @@ -16,22 +16,32 @@ Nothing here is urgent; all are low-risk, no-downtime changes. tokens, or add a static host-allowlist per `.htpasswd` user in the PHP. -- [ ] **dyndns/default-vhost access logging is a no-op** — found - 2026-07-20, while investigating the command injection below. +- [x] **dyndns/default-vhost access logging is a no-op** — done 2026-07-25 + found 2026-07-20 while investigating the command injection below. `dyndns.jayfield.org`, `jayfield.org`, `www.jayfield.org`, `mail.jayfield.org`, `web.jayfield.org`, and `cloud.jayfield.org` - have no `CustomLog` directive of their own, so requests to them - should fall back to the global `CustomLog ${APACHE_LOG_DIR}/access.log` - in `apache2.conf` — but that file had 0 lines when checked. Only - `default-ssl.conf`/`000-default.conf` explicitly set `CustomLog`. - Net effect: there's currently no access-log trail for any real - vhost on this host, which is exactly the evidence that would be - needed to rule out past abuse of things like the dyndns injection - above. Needs root-causing (global `CustomLog` not actually wired up - to these vhosts? logs going somewhere else? log rotation wiping it - right before checks?) and likely a per-vhost `CustomLog` added to - each site, matching the `default-ssl.conf`/`000-default.conf` - pattern. + had no `CustomLog` directive of their own, and `access.log` (only + written by `default-ssl.conf`/`000-default.conf`) had 0-8 lines — + looking like no real vhost was being logged at all. + Root cause (2026-07-25 re-check): the fallback assumption was wrong. + There's no global `CustomLog access.log` in `apache2.conf`; instead + `conf-enabled/other-vhosts-access-log.conf` enables `mod_vhost_combined`, + which was already writing every vhost-without-its-own-`CustomLog`'s + traffic to `/var/log/apache2/other_vhosts_access.log` (5,432 lines, + confirmed real traffic incl. bot scans against `cloud.jayfield.org`). + So requests were never actually un-logged — just commingled in one + shared, harder-to-grep file instead of `access.log`. + Fixed anyway, since a dedicated per-site log remains the better + end state for incident review: added an explicit + `CustomLog ${APACHE_LOG_DIR}/_access.log combined` to every + `` block for `dyndns`, `jayfield.org`, `www`, `mail`, + `web`, `cloud`, and `portainer` (the `:80` and `:443`/`le-ssl` blocks + of each site share one log file). Configs backed up to + `/root/removed-configs-backup/vhost-customlog-20260725203959/`. + `/etc/logrotate.d/apache2` already globs `*.log`, so no logrotate + change needed. Validated with `apache2ctl configtest`, applied via + `systemctl reload apache2`, verified live with `curl` against all 7 + domains and confirmed each new `_access.log` recorded the hit. - [x] **OS command injection in the dyndns update scripts** — done 2026-07-20 `/var/www/dyndns/nsupdate.php`, `nsupdate_ipv4.php`, and