DDoS Protection on Hosting Servers: What Your Panel Handles and What It Does Not

Short answer: Hosting panels stop application-layer DDoS attacks well. They cannot stop volumetric network attacks. This guide draws the line precisely — and shows what Panelica built-in defences handle at each layer, and when you need upstream protection to fill the gap.

If you run a VPS or a dedicated server, the question is not whether you will be attacked. It is which kind of attack will hit you, and whether your stack is positioned to handle it before it takes your site offline. Understanding that boundary is the difference between a false sense of security and an actual defence posture.

Most guides on DDoS protection either overstate what a hosting panel can do, or understate it. Neither is accurate. This guide is based on verified code from the Panelica source tree — specifically backend/internal/services/security/ — and on standard industry attack classifications. No speculation.

At a Glance

Jump to the section that fits your situation:

• For VPS owners and operators — Plain-language overview of what you need and what Panelica provides out of the box.
• For sysadmins and technical readers — Layer-by-layer breakdown, verified nginx config, ModSecurity configuration, and monitoring guidance.

For VPS Owners and Operators

What is a DDoS attack, and which kinds reach your VPS?

A distributed denial-of-service (DDoS) attack sends traffic from many sources simultaneously with the goal of exhausting a resource — bandwidth, CPU, connection table, or application state — so that legitimate requests cannot be served.

Not all DDoS attacks are the same. The ones that reach your VPS fall into two categories with very different remedies:

• Volumetric attacks (Layer 3/4): These try to fill your network pipe with junk traffic — UDP floods, SYN floods, DNS amplification. If your server has a 1 Gbps uplink and the attacker sends 10 Gbps of traffic, your server simply goes dark. No software on the server itself can help, because the pipe is full before a single packet reaches your application. The only defence is upstream filtering: Cloudflare, your hosting provider DDoS scrubbing service, or a purpose-built network-layer protection provider.
• Application-layer attacks (Layer 7): These send HTTP requests that look legitimate but are designed to exhaust server resources — thousands of concurrent connections that never send data (slow loris), floods of POST requests to login pages or xmlrpc.php, or rapid-fire API calls from botnet nodes. These attacks do not require massive bandwidth. A cheap botnet can overwhelm a misconfigured web server with a few hundred requests per second. And this is exactly where a hosting panel stack can help significantly.

The vast majority of attacks that target ordinary VPS servers are application-layer attacks. Terabit-scale volumetric attacks are expensive to mount and are almost exclusively directed at large infrastructure targets. If you run a handful of sites on a VPS, you are far more likely to face a slow loris or a WordPress xmlrpc flood than a 100 Gbps UDP flood.

What your hosting panel can stop — and what it cannot

A hosting panel manages software that runs on your server: the web server, the application firewall, the fail2ban daemon, the firewall ruleset. Everything it does operates within the boundary of your server own network interface.

Panels can stop or significantly mitigate:

• HTTP floods and GET/POST request floods (rate limiting at the web server layer)
• Slow loris and RUDY attacks (connection and timeout configuration)
• Login bruteforce against WordPress, SSH, FTP, and panel admin (fail2ban and WAF rules)
• Known malicious bot traffic (bot signature blocklists, user-agent filtering)
• Modest SYN floods (Linux kernel SYN cookies and nftables rate limiting)
• Country-originated traffic if you have no legitimate users there (GeoIP blocking)

Panels cannot stop:

• Volumetric attacks that saturate your network uplink before reaching your server
• DNS amplification attacks where your server is not even the target, but is used as a reflector
• Attacks that exceed your server CPU capacity to process nftables rules at line rate
• Sophisticated botnet traffic that passes rate limits and WAF rules by mimicking browser behaviour

Three layers of DDoS protection your VPS needs in 2026

A practical defence posture for a VPS has three layers, and each layer handles what the previous one cannot:

When you need to pay for upstream DDoS protection

Cloudflare free plan covers most website traffic scenarios adequately. You need to consider a paid upstream solution when:

• You serve non-HTTP traffic (VoIP, game servers, RTMP streams) that Cloudflare cannot proxy
• You have been hit by a volumetric attack that exceeded your provider included protection threshold
• Your hosting provider does not include any network-level DDoS scrubbing in your plan
• Your business has an SLA that requires near-zero downtime during an attack

