On 10/11/19 2:04 PM, DP wrote:
Take a look at the script - let me know what you think?  This can dramatically improve the security of your server and require less resources.  I hope to continue to develop this to make it more powerful and flexible.

I took a look at this and think it was nicely done. (I did not install and test it because I did not have a test system readily at hand.) I have some comments.

I agree that blocking upstream of fail2ban is more efficient than relegating it to fail2ban. This includes traffic that would not trigger a fail2ban response.

Using ipset is an elegant way to filter on a potentially large number of CIDRs.

I checked to see if use would result in Self Denial. That was not the case (though I am somewhat near 66.110.192.0/19 which caught my eye — if one inspects that 66.110.192.0/19 CIDR, there are domains which might not qualify as undesired origins). However, I realized that if one were hosted on a common cloud provider, whether domestic or foreign (if either or both were used), one would be included in the target CIDRs, so that must be considered when using this on a cloud-hosted service. Also, many hosting providers have (relatively) domestic and foreign points of presence.

IPv6 is not handled. IPv6 blacklisting must typically be done at least using a 64-bit or more inclusive prefix (and requires a different ipset family).

A more precise method of targeting might allow selection of origins by related country or origin characterization (e.g., hosting, consumer-facing, mobile). I am not aware of any resources that provide exactly that, though I suspect they do exist.

I am uncertain whether the CIDRs you have provided precisely match those in use. An example is Digital Ocean (ASN 14061, bgp.he.net). You have obviously curated some sources of CIDR+characterization; these can change over time and may require frequent updating.

In my opinion, blacklisting must ultimately be performed based on reputation (i.e., observed bad behavior) and that reputation will change over time. Sharing of evidence-based reputation is feasible: there are many such sources available (e.g., http://www.blocklist.de/en/index.html). Use of such sources must be accompanied by some estimation of quality, freshness, and trust. Real-time reputation sharing and real-time application to filtering is technically feasible; establishing the related reputation of sources of threat information in such a sharing arrangement is not technically simple and would require authentication of contributors and attribution of their contributions. There are some examples of threat sharing in fail2ban actions (e.g., abuseipdb.conf).

Regards,

Gary

_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users

Reply via email to