From: DP <dol...@gm...> - 2019-10-11 18:05:09
|
Myself and some associates have been working on a project that was mentioned before on this list. A "pre-filter" that makes a great addendum to F2B. Our tests have shown with login-shield in place, it cuts down the F2B banned traffic by 95+%! We've finally got a public release, ready for people to test here: https://github.com/DPsystems/Login-Shield We call this, "Login-Shield" - it's a set of shell scripts that create an ipset blacklist of large blocks of IP space that are common vectors for hacks/attacks/probes. This is an initial line of defense that sits in front of F2B on the server and logs/drops traffic to login-based ports (ftp,ssh,imap,pop3,ftp, etc). By default it doesn't mess with mail (smtp) or web traffic. It's main intention is to stop system probes to find login credentials, which seems to be a major source of unwanted bot activity. One script creates the blacklist, then there's a series of 4 other scripts that add various types of IP blocks to the blacklist - you can edit the IP lists and remove any systems you want to enable. Then there's one last script which activates the blacklist via iptables. All of the scripts can be reversed with the "del" parameter as well. This is an initial public beta release - we've been testing it now for several months and it looks very promising. It requires very little memory (18k RAM with 314 entries in the BL) and even with that little bit, it puts a huge stop to the vast majority of system probes. This system was developed primarily for use with American servers who may not have any clients overseas who need to login. It could easily be adapted for use anywhere. I also include a IP blacklist of common US-based hosting companies that are common sources of bot attacks - I use these in my local blacklist as well, just making sure to either whitelist my/client IPs or remove any IP ranges that might affect me. These IP-based blacklists cover a big chunk of IPV4 space.. various class A and class Bs that are attributed to common threat sources such as China, Korea, Russia, Mexico, South America, etc. There is also a blacklist of known proxies and VPNs as well as a list of American IP space that covers the lion's share of cloud/hosting - you can pick and choose which categories and which IP groups you want to block. These are large blocks - leaving F2B to catch the rest in smaller blocks. 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. - DP |
From: Gary G. <fai...@ga...> - 2019-10-14 16:16:09
|
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 10/11/19 2:04 PM, DP wrote:<br> </div> <blockquote type="cite" cite="mid:CAN...@ma..."> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr">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.</div> </blockquote> <p>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.</p> <p>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.<br> </p> <p>Using ipset is an elegant way to filter on a potentially large number of CIDRs.</p> <p>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 <a href="https://whois.ipip.net/cidr/66.110.192.0/19">66.110.192.0/19</a> 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.<br> </p> <p>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).<br> </p> <p>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.<br> </p> <p>I am uncertain whether the CIDRs you have provided precisely match those in use. An example is Digital Ocean (<a moz-do-not-send="true" href="https://www.cidr-report.org/cgi-bin/as-report?as=AS14061&view=2.0">ASN 14061</a>, <a moz-do-not-send="true" href="https://bgp.he.net/search?search%5Bsearch%5D=digitalocean&commit=Search">bgp.he.net</a>). You have obviously curated some sources of CIDR+characterization; these can change over time and may require frequent updating.<br> </p> <p>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., <a href="http://www.blocklist.de/en/index.html">http://www.blocklist.de/en/index.html</a>). 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 <i>sources</i> 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., <a moz-do-not-send="true" href="https://github.com/fail2ban/fail2ban/blob/0.11/config/action.d/abuseipdb.conf">abuseipdb.conf</a>).<br> </p> <p>Regards,</p> <p>Gary<br> </p> </body> </html> |