If you run standard web hosting — WordPress sites, business websites, SaaS applications over HTTPS — Cloudflare free plus a well-configured panel stack is a reasonable starting point.

What Panelica built-in DDoS protections cover

Panelica ships the following security components on every installation, including the Starter (free trial) tier. These are not premium add-ons:

• nftables firewall management — The modern nftables-based firewall replaces iptables. Panelica manages rules through the panel UI, including per-IP blocking, protocol restrictions, and port controls.
• IP blocking — Manual IP blocking through the panel UI, plus automatic blocks triggered by fail2ban jails for SSH, FTP, mail, and the panel admin interface.
• Country blocking with GeoIP — If you have no legitimate traffic from a region, you can block it at the firewall level through the panel.
• nginx rate limiting — Pre-configured connection and request rate zones (30 requests per second per IP by default) that activate a 429 response when exceeded. Applied per vhost.
• ModSecurity with OWASP Core Rule Set — The industry-standard WAF ruleset is deployed and managed through the panel. It blocks known exploit patterns, bad bot signatures, and common attack payloads.
• fail2ban integration — Monitors nginx access logs, SSH auth logs, ProFTPD logs, and mail logs. Repeated failed authentication attempts result in automatic IP bans.
• Cloudflare integration — Panelica Cloudflare module manages DNS proxy settings, automatic SSL, and the real-IP trust configuration so that rate limits and fail2ban see the actual client IP rather than Cloudflare proxy addresses.

Cloudflare in front of your VPS: when it is enough

For HTTP/HTTPS traffic — which covers the vast majority of hosting scenarios — putting your domains behind Cloudflare proxy mode and configuring Panelica Cloudflare integration gives you a strong combined defence:

• Cloudflare absorbs volumetric attacks before they reach your server
• Cloudflare Layer 7 DDoS protection blocks application-layer flood patterns at their edge network
• Panelica WAF and rate limiting act as a second layer of defence for requests that do reach your origin
• Panelica real-IP configuration ensures fail2ban and ModSecurity see actual client IPs through the Cloudflare proxy

This combination is not perfect for every scenario, but it is a substantial and practical baseline that most small and medium VPS deployments can set up in an afternoon.

For Sysadmins and Technical Readers

Layer 3/4 attack types and the kernel-level defences available

Network-layer attacks operate below the web server. The kernel and firewall are the first line of response — and there is a hard ceiling on what they can do when bandwidth is the scarce resource.

SYN flood: The attacker sends TCP SYN packets with spoofed source IPs. The server allocates connection state for each one, waiting for the ACK that never arrives. The connection table fills. New legitimate connections are rejected.

Linux kernel mitigation: net.ipv4.tcp_syncookies=1. When the connection table is under pressure, the kernel stops allocating state and instead embeds a cryptographic cookie in the SYN-ACK. State is only allocated if a valid ACK containing the cookie is received. This defeats small-to-moderate SYN floods. At high packet rates (above 100k pps), even processing the SYN cookies consumes enough CPU to degrade service. nftables rate limiting on new TCP SYN packets provides an additional layer but has the same ceiling.

UDP flood: UDP is stateless. The attacker sends high-volume UDP packets to arbitrary ports. The kernel processes each packet, finds no listening socket, and sends ICMP Port Unreachable responses — which consumes CPU and generates outbound traffic. At multi-gigabit scale, the uplink is saturated regardless of kernel behaviour. nftables can drop UDP packets by rate limit or by port, reducing CPU cost, but the inbound bandwidth is already consumed. Upstream filtering is the only effective solution at scale.

DNS amplification: The attacker sends DNS queries with spoofed source IPs pointing to your server, to open resolvers across the internet. Those resolvers send large DNS responses to your server IP. Your server receives traffic it never requested. Your BIND installation is not the attack vector here — your IP address is the target. No on-server software can stop traffic that arrives at the NIC. This requires upstream null-routing or scrubbing.

Layer 7 attack patterns: HTTP flood, slow loris, RUDY, login bruteforce

HTTP GET/POST flood: A botnet sends high-volume HTTP requests to resource-intensive endpoints — pages that hit the database, execute PHP, or perform disk I/O. The goal is CPU and connection exhaustion rather than bandwidth exhaustion. Characteristics: requests are syntactically valid HTTP, source IPs are distributed across botnet nodes, user-agents may be spoofed. nginx rate limiting and ModSecurity are the primary mitigations.

Slow loris: The attacker opens many simultaneous HTTP connections and sends request headers extremely slowly, never completing the request. nginx has a bounded worker connection pool. If all workers are occupied waiting for slow clients, legitimate connections queue and time out. nginx mitigation: client_header_timeout, client_body_timeout, and limit_conn. Default nginx values are permissive; Panelica limit_conn zone constrains the maximum concurrent connections per IP before slow loris becomes effective.

RUDY (R-U-Dead-Yet): Similar to slow loris but targets POST request bodies. The attacker sends a POST with a large declared Content-Length and drip-feeds the body bytes. client_body_timeout handles this: if the body is not received within the timeout window, nginx closes the connection.

WordPress xmlrpc and wp-login bruteforce: xmlrpc.php is a common bruteforce and credential-stuffing target because it allows multiple authentication attempts per request. wp-login.php receives credential spray attacks. Panelica ModSecurity OWASP CRS includes WordPress-specific rules. fail2ban monitors nginx access logs for repeated 401/403 responses against these paths and issues automatic IP bans after configurable thresholds.

Panelica stack: nftables, ModSecurity OWASP CRS, nginx rate limiting, fail2ban

The security stack in Panelica source tree (backend/internal/services/security/) covers four components that are relevant to DDoS and abuse mitigation:

nftables_service.go and firewall_service.go: Manages the server nftables ruleset. Operations include adding and removing individual IP blocks, setting per-protocol port rules, and flushing rule sets. The firewall cache (firewall_cache.go) keeps in-memory state consistent with the nftables kernel tables to avoid expensive list operations on every rule check.

ip_blocking_service.go: Handles both manual IP blocks (operator action through the panel) and programmatic blocks triggered by fail2ban jails. The blocking mechanism writes to nftables directly rather than through iptables wrappers.

country_blocking_service.go: GeoIP-based blocking using the server MaxMind GeoLite2 database. Block rules are expressed as IP set membership checks in nftables — this is more efficient at scale than individual IP rules because the kernel can evaluate set membership in O(log n).

modsecurity_global_service.go and modsecurity_service.go: Manages ModSecurity configuration at both the global level and per-domain level. The global configuration (etc/modsecurity/panelica-global.conf) sets the engine mode, audit log path, and loads OWASP CRS. The per-domain service generates domain-specific rule overrides and whitelists. The etc/modsecurity/bad-bots.txt and global-blacklist.txt files are loaded as custom rule sources alongside the CRS.

Default rate-limit zones in Panelica nginx configuration

Panelica ships a default rate-limiting configuration at etc/nginx-customer/snippets.d/ddos-zones.conf. This file is included by the nginx customer vhost configuration. The full content of the zones definition, as it exists in the source tree:

# Connection limit + general request rate zones for DDoS mitigation.
# Apply in vhosts:
#   limit_conn panelica_perip 20;
#   limit_req  zone=panelica_general burst=50 nodelay;
limit_conn_zone $binary_remote_addr zone=panelica_perip:10m;
limit_req_zone  $binary_remote_addr zone=panelica_general:10m rate=30r/s;

# Tune the response when limits are hit (HTTP 429 by default)
limit_conn_status 429;
limit_req_status  429;

Per-vhost activation uses:

limit_conn panelica_perip 20;
limit_req  zone=panelica_general burst=50 nodelay;

What this means in practice:

• zone=panelica_perip:10m — a 10 MB shared memory zone keyed on binary client IP. 10 MB holds approximately 160,000 simultaneous IP entries.
• rate=30r/s — a token bucket refills at 30 requests per second per IP. The burst=50 nodelay vhost directive allows a short burst of 50 requests without delay before the 429 response kicks in.
• limit_conn panelica_perip 20 — no single IP may hold more than 20 concurrent connections to a single vhost. This directly limits slow loris effectiveness.
• Both zones return HTTP 429, which triggers a user-facing error page (etc/templates/error-pages/429.html.tpl).

