Re: SSH bruteforce on its way...

>> Nah, there were some exploits a while back that took advanteage in
>> some timing flaws in the SSHd that let attackers determin valid
>> usernames.
> Would you please provide some supporting references.  I can not find any
> evidence of existing timing attacks against openssh.  In fact Openssh
> goes to some trouble to defeat such attacks.

The worst thing I find is that ssh brute forcers have been harvesting email 
addresses and using the username portion in their brute force attempts (I'm 
seeing the regular ones like adm, apache, ftp, games, gopher, operator, root 
and also pretty much complete lists of the email@ names) so relying on 
obscurity no longer works, there's more then one way to harvest a username. 
[*]

Actually it happened in the PAM backend used by OpenSSH portable on Linux 
systems/etc:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-0190

Basically pam behaves differently when it comes to wrong username (no delay) 
vs. wrong username and password (enforced delay), you can prevent this by 
using the "nodelay" option in your pam configuration (/etc/pamd/sshd).

> While on this thread, one effective counter measure against brute force
> password attacks is to use decent passwords which everyone should be
> doing anyway.  We have lost about 3 systems here to ssh brute force
> attacks and in all cases the systems were in serious breach of our
> policies (which are not particularly draconian).

You can use PAM to restrict which users are allowed to login, from an older 
article of mine:

http://www.samag.com/documents/s=1161/sam0009a/0009a.htm

 Limiting User Access to Services
auth required /lib/security/pam_listfile.so \
   item=user sense=allow \
   file=/etc/imapusers-allow onerr=failThis can help (i.e. email users are 
allowed to authenticate to pop/imap/smtp but not say to ssh. You can also 
use OpenSSH's AllowUsers and AllowGroups in sshd_config to limit access to 
certain users or groups ("staff" for example), conversely you can use 
DenyUsers and DenyGroups ("users" for example) to restrict various users.

> In one case I did feel a bit sorry for the victims, they had installed a
> third party package that created an account with an insecure password
> and they never noticed.  A good case for simple monitoring script like
> the one that is run nightly on OBSD system that warns you about changes
> in critical files.

Or to lock those accounts out so they can't be used to login via ssh, telnet 
or other interactive services (see above). Least privilege and all that good 
stuff. Additionally requiring key authentication and preventing password 
based authentication ("PasswordAuthentication" in sshd_config) will pretty 
much squash any remote brute forcing attempts.

> Russell.

* Alternative ways:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-1013
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=user+enumeration
Web harvesting, email, usenet news (google groups is great for this) and so 
on.

-Kurt Seifried
http://seifried.org/freescan/