TrueAbuse

From a line in your log to a complaint on someone's desk.

Seven stages. Four of them exist to stop a report going out when it should not, which is why they are worth describing rather than hiding behind the word automatic.

  1. The agent sees it

    It follows the logs your existing tools already write — fail2ban, ModSecurity, rspamd, Postfix, or a file and a pattern you supply. It keeps its place across a restart and across a rotation, so a redeployed host does not report last week all over again.

  2. It travels signed

    Every request carries a signature over its timestamp, a single-use nonce, the method, the path and a hash of the body. A replayed request is refused, and each host has its own key, so a machine that is compromised can speak for itself and for nothing else in your fleet. If the console is unreachable the agent spools to disk and sends later.

  3. Repeats join what is already filed

    One address trying four hundred passwords overnight is one complaint, with the count and the window on it. Inside the deduplication window the same address and the same kind of attack land on the report that already exists.

  4. We work out who to tell

    The address is looked up at the regional registry over RDAP, falling back to WHOIS where RDAP is not served, to find the network that holds it and the address they publish for complaints. Answers are cached, so a busy night is not a thousand lookups.

  5. We check the attack can be pinned to the address

    A ban from fail2ban or a connection logged by Postfix came from the connection itself. A web firewall reading the client address out of a request header did not — that is whatever the sender wrote there. Unless a proxy you actually run rewrote the header, the report is held: it is visible to you, and nothing is sent.

  6. It goes out under your name

    One report, with your organisation on it and your reply address, quoting the evidence rather than summarising it. Nothing in it describes how it was delivered.

  7. We watch what comes back

    A hard bounce or a complaint puts that contact on your suppression list rather than into a retry loop. If too many reports bounce, sending pauses itself and the account owner is told why — because an abuse desk that stops reading you is worse than a report that went out a day late.

What you do once

Register the host in the portal, run the installer it hands you, and point it at the logs if they are somewhere unusual. There is no agent to upgrade on a schedule and no daemon to supervise beyond the one service file. 

# copy the agent to the host and run its installer
scp -r agent/ root@host:/opt/trueabuse-agent
ssh root@host 'cd /opt/trueabuse-agent && ./install.sh'

# put in the key and secret the portal showed you, then check
ssh root@host 'vi /etc/trueabuse/agent.env && trueabuse-agent check'
ssh root@host 'systemctl enable --now trueabuse-agent'

# and tell fail2ban to report the jails you care about
# /etc/fail2ban/jail.local
#   action = %(action_)s
#            trueabuse
trueabuse-agent check tells you whether the key works, the clock is close enough and the logs are readable, before you enable anything. Sources it did not find can be added later in /etc/trueabuse/sources.conf.

Start with one server

Whatever your firewall catches tonight is a complaint that gets filed by morning.

Open the portal What leaves your machine