WordPress Xmlrpc 403 Error

AIOWPS Troubleshooting/Recovery Tips

Scenario: You are blocked or locked out and can’t get back in

Do the following steps if you for some reason cannot get log back into your WordPress site due to the AIOWPS plugin:

1) use CPANEL file manager (or FTP) and temporarily rename this plugin’s folder.

all-in-one-wp-security-and-firewall

tmp-all-in-one-wp-security-and-firewall

2) Get your currently active .htaccess file and remove all code which is between and including the following tags:

# BEGIN All In One WP Security

# END All In One WP Security

3) Log into your site using the standard login link – ie, wp-login.php

4) Using your cpanel or FTP rename the folder back to all-in-one-wp-security-and-firewall.

5) Once logged in you can disable or re-configure the feature(s) which were giving you problems

Scenario: You are receiving loads of lockout emails even though you have hidden your login page

If you find that even though you’ve hidden your login page you are surprised to see that you are still getting a bunch of continuous lockout event emails don’t panic! The chances are that the bad guys have NOT discovered your hidden login page.

What is most likely happening is that the bad guys, or more specifically automated scripts they have written, are continuously targeting your xmlrpc.php file which is part of the standard core WordPress installation.

XMLRPC is used by some plugins and apps such as JetPack and the WordPress app.

If you’re certain that your site does not need XMLRPC and is hosted on an Apache server, then you can block access to the xmlrpc.php file by enabling the following AIOWPS feature:

From your WordPress admin panel, go to:

WP Security >> Firewall >> Basic Firewall Rules

In the section called “WordPress XMLRPC & Pingback Vulnerability Protection” check the box called “Completely Block Access To XMLRPC“.

The above works only for Apache-type servers. If you have an nginx server there are manual rules you can insert into the nginx.conf file to do the equivalent of what I described above (just do a Google search).

Alternative method:
(This is independent of type of webserver)
If you purely want to use PHP code to block XMLRPC requests then copy and paste the following code into your theme’s functions.php file:

Scenario: The File change detection feature continuously gives a mysql warning when trying to perform a scan.

If you are getting the following warning when trying to a file change detection scan:
PHP Warning: mysqli_query(): MySQL server has gone away in . wp-includes\wp-db.php on line xxxx

This may be caused when you have a large site with many files in your system. One thing you can try which may fix the issue is to increase the following configuration item which can be found in the my.ini file:

max_allowed_packet

(Note: the default may be set to 1M. Try increasing this to something larger such 10M or 20M)

Scenario: You are seeing a 403 forbidden error when auto-logged out in some cases.

When you have been auto-logged logged out you see the following error:

The above will usually be caused by one of the firewall rules because one of strings in the URL is firing the rule.

You have an xampp localhost test site and also have the “Deny Bad Query Strings” firewall rule active. Your login time has expired and the redirect URL looks like the following:

http://localhost/test-site/wp-login.php?redirect_to=http%3A%2F%2Flocalhost%2Ftest-site%2Fwp-admin%2Fadmin.php%3Fpage%3Daiowpsec_spam&reauth=1

This is a false-positive and is being caused by the fact that the URL contains a query parameter which has a string that one of the firewall rules is detecting as forbidden.

(NOTE: the query parameters consist of all of the parts after the “?” character)

In this case the “Deny Bad Query Strings” is detecting the string “localhost“.

This is simply a false positive and you can ignore the 403 message.

Solution : To get back into your site simply remove the query parameters from the URL, ie, all of the portion starting from the following to the end of the url string:

So from the example above you would just enter the following in your browser to log back in:

(NOTE: If you have renamed your login page you would enter your login URL with the secret login slug)

Scenario: The plugin is showing the server or internal IP addresses instead of the visitor addresses.

If your host provider has a setup whereby your web server is behind some kind of load balancer or perhaps you are using CloudFlare then you might see that this plugin is showing incorrect visitor IP addresses such as internal addresses, server address or CloudFlare addresses etc

