DDoS Attack Explained: Types, Symptoms, and Protection

A DDoS attack (distributed denial-of-service attack) is an attempt to make a server, network, or application unavailable by flooding it with traffic or requests from many sources at once. A DDoS protected server defends against this by detecting the malicious traffic and filtering it upstream, before it reaches your machine or saturates your link.

This guide covers how DDoS attacks work, the three main categories, the symptoms you will see, what you can and cannot fix on the server itself, and how network-level protection works.

How a DDoS attack works

A normal denial-of-service attack comes from one source, so you can block one IP address. A distributed attack comes from thousands or millions of sources, so blocking individual addresses does not help.

Attackers typically use one or more of these:

• Botnets: compromised servers, routers, IoT cameras, and PCs that take commands from an attacker.
• Reflection and amplification: the attacker sends small requests with a spoofed source IP (your IP) to open servers, such as misconfigured DNS, NTP, or memcached. Those servers send much larger replies to the victim.
• Rented stresser/booter services: cheap, point-and-click attack tools that make attacks accessible to unskilled people.

The goal is always to exhaust a finite resource: bandwidth, packet-processing capacity, connection tables, or application CPU.

The three main types of DDoS attacks

1. Volumetric attacks (bandwidth exhaustion)

These attacks try to fill your internet link. Common examples are UDP floods and DNS, NTP, or memcached amplification. The traffic is mostly junk, and its only purpose is to consume capacity.

The key point: if the attack is larger than your uplink, nothing you do on the server will help. The packets have already filled the pipe before they reach your firewall. This is why volumetric attacks must be stopped upstream.

2. Protocol attacks (state exhaustion)

These target weaknesses in how network protocols and devices handle connections. They exhaust the connection tables of servers, firewalls, and load balancers, usually at Layers 3 and 4.

• SYN flood: the attacker sends many TCP SYN packets and never completes the handshake, which fills the half-open connection queue.
• ACK/RST floods: packets that do not belong to any connection and force the stack to do pointless lookups.
• Fragmentation attacks: malformed or fragmented packets that are expensive to reassemble.

These attacks can be small in bandwidth but large in packets per second (pps). A 1 Gbps link can be overwhelmed by a pps-heavy flood of tiny packets even when the bandwidth graph looks fine.

3. Layer 7 (application) attacks

These look like legitimate traffic. A botnet requests expensive pages, hits login or search endpoints, or opens many slow connections (Slowloris-style). Every request is valid HTTP, but together they exhaust your web server, database, or API.

They are low in bandwidth, so link graphs may look normal while your application slows to a crawl. They are also the hardest to separate from a real traffic spike.

Symptoms of a DDoS attack

One symptom alone does not prove an attack. Look for a combination:

• Sudden, sustained spike in inbound traffic or packets per second
• Website or game server unreachable or extremely slow, with no deployment or config change
• Packet loss and high latency to your IP from multiple locations
• Many connections from a large number of unrelated IPs
• SSH sessions lagging because the link itself is saturated
• Traffic dominated by one protocol or port (for example, UDP to a port you do not use)
• Your provider null-routes your IP

A marketing campaign, a crawler, or a viral post can look similar. The difference is the traffic content: attack traffic is usually uniform, repetitive, and does not follow normal user behavior.

Quick triage on a Linux server

These commands help you tell what kind of traffic you are seeing. Replace eth0 with your interface.

Check packet and bandwidth rates live:

sar -n DEV 1 5
# or
ip -s link show eth0

Count half-open TCP connections (SYN flood indicator):

ss -n state syn-recv sport = :443 | wc -l

See the top source IPs sending SYN packets:

tcpdump -nn -i eth0 -c 5000 -l 'tcp[tcpflags] & tcp-syn != 0' \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head

Check what protocols dominate:

tcpdump -nn -i eth0 -c 2000 udp | awk '{print $5}' | sort | uniq -c | sort -nr | head

