{"id":416,"date":"2026-09-01T17:07:06","date_gmt":"2026-09-01T17:07:06","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=416"},"modified":"2026-09-01T09:30:37","modified_gmt":"2026-09-01T09:30:37","slug":"what-is-a-ddos-attack-vps-protection-guide","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/what-is-a-ddos-attack-vps-protection-guide\/","title":{"rendered":"What Is a DDoS Attack? A Practical VPS Protection Guide"},"content":{"rendered":"
Table of Contents<\/strong><\/p>\n
    \n
  1. What Is a DDoS Attack, and How Does It Affect a VPS?<\/a><\/li>\n
  2. Identify the attack before choosing the fix<\/a><\/li>\n
  3. The first five minutes: collect evidence before restarting<\/a><\/li>\n
  4. Defenses you can apply on the VPS<\/a><\/li>\n
  5. Why the provider and CDN layers matter<\/a><\/li>\n
  6. Monitoring, logging, and the cleanup after an attack<\/a><\/li>\n
  7. When should you resize the VPS or change the architecture?<\/a><\/li>\n
  8. Shortcuts that cause more trouble<\/a><\/li>\n
  9. A practical DDoS checklist for your VPS<\/a><\/li>\n
  10. Frequently asked questions<\/a><\/li>\n<\/ol>\n<\/div>\n

    What Is a DDoS Attack, and How Does It Affect a VPS?<\/h2>\n

    When three monitoring alerts appear during a night shift, my hand does not go straight to reboot<\/code>. I first check where the traffic is coming from, which port is filling up, and how much of the machine’s resources are actually being consumed. During a DDoS event, an impatient reboot may not stop anything. It can erase useful evidence and clear the active connection table.<\/p>\n

    DDoS stands for Distributed Denial of Service. It describes an attempt to make a server or service unavailable by sending a large volume of requests or traffic from many sources. The target is not always a website. DNS, game servers, SSH, APIs, and the public IP address of a VPS can all be attacked.<\/p>\n

    The word distributed<\/em> matters. Because the traffic does not come from one computer, blocking a single IP address is rarely enough. Attackers may use botnets made up of compromised devices. Some attacks consume bandwidth, while others exhaust connection tables. HTTP-like attacks can use CPU and database capacity without producing an enormous amount of network traffic.<\/p>\n

    I think about DDoS protection in two layers: reducing resource consumption inside the VPS, and filtering unwanted traffic at the data center or upstream provider. Your own configuration helps with the first layer. The second may require your hosting provider’s DDoS service, a scrubbing center, or a CDN.<\/p>\n

    Identify the attack before choosing the fix<\/h2>\n

    Not every traffic spike is a DDoS attack. A newly published campaign, a search-engine crawl, a broken cron job, or a link shared by a customer can all create a short-lived increase. Calling it an attack without checking the evidence is expensive. So is treating a real attack as normal traffic.<\/p>\n

    Volumetric attacks fill the connection<\/h3>\n

    These attacks aim to consume the capacity of your internet connection. UDP floods, ICMP floods, and large DNS response floods belong to this category. Even if you write an nftables<\/code> rule on the VPS, the packets usually reach the data-center uplink first. Once the connection is full, rejecting packets on the server does not give bandwidth back to legitimate users.<\/p>\n

    For volumetric attacks, the response usually starts with the provider. Traffic must be filtered before it reaches the VPS, or redirected to a scrubbing service. A local firewall can help during a small, short-lived burst, but it cannot create extra network capacity.<\/p>\n

    Protocol attacks consume connection resources<\/h3>\n

    A SYN flood tries to exhaust resources during TCP connection setup. When large numbers of half-open connections accumulate, the backlog and conntrack tables can come under pressure. Ordinary users then struggle to establish connections as well.<\/p>\n

    SYN cookies, connection limits, and provider-side filtering can help here. Randomly increasing sysctl<\/code> values is not a complete fix. Larger tables can give an attacker a larger space to fill, while also increasing RAM consumption.<\/p>\n

    Small changes matter. Blind changes do not.<\/p>\n

    Application-layer attacks can look ordinary<\/h3>\n

    HTTP floods, slow requests, and expensive API calls may look like normal web traffic from the outside. Requests arrive on port 443, TLS completes successfully, and nginx or Apache passes them to the application. The traffic volume may not look enormous, but if every request starts a PHP worker, a MySQL query, or an external API call, the VPS can run out of breath quickly.<\/p>\n

    This is where CDN filtering, web-server rate limits, caching, authentication, and application-level quotas need to work together. Blocking IP addresses alone is usually insufficient; a botnet may contain thousands of addresses.<\/p>\n

    The first five minutes: collect evidence before restarting<\/h2>\n

    During an incident, I want the diagnostic phase to stay short and repeatable. I start with the provider’s traffic graph, resource usage, and any available DDoS alert. Then I connect over SSH and take a general snapshot of the system. If SSH is also affected, the provider’s console may be the safer route.<\/p>\n

    date\nhostname\nuptime\nfree -h\nip -s link\nss -s<\/code><\/pre>\n
    Do not skip the hostname<\/code> line. My production prompts are red for a reason: I want this check to be impossible to miss. ip -s link<\/code> shows interface-level packet and error counters, while ss -s<\/code> gives a rough summary of TCP states. None of these commands proves that a DDoS attack is happening on its own.<\/p>\n
    To inspect a particular port, I use a narrower query:<\/p>\n
    ss -Htan state syn-recv | wc -l\nss -Htan '( sport = :80 or sport = :443 )' | head -20\nss -Huan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head<\/code><\/pre>\n
    The first command counts half-open TCP connections. The second displays a sample of HTTP and HTTPS connections. The third roughly counts UDP endpoints; do not trust this short awk<\/code> pipeline blindly when IPv6 addresses or different output formats are involved.<\/p>\n
    During an incident, I also save the output:<\/p>\n
    ss -s > \/root\/incident-ss-$(date +%F-%H%M).txt\njournalctl -k --since \"10 minutes ago\" > \/root\/incident-kernel.log<\/code><\/pre>\n
    Kernel logs may show drops, SYN-flood messages, conntrack warnings, or network-driver errors. The absence of a log message does not prove the absence of an attack; some counters rise without producing a log entry.<\/p>\n
    I once changed a remote firewall without opening a second SSH session first. The existing connection stayed alive, fortunately, so I could correct the rule instead of using the provider console. Since then, I keep a second session open before touching a remote firewall. Boring is good during an incident.<\/p>\n
    Defenses you can apply on the VPS<\/h2>\n
    Close ports you do not need<\/h3>\n
    Every publicly exposed service is part of your attack surface. First, list the services that are listening:<\/p>\n
    sudo ss -lntup<\/code><\/pre>\n
    I pay particular attention to services listening on 0.0.0.0<\/code> or ::<\/code>. In many setups, PostgreSQL, Redis, and MySQL have no reason to be reachable from the public internet. When installing and securing MySQL, check its bind address and firewall access together; a strong password by itself is not enough.<\/p>\n
    At the firewall, allow only the ports you actually use. A simple nftables<\/code> starting point for SSH, HTTP, and HTTPS could look like this:<\/p>\n
    table inet filter {\n  chain input {\n    type filter hook input priority filter; policy drop;\n\n    iifname \"lo\" accept\n    ct state established,related accept\n    ip protocol icmp accept\n    ip6 nexthdr ipv6-icmp accept\n    tcp dport 22 ct state new limit rate 15\/minute accept\n    tcp dport { 80, 443 } accept\n  }\n\n  chain forward { type filter hook forward priority filter; policy drop; }\n  chain output { type filter hook output priority filter; policy accept; }\n}<\/code><\/pre>\n
    Adjust this example for your distribution, remote-access policy, and IPv6 setup. If you have a fixed administration IP, restrict the SSH rule to that address instead. The rate limit here applies to new SSH connections as a group, not separately to every source address.<\/p>\n
    When changing a remote firewall, I open a second session first. That habit saved me once. A small omission can become a long walk to the provider console.<\/p>\n
    Move SSH away from the center of attention<\/h3>\n
    Changing SSH from port 22 to another port is not security. It may reduce some automated scanning noise, but the controls that matter are key-based authentication, disabled root login, current OpenSSH packages, and firewall restrictions.<\/p>\n
    sudoedit \/etc\/ssh\/sshd_config<\/code><\/pre>\n
    PermitRootLogin no\nPasswordAuthentication no\nMaxAuthTries 3<\/code><\/pre>\n
    Check the configuration before reloading it:<\/p>\n
    sudo sshd -t && sudo systemctl reload ssh<\/code><\/pre>\n
    On Ubuntu and Debian, the service is usually called ssh<\/code>; some distributions use sshd<\/code>. Test a new key-based login without closing the current session. If you use a fixed administration network, combine these settings with a firewall allowlist and a VPN such as WireGuard.<\/p>\n
    Use rate limits at the web server<\/h3>\n
    At the HTTP layer, nginx’s limit_req<\/code> and limit_conn<\/code> modules can protect selected endpoints. Login, search, and expensive reporting APIs should not necessarily have the same limits as ordinary pages.<\/p>\n
    http {\n    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r\/m;\n    limit_conn_zone $binary_remote_addr zone=addr:10m;\n\n    server {\n        limit_conn addr 30;\n\n        location = \/wp-login.php {\n            limit_req zone=login_limit burst=3 nodelay;\n            include fastcgi_params;\n            # Keep your existing PHP-FPM settings here.\n        }\n    }\n}<\/code><\/pre>\n
    This is not a WordPress recipe to copy into every installation. Many real users behind a NAT gateway may share one public IP, so an IP-based limit can affect them all. Quotas based on an API key, session, or user account may be more accurate at the application layer.<\/p>\n
    After changing the configuration:<\/p>\n
    sudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n
    Do not reload nginx until nginx -t<\/code> succeeds. I have seen rate limits added while every anonymous request remained uncached. That wastes the protection you already paid for with CPU and database work. Serve anonymous, cacheable content from the edge or nginx whenever possible.<\/p>\n
    Why the provider and CDN layers matter<\/h2>\n
    If your VPS is receiving hundreds of megabits per second, local firewall rules may still process the packets. But if the connection capacity assigned to the VPS is full, legitimate traffic cannot get in. At that point, a local rule has limited value; filtering must happen closer to the traffic source.<\/p>\n
    When contacting your hosting provider, send measurable details instead of simply saying “the site is slow”:<\/p>\n