Link P
Forum Replies Created
-
Can confirm this recent update (version 5.2.7) prevents login when Duo Authenticator plugin is in use. Since I use Duo Authenticator and AIOS on all of my sites, this is not good. Can we roll AIOS back to the previous version, or will an emergency update fix this critical issue promptly?
I don’t think you have been infected or breached. One of my sites started having problems after today’s AIOS plugin update. I deactivated it by renaming the folder and was able to log in. Oddly enough reactivating the plugin did not take the site offline again.
I am seeing error log entries triggered by AIOS when UptimeRobot connects. The log entries refer to a missing column in the database.
[Thu Feb 08 02:43:18.455830 2024] [proxy_fcgi:error] [pid 2381630:tid 139642920879808] [remote 216.144.248.23:0] AH01071: Got error 'PHP message: WordPress database error Unknown column 'released' in 'where clause' for query SELECT * FROMwp_aiowps_login_lockdownWHERE released > UNIX_TIMESTAMP() AND failed_login_ip = '216.144.248.23' AND lock_reason = '404' made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('/srv/www/example.com/www/wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, AIO_WP_Security->wp_security_plugin_init, AIOWPSecurity_General_Init_Tasks->__construct, AIOWPSecurity_General_Init_Tasks->do_404_lockout_tasks, AIOWPSecurity_Utility::check_locked_ip', referer: https://example.com/Forum: Plugins
In reply to: [Add From Server] Add from remote serverThis plugin allows you to add files from the local server, not a remote server.
The page you linked to explicitly warns *NOT* to leave wp-config.php permissions set to 644, yet the AIOWPS plugin suggests changing to that vulnerable state.
644 makes the file world readable which will potentially expose the database credentials to any user on the host.
Depending on the group assigned to the file 640 or 600 offer adequate protection.
Would it be possible to update AIOWPS so that it does not encourage the user to expose database credentials?
Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] Plugin Redirecting to 404 Recently?This happened recently on one of my customer’s sites. In that instance, it appears to have been caused by Hostgator eliminating the use of the shared SSL certificate on their Linux hosting.
It feels like a kludge that’s probably asking to break things in the future (like whenever Debian rolls out a security update to the wordpress package). For now, editing
/usr/share/wordpress/wp-includes/class-http.phpto use'sslcertificates' => '/usr/share/wordpress/wp-includes/certificates/ca-bundle.crt',has fixed the problem from within WordPress.Minor update – no resolution yet.
Further analysis shows that the working server is using the /etc/ssl/certs directory as its CA Path. The broken server is using the same path when it fails.
MD5 sums of /etc/ssl/certs/ca-certificates.crt differ on the machines, but that seems appropriate since that file would include different local certificates in addition to the common Root CA certs.
I’m not willing to disable certificate verification as it breaks SSL. I’m still working through this. I will post a follow-up when I have a resolution. Some installation data and my results so far are include below for review.
I have two Debian Jessie servers running WordPress instances.
Both have the following package versions:
apache2:amd64/jessie 2.4.10-10+deb8u3 uptodate
curl:amd64/jessie 7.38.0-4+deb8u2 uptodate
mysql-server:all/jessie 5.5.46-0+deb8u1 uptodate
openssl:amd64/jessie 1.0.1k-3+deb8u2 uptodate
php5:all/jessie 5.6.14+dfsg-0+deb8u1 uptodateThe server that runs WordPress from stand alone instances in user directories is having no difficulty with MailChimp for WordPress.
The server that is running the Debian WordPress package (4.1+dfsg-1+deb8u7) is failing to validate the SSL certificates.
The results are consistent whether using the
curl -v https://us1.api.mailchimp.com/3.0/?apikey=testor directly from the WP plugin.The MD5 sum of the ca-bundle.crt file on both servers is 978976c7bbfab9219a6f0a8a66a4da6f (in the users WP install directory on the host that works, and /usr/share/wordpress/wp-includes/certificates/ on the deb install)
Neither machine has curl.cainfo set in any php.ini file.
I just reran the curl test (from the CLI) and specified the /usr/share/wordpress/wp-includes/certificates/ca-bundle.crt with the –cacert option and it worked. For whatever reason, it appears (for me at least) that the problem is being caused by curl not using the ca-bundle.
Your WordPress blog still needs to be configured for HTTPS on your web server. That involves an SSL certificate and server configuration. Whether or not you need to buy one or if you can make your own certificate would depend on what you want to accomplish with HTTPS. This plugin does not deal with that part of using SSL. It just configures what parts of your blog will use HTTPS.
If you are just looking to secure the admin area for your own use, a self-signed certificate would suffice. If you want your visitors to use HTTPS to login or view the blog, a self-signed certificate will present them with a warning which might cause them concern. To remedy that warning you can use a certificate from a recognized provider. You might want to ask your web host for details.
Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] metaboxes don't load when wp-content dir is movedI experiencing the same thing and identified the same line as the source of the problem. I don’t have more to add than a “me too” comment, but I don’t see a way to get notified of follow up posts without leaving a comment.