Daniel Lawson wrote:
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
Security through obscurity doesn't work very well[1]. You'll do a lot better in the long term to make sure your SSH passwords are secure, or to only allow key-based auth, or to use TCP wrappers or firewalling to limit who *can* connect.
[1] This will prevent the current attacks, but it's only a matter of time before there are worms out there scanning all ports and making note of common services on high ports.
I have a secure password. An insecure password isn't just an ssh issue that's an issue on all parts whenever you create a login. SSH just happens to be one of the easily attacked protocols via brute force. I say using a high port because this DOES get around 99.9% of current port scans for ssh brute force on port 22. Until these brute force attacks start recognising I am using a higher port then I will consider filtering though I find this is trivial at this current time as I get through to the box via means that use dynamic ip addressing. The only machine I am getting brute forced on is a machine I didn't set up and get forwarded the daily security emails with these in the logs. I haven't been touched on any of my other 8+ servers. They are hitting common names and users like 'test' and 'guest'. Another precaution is not allowing your services users ssh access, mysql, httpd/www, etc (make sure their shell is something like /bin/true) they generally hit common service names as well. My 2 cents. - Drew