This is because the plugin uses the $_SERVER[‘REMOTE_ADDR’] by default to identify the real visitor IP address but your hosting setup may have different behaviour.

Solution : Try adjusting the following setting:

For example if you are using CloudFlare you should choose “HTTP_CF_CONNECTNG_IP”.
In other cases “HTTP_X_FORWARDED_FOR” usually contains the correct visitor IP address.
Try each of the settings to see which works for your setup.
If after trying all of the above settings you are still finding that you are not seeing the real IP address then please contact your host provider and ask them where in the $_SERVER global variable do they set the real visitor IP address.

WordPress xmlrpc 403 error

Block WordPress brute force attacks via xmlrpc.php

Detecting xmlrpc.php hacking attempts

Over the past weeks, I spent a lot of time identifying and blocking “over-active” crawlers and bots to reduce unnecessary load on my web servers. I still saw a lot of activity on one of my WordPress blogs… Too much to be explained by “normal traffic…”

While checking the web server accesslog for that blog, I saw many “clients” accessed “xmlrpc.php”. Apparently, since mid last year, there was an increased occurrence of brute force attacks using this script.

With this linux command I checked the amount of times xmlrpc.php occurs in my log file:

I found 800 xmlrpc.php access instances, per hour. (!!)

“xmlrpc.php” is a php script that supports a standard WP function to remotely publish posts via email (and get pingbacks). I don’t update my blog via email, so time to block this functionality!

How to block “xmlrpc.php” hacking attempts?

You can easily disable the access to “xmlrpc.php”, via the .htaccess file, similarly as I explained earlier for the wp-login.php file

Not only will it make your blog more secure but it will, once again, offload your server.

16 Comments to “Block WordPress brute force attacks via xmlrpc.php”

Peter, thanks. I think your WordPress security tip is quite reasonable especially regarding server load.
Once I cut off Amazon servers-based spiders and it saved me 40% (!) of bandwidth volume. Frankly, I was surprised with such huge savings.
By the way, do you use any kind of firewall to cut off brute-force attacks?

At the server level, I have an IP firewall, which blacklists IP addresses which unsuccessfully try to log in at Linux level.
On WordPress, I use the Limit Login Attempts plugin, which blacklists IP addresses trying to log in unsuccessfully at WordPress level.
On Drupal, I have no specific firewall.

Hope this helps,

Using the Limit Login Attempts plugins together with a strong password on WordPress does the trick in most cases I think when dealing with brute common brute force attacks. However during a hard time (attacking from thousands of IPs simultaneously) this is not enough as server starts suffering from a high load. I have not experienced such a tough attack yet (luckily) but if it comes, I think it will make sense to use kind of CDN/Website Firewall service that blocks brute force attacks even before your server starts getting the malicious hits.

By the way, there is a plugin for Drupal (https://www.drupal.org/project/login_security) that limits logins as well.

Oh cool. Tnx for the tip on the Drupal module! — Peter

I’m really upset at people who do this stuff to take short cuts in life by ruining other peoples hard work… It’s really sad, I hope these terrorists of the Internet get what they deserve one day. I’m having a hard time fixing these attacks and it’s just stresstful but thanks for sharing this, helped a little.

In case you are not aware (sorry if you already know this), but XMLPRC is used for posting content remotely. The xmlrpc.php file is what WordPress uses to allow you to post remotely.

As you know, one of the things we all love about WordPress is how easy it is to create new websites and to manage the content. These are the very same reasons why hackers also love WordPress.

If you are not posting comments to your website remotely, one of the quickest way to get yourself out of this situation is to rename the xmlrpc.php file to some fictitious name. Make sure you change the file type to anything other than “.php.” This way, you will remove the possibility that the server may accidentally run the code.

If you are doing posts remotely, here’s some code you can add to your .htaccess file:

order deny,allow
deny from all
allow from 123.456.789.123 allow

WordPress has a bunch of security holes and we have been victimized many times. I a solution that so far has helped me secure our sites more than anything else we have tried.

Hopefully, WordPress will not open up new holes with the next WP update.

Not a good idea because with this code, the 404 wp error page will be call and the database connection to. I think, the best is to redirect to another IP like :
RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]

