Initial version: npm-scanner image, filters, entrypoint, watcher, testbed

- Image based on crazymax/fail2ban:1.1.1 with inotify-tools
- Filters npm-scanner and npm-wplogin, tested with fail2ban-regex in the build
- jail.local generated from .env, optional npm-wplogin and recidive
- Watcher reloads the jails when NPM creates a new proxy host log
- check command, docs, testbed for LXC

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

SECURITY.md

@@ -0,0 +1,34 @@
+# Security
+
+## Reporting a vulnerability
+
+Please do **not** open a public issue. Send a description and, if possible, steps to
+reproduce to the maintainer via a private message on
+[git.retronerd.at](https://git.retronerd.at/schiwagoa). You will get an answer within a
+few days; fixes are released as soon as possible and mentioned in the changelog.
+
+## Security model
+
+fail2ban has to change the firewall of the host, so this container is **not** isolated
+like a normal service:
+
+| Right | Why |
+|---|---|
+| `network_mode: host` | rules must land in the host's `DOCKER-USER` / `INPUT` chains |
+| `NET_ADMIN`, `NET_RAW` | needed by iptables / nftables |
+| runs as root inside the container | required by fail2ban and iptables |
+
+Limits:
+
+- No ports are opened; the container only reads logs and changes firewall rules.
+- NPM logs are mounted **read-only**.
+- `.env` values end up in `jail.local`; the entrypoint rejects characters outside
+  IP/network/host-name syntax in `WHITELIST` and validates all numbers and durations.
+- Anyone who can run `docker exec` on the host can ban or unban any IP – that is the same
+  as root on the host anyway.
+
+Recommendations:
+
+- Always set `WHITELIST` (own public IP, LAN, VPN, monitoring).
+- Keep `.env` at mode `600`.
+- Pull the image regularly – it follows the `crazymax/fail2ban` releases.