Contrib.social

Autoban Into Core?

Open on Drupal.org →
Created on 3 July 2019, about 6 years ago
Updated 24 June 2025, 12 days ago

Core Team -

I imagine you get gobs of requests to introduce / incorporate module functionality into the core architecture. This request is no different from those. This one is to lobby to have the Autoban functionality added into core.

For anyone unfamiliar with Autoban, it's basically a security module that allows you to define behaviors that Watchdog creates log entries for and when the respective event is logged, you can then have the behavior take action by banning the IP address of the culprit or else the entire range the visitor is on. Given the number of exploits we've been dealing with for the past year or so, I'd think that having something like this in core would be an absolute priority.

All that being said, the one flaw with Autoban is the delay sometimes experienced between the point in which the behavior is observed and the point in which the respective action is taken. It's believed that this delay sometimes occurs due to various layers of caching or else because of how the logs are recorded. Ideally, there shouldn't be a delay at all, implying that perhaps a functionality like what Autoban does might be possible somehow were it not so dependent on log file entries?

Here's a good example of this:

Let's say you get a number of random servers trying to probe your website for something like /wp-admin (a common location with Wordpress installs). The moment you see a visitor trying to make a request to your website for that location, you know for a fact that it's almost 100% certain that it's likely a black-hat bot probing for a Wordpress login form. Thankfully, Autoban provides you with the capability to define this behavior, in which case once this behavior is registered with Watchdog, you can either ban the infringing IP address the visitor is on or else ban the entire range. This is great except that tests have revealed how the actual act of banning sometimes doesn't occur until either cron runs or else until the admin (or someone with admin privileges) performs an action that allows the Autoban behavior to "kick in." So not only is there some form of delay between the act and the resolution but it's also a somewhat flawed approach due to relying on the Watchdog entries.

The best approach here would be to take what Autoban tries to accomplish but incorporate it into core at a point in which no delay is possible. Having something like this in core should be a game changer from the standpoint of offering more security for Drupal installations.

Have there been any discussions or plans made to do this? Thinking back at various "Drupalgeddon" storms, this form of functionality would be pivitol in (at minimum) biding time for site owners to apply security patches.

2 other modules also exist that could improve security... One locks down the login form to whitelisted IP ranges and another allows site owners to change the request endpoint of the login form. I can't remember what the names of those modules are but their intentions represent great ways to reinforce security efforts for Drupal. I mean, we all get nasty visits from loser bots but I can't seem to recall major efforts to add facilities into Drupal core to prevent and or stop completely these resource-sucking requests.

Is there anything being done for Drupal core on the security front seeking to provide site owners more capabilities to defend their sites against these kinds of things or will this continue to be something treatable only through a mixture of various modules?

Any insight on this would be appreciated.

✨ Feature request
Status

Active

Component

General

Created by

🇺🇸United States Wolf_22

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 12 days ago →
    🇳🇿New Zealand quietone

    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.

  • Comment 12 days ago →
    🇺🇸United States tim.plunkett Philadelphia
  • Comment 6 days ago →
    🇦🇺Australia pameeela

    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?

  • Comment 5 days ago →
    🇺🇸United States Wolf_22

    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.

  • Comment 5 days ago →
    🇦🇺Australia pameeela

    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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024