|
From: Jim S. <jse...@Li...> - 2018-10-06 14:49:56
|
On Fri, 5 Oct 2018 18:47:25 -0700
James Harris <jam...@gm...> wrote:
> I have had a similar idea about offline processing. Instead of
> banning people that are trying to brute force with default
> usernames, I was thinking about blocking subnets or whole network
> providers by determine the AS (autonomous system) associated with
> the IP.
[snip]
The people who run the servers that supply the ASN data may not
appreciate the traffic if many people started doing that.
I used to run an automated blocklisting system that worked like this:
. One (1) spam got you blocklisted for time T with a probationary
period P
. Repeated spams after T expired, but w/in P, re-blocklisted with
incremented T and P
. T would increment to infinity after N relistings
. A script ran every 24 hours that would count the number of
unique listed IP addresses w/in each /24. More than X unique IP
addresses w/in a /24 got the entire /24 listed.
. I had two manual netblock lists:
. A list that, any IP address w/in the list that spammed me
earned immediate infinite listing
. A manual list that was an immediate listing of the entire
netblock
(I'd briefly considered the ASN thing, too. But the ASN server abuse
thing was a bit of a show-stopper.)
Let me tell you how effective all that was: I stopped running it long
ago. Of all the spam blocked by the various mechanisms I used, my
system accounted for a fraction of a percent. (Mainly what all that
effort did was give me a heckuva education in some pretty nifty RDBMS
methods.)
I never got around to running an analysis of sshguard repeat
offenders on my systems, but, if the results of my efforts at creating
my own spam blocklist is any guide: Probably relatively low. There
are *a lot* of IP addresses out there.
The truth is there are so many infected systems out there, so many
systems ripe for infection--due to poor code, poor administration or
both, and so many bad actors exploiting all that, that no automated
system beyond what sshguard is already doing will have much
incremental effect.
IMO: To *really* improve the efficacy of sshguard, many, many
instances of sshguard, across the 'net, would have to be "meshed."
Heuristics and trust mechanisms, similar to those employed by NTP,
would have to be developed. (I actually once considered doing that
between my systems a few years ago.)
Regards,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
|