Re: [gentoo-user] Curious pattern in log files from ssh...

[Steve]

Thanks for all the replies so far... I'll reply once to these... (Oh,
and when I said "ports" in my original post, I meant "addresses" - my
typing fingers just ignored my brain...)

I'm against a 'novel port' approach - as I am against port-knocking (for
my server) because these may prove challenging for the environments from
which I may want to log on.  I want to retain a 'standard' service to
make it easiest for me to connect to my server from a remote site
without requiring reconfiguration of firewalls etc.

I have, in the past, used DSA only keys - but this was frustrating on
several occasions when I wanted access to my server and didn't have my
SSH keys available to me... I almost always connect using a key pair
rather than a password - but the password option is very useful to allow
me to get hold of my SSH keys in the first place in some environments. 
If I found a distributed attack on a valid user name, for example, I'd
consider this a critical change - however inconvenient.

I previously used denyhosts - but (I can't remember why) it became
preferable to block with IPtables rather than with tcpwrappers... which
prompted me to dump it in favour of a bespoke script based upon
blacklist.py (http://blinkeye.ch/mediawiki/index.php/SSH_Blocking) -
though, now, I'm tempted by the more professional looking sshguard -
thanks for the tip.  Of course, this doesn't really address the problem
I posted about - because I'm now faced with a highly distributed
dictionary attack...

It strikes me that, given the conclusive nature of this attack (which,
by virtue of the fact that the usernames are attempted in alphabetical
order proves it to be a single coordinated attack) I can create a list
of a large number of IP addresses - which, likely, correspond to
compromised hosts.  It strikes me that this would be a perfect source of
information to set up a block list... and, if others' logs show similar
attacks, it should be easy enough to combine this data to provide
distributed protection from a distributed attack.  I don't think for one
second that this attack is targeted - neither my hardware or the
information on my server is particularly interesting to anyone but me. 
It would be extremely interesting to me, however, if it were to
transpire that my IP address originated login attempts such as these -
as this would clearly demonstrate it to be compromised...  I suspect,
too, the ISPs should be interested to inform their subscribers in the
interest of security... though, of course, I recognise that this is
being optimistic.

When I exposed my server to internet SSH logins, I carefully considered
security... though I also had to consider convenience - since that was
the only reason for doing so in the first place.  If I could block all
IPs suspected of being in a bot-net - then this would be an improvement
in security without a great cost in terms of lost convenience.  Right
now, in the context of this attack which circumvents my earlier blocking
strategy, I'm looking for a viable blacklist solution in order to avoid
white-listing.  A potential solution for me would be to have sshd be far
more choosy about source IPs when using password authentication... for
example, restricting it to hosts in the UK... but still allowing remote
access wherever I've propagated DSA keys... but I think this would be
tricky to set up.  A shared block-list, I suspect, would be the most
effective response to this attack... and the response most likely to
minimise others' exposure, too.

Steve