Recently, a script-kiddie tool for brute forcing SSH passwords made its way into the wild. Early versions generally would make a few random attempts at logging into the root, admin, test, and guest accounts, choosing randomly from a list of 2000-odd "obvious" passwords.

I've seen an extended version of this hit a Linode that I manage for my employer, trying a variety of other accounts as well (such as people's names, webmaster, etc.), and failing.

This raises two issues:
1. Make sure that you do not use an "obvious" password for lish. It's almost inevitable that someone will try this tool against a Linode host box, if it hasn't already happened.

2. If you run sshd on your own Linode, use RSA or DSA key authentication only. You will need to generate a key pair, and place a copy of the public key into the user's $HOME/.ssh/authorized_keys file, and then set:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no

in your sshd_config file (usually /etc/ssh/sshd_config). Keep your existing SSH session open, restart sshd, and test a new login using the RSA key.

Keep your private key PRIVATE! It is a good idea to protect it with a passphrase. You might want to keep a copy of it on a USB flash drive.

You can generate key pairs using ssh-keygen on a Linux/FreeBSD/other *nix/Cygwin installation, or with PuTTYgen if you use PuTTY on Windows.

edit: add PubkeyAuthentication

_________________
Bus error (passengers dumped)

so.. on this note i found i had the same thing, so i wrote a perl script to handle this.. it needs a bit of work because it takes a while sometimes, but the shortversion is after 3 failed logins u get added to iptables drop.. the details for it are all here
http://www.our-lan.com/blog

Another band-aid fix you can do if you have a very small number of users is to run sshd on a non-standard port. This of course is not a fix, but for 99.99% of the attacks out there, it'll be effective, since these brute-force approaches look for the low-hanging fruit, and they're not going to take the time to do a complete port scan on every IP. Not yet, anyway...

_________________
----
Ed/Bones.

That's exactly what I do

_________________
Jay Faulkner
http://oldos.org

n00b question, but how can I set that up? Recommend any good tutorials, or any recommendations?

Thanks,
-Kevin

Edit /etc/ssh/sshd_config - change the value of the Port parameter, uncomment the Port statment if necessary and then restart the ssh daemon.

To connect, specify the -p portnum option for ssh, in addition to your normal options.

Choose a port number less than 1023, so that if sshd ever goes down, a user cannot start his own compromised version of ssh listening on your chosen port.

_________________
/ Peter

Peter,

Thanks! I'll go set that up in a few.

One question, I assume this would affect how scp would work as well, correct? I noticed there is a -P (port) option for scp, so I would just need to do -P and the port number, is that correct?

[Follow up] So it appears to have worked, except when I connect to Lish. If I type 'ssh [username]@host34.linode.com' it connects fine. Any idea why that is?

Thanks
-Kevin

Lish is accessed via a separate instance of sshd running under the host kernel - so that Lish is still available to access your Linode's console even if you hose your ssh daemon. You have no control over which port the daemon running under the host kernel listens on (it's common to all Linodes on that host and controlled by caker).

_________________
/ Peter

Ahh, OK yeah that makes sense now

Thanks for your help!

-Kevin

As a follow up, I have started using a different port under 1023, but I think it's causing issues, as after a period of time, the connection seems to freeze, then time out. I'm thinking I might be using a port that is being used by something else. Anybody recommend a range of ports that are relatively safe to use without running the risk of being used by something else.

Thanks,
-Kevin

Check out this link for an alternative. It uses the recent netfilter module which is installed in the Linode kernels. This limits ssh connection attempts to 3 per 60 secoond period without having effects on existing connections.

http://blog.andrew.net.au/2005/02/17

Try 203, 205, 207 & 208. The block from 201 to 208 inclusive is assigned to AppleTalk, and the four just listed are currently marked as unused by that protocol.

_________________
/ Peter

So im corious to know, if there is a way to makeip tables load certian rules on startup? cause i would like to implement the methods that were described in the link posted by mike

cheers
Nathan

You can put startup scripts in /etc/init.d or /etc/rc*.d.
LSB (linux standard base) is now /etc/init.d but redhat 9 uses /etc/rc*.d

Lish is very useful if your firewall locks you out

Here is a script based on the debian skeleton init.d script:

#! /bin/sh
#
# ssh-bruteforce
#
# Author:   Michael Greb <michael@thegrebs.com>.
#
# Version:      @(#)ssh-bruteforce  1.0  26-Mar-2005 
#

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="iptables for ssh brute force mitigation"
NAME=ssh-bruteforce
SCRIPTNAME=/etc/init.d/$NAME


#
#       Function that starts the daemon/service.
#
d_start() {
    iptables -N SSH_WHITELIST
    iptables -A SSH_WHITELIST -s 70.187.46.105 -m recent --remove --name SSH -j ACCEPT
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
        --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
    iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
        --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
}

case "$1" in
  start)
        echo -n "Starting $DESC: $NAME"
        d_start
        echo "."
        ;;

  *)
        # echo "Usage: $SCRIPTNAME {start}" >&2
        echo "Usage: $SCRIPTNAME {start}" >&2
        exit 1
        ;;
esac

exit 0

This line:

iptables -A SSH_WHITELIST -s 70.187.46.105 -m recent --remove --name SSH -j ACCEPT

should be repeated as many times as you wish with the IP addresses you want whitelisted, or none if you don't wish to have any whitelisted. This script does not unload the iptables rules when asked