Re: ssh brute force attacks

From: James T (turajb_at__NOSPAM_hoflink.com)
Date: 03/20/05


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
>
>
> cheers
>
> B.

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
better...)

-- 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
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 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
that IP.

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...

James T.



Relevant Pages

  • Re: sshd brute force attempts?
    ... ssh is not a public service like http or smtp where you need anyone to be able to connect. ... Disable direct root login, in the article more than a third attempted to login as root. ... Use a scheme for choosing usernames that avoids common names like "james" and avoid publishing usernames on web-sites, e-mail may differ from the username. ... This is really only a problem if the traffics saturates your connection, or your log files grow so much that you run out of diskspace. ...
    (freebsd-questions)
  • Re: Setting up tunnel across multiple systems?
    ... > ssh to their border system and then ssh to to another system where I need to ... How can I setup ssh tunnel so that I can login from my system ... Usernames on system A and system C are same, but system B only has one ... > it's backed up on tape somewhere. ...
    (comp.security.ssh)
  • Re: repeated ssh login attempts/failure/break-in attempts from kiddy script
    ... of various usernames, etc... ... attempts like 100-200 logins, fails and goes away. ... no one has managed to login (there are only ... three accounts which even have a shell or can login via ssh... ...
    (freebsd-questions)
  • Internet SSH scans
    ... SSH service. ... happens to run a SSH server at home. ... with different usernames. ...
    (Incidents)
  • Re: ssh gives "Permission denied, please try again"
    ... port 22 on your internal machine, so you will need to keep ssh up to ... I configure the router to forward a different external port to 22 on my ... For good measure pick usernames that are none obvious, ... root/password: 163 times ...
    (uk.comp.os.linux)