damien7

Hi Igirao,

Thanks for bringing this to my attention. I suspect the firewall is using old paths from your dev environment.

Can you try downgrading the firewall by going to WP Security > Firewall > Advanced settings?and press the?Downgrade firewall. button.

Is the error resolved when the firewall is in the downgraded state?

If so, will you try then clicking the Set up firewall button and see if the error is also now resolved in that state?

If this fixes your issue, then I would suggest downgrading the firewall when you need to move environments. I’ll also investigate to see if we can handle these situations better.

Thank you for letting me know; I’m glad everything is back working as before.

Hi,

That’s part of the firewall setup. Essentially, when the firewall is setup, it attempts to set itself up before WordPress loads to give greater protect. The code in wp-config is one of the places. Another place is in your .htaccess file or .user.ini file (depending on the server type).

The .htaccess / .user.ini is the most important, if the code is in those files, you can remove the code from the wp-config if you don’t like it there.

Alternatively, if you want to undo all the file changes that the firewall setup has made, you can go to WP Security > Firewall > Advanced settings and press the Downgrade firewall. button. You can set it back up in that same location if you wish too.

Hi Igirao,

It looks like the directory where the firewall’s rules are located is being denied permission.

Are you able to ensure that the following directory has permissions set to 755: plugins\all-in-one-wp-security-and-firewall\classes\firewall\rule\rules

With the latest update (5.1.8), the failed login table entries should now have been transferred to the audit table. If you go to WP Security > Dashboard > Audit logs are you able to confirm whether the date is now correct for you?

If it’s not, could you provide a screenshot of the table? You can blank out any potential sensitive information beforehand.

Thanks again.

Thank you for clarifying and apologies for the delay in responding!

Can you just confirm whether the date is correctly showing in the audit log? If you go to WP Security > Dashboard > Audit logs and let me know if the date displays correctly for you.

We’re working on moving the failed logins to the audit log. So if the audit log works for you, then it should be resolved shortly.

Hi Mina,

Can I just clarify: Are we talking about WP Security > Dashboard > Permanent block list table or WP Security > User Login > Failed login records table?

If it’s the Failed login record, then the corresponding database table for that would be aiowps_failed_logins. Are the dates correct in that table too?

Thank you for your patience on this issue.

Hi Mina,

Apologies for the delay in replying. I’ve still not been able to replicate this even after changing the calendar, timezone and language to match yours.

Is there a problem with the other tables in AIOS plugin? Or is it just the failed login table being affected? If it’s just the failed login table being affected, you could deactivate the plugin, delete the aiowps_failed_logins table and reactivate the plugin and see if that resolves the issue.

Alternatively, we can take a look on the backend for you, if you’re able to provide access. If you’d like to go this route, you can post the necessary details to our private support: https://aiosplugin.com/premium-support/

Thanks

Hi Mina1400, thank you for your patience on this.

The date set in the failed login table is also affected by WordPress settings.

Are you able to go to Settings > General and let me know what you have set for the Timezone , Date Format, and Time Format settings?

Also under the Timezone setting, it shows you the Universal time and the Local time, are you able to paste what they say in here too?

Hey Shun Abe,

It looks as though the auto_prepend_file directive is pointing to aios-bootstrap.php file, but that the aios-bootstrap.php file does not exist.

You can manually create the aios-bootstrap.php file in your root directory (the same directory where WordPress is installed). And that should get rid of the error.

However, if you would like to remove the aios-bootstrap.php file, then you will need to remove it first from the auto_prepend_file directive.

Where the auto_prepend_file directive is set depends on your setup. Please check the following places:

– php.ini file
– .htaccess file
– .user.ini

Hi isaac2k2,

Thanks for the question.

The RedirectMatch 403 directives are from the Advanced character string filter option.

If you go to WP Security > Firewall > Additional Firewall Rules, you will find the option for Advanced character string filter. If you disable it, the redirect directives should disappear from your .htaccess file. If you enable it, they should return.

I hope that helps.

Hi CreativeAlien,

Thanks for the question and apologies for the delay.

Enable 6G firewall protection acts as a master switch that enables or disables all the 6G options at the same time. So if you enable Enable 6G firewall protection and save the settings. You’ll see that all the options on the 6G firewall page are enabled (except for the POST header). Conversely if you disable it and save, then you’ll see the settings are disabled.

You may not want to enable or disable all the settings at the same time, so you can individually enable the the options instead. Which is why you have the individual options in the 6G other settings

As you already know the Block referrers and Block user-agents block patterns from the referrer and user-agent headers which 6G deems malicious.

The Block request strings will block patterns from the requested URL. So if you have the URL: example.com/example/users/all. Everything after the host (so the /example/users/all part of the URL in this example) will be checked for malicious patterns.

The Block query strings will block patterns from the query portion of the URL. So if you have the URL: example.com/example/url/admin.php?name=example&action=submit. Everything after the question mark (so name=example&action=submit in this example) will be checked for malicious patterns.

If you would like to see what patterns 6G deems malicious, you can check out the perishablepress website: https://perishablepress.com/6g/

I hope that helps.

Hi leechu84, it looks as though that code is blocking all requests to your site except of those that come from PL (which I’m guessing is Poland?). If you want Google bot to not be blocked, you’ll have to explicitly add the Google bot’s country to your allow list.

Thank you for letting us know. I will investigate this further and hopefully will have a patch for a future release.

Thanks for reaching out to us. What errors are you receiving when trying to rename the login?