Well, recently Brute force Attacks has immensely increased, becoming a dangerous factor for all WordPress users, but it is a thing, which is fight-able, I mean, by using security methods, we can move brute force attacks out of the window. Although, it can be difficult for newbies, who just got started with WordPress, but he/she can learn by reading posts online and then can implement security.
In my view, implementing only three tricks works very well, Changing Login Slug, A content Delivery network (CDN) and a Security Plugin, which bans IP address after a few Login attempts.

I got an idea, stop using crappy a$$ wordpress!

Hi, try ithemes security plugin. It does IP blacklisting at WordPress level and more.

I have suffered with xmlrpc.php last two days. Google search engine and web browser was showing warning, now I am safe to edit .htaccess. Tjanks

I had the same thing. lately. I stopped it aswell with .htaccess edit.
But there was something REALLY curious, the location chart exploded, and the location-pins had a devilish upside-down cross pattern: http://omwegen.naardehemel.nl/2016/04/07/hackersaanvallen-geblokkeerd/
(It is in Dutch, you could use Google translate.)
See posts above on my blog to see other comments and graphs.
(If you don’t see the pattern, I have a post with a picture with two lines added: http://omwegen.naardehemel.nl/2016/04/08/omgekeerd-kruis-waar-dan/ )
This is the other post with a graph about this: http://omwegen.naardehemel.nl/2016/04/08/hackersaanvallen-voorbij/
I found it REALLY exciting!

I’d suggest better protection with .htaccess file, which has different blocking rules against attacks on a WordPress:

# Block the include-only files.

RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ – [F,L]
RewriteRule !^wp-includes/ – [S=3]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php – [F,L]
RewriteRule ^wp-includes/theme-compat/ – [F,L]

SecFilterEngine Off
SecFilterScanPOST Off

# Disable directory browsing
Options All -Indexes

Order Deny,Allow
Deny from all

Require all denied

# Deny access to all .htaccess files

Require all denied

Hope this helps somebody.
Cheers

thank you for the valuable information.appreciate your work

WordPress has a bunch of security holes and we have been victimized many times

Can make 403 denied error, and client don’t make problem this way.

Tag: 403 Error

Setting up Windows Live Writer–rename xmlrpc.php

Well, this evening has been my second attempt at setting up some offline blog publishing software for use with my WordPress sites. I’d tried both Blog-Desk and Windows Live Writer before given the quality of reviews both have been getting, but do you think I could get either of them configured? Hell No!

Let’s start with Blog-Desk. Everything is fine with the setup right up until it asks you for the Blog-ID. It wouldn’t accept a sausage instead returning me a nice 403 Error for my trouble. So I gave up on it.

So I thought I’d try Windows Live Writer. Like Blog-Desk, it installed fine with no errors. Go to setup my blog using the wizard and all is fine and dandy until it asks for the exact path to xmlrpc.php. And everytime it would return that it couldn’t find the URI (Universal Resource Identifier).

Nothing worked until I happened upon this forum post here Thanks to fullphaser, I changed the name of xmlrpc.php file to blogdesk.php, and as he said “it now works”.

And the weird thing is, it works in both Blog-Desk AND Windows Live Writer.

Don’t forget to back up your xmlrpc.php file before you try this (as always)

Setting up Windows Live Writer for WordPress Procedure:

1. Rename your xmlrpc.php file to blogdesk.php

2. In Windows Live Writer, from the File tab select Options

3. Select Accounts from the next window that opens then select the Add button

4. Select Other services, when asked “What blog service do you use?

5. The next window will ask you to Add a blog account. Insert the web address to the site where you WordPress install resides, followed by the Username (don’t use admin) that you use to post on your WordPress blog and the password.

6. Next you’ll be asked to Select a blog type. Most WordPress sites these days will select WordPress 2.2+ as the type of blog. Then in the Remote posting web address box place the full web address to where your blogdesk.php file resides. Don’t insert myblog.com/public_html/blogdesk.php if that’s where your file resides. You’d instead use myblog.com/blogdesk.php.

Windows Live Writer will configure itself from here on in.

How this worked for me given that the very first step asks me to do something contrary to the type of blogging site I have; I’ve no idea. But for some insane reason it’s worked for me and it’s also worked for someone else as well.

How to protect wordpress from XML-RPC attack

Introduction

What is XML-RPC ?

According to Wikipedia XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.XML-RPC also refers generically to the use of XML for remote procedure call, independently of the specific protocol. In short, it has three main features in WordPress:
* Connecting to your site(s) with your smartphone
* Trackbacks and pingbacks when other sites refer to your site
* Jetpack( using it)

The security problem of XML-RPC with your site ?

  • Brute force attacks: Attackers try to login to WordPress using xmlrpc.php with as many username/password combinations as they can enter. A method within xmlrpc.php allows the attacker to use a single command (system.multicall) to guess hundreds of passwords. Daniel Cid at Sucuri described it well in October 2015: “With only 3 or 4 HTTP requests, the attackers could try thousands of passwords, bypassing security tools that are designed to look and block brute force attempts.”
  • Denial of Service Attacks via Pingback:Back in 2013, attackers sent Pingback requests through xmlrpc.php of approximately 2500 WordPress sites to “herd (these sites) into a voluntary botnet”. For more you can read previsous post of Cloudi xml-rpc-ddos . In short, attackers can do hundreds of login attempts within a single HTTP request.Imagine seeing it in your access log !

How to recoginze XML-RPC DDoS Attack ?

Finding many entries similar to "POST /xmlrpc.php HTTP/1.0” in your web server logs.
The location of your web server log files depends on what Linux distribution you are running and what web server you are running or your configuration:
For Nginx on Redhat/Ubunutu open server log file on directory and using command :

For Apache on Redhat/Ubunutu open server log file on directory and using command :

Your WordPress site is receiving XML-RPC DoDos attack if the commands above result in many lines of output, similar to this example:

How to prevent XML-RPC Attack ?

The best thing you can do !

The best thing you can do to protect yourseft is to turn off XML-RPC in your Settings altogether.

For Apache on Redhat/Ubunutu open file apache configuration vim /etc/apache2/apache2.conf and add the line below:

For Nginx on Redhat/Ubunutu open file nginx configuration vim /etc/nginx/nginx.conf and add the line below:

Why WordPress still using xmlrpc.php

An author has a security plugin wrote:
“To us, disabling XML-RPC comes with a cost. You are disabling a major API in WordPress. We briefly provided this capability, but removed the feature because WordPress’s own API abuse prevention has improved. Furthermore, providing the ability to disable XML-RPC caused confusion among users when their applications broke because they could not access the API.”
If you have become dependent on these tools dependent XML-RPC. And you don’t want to turn XML-RPC off.
Here are some plugins that can help:
* Strop XML-RPC Attack
* Jetpack: “he Jetpack plugin for WordPress can block the XML-RPC multicall method requests with its Protect function”

It’s time to say goodbye with XML-RPC

From Wordpres version 4.7 released , WordPress core developers are turning WordPress’s code into a REST application. you won’t have to use XML-RPC to use the mobile apps or Jetpack.
Instead, you’ll authenticate yourself in external apps through the OAuth protocol. You may not know what OAuth is, but if you’ve ever clicked a Twitter button on a post, you’ve used OAuth.

Leave a Reply

Your email address will not be published. Required fields are marked *