[D8][SR] Add the ability to block IP addresses (feature parity with Drupal).

[klonos]

This is a sibling issue to #1169 and a counter-issue to #1394 (where we discuss documenting that it is not possible to ban an IP in Backdrop and that such a feature belongs in contrib).

Both D8 and D7 have a ban IP feature (https://www.drupal.org/documentation/modules/ban), so this makes this issue here also part of #378:

In D7 it is part of the system module, so enabled by default:

...whereas in D8 it is a separate core module (Ban) that is disabled by default:

Related issue and change record where the "Ban IP" feature was removed from Backdrop core: #2543 https://api.backdropcms.org/node/44866

I personally get a lot of "page not found" errors in the log of quite a few sites I run. Some examples of pages requested are:

ttp://testp1.piwo.pila.pl/testproxy.php
w00tw00t.at.blackhats.romanian.anti-sec:)
phpMyAdmin/scripts/setup.php
pma/scripts/setup.php
myadmin/scripts/setup.php

...and so on. So, it would be great to have an automatic thing in place that works like fail2ban and blocks "nasties" (with the threshold being configurable). For feature parity with Drupal, we should also allow manual entry of IP addresses.

If we have this + Honeypot in core (#1169) and enabled with some sensible defaults out of the box + a dedicated Configuration -> Security admin section, then we'd be able to market all that as additional security features.

[maxmeno]

I add my vote on this.

I spot dozens of bots that try to exploit both WP and Joomla vulnerabilities, non stop. It would be useful to automatically ban (for a while or forever) any IP requesting specific non-Drupal pages. I already have a list of bad requests.

[Gormartsen]

+1 to core feature. Also I recommend to check IP even before bootstrap_full loaded. Better even before core get loaded.

[klonos]

I would also like to propose automatically blocking IPs that try to access bogus paths like /wp-admin.php. Something that the path2ban D7 module does:

The path2ban module allows to block web scanner's attacks from individual IP addresses.
Module has a list of restricted paths. All attempts to scan restricted paths will be logged:

admin.php
admin/index.php
bitrix/admin/index.php
administrator/index.php
wp-login.php
and others.

[klonos]

We should communicate that we care about security within the product itself, and I see no better way than adding a dedicated "Security" section under "Configuration", or under "Configuration" -> "System" and have #1169 and this issue here live under that.

[klonos]

...tentatively setting this to 1.12.0 to match #1169

[Graham-72]

I would also like to propose automatically blocking IPs that try to access bogus paths

👍 I am pleased to see this back on the agenda.

[klonos]

@Graham-72 ...yeah, I have done a brief research of various modules implementing banning of IPs and it seems that this feature is required in many cases. We should build only the basic functionality in core, and automate what makes sense. I was thinking:

1. Page that lists all banned IPs (to allow manual unblocking)
2. "+ Block IP" button to manually add IPs (perhaps worth supporting IP ranges?)
3. Setting to automatically ban IPs after x amount of attempts
4. Setting to enable automatically banning attempts to access known bogus paths. Could be a list with pre-populated values, so that people can add their own (once we have metrics in place, this could become a crowdsourced source of bogus paths: we see a path being added by most of the installations -> we add it to the defaults).
5. Perhaps also support DNS blacklists(? not sure about this one; could be taking it too far for core).

...the rest (like automatically unbanning, whitelisting etc.) could/should be left to contrib, but we should definitely accomodate for the banning/unbanning facilities they can use. If we get this right and re-introduce what has been removed, we will make it easier to port any of the existing IP-banning-related D7 contrib modules that would have otherwise been impossible/hard to port before.

[jenlampton]

We removed this feature because we thought:

1. it wasn't a feature used by the 80% (I only used it once or twice back in my Drupal 5 days, and I never felt it worked very well)
2. it's not something that should be done at the application level -- that it's best done at the server level.

To play devil's advocate for #2, our intended audience isn't likely to have the knowledge on how to protect themselves at the server level -- or the access.

For #1, it sounds like a lot of people miss having this feature. Was this something you used on Drupal 7 sites, and if so, was it actually effective?

Another thought: Are there contrib modules we could / should look at merging into core, instead? (if they are more effective)

[stpaultim]

I am not speaking against this feature, but a couple of comments.

1. I have never used this feature on any Drupal sites.
2. I just spoke with a D7 client who was battling registration SPAM a week ago and he pointed out that this feature probably wouldn't help him, because he is using Cloudflare on his site and he assumes that Cloudflare would make the feature ineffective. He knows more about server stuff than I do.

[jenlampton]

Rather than bringing back Ban, can we look into better/alternative approaches? We removed ban for a reason. Maybe we should find something that's a better match for our core values? What about something like https://www.drupal.org/project/autoban, instead?

I don't personally like autoban because it requires both Rules and having the database logging module enabled, but it would be great if we could do something similar instead of just Ban. Or, maybe we bring back Ban, and add our own auto logic?

There's no PR here yet, and code freeze for 1.13 is in less than a week. We should get crackin' if we want this in the next release.

[klonos]

What about something like https://www.drupal.org/project/autoban, instead?

Yes, I personally am not married to any specific module; core or contrib. So long as we add the feature in an intuitive way, that works as much as possible OOTB, and allows users to enable/disable/tweak it.

This is a perfect candidate for #3624

[jenlampton]

Agree!

…

On Fri, Apr 26, 2019, 1:42 AM Gregory Netsas ***@***.***> wrote: What about something like https://www.drupal.org/project/autoban, instead? Yes, I personally am not married to any specific module; core or contrib. So long as we add the feature in an intuitive way, that works as much as possible OOTB, and allows users to enable/disable/tweak it. This is a perfect candidate for #3624 <#3624> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1878 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBER67URLPHUUJ2CWHIXTPSK57TANCNFSM4CD7JNMA> .

[caseyburk]

For whatever it's worth, I reached out to "goodboy" (Sergey Loginov) directly about his work with Autoban potentially becoming part of BD. I suggested he reach out to you guys in an effort to assist wherever possible. (He's the author of Autoban.) He showed interest, so hopefully you'll see something from him at some point.

