-
Notifications
You must be signed in to change notification settings - Fork 20
In case that for some reason you have locked yourself out of your own installation, the way to unblock yourself depends on whether you have .htaccess blocking enabled or not. If you don't know about .htaccess blocking, you probably have it disabled (it's disabled by default).
If you are using database blocking (the default), you have two alternatives to get back into your Joomla! installation:
-
If you have access to the database behind Joomla! (e.g. via phpmyadmin), then you have several options: To specifically remove the block on your IP address:
- Either go to the table
#__bfstop_bannedip(where #_ must be replaced by your database prefix); there, delete the entry with your IP address. - Or go to the table
#__bfstop_allowlistand add an entry for your IP there (an entry in the allow list will override any active block)
To disable BFStop altogether:
- Navigate to the table
#__extensions(where #__ again needs to be adapted to your database prefix). Locate the entry with name='plg_system_bfstop' and set 'enabled' for this entry to 0.
- Either go to the table
-
Alternatively, if you have FTP access to the server running Joomla!, you can also move the file "bfstop.php" in the folder "plugins/system/bfstop/bfstop.php" to another location, e.g. to "plugins/system/bfstop/bfstop.php.bak". Note that this will disable the whole plugin, though! You can then go to the backend, go to the list of blocked IP addresses (Components -> Brute Force Stop Administration), and unblock yours. Then it's safe to move the bfstop.php file back to its old location.
If you have .htaccess blocking enabled:
- You need FTP access to the server running Joomla! or another form of accessing the files on your Joomla! installation folder (e.g. ssh).
- Go to the root Joomla! folder, identify the .htaccess file
- If you have only FTP access, download the file; otherwise (e.g. via ssh) you can directly edit the file
- Open the file in an editor, find your IP address between the
# BEGIN Brute Force Stop Blocksand the# END Brute Force Stop Blocks(prefixed with "deny from "), and remove the line. - If you have FTP access, you will have to re-upload the file
- Note: .htaccess blocking works in addition to blocking via database. So you also have to go through one of the options mentioned above to get rid of the database block entry.
It is always worth to take a look at your webserver and php logfile first; if there's nothing there, enable logging on plugin side (see How do I turn on logging? ); repeat the process which leads to the unexpected behavior, and see if something meaningful turns up in the logfile; possibly you can then already resolve the problem yourself. If you find that something is wrong which you don't think you can do anything about, and which is an error in BFStop, then create an issue here: https://github.com/codeling/bfstop/issues.
- Go to the BFStop configuration (Extensions -> Plugins -> "System - Brute Force Stop")
- Under "Advanced settings", set "Logging" to "Detailed information"
The log file is named "plg_system_bfstop.log.php", and resides in the configured Joomla! log directory. Note that the file only exists if there already were some log entries.
You can check the changelog and the description of the milestone of the respective version. For a list of detailed changes (including the option to view the actual code changes, look at the plugin commit log or the component commit log.
You can take a look at the planned milestones for the upcoming versions, as well as the list of issues (you might also want to check the list of closed issues to see if something was already implemented in the git repository).
BFStop uses the Joomla! mail configuration. So, first make sure you have configured it correctly. To do so, in your backend, go to "Global Configuration->Server", and verify that everything there is set up correctly, e.g. that your mail server details are entered. See the Joomla! Documentation for details on that. Second, make sure you have configured a recipient for the notifications (currently configured in the plugin configuration). Make sure that at least one of the following applies:
- You have entered a valid email address in the respective input field
- You have selected a user
- You have selected user group with at least one member
When that is done, you can test the notification in the "Brute Force Stop Administration" Component under "Settings". In the toolbar, there is a button to test the current notification settings. It will report any issues it encounters during sending in the messages box. If something after the immediate sending goes wrong, you might have to check your inbox for return messages. Also make sure to check the logs.
Yes, specifying ranges is possible, both in the allow list and in the blocked list. The tooltip on hovering over the address input caption shows some information on how to do that. You have to enter the subnet in CIDR suffix notation. You enter an IP address, and after it, you enter a slash and the number of bits that need to match the given IP address.
Some Examples:
- If you enter "10.1.0.0/16" in the IP address field, it will block all IP addresses in the range 10.1.0.0 to 10.1.255.255 (this would be equivalent to a "wildcard" block of 10.1.*).
- If you enter "192.168.0.0/24", it will block IP addresses in the range 192.168.0.0 to 192.168.0.255 ("wildcard" equivalent would be "192.168.0.*).
When blocking such IP ranges, make sure you know what you are doing, so that you don't block yourself with a too generic range! Please cconsult for example the above linked article for more details.
Note: At this point, IPv6 ranges / CIDR suffixes are not supported yet, you will not be prevented to enter such entries, but they will simply be ignored. Their handling will be implemented in version 1.6.0.
Such a feature has been previously requested; and in a pre-release version this was also included.
However, the Joomla! Security experts considers this a possible information disclosure problem, as was reported for the Login Failed Log extension, see here: http://docs.joomla.org/Vulnerable_Extensions_List#Login_Failed_Log.
Therefore, there is a low probability that I will implement this. Under some special circumstances (when you want to do some statistics about used passwords in attacks, I guess?) this might be useful; but for the general usecase it is not needed.
Basically, BFStop aims at supporting the range of currently actively maintained Joomla versions; see the release notes as well as the Changelog for remarks on which Joomla! versions were the first to be compatible with specific Joomla! versions; as a quick overview: BFStop development started with Joomla! versions 2.5/3.0. Version 1.4.2 was the first released version compatible with Joomla! 4; the current version 1.4.6 is the first to support Joomla! 5. Support for Joomla! 5 in this version is basic and relies on the compatibility plugin being enabled, see this issue. The first fully Joomla! 5 compatible version (that is, without the compatibility plugin) will be the soon-to-be-released BFStop version 1.5.0.
Typically, backwards compatibility is kept a while after the support for a version is dropped (but it is not actively maintained anymore). Currently for example, J4 and J5 are actively supported, while support for J3 is slowly phasing out. For the upcoming BFStop version 1.5.0, there are currently plans to release two variants: one for Joomla! 3.x and one for Joomla! >= 4.
See https://github.com/codeling/bfstop/issues/72
BFStop uses Joomla's global "Default List Limit" configuration; see Global Configuration - Site. In versions released so far, there is no option to override this for a specific table; but it is available already in the main branch in the git repository, and will be released in version 1.5.0.
BFStop is a fun project I to do in my spare time; I currently do not accept monetary donations, and do not plan to do so any time soon. I would however be very happy about feedback in BFStop's Joomla! Extensions Directory entry or, preferred in case it is a bug or feature request, in the issues section here on github.