[SWLUG] Possible SSH Attack

[Chris King]

On Thu, July 14, 2011 22:22, Jon Reynolds wrote:
>  Hi folks,
>
>  Am a bit naive when it comes to these things, but looking through just
>  the last few days of auth.log I see lots of this:
>  Jul 10 16:17:30 jcrdevelopments authdaemond: pam_unix(pop3:auth):
>  authentication failure; logname= uid=0 euid=0 tty= ruser= rh
>  ost=  user=root
>
[rest of log snipped for brevity]
>
>  I am of course wondering if this is some sort of brute force attack,
>  where someone is trying to log in with any possible user name....
>
>  Is there anything I can do? Should I be worried? I use ssh keys to
>  login, but I have left password auth on in case I loose the keys :)
>
>  ...maybe this is just normal?
>
>  Thanks in advance.

Jon

There's nothing "possible" about it. That's a definite - and unsubtle -
attempt to probe your system. Sadly, that's normal for any
internet-connected machine these days.

Carwyn has mentioned changing the port number (which thwarts most but not
all automated probes) and using Fail2Ban - also, check out the
"AllowGroups" configuration option in sshd_config(5).

On systems I set up, I usually create a user group called "sshlogin" and
add "AllowGroups sshlogin" to my ssh_config. I then add each user that
needs to perform SSH/SFTP logins to the "sshlogin" group:

# groupadd -g <group-id> sshlogin
# usermod -a -G sshlogin <username>

Restart OpenSSH ("/etc/rc.d/rc.sshd restart" or whatever your distro of
choice uses) and only the users in the "sshlogin" group will be able to
log in via SSH.

This seems to work with key-based authentication as well as passwords -
even if you provide the correct keys/passwords for users not in
"sshlogin", you just get an authentication failure.

The usual advice about choosing strong passwords also applies - there's no
point enabling this if the account password is set to the username !

If you use accounts for file transfer only, the "Match" directive can lock
them down for SFTP without having to build a chroot-jail environment:

Match User username
     X11Forwarding no
     AllowTcpForwarding no
     ForceCommand internal-sftp
     ChrootDirectory /home/username

You need OpenSSH 4.8 or later for this, and it doesn't work properly on
some distros - I tore out big clumps of hair trying to make this work on
CentOS 5 !

Chris

-- 
Chris King
http://www.csking.co.uk/