jtesta
please specify recommended connection trottling settings against
One aspect mentioned in #262 was connection trottling as a mitigation against CVE-2002-20001. However, the hardening guide that accompanies ssh-audit doesn't specify what the settings should be. As a result, playing with the settings keeps on producing the following line:
(nfo) Potentially insufficient connection throttling detected, resulting in possible vulnerability to the DHEat DoS attack (CVE-2002-20001). Suppress this test and message with the --skip-rate-test option. Additional info: 38 connections were created in 0.224 seconds, or 169.8 conns/sec; server must respond with a rate less than 20.0 conns/sec to be considered safe.
It would therefore be desirable for the hardening guide to specify the recommended values for MaxStartups, PerSourceMaxStartups, PerSourceNetBlockSize and any other setting meant to mitigate this.
This was already on my private to-do list, which will be handled within the next few days.
I'm still doing final tests on my end, but it seems so far there are two possibilities for handling CVE-2002-20001. The first is to use PerSourceMaxStartups 1. The pros include easy configuration. Cons include interference with ssh-audit tests, and possible legitimate use case failures (i.e.: if a client process attempts to create multiple SSH connections simultaneously). The other option is to use connection throttling through iptables. The following settings will allow 10 connections every 10 seconds per IPv4/IPv6 source address:
# iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
# iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP
# ip6tables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
# ip6tables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j DROP
Pros include a complete and flexible solution that won't interfere with any ssh-audit tests or legitimate use cases. Cons include... just a slightly more complex config? (Is that even a real con?)
I think that venturing into iptables falls outside the scope of OpenSSH configuration hardening.
What I was asking about (which the hardening guide should address) is how to achieve the recommended "server must respond with a rate less than 20.0 conns/sec to be considered safe."
The only two methods I know to reduce the rate of incoming connections in order to avoid the DoS condition is to use PerSourceMaxStartups 1 (which will interfere with ssh-audit group-exchange tests, along with some other use cases), or to use iptables.
I plan on updating the guides to list both methods, along with the pros & cons of each. The end users can then decide for themselves which they'd like to implement.
The key question was how to achieve "less than 20.0 conns/sec" and with which setting. PerSourceMaxStartups 1 would merely limit the number of connection per source to one. It would not limit the number of connections per second to 20 or less, as suggested.
I've revised the connection rate warning just now to:
(nfo) Potentially insufficient connection throttling detected, resulting in possible vulnerability to the DHEat DoS attack (CVE-2002-20001). 38 connections were created in 0.340 seconds, or 111.9 conns/sec; server must respond with a rate less than 20.0 conns/sec per IPv4/IPv6 source address to be considered safe. For rate-throttling options, please see <https://www.ssh-audit.com/hardening_guides.html>. Suppress this test and message with the --skip-rate-test option.
It points the user to the hardening guides, though as of right now, they don't include the updated instructions yet. I'll be adding that in the next few days.
The guides have been updated for Ubuntu Server 22.04 and Amazon Linux 2023. The rest will roll out over the next few days.
Now with the hardening guides updated, I think the original question has been answered.
The equivalent of the iptables configuration for firewalld would be:
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp --dport 22 -m state --state NEW -m recent --set
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j REJECT --reject-with tcp-reset
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT_direct 0 -p tcp --dport 22 -m state --state NEW -m recent --set
firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT_direct 1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 10 --hitcount 10 -j REJECT --reject-with tcp-reset
firewall-cmd --reload
