verify mechanism for protecting bbn-hn from SSH password-guessing attacks

[chaos@bbn.com]

The publically-accessible node bbn-hn allows password-based SSH login. Explain how the node is protected against password-guessing attacks. GPO will verify that the specified mechanism works before closing the ticket.

[jonmills@renci.org]

Originally it was RENCI policy to lock down sshd to trusted subnets using tcpwrappers, with iptables allowing all connections to port 22. This method couples explicit allows with a blanket deny. It does not prevent ssh dictionary attacks, but ensures that any such attack would have to come from a trusted IP range to be successful.

With ExoGENI, I began to set up DenyHosts? in favor of subnet restrictions. DenyHosts? is a daemonized python script that implements a filter system on top of tcpwrappers. It's methodology is a blanket allow, followed by pro-active explicit deny statements for any IP that fails to pass its filter tests. These deny statements can clearly be seen in /etc/hosts.deny on bbn-hn.

DenyHosts? has the advantage of allowing valid ssh connections from real ExoGENI users without the requirement that they be on VPN. (However, if these valid users mistype their passwords too many times, they too will fail the DenyHosts? filters and lock out the IP address from which they are connecting).

DenyHosts? will add an IP address to /etc/hosts.deny if a password is mis-typed 5 times AND the username given DOES exist in a defined passwd database (files, ldap). It will add an IP address much quicker if the username given DOES NOT exist in a defined passwd database, OR if the given username is root.

[chaos@bbn.com]

Just to update this ticket with the status: this is on my plate. I need to test the mechanism Jonathan outlined in the previous comment, and make sure it works.

[chaos@bbn.com]

Jonathan: heads-up. I'm testing this now. Assuming i succeed, i will need to make a request for you to remove my test source IPs from /etc/hosts.deny.

[chaos@bbn.com]

Jonathan: i have test results from this at ​http://groups.geni.net/geni/wiki/GENIRacksHome/ExogeniRacks/AcceptanceTestStatus/EG-ADM-2#Resultsoftestingstep1A:2012-07-23.

Capsule summary: it seems to work. Also note that root login is not permitted at all by sshd:

bbn-hn,[~],20:27(0)$ sudo cat /etc/ssh/sshd_config | grep Root
PermitRootLogin no

so that is the real protection against root password guessers.

More details/questions:

• I successfully locked out source IPs 128.89.91.28, 128.89.91.48, and 128.89.91.49. Can we unlock those? Is it as easy as removing the entries from /etc/hosts.deny, or is there state elsewhere as well?
• Logging in as user chaos, i was allowed to try 12 passwords (3 at a time). Logging in as invalid user xyzzy, i was allowed to try 6 passwords. As root, i was allowed to try 9 (but see above). Is all of that as expected?

[chaos@bbn.com]

Ping. Jonathan answered my first question via e-mail, saying:

Denyhosts saves state.  Editing /etc/hosts.deny is not sufficient, since
Denyhosts will just re-insert your IP.  You must edit
/var/lib/denyhosts/hosts-restricted

I also asked:

• Logging in as user chaos, i was allowed to try 12 passwords (3 at a time). Logging in as invalid user xyzzy, i was allowed to try 6 passwords. As root, i was allowed to try 9 (but see above). Is all of that as expected?

[chaos@bbn.com]

I still had one more minor outstanding question on this ticket:

• Logging in as user chaos, i was allowed to try 12 passwords (3 at a time). Logging in as invalid user xyzzy, i was allowed to try 6 passwords. As root, i was allowed to try 9 (but see above). Is all of that as expected?

[lnevers@bbn.com]

Are Chaos' findings as expected for this mechanism, please provide answer so this ticket may be resolved.

Replying to chaos@bbn.com:

I still had one more minor outstanding question on this ticket:

• Logging in as user chaos, i was allowed to try 12 passwords (3 at a time). Logging in as invalid user xyzzy, i was allowed to try 6 passwords. As root, i was allowed to try 9 (but see above). Is all of that as expected?

[jonmills@renci.org]

Those are probably the default settings in denyhosts.conf. It is totally customizable, so if you want different settings, just speak up. However, those settings are sufficient to prevent an SSH attack.

[chaos@bbn.com]

Sure, that seems fine.