If you see a few IPs with huge counts, you may be dealing with a simple flood. If the counts are spread evenly across thousands of addresses, it is distributed, or the source addresses are spoofed.

What you can do on the server itself

Host-level hardening helps with small protocol and Layer 7 attacks. It does not help with volumetric attacks.

Enable SYN cookies:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Rate-limit new connections with nftables (tune the numbers to your normal traffic, or you will block real users):

nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; }'
nft add rule inet filter input tcp dport 443 ct state new limit rate over 200/second drop

Rate-limit expensive HTTP endpoints in nginx:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
    }
}

Common mistakes:

• Relying on the host firewall for a volumetric attack. The link is already full. Fix: filter upstream.
• Setting rate limits too low. Users behind carrier-grade NAT share one IP and get blocked. Fix: measure normal traffic first and leave headroom.
• Leaving open resolvers or NTP servers. Your server can become part of someone else's reflection attack. Fix: restrict recursion and disable unneeded monlist-style features.
• Not knowing your baseline. Without normal traffic numbers, you cannot recognize an attack quickly. Fix: collect flow or interface statistics all the time.
• Exposing the origin IP behind a proxy. Attackers bypass the proxy and hit the origin directly. Fix: firewall the origin so it accepts traffic only from the protection layer.

How a DDoS protected server defends you

Effective protection works at the network level, in front of your server. The process has four parts:

1. Detection. Flow data (NetFlow, sFlow, or IPFIX) from edge routers is analyzed for anomalies such as sudden pps growth, unusual protocol mix, or traffic to a single destination. Flow-based detection is fast and does not slow down the traffic itself.
2. Mitigation. Malicious traffic is dropped or filtered at the network edge, using techniques like stateless filtering, protocol validation, rate limiting, and signature or behavior-based rules. Spoofed and malformed packets are discarded.
3. Clean traffic delivery. Legitimate traffic continues to your server. For a hosted server, this happens inside the provider's network. For customers with their own network, it can be delivered over a tunnel.
4. Visibility. You need graphs and alerts that show what was dropped and why, so you can tune rules and confirm that the attack has ended.

Filtering must happen on infrastructure with more capacity than the attack, and it must happen before your last-mile link. That is the main difference between a protected server and a regular one with a firewall.

Protection with your own ASN and IP space

If you operate your own ASN and prefixes, protection can be done at the routing layer. Your traffic is attracted to a scrubbing network, cleaned, and returned to you, commonly through a GRE tunnel that carries a BGP session. This keeps your own IP addresses while the filtering happens upstream.

At Nixcon, which operates AS40368 with locations in Izmir (Turkey), Frankfurt, and Fremont, California, this is available as NixGuard Edge. Customers can also run a BGP session from a VDS and choose DDoS-protected or unprotected announcements. For a regular hosted server, see our DDoS protection and firewall page.

Detection and monitoring matter as much as filtering

You cannot respond to what you cannot see. If you run your own network, flow-based monitoring shows which destination IPs and ports are receiving attack traffic, and alerts you in time to trigger mitigation. NixMon provides flow-based network monitoring and DDoS detection for this purpose.

You can also check how your network is reachable from different regions with the public looking glass, which supports BGP route, ping, and traceroute queries from Izmir, Frankfurt, and the US.

A simple response checklist

1. Confirm the attack: compare current traffic with your baseline and check the traffic type.
2. Identify the target IP, protocol, and port.
3. Contact your provider early; do not wait until the service is fully down.
4. Apply host-level limits only for what the host can handle (SYN cookies, rate limits).
5. Make sure the origin IP is not directly reachable if you use a proxy layer.
6. Keep logs and flow data for later analysis.
7. After the attack, review what slowed you down and tune the rules.

Summary

DDoS attacks fall into three categories: volumetric attacks that fill your link, protocol attacks that exhaust connection state, and Layer 7 attacks that exhaust your application. You can handle small protocol and application attacks with careful hardening, but anything that saturates your link has to be stopped upstream. Choose protection that detects quickly, filters at the network edge, and gives you visibility.