These defaults are tuned for a shared hosting environment where individual IPs may generate higher traffic in short bursts. For high-traffic legitimate applications — CDN origins, API endpoints with high request rates from a small set of IPs — you may need to adjust burst size or extract those endpoints from the general rate limit zone.

Country blocking with GeoIP and when it is reasonable

Country-level IP blocking is a coarse instrument. It is effective in specific situations and counterproductive in others.

Reasonable use cases:

• Your application has no users in a given region and you are seeing attack traffic exclusively from that region IP ranges
• Compliance requirements restrict your service to specific geographies
• A sustained attack is originating heavily from a small set of country prefixes and upstream protection is not yet active

Poor use cases:

• Blocking a country because its ASNs appear in attack traffic when the same ASNs also carry legitimate users
• Using country blocking as a substitute for application-layer rate limiting — IP blocks are bypassed by any attacker who can rotate through global proxy infrastructure
• Blocking large IP ranges that overlap with VPN or Tor exit nodes used by legitimate privacy-conscious users

Panelica country blocking operates via nftables IP set membership. The GeoIP lookup happens at panel rule generation time, not at packet processing time — so adding a country block generates an nftables set update rather than inserting a kernel module hook into the packet path.

Integrating Cloudflare edge protection cleanly

When Cloudflare proxies your traffic, nginx and fail2ban see Cloudflare proxy IP addresses rather than the actual client IP. Without correcting for this, rate limits apply to Cloudflare shared IPs (triggering 429 for all Cloudflare-proxied traffic simultaneously) and fail2ban bans Cloudflare infrastructure rather than the attacker.

Panelica ships etc/nginx-customer/snippets.d/cloudflare-real-ip.conf which instructs nginx ngx_http_realip_module to trust Cloudflare published IP ranges and rewrite $remote_addr to the value of the CF-Connecting-IP header. With this snippet included, all downstream rate limiting, fail2ban log parsing, and ModSecurity rule evaluation operate on the true client IP.

The Panelica Cloudflare integration module handles this automatically when you connect a Cloudflare account and enable proxy mode through the panel — the snippet is included in the vhost configuration and Cloudflare DNS proxy setting is toggled from the panel UI without manual DNS changes.

Monitoring DDoS attempts: which logs to watch, which thresholds matter

During or after an attack, the most useful signals are in nginx access logs and fail2ban logs:

# High request rate from a single IP — look for repetition
grep "POST /wp-login.php" /opt/panelica/var/logs/nginx/access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 429 responses — rate limiting is triggering
grep " 429 " /opt/panelica/var/logs/nginx/access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# fail2ban bans in the last hour
fail2ban-client status panelica-nginx 2>/dev/null
journalctl -u fail2ban --since "1 hour ago" | grep "Ban"

Key thresholds to watch:

• If a single IP is generating more than 1000 requests in a five-minute window and not being blocked, your rate limit zone or fail2ban jail threshold may need tuning.
• If nginx worker connections are consistently near the worker_connections maximum, a slow loris attack may be in progress. Check active connection counts per IP with ss -tn | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10.
• If server load is high but request rate is low, a computationally expensive endpoint may be the target — check which URLs are consuming PHP-FPM worker slots.

DDoS Layer Capability Reference

Three-Layer Defence Architecture

[ Internet / Attacker ]
         |
         v
+------------------------------------------+
| Layer 1: EDGE (upstream)                 |
| Cloudflare / Hosting provider scrubbing  |
| Handles: volumetric UDP, DNS amp,        |
|          NTP reflection, L7 flood        |
| Cost: Cloudflare free tier covers HTTP   |
+------------------------------------------+
         |
         v
+------------------------------------------+
| Layer 2: KERNEL + nftables               |
| Runs on the VPS itself                   |
| Handles: SYN flood (syncookies),         |
|          per-IP connection limits        |
| Cost: included in every Linux distro     |
+------------------------------------------+
         |
         v
+------------------------------------------+
| Layer 3: WEB SERVER + WAF + rate limit   |
| Panelica-managed (nginx, ModSecurity,    |
| OWASP CRS, fail2ban, bad-bots.txt)       |
| Handles: HTTP flood, slow loris,         |
|          bot traffic, login bruteforce   |
| Cost: included in all Panelica tiers     |
+------------------------------------------+
         |
         v
+------------------------------------------+
| Layer 4: APPLICATION                     |
| fail2ban + 2FA + per-user PHP-FPM        |
| Handles: repeated auth failure, panel    |
|          admin attack, per-user          |
|          blast radius containment        |
| Cost: included in all Panelica tiers     |
+------------------------------------------+
         |
         v
[ Your service / origin ]

What Panelica Does Not Do

Being clear about the limits of a tool is as important as knowing its capabilities. Panelica does not provide, and cannot provide, the following:

• Volumetric DDoS protection above your network uplink capacity. Panelica is a hosting panel that runs on your server. It has no access to your provider upstream routing. If your server 1 Gbps link is saturated, Panelica cannot unsaturate it. You need your hosting provider DDoS scrubbing service, Cloudflare network, or a dedicated upstream protection service.
• DNS amplification reflection defence. Panelica includes a managed BIND installation for customer DNS. But DNS amplification attacks send traffic to your IP address from external resolvers — the attack does not originate from your BIND instance. On-server filtering cannot help because the traffic arrives at your NIC from the internet before any Panelica component can evaluate it.
• Anycast network or global scrubbing centre. Panelica is not a network service provider. It does not operate its own Anycast network, point-of-presence infrastructure, or traffic scrubbing platform. If you need that level of protection, it must come from a dedicated provider whose infrastructure sits in front of yours.
• Sophisticated bot evasion at scale. Panelica bot filtering relies on signature lists and rate limits. A sophisticated botnet that rotates user agents, solves CAPTCHAs, uses residential proxies, and mimics browser behaviour will eventually bypass these controls. ML-based bot management solutions are required for that threat class.

Getting the Most Out of What You Have

The practical sequence for most VPS deployments:

1. Enable Cloudflare proxy mode for all HTTP/HTTPS domains in the Panelica Cloudflare module. This handles volumetric attacks at zero cost for web traffic.
2. Verify that the Cloudflare real-IP snippet is active in your nginx vhost configurations. Without this, rate limiting and fail2ban operate on Cloudflare shared proxy IPs rather than actual client IPs.
3. Confirm ModSecurity is in enforcement mode (not detection-only) in the panel Security section. Detection mode logs attacks; enforcement mode blocks them.
4. Review which fail2ban jails are active for your services. SSH, FTP, mail, and the panel admin login should all have active jails with reasonable ban thresholds.
5. For WordPress sites specifically, verify the WordPress security hardening settings are enabled in the panel. This disables xmlrpc.php access and adds fail2ban monitoring for wp-login.php.

Panelica security page surfaces configuration state for all of these components in a single view, so you can audit your posture without touching config files manually.

None of this eliminates all risk. A motivated attacker with sufficient resources and a specific target will eventually find a path. What you are doing is raising the cost of a successful attack to the point where your server is no longer the easiest target in the pool — and ensuring that the class of attack most likely to hit a typical VPS server (application-layer, credential stuffing, bot scraping) is handled automatically without intervention from you.

For more on specific security components in Panelica, see the related posts below.

Related Posts

• Free VPS Control Panels in 2026: An Honest Comparison
• Cloudflare on Autopilot: How Panelica Manages DNS, SSL, and Proxy Mode
• How Panelica Isolates Every User: 5-Layer PHP Security Architecture
• Best cPanel Alternatives in 2026: 8 Panels Compared Honestly
• Server Panel Security Showdown 2026: User Isolation
• Panelica vs alternatives: feature comparison

Last verified: Panelica defaults and capabilities verified 2026-05-24 against the panel source code (backend/internal/services/security/) and default nginx and ModSecurity templates (etc/nginx-customer/snippets.d/, etc/modsecurity/). DDoS attack-vector classifications follow standard industry taxonomy.