david1941

[Log in to get rid of this advertisement]

In the last couple of days, my small network has been hit by dictionary attacks to my sshd port that are undetected by by my IP blocking routine. I have always blocked login attempts to specific user accounts and multiple attempts from any one IP. But this one used an array of source IPs, not from the same subnet and spaced about 12 minutes apart. My ssh attack demon does not catch these and I doubt that it will as I have not found any way to anticipate when and where the next attempt will come from.
I have considered closing the ssh port but that cuts off outside access from our remote use.

I guess I'll just have to rely on the allow users to work as these never seem to repeat from the same address. The attacker (and I think it is one perp) evidently has a whole slew of zombie machines just waiting to do his dirty work. <sigh>

Dave

{BBI}Nexus{BBI}

There's no point in panicking and closing that port unless you know some of your users have weak passwords, in which case you should force them to change them to a more secure one. I get those pathetic dictionary attacks too from time to time. I just keep a close eye on my firewall and machine logs. I run rootkit checkers and block the offending ips.

keefaz

Maybe make the attacker life slightly harder by setting the SSH server to another port than port 22 ?
(will not avoid port scanning though)

david1941

The interesting thing about this attack was that each attempt came from a different source, with only two out of a hundred or so from the same class B network (different address though). It may be hard to get that many zombies to use a different port destination. I may try a time-phased port switching daemon to restart my sshd with a port related to a GMT hour key. If the attacker is using remotely controlled clones as it seems necessary, that may work to keep her at bay.

I have tested to see if open ssh connections are terminated on a sshd restart and didn't find it so. Maybe on a port switch they will die.

Oh well, thanks for the suggestions, guys. Using strong passwords is really indicated but hard to implement when you are related to your users. I rely a tiny bit on my network being so small and unknown, but that seems no help. Predators seek the weakest prey.

Dave

anomie

This is a "low and slow" style attack. If I were in your shoes, I would start enforcing strong password for your users.

Read the manpages for pam_passwdqc(8). I wrote a guide on using this particular pam facility if you're interested: http://daemonforums.org/showthread.php?t=1019

(The guide is aimed at FreeBSD sysadmins, but I did include a GNU/Linux section.)

Additionally, you may need to start getting proactive on auditing (i.e. John the Ripper).

jiml8

If they are coming that slowly from that many different sources, then how are you identifying them as the same attacker?

david1941

I keep a watch on my log (/var/log/secure) and usually just get a couple of ssh hits that are easily added to my iptables by a daemon. About 900 in the past two years. But Monday I got three screens full of seemingly unrelated hits, all about 11 minutes apart and having user names increasing alphabetically with each one. I just think that is too coincidental to be unrelated. Nothing further that was unusual from Tuesday night. A couple of Kiddie things but that's all. That made me ask about it here.

It is devilishly hard to block these as by the time I recognize it, all previous hits are inactive. Thinking that no legitimate user would attempt to log in from two different class B networks and fail on both within a 15 minute time period, I adjusted my blocker to block the second one and retroactively block the previous one but what is really needed is to block the following one. I have thought of blocking new incoming port connections via iptables for 15 minute periods to break the chain (thinking that a daisy-chain type attack might be in use) but that hosed a legitimate login from a remote user.

I posted it here as it is the type of attack that would normally be hard to recognize in a more heavily burdened server. But someone else may have experienced it. Right now I am relying on AllowUsers and password strength.

Dave

jschiwal

The AllowUsers option you used is right on because it denies any other user, including attacks against known system users. You could enforce a policy that users use public key authentication. That would eliminate weak passwords. A user would still need to use a strong passphrase to protect their private keys in case they were lost.

secondmouse

Dave,
Did you try denyhosts.py? I'm using it and it does a pretty good job. Here's the link to its homepage

http://denyhosts.sourceforge.net/index.html

Also as keefaz pointed out, using a different port for ssh would definitely help a bit.

Micro420

I second denyhosts. That will eventually add the user's IP address to the hosts.deny and they will never bug you again ... EVER!

Better yet, I just change the standard SSH port 22 to another port and that cuts down about 95% of these scripts and bots trying to break in.

david1941

Thanks to all of you for your comments. I am not sure that denyhosts adds much to the already implemented AllowUsers in sshd_config as the man seems to give them both the same results but with the classic deny/allow decision. As my network is small, it is easy to implement an allow policy.
I have given a higher priority to closing my primary firewall to unwelcome visitors; adding whatever security help is available in the application as a secondary defence. An intruder would probably try both the back door and the basement door in addition to the front door. Better to keep him/her off the property!

A more complete description of my setup is here: http://maplepark.com/~drf/consults/Killit_Plan.html

Dave