BlazeBans/Investigating

Alts and IP tools

Finding accounts that belong to the same person, and punishing the address rather than the account. All of it depends on IP storage, which is off by default.

Turning it on

In settings.yml:

yaml
privacy:
  # Store player IP information for alt/IP matching.
  store-ip-addresses: false

  # Hash stored IPs with BlazeBans' local salt.
  hash-ip-addresses: true

  # Allow staff with blazebans.see.ips to see live IPs in lookup output.
  show-ip-to-staff: false

  # Player names exempt from alt lookups.
  alts-blacklist: []

store-ip-addresses is the master switch. With it off, /alts finds nothing, IP bans have nothing to match, and ban evasion detection cannot work. That is the default because storing player IPs is a decision you should make deliberately rather than inherit.

hash-ip-addresses should stay on. With it on, BlazeBans stores a scrambled form of the address rather than the address itself. It can still tell that two accounts came from the same place, which is all alt detection needs, but nobody reading your database can turn the stored value back into a real address. Alt matching and IP punishments work exactly the same either way, so the only thing this changes is how damaging a database leak would be.

show-ip-to-staff controls whether staff holding blazebans.see.ips can see actual addresses in lookup output. Leave it off unless you have a specific reason, and grant the node narrowly when you turn it on.

Finding linked accounts

minecraft
/alts <player>

Lists accounts sharing a stored IP with this one. Needs blazebans.command.alts.

Each entry shows the account name, whether it is online, and whether it is currently banned or muted, with a summary of how many of the linked accounts are punished. Hovering an entry shows a short history preview.

Staff with blazebans.alts.details see the full detail view. Without it, they get a summary: enough to know the account has links worth escalating, without handing every moderator a full picture of who plays with whom.

What counts as linked

A shared stored IP, and nothing else. That is a strong signal and not a proof. Two people in the same house, on the same school network, or behind the same VPN exit share an address without sharing an owner.

Treat an alt list as a reason to look closer, not as a verdict. It is evidence for a decision, not the decision.

Keeping people out of alt lookups

Two ways:

yaml
privacy:
  alts-blacklist:
    - "SomePlayer"

Or grant blazebans.alts.exempt, which does the same thing without a config entry.

Either way, /alts on that player is refused and they do not appear in anyone else's list. Use it for staff accounts, for players with a documented reason, and for anyone whose household you should not be mapping.

IP punishments

minecraft
/ipban <player> [duration] [reason] [flags]
/ipmute <player> [duration] [reason] [flags]

These store IP_BAN and IP_MUTE records that match on the stored address as well as the account, so a new account on that address is caught by the existing record.

They need blazebans.command.ipban and blazebans.command.ipmute. Give them to senior staff. An IP ban can catch a sibling, a housemate, or an entire dormitory, and the person it catches has no idea why.

The --ip flag on /ban and /mute does the same thing:

minecraft
/ban Steve 30d Cheating --ip

It needs blazebans.ip. The separate commands are usually clearer for staff and easier to gate.

Automatic ban evasion

BlazeBans can ban a joining account when another account on the same stored IP already has an active ban:

yaml
punishments:
  ban-evasion:
    enabled: false
    duration: "permanent"
    reason: "Ban evasion"
    silent: false

Off by default. Full detail in Ban evasion.

Permissions

NodeGrants
blazebans.command.altsRunning /alts
blazebans.alts.detailsThe full alt view rather than a summary
blazebans.alts.exemptNot appearing in alt lookups
blazebans.command.ipbanRunning /ipban
blazebans.command.ipmuteRunning /ipmute
blazebans.ipThe --ip flag, and the IP toggle in the punish GUI
blazebans.see.ipsSeeing real addresses, when show-ip-to-staff is on

Handling this responsibly

IP data is personal data in most jurisdictions, including under the GDPR. A few things worth deciding before you turn storage on:

  • Say so. Put it in your rules or privacy notice. Players are entitled to know what you keep.
  • Keep hashing on. A hashed store still does everything you need it to and is far less damaging if your database is exposed.
  • Grant blazebans.see.ips narrowly. Most moderation needs "these accounts are linked", not the address itself.
  • Exempt people who need it. Staff, and anyone whose living situation should not be mapped by volunteers.
  • Be careful with IP bans. Prefer an account ban plus ban evasion detection, which reacts to the specific behaviour rather than pre-emptively closing an address.