Resolving Common Solid Security Lockout and Configuration Issues

Solid Security (formerly iThemes Security) is a powerful plugin for hardening your WordPress site. However, users sometimes encounter issues with lockouts, configuration errors, or unexpected behavior. This guide covers the most common problems and their solutions, based on community reports and troubleshooting.

Common Issues and Solutions

1. Getting Locked Out of Your Own Site

Problem: You find yourself permanently or temporarily locked out, even when using correct credentials. This can happen due to strict brute force protection settings or because your IP address was accidentally banned.

Why it happens: The plugin's Local Brute Force Protection module bans IP addresses after too many failed login attempts. If you are testing a login form or have a caching setup that shares an IP, your legitimate actions can trigger a lockout.

Solution: To regain access, you will need to manually remove the ban. If you can still access your WordPress admin, navigate to Security > Settings > Banned Users. Find your IP address in the ban-users[host_list] textarea, remove it, and save the changes. If you are completely locked out, you may need to use FTP or your web host's file manager to temporarily rename the /wp-content/plugins/solid-security folder to deactivate the plugin. After logging in, rename the folder back and reconfigure your settings.

2. HTTP 500 Error After Editing wp-config.php

Problem: Your site crashes with a 500 error after manually editing the wp-config.php file to change a setting added by Solid Security.

Why it happens: A syntax error, such as a missing semicolon or a typo in a constant name, will cause a fatal PHP error. The plugin adds specific code blocks to this file, and manual edits can easily break it.

Solution: The safest way to change these settings is through the plugin's interface, not by editing files directly. To fix the error, use FTP to access your wp-config.php file. Ensure the code block between the // BEGIN iThemes Security and // END iThemes Security comments is correct. A standard entry looks like this:

define( 'DISALLOW_FILE_EDIT', true );

If the file is corrupted, you may need to restore it from a backup or ask your hosting provider for help.

3. Error Logs Showing 'AH01630: client denied'

Problem: Your server error logs are filled with entries like AH01630: client denied by server configuration for wp-login.php or xmlrpc.php.

Why it happens: This is not an error; it is proof that Solid Security is working correctly. These entries indicate that the plugin's features to disable XML-RPC and protect the login page are actively blocking unauthorized access attempts.

Solution: No action is needed. These log entries confirm that your site is being protected. You can safely ignore them.

4. Validation Function Errors on the Security Page

Problem: You see PHP warnings on the Solid Security dashboard about validation functions for non-existent data entries (e.g., onboard_complete, enable_remote_help).

Why it happens: This is almost always caused by running a severely outdated version of the plugin. Older versions contain code for settings and features that have been removed or renamed in newer releases.

Solution: Update the plugin to the latest version immediately. This will synchronize your database with the current codebase and eliminate these warnings. Always keep your plugins updated for security and compatibility.

5. IP Address Not Being Added to Ban List

Problem: The plugin's logs show brute force attempts, but the IP addresses are not being automatically added to the Banned Users list.

Why it happens: The ban-users[agent_list] is for manually banning user agents and will always be empty by default. The ban-users[host_list] is populated automatically, but only if a lockout is successfully triggered. High traffic or specific server configurations can sometimes interfere with the process.

Solution: First, verify that all relevant modules are enabled and configured in Security > Settings > Advanced. Check the logs in Security > Logs for specific 'ban' events to confirm the feature is working. If IPs are still not being banned, you can manually add them to the ban-users[host_list] textarea.

6. 403 Forbidden Error with Banned Users List

Problem: After enabling the 'Default Ban List', your site's scripts or functions (like sending email) start returning 403 Forbidden errors.

Why it happens: The default ban list includes rules that block certain user agents and request patterns associated with bots and hackers. In rare cases, these broad rules can accidentally block legitimate processes on your own server.

Solution: If a critical function on your site breaks after enabling this feature, the simplest solution is to disable the 'Default Ban List' in Security > Settings > Banned Users. You can then build a custom ban list manually based on the malicious activity you see in your logs.

General Troubleshooting Tips

• Check for Plugin Conflicts: Deactivate all other plugins and see if the issue persists. If it resolves, reactivate them one by one to find the culprit.
• Review Server Error Logs: A '500 Internal Server Error' is often caused by a PHP fatal error. Your hosting provider can help you locate your PHP error log, which will specify the exact cause.
• Proxy and Caching Configuration: If your site uses Cloudflare or a similar proxy, ensure the Proxy Detection setting (Security > Settings > Global Settings) is correctly configured to 'Automatic' or the recommended value from your proxy provider. Misconfiguration here can cause the plugin to see all traffic as coming from your server's IP, leading to incorrect lockouts.

By following these steps, you can resolve most common issues encountered with the Solid Security plugin. For persistent bugs or unique problems, the WordPress support forums are a valuable resource for finding help from the wider community.