DoS vs DDoS: How Denial-of-Service Attacks Work and How to Defend

If your website or application suddenly grinds to a halt and nobody can reach it, one possible cause is a denial-of-service attack. The goal of these attacks is simple and disruptive: overwhelm your server with so much junk traffic or so many bogus requests that real customers can no longer get through. For an online business, that means lost sales, frustrated users and a damaged reputation.

This article explains the difference between a DoS and a DDoS attack in plain language, shows how the common attack types work, lists the warning signs, and walks through a practical, layered defence you can apply to your Momo Cloud server. This is defensive content only: there are no instructions here for launching attacks, and running a denial-of-service attack against systems you do not own is illegal.

DoS vs DDoS: what is the difference?

A Denial-of-Service (DoS) attack comes from a single source — one machine or one connection trying to exhaust your server's resources. Because it has a single origin, it is comparatively easy to identify and block.

A Distributed Denial-of-Service (DDoS) attack comes from many sources at once — often thousands of compromised devices (a "botnet") spread across the globe. Each source sends a modest amount of traffic, but together they can bury your server. Because the traffic comes from countless different addresses, you cannot simply block one IP and be done with it.

How the attacks work

Denial-of-service attacks generally fall into three families. Understanding them helps you choose the right defence.

Volumetric (bandwidth) floods

These aim to saturate your network link by sending massive amounts of data — far more than your connection can carry. UDP floods and amplification attacks fall into this category. Once your pipe is full, legitimate packets simply cannot get in. These are almost always distributed, and they are the hardest to absorb on the server alone because the damage happens upstream, before traffic even reaches you.

Protocol attacks (e.g. SYN floods)

These abuse the way network protocols establish connections. In a SYN flood, the attacker sends a stream of connection requests but never completes the handshake, leaving your server holding thousands of half-open connections until it runs out of capacity to accept new ones. The traffic volume can be modest, but the effect is the same: legitimate users are turned away.

Application-layer (L7) attacks

These target your application directly, usually over HTTP/HTTPS. An HTTP flood sends a torrent of seemingly valid requests — for example, repeatedly hitting a search page or login form — that force your server to do expensive work (database queries, page rendering) for each one. Because each request looks legitimate, these attacks are stealthy and can take down a site with relatively little bandwidth.

Warning signs

An attack rarely announces itself. Watch for these symptoms, which you can correlate with the resource graphs on your server detail page in the client area:

• Sudden, unexplained slowness — pages that loaded instantly now take many seconds.
• The site or server becomes unreachable — timeouts, 502/503 errors, or SSH that will not connect.
• Traffic spikes with no business reason — a sharp jump in requests or bandwidth that does not match a campaign or news event.
• CPU, memory or connection counts pinned at maximum on your resource graphs.
• A flood of requests from a narrow set of IPs or odd user-agents in your access logs.

Tip: Genuine traffic surges (a viral post, a sale) can look similar to an attack. Check your logs and analytics first — if the requests are spread across real pages from varied, plausible visitors, you may simply need more capacity rather than a defence response.

Defend in layers

No single control stops every attack. Effective protection stacks several layers, so that traffic is filtered the furthest away from your server possible, and whatever gets through is rate-limited and recoverable.

1. Put a CDN/WAF in front of your site

The single most effective step for most websites is to route traffic through a Content Delivery Network with a Web Application Firewall, such as Cloudflare. The CDN sits between visitors and your origin, absorbs volumetric floods across its global network, hides your real server IP, and lets a WAF filter out malicious L7 requests before they ever reach you. Point your domain through the CDN and only allow your origin to accept traffic from it.

2. Configure a proper firewall (ufw)

On Ubuntu, ufw gives you a simple, effective default-deny firewall. Open only the ports you actually need and close everything else. Run these as root or with sudo:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Warning: Always allow SSH (ufw allow OpenSSH) before running ufw enable, or you can lock yourself out. If that happens, you can still get back in via the in-browser Console/VNC on your VPS server detail page.

3. Rate-limit at the web server (nginx)

Rate limiting caps how many requests a single client can make, which blunts HTTP floods and brute-force attempts against login pages. Define a shared memory zone in the http block of /etc/nginx/nginx.conf:

http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
}

Then apply it inside the relevant server or location block in your site config. The burst allows short, legitimate spikes, while nodelay serves the burst immediately and rejects anything beyond it:

server {
    location / {
        limit_req zone=req_limit burst=20 nodelay;
        limit_req_status 429;
        # ... your existing proxy_pass / root config ...
    }
}

Test the configuration and reload without dropping connections:

nginx -t
systemctl reload nginx

4. Block repeat offenders with fail2ban

fail2ban watches your logs and temporarily bans IPs that misbehave — for example, addresses that trip the nginx rate limit or hammer SSH. Install and enable it:

apt update
apt install fail2ban
systemctl enable --now fail2ban

Create /etc/fail2ban/jail.local so your settings survive package updates, enabling the nginx and SSH jails:

[sshd]
enabled = true

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
logpath  = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime  = 3600

systemctl restart fail2ban
fail2ban-client status nginx-limit-req

5. Keep software patched

Many attacks exploit known, already-fixed vulnerabilities. Apply security updates promptly and consider enabling unattended upgrades:

apt update && apt upgrade
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

6. Have backups and snapshots ready to recover

Defence is not only about prevention — it is about getting back online quickly if something does break. On your Momo Cloud VPS detail page you can take snapshots and backups. Take a snapshot before any major change, and keep recent backups so that if an attack is paired with a compromise, you can roll back to a known-good state rather than rebuilding from scratch.

If you suspect an attack right now

Tip: During a suspected DDoS, the most important action is to open a support ticket with Momo Cloud immediately from the client area at cloud.momo.tz. Volumetric attacks are best stopped upstream, before traffic reaches your server, and our team can apply network-level mitigations that you cannot apply yourself. Support is available 24/7 in English and Swahili.

While you wait, gather evidence: note the start time, capture a sample of your access and error logs, and check the resource graphs on the server detail page. That information helps support diagnose the attack type and respond faster.

Wrapping up

DoS and DDoS attacks try to drown your service in junk traffic, but they are not unbeatable. A single-source DoS can usually be handled on the server with a tight firewall, nginx rate limiting and fail2ban. A distributed DDoS needs help further upstream — a CDN/WAF in front of your site and your hosting provider's network mitigations. Layer these defences, keep your software patched, and keep recent snapshots so you can recover quickly.

If you would like a server with the controls described here, you can spin up a VPS from the Momo Cloud client area at cloud.momo.tz — and if you ever think an attack is under way, open a support ticket straight away so our team can step in.