Rule Templates & Bundles: One-Click DDoS Policy for ISPs and Enterprises

The hardest part of DDoS protection is rarely detection. CoreDetection™ handles that with AI-learned baselines. The operational bottleneck is policy deployment: writing firewall rules per prefix, keeping them consistent across hundreds of subnets, and doing it fast enough that a new customer is protected before their first attack.

Most platforms leave you with two bad options: accept generic threshold-based filtering that breaks legitimate traffic, or spend days hand-crafting rules for every prefix. CoreTech offers a third path — 99 pre-built rule templates and ordered policy bundles that deploy baseline protection to any prefix in seconds through the Client Portal.

This guide explains how templates and bundles work, what ships out of the box, and how ISPs scale policy across unlimited prefixes without reinventing the wheel for every customer.

The Policy Deployment Problem

ISPs and hosting providers face a specific challenge that enterprise DDoS products were never designed for:

• A mid-size operator might protect 100+ /24 blocks across dozens of downstream clients
• Each client runs different services — web hosting, VoIP, gaming, VPN, databases
• Writing custom XDP rules per prefix is slow, inconsistent, and error-prone
• Blanket DROP rules break legitimate high-bandwidth services during attacks

The result is either under-protected prefixes waiting for manual configuration, or over-aggressive rules that cause collateral damage. Neither is acceptable at ISP scale.

CoreEdge™ solves this with a template library — standardized, tested rule patterns that operators apply individually or as complete policy packs.

What Is a Rule Template?

A rule template is a reusable DDoS policy pattern stored in the CoreTech portal. Each template defines two things:

Match criteria (from) — what traffic to inspect:

• IP protocol (TCP, UDP, ICMP, GRE, or any)
• Source/destination IP ranges and port ranges
• TCP flags (SYN, ACK, FIN, RST, PSH, URG)
• ICMP type and code
• GeoIP source country

Action (then) — what to do when matched:

• DROP — block matching traffic
• ALLOW — permit with optional rate limit
• RATE_LIMIT — shape traffic to a PPS ceiling
• RATE_LIMIT_SRC — per-source-IP rate limiting
• MATCH_CONNECTION — stateful connection tracking
• CUSTOM — full protocol profile with 20+ tunable parameters

When you apply a template, it becomes a live rule on CoreEdge — evaluated at wire speed via XDP/eBPF before packets enter the kernel stack.

Example: TCP SYN Flood Protection

The most common DDoS vector is the TCP SYN flood — thousands of SYN packets without completing the three-way handshake. CoreTech ships a template that handles this precisely:

This is not a blunt DROP. Connections that stay within the rate limit continue normally. Only abusive volumes are shaped — the same philosophy behind our What We Don’t Block approach.

The 99-Template Library

CoreTech ships 99 system templates organized into nine categories. Every template is production-tested and uses rate limiting over hard drops wherever legitimate traffic could be affected.

Attack Mitigation Templates

Service Allow Templates

These templates explicitly permit production services with tuned rate limits — the building blocks of a “what we don’t block” policy:

An ISP protecting a VoIP customer applies the SIP templates. A hosting provider applies HTTP/HTTPS allow rules. A gaming operator applies the gaming port templates. No custom rule writing required.

What Is a Rule Bundle?

A single template protects against one vector. Real-world prefixes need multi-layered policy — allow legitimate services, rate-limit flood vectors, and drop known attack patterns. Doing this template-by-template works, but at ISP scale it is still too slow.

A Rule Bundle is an ordered collection of templates applied as a single atomic operation to a prefix. Think of it as a policy pack:

Bundle: "Web Protection"
  seq 1  →  Allow HTTPS Traffic
  seq 2  →  Allow HTTP Traffic
  seq 3  →  TCP SYN Flood Protection
  seq 4  →  UDP Flood Protection
  seq 5  →  Block Invalid TCP Flags
  seq 6  →  ICMP Echo Protection

All six rules are pushed to CoreEdge in sequence order. The prefix is protected in one action.

Bundle Categories

Admins can compose custom bundles from any template in the library — reorder templates, mark some as required, and override rate limits per template. Customers apply pre-built bundles through the Client Portal without needing admin intervention.

How Rules Are Evaluated

Understanding evaluation order matters when combining templates with automated mitigation:

1. Custom rules (your templates/bundles)     ← evaluated first, lowest seq wins
2. Auto-generated mitigation rules           ← CoreDetection during active attacks

Your baseline policy always runs first. During an attack, CoreDetection generates additional rules targeting the specific attack signature — but your allow rules for HTTP, SIP, VPN, and other services remain in effect. Legitimate traffic to unaffected services continues.

Each prefix supports up to 20 custom rules. Bundles are designed to fit within this limit while covering the most common attack vectors and service allows.

Deployment Flow: Portal to Wire Speed

Applying a bundle takes seconds through the Client Portal:

1. Admin assigns prefixes to the customer account (via AS-SET import or manual CIDR list)
2. Customer opens Networks — browses assigned prefixes, selects targets
3. Add to Firewall — registers the prefix on the assigned CoreEdge cluster
4. Apply Bundle — selects a policy pack (Web Protection, Gaming, etc.)
5. Rules go live — pushed to CoreEdge XDP via cluster API; application logged for audit

No support ticket. No manual rule writing. No waiting for an engineer to configure each prefix.

For ISPs onboarding dozens of downstream clients, the workflow scales linearly: same bundle, different prefix, one click each.

Guardrails Built In

Self-service does not mean uncontrolled. The portal enforces:

• Prefix scoping — customers can only manage prefixes within their assigned CIDR ranges
• 20-rule cap per prefix — prevents policy sprawl
• Role-based access — firewall management requires SUPPORT or ABUSE sub-role
• Audit trail — every bundle application and rule change is logged
• Cluster validation — rules only deploy to clusters assigned to the customer’s service

Admins retain full CRUD over templates, bundles, and infrastructure defaults. Customers operate within their boundaries.

Three Real-World Scenarios

Web Hosting ISP — 200 /24 Prefixes

A hosting provider protects 200 downstream /24 blocks. Without templates, configuring each prefix manually would take weeks.

With bundles: Apply the Web Protection bundle to each prefix as customers onboard. Six rules per prefix — HTTPS allow, HTTP allow, SYN flood protection, UDP flood protection, invalid flag drop, ICMP protection. Total time per prefix: under 30 seconds.

VoIP Carrier — SIP Infrastructure

A VoIP provider’s prefixes carry SIP signaling on UDP/TCP 5060 and TLS on 5061. Blanket UDP rate limiting would drop legitimate call setup traffic.

With templates: Apply Allow SIP (5060) and Allow SIP TLS (5061) templates with 2,000 PPS rate limits. Add UDP Flood Protection as a separate rule — SIP traffic within limits passes; only flood volumes from spoofed sources are shaped.

Gaming Provider — Low-Latency Requirements

Gaming servers on ports 25565 (Minecraft), 7777–7784 (Unreal), and Discord voice UDP cannot tolerate aggressive filtering.

With bundles: Apply the Gaming Protection bundle — game port allow rules with tuned rate limits plus SYN/UDP flood protection underneath. Legitimate player connections stay online; only attack traffic is shaped or dropped.

Templates vs Bundles vs Manual Rules

Most operators start with a bundle for baseline protection, then add individual templates for customer-specific services (SIP, gaming, VPN) as needed.

Built on CoreEdge XDP/eBPF

Templates and bundles are not portal abstractions — they compile to live XDP/eBPF programs on CoreEdge clusters. Every rule runs at the NIC level:

• Line-rate filtering — no kernel stack traversal for matched packets
• Per-prefix isolation — each customer’s policy is independent; no shared rate-limit buckets
• Stateful TCP validation — CUSTOM action profiles support connection tracking, SYN timeouts, and per-source limits
• GeoIP matching — country-scoped rules from the same interface used for protocol matching

The portal is the control plane. CoreEdge is the data plane. Templates bridge the gap between operator intent and wire-speed execution.

Getting Started

Every CoreTech deployment includes the full template library and bundle system:

• 99 system templates — available immediately, no configuration required
• Pre-built bundles — Web, DDoS, Gaming, API, and General Security
• Custom bundle creation — admins compose policy packs for specific customer segments
• Self-service application — customers deploy bundles through the Client Portal

For ISPs evaluating CoreTech, the template library answers a question we hear constantly: “What does baseline protection look like on day one?” The answer is six rules, one click, and wire-speed XDP filtering — not a blank configuration screen.

Share your prefix count and service mix — our network engineering team will recommend the right bundle for your deployment model.

Contact our network engineering team →