How to detect a DDoS attack on your VPS in under 30 seconds?

Learning how to detect DDoS VPS attacks quickly can mean the difference between 30 seconds of downtime and hours of service disruption. In 2026, distributed denial-of-service attacks have grown more sophisticated, targeting virtual private servers with precision—yet the fundamental signs remain identifiable with the right commands and monitoring approach. This guide walks you through a practical, 30-second diagnostic workflow using native Linux tools, then explains how kernel-level protection layers like XDP and nftables fit into your detection and mitigation strategy.

Whether you're running game servers, API endpoints, databases, or web applications on a VPS, DDoS detection should be a reflex—not a mystery. We'll cover the essential signals: abnormal packet rates, connection state anomalies, bandwidth saturation, and protocol-specific patterns. By the end of this article, you'll have a repeatable checklist to diagnose attacks in real time, understand the distinction between legitimate traffic spikes and malicious floods, and know which metrics matter most at the kernel level.

The 30-Second DDoS Detection Checklist for VPS

When you suspect an ongoing attack, speed is critical. Open an SSH session to your VPS and run this sequence of commands in under 30 seconds to gather the essential data points:

# 1. Check interface packet rate (5-second sample)
sar -n DEV 1 5 | grep eth0

# 2. Inspect current connection states
ss -s

# 3. List top source IPs by connection count
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10

# 4. Review recent kernel drops (XDP, nftables, iptables)
nft list ruleset inet pakkt | grep counter
dmesg | tail -20 | grep -i 'drop\|flood'

Let's decode each step:

• sar -n DEV: Displays packets-per-second (pps) and bytes-per-second for each network interface. A sudden spike from 10,000 pps to 500,000+ pps is a strong indicator.
• ss -s: Summarizes socket statistics—TCP states (ESTAB, SYN-RECV, TIME-WAIT), UDP sockets. A SYN-RECV count above several thousand often signals a SYN flood.
• netstat + awk pipeline: Extracts source IPs and counts active connections. A single IP with 1,000+ connections is suspicious unless it's a known load balancer or CDN.
• nft list ruleset: If you're using nftables (especially the inet pakkt table deployed by PAKKT.io), counters show how many packets each rule has processed or dropped.
• dmesg: Kernel ring buffer may log XDP or conntrack drops if your system is under extreme load or has XDP programs attached.

Within 30 seconds, you'll know: (1) whether packet rates are abnormal, (2) which IPs dominate your connection table, and (3) if kernel-level filters are already mitigating traffic. This rapid triage determines your next move—block offending subnets, enable rate-limits, or escalate to upstream scrubbing if the attack exceeds your VPS capacity.

Understanding Attack Signatures: Volume vs. Protocol Exploitation

Not all DDoS attacks look alike. To detect DDoS VPS events accurately, you must distinguish between two primary categories:

Volumetric Attacks

Volumetric floods aim to saturate your network interface or upstream bandwidth. Common vectors include:

• UDP amplification: DNS, NTP, SSDP, memcached reflection attacks generating hundreds of megabits or millions of packets per second.
• ICMP floods: Ping floods that consume bandwidth and interrupt legitimate traffic.
• Generic UDP floods: Random-source UDP packets targeting game server ports (e.g., 25565 for Minecraft, 27015 for Source Engine).

Detection signals: sar -n DEV shows rxpck/s (received packets per second) jumping from baseline (e.g., 5,000 pps) to 200,000+ pps. Interface utilization approaches line rate. ss -s may show normal TCP states but a massive count of UDP sockets or raw sockets.

Protocol and State-Exhaustion Attacks

These exploit server resources—CPU, memory, connection tables—without necessarily saturating bandwidth:

• SYN floods: Half-open TCP connections fill the SYN queue. ss -s reports thousands of SYN-RECV states.
• ACK floods: Invalid ACK packets force the kernel to traverse conntrack tables, wasting CPU cycles.
• HTTP GET floods / Slowloris: Application-layer attacks that appear as legitimate connections but exhaust worker threads or file descriptors.

Detection signals: CPU usage spikes (check top or htop for ksoftirqd processes consuming cores). Connection count grows but bandwidth remains moderate. Application becomes unresponsive even though interface utilization is only 20–30%.

Kernel-level mitigation—XDP for volumetric, nftables with conntrack for state-exhaustion—handles each category differently. XDP operates before the kernel allocates an skb (socket buffer), so it can drop millions of packets per second with sub-microsecond latency per packet. Nftables with connection tracking (conntrack) inspects TCP flags and connection states, rate-limiting new connections per source IP using ct state new limit rate rules.

Practical Example: SYN Flood Detection

# Check SYN-RECV backlog
ss -tan | grep SYN-RECV | wc -l

