Block abusive IPs

How to use SGEN's IP blacklist to block spam, bots, and bad actors

The Blacklist is a single admin page where you add IP addresses you want blocked from your site. Once a rule is saved, the next time someone from that IP tries to reach your site, they are redirected away automatically. This walkthrough covers the everyday cases — blocking a spam source, blocking a range of bad actors, and checking whether a specific IP is currently blocked — and one pattern that will lock you out of your own site if you are not careful.

Before you do anything, read the first anti-pattern below. There is one specific input that will block every visitor including yourself, with no way to recover from the admin UI. Know what it looks like before you start typing.

What is this for?

The Blacklist page is where you tell SGEN, "never let this IP reach my site." It is a response tool, not a prevention tool — you use it after you have identified a source of abuse (a bot hammering your contact form, a scraper that keeps returning, a botnet range you noticed in your server logs). It blocks by source IP address only — there is no filter by email, user agent, country, referrer, or keyword.

Good use cases

Example 1: A bot is hammering your contact form with spam. You check your server logs or Discussions spam queue and notice 200+ submissions over the last hour from 198.51.100.42. Open /sg-admin/blacklist/ and add that IP as a new entry. Note the ticket number in the Reason field so you remember why later:

The next time a request arrives from that IP, the hit counter increments and the visitor is bounced away before your contact form ever loads.

Example 2: Several bad actors are coming from the same range. Rather than entering 50 individual IPs, use CIDR notation to block the whole range in one entry. 198.51.100.0/24 covers 256 addresses (198.51.100.0 through 198.51.100.255). You can also use IPv4 wildcards like 198.51.100.* for the same effect. After a few matches the list looks like this:

Each row shows a live Hits counter that increments every time a visitor from that IP is blocked. That is the fastest way to tell which rules are doing real work and which are stale.

Example 3: A known attacker is coming from IPv6. The Entry field accepts IPv6 single addresses (2001:db8::1) and IPv6 CIDR (2001:db8::/32) the same way it accepts IPv4. The validator recognizes both families.

What NOT to use this for

**1. Never enter ..., 0.0.0.0/0, or ::/0.**

These three patterns match every IP address. Saving any of them will block every visitor to your site, including you, starting on the next page load — there is no admin bypass, no whitelist, no safe mode. Your admin session becomes irrelevant because the block runs before the session check. Recovery requires direct database access (which most customers do not have without opening a support ticket).

If you are tempted to "test the validator by entering a wildcard," stop. The validator currently accepts all four of these patterns. The wildcard help text under the Entry field lists 192.168.. as a legitimate example — and that is fine — but four stars in a row is not. This is behavior to know, not a bug to experiment with.

If you are migrating a blacklist from another platform, audit every row before pasting. A single overly-broad CIDR is enough to take you offline.

2. Do not blacklist your own current IP.

You and your visitors often share an IP, especially in offices behind a single firewall or on mobile carrier networks. Blocking a visitor's IP blocks anyone else on the same network — including you if you are sitting there. Before you add any entry, confirm what you are blocking. Open a second browser tab, visit https://api.ipify.org, and make sure your own public IP does not match the rule you are about to save.

3. Do not rely on IP blocking as long-term anti-abuse.

Attackers rotate IPs constantly. VPNs, proxies, residential botnets, Tor exit nodes — a motivated attacker will rotate faster than you can keep up. A small handful of Blacklist entries will stop lazy or one-off abuse. If your list is growing past 100 active entries and abuse is still ongoing, you need different tooling — a WAF (Cloudflare, AWS WAF), rate limiting at the edge, or captcha on your forms. The Blacklist is a scalpel, not a shield.

4. Do not block an entire residential ISP range.

Home ISPs recycle IPs across customers every few days. A residential /16 can include tens of thousands of legitimate users. Blocking that wide will catch innocent visitors mixed in with the one bad actor you saw. Use /24 or narrower when the abuser is on residential, and prefer exact IPs for anything under a dozen bad addresses.

5. Do not assume blocked visitors see a friendly "you are blocked" page.

Blocked visitors are currently redirected to https://www.google.com/. That means the visitor lands on Google, not on a page that explains what happened. Some people will think your site is down or their DNS is misconfigured. They will not see an error, they will not understand that they have been intentionally blocked, and they have no way to appeal. If a visitor complains that your site is sending them to Google, check the Blacklist first.

Before you start

• You are signed in as an admin with access to the Blacklist.
• You know the exact IP address, CIDR range, or wildcard you intend to block.
• You have confirmed that IP is not your own and is not shared with any legitimate visitor you care about.

Where to go

1. Open the left navigation.
2. Select Blacklist. You land on /sg-admin/blacklist/.

That is it — the whole feature is a single page. The left card is the add/edit form; the right card is the list of existing entries with the bulk-action toolbar, search, and Test IP tool above it.

Steps to add a block

1. Enter the IP, CIDR, or wildcard

Type the source you want to block into the Entry field. The validator accepts:

2. Fill in the reason

The Reason field is optional but you should always use it. Include the ticket number, the log line that flagged the IP, and the date. You will thank yourself in six months when you are cleaning up stale rules and cannot remember why a particular range is blocked.

3. Click Blacklist item

You land back on the list view with a green success banner. Your new entry appears in the table with a Hits column at 0.

Check whether a specific IP is currently blocked

Above the list there is a Test IP tool. Paste any IP and click Test — the admin page tells you whether any rule currently matches, and if so which rule.

This is the fastest way to handle the most common support question: "a visitor says they cannot reach my site — is it me blocking them?" Paste their IP, hit Test, and you have your answer without opening the database.

Edit or remove an entry

To change the Reason on a row (e.g., link a new ticket number), click Edit on the row. The left card switches to update mode with the entry prefilled:

Edits preserve the Hits counter, the date the entry was created, and the author attribution. If you change the Entry field itself, that is effectively a new rule — if the new value matches different visitors, their traffic starts getting blocked on the next request.

To remove entries, either click Delete on a single row (with confirmation) or tick the checkboxes for multiple rows and use the bulk dropdown:

The only bulk action available today is Delete — there is no "pause" or "disable" state. A Blacklist entry either exists (blocks the IP) or it does not (allows the IP). To stop blocking, delete the entry.

What success looks like

• Your new entry appears at the top of the list with a Hits counter at 0.
• The next time a visitor matches, the Hits counter increments and Last Matched updates.
• The Test IP tool, with the blocked IP pasted in, returns a green "is blacklisted by ..." banner.

What to do if it does not work

• Hits stays at 0 for days. Either no real traffic matches your rule (abuse has moved elsewhere — consider deleting), or your rule is too narrow (paste a specific IP you know should match into Test IP; if Test says "not blacklisted", the rule is not what you think it is).
• A legitimate visitor is complaining they cannot reach the site. Paste their IP into Test IP. If it matches a rule, you have a false positive — delete or narrow that rule.
• You locked yourself out. If you entered a match-all wildcard or a CIDR that includes your own IP, the admin page is unreachable. Contact support with your account details and the time of the change. Recovery is database-level; there is no self-service path.

How this connects to other features

• Redirects — similar admin surface, different concern. Redirects match URLs and send visitors elsewhere; Blacklist matches source IPs and blocks visitors entirely. If you want to block based on URL pattern, use Redirects. If you want to block based on visitor IP, use Blacklist.
• Forms and Discussions — where most of the abuse you will want to block actually shows up. When you see a surge of form spam or comment flooding, check the source IPs there first, then add the worst offenders here. Blacklist is reactive; use it after identifying the source, not speculatively.

Next steps

• Audit your list monthly. Delete entries with Hits at 0 for more than 30 days — abusers have moved on and the rule is taking up space.
• Document your Reason field practice. Future-you and any teammate who inherits the admin will need context. A Reason field of "ticket #1289, form spam, 2026-04-21" takes ten seconds to write and saves hours of archaeology later.
• If your list is growing past a few dozen active entries, escalate to your ops or platform team. The Blacklist is meant to be a small, targeted list — large lists indicate a problem this tool is not designed to solve.