DDoS Basics for Website Owners: Symptoms, Triage and Protection

A distributed denial-of-service (DDoS) attack tries to make a website unavailable by overwhelming it with traffic or requests from many sources at once. Most small sites will never be a deliberate target, but any public site can get caught up in one, and the first minutes of confusion are expensive. This guide is for owners and admins, not security specialists: what a DDoS is, how to tell it apart from a harmless traffic surge or an ordinary fault, which basic protections to set up before anything happens, and what to do and say when it does.

What a DDoS attack is

"Denial of service" means legitimate users cannot use the service. "Distributed" means the traffic comes from a large number of machines, often compromised devices, so you cannot just block one address. The attacker's goal is exhaustion: use up some limited resource so that real visitors are crowded out. There are three broad families, defined by the resource targeted.

Volumetric attacks

These try to fill the bandwidth of your network connection or your provider's. The packets are mostly meaningless; the point is volume. If the pipe is full, nothing real gets through. You cannot defend against this from your own server, because by the time traffic reaches it the link is already saturated. Defense has to happen upstream, at a network large enough to absorb it.

Protocol attacks

These abuse how network protocols work to exhaust state in servers, firewalls or load balancers. A SYN flood, which fills the table of half-open TCP connections, is the classic example. Larger cases need upstream filtering.

Application-layer (layer 7) attacks

These send requests that look like normal web traffic, such as thousands of requests for a search page or login endpoint, aimed at exhausting CPU, database connections or application workers. They need far less bandwidth to hurt you, because each request is expensive to answer. They are the hardest to separate from real users, and the ones a small site is most likely to meet.

Brute-force login attempts and aggressive scrapers cause similar slowness without being a DDoS in the strict sense. The defenses overlap.

Symptoms: attack, traffic spike or ordinary fault?

Slowness and errors have many causes. Before you declare a DDoS, compare the evidence.

Useful questions to ask in order:

1. Did anything change on our side? Deploys and updates cause most outages. See why is my website down.
2. Did marketing send traffic? A campaign, mention or sale is the most common cause of a good spike. Ask the team.
3. What do the logs say? Look at requests per minute, top URLs, top IP addresses and top user agents. A genuine spike is spread across many pages and many ordinary browsers. An attack is concentrated and uniform.
4. Is it global? Use down from where to see whether the site fails everywhere or only from some networks.
5. Which layer fails? The outage root cause finder helps distinguish DNS, connection, TLS and HTTP failures. A timeout at connection level is a different story from a 503 from the application.

A few commands to see the shape of traffic on a typical nginx server (adjust paths to your setup):

# Requests per minute (nginx access log, default format)
awk '{print substr($4,2,17)}' /var/log/nginx/access.log | sort | uniq -c | tail -20

# Top requesting IP addresses
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Most requested paths
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Look up the busiest addresses with the IP lookup tool: a cluster from one cloud provider's range tells a different story than a spread of consumer ISPs.

Basic protection to set up before you need it

You do not need an enterprise budget. A few layers go a long way, and most of them are cheaper to set up on a calm day.

1. Put a CDN or reverse proxy in front

A CDN absorbs volumetric and protocol attacks in capacity your origin lacks, and serves cached pages without touching your server. Many include DDoS mitigation on all plans, but details differ, so read your provider's current documentation. See CDN explained और Cloudflare setup for DNS and SSL modes. Confirm that a CDN is actually active with the CDN detector.

2. Hide your origin address

A CDN only protects you if attackers cannot reach the origin directly. If your real server IP is discoverable, for instance through old DNS records, a mail server on the same address or a forgotten subdomain, traffic can bypass the CDN. To reduce this:

• Allow web traffic to the origin only from your CDN's published IP ranges, using the firewall.
• Review old DNS history and subdomains. See subdomain takeover and dangling DNS.
• Consider changing the origin IP if it has been exposed and you now rely on a CDN.

3. Cache aggressively

Every request answered from cache is one that does not touch your application. Cache anonymous pages at the CDN. See Cloudflare cache rules and purge. Static pages can survive heavy traffic that a dynamic, uncached page cannot.

4. Use a web application firewall (WAF)

A WAF filters requests using rules: known bad signatures, suspicious patterns, bots, countries you choose to challenge. Managed rule sets from your CDN are the easy starting point. Country blocking and strict rules can block real customers, so use them carefully.

5. Add rate limiting

Rate limits cap how many requests one client can make in a window. Apply stricter limits to expensive endpoints: login, search, password reset, checkout, XML-RPC and API routes. At the CDN this is usually a dashboard rule. On nginx you can do it at the server:

# in the http block
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# in the server or location block
location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    limit_req_status 429;
    # ... your normal handling
}

Tune limits to real traffic: too low and you block legitimate users who share an IP, such as an office.

6. Know your hosting limits

Cheap hosting often offers only best-effort protection, and some hosts null-route an attacked site to protect other customers. Ask your host in advance what is included and how to escalate. Read choose web hosting for uptime और VPS vs shared hosting reliability. The website hosting checker will show where you are hosted.

7. Monitor it

An external uptime monitor tells you when the site stops responding, and response-time history shows the slow build-up that often comes first. See alert fatigue and on-call basics.

What to do during an attack

1. Confirm and note the time. Record when it started, what you see, and from where. This is your evidence.
2. Tell your hosting provider immediately. Use the fastest channel they offer (phone or emergency ticket). Give them:
3. Affected domain(s), server IP(s), and the start time with time zone
4. What you observe: errors, timeouts, bandwidth graph, top paths and addresses from the logs
5. Whether a CDN or firewall is in front, and any changes you made
6. What you want: mitigation, filtering, or a temporary IP change
7. Turn on stricter protection at your CDN. Many CDNs offer an elevated-protection mode that challenges visitors before serving pages (Cloudflare calls it "Under Attack Mode"). It adds friction for real users, so turn it off when the event is over.
8. Reduce load temporarily. Serve cached pages for expensive routes and turn off search, comments and other non-essential features.
9. Communicate. Post a short message on your status page. See status page communication templates. Keep it factual: "We are experiencing degraded availability and are working with our providers."
10. Do not pay a ransom if one arrives; report it to your host and, where appropriate, law enforcement.
11. Preserve logs for later.

After the attack

Write up an incident postmortem covering what worked and which gaps remain. Check whether your SLA or hosting terms exclude attacks, because many do; see SLA uptime calculation.

अगले कदम

• Check whether you are behind a CDN with the CDN detector.
• Start external checks with the uptime monitor.
• Find out where failures occur with down from where.
• Read CDN explained और Cloudflare setup for DNS and SSL modes.
• Prepare your announcements with the status page tool.

सामान्य प्रश्न

Is my small website likely to be attacked?

Direct targeting of small sites is uncommon, but automated abuse such as bot floods and login attacks is common. Basic CDN, caching and rate limiting protect you against most of it.

How can I tell a DDoS from a viral spike?

Look at the traffic shape. A real spike spreads across pages and ordinary browsers and matches a campaign or mention. An attack concentrates on a few URLs with uniform, automated-looking requests.

Will a free CDN stop a DDoS?

It can absorb a lot, especially volumetric floods, if your origin is hidden behind it. Features and limits differ by provider and plan, so check their current documentation.

Should I take my site offline during an attack?

Usually no. Try stricter CDN protection and cached pages first. Going offline gives the attacker what they wanted, though your host may need to null-route you if the attack threatens other customers.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.