Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Feb 2011 15:55:42 -0500
From:      Vadym Chepkov <vchepkov@gmail.com>
To:        Daniel Hartmeier <daniel@benzedrine.cx>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: brutal SSH attacks
Message-ID:  <FB3E9540-742A-4783-9813-B7DBCD515C7E@gmail.com>
In-Reply-To: <20110209185118.GA16942@insomnia.benzedrine.cx>
References:  <D04005BA-E154-4AE3-B14B-F9E6EF1269B0@gmail.com> <5A0B04327C334DA18745BFDBDBECE055@charlieroot.de> <A6E48F78-AC10-40DE-9345-86D14CC4D3A1@gmail.com> <98689EFE59404E4B838E79071AABA8B4@charlieroot.de> <56413CA2-EE4F-4E06-B044-0982E864E44D@gmail.com> <A141DF22-E35C-46BD-B88B-D68800812359@gmail.com> <20110209185118.GA16942@insomnia.benzedrine.cx>

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

On Feb 9, 2011, at 1:51 PM, Daniel Hartmeier wrote:

> On Tue, Feb 08, 2011 at 08:07:52PM -0500, Vadym Chepkov wrote:
>=20
>> No idea, why it didn't stop after 9 attempts.
>=20
> The connection rate is not calculated precisely, from pf.conf(5)
>=20
>     max-src-conn-rate <number> / <seconds>
>           Limit the rate of new connections over a time interval.  The =
con-
>           nection rate is an approximation calculated as a moving =
average.
>=20
> There is a counter, and a last-update-time.
>=20
> When the first connection matches, the counter starts at zero, and the
> time (one second resolution) is noted.
>=20
> Whenever a subsequent connection matches, the following happens:
>=20
>  1) if the last-update-time is further back than <seconds> (60, in =
your
>     case), the counter is reset to zero.
>  2) otherwise, the counter is reduced relative to how much time has
>     passed since last-update-time (i.e. the counter is multiplied by
>     (now - last-update-time) / <seconds>
>  3) the counter is incremented by 1000
>=20
> When the counter exceeds 1000 * <number> (9, in your case), the
> max-src-conn-rate is triggered.
>=20
> This works reasonably well in many cases, but may be quite inprecise,
> especially when <number> is much smaller than <seconds>.
>=20
> You could try max-src-conn-rate 2/5 instead.
>=20

Wouldn't it be dangerous to reduce it this drastically? I can lock out =
myself.
I don't think it's uncommon to try to open 3 connections at the same =
time, especially in NAT environment.

I would increase "number", but it will negate the rule.
Here is an example of an actual intruder:

Feb  8 11:27:01 castor sshd[57304]: Invalid user ariane from =
113.185.0.16
Feb  8 11:27:04 castor sshd[57306]: Invalid user armand from =
113.185.0.16
Feb  8 11:27:08 castor sshd[57308]: Invalid user armande from =
113.185.0.16
Feb  8 11:27:11 castor sshd[57310]: Invalid user armando from =
113.185.0.16
Feb  8 11:27:15 castor sshd[57312]: Invalid user armani from =
113.185.0.16
Feb  8 11:27:18 castor sshd[57314]: Invalid user arnie from 113.185.0.16
Feb  8 11:27:22 castor sshd[57316]: Invalid user arne from 113.185.0.16
Feb  8 11:27:25 castor sshd[57318]: Invalid user arnold from =
113.185.0.16
Feb  8 11:27:29 castor sshd[57320]: Invalid user art from 113.185.0.16
Feb  8 11:27:33 castor sshd[57322]: Invalid user arthur from =
113.185.0.16
Feb  8 11:27:36 castor sshd[57324]: Invalid user artie from 113.185.0.16
Feb  8 11:27:47 castor sshd[57326]: Invalid user arty from 113.185.0.16
Feb  8 11:27:50 castor sshd[57328]: Invalid user asha from 113.185.0.16
Feb  8 11:27:54 castor sshd[57330]: Invalid user asher from 113.185.0.16
Feb  8 11:27:57 castor sshd[57332]: Invalid user ashley from =
113.185.0.16
Feb  8 11:28:01 castor sshd[57334]: Invalid user ashton from =
113.185.0.16

That's 16 packets in 60 seconds.
2/5 wouldn't caught him either - 7 seconds between 3 packets

And I would be fine if just 3-4 packets exceeded the threshold, if it's =
not precise.
But it doesn't stop him at all, that what puzzles me

# bzgrep 113.185.0.16 /var/log/auth.log.0.bz2 | wc -l
     939

# pfctl -t abusive_hosts -T show=20
   46.23.72.63
   69.162.99.220
   79.136.100.188
   93.174.31.134
   109.169.21.37
   188.127.244.107
   200.24.219.198
   221.133.41.170
   221.238.253.85
   222.186.37.205


some do caught, as you can see, but I still see every day those that =
avoid the trap

Thanks,

Vadym

> The details can be found in pf.c, see
>=20
>  =
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c?rev=3DHE=
AD
>=20
> The reason this was chosen over a more precise algorithm is that this =
is
> very cheap CPU-wise and requires only a minimal amount of memory.
>=20
> Regards,
> Daniel




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB3E9540-742A-4783-9813-B7DBCD515C7E>