DDoS Protection Strategies for Dedicated Infrastructure

Understanding What You’re Actually Defending Against

DDoS attacks are not a monolithic threat. The category includes several distinct attack vectors that require different mitigation strategies:

Volumetric attacks flood your network pipe with traffic — UDP floods, ICMP floods, amplification attacks using DNS or NTP. These are measured in Gbps and Mpps (million packets per second). A 100Gbps volumetric attack against a server with 10Gbps connectivity simply fills the pipe regardless of how good your server-level firewall is. Mitigation requires upstream scrubbing before traffic reaches your data center.

Protocol attacks exploit weaknesses in TCP/IP — SYN floods being the most common. These exhaust connection table capacity on your server rather than bandwidth. A sustained SYN flood can bring down a server without saturating the network link at all.

Layer 7 (application) attacks target your application specifically. Low-and-slow attacks like Slowloris keep connections open indefinitely, exhausting connection limits without generating significant traffic volume. HTTP floods send legitimate-looking requests to expensive application endpoints — database-heavy pages, large file downloads, search functions.

According to Cloudflare’s 2024 DDoS Threat Report, HTTP DDoS attacks increased substantially year over year, with application-layer attacks now representing a significant proportion of total DDoS events. Volumetric attacks still occur, but sophisticated attackers increasingly target the application layer specifically because basic volumetric scrubbing doesn’t stop them.

Layer 1: Upstream Mitigation (Scrubbing Centers)

For volumetric attacks, no amount of server-side configuration helps if your 10Gbps connection is already saturated with 40Gbps of attack traffic. The mitigation must happen upstream, before traffic reaches your server.

Cloudflare’s Magic Transit and AWS Shield Advanced both provide upstream scrubbing services that filter traffic before it arrives at your data center. Cloudflare’s network capacity exceeds 250Tbps, meaning they can absorb volumetric attacks that would overwhelm any single data center’s transit capacity. Magic Transit announces your IP prefixes via BGP and routes all traffic through Cloudflare’s scrubbing infrastructure, passing only clean traffic to your server.

This layer is not optional for infrastructure that needs guaranteed availability during volumetric attacks. The server-side techniques below address Layer 7 and protocol attacks; they don’t solve bandwidth exhaustion.

InMotion Hosting’s dedicated server network provides baseline DDoS mitigation at the data center level. For higher-volume threat environments, layering a CDN or scrubbing service in front of your InMotion infrastructure adds the upstream capacity needed to absorb large attacks.

Layer 2: Rate Limiting at the Web Server

Nginx and Apache both support connection rate limiting that stops Layer 7 floods before they consume application server resources.

Nginx rate limiting configuration:

# Define a zone tracking requests by IP address

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/m;

server {

    location /api/ {

        limit_req zone=api_limit burst=10 nodelay;

        limit_req_status 429;

    }

}

This configuration limits each unique IP to 30 requests per minute against /api/ endpoints, with a burst allowance of 10 requests before rate limiting activates. Nginx’s rate limiting documentation covers the full parameter set. Set rates based on legitimate user behavior — an authenticated user submitting a form shouldn’t trigger a limit; an automated script hitting an endpoint 500 times per minute should.

Connection limiting addresses Slowloris-style attacks:

limit_conn_zone $binary_remote_addr zone=conn_limit:10m;

server {

    limit_conn conn_limit 20;

    client_body_timeout 10s;

    client_header_timeout 10s;

    send_timeout 10s;

}

The timeout values are critical. Slowloris works by sending HTTP headers very slowly, keeping connections open. Short timeouts drop these connections before they accumulate.

Layer 3: Firewall Rules for Protocol Attack Mitigation

SYN flood protection starts with kernel-level settings on Linux:

# Enable SYN cookies to handle SYN floods without exhausting connection tables

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Reduce the number of times a SYN-ACK is retransmitted before the kernel drops the connection

echo 2 > /proc/sys/net/ipv4/tcp_syn_retries

# Reduce TIME_WAIT state duration to recycle connections faster

echo “1 4 2 6 10 15 25 26” > /proc/sys/net/ipv4/tcp_retries2

# Make permanent

sysctl -p

For firewall-level mitigation, nftables (replacing iptables on modern Linux distributions) provides efficient packet filtering with minimal CPU overhead:

# Block invalid TCP packets (common in SYN flood attacks)

nft add rule inet filter input tcp flags ‘& (fin|syn|rst|psh|ack|urg) == fin|psh|urg’ drop

# Rate-limit new connections

nft add rule inet filter input ct state new limit rate 100/second accept

nft add rule inet filter input ct state new drop

Fail2Ban automates IP blocking based on log patterns which is useful for repeated failed authentication attempts or sustained requests from single IPs that slip through rate limiters. Fail2Ban reads your Nginx, Apache, or SSH logs and adds iptables/nftables rules automatically when thresholds are exceeded.

Layer 4: IP Reputation and Geo-Filtering

IP reputation filtering blocks known malicious IPs before they reach your application. Services like AbuseIPDB maintain databases of IPs with confirmed abuse history. Integrating these blocklists into your firewall or WAF eliminates traffic from IPs already known to participate in attacks.

Geographic filtering is a harder call. Blocking entire countries sounds appealing during an attack, but consider the collateral damage carefully. Residential IPs in any country can be compromised and used as botnet nodes, so geo-blocking rarely provides clean protection. For applications that genuinely have no legitimate users in specific regions, geo-filtering is a reasonable first layer.

Cloudflare’s free tier provides both IP reputation filtering and country-level blocking without server-side configuration.

Layer 5: Application-Level Protections

The most targeted Layer 7 attacks hit expensive application operations deliberately. Common targets:

• Search functions that trigger full-text database queries
• Login endpoints that require bcrypt hash comparison
• Large file download endpoints
• WordPress XML-RPC and admin endpoints if exposed publicly

Protect expensive endpoints with:

• CAPTCHA challenges via Cloudflare Turnstile or hCaptcha on login and registration flows
• API keys or authentication on any endpoint that runs database queries
• WordPress-specific hardening: disable XML-RPC if not needed (deny all; in Nginx for /xmlrpc.php), block access to /wp-admin/ by IP allowlist if your team is geographically consistent

Incident Response: What to Do When an Attack Is Active

If you’re currently under attack, priorities in order:

1. Identify the attack type: Check netstat -an | grep SYN_RECV | wc -l for SYN floods; check Nginx access logs for HTTP flood patterns; check iftop for volumetric attacks.
2. Enable Cloudflare or equivalent proxying immediately: Route traffic through a scrubbing service if not already configured. This is the fastest path to volumetric mitigation.
3. Temporary IP blocks for obvious attack sources: nft add rule inet filter input ip saddr <attack_ip> drop
4. Contact InMotion Support: The APS team can assist with traffic analysis and coordinate with the network operations center for upstream filtering.

The teams with the lowest mean-time-to-recovery from DDoS events are the ones who tested their response plan before an attack.