Mitigation strategies for SSH denial of service attacks

SSH denial of service is basic hardening for any homelab that exposes SSH. The fixes are small, but the risk is real: a service can be flooded until it stops responding. Cisco’s IEC6400 advisory shows how a missing flood protection can make SSH go quiet while the rest of the device keeps running.

Start with sshd_config and set explicit limits for unauthenticated activity. Useful lines I run in my lab are:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 2
UseDNS no
MaxStartups 10:30:60
X11Forwarding no
AllowTcpForwarding no
HostbasedAuthentication no
AllowUsers youruser

MaxStartups 10:30:60 allows bursts, then starts dropping new unauthenticated connections once the table fills. Lock access to specific accounts with AllowUsers or AllowGroups. These changes narrow the attack surface and make an SSH denial of service harder to trigger with simple connection floods.

Add network-level rate limiting and access controls. If your host runs nftables or iptables, add a connlimit rule for TCP port 22. A practical nftables example looks like this:

add rule inet filter input tcp dport 22 ct count over 10 drop

Use fail2ban to parse auth logs and temporarily ban sources that attempt many sessions or failed logins. For a homelab that needs remote admin, put SSH behind a VPN or a bastion host. I use WireGuard as a jump point; the SSH port is not publicly exposed. Hiding the port is not security by itself, but a VPN with connlimits and strict SSH settings gives defence in depth. If you control a small edge router, push rate limits there rather than relying only on the server.

Plan the response before an incident happens. Logging and monitoring matter for denial of service as much as for intrusion. Set OpenSSH LogLevel to VERBOSE during testing so you capture connection patterns, then revert to INFO for normal use. Forward logs to a small syslog server or central journald instance so you can spot spikes: sudden hundreds of SYNs or many half-open sessions are a clear sign.

Keep a short runbook with three actions: apply a temporary firewall block for offending IP ranges, tighten connlimits, and capture a pcap of the traffic for analysis. If the device supports vendor updates, prioritise fixes that mention SSH flood protection. The Cisco IEC6400 advisory is a reminder that vendors do ship fixes for this class of flaw. Disabling SSH is still an option if you genuinely do not need remote shell access.

Test the setup regularly. Run scans with ssh-audit and nmap from an isolated test network to see how the service behaves under load. Simulate a denial of service in a controlled environment with hping3 or another traffic generator, then watch whether MaxStartups and connlimits hold and whether SSH still accepts legitimate connections. Audit the configuration twice a year, check installed OpenSSH versions for CVEs, and keep a short checklist beside the router console: patch date, last config test, fail2ban enabled.

Patch devices that list SSH flood fixes first, tighten sshd_config, apply connlimits at the host or router, use fail2ban and a VPN or bastion for remote access, and keep a tested runbook for temporary blocks and traffic capture.