simco

I did deactivate every other plugin and tested, same results. I’m using the latest version of your plugin, 4.0.2. This problem seemed to occur when the last update hit that included your notice to install the ‘business location’ plugin that won’t go away when clicking the Dismiss This Notice link.

All other elements are up to date, theme, plugins, WordPress, etc.

Ideas?

I think we’ll opt for the IF statement method. But i’m sure i’ll be back here to get some help ?? Most specifically to the assignment of multiple templates to a form and so forth. Thanks!

Are there any examples of that in the templates folder?

I see, so it’s possible to allow the template to determine what ‘sections’ will be displayed/completed?

Awesome! And how would that form then select the template needed for the output since it’s predicated on the type of bond they are applying for?

Thanks for the unbelievably quick response!

I checked the .htaccess and it did have the ‘old’ instruction in there. I deactivated/reactived the pingback element and the new instruction is in there now. Let’s see if that takes care of the login access URL problem.

XML-RPC server accepts POST requests only.

That’s the message I get when typing the url with that extension.

Totally different. Basically from all over the world and obviously using proxy servers. The last two were from the U.S. and Japan. The one before that was from France.

I don’t expect the plugin to ‘stop’ the attack. It’s doing its job in preventing the ability for them to gain access via a ‘site lockout’ due to the fact they are attempting to log in with a username that doesn’t exist in our database which is one of the settings in the AIO plugin. But, still, it’s giving them the ability to ‘attempt’ the login. Meaning, they can still try.

The understanding of the ‘hide the login’ function is so they can’t find it (the login page). Even if I named it a URL that was so ridiculous that a NASA computer couldn’t figure it out, these hacker attempts somehow found the login page or they wouldn’t be able to do these repeated attempts. So, either that function isn’t working OR these guys are off the charts geniuses.

The basic question is ‘How did they find the hidden URL no matter what I change it to’. Not ‘How can I stop the bot’. If we solve the first question then the second one is irrelevant.

FYI, I just received 9 more notifications of attempts to log in using ‘admin’ as the username. Somehow this ‘bot’ or super-human is able to find the hidden login URL or bypassing the settings in some way.

No other security plugins are installed. Nor is there any caching plugins installed.

Regarding the login attempts, I think what I was trying to say is that we are currently receiving notices via AIO stating a site lockout was imposed due to someone attempting to log in under an unregistered name (admin). Here’s an example of one just received in the last hour:

A lockdown event has occurred due to too many failed login attempts or invalid username:
Username: admin
IP Address: 182.160.155.72

IP Range: 182.160.155.*

Log into your site’s WordPress administration panel to see the duration of the lockout or to unlock the user.

Over the past 48 hours I have received about 150+ of these all pointing to different IP addresses but all trying to log in under ‘admin’ username which doesn’t exist. It’s obviously some ‘bot’ or automated program making the attempts. But the question remains as to how they found the hidden login page.

Hard to say, actually. I deleted the old error_log without looking at it because it was about 2.6mb’s and thought it was just dead weight. That was about 2 days ago. Then, I noticed the new error_log was about 240k in just 2 days so decided to investigate and noticed the error. I’m assuming this has been occurring since the plugin was installed initially.

Yes, just the rename login page is enabled.

This is the reason I posted in the other threads, the question is ‘how are they finding the login page in order to conduct these brute force attacks’. The other posts were related to that same issue/topic so I posted my issues there as well

They are related only in the fact that the error message I posted here is the failed attempts at logging the repeated failed login attempts into the database. This could result in the inability of the plugin to actually block further repeated attempts from the same IP’s.

I’ll look forward to hearing from the developer(s). Thanks!

I’m getting the same types of hack attempts, repeated brute force attempts to log in as ‘admin’ from different IP’s on each attempt.

The ‘prevent pingbacks’ function is/has been active this entire time. So, apparently it’s not blocking the xml/rpc attacks you mentioned.

Since ‘admin’ doesn’t exist we haven’t had to worry. But, it does give us the feeling that they have found our login form which should be ‘cloaked’ with the custom URL provision in AIO.

I’ve also had a similar attack over the past 24-36 hours. Repeated attempts to log in with the username ‘admin’ which I have blocked with the setting pertaining to ‘lock out login attempts with usernames that don’t exist’. The IP addresses are different for each attempt. Obviously it’s an automated method they’re using to try to gain access with the ‘admin’ commonly used login name.

It’s locking them out but it would be great if there was a way to simply stop the attack. The attempts come in spurts and no specific intervals time wise.

Any suggestions would be helpful.