Opened 13 years ago

Closed 12 years ago

#34 closed (fixed)

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

Reported by: chaos@bbn.com Owned by: jonmills@renci.org
Priority: major Milestone: EG-ADM-2
Component: Administration Version: SPIRAL4
Keywords: Cc:
Dependencies:

Description

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.

Change History (9)

comment:1 Changed 13 years ago by jonmills@renci.org

Owner: changed from somebody to jonmills@renci.org
Status: newassigned

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.

comment:2 Changed 12 years ago by 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.

comment:3 Changed 12 years ago by 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.

comment:4 Changed 12 years ago by 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?

comment:5 Changed 12 years ago by 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?

comment:6 Changed 12 years ago by 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?

comment:7 in reply to:  6 Changed 12 years ago by 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?

comment:8 Changed 12 years ago by 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.

comment:9 Changed 12 years ago by chaos@bbn.com

Resolution: fixed
Status: assignedclosed

Sure, that seems fine.

Note: See TracTickets for help on using tickets.