A Practical Beginner’s Guide to DDoS Protection

Distributed Denial of Service (DDoS) attacks are no longer a “big company problem.” Even small projects, hobby APIs, and early-stage SaaS platforms get hit—often by low-effort attacks that are surprisingly effective against poorly configured systems.

This guide is not theoretical. It focuses on what actually matters when you’re trying to keep a service online under stress.

What a DDoS Attack Really Is (in practice)

At a high level, a DDoS attack is just resource exhaustion.

That resource could be:

  • CPU (expensive request processing)
  • Memory (too many concurrent connections)
  • Network bandwidth
  • Application-layer bottlenecks (database, cache misses, etc.)

Most beginners think in terms of “too many requests,” but the real issue is:

How expensive each request is for your system.

100 requests/second can kill your server if each request triggers heavy DB queries.

Layer Matters: L4 vs L7

You’ll often see these terms:

L4 (Transport layer)

  • TCP/UDP floods
  • Targets: network stack, connection tables
  • Mitigation: usually handled by infrastructure providers

L7 (Application layer)

  • HTTP floods, API abuse
  • Looks like legitimate traffic
  • Harder to detect

If you’re running a web app, L7 is your real problem.

Core Principle: Make Requests Cheap

Before adding “protection,” fix your baseline.

1. Cache aggressively

If your endpoint hits the database every time, you’ve already lost.

  • Use reverse proxy caching (e.g., Nginx, Varnish)
  • Cache full responses when possible
  • Cache even errors (like 404) briefly

2. Avoid dynamic bottlenecks

Common mistake:

SELECT * FROM users WHERE email = ?

on every request without index → instant bottleneck.

3. Precompute where possible

  • Static pages > dynamic rendering
  • Pre-render APIs if data doesn’t change often

Rate Limiting (Your First Real Defense)

This is the simplest and most effective control.

Basic idea:

Limit how many requests an IP (or token) can make in a time window.

Example (conceptually):

  • 100 requests per 10 seconds per IP
  • Burst allowed, but sustained abuse blocked

Implementation options:

  • Nginx: limit_req_zone
  • HAProxy: stick tables
  • Application-level (not ideal alone)

Important:

Don’t just block instantly—use progressive penalties:

  • Slow down
  • Then block

Use a Reverse Proxy (Mandatory)

Never expose your application directly.

A reverse proxy:

  • Absorbs connections
  • Applies rate limits
  • Handles TLS
  • Filters obvious garbage

Typical stack:

[Internet] → [CDN / Proxy] → [Nginx/HAProxy] → [App]

Hide Your Origin IP

If attackers know your real server IP, they can bypass your protection layer.

Do this:

  • Only allow traffic from trusted proxy IPs
  • Block direct public access to your origin
  • Use firewall rules strictly

Connection-Level Controls

DDoS isn’t just about request count—it’s also about open connections.

Mitigations:

  • Limit concurrent connections per IP
  • Reduce keep-alive timeout
  • Drop slow clients (slowloris-style behavior)

Example strategies:

  • Max 20 connections/IP
  • Timeout idle connections quickly

Logging and Visibility

You can’t defend what you can’t see.

Track:

  • Requests per IP
  • Response times
  • Error rates
  • Unusual spikes

Look for:

  • Same IP hitting many endpoints
  • High request rate with low success ratio
  • Patterns (user agents, paths)

Basic Filtering (Low Effort, High Impact)

You’d be surprised how much junk you can drop early.

Examples:

  • Block empty or invalid user agents
  • Deny known bad patterns
  • Restrict methods (e.g., only allow GET/POST)

This won’t stop a serious attack—but it removes noise.

CDN and Edge Protection

A CDN acts as a buffer between you and the attacker.

Benefits:

  • Absorbs large traffic spikes
  • Filters common attack patterns
  • Caches static content globally

Even a basic setup drastically improves resilience.

Fail Gracefully

You won’t always “win” against an attack. Plan for degradation.

Strategies:

  • Serve cached content when backend is overloaded
  • Disable non-critical features
  • Return simple responses instead of complex ones

Example:
Instead of:

{ "user": {...}, "recommendations": [...], "analytics": {...} }

Return:

{ "status": "degraded" }

Common Beginner Mistakes

  • Relying only on application-level rate limiting
  • No caching at all
  • Exposing origin IP directly
  • Unlimited database queries per request
  • No monitoring until things break

Minimal “Good Enough” Setup

If you’re starting out, aim for this:

  • Reverse proxy (Nginx or HAProxy)
  • Basic rate limiting
  • Full-page caching where possible
  • Firewall restricting origin access
  • Simple logging + alerting
  • CDN in front (optional but highly recommended)

Final Thoughts

DDoS protection is not about having a “magic shield.” It’s about:

  1. Reducing the cost of each request
  2. Limiting abusive behavior early
  3. Adding layers between attacker and application

Most attacks succeed not because they are powerful—but because the target is inefficient.

Fix that, and you’re already ahead of most systems online.

Experiencing DDoS attacks?

Our team can analyze and mitigate in real time.

Open ticket now

🆘 Need help with a DDoS attack?

If your server is under attack or you want proper protection:

👉 Create an account: https://miraiguard.com/app/register
👉 Open a support ticket with your case

The Mirai Guard team will review your situation and help you find the best protection strategy.