Anti-hammering / Login blocker

Authentication ::: auth_antihammer
Maintained by Sebsoft Plugins, Rogier van Dongen
The Sebsoft Anti Hammering Authentication Plugin offers you the possibility to prevent hammering your login system. This plugin can be configured to "smart detect" so called hammering on IP basis or for users in general.
Latest release:
201 sites
63 downloads
21 fans
Current versions available: 6


SEBSOFT ANTIHAMMER PLUGIN


The Sebsoft Anti Hammering Authentication Plugin offers you the possibility to prevent hammering your login system.

This plugin can be configured to "smart detect" so called hammering on IP basis or for users in general.

Hammering is the process of pretty much brute force attacking Moodle's login system.

This plugin detects the IP address of the remote client, and will track the entered username (and, if the

username exists, also the Moodle userid) and stores it's information to block the user and/or IP address

depending on the configuration of your authentication plugin.


When the plugin has been installed, you should enable or disable blocking by IP and/or username and

configure the timespan at which detection is valid and number of times an attempt can be made.


This plugin can also be configured to make use of the messaging API in moodle.

This is a specific setting that needs to be enabled; if not configured the messaging API will not be used.

Please note receiving messages is not configured for everybody by default. Every applicable person (usually

administrators) MUST configure their preferences if they'd like to receive these messages.


Moodle's lockout system vs Antihammer:

Moodle already has the capability to (temporarily) lock out users https://docs.moodle.org/30/en/Site_policies#Account_lockout)


However, this plugin will add to that functionality, enabling to also take a look at specific IP usage of users trying to login.

There is *no* interaction with the lock out users system of Moodle.


If you want to be able to use the default method of Moodle account locking, but want to use

this plugin for the additional functions of being able to block hammering/testing of passwords

from a certain IP, you need to enable the IP Settings of the antihammer plugin.

You *need* to keep the User mode/setting disabled if you wish to keep Moodle's standard account lockout.


Furthermore this function differs from the Moodle implementation as Moodle will also allow

you to configure if you want to send an e-mail with a unlock link.

The Antihammer authentication method does not do this, as it's more of a way to

provide additional security and possibly block attacks with admin notification.


*Warning*: Whatever you do, do *never* enable both the user mode in Antihammer

AND the account lockout feature together, this may/will cause unintended side effects.


Important note:

This plugin does not neccessarily prevent brute force hacking when IP detection is not configured.

When the only checks are done based on the username, and an attacker uses a different username on virtually

every request (dictionary hacking), a lot of log/status records will be created, but this plugin can't

really do anything (simple because the username is differing too often). In that case IP blocking might help.


Please note this authentication plugin creates administration menu items to view the logs and status tables.


INSTALLATION


- Copy the antihammer folder to your auth directory.

- Configure your authentication plugin.

- We're ready to run!


Screenshots

Screenshot #0

Contributors

Sebsoft Plugins (Lead maintainer)
Rogier van Dongen: Lead maintainer / developer
Please login to view contributors details and/or to contact them

Comments RSS

Show comments
  • Rogier van Dongen
    Mon, 10 Jan 2022, 9:12 PM
    @Natassia,
    Please allow me some time to work out any extra details (I'm extremely busy at the moment); but I can already provide you some answers:

    - Yes, the authentication plugins are loaded and applied/called "in sequence" conforming to the sequence as set in the administration interface. So you are absolutely correct the antihammer plugin should be your very first in the sequence. This makes sure any checks are done before anything else (please also be aware we do NOT actually validate the login process itself but rather the so called loginpage hook. If data (such as the username) is available because of e.g. a postback, it will be used for the user detection/blocking feature. However, because this hook is called before anything else or even before the page is first loaded, this is exactly where we hook into checking the IP address. In short: we hook into the process at the very first possibility, indeed trying to prevent as much wasteful code execution as possible.

    For your other question regarding defaults: you're not the only one who is confused, I've been asked this question multiple times before.
    It's pretty easy: when you define global settings, the whole idea (and often mandated to be provided), plugin defaults indicate exactly what they imply: default settings.
    When a plugin gets installed _first_ time, these are the defaults used to pre-fill any checkboxes (e.g.: checked when the default implies "Yes").
    Please note "first time", because after that, the _known_ configuration will be used to set the state of checkboxes, dropdown, lists, text entries, etc etc.
    In other words: only on first installation (OR when introducing a new setting) will these defaults actually be used. They will still be indicated as the defaults and whenever you perform a "reset to defaults" these values will be used.
    In any other circumstance, I fully agree with your confusion: it only adds information to the interface that can be misinterpreted and might eaise more questions than it provides answers. It's just how Moodle has imp[lemented things though. Unless they change the interface (which can always be requested in the Moodle Tracker), it's something you have to deal with, as misleading or confusing as the indications may be.

    For now, these are my answers. I hope to get some time free any time soon to implement more fine grained ways of offender penalties.
    Cheers
  • Channara Chea
    Fri, 21 Jan 2022, 5:39 AM
    This note seems important, where do I go to ensure I don't do this?

    *Warning*: Whatever you do, do *never* enable both the user mode in Antihammer

    AND the account lockout feature together, this may/will cause unintended side effects.
  • Rogier van Dongen
    Mon, 28 Feb 2022, 7:52 PM
    @Channara,
    The account lockout features in core Moodle can be located under the site security settings in the security section of the site administration settings.
    Whenever you're using user mode lockout features from the plugin; you should make sure you have Moodle's settings for "Account lockout threshold" set to NO.
    In the future we may add a message indicating when both settings are in use.
    Cheers,
  • Steve Radford
    Tue, 12 Apr 2022, 4:44 PM
    Hello, Can I check if this will be upgraded for Moodle 4.0 when that's released next week? Many thanks.
  • Rogier van Dongen
    Wed, 13 Apr 2022, 4:42 PM
    Hi Steve,
    Just checked (and fixed some minor coding standards issues as well as added a capability string) and I can confirm the plugin to work for Moodle 4.0
    Please be a little patient for the new version as this is an automated job these days but at this moment requires some updates.
    We do have the new version ready for (automated)release but only on our internal git at the moment.
    Cheers
  • Steve Radford
    Wed, 13 Apr 2022, 5:11 PM
    Thank you Rogier, that's amazing. I'm keen to upgrade to 4.0 fairly quickly after launch, and this is a plugin I really wouldn't want to lose during the process. Thank you for your fast response to my comment and for the work you're doing to update the plugin!
  • Rogier van Dongen
    Thu, 14 Apr 2022, 7:15 PM
    New version is here!
    Validated working for Moodle4.0
    No significant additions to features this time; just some minor fixes.

    Cheers!
  • Виктор Рогов
    Sat, 25 Jun 2022, 6:12 AM
    Please may you attempt to support wildcards for ip at first? It would be so useless to type whole huge local network without wildcards
  • Rogier van Dongen
    Tue, 30 Aug 2022, 4:16 PM
    Hello Виктор,
    Can you provide more details for your use case?
    This plugin is intended to temporarily block out users that hammer the authentication system and, if applicable, blocks the source IP address.
    However, the plugin is not intended as a low level security layer.
    Because the plugin works with the current source IP addres, expanding to wildcards is not something this plugin should be responsible for.
    One of the reasons is because it'd have to be configurable what parts to "wildcard".
    If you wish to block IP ranges, Moodle has another mechanism (mind: using both the plugin and Moodle's internal IP blocking _can_ cause unintended side effects!).
    Please look into https://docs.moodle.org/311/en/IP_blocker
    Cheers
  • Виктор Рогов
    Wed, 5 Oct 2022, 5:42 AM
    Hello Rogier van Dongen,
    English isn't my first language and maybe is better to say that in my university has really huge network which I don't want to block accidentally when someone in local network can't login because forgot password.
    It would be really hard for me to typing all ip addresses which starts from 10.0.0.0.
  • Natassia Stelmaszek
    Wed, 4 Jan 2023, 1:28 AM
    Виктор Рогов
    I set my system to Autoclear blocked IPs after one hour. That prevents a real user from being permanently locked out. I only use the Whitelist to allow a few maintenance consoles constant access.
  • Natassia Stelmaszek
    Wed, 4 Jan 2023, 1:42 AM
    Rogier,
    I installed your latest version on my system running Moodle 4.1 on a Rocky Linux system. FYI - When I go to Site Administration -> Anti-hammering/Login blocker section and click on the "Repeat offenders" link, I get an error "Section error!" with a link to a moodle.org page. But I can click on the "Antihammer reports" or "Antihammer logs" links and then click on the tabbed link for "Repeat offenders" which does seem to work.
    Natassia
  • Rogier van Dongen
    Mon, 16 Jan 2023, 9:33 PM
    @Natassia,
    this is fixed (though only locally at the moment). The next release will have this fixed.
    Cheers
  • Minh Nguyen Ba
    Wed, 13 Mar 2024, 5:56 PM
    Hi,

    We are using Anti-hammering / Login blocker. It works, it can block IP. But the notification report does not include username.
    "The block is made active for IP address xxx.xxx.xxx.xxx, username -". Does anyone know how to include username in report.

    Thanks
  • Rogier van Dongen
    Mon, 18 Mar 2024, 4:21 PM
    Hi Minh,

    The plugin doesn’t directly tie the IP address to the user but follows a different strategy.
    ”Hammering” is determined on 2 levels: IP based and user based.

    The IP strategy looks at the IP address and marks a counter on it. Exceeding the counter within timespan X with the configured value will instantly lead to the IP being blocked.
    The USER strategy looks at an entered username and marks a counter on it. The combination of user vs counter is the key here. Exceeding the counter within timespan X for user Y will lead to user user Y being blocked.


    This is also why IP blocks cannot be sanely provided with a user: there’s no direct correlation between the two unless the block on both IP and user is/was a result of the person entering the exact same username every time (for whatever reason).

    In this case the IP block is processed in favour of the user block. We may change this in a next release so this very condition will make two blocks: one for the user and one for the IP.
    The code can then also try to correlate the two and see if both would be applicable.
1 2 3
Please login to post comments