# Inspect SYN cookies (kernel defense mechanism)
sysctl net.ipv4.tcp_syncookies

# Review nftables meter for per-IP new-connection rate
nft list ruleset inet pakkt | grep 'ct state new'

If SYN-RECV count exceeds your configured net.ipv4.tcp_max_syn_backlog (default often 512–1024), the kernel activates SYN cookies—a stateless fallback that sacrifices TCP options but prevents resource exhaustion. Observing this behavior confirms a SYN flood. A well-configured nftables rule, such as:

nft add rule inet pakkt input tcp dport 25565 ct state new limit rate 50/second accept

…will rate-limit new TCP connections to 50 per second per rule, mitigating the attack before the SYN queue overflows.

Kernel-Level Visibility: XDP and nftables Counters

Traditional userspace tools (tcpdump, Wireshark) introduce latency and CPU overhead during high-pps attacks. Kernel-level telemetry—XDP maps and nftables counters—provides real-time visibility without copying packets to userspace.

XDP Map Inspection

If you're running an XDP program (like the PAKKT Engine), BPF maps store rules and counters. To inspect:

# List all BPF maps
bpftool map list

# Dump the pakkt_rules map (rule definitions)
bpftool map dump name pakkt_rules

# Dump the pakkt_stats map (per-rule packet/byte counters)
bpftool map dump name pakkt_stats

Each entry shows packets processed, dropped, or passed. A sudden spike in the drop counter for a specific rule (e.g., rule_id 5 blocking UDP port 19132) confirms that XDP is mitigating an attack at wire speed. Because XDP runs before the kernel's networking stack allocates memory for packets, dropped packets consume minimal CPU—often just a few nanoseconds per packet on modern hardware.

nftables Counters and Logs

The inet pakkt table deployed by PAKKT Integrations (Pterodactyl, public API) includes counters on every rule:

nft list ruleset inet pakkt

Look for lines like:

counter packets 1523420 bytes 91405200 drop

A counter incrementing by thousands per second indicates active filtering. You can also enable logging for specific rules during diagnostics:

nft insert rule inet pakkt input ip saddr 203.0.113.0/24 log prefix "BLOCKED_SUBNET: " drop

Then monitor /var/log/kern.log or dmesg for the prefix. Remember to remove verbose logging after diagnosis to avoid disk I/O bottlenecks.

Advantages Over Userspace Packet Capture

Method	Latency Impact	CPU Overhead	Max Throughput
tcpdump / Wireshark	High (packet copy to userspace)	High (multiple cores saturated)	~100k pps before drops
XDP + BPF maps	Sub-microsecond per packet	Negligible (< 1% per core)	Several million pps
nftables counters	Low (kernel context)	Low (< 5% per core)	Hundreds of thousands pps

During an active attack, relying on XDP and nftables telemetry keeps your VPS responsive for SSH access and mitigation adjustments, whereas launching tcpdump might lock up the system entirely.

Automated Detection: Metrics, Alerts, and Centralized Dashboards

Manual diagnostics are essential for rapid triage, but continuous monitoring prevents attacks from going unnoticed. Modern kernel-level protection platforms integrate telemetry pipelines that stream XDP and nftables metrics to centralized dashboards.

Metrics to Track

• Packets per second (pps) per interface: Baseline vs. current. A 10× spike warrants investigation.
• Drops per rule: XDP map counters and nftables rule counters. High drop rates confirm active mitigation.
• Top source IPs and countries: GeoIP data highlights attack origins. A sudden surge from a single ASN or country is suspicious.
• Connection states: SYN-RECV, ESTABLISHED, TIME-WAIT trends. Anomalies indicate protocol attacks.
• CPU and memory utilization: Correlate with packet rates to distinguish volumetric from resource-exhaustion attacks.

Real-Time Dashboards and Alerts

Platforms like PAKKT.io aggregate these metrics into a single pane of glass: real-time world map (GeoIP), per-port/rule charts (powered by TimescaleDB), and audit logs. When packet rates exceed a configured threshold, webhook alerts notify your team via Slack, Discord, or PagerDuty. The 30-second heartbeat from the Go agent ensures the dashboard reflects ground truth with minimal lag.

For example, if your Minecraft server on port 25565 suddenly receives 300,000 UDP pps from a botnet distributed across 50 countries, the dashboard will:

• Highlight the port in red on the per-rule chart.
• Plot source IPs on the world map, color-coded by packet volume.
• Increment the drop counter for the corresponding XDP rule in real time.
• Trigger an alert if the attack persists beyond 60 seconds.

This visibility empowers you to adjust rate-limits, expand IP blacklists, or activate more aggressive rulesets without SSH-ing into each node—critical when managing fleets of VPS instances across multiple regions.

Integration with Existing Stacks

Because the PAKKT agent deploys nftables rules in an isolated inet pakkt table, it coexists peacefully with Docker iptables rules, fail2ban chains, and iptables-persistent configurations. Your existing monitoring stack (Prometheus, Grafana, Zabbix) can also scrape bpftool map dump outputs or parse nft list ruleset counters via node_exporter textfile collectors. This layered approach gives you both centralized SaaS convenience and local observability.

Post-Detection: Immediate Mitigation Steps

Once you've confirmed a DDoS attack using the 30-second checklist and kernel-level telemetry, mitigation follows a priority ladder:

1. Activate or Refine XDP Rules

If the attack targets a specific port or protocol, deploy or adjust an XDP rule. For instance, block all ICMP traffic:

# Pseudo-command (actual deployment via PAKKT panel or API)
# XDP rule: protocol=ICMP, rule_type=block

The stateless nature of XDP means rules take effect immediately—no connection tracking overhead, no state synchronization. Dropped packets never enter the kernel's network stack, preserving CPU for legitimate traffic.

2. Enforce Per-IP Rate Limits with nftables

For SYN floods or connection-based attacks, add a nftables meter rule:

nft add rule inet pakkt input tcp dport 443 meter https_ratelimit { ip saddr limit rate 100/minute burst 20 packets } accept
nft add rule inet pakkt input tcp dport 443 drop

This permits up to 100 packets per minute per source IP (with a burst allowance of 20), dropping excess traffic. Meters are stateful and per-source, so legitimate users spread across many IPs remain unaffected.

3. Expand IP Blacklists

If the top-10 source IPs from your netstat output are clearly malicious, blacklist them at both layers:

• XDP BPF map: Wire-speed drop before any packet processing.
• nftables set: Stateful inspection for any packets that bypass XDP (e.g., local-origin traffic).

Centralized panels automate this synchronization—add an IP to the blacklist once, and the agent updates both XDP map and nft set within seconds.

4. Consider Upstream Scrubbing for Saturating Attacks

If your VPS uplink (1 Gbps, 10 Gbps) is fully saturated—e.g., 15 Gbps inbound—kernel-level protection cannot help because packets are dropped by your datacenter's edge routers before reaching your NIC. In this scenario:

• Activate upstream DDoS scrubbing (e.g., OVH VAC, Cloudflare Spectrum) to filter traffic before it reaches your VPS.
• Keep kernel-level XDP/nftables active as a secondary defense layer for attacks that slip through or target non-scrubbed ports.

Kernel protection and cloud scrubbing are complementary, not mutually exclusive. XDP handles the "last mile" on your server, while upstream scrubbing absorbs the bulk of volumetric floods.

Conclusion

Learning to detect DDoS VPS attacks in 30 seconds transforms reactive firefighting into proactive defense. By combining rapid command-line diagnostics—sar, ss, netstat, nft, bpftool—with kernel-level telemetry from XDP and nftables, you gain the visibility and speed required to mitigate threats before they cascade into prolonged outages. Centralized dashboards and automated alerting extend this capability across entire server fleets, ensuring that no attack goes unnoticed. In 2026, the fusion of eBPF efficiency and stateful firewall precision gives VPS operators the tools to stand resilient against even sophisticated, distributed adversaries.

FAQ

Can I detect a DDoS attack on my VPS without installing additional software?

Yes. Native Linux commands like sar -n DEV, ss -s, netstat, and nft list ruleset provide immediate visibility into packet rates, connection states, and firewall counters. However, continuous monitoring and real-time alerts require either custom scripts polling these commands or a dedicated telemetry agent that streams metrics to a centralized dashboard.

What packet rate threshold indicates a DDoS attack on a typical VPS?

Baseline packet rates vary widely by application—a busy web server might see 10,000–50,000 pps during normal operation, while a game server could handle 5,000–20,000 pps. A sudden 5–10× spike (e.g., jumping to 200,000+ pps) within seconds is a strong indicator. Context matters: inspect source IP diversity, protocol distribution, and connection states to confirm whether the surge is attack traffic or a legitimate flash crowd event.

How do XDP and nftables differ in DDoS detection and mitigation?

XDP operates at the earliest possible point—immediately after the NIC driver, before the kernel allocates socket buffers—making it ideal for dropping volumetric floods (UDP amplification, ICMP) at multi-million pps rates with negligible CPU impact. Nftables runs later in the stack, with access to connection tracking (conntrack) and stateful inspection, enabling it to mitigate protocol attacks like SYN floods using per-IP rate limits and TCP flag validation. Both layers are complementary: XDP for raw speed, nftables for intelligent state-aware filtering.