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
