TCP Shield

Resell TCPShield DDoS protection for Minecraft, with a self-service panel where clients run their own domains, backends, Bedrock tunnels, and firewall rules.

What it does

A Minecraft server is an easy DDoS target, and most hosts either build their own protection or leave clients to sort it out themselves. The TCP Shield module orders a protected TCPShield network the moment a client's service goes active, then gives them a full self-service panel to manage it - so protection is live at checkout and your support team isn't the one configuring DNS records for every order.

Key features

• Automatic Network Provisioning: A paid order creates the client's TCPShield network and stores its protected CNAME against the service, so protection is live the moment they pay.
• Guided Client Onboarding: The Domains tab walks a new client through their protected CNAME, the RealIP plugin download, and the exact DNS records to create, so they get protected without opening a support ticket.
• Domain Verification: Clients add, edit, and remove their own domains, assign each to a backend set, and prove ownership through a guided TXT-record verification flow built into the tab.
• Backend & Bedrock Management: Clients manage their own backend sets and Bedrock tunnels, so they can repoint traffic themselves whenever their servers move.
• Firewall Rules: Clients add and remove CIDR firewall rules with a whitelist toggle, keeping unwanted networks away from their servers.
• Player & Bandwidth Statistics: Charted player counts and bandwidth over the last 24 hours, 2 days, or 7 days, so both you and your client can see their traffic.
• Staff Mirror of Every Tab: Your team gets the same Domains, Backends, Bedrock, Firewall, and Statistics tabs on the staff side, so support can fix a client's setup for them without leaving Blesta.
• Per-Package Limits & Mock API Mode: Cap how many domains and backend sets a package allows, and try the whole module end to end with bundled sample data before you ever enter a TCPShield API key.

Installing TCP Shield

Before you start

• Version 3.x requires Blesta 6.0 or later. On a Blesta 5 install, use version 2.x instead.
• If you are on the leased (subscription) licence, the Blesta Club Subscription Manager must be installed and your subscription active. The owned and owned-source licences have no such requirement.
• You will need a TCPShield API key from your TCPShield account. If you just want to try the module out first, you don't need one at all - a built-in Mock API mode lets you test every screen with bundled sample data instead of a live account.

1. Upload the files

Upload the extension folder into your Blesta installation so it lands under your Blesta directory at:

components/modules/tcp_shield/

For example, on a typical install: /var/www/html/blesta/components/modules/tcp_shield/

2. Install it in Blesta

1. Log in to your Blesta admin area with a staff account that has the Modules permission (under Settings in Manage Staff Groups), including its Install Module sub-permission.
2. Go to Settings > Company > Modules and click the Available tab.
3. Find TCP Shield in the list and click Install.

3. Configure it

1. Go to Settings > Company > Modules, find TCP Shield in the Installed list, and click Manage.
2. Click Add Account to add a TCPShield account:
   • Enter a Network Name Prefix - this is prepended to every network TCP Shield creates for a client, so one TCPShield account stays tidy across many customers.
   • Enter your TCPShield API Key. If you want to test or demo the module first, leave the key blank and tick Mock API instead - every request is then served from bundled sample data and nothing is created or changed at TCPShield.
   • Save the account.
3. Create or edit a package that uses the TCP Shield module and this account. On its Module tab you can optionally cap the Maximum Domains and Maximum Backend Sets a client on this package may add - leave either blank or 0 for unlimited.

You're ready to go - see the usage guide for a walkthrough of day-to-day use.

Updating TCP Shield

Upgrading works just like installing: upload the new files over the old ones, then run the upgrade from the same page you installed it on.

1. Back up your current extension files first - good practice before any upgrade.
2. Upload the new version over the existing folder, replacing the old files.
3. Log in to your Blesta admin area and go to Settings > Company > Modules.
4. Find TCP Shield and click Upgrade to run the upgrade.

Version-specific notes

