What the system-wide IP blacklist blocks

Most VICIdial IP controls are about letting the right people in. The system-wide blacklist is the opposite tool: it keeps the wrong addresses out, everywhere, all at once. If a single IP is hammering your login page or you spot a scraper, the blacklist is the blunt instrument you want.

What it actually blocks

The blacklist is a single IP List you point at from System Settings. Any address in that list is denied all web service access for every user on the system. It does not matter which User group a person belongs to, whether they're an admin or an Agent, or whether they have valid credentials. If the request comes from a blacklisted IP, it's refused.

Blacklist versus per-group whitelist

The per-group whitelists answer "who is allowed in for this group" and only restrict the surfaces you enable. The blacklist answers "who is banned outright" and applies to the whole system. They work together, but they're different in scope. Whitelisting is allow-by-default-deny; the blacklist is deny-everywhere, including for the agent and admin screens and the Non-agent API.

flowchart TD
  A[Web request arrives] --> B{Source IP on blacklist}
  B -->|Yes| C[Deny all web access]
  B -->|No| D[Continue to login]
  D --> E{Credentials valid}
  E -->|No| F[Reject login]
  E -->|Yes| G{Group whitelist allows IP}
  G -->|No| H[Block this surface]
  G -->|Yes| I[Allow access]

Setting it up

Like the rest of the IP List tooling, the blacklist only appears once you enable "Allow IP Lists" in System Settings. Build an IP List, mark it Active, add the offending addresses one per line, then select it as the system settings blacklist IP List. From that point the listed addresses are shut out of the whole system.

Warning: the block is broad on purpose, so be careful with shared or NAT addresses. If your whole office sits behind one public IP and you accidentally add it, you lock everyone out, agents and managers alike. Test from outside the listed range, and double-check the address before saving.

When to reach for it

The blacklist is best used as a fast, temporary response rather than a long-term firewall. If you spot repeated failed logins from one address or a script crawling your screens, drop that IP into the blacklist list and the requests stop reaching the application immediately. For ongoing protection of who is allowed in, the per-group whitelists are the better tool, because they describe your normal trusted networks instead of chasing bad actors one address at a time.

Review the list periodically. An IP you blocked during an incident months ago may now belong to a legitimate visitor or a recycled address, and a stale blacklist quietly creates support tickets nobody can explain. Treat it like a living document: add fast when you need to, and prune just as deliberately once the threat is gone.

Keep in mind that this is an application-level control, not a network firewall. It stops listed addresses from using the VICIdial web services, but it isn't a substitute for blocking abusive traffic at the server or carrier edge when an attack is large enough to matter.

The blacklist is part of the same access-control family as group whitelists and user permissions. The users and groups multi-team guide covers the whole picture, and if you're locking down automated access specifically, see how to set up an API-only user.

On a managed VICIfast box these settings are exposed in a clean admin over HTTPS from day one. Start a VICIfast trial and spin up a dedicated dialer in under 40 seconds.