What minsec collects
The complete list of what an enrolled agent sends, and how long we keep it. It is short on purpose.
Multiplayer mode is opt-in on every agent. Without /etc/minsec/sync.toml the
daemon makes no network connections at all.
What agents send
One record per automatic ban:
| Field | Example | Notes |
|---|---|---|
ts | 1724371190 | when the ban fired |
ip | 203.0.113.7/32 | the attacker's network, IPv6 aggregated to /64 |
filter | sshd | the rule that matched — an opaque name, not free text |
count | 5 | matching hits inside the ban window |
ban_ttl | 3600 | your local ban length, in seconds |
escalation | 2 | repeat-offender depth for this attacker; omitted on a first ban |
Agents don't send log lines, usernames, hostnames, domain names, or anything about the protected system's users or traffic. Manual bans and unbans are not reported.
Alongside the reports we hold the agent's host_id (a random UUID we assign,
not derived from any hardware or network identifier), its public key, its version
string, and timestamps. host_id identifies an installation, not a person.
About the filter field
filter is the field that carries the most meaning, so it deserves its own
paragraph.
It names a detection rule, and rule names are chosen by whoever wrote the rule — either the built-in set that ships with minsec, or a local filter written by the operator. It is never derived from the traffic that matched. No URL, no user agent, no username and no payload ever leaves the agent.
This is what lets the abuse categorisation get more specific over time without
collecting more. A rule that detects exploitation of a particular vulnerability
reports a name like cve-2024-4577-php-cgi, and our signature registry maps that
name to a category and a CVE. The intelligence comes from the registry, which is
our data — not from anything extra taken off your server.
One consequence, if you write custom filters
A custom filter name is chosen locally and could in principle be distinctive to one installation. Reported names are never published — only the category they resolve to — and a name with no registry entry is excluded from every category-derived output, including the DNSBL. If you would still rather not send a particular rule's name, disable reporting for that filter.
What we store, and for how long
| Data | Retention | Why |
|---|---|---|
| raw reports | 30 days (daily partitions, dropped wholesale) | re-scoring, poisoning forensics |
| per-network reputation | 30 days after last activity; listed entries until delisted + 30 days | the product |
| per-network-per-category reputation | same | category-derived outputs |
| feed snapshots | 14 days | the delta protocol's horizon |
| agent enrollment source IP | 7 days, then nulled | enrollment abuse forensics only |
| agent record (host_id, pubkey, status, reputation) | life of the enrollment | authentication |
Retention is enforced by an automated daily job, not by intention. Those numbers are the defaults in the running configuration.
Reported addresses and the GDPR
The IP address of an attacking host can be personal data. Our position: processing is a legitimate interest — network and information security, GDPR Recital 49 — the data is minimal (a network and a rule name, no content), retention is short and enforced, and listings expire automatically after 48 hours unless the address is seen again. Allowlisted infrastructure — shared resolvers, CDN ranges, special-use space — is never published.
If you believe an address is wrongly listed, mail delist@minsec.io. Delisting takes
effect within a few minutes and removes the address from the
blocklist feed and the DNSBL together. You can check
any address yourself on the lookup page. If abuse reports continue
from the IP, it will be re-added, so it is recommended you solved the problem
on the host and then request delisting.
Publishing the DNSBL is a further purpose beyond operating the feed for
participants, and it carries a higher duty of care — a wrong entry bounces
someone's mail rather than dropping an attacker's packets. The mitigations are
structural rather than procedural: only /32 and IPv6 /64 entries are published,
unknown categories never are, listings expire on the same 48-hour TTL, and the
never-list is applied before the zone is rendered.
What the feed does not contain
Published feeds contain aggregated attacker networks and nothing else. Never which agents reported an address, never how many systems run minsec, never any per-reporter data.
Questions
delist@minsec.io for delisting, privacy@minsec.io for anything on this page.