• v3.0.0: Requires Blesta 6.0 or later - upgrade Blesta first, then the module. Blesta 5 installs should stay on 2.x. Nothing changes in your accounts, packages or services; the staff screens take on the Blesta 6 admin theme (light and dark), the Edit and Delete links on the account list become buttons, the Add/Edit Account forms gain a Back button, and a delete in the staff Domains, Backends, Bedrock Backends and Firewall tabs confirms with the Blesta 6 dialog. The client area is unchanged.
• v2.0.0: Re-save each TCPShield account after upgrading. Earlier versions stored the account API key in plain text and used it as the account's display key; both are fixed on save, but an existing account keeps its plaintext key until it is saved again. The Network ID field is now admin-only and no longer accepted from a client order or service edit. Staff also get a full mirror of the client's Domains, Backends, Bedrock Backends, Firewall, and Statistics tabs on the service page, and packages can optionally cap how many domains and backend sets a client may add - both appear automatically, there is nothing to enable.
• v1.1.0: A new Mock API checkbox is available on each account for testing and demos. Account API keys are now stored encrypted and masked on the manage page - this happens automatically the next time you save an account, nothing to do beforehand.

This upgrade is otherwise drop-in - no data migration is required for any of the above.

Using TCP Shield

For your staff

Managing TCP Shield accounts

Go to Settings > Company > Modules, open TCP Shield's Manage page, and you'll see your Accounts table (each one a TCPShield API key and its Network Name Prefix, or a Mock API account for testing) and any Account Groups you've created to pool multiple accounts together. Click the pencil button next to an account to change its name prefix, replace its API key, or toggle Mock API - leaving the API Key field blank on save keeps whatever key is already stored, it is never cleared by accident - and the trash button to remove it after a confirmation. Click Add Account to add another one; both account forms have a Back button that returns you to this list.

Setting up a package

On a package that uses the TCP Shield module, its Module tab lets you optionally set Maximum Domains and Maximum Backend Sets - the number of each a client on this package may add themselves. Leave either blank or 0 for unlimited.

What happens when a service is ordered

The moment a service goes active, Blesta creates the client's network at TCPShield and stores its Network ID, Name, and Protected CNAME on the service - these three fields appear on the service summary, and the Protected CNAME is also available as a welcome email tag. Renaming the service in Blesta renames the TCPShield network to match.

Managing a client's network from the staff side

Open the service for full management and you'll find the same five tabs your clients get, mirrored for your team:

• Statistics - player count and bandwidth, charted over the last 24 hours, 2 days, or 7 days.
• Domains - the client's onboarding steps (protected CNAME, RealIP plugin download, DNS instructions) plus their Domain Management table: hostname, assigned backend set, Badlion support, and verification status. A Verify link next to an unverified domain opens the same guided TXT-record verification flow the client sees.
• Backends - the client's backend sets, each with its own list of host:port backends and a Proxy Protocol toggle.
• Bedrock Backends - Bedrock tunnels, each with a name, assigned backend set, location, and Proxy Protocol toggle.
• Firewall - CIDR firewall rules with a Whitelist toggle.

Use these to add, edit, or remove anything on the client's behalf without needing their login.

Suspending and canceling

Suspending a service doesn't delete the client's configuration - it snapshots every backend set and repoints them so nothing resolves, then restores the exact same backends when you unsuspend. Canceling does not remove the network at TCPShield; it only affects the Blesta service.

For your clients

Domains tab

The first tab a client meets after ordering. It walks them through three onboarding steps - their protected anycast CNAME, downloading the RealIP plugin for Bungee, Spigot, or Velocity, and the exact DNS records to create - then lists their domains below with the same add, edit, remove, and Verify controls staff have. Verifying asks them to add a TXT record and click Verify once it has propagated.

Backends, Bedrock Backends, and Firewall tabs

Clients manage their own backend sets (name, backend list, Proxy Protocol), Bedrock tunnels (name, backend set, location, Proxy Protocol), and CIDR firewall rules (with a Whitelist toggle) - the same controls your staff have, scoped to their own network.

Statistics tab

Charted player count and bandwidth for their network, with a period selector for the last 24 hours, 2 days, or 7 days.

Good to know

• Mock API mode lets you try every screen above - ordering, all five tabs, suspension - without a TCPShield account at all. No network is ever created, changed, or deleted at TCPShield while an account has it ticked.
• Every request and response to TCPShield is recorded under Tools > Logs > Module Log - check there first when an action fails.
• Per-package domain and backend-set limits apply to your clients only; staff can always manage the client's network from the admin side regardless of the package's caps.