Note, too, that during some tests I conducted with him for Autoban, we eventually realized that Autoban's "Forced Mode" is a little buggy or inconsistent. It's intention is to block an offender the instant one of the offender rulesets is triggered. So for example, if you create a ruleset that's designed to block anyone who issues a request for something like "/admin" with no referrer, that would be an obvious red flag that the request is malicious. During our tests, we discovered that "Forced Mode" inconsistently works when applying block rulesets: Sergey believes its has something to do with caching... The design requirement is that it needs to block the INSTANT an offending ruleset is triggered, so I hope you'll keep that in mind during your work with BD because I think that would be a deal-breaker for many situations, especially during those times we all often experience when a wave of attacks is taking place--think Drupalgeddon. Autoban works well enough (for the most part) that it does a pretty great job of barring bad originators but this "Forced Mode issue" the one flaw it currently suffers from that nobody seems able to understand and fix. (This situation was verified when testing a fresh localhost D7 installation site using 2 workstations where 1 acted as the server serving a site with 1 Autoban ruleset enabled and the other workstation acting as the offender trying to intentionally trip the blocking ruleset--the attacking workstation was able to submit numerous malicious requests using the offending ruleset recipe before finally being blocked and that was only after the admin of the site performed actions that appeared to trip functionality the Autoban module somehow depended on to enact the defensive functionality needed to apply the block.)

Lastly, I hope that your guys' ideas about having an IP ban functionality similar to (or exactly like) what Autoban can provide also includes the ability to block / blacklist (or allow / whitelist) by IP ranges. I think it's important to include that if possible because from the experiences I've had with my personal D7 website, I've observed scenarios where malicious bots almost always "hot swap" to adjacent IP addresses or ranges within the same host provider network they serve their attacks from, which is an obvious countermeasure designed to bypass network-based or site admin blocks at either firewall or app layers.

Keep up the great work and if I can assist with testing any blocking facilities you guys come up with, please don't hesitate to reach out.

• Wolf_22

[klonos]

For whatever it's worth, I reached out to "goodboy" (Sergey Loginov) directly about his work with Autoban potentially becoming part of BD. I suggested he reach out to you guys in an effort to assist wherever possible. (He's the author of Autoban.) He showed interest, so hopefully you'll see something from him at some point.

Thanks @caseyburk 👍

I hope that your guys' ideas ... also includes the ability to block / blacklist (or allow / whitelist) by IP ranges.

Seems a reasonable request, and possible I believe (should be easy once we get the basic IP banning implemented I mean).

In general, I would like to see us work on #3624, and adding things there that help people secure their sites (contrib modules would have a place to live under too 😉). That would be a great way to show that we are actually concerned about security, and making it easier for people to find security-related settings/tweaks in a single place in the admin UI. We could also be linking to security-related documentation in b.org from that place.

Keep up the great work and if I can assist with testing any blocking facilities you guys come up with, please don't hesitate to reach out.

❤️

[caseyburk]

Sounds like a solid plan to me, Gregory. :) Regards, *Casey J. Burk* Internet Media Delivery Specialist [email protected] www.caseyburk.com

…

On Mon, Apr 29, 2019 at 6:20 PM Gregory Netsas ***@***.***> wrote: For whatever it's worth, I reached out to "goodboy" (Sergey Loginov) directly about his work with Autoban potentially becoming part of BD. I suggested he reach out to you guys in an effort to assist wherever possible. (He's the author of Autoban.) He showed interest, so hopefully you'll see something from him at some point. Thanks @caseyburk <https://github.com/caseyburk> 👍 I hope that your guys' ideas ... also includes the ability to block / blacklist (or allow / whitelist) by IP ranges. Seems a reasonable request, and possible I believe (should be easy once we get the basic IP banning implemented I mean). In general, I would like to see us work on #3624 <#3624>, and adding things there that help people secure their sites (contrib modules would have a place to live under too 😉). That would be a great way to show that we are actually concerned about security, and making it easier for people to find security-related settings/tweaks in a single place in the admin UI. We could also be linking to security-related documentation in b.org from that place. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1878 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPUG6ZIIVJ5CRAW5YMN6SDPS5YANANCNFSM4CD7JNMA> .

[jenlampton]

It's release day and there's no PR here. removing milestone, adding candidate tag.

[oadaeh]

As an FYI, Hook 42 developed an autobanning module for one of their clients a while back. It has not yet been released into the wild, but I asked about it earlier this week, and that is still the plan.
I also asked them about porting it to Backdrop, and they are on board with that idea.
I did a code review of an early implementation of the module quite some time ago, but I don't remember the details. So as soon as I get access to the current implementation, I'll post the details here to see if that module would be at all useful here or not.

[klonos]

Throwing https://www.drupal.org/project/crawler_rate_limit and https://www.drupal.org/project/perimeter to the mix. I like the latter's approach:

Basic perimeter defence for a Drupal site. This module bans the IPs who send suspicious requests to the site. The concept is: if you have no business here, go away.

Use the perimeter module if you get a lot of requests to 'wp-admin' or to .aspx urls on a Linux server, or other similar requests.

Been working for a few years in hosting platforms where site owners are being billed based on page views or where their sites go down because of traffic spikes, and some sort of set-and-forget solution like the above for obviously malicious requests would just make sense in those cases. I agree that this problem is better to be addressed at the WAF/CDN layer, however not everyone can afford or know how to configure those. Having something that just works OOTB, especially requests to /wp-admin which is dead-obvious, would provide great value IMO.

[laryn]

Regarding contrib, I started to port path2ban and then I was informed that there's another module that's actively maintained -- antiscan (in combination with ip_blocking:

• https://github.com/backdrop-contrib/antiscan
• https://github.com/backdrop-contrib/ip_blocking