[TriLUG] Securely and Accurately transmit passwords

[Kevin Hunter]

At 9:49p -0400 on 03 Oct 2007, Jon Carnes wrote:
> The maximum number of times I let folks try a password (before 
> locking the account for an hour) is 10 times. Tell me how some 
> cracker is going to use a dictionary attack and crack one of my 
> accounts. Unless he lucks into the password in the first 10 tries, 
> his app is simply going to be spinning its' wheels uselessly for the 
> next 59 minutes and 59 seconds...
> 
> Also, most admins I know use the security app Denyhosts.  It was 
> mentioned by someone else earlier in this thread. I have some very 
> strict Denyhost rules for my secure accounts (admin/root accounts).

Hrm.  I assume we're talking ssh here?  Pardon my naivety, but at the
point you have power users with admin privileges, why do you allow ssh
to root at all (except from within your network; even then . . .)?
What's wrong with good ol' "sudo su -"?  Second question, why don't you
use ssh keys with a passphrase for your admins?  (And with passphrases,
presumably refer back to this discussion :-P)

> If a hacker 

Hey now!  I consider myself a hacker!  Don't you mean cracker?  ;-)

> is trying to break into a secure account, the python app 
> Denyhosts locks out all the IP's used in his attacks. The hacker 
> would have to harvest the entire net to stand a chance of breaking 
> in, and even then he'll only have a window of opportunity of 10 
> attempts every hour.

Again, pardon my naivety (I'm fairly new to these waters), but assuming
you mean ssh why do you need to use the python app Denyhosts?  Can't
this be done at the firewall level (since ssh uses a new connection for
new login attempts)?  Something like this in the netfilter rule file:

# allow ssh connection attempts, both in- and out-going, but protect
# against brute force ssh attacks
$IPTABLES -A OUTPUT -p tcp -d 0/0 --dport 22 -j ACCEPT
$IPTABLES -A INPUT -p tcp -d 0/0 --dport 22 -m state --state NEW -m \
          recent --set --name SSH -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
          --hitcount 4 --rttl --name SSH -j LOG \
          --log-prefix "SSH Brute force"
$IPTABLES -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 \
          --hitcount 4 --rttl --name SSH -j DROP

This is what I have set up on my machine.  Does Denyhosts do it better?

... /me reads further posts before clicking send, then kicks self

Two different levels.  The firewall method blocks individual IPs but
still leaves accounts open to distributed attacks.  I assume denyhosts
blocks off the user account with /bin/false, *, !, or something?  The
description touts that it doesn't need firewall built into the kernel;
but if you've netfilter compiled in, wouldn't the firewall approach be
less expensive cpu-wise?

Questioning my security practices,

Kevin