01Why
An exposed SSH port is under credential-stuffing traffic around the clock
Scanning botnets sweep the whole routable IPv4 space and try password lists against every host answering on TCP/22. An SSH daemon reachable from the internet receives that traffic whether the host is a corporate bastion or a single VPS.
- Thousands of failed authentications per day
- A new host answering on TCP/22 starts logging failed SSH authentications within hours of its address becoming routable. A typical internet-facing server records thousands of "Failed password" and "Invalid user" events in systemd-journald every day, arriving from address ranges that rotate faster than any single administrator can review them.
- CPU, memory and journal writes spent on traffic that will never authenticate
- Every SSH authentication attempt costs a TCP handshake, an SSH key exchange, a PAM lookup through /etc/pam.d/sshd, and one synchronous write into systemd-journald. A sustained brute-force stream therefore holds permanent background load on the host, inflates journal storage, and pushes real administrative logins behind sshd's MaxStartups queue - none of which the attacker has to authenticate to achieve.
- One guessed credential is a full compromise
- A single correct password grants an interactive shell with that account's privileges: ransomware staging, data exfiltration, or outbound spam attributed to the host's own address. Passwords that are weak or reused from a public breach corpus fall to a dictionary run within days, and the SSH authentication log records the successful attempt exactly like any other line.
- pam_faillock turns the attack into a lockout of the real administrator
- The PAM stack configured in /etc/pam.d/sshd counts consecutive failures with pam_faillock and locks the account once the deny threshold is reached. An attacker who has guessed only a valid username - never the password - can therefore trip that counter deliberately and lock the genuine administrator out of the host. The result is a denial of service produced entirely by the defence mechanism.
SSH Protector moves the decision from userspace to the netfilter input hook
The SSH Protector daemon correlates failed authentication events per source network and commits one nftables rule that drops the attacker's entire /24. Once that rule exists, netfilter discards the packets in the kernel's input hook, before sshd accepts a connection, before a PAM lookup runs and before anything is written to the journal - so CPU usage, journal volume and the number of guesses reaching the password check all fall at the same time.
