Re: ssh brute force attacks
From: James T (turajb_at__NOSPAM_hoflink.com)
Date: Sun, 20 Mar 2005 10:48:00 -0500
On Sat, 19 Mar 2005 13:28:32 +0000, Brendon Caligari wrote:
> Hey all
> I've noticed a hell-of-a-lotta brute force login attempts on my machine.
> I'm not exceptionally worried and they're more of a nuisance than a
> threat...but annoying none the less.
> sshd is pretty much locked down, but before I put together some quick
> and dirty homegrown hack I was wondering whether there are any tried and
> tested deamons to temporarily lock out an ip's access to port 22
> following a brute force attempt
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/password combos on those systems which which
offer SSH on port 22.
There are actually several ways to address this: (Using more here is
-- you can move SSH access to a non-standard port number
-- use a separate username/password for SSH access, while having another
for web site stuff (like logging into a message board & email accounts)
-- enforce more complex usernames & passwords for all users on the server
(letters, numbers & non-alphanumeric characters should be used)
-- don't use default usernames/passwords 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
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 assign 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/passwords 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 password.
Perhaps this can be used in conjunction with the standard SSH
username/password 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
There are other ways to address this situation, but these are most common
solutions. As long as your usernames/passwords 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/passwords for anything. I use a separate username/password
for server/SSH access & different ones for web site stuff (like logging
into a message boards & email accounts). I enforce more complex
usernames & passwords 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...