2023 slots free play,Taya 365 VIP.REGISTER NOW GET FREE 888 PESOS REWARDS!

AIOSecurity isn’t locking out IP addresses

goddin — Mon, 18 Nov 2024 11:05:39 +0000

I am having an issue with AIOSecurity re brute force attacks on my site. They occur daily, which I’m told is not unusual, but I have the setting to lock out an IP address after 3 failed attempts within 5 minutes and this is not happening. The audit log shows the same IP address being used for roughly 50 login attempts, then another IP is used for another 50 or so attempts and these IP addresses are not being locked out. There’s nothing in my log about lockouts occurring. These attempts all have the same time stamp, meaning apparently 50 attempts is performed by a bot in one minute. I am blacklisting the IP addresses after the fact but I’m now unsure the plugin is working at all. I also have the setting turned on to instantly lockout use of specific usernames (admin for instance) yet this policy isn’t working either. My log shows 50 attempts from the same IP (not mine which is whitelisted) with the user name admin.

How can I troubleshoot this issue? I don’t use any other security plugins. I’m on a Litespeed sever and use that plugin, and i use AIOSEO plugin, those are the ones i assume might be conflicting. My site is a multisite. The site in question is my main site.

I’m also annoyed that the speedometer graphic shows my site is green but if it’s just measuring plugin settings that are turned on versus functioning as intended then it’s a misleading indicator.

username empty attack

laellou — Wed, 17 Jul 2024 13:43:47 +0000

I have a lot of attacks

“This email was sent from your website “JDG” by the Wordfence plugin at Wednesday 17th of July 2024 at 09:26:25 AM

A user with IP address 111.90.148.123 has been locked out from signing in or using the password recovery form for the following reason: Exceeded the maximum number of login failures which is: 3. The last username they tried to sign in with was: ”.
The duration of the lockout is 4 hours.
User IP: 111.90.148.123
User hostname: server1.kamon.la
User location: Kuala Lumpur, Malaysia??

I have change the login page,

block the access on my CDN except for France for wp-admin, login.php and account/lost-password and for my login page

XML-RPC is deactivated

So I don’t understand how is it possible and how is is possible that ” The last username they tried to sign in with was: ‘’.

Username is empty ?

Could you help me ?

Best regards,

locked out, cleaned AIOWPS and still not being able to login

Tue, 21 May 2024 10:34:05 +0000

I have trouble with AIOWPS:

after cleaning all AIOWPS parts (plugin files, database, etc., as recommended by your instructions here in the forum) and after clearing all caches, I get the following message when trying to login to WP:
“The site is experiencing technical difficulties. Please check your site admin email inbox for instructions.”
what can I do?

Brute force incorrect redirects

Lovro Hrust — Thu, 02 May 2024 10:09:19 +0000

I recently had problems with several pages (at different times) with cookie based brute force prevention. I was unable to login, redirection was active even when correct secret URL was entered. After disabling brute force redirection through wp-config, clearing wp caching plugin and clearing and setting cookie based brute force prevention, secret url started to work, but after filling username and password, the page was redirecting in a loop (back again to login screen). After a while of tinkering, I found out that clearing Cookie based prevention, and setting Rename login page url fixed things.
Is there any cache in the plugin for PHP-based redirection which can be cleared in such cases?
If so, how to do it?

Minimum Lockout Time setting

Rent-A-Geek LLC — Fri, 26 Apr 2024 12:30:38 +0000

I see mention in past support posts in this forum that there was at one time a setting for the minimum time that an IP address would be locked out after a brute force login attack.

Is this setting still available? I cannot seem to find it anywhere in he AIOS settings. My site is running version 5.2.9.

Thanks…

JGB

WordPress Brute Force Attack | dynamic-linx

Generosus — Tue, 19 Mar 2024 15:00:38 +0000

Good Day,

Is SiteGround aware of this extremely malicious Brute Force attack? (click below)

https://windowsreport.com/wordpress-brute-force-attack/

https://blog.sucuri.net/2024/03/from-web3-drainer-to-distributed-wordpress-brute-force-attack.html

If so, has it been mitigated via server and plugin security updates?

Thank you!

Flooded with brute force login attempts

pierregielen — Mon, 11 Mar 2024 09:48:21 +0000

Since a few weeks now, our site is flooded with brute force login attempts, a couple of dozens every day. Until now, no one has succeeded in getting in and even if they would guess a working username/password combination, they will only encounter the second level of protection, 2FA.

I have not seens this much illegal login attempts since I have changed the url of the login page (wp-admin) to something else, so I am wondering how it is possible that hackers can still come this far and reach the login page. Is there a bypass somewhere in the AOIWP plugin or in wordpress?

Free Micro Cloud Upgrade

QUEERmdb — Thu, 15 Feb 2024 15:40:39 +0000

Your plugin says: Warning: Your website has had over 100 failed registration attempts in the last 24 hours. Your website is currently exposed to a higher risk of brute force activities. We recommend our free Micro Cloud upgrade to get access to our registration firewall and other premium functions.

Where can I get this upgrade? Google research didn’t find usable answers.

Can’t login after enabling brute force protection

bahus — Sun, 11 Feb 2024 12:35:29 +0000

I can’t log into the admin panel after enabling the brute force protection featu

I remember the addition at the end of the address.
But when logging in, the page redirects to https://127.0.0.1/.
How to bypass this and get into the site admin area?

Add mistype leeway for “Immediately lock out invalid usernames” function

nathanm4444 — Thu, 04 Jan 2024 10:52:16 +0000

Feature Request

The “Immediately lock out invalid usernames” feature is a very useful feature that protects against bots that are trying non-existing usernames. Although the username “admin” is tried most often by bots and this is easily blocked, it is also useful to restrict access for other false usernames that are tried by bots. It is safer to immediately block IP-addresses that try non-existing usernames to gain access, and this also saves server capacity

https://pasteboard.co/I6PhFSK7f9hW.png <– Firewall page

WordFence allows website administrators to filter any website visitor that uses different usernames than the ones already existing, logically assuming that the actual users, editors and administrators of that WordPress website know their own usernames and will not try a bunch of different usernames to gain access. But WordFence also assumes users will type in their usernames correctly every time.

With the website that I am managing, it is not easy to ‘guess’ the different usernames. Certainly with 2FA added, logging in is very secure. But whenever one of my users or editors (from different locations/IP-addresses) mistypes their username, they are blocked out and have to use the link that is sent to their email address.

Now, I do not want to add the IP-address of every single user to the IP white-list, because this is a lot of work and there are different locations. And I also do not want to turn this feature off, because it saves valuable server capacity and my website responds faster to actual visitors.

So what I am suggesting, is a mistyping algorithm that predicts how the existing usernames could get mistyped, and then allows for a second chance when a mistype occurs.

For example, the username johnsmith is not blocked, and the algorithm predicts that users might mistype this username in the following ways:

johnamith
jojnsmith
johnsmir
johnsmiht

Then the words ‘johnamith’, ‘jojnsmith’, ‘johnsmir’ and ‘johnsmiht’ are added to the whitelist. Whenever an IP address types in this username combined with a password that exists in the login database, they are not immediately restricted and blocked. The page will return the login menu and the user will be given a second chance to login.

In conclusion, this is what feature is missing: