ssh brute force attacks 3201

On Sat, 19 Mar 2005 13:28:32 +0000, Brendon Caligari

What you are most likely seeing are SSH worms on hacked PCs that scan blocks of IP addresses and look for SSH running on port 22. It then tries all sorts of default username-pbuttword combos on those systems which which offer SSH on port 22.

There are actually several ways to address this: (Using more here is better...)

-- you can move SSH access to a non-standard port number

-- use a separate username-pbuttword for SSH access, while having another for web site stuff (like logging into a message board & email accounts)

-- enforce more complex usernames & pbuttwords for all users on the server (letters, numbers & non-alphanumeric characters should be used)

-- don't use default usernames-pbuttwords for anything (especially for server level logins).

-- don't let users login directly as 'root' or any root permissioned user. Instead require the user to login as a non-root user first, and then SU to 'root' or to the root permissioned user.

-- use port knocking to turn on-off SSH access when not needed (especially if it is only you or a select few people who use SSH on a limited basis)

-- restrict usernames who should have SSH login permission (can be done 2 ways)

1 - hard code a list of allowed usernames into your SSH config directly

2 - create a group for SSH users. Then config SSH to only let members of that group login to SSH. Then whenever you want to permit someone to have SSH access, you simply buttign them to that group.

-- if all of your SSH users have static or fairly static IPs, restrict access to those specific IPs &-or IP subnets (can be done via iptables or the SSH configuration)

-- you can switch to RSA keys, so usernames-pbuttwords are no longer needed (users can have their RSA key on their HD or stored to a flash drive). I personally don't like the idea of not asking for a login pbuttword. Perhaps this can be used in conjunction with the standard SSH username-pbuttword login ability, so the RSA key is simply an extra piece of info used to verify validity of the user who is logging in.

-- setup iptables to block the IP for `X` minutes, after it sees `Y` login attempts during a `Z` time frame.

-- setup a small script, to run via the cron, and let it scan the SSH logs for multiple failed login attempts. If it finds `X` login failures during the specific time frame scanned, it will add the offending IP to the hosts.deny file and optionally set a iptables rule to drop packets from that IP.

There are other ways to address this situation, but these are most common solutions. As long as your usernames-pbuttwords are complex (see above) and your server's packages (especially SSH) are kept updated, you should not have any problems with this type of attack. However by adding any combo of the above options to your SSH config (the more the better), you further limit the possibility of such an attack succeeding.

On my servers, I use a combo of the above. I don't allow root permissioned users to login directly. They need to login as a non-root user & then SU to a root permissioned user. I don't use default usernames-pbuttwords for anything. I use a separate username-pbuttword for server-SSH access & different ones for web site stuff (like logging into a message boards & email accounts). I enforce more complex usernames & pbuttwords for all users on the server (letters, numbers & non-alphanumeric characters). I limit the usernames of the users permitted access to SSH & run a small script that looks for login failures and blocks the IP address of offenders. With this config, it has proved to very powerful-secure combo for SSH control & incidents of false positives (legit users getting locked out automatically) is very small.

I hope this helps...

James T.