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/
