Denial-of-Service Symptoms

A Debian-first guide to identifying traffic floods, overloaded services, and resource exhaustion symptoms, then containing pressure and restoring stability.

What this is

Denial-of-service symptoms appear when a service, system, or network path becomes overloaded to the point that normal use is degraded or unavailable. This can come from malicious traffic, accidental load, poorly protected endpoints, or resource exhaustion caused by a specific application path.

The goal is not only to recognize that the system is under pressure, but to identify what is being overwhelmed and from where.

What it looks like

Web pages time out or become extremely slow
CPU, memory, or connection counts spike unexpectedly
Large volumes of requests from one or many IPs
Services restart, crash, or stop responding under load

Detect

Review current system load

uptime
free -h
ps aux --sort=-%cpu | head -n 20
ps aux --sort=-%mem | head -n 20

Review active connections

sudo ss -tan
sudo ss -tulnp

Count repeated source IPs in web logs

sudo awk '{print $1}' /var/log/caddy/*.log 2>/dev/null | sort | uniq -c | sort -nr | head

Review recent web service activity

sudo journalctl -u caddy --since "30 minutes ago"

Review firewall logs for blocked pressure

sudo grep "UFW" /var/log/ufw.log | tail -n 100

Contain

Block a clearly abusive source IP if the pressure is concentrated

sudo ufw deny from <IP_ADDRESS>

Reduce public exposure of nonessential services

sudo ufw status numbered
sudo ss -tulnp

Restart a degraded service if needed after pressure is reduced

sudo systemctl restart caddy

Stop nonessential local services temporarily to preserve resources

sudo systemctl list-units --type=service --state=running

Recover

Review which path or service absorbed the pressure

sudo journalctl -u caddy --since "2 hours ago"
sudo ss -tan

Review system stability after containment

uptime
free -h
ps aux --sort=-%cpu | head -n 20

Check for related follow-on abuse

sudo grep -Ei "Accepted|sudo|useradd|adduser" /var/log/auth.log
ps auxf
sudo ss -tpn

Recovery means restoring service stability and determining whether the issue was pure traffic pressure or part of a broader attack chain.

Prevent

Option 1 — Reduce nonessential public exposure

sudo ss -tulnp
sudo ufw status numbered

Option 2 — Review logs for repeated high-volume paths

sudo journalctl -u caddy --since "24 hours ago"

Option 3 — Keep the service stack lean and updated

sudo apt update
sudo apt upgrade
sudo systemctl list-units --type=service --state=running

Option 4 — Watch connection counts and resource usage during incidents

sudo ss -tan
uptime
free -h

Option 5 — Plan for service isolation where practical

# Separate critical public services from unnecessary background workloads

Optional Tools & Hosting

Manual containment and service review should come first. Over time, this section may include carefully selected infrastructure options that make traffic handling or isolation easier, but the immediate Debian-side priority is visibility, exposure reduction, and service stability.

Notes

Not every denial-of-service symptom is a large distributed attack; some are caused by one weak endpoint.
The first priority is preserving service and understanding what is under pressure.
Repeated overload can reveal application paths that need hardening even if the system survives.

Environment Note

All commands shown are based on Debian-based systems unless otherwise noted.