Protection against OpenSSH brute force and exploits

The latest versions of OpenSSH have protection against brute-force passwords, as well as exploit attempts. These are very valuable settings that the developers recommend everyone to use.

It should be noted that the new OpenSSH feature is fundamentally different from fail2ban, sshguard and similar tools, since it does not parse logs or change firewall rules, but applies options only within one program, without accessing anything through the kernel, which makes it much safer than the above-mentioned utilities.

In June commit OpenSSH developer Damien Miller has introduced new configuration options sshd(8): PerSourcePenalties And PerSourcePenaltyExemptList. As written in the commit, the changes introduce a “penalty for unwanted behavior.” In reality, they add a familiar option for many web applications – a delay after entering an incorrect password (first patch). And also protection against introducing such a delay for some clients (second patch).

Delay after input

As written in

documentation

if the function is enabled

PerSourcePenalties

then sshd(8) will monitor the final status of the pre-authentication session's children to detect failed authentication. Such conditions include situations where the client has repeatedly attempted to authenticate without success (this may indicate a brute-force attempt on one or more accounts) and where the client's behavior has caused sshd to crash (possibly an attempt to exploit sshd).

When such situations occur, sshd sets a penalty of a certain duration (e.g. 30 seconds) for that client. If the time exceeds the minimum threshold specified in PerSourcePenaltiesthen connections from that client address will be rejected (along with any others in the same range PerSourceNetBlockSize).

In case of repeated violation from the same address, fines will increase up to the maximum specified in the settings.

Arguments PerSourcePenalties are specified in the following format:

• crash:срок – how long to disable the client after the program crashes (by default) 90s);
• authfail:срок – how long to disconnect the client after one or more failed authentication attempts (default) 5s);
• noauth:срок – how long to disconnect a client that disconnected after an authentication attempt (default) 1s), this delay should be used carefully so as not to penalize legitimate scanners like ssh-keyscan(1);
• grace-exceeded:срок – how long to disconnect a client that has not passed authentication within the specified time LoginGraceTime (by default 20s);
• max:срок — the maximum time for which a specific client can be disconnected (by default) 10m), repeated fines are summed up to this amount;
• min:срок — the minimum time for which a client can be disconnected after accumulating fines (by default) 15s);
• max-sources4:number And max-sources6:number — maximum number of IPv4 and IPv6 address ranges for tracking fines (default) 65536 in both cases);
• overflow:срок — determines the server's behavior when the value in the previous parameter is exceeded: there are options deny-all (prohibit all incoming connections except those specified in PerSourcePenaltyExemptList) And permissive (allows new connections, default)
• overflow6:режим — allows you to specify a different overflow mode for IP:v6 addresses, the default is the same as specified for IPv4.

According to the documentation, the option

PerSourcePenalties

is already enabled by default with the default values ​​specified above. It can be disabled manually using the keyword

off

. You can also manually change the values ​​of all timeouts.

Protection from fines

Option

PerSourcePenaltyExemptList

exempts certain address ranges from all penalties. This ensures that there is no input delay for the system administrator himself.

If such protection is not installed, a situation is possible where an attacker will try to launch a DoS attack against the system administrator by introducing artificial penalties for him through intentionally unsuccessful authentication from his address range. If users are behind a NAT firewall, then several clients can use one IP address, so a penalty for one of them will affect the others. Thus, the administrator can suffer even accidentally.

In addition to protection, the option simply saves the administrator from the delay after an error when entering a password.

Other problems

Brute-force password guessing is not the only threat to SSH. Although it was fixed with the latest patch, other issues are yet to be addressed in the future.

Among them The following are called:

• The difficulty in managing SSH keys on hosts and clients results in a deplorable state of key management in many enterprises.
• Possibilities for MiTM attacks, which is related to poor storage conditions of secrets (see the problem above).

Of course, these are not so much problems for OpenSSH developers as for IT departments of enterprises and the entire IT industry. In general, enterprises are recommended to pay special attention to the key management system, organization of their storage and use.

By the way, there is another interesting program for protection against SSH brute force

Endless

which pretends to be an SSH server and puts attackers into an endless waiting loop, stretching sessions for hours or days. But this is more for fun and to mock attackers than for real protection.