I have a WordPress website hosted on Amazon Ubuntu.
Amazon reported that my server is sending a WordPress login attempt requests to other servers on Amazon.
My website is just a landing page with a contact form. How do I prevent such incidents?
You can block external http requests check adding
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
in wp-config.php
Since you have already found a bad curl call in your source, I strongly suggest you check the integrity of your Wordpress installation.
If you have WP CLI available you can do this with the command wp core verify-checksums.
If you don't have WP CLI available you can use this excellent solution by Jan Reilink (either directly or as a starting point for your own code).
Either way you'll get output that tells you whether or not additional files have been modified (you could then restore them from the same WP version source). This will not be a catch-all-method in regards to malware, but I think it can be helpful in your specific situation.
Given that the code that's causing these requests is not part of the Wordpress core the answer to your question is some of the general best security practices for Wordpress:
Keep Wordpress and plugins updated
Use strong passwords for users
Add a captcha and brute force protection to your login page if possible
Related
I have a WordPress Multisite running on a relatively new Amazon Web Services (AWS) Lightsail instance, based on a Bitnami image (provided through AWS Lightsail) running a LAMP stack, based on Debian.
Until recently, plugins installed through the WordPress multisite Administrator Dashboard installed and ran good. Worked great before, no problems. Now, for some reason, attempting to install any WordPress plugin surfaces a dialog requiring FTP credentials be provided. There's a screenshot of the WordPress multisite dialog asking for FTP credentials at the end of this message.
I'm thinking this - new - demand to provide FTP credentials when adding a WordPress plugin is happening due to permissions. Naturally, I'd rather not need to install WordPress plugins using FTP.
So, I have two questions:
What settings were accidentally - somehow - changed to cause WordPress to now produce this new requirement asking for FTP credentials when installing any WordPress plugin?
How to I fix WordPress so that plugins can be installed without FTP?
I did see many solutions for fixing permissions on the Internet, except since I'm new to AWS, Linux (Debian) & WordPress I'd like to use this opportunity to learn how this situation happened, while learning how to fix the hiccup. Other than using a few new plugins, which installed & ran fine without FTP, I have not made any edits to any internal WordPress files.
The only chance to change permissions might - maybe - have happened when setting-up users within my AWS account, including setting-up of a Yubico key with key-pairs --> I don't think that security change would influence the LAMP stack running the WordPress multisite, but I wanted to offer information that might - maybe - related to security changes influencing why, now, adding WordPress plugins requests FTP credentials.
Thanks in advance, everybody. Thank you. :)
WordPress multisite dialog asking for FTP credentials
I tried to add many, many WordPress plugins to confirm that every WordPress plugin now asks for FTP credentials for any new plugin.
I have looked at many Internet posts explaining how to change WordPress & Linux permissions, along with posts explaining how to change WordPress configuration files to not ask for FTP when installing new plugins. I have not acted on these many suggestions since I'm cautious & careful --> I'm ready to study months & months becoming a Linux, WordPress, and supporting technologies expert, but at this stage since I'm new to all-of-the-above, I'm reluctant to make any changes until I fully understand the technologies (after making this post, I will make copies of WordPress configuration-files to test changes that can be undone, but I wanted to see whether StackOverflow might help me learn what happened in the first place, while learning how to correctly fix these issues.
I pay for AWS Premium Support --> I've sent a message to AWS Premium Support, but so far have not heard back from AWS.
We use the XML-RPC Wordpress API in some applications. On this particular blog we get this error in the image below. We've tried removing plugins, re-installing the blog, and contacting the hosting, but we can't figure-out what's wrong and how it is disabling the access.
I am not familiar with Wordpress and the plugins architecture so I do not know if this is in the code or in the database (credentials in image are fake).
As my point of view, this problem can be for 3 reasons:
1) Your server hasn't xmlrpc extensions installed or enabled.
2) Wordpress blocks every xmlrpc calls (check security plugins if you have any installed and .htaccess)
3) Your server deny your xmlrpc calls because it believes that you are doing an attack (tipycally DOS attacks). Check that your server hasn't blocked your ip.
So I created a new subdomain on Dreamhost. One-click installed Wordpress. Fresh Copied the olddomain.com to newdomain.com exported all the tables with the drop attribute to the new wordpress database via phpmyadmin. Then followed this post to update the urls.
The site doesn't load, giving me this error message:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.
I would make sure to check the 'www' rules in Fully Hosted (from the web panel: Manage Domains > Web Hosting > Edit), compared with your site URL settings in the WordPress dashboard. Make sure those aren't conflicting first.
If you need further assistance, just let me know the domain name and I can take a look. Please also feel free to start a LiveChat from the panel or submit a ticket; our support team is here to help 24/7!
Thanks!
Ellice S
DreamHost Staff
I finally ended up creating an empty site and then using the WP Duplicator plugin. Worked like a charm!
The WP back end of a site I'm working on (It's a multisite) takes about 25 seconds to load.
Everything was working fine until yesterday and the front end still works perfectly well. All other sites on the same server run just as well, so it MUST be a WP back end issue.
I don't remember exactly what change it was that made it so slow. I remember updating WP recently (to version 3.4.2), adding some plugins on one of the sites and changing the max upload file size.
I tried to disable all the plugins, changing the themes back to default, changing the max file size back, and adding define('WP_MEMORY_LIMIT', '1024M'); (and other values) to WP-config but none of it helped.
Also tried to 'Update network', but I got an error - couldn't connect to host.
Any ideas?
I got in touch with our network admin and we resolved the issue.
I will copy his answer here. Hope it helps someone.
Does Wordpress use 'self-referential URLs' ? What I mean by this is...
is wordpress trying to access it's own templates/css using fully
qualified domain names in the URL (e.g. http://example.co.uk/someurl )
Because we use Network Address Translation (NAT) on our firewalls to
hide the real IP address of the server, it has the side effect that if
the server tries to access it's own URLs, it will try to send the
traffic to the external interface on our firewall, which is where the
DNS resolves to.
The fix for this is very simple - we just add the site url into the
/etc/hosts file so that the server knows to use it's own IP address
instead of the address on the firewall.
So he added our address to the hosts file and now it works perfectly.
Awesome.
I've seen this before where the admin pages are trying to poll external Wordpress sites for details of Wordpress upgrades, plugin updates and Wordpress news. If there's no proper access (because of firewall restrictions, bad DNS, etc) then the page has to wait for the HTTP requests (I think WP uses cURL) to timeout.
If you're still unable to identify the cause I'd recommend a catch-all solution of installing xdebug and profiling the page with webgrind, xcachegrind, etc
Had the same problem for a week and now the problem of very slow WP-admin was solved!
Before, I cannot access my sites if I use incognito or I am not logged in as WP user, but all times in the wp-admin, it takes me 40 seconds- minute or even never.
Solution that worked:
I accessed the files in the file manager using the CPanel, and I saw so many unused and unnecessary folders and themes and that's the reason that causes the very slow access to admin.
It was because during the days of being a newbie, I stuffed a lot of files in the Public Http and that made it congested.
I logged in to another CPanel account that I bought personally before, and compared the folders of the "proper" versus the "congested" and compress, backed-up and deleted all the unnecessary.
My host: Hostgator, responded well also.
Hope this would help others.
I also had a very slow Dashboad in wordpress. Reading the James C´s answer, I realized that my site is located in a corporate intranet behind a firewall to access internet.
James C answered:
"I've seen this before where the admin pages are trying to poll external Wordpress sites for details of Wordpress upgrades, plugin updates and Wordpress news. If there's no proper access (because of firewall restrictions, bad DNS, etc) then the page has to wait for the HTTP requests (I think WP uses cURL) to timeout."
My solution was avoid all the internet conections: (1) disable all the wordpress updates using the wordpress plugin "Disable all wordpress updates". (2) activate de wordpress pluging "Disable google fonts"
After these two plugin activations, the Dashboard works to a suitable speed.
How do you make a Wordpress Theme part of the auto update check. I know you can plug in to the plugin auto updater, to add/remove plugins from the auto updater, but how do you do this with themes?
I tried digging through the Twenty Ten theme, but there is no code anywhere which defines how it auto updates, or registers it for auto update. Yet, it auto updates with Wordpress.
Any help would be greatly appreciated.
EDIT: Should have specified, my theme is not in the Wordpress repository. It will be distributed separately.
Hook into pre_set_site_transient_update_themes
Because your theme does not reside on the Wordpress repository, an easy methodology is to incorporate file access in your theme. A quick way to do this:
Incorporate version control within a master file in your theme. Create a "version.php" file that has a PHP variable like version = 1.1
Create a directory where your theme files will be hosted on your own site. Create a "version.txt" file in that directory that only contains the latest version number (i.e.: 1.2) and no other text or numbers. The URL might look like domain.com/repository/version.txt.
Design your theme to open the contents of domain.com/repository/version.txt and use PHP to compare the numbers of each. If there is a newer version, then download the latest version of the theme as a ZIP.
$version = floatval(file_get_contents('domain.com/repository/version.txt'));
// note use only 1 decimal to keep it simple and prevent floatval() from failing
if($version > $localversion) {
copy("domain.com/repository/version".$version.".zip","theme/tmp/version_temp.zip");
$zip = new ZipArchive;
$res = $zip->open("theme/tmp/version_temp.zip");
if ($res === TRUE) {
$zip->extractTo("theme");
$zip->close();
echo 'ok';
} else {
echo 'failed';
}
}
You'll need to take that code, refine it, and account for file permissions and what works best for performance.
The update API is split in three: core, plugins and themes. All are hosted on wp.org, and the mere existence of your plugin/theme in the WP repository makes it auto-updated without a line of code beyond the standard plugin/theme headers and readme.txt files.
wordpress.org has an API listening for plugin/theme update requests. The client is the local WordPress installation that sends those requests to WordPress.org, and waits for a reply. The local WordPress installation uses wordpress.org as a default, but the remote API can be any custom URL, such as example.com.
If your local WordPress installation is on example.com it will need a custom plugin that is built to act as an API that listens for update requests using HTTP(s) from your plugin/theme installed elsewhere, or even on the same server.
For a plugin/theme to send the API request to a server, such as example.com, rather than wordpress.org, you would need to build client software, such as a client class, to send the API request to example.com, and when the client receives the HTTP(s) response it would hook into one of two filters:
pre_set_site_transient_update_plugins
pre_set_site_transient_update_themes
One filter hook is for plugins and one filter hook is for themes. Those are not the only hooks available in WordPress.
To summarize, a client library needs to be built for the plugin for theme to send HTTP(s) requests to an API located on a server, such as at example.com. A plugin must also be built and installed on the server, such as on example.com, for an API to listen for client HTTP(s) requests.
What is done with those HTTP(s) requests on the client and server can be customized however you'd like, but it takes time to develop a solution. There are free and commercial solutions available that may meet your immediate needs, or you can use one of those solutions as a start to create your own custom solution.
Here is the request and response flow:
client ->(HTTP(s)) request)-> server(API)
server(API) ->(HTTP(s)) response)-> client
Here are two solutions as an example:
(Free) wp-update-server from YahnisElsts
(Commercial) WooCommerce API Manager
There are other solutions and tutorials out there currently that a Google search can help locate.
Keep in mind, any solution you develop should have security at the forefront, so as not to expose your server to a hack, especially since you are exposing an API on your server. This is one reason I included a commercial solution as one of many solutions available.