Reselling DDoS Protection with WHMCS: Multi-Tenant Guide

Reselling DDoS protection to hosting customers with WHMCS comes down to three things. Each customer's IPs must map to one tenant. Each tenant needs its own thresholds, alerts and mitigation policy. The billing system must keep that mapping accurate over the service lifecycle. If you get those right, DDoS protection becomes a product line instead of an internal cost you absorb.

This guide covers the design: what to sell, how to isolate tenants, how to feed flow data, how to route alerts, and what usually goes wrong.

Decide What You Are Actually Selling

"DDoS protection" means different things at different layers. Define tiers before you touch any tooling:

Be honest in the product description. A /32 blackhole stops the attack from saturating your uplinks, but the victim IP is unreachable until it is withdrawn. Customers who need to stay online during an attack need filtering or scrubbing, not blackholing. Most resellers end up with a free or low-cost baseline tier (detection plus RTBH) and a paid upgrade tier.

Step 1: Make Your IP Inventory the Source of Truth

Multi-tenancy fails first at the inventory. Before onboarding anyone:

1. Export every customer-assigned IP and prefix from WHMCS (or your IPAM).
2. Assign each to exactly one tenant. Shared IPs on shared hosting belong to your own tenant, not to a customer.
3. Keep infrastructure ranges (DNS resolvers, mail, management, router loopbacks) in a separate "protected, never blackhole" group.
4. Document who owns what when a customer holds a whole /24 versus a few /32s.

Everything below depends on this mapping. If a customer's IP lands in the wrong tenant, they get someone else's alerts or no alerts at all.

Step 2: Export Flows From Your Edge

The detection side does not care about tenants. It sees traffic to and from IPs, and the tenant mapping is applied on top. Export flows from your border and, if possible, aggregation routers. The collector address below is a documentation IP.

Juniper (inline IPFIX):

set services flow-monitoring version-ipfix template T4 ipv4-template
set chassis fpc 0 sampling-instance DDOS
set forwarding-options sampling instance DDOS input rate 1000
set forwarding-options sampling instance DDOS family inet output flow-server 192.0.2.50 port 2055
set forwarding-options sampling instance DDOS family inet output flow-server 192.0.2.50 version-ipfix template T4
set forwarding-options sampling instance DDOS family inet output inline-jflow source-address 192.0.2.1
set firewall family inet filter SAMPLE term all then sample
set firewall family inet filter SAMPLE term all then accept

Cisco IOS XE (Flexible NetFlow):

flow exporter COLLECTOR
 destination 192.0.2.50
 transport udp 2055
 export-protocol ipfix
flow monitor DDOS-MON
 exporter COLLECTOR
 record netflow ipv4 original-input
interface TenGigabitEthernet0/0/0
 ip flow monitor DDOS-MON input

MikroTik (RouterOS v7):

/ip traffic-flow set enabled=yes interfaces=ether1
/ip traffic-flow target add dst-address=192.0.2.50 port=2055 version=9

Linux (softflowd on a mirror or router):

softflowd -i eth0 -n 192.0.2.50:2055 -v 9

Sampling rate matters for small customers. At a high sampling ratio, a small VPS under a modest attack may not produce enough sampled packets to cross a threshold reliably. Pick a rate that suits your smallest protected tenant, not only your largest.

Step 3: Per-Customer Thresholds

One global threshold is the most common reason resellers get complaints. A 10 Gbps dedicated server and a small VPS on the same /24 should not share a limit. Define a small set of profiles and attach tenants to them:

The numbers are specific to your network, so derive them from baselines. Set both pps and bps, because small-packet floods can hurt a router or server long before bandwidth looks unusual. See our posts on DDoS detection thresholds and baselines for the tuning method.

Review the profiles after the first month. Move customers who triggered false positives to a higher profile, and keep a record of why.

Step 4: Tenant-Aware Mitigation Policy

Let each tier map to an action:

• Alert only: the customer is notified, no routing change. Suitable for infrastructure and for customers who prefer to decide themselves.
• Automatic RTBH: the attacked /32 is announced with your blackhole community. A Juniper example:

set routing-options static route 192.0.2.10/32 discard community 65535:666
set policy-options policy-statement RTBH-OUT term 1 from community BLACKHOLE
set policy-options policy-statement RTBH-OUT term 1 then accept

• FlowSpec: drop or rate-limit specific traffic, such as UDP source port 123 or 11211 toward one IP, without cutting the host off. This is a better fit for customers whose service must stay reachable.
• Scrubbing: if you operate your own ASN with at least one /24, a service like NixGuard Edge announces your prefixes from the scrubbing edge and returns clean traffic over a GRE tunnel with a BGP session inside. It can be always-on or on-demand, which maps well to a premium tier.

Put guardrails around automation. Never allow RTBH on infrastructure prefixes, set a maximum announcement duration with automatic withdrawal, and cap the number of simultaneous blackhole routes so a bad rule cannot blackhole half a /24.

Step 5: Per-Customer Alerts

A tenant should see only its own IPs, attacks and traffic graphs, and nobody else's. Check this explicitly before launch by logging in as a test tenant and trying to find data from another one.

Good alerts for hosting customers include:

• the targeted IP and the time the attack started,
• an attack type if known (UDP flood, SYN flood, amplification),
• peak pps and bps,
• what action your network took (none, blackhole, filter),
• when the action was or will be removed.

Keep the wording plain, since many customers are not network engineers. Also decide who gets alerts: the end customer, your NOC, or both. A common pattern is that the customer gets the notification and your NOC gets everything, with extra escalation for large attacks.

Step 6: Tie It to WHMCS Lifecycle

The recurring failure in reselling is drift between billing and protection. Plan these events:

1. Service created: the tenant exists and IPs are attached to it.
2. IP added or changed: the new IP is covered by the right profile. An unmapped IP is an unprotected IP.
3. Upgrade or downgrade: the profile and mitigation tier change with the product.
4. Suspension: decide what happens to protection and alerts during non-payment.
5. Termination: remove the IPs and the tenant, so a re-assigned IP does not notify the previous customer.

NixMon includes a WHMCS integration, a hosted multi-tenant panel and a reseller mode. Test in a trial exactly which of these events your workflow needs and how each is handled, instead of assuming. Also test a manual fallback for anything you want to control by hand.

Step 7: White-Label It

Customers should see your brand. NixMon offers a white-label / reseller mode, and native iOS and Android apps with attack alerts. Beyond branding, plan the support side:

• Write a short "what happens during an attack" page for customers.
• Publish your blackhole policy: when it triggers, how long it lasts, how to request removal.
• Train support staff to read an attack record so they can answer "was I attacked?" in minutes.
• Decide in advance who approves manual blackhole removal.

Common Mistakes

• One threshold for everyone. Leads to false positives on big tenants and missed attacks on small ones.
• Blackholing infrastructure IPs automatically. An attack on a resolver can turn into an outage for every customer.
• Not selling the limits. Customers assume "DDoS protection" means they stay online. State clearly what RTBH does.
• Ignoring IPv6. If tenants have IPv6 space, export and map it too.
• No removal process. Blackholes that never expire turn into permanent outages.
• Skipping the isolation test. Verify tenant separation yourself before customers find a problem.

Launch Checklist

1. IP inventory mapped to tenants, infrastructure group excluded from automation.
2. Flow export live on every edge router, sampling rate checked.
3. Three or four threshold profiles defined and assigned.
4. Mitigation actions per tier, with timeouts and route caps.
5. Alerts tested end to end with a tenant account.
6. WHMCS lifecycle events tested, including termination.
7. Branding, support documents and customer-facing policy ready.

You can validate this design with the 15-day free trial of NixMon, with no credit card required. Start with a single test tenant and a few IPs before you onboard real customers.