pmb
da4fa18525
The per-IP ban tracker treats every globally-routable client equally, but an aggregating front-end like the finger-web proxy funnels the whole internet's federated lookups through a single IP. A burst from any one client of the proxy (or a load test) is then attributed to the proxy's IP and, once it crosses the failure threshold, the daemon blocks the proxy — taking out finger lookups for everyone. Per-client abuse protection for the proxied path belongs in the proxy (which now rate-limits per real client IP), so the daemon should trust it. Add a FINGER_BAN_ALLOWLIST env var (comma-separated IPs). Allowlisted addresses are marked non-trackable in the listener, so their connections are never blocked and never recorded as offenses. Unset = unchanged behaviour. - parse_ip_allowlist() in ban.cpp (trims entries, skips blanks) + unit tests - listener() consults the set when computing 'trackable' - documented in docker-compose.yml and DOCKER.md
finger
A silly finger service written in c++20
Compiling:
meson setup builddir
meson compile -C builddir
This will create a static linked binary called builddir/finger. You can copy this to your remote server if you're going to run it via docker.
Building a Dockerfile
Create a Dockerfile with the contents:
# Use a minimal base image
FROM alpine:latest
# Copy the local binary to the container
COPY finger /usr/local/bin/finger
# Make the binary executable
RUN chmod +x /usr/local/bin/finger
# Create the directory for user data
RUN mkdir -p /var/finger/users
# Expose port 79 (finger protocol)
EXPOSE 79
# Set the binary as the default command
CMD ["finger"]
And execute docker build -t finger-app .
Running
Create a docker-compose.yml file:
version: '3.8'
services:
finger:
build: .
ports:
- "79:79"
volumes:
- ./users:/var/finger/users
restart: unless-stopped
and execute docker compose up -d
Setting your status
within the ./users directory, create a file named after the user you wish to have a response. That's it!
Abuse protection
Most traffic on port 79 is not finger at all -- HTTP and SIP probes, TLS
handshakes, and username-guessing scanners. None of these resolve to a plan
file, so the daemon treats any request that fails to read a plan as an
"offense" and timestamps it against the source IP. When an IP records more than
3 failures within a rolling 24-hour window, its connections are dropped
(without being read or answered) until those failures age back out of the
window. Legitimate lookups that hit a real plan never count against an IP. All
state is in-memory; thresholds live in BanTracker::Config (ban.hpp).