Re: Dictionary sshd attacks

From: Tobias Klausmann (klausman-un0705_at_schwarzvogel.de)
Date: 07/17/05 

Date: 17 Jul 2005 10:35:09 GMT

Wayne <wayne@nospam.4me.invalid> wrote:
> Is it possible to have sshd or some other daemon recognize
> a dictionary attack in progress, and to "shun" that IP for
> (say) an hour? The machanics seem simple to me: A log file
> reader spots the pattern in real time

"Spot the pattern" can becom arbitrarily complex. That's hump
number one you'll face.

> and issues an iptables
> command to DROP port 22 packets from the identified IP address,
> sends a syslog message, and creates an "at" job to remove the
> iptabes rule after some period of time.

I don't know about you, but I always feel uneasy when some
script messes with my Netfilter rules autopmagically. Besides
zeroing counters, that is. That (to me) would be hump number two.

> I know I've read of such tools someplace before, but I can't
> remember any details.

The places I'd look for such things would be Freshmeat,
Bugtraq/Focus-Linux and Google, in that order.

> Some of my servers have been under attack for many months now.
> Sometimes twice a day, hundreds to thousands of ssh connections
> are attempted using a dictionary of common usernames.
>
> I have been saving the logs but no pattern has emerged yet
> from the IP addresses. Of course they don't get in (yet),
> but I'd like a more automatic way to respond to such attacks.

Well, I can understand that. I've taken to nailing my Netfilter
rules shut for SSH (besides a handful low-risk addresses). Makes
me sleep much better :)

> Lessons learned:
>
> Have account naming policies that forbid usernames that commonly
> appear in dictionary attacks.

Agreed. Cracklib can do a nice job here.

> Make sure *all* system accounts are disabled, and where possible
> have invalid shells (such as /bin/false or /sbin/nologin).

And shun software that needs accounts with shells (or uses nobody
as hardcoded run-as user).

> Never allow sshd (or other) root logins.

I allow root logins on the console. If physical security is
compromised in the co-lo, nearly all bets are off.

> Configure the PAM "su" policy to only allow a few select users to
> succeed with the su command. (The members of group "wheel".) Other
> users who attempt "su" will fail even if they know the password.

My distribution of choice does this by default.

Regards,
Tobias 

-- 
export DISPLAY=vt100
Loading