Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Sep 2004 17:51:55 -0700
From:      "Darren Pilgrim" <dmp@bitfreak.org>
To:        "'Antony Mawer'" <fbsd-security@mawer.org>, "'Chris Ryan'" <chrisryanemail@yahoo.com.au>
Cc:        freebsd-security@freebsd.org
Subject:   RE: Attacks on ssh port
Message-ID:  <001001c4a363$07f6c880$162a15ac@spud>
In-Reply-To: <414CE5E8.6000103@mawer.org>

next in thread | previous in thread | raw e-mail | index | archive | help


> -----Original Message-----
> From: owner-freebsd-security@freebsd.org=20
> [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Antony Mawer
> Sent: Saturday, September 18, 2004 6:51 PM
> To: Chris Ryan
> Cc: Frankye - ML; freebsd-security@freebsd.org
> Subject: Re: Attacks on ssh port
>=20
>=20
> Chris Ryan wrote:
> > protection - with the appropriate active firewall that
> > blocks their IP address after x failed attempts
> > permanently....
>=20
> Has anyone found any good scripts or utilities for automating=20
> this kind=20
> of thing? I too have been subject to these probings, and my initial=20
> thought was to firewall off any address after any number of incorrect=20
> attempts.
>=20
> While I could write a script to parse the ipfilter logs, I didn't want =

> to go re-inventing the wheel for something which I was sure someone=20
> would have already attempted.
>=20
> Anyone have any suggestions?

There's three factors: wasted bandwidth, a successful intrusion and log
noise.

Filtering mitigates bandwidth wastage.  But unless you can place the =
filter
out at the point where the Big Fat Pipe feeds into your comparatively =
small
pipe (i.e., the ISP's router), it's pointless--the scans will still eat =
your
bandwidth.  IP Filtering is at best a tertiary security measure.  It =
should
not replace proper configuration and maintenance, which is what you're
seeking to accomplish.

Check out the DenyUsers sshd_config keyword.  With it OpenSSH will block =
any
login attempt with an account listed by DenyUsers.  DenyUsers-listed
accounts produce logging sooner (upon receipt of the username, rather =
than
after four bad passwords) and have different log entries than normal
password failures.  Cutting down the log noise is then a simple matter =
of
adding a filter to 800.loginfail or whatever else you may be using to =
read
auth.log.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001001c4a363$07f6c880$162a15ac>