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>. |