{"id":1377,"date":"2026-09-03T11:37:59","date_gmt":"2026-09-03T06:07:59","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/how-to-protect-server-layer-7-ddos-cloudflare-ufw\/"},"modified":"2026-09-03T12:32:20","modified_gmt":"2026-09-03T07:02:20","slug":"how-to-protect-server-layer-7-ddos-cloudflare-ufw","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/how-to-protect-server-layer-7-ddos-cloudflare-ufw\/","title":{"rendered":"How to Protect Your Web Server from Layer 7 DDoS Attacks with Cloudflare & UFW"},"content":{"rendered":"
\n

\n Quick Answer:<\/strong> To protect a Linux web server from Layer 7 application-layer DDoS attacks (HTTP floods), route DNS traffic through Cloudflare Proxy (Orange Cloud)<\/strong> and lock down your server’s UFW firewall so that port 80 and 443 only accept connections from Cloudflare’s published IP ranges, preventing attackers from bypassing the CDN proxy.\n <\/p>\n<\/div>\n

Understanding Layer 7 vs Layer 4 DDoS Attacks<\/h2>\n

While Layer 4 volumetric attacks (SYN floods, UDP amplification) attempt to saturate network bandwidth, Layer 7 Application Attacks<\/strong> mimic legitimate user requests (such as heavy search queries or database POST requests). These attacks consume 100% of PHP-FPM workers and MySQL CPU buffers, crashing the web server with minimal attacker bandwidth.<\/p>\n

Step 1: Enabling Cloudflare Proxy and WAF Protection<\/h2>\n
    \n
  1. In your Cloudflare dashboard, ensure all root and sub-records have the Proxy status set to Proxied (Orange Cloud)<\/strong>.<\/li>\n
  2. Navigate to Security > WAF > Rate Limiting Rules<\/strong> and create a rule restricting any single IP to a maximum of 50 requests per 10 seconds.<\/li>\n
  3. During an active attack, toggle Under Attack Mode<\/strong> to enforce a managed JavaScript\/Turnstile verification challenge.<\/li>\n<\/ol>\n

    Step 2: Locking Down Origin IP in UFW (Prevent Direct Bypass)<\/h2>\n

    If an attacker discovers your direct origin server IP address, they can send traffic directly to your VPS, bypassing Cloudflare completely. To eliminate this vector, configure UFW to allow port 80\/443 traffic only<\/em> from Cloudflare reverse proxy IPs:<\/p>\n

    #!\/bin\/bash\n# Sync Cloudflare IP ranges with UFW\nfor ip in $(curl -s https:\/\/www.cloudflare.com\/ips-v4); do\n    sudo ufw allow from $ip to any port 80,443 proto tcp\ndone\n\n# Deny all other direct incoming web connections\nsudo ufw deny 80\/tcp\nsudo ufw deny 443\/tcp\nsudo ufw reload<\/pre>\n
    Step 3: Restoring Real Visitor IPs in Nginx \/ Apache<\/h2>\n
    Because all incoming traffic now arrives from Cloudflare proxy IPs, configure your web server to read the CF-Connecting-IP<\/code> HTTP header so access logs and Fail2ban see true client IPs:<\/p>\n
    # \/etc\/nginx\/conf.d\/cloudflare.conf\nset_real_ip_from 173.245.48.0\/20;\nset_real_ip_from 103.21.244.0\/22;\nset_real_ip_from 104.16.0.0\/13;\nreal_ip_header CF-Connecting-IP;<\/pre>\n
    Local Web Server Rate Limiting with Nginx & OpenLiteSpeed<\/h2>\n
    Even with Cloudflare proxy active, configure local web server rate limiting to prevent memory exhaustion if attackers target un-cached search queries or API endpoints:<\/p>\n
    # \/etc\/nginx\/nginx.conf\n# Define shared memory zone for rate limiting (10 MB stores 160,000 IPs)\nlimit_req_zone $binary_remote_addr zone=one:10m rate=10r\/s;\nlimit_conn_zone $binary_remote_addr zone=addr:10m;\n\n# Apply rate limiting to virtual host\nlocation \/ {\n    limit_req zone=one burst=20 nodelay;\n    limit_conn addr 10;\n    try_files $uri $uri\/ \/index.php?$args;\n}<\/pre>\n
    Automated Origin IP Blackhole via Fail2ban Cloudflare API<\/h2>\n
    You can configure Fail2ban to communicate directly with Cloudflare’s REST API. When Fail2ban detects malicious Layer 7 floods locally, it dispatches an API request to Cloudflare to block the offending IP globally across all Cloudflare edge data centers.<\/p>\n
    Layer 7 DDoS Mitigation: Nginx FastCGI Microcaching vs Dynamic Floods<\/h2>\n
    When Layer 7 attackers flood dynamic WordPress PHP endpoints (like \/?s=random_query<\/code>), PHP-FPM processes and MySQL CPU usage immediately spike to 100%. Implementing Nginx FastCGI Microcaching<\/strong> caches dynamic HTML pages for 1 to 5 seconds, allowing your server to absorb tens of thousands of requests per second directly from memory without invoking PHP or MySQL:<\/p>\n
    # \/etc\/nginx\/conf.d\/microcache.conf\nfastcgi_cache_path \/var\/cache\/nginx levels=1:2 keys_zone=MICROCACHE:10m max_size=500m inactive=60m;\nfastcgi_cache_key \"$scheme$request_method$host$request_uri\";\n\nserver {\n    set $skip_cache 0;\n    if ($request_method = POST) { set $skip_cache 1; }\n    if ($query_string != \"\") { set $skip_cache 0; } # Cache search floods!\n\n    location ~ \\.php$ {\n        fastcgi_cache MICROCACHE;\n        fastcgi_cache_valid 200 301 302 2s; # Cache for 2 seconds\n        fastcgi_cache_use_stale error timeout updating invalid_header http_500;\n        fastcgi_no_cache $skip_cache;\n        fastcgi_cache_bypass $skip_cache;\n        include snippets\/fastcgi-php.conf;\n        fastcgi_pass unix:\/var\/run\/php\/php8.3-fpm.sock;\n    }\n}<\/pre>\n
    Testing DDoS Resilience with Simulated Load Tools<\/h2>\n
    Benchmark your server’s rate limiting and caching resilience using HTTP load-testing utilities like wrk<\/code> or vegeta<\/code> from an external test instance to verify that un-cached floods are successfully dropped before consuming server memory.<\/p>\n
    Mitigating Slowloris & Slow HTTP Post Attacks on Nginx<\/h2>\n
    Slowloris<\/strong> attacks keep thousands of HTTP connections open simultaneously by sending headers extremely slowly, exhausting the web server’s connection pool without triggering standard volumetric packet thresholds. Harden Nginx timeout directives to drop slow connection attempts aggressively:<\/p>\n
    # \/etc\/nginx\/conf.d\/anti_slowloris.conf\n# Aggressive timeouts to terminate slow-drip attacker sockets\nclient_body_timeout 10s;\nclient_header_timeout 10s;\nkeepalive_timeout 15s;\nsend_timeout 10s;\nreset_timedout_connection on;<\/pre>\n
    Automated Origin IP Blackhole Synchronization via Cron<\/h2>\n
    Cloudflare periodically updates its global reverse proxy IP ranges. Create an automated monthly cron script to ensure your UFW firewall rules remain synchronized with Cloudflare’s published CIDR blocks:<\/p>\n
    # \/etc\/cron.monthly\/update-cloudflare-ufw.sh\n#!\/bin\/bash\ncurl -s https:\/\/www.cloudflare.com\/ips-v4 -o \/tmp\/cf_ips.txt\nfor ip in $(cat \/tmp\/cf_ips.txt); do\n    sudo ufw allow from $ip to any port 80,443 proto tcp\ndone\nsudo ufw reload<\/pre>\n
    \n
    \n        \ud83d\udd17<\/span> Recommended Related Technical Guides:
    \n    <\/h3>\n