News Group Posts

ssh login attacks

Main Index

There's a lot here about ssh security but this post sums up a lot of things:

From: James T <turajb@_NOSPAM_hoflink.com>
Subject: Re: ssh brute force attacks
References: <423c2901$0$38037$bed64819@news.gradwell.net> 
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.
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.