This one time, at band camp, Justin Pryzby said:
> Package: ssh
> Version: 1:3.8.1p1-8.sarge.4
> Severity: critical
> File: /usr/sbin/sshd
> Tags: security
> Justification: root security hole
This part seems like panic - it's a user level security hole, if it
exists.
This one time, at band camp, Greg Webster said:
> On Fri, 2005-06-17 at 12:51 -0400, Justin Pryzby wrote:
> > You're talking about microsecond delays, right?
>
> Nope...human-discernable delays. Give it a shot on your system. I can
> easily determine just by mentally counting, if an account is valid.
I think I remember seeing a report that in PAM using setups, there was a
noticeable delay introduced by PAM. I was under the impression it was
addresses, however. Let me try ... OK, I see no difference on a sarge
machine that isn't probably induced by me (half a second difference
between valid user/invalid password and invalid user/random password,
averaged over 5 tries of each). The difference is too small for me to
notice it with the eye, at any rate.
> > > This attack is already in the wild, as shown in logs:
This is a random username attack. It has been going on for months now,
and does not seem to be slowing down. It does not coincide with any
vulnerability I am aware of, and has not gotten anyone access to any
machines I run, as far as I can tell. It appears to just try common
usernames with weak passwords.
This one time, at band camp, Greg Webster said:
> The problem is, I've seen that valid accounts (like my own 'greg') get
> tested a lot more often than the others.
> 9 www-data
> 10 adam
> 10 irc
> 11 john
> 11 news
> 11 operator
> 12 mail
> 12 nobody
> 12 richard
> 16 michael
> 23 mysql
> 352 root
>
> Created with: zgrep 'Failed password' auth.log*gz |awk '{print $9}' |
> sort| uniq -c |sort -k1 -n|less
>
> Now, none of the people with 1 attempt are valid, but all of those above
> 10 are. None of the users have a valid shell to access the server via
> ssh, yet certain accounts get many more attempts (ignoring 'root'
> entirely, since it'd be a known target).
The usernames adam, john, richard, and michael are very common names.
the others are all common system accounts.
Here's my top ten on one system:
25 uucp
28 mysql
28 news
28 webmaster
29 daemon
31 oracle
32 bin
38 test
52 admin
412 root
but look,
4 richard
7 adam
9 greg
9 john
9 johnny
3 michael
are all getting hit as well. This machine has _no_ valid usernames to
speak of (3 or 4 accounts, and none are normal names). None of them
appear in the output of your zgrep. I see similar patterns in the logs
of the half dozen servers I have that unfortunately still have ssh open
to the world.
I think you are conflating an attack on a common username with a guessed
username. OTOH, the delay that you can see with the naked eye is odd,
and if you can provide some way to reproduce it, that would certainly be
a bug (maybe config file settings?).
Thanks,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature