Autoban Into Core?

The Ideas project is being deprecated. As discussed in a core committer meeting issues that are adding modules are being moved to the Drupal CMS project for discussion.

I've never used this module myself. The usage is not overwhelming but not nothing either. Wondering if anyone has strong thoughts on this either way?

Thoughts about what? Its overall usage? While that may act as a good measure of a module's usefulness or success, anyone who relies on that metric alone can do themselves a disservice because if we all relied on that to determine a module's usefulness or success, we'd never discover new modules worth using. (I'm sure you didn't mean to come across like that was the only thing you were thinking of, so don't read that the wrong way. But it's something worth emphasizing, right?) It's my belief that if more people knew about this module, I think you'd see that current usage amount increase. More so if people understood the implication of disregarding their access logs as even the more trivial Wordpress endpoint probes have long-term affect for a site. But given the market share that Drupal is losing, it makes increasing its usage difficult to increase anyway. Things have definitely changed with Drupal since the version 7 days, and not entirely for the better.

But I've used this module for years, and from what I've seen during that entire time, it compliments really well the core functionality Drupal enjoys when blocking IPs and or entire ranges by pairing that core functionality with this module's ability to base block evaluation criteria on what I call "request signatures" (or requests that nodes make against your endpoints)... And it can do it all, autonomously. In other words, and as an example, if you get a bunch of bad bots probing your site for things like Wordpress endpoints (which we all get and should act on since they consume host resources), you can use this module to watch for those requests and use it to immediately block their IPs (or entire ranges) in response. I personally used this module to not only do exactly that, but also to essentially create a database of black hat IP (entire) blocks that I then use to prevent access to my site. It's just one piece of an overall portfolio of efforts I use to keep my site secure, and it's done wonders for that. In tech, we have to err on the side of prioritizing security-centrism. This module alone doesn't do it all. It's just one piece to a wider array of tools and approaches one should have access to (from core) and use when trying to keep their site secure, especially for those of us who lack the luxury of enjoying their own dedicated firewalls, intrusion detection systems, security teams, etc.

And that's the crux of it: Drupal has always come with YESTERDAYS method of blocking IPs / ranges in core (which is also mission-critical to have), but it's not TODAY'S more modern equivalent for the more advanced forms of very-much-necessary security-centric functionality core now needs. Yes, it needs to be in core. And between this, anti-bot, and a few other modules (such as that one that allows you to change core file locations and thereby make automated probing that much more difficult for black hats), well, Drupal has plenty of room for security improvements. I know the maintainers and the core team have a lot on their plate, so I know it's easy to demand or expect things like this, but in time, I can only hope that these functionalities somehow find their place in core. I know it'd go a long way towards making Drupal better.

Just my two cents.

Thoughts about what? Its overall usage?

No, the comment on usage was just an observation. I was asking whether other members of the community have thoughts on adding this module.

2 cents:
in situations where i've seen these types of ban tools used...my general opinion is that trying to block within a PHP runtime (drupal) is not successful in heavy load situations as the server is already in crisis. trying to get to an admin path, or trigger drush commands -- tends to fail at those points too. These tools are not the best way to safeguard a running app. IMO.

adding 'blockible path' to htaccess (items like /wp-admin) is should be done if that is to scope concern of that site owner...

adding 'blockible path' to htaccess (items like /wp-admin) is should be done if that is to scope concern of that site owner...

In your scenario, I'm not sure it would matter if we err on the side of using PHP or HTACCESS because an overwhelmed server is an overwhelmed server: If it's unresponsive due to something like a denial-of-service attack, then that'd be a completely different scenario anyway that no module nor server configuration (short of firewall controls) will overcome without some kind of external intervention either in the form of (for example) data center or web host staff or intrusion detection system (IDS) disaster recovery.

But even if you opt for HTACCESS in the scenarios that this module tries to accommodate protections for, you're putting all of your nuts and bolts in 1 point-of-failure bucket that runs the risk of incorrectly configuring your respective server's flavor of HTACCESS implementation as HTACCESS isn't exactly a standardized web server feature that exists between the different types of web servers that exist in the wild, especially when it comes to access path request controls. For example, Nginix and IIS both have their different / proprietary methods for incorporating it, to say nothing about the versions that may conflict between environments.

I also think it's important to provide a method for allowing protections from a module layer anyway since not every website owner has access to luxuries like firewalls or IDSs (as is usually the case in shared hosting plans and even some virtual private plans). If something like using and controlling HTACCESS could be programmatically accomplished by way of Drupal's module API layer, then sure, that'd be a great inclusion! And technically, the best of both worlds would be to have this module (or maybe a new module altogether) incorporate control over both HTACCESS and what it currently provides from its PHP layer in an all-inclusive security module that uses all available possible security features that the majority of web servers might be configured with. Best of all would be to have it all added into core, but I doubt we'll ever see that. So, I'd be content in just having what this module currently does added into core.