Route attacker-check reports to root@jayfield.org, add dated archive

root@jayfield.org didn't resolve to anything (missing from both
/etc/aliases and vmail.aliases) - added it as a new alias to
jens@jayfield.org, matching the existing postmaster/hostmaster/
webmaster/wlan pattern, so the weekly report doesn't just bounce.
Also added per-run dated report files under
/var/log/attacker-check/reports/ alongside the existing CSVs, for a
plain-text historical archive browsable by date.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-26 14:45:08 +02:00
co-authored by Claude Sonnet 5
parent 24d634c27f
commit 628f75303e
2 changed files with 20 additions and 1 deletions
+9 -1
View File
@@ -66,13 +66,21 @@ routine pending package upgrades, don't fail the run).
history to cover a full week regardless of exactly when logrotate's daily history to cover a full week regardless of exactly when logrotate's daily
midnight run lands relative to the cron job) for the past 7 days and midnight run lands relative to the cron job) for the past 7 days and
turns it into two append-only CSVs for longitudinal analysis, plus a turns it into two append-only CSVs for longitudinal analysis, plus a
human-readable weekly summary emailed to `jens@jayfield.org`: human-readable weekly summary emailed to `root@jayfield.org` and saved
as a dated report file:
- `/var/log/attacker-check/per_ip_weekly.csv` — one row per (jail, IP) - `/var/log/attacker-check/per_ip_weekly.csv` — one row per (jail, IP)
per week: event count, first/last seen, `/24` subnet, and interval per week: event count, first/last seen, `/24` subnet, and interval
statistics (mean, stdev) between repeat hits. statistics (mean, stdev) between repeat hits.
- `/var/log/attacker-check/per_jail_weekly.csv` — weekly rollup per jail: - `/var/log/attacker-check/per_jail_weekly.csv` — weekly rollup per jail:
total events, distinct IPs, distinct `/24`s, new bans. total events, distinct IPs, distinct `/24`s, new bans.
- `/var/log/attacker-check/reports/<week-ending-date>.txt` — the full
human-readable report for that run, one file per date.
`root@jayfield.org` didn't resolve to anything before this (not in
`/etc/aliases`, not in the `vmail` aliases table) — added it as a new
`vmail.aliases` row → `jens@jayfield.org`, matching the existing
`postmaster`/`hostmaster`/`webmaster`/`wlan` pattern.
Two detection heuristics run on top of the raw data, both modeled Two detection heuristics run on top of the raw data, both modeled
directly on real campaigns found earlier this engagement (see `TODO.md`): directly on real campaigns found earlier this engagement (see `TODO.md`):
+11
View File
@@ -3,6 +3,17 @@
Outstanding hardening items (see `README.md` for the full service overview). Outstanding hardening items (see `README.md` for the full service overview).
Nothing here is urgent; all are low-risk, no-downtime changes. Nothing here is urgent; all are low-risk, no-downtime changes.
- [x] **Weekly attacker-summary report routing to `root@jayfield.org`** — done 2026-07-26.
`attacker-check.py`'s report email was pointed at `root@jayfield.org`, but that address
didn't resolve to anything (not in `/etc/aliases`, not in `vmail.aliases`) — would have
bounced every week. Added it as a new `vmail.aliases` row → `jens@jayfield.org`, matching
the existing `postmaster`/`hostmaster`/`webmaster`/`wlan` pattern. Also added per-run
dated report files (`/var/log/attacker-check/reports/<date>.txt`), alongside the two
existing append-only CSVs. Verified: `postmap -q root@jayfield.org
mysql:/etc/postfix/sql/aliases.cf` resolves correctly, a live re-run delivered to
`jens@jayfield.org` (`orig_to=<root@jayfield.org>` in the Postfix log) and wrote
`reports/2026-07-26.txt`.
- [x] **BIND's own DNSSEC validation was broadly broken for signed domains** — found and fixed 2026-07-26 - [x] **BIND's own DNSSEC validation was broadly broken for signed domains** — found and fixed 2026-07-26
while investigating why third-party apt repos (`download.docker.com`, `ppa.launchpad.net`) kept while investigating why third-party apt repos (`download.docker.com`, `ppa.launchpad.net`) kept
failing to resolve ("Temporary failure resolving") during prep for an OS release upgrade. failing to resolve ("Temporary failure resolving") during prep for an OS release upgrade.