Maikuolan

Hi,

Any sufficiently strong measures to keep out the majority of nasties is going to have at least some small degree of false positive risk. As to the actual severity of that risk, as well as exactly what would constitute “sufficiently” strong, will somewhat depend on the nature of the website in question and the scope of its normal, intended traffic (e.g., whether that traffic is inherently internationalised versus being more localised, targeting a specific country or region, and therefore how vigilant we’re able to be in regard to blocking anything outside the targeted countries/regions; whether the software being used on that website behaves in ways that might trigger any of CIDRAM’s signatures; commercial versus non-commercial websites, in the sense of how that would play into tolerances; etc). Which kinds of block events actually constitute a false positive in the first place is also somewhat opinionated, given that whether something should or shouldn’t be blocked in the first place is also somewhat opinionated and that a false positive is defined on that basis. Because of that, what would generally be considered the best, most optimally balanced settings is likely to vary somewhat from one website to another.

That all said, there are some general recommendations that should hold true for just about everyone.
– Enabling measures for users, in limited circumstances, to be able to regain access to the website when wrongly blocked, e.g., by enabling CIDRAM’s ReCaptcha or HCaptcha features (or even, when possible, both) is going to be a good idea. While not eliminating the risk of false positives, it’ll take the sting out of it in most cases.
– For the most part, the more modules, signature files and such which are active at an installation, the stronger that installation’s provided protections will be, but also, the higher the risk of false positives. Of those available modules and signature files, using what you need while leaving out what you don’t need, in general, is going to help in regard to finding that sweet spot between best protection and least false positive risk. Knowing exactly what it is that you do and don’t need often comes down to a combination of experience and knowing what each module and signature file provides. The latter part of that, at least, can be learned by reading the descriptions of those available modules and signature files as shown at the updates page.
– Log as much as you can. If anything goes wrong (i.e., when false positives occur), logs will help in diagnosing exactly what has gone wrong, and help in finding the right solution to the problem. Without logs, in most cases, we’re left in the dark about such problems.
– If you’re not sure what something does, ask.
– Checking how “signatures➡shorthand” has been configured and adjusting according to your needs (i.e., based on the reason for something being blocked, whether you would agree or disagree that it should be blocked in the first place) is always a good idea.
– Wherever possible, the signature files and modules I would recommend for most installations are already enabled by default, but there are some which aren’t, because they require API keys which would need to be entered into the configuration in order for those modules to work properly (e.g., the AbuseIPDB module, the Stop Forum Spam module, the Project Honeypot module, etc). Enabling those can definitely help with keeping the nasties out, though there some inherent limitations, too (i.e., regular API lookups could slow a website’s response times down a bit where performed, plus most such APIs tend to impose lookup quotas, so it’s generally best not to use all of them at the same time, and to only perform those lookups where essential, such as at a website’s login and registration pages, contact pages, etc, in order to not affect performance too much and to avoid surpassing any imposed quotas; though, of course, that would mean that any pages where said lookups aren’t being performed could still be accessible by anything which would normally be blocked by said lookups). All of said APIs also have their own inherent false positive risk, too.
– The more time you have available to monitor and optimise everything over time, generally, the stricter you can afford to be with your settings (because you’ll be more likely to notice if/when something goes wrong and have the time to adjust accordingly). The less time you have available, the less strict you’ll likely want to be with your settings due to the increased risk of not noticing when something goes wrong and/or not having the time to fix it when it does. In a less-strict scenario, you’ll likely be blocking less nasties than would be ideal, but also likely incur less false positives than would otherwise be the case. In a more-strict scenario, you’ll likely do better at blocking the nasties, but may potentially incur a greater number of false positives than would be ideal (but will also hopefully have the time, log data, and anything else necessary to be able to rectify the problem when it occurs).

If I think of anything else, I’ll write it in a separate, subsequent reply, so that this reply doesn’t reach TL;DR lengths and to avoid the risk that I accidentally repeat any points. Anyhow, for now, I hope that helps. 🙂

No worries; Happy to help. And done. 🙂

From the front-end updates page, look for “Quic cloud compatibility module”, select “Install + Activate“, and press “OK”. After that, it should all be handled automatically.

Hi,

The easiest way to prevent a specific IP address being blocked would be to whitelist that IP address via an auxiliary rule.

From the auxiliary rules page at the CIDRAM front-end:
1. Click the “Create new rule” toggle to display the controls for creating a new auxiliary rule.
2. Enter a name for the new auxiliary rule.
3. From the auxiliary rule action menu, select “If the following conditions are met, whitelist the request.”
4. At the provided condition line, at the condition source menu, select “IP address”, and at the condition value field, enter the IP address to be whitelisted (the attached image shows as example).
5. Click the “Create new rule” button (all the other fields/menus/etc provided at the page can be ignored for now, as they won’t be needed for this specific rule).

Once done, CIDRAM shouldn’t block the IP address anymore. For any IP addresses already recently blocked (e.g., the specific IP address of concern in this case), be sure to also clear said IP address(/es) from the IP tracking page if/when listed there. 🙂

If there’s a cache.dat file located in the base of CIDRAM’s vault directory, that’ll be the file containing the tracking information for login attempts (alongside any other temporary caching, statistical information, etc). Deleting that file outright should immediately restore access to the login page.

If the file doesn’t exist, it could be the case that CIDRAM has detected the availability of a supported caching mechanism (e.g., APCu) and has opted to use that instead of file caching. If that’s the case, to restore access to the login page, you’ll need (in order of most-to-least tedious) to either (1) delete the specific cache entries responsible (if the caching mechanism used provides some kind of interface of its own, most likely using that, or, if not, it might be trickier as you’d likely need to interact with its API using code), (2) restart the cache mechanism (typically achieved by restarting the PHP process, as most such caching mechanisms typically interact with PHP via PHP extensions), or (3) wait 24 hours for it to expire by itself.

The code responsible for creating the cache entry which triggers the “Maximum number of login attempts exceeded” message, blocking further login attempts, sets the expiry/TTL for that cache entry as 1 day from its creation time, as long as the login endpoint isn’t being continuously hammered after the default maximum number has already been reached (e.g., by bots, which mightn’t realise they’ve been blocked from logging in and might keep trying anyway), or, for when that occurs, sets it as 1 day multiplied by the number of additional attempts.

Steps taken sound good so far. :+1:

Have you also populated some values into the “phpmailer” configuration directives at the configuration page? If anything needed from there is missing (e.g., phpmailer➡host, phpmailer➡username, etc), that could potentially cause 2fa to not work properly.

• This reply was modified 2 years, 5 months ago by Maikuolan.

Hi @kbliang,

I’ve pushed some changes just now which should solve the problem. If possible, from the front-end updates page, try updating to the latest available version (3.5.0-DEV+233360).

If not possible (i.e., due to 2FA already being enabled, and no available front-end account without it), if you edit your CIDRAM’s configuration file, look for the line enable_two_factor: true and change it to enable_two_factor: false, that should disable 2FA for your CIDRAM installation (you can reenable it again from the front-end configuration page after you’ve successfully logged in and updated).

After updating, try reenabling 2FA. If the problem persists, let me know. 🙂

Hi @webtesher.

The issue should now be fixed (commit a83e933) 🙂

CIDRAM installations can be brought up-to-date early (e.g., when some kind of bugs like this have been fixed, and we want to patch our installations with the fix, but development isn’t quite ready just yet to have a new version/release tagged here at ww.wp.xz.cn right away) by updating via the CIDRAM front-end updates page.

If the issue persists, please let me know.