Bug in widely used OpenSSH opens servers to password cracking

[Chiefcrowe]

http://arstechnica.com/security/201...ed-openssh-opens-servers-to-password-cracking

 

[John Connor]

Does anyone know if DD-WRT uses OpenSSH?

I have these IPtables.

#SSH Protection iptables -N rate_limit iptables -F rate_limit iptables -A rate_limit -p tcp --dport 22 -m limit --limit 3/min --limit-burst 3 -j ACCEPT iptables -A rate_limit -p udp --dport 22 -m limit --limit 3/min --limit-burst 3 -j ACCEPT iptables -A rate_limit -p ICMP --icmp-type echo-request -m limit --limit 3/sec -j ACCEPT iptables -A rate_limit -p ICMP -j LOG --log-prefix " Connection dropped!! " iptables -A rate_limit -p tcp -j REJECT --reject-with tcp-reset iptables -A rate_limit -p udp -j REJECT --reject-with icmp-port-unreachable iptables -A rate_limit -j DROP iptables -I INPUT -p tcp --dport 22 -m state --state NEW -j rate_limit iptables -I INPUT -p udp --dport 22 -m state --state NEW -j rate_limit iptables -A INPUT -i vlan1 -p igmp -j DROP iptables -I INPUT -i vlan1 -d 192.168.0.0/16 -p igmp -j DROP iptables -A INPUT -i vlan0 -p igmp -j DROP iptables -I INPUT -i vlan0 -d 192.168.0.0/16 -p igmp -j DROP

Some might be redundant. I changed my port here. It's not 22.

 

[A5]

If you're using an open source project that has an SSH server, it is almost certainly OpenSSH.

Based on my understanding of the vulnerability, rate limiting the connection won't do anything, because it is just spinning inside of one connection to try passwords.

That said, your best protection (for now) is the same as anything else: use strong passwords or Pub/Priv key auth on your SSH accounts.

 

[matricks]

Most projects aimed at embedded devices (routers and other with limited space and resources) use Dropbear, not OpenSSH. I can confirm this is the case for OpenWrt. I see DD-WRT has Dropbear source in its tree, and OpenSSH is not immediately apparent in said tree, so I'd guess DD-WRT uses Dropbear too, but I can't check. Just run ps, and look for openssh-server or sshd. OpenWrt offers OpenSSH as an installable package, but it's not included in any official build.

Rate limiting connections may mitigate this vulnerability to some extent (depending on rule specifics), but fail2ban and similar will be more effective. Fail2ban looks at (failed) authentication attempts, and even if 10000 attempts happen in a single TCP session, it will register as failed login attempts, and trigger fail2ban if it is configured to do so.

 

[TheRyuu]

Disabling password authentication will mitigate this bug as well. If you can disable it you should (e.g. only priv/pub key authentication).

 

[John Connor]

If you're using an open source project that has an SSH server, it is almost certainly OpenSSH.

Based on my understanding of the vulnerability, rate limiting the connection won't do anything, because it is just spinning inside of one connection to try passwords.

That said, your best protection (for now) is the same as anything else: use strong passwords or Pub/Priv key auth on your SSH accounts.

When I made the key it is like 4096. And I believe I read that it should be higher than 2048 or something. So that's good I guess. I don't use port 22 either.

 

[John Connor]

Most projects aimed at embedded devices (routers and other with limited space and resources) use Dropbear, not OpenSSH. I can confirm this is the case for OpenWrt. I see DD-WRT has Dropbear source in its tree, and OpenSSH is not immediately apparent in said tree, so I'd guess DD-WRT uses Dropbear too, but I can't check. Just run ps, and look for openssh-server or sshd. OpenWrt offers OpenSSH as an installable package, but it's not included in any official build.

Rate limiting connections may mitigate this vulnerability to some extent (depending on rule specifics), but fail2ban and similar will be more effective. Fail2ban looks at (failed) authentication attempts, and even if 10000 attempts happen in a single TCP session, it will register as failed login attempts, and trigger fail2ban if it is configured to do so.

Interesting. I do use DD-WRT.