Skip to main content

DDoS Protection at ZevsHost: How It Works

Security · 12.03.2025 · 6 min read
Illustration for “DDoS Protection at ZevsHost: How It Works”

DDoS protection on ZevsHost

Every ZevsHost server is protected against DDoS attacks at the L3, L4 and (in the USA and OVH data centers) L7 levels. The goal of such an attack is not to steal data but to make a service unavailable to regular visitors by exhausting some resource: channel bandwidth, server compute, or the limit on simultaneous connections.

DDoS stands for Distributed Denial of Service. The key word is "distributed": the attack does not come from a single address that can simply be blocked, but from thousands or millions of infected devices at once (a botnet). That is exactly why protection is built on analysing traffic patterns rather than a list of specific malicious IPs.

Protection levels

  • L3 — filtering malicious traffic at the network level (IP addresses, protocols)
  • L4 — protection at the transport protocol level (TCP/UDP flood)
  • L7 — protection at the application level (HTTP flood, slowloris)

What typical attacks look like

Attack typeLevelSign in logs or monitoring
SYN floodL4Many half-open TCP connections in the SYN_RECV state
UDP amplification (DNS, NTP)L3/L4A sharp rise in inbound traffic from someone else's open DNS/NTP servers
HTTP floodL7Thousands of identical GET requests from different IPs to the same URL
SlowlorisL7Many open connections that stay open but transfer almost no data

L3 and L4 are filtered at the edge of the provider's network before traffic ever reaches your server. L7 requires understanding the logic of the HTTP protocol, so it is available only on platforms with the matching equipment — see the table above.

How to tell an attack from an organic spike

Not every sharp rise in traffic is an attack. The difference shows up in the request pattern:

  • An organic spike (for example, after media coverage) — varied URLs, varied User-Agents, behaviour resembling regular visitors.
  • An attack — repetitive requests to a single URL or endpoint, an abnormally small spread in time between requests, many requests from subnets that are not typical for your audience.

Automatic filtering sometimes errs in both directions: it can let a slow attack spread out over time pass as normal load, or it can briefly slow down responses to legitimate users during a sudden surge of interest in the site. False positives cannot be eliminated entirely — the goal of a protection system is to keep them noticeably smaller than the real damage from a missed attack.

What happens during an attack

  1. The system automatically detects anomalous traffic
  2. Malicious packets are filtered before reaching the server
  3. Legitimate traffic passes through without delay
  4. The monitoring team is alerted about large attacks

What DDoS protection does not cover

  • A password brute force from one or a few IPs using a small number of requests — that is not DDoS by volume, it is stopped by fail2ban and a login attempt limit, not a network filter.
  • A vulnerability in application code exploited with individual requests — traffic filtering does not check the logic of your code.
  • An overload from your own legitimate audience growth — that calls for a scalable server and caching, not attack protection.

During an attack

Open a support ticket — we can apply additional filtering rules.

While the ticket is being handled, part of the response can be done yourself if you have access to the server and, where it is used, to the Cloudflare panel:

  • Turn on Under Attack Mode in Cloudflare if the domain is already connected — it adds an intermediate browser check before every request.
  • Temporarily limit the number of simultaneous connections from a single IP on Nginx with limit_conn, to reduce load from individual aggressive clients while filtering is not yet at full strength.
  • Note the exact time the attack started and save a sample of the logs — this speeds up the analysis on the support side and the selection of precise filtering rules.

How to verify that filtering is actually working

  1. Look at the response headers on a normal request — on platforms with L7 through Cloudflare they include cf-ray, confirming that traffic passed through the filtering node.
  2. During a real attack, compare the volume of inbound traffic on the network interface (vnstat or a monitoring panel) with the load on the service itself — with filtering working, the service stays responsive even at a large inbound volume.
  3. After the incident, ask support for a filtering report — legitimate requests should not appear among the dropped packets.

How to set up an extra layer of protection through a proxy in front of the server is covered in DDoS protection with Nginx and Cloudflare, and basic firewall rules are covered in UFW on a VPS.

Frequently asked questions

Do I need to set up or pay separately for DDoS protection on ZevsHost servers?

There is no separate setup or payment required: L3 and L4 protection runs automatically on every ZevsHost server without extra configuration. L7 protection depends on the data center, available only where matching hardware for analyzing HTTP traffic is installed, so it follows from the hosting location chosen, not a separate client action.

What should be done if filtering accidentally slows down access for regular visitors?

False positives cannot be fully avoided: during a sudden surge of interest in a site, filtering sometimes briefly slows responses even for regular visitors. If delays are noticeable and persist, it makes sense to open a support ticket so filtering rules get adjusted manually, reducing such cases instead of waiting for the load to settle on its own.

Does DDoS protection defend against a break-in through a vulnerability in the site's code?

No. Network traffic filtering only analyzes request patterns and volume, not the logic of your application, so a vulnerability exploited through a handful of individual requests is neither detected nor blocked by it. Protection against that kind of attack comes from updating the code, a security audit, and monitoring the application's own logs, a separate task from network-level filtering.

What can be done on your own while a support ticket is still waiting to be handled?

While the ticket is being handled, you can turn on Under Attack Mode in Cloudflare if the domain is already connected there, adding an extra browser check before every request. On Nginx it helps to temporarily limit connections from a single address, and note the exact time the attack started, saving a log sample for support.

Was this article helpful?
← Back to Knowledge Base Ask Support