Know the kind of attack

See what is happening right now

Count the connections per IP address to the web ports. A few addresses with hundreds of connections point to a connection flood:

ss -Htn state established '( sport = :80 or sport = :443 )' | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -n | tail

Check the load with uptime and the busiest processes with htop. If the server is calm but the network is saturated, the attack is volumetric and must be stopped upstream. Contact support.

Option 1: CSF connection limits (recommended)

If you run CSF, use its built-in limits instead of a separate script. In /etc/csf/csf.conf:

# Block an IP that holds more than 150 connections (checked every 30 seconds)
CT_LIMIT = "150"
CT_INTERVAL = "30"
CT_PORTS = "80,443"

# Limit concurrent connections per IP for each port
CONNLIMIT = "22;5,80;50,443;50"

# Limit new connections per IP over time (port;proto;hits;seconds)
PORTFLOOD = "80;tcp;100;5,443;tcp;100;5"

Restart CSF with csf -r. Start with generous values and lower them if needed: visitors behind a shared office or mobile network can open many connections from one address. Do not set the limits too low on sites behind Cloudflare, because all traffic arrives from Cloudflare’s addresses.

Option 2: DDoS-Deflate

DDoS-Deflate is a small shell script that runs every minute, counts connections per IP address, and blocks addresses over a limit for a set time, using iptables, CSF or APF. The maintained version is the jgmdev/ddos-deflate project on GitHub. Its settings are in /etc/ddos/ddos.conf, mainly the connection limit, the ban period and an ignore list for your own addresses.

If you use it, download it from the project page, read the install script before you run it as root, and add your own IP addresses and monitoring services to the ignore list. Do not run it together with CSF connection limits; choose one.

Option 3: protect the website itself

• Cache pages so most requests never reach PHP. A cached page costs the server almost nothing.
• Rate-limit login and search pages, which attackers target because they are expensive to serve.
• Use Cloudflare or a similar service in front of the site. It absorbs floods and can challenge suspicious visitors. See our Cloudflare and cPanel guide.
• Use a web application firewall such as ModSecurity to block abusive request patterns.

On Nginx, a simple rate limit for a login page looks like this:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    # ...your usual PHP settings
}

Option 4: network-level protection

Large attacks must be filtered before they reach your server. Several UnderHost products include DDoS protection at the network level; check the product page of your plan for what is included, or ask support. During an attack, open a ticket with the time, the target IP address and what you see, so the network team can act.

During an attack: a short checklist

1. Confirm the attack: connection counts, load, and network graphs.
2. Contact support with the details, especially if the network is saturated.
3. Turn on Cloudflare’s Under Attack mode if the site is behind Cloudflare.
4. Block the worst source addresses in the firewall, and tighten rate limits on the targeted pages.
5. Keep notes and logs, so you can tune your protection afterwards.