#35532 closed enhancement (wontfix)
Additional Security for XML-RPC to Prevent High Server Load - Specifically Pingbacks
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | minor | Version: | 4.4.1 |
| Component: | Pings/Trackbacks | Keywords: | |
| Focuses: | Cc: |
Description
XML-RPC requests need additional security to prevent high system resource usage on web hosting servers.
Under Discussion settings, there are two settings:
Attempt to notify any blogs linked to from the article
Allow link notifications from other blogs (pingbacks and trackbacks) on new articles
Even with both of these settings disabled OR enabled, XML-RPC pingback POST requests received in small increments (say 4 requests per second) can overwork the server resulting in a Linux server load increasing from under 0.50 to anywhere between 5-15 from a single abuser targeting a single installation of WordPress. The processing required for handling these requests needs to be more efficient.
Recently, several installations of WordPress on my shared web hosting server have been under attack with bogus pingback requests sent repeatedly many times per second. For some reason, the logic handling these requests is causing too much processing to happen on the server resulting in the server load heavily increasing until the exploiter's IP address is banned (via iptables) or the Disable XML-RPC Pingbacks plugin is installed (https://wordpress.org/plugins/disable-xml-rpc-pingback/). Asking all of my shared hosted users to install this plugin isn't a solution to this problem. It's merely a work-around.
Here is an idea to keep the web server from working too hard to process these requests:
Write a file when a pingback request is received with the name of {IP_ADDRESS}.txt which contains a timestamp. {IP_ADDRESS} being the IP address from the client sending the request (PHP can grab this easily). When a pingback request is received, we check to see if the file exists, and if it does, we check to see if the current timestamp is greater than the old timestamp + 60 seconds. If it's not, we do NOT process this request at all because not enough time has passed. If it is, we process the pingback and write the new timestamp to the file. If the file doesn't exist, we create the file with the current timestamp and process the request. Then, WordPress could run a "cron" like function like it does for updating WordPress to delete these files to cleanup every once in a while. This will limit a source to one pingback request per minute, which seems more than fair. File system operations are very fast and so are timestamp operations, so I could see this working. This would also prevent a single attacker or multiple attackers from having a noticeable impact on the server. This solution could also be implemented database side assuming this isn't the reason for the high server load in the first place (initialization of the database).
Please see these two topics for additional details (including packet captures) of how this problem is affecting a lot of installations:
I think this is an important issue that needs to be addressed.
Denial of Service attacks are a problem for every software that accepts and actions requests.
While I certainly think that the pingback and xml-rpc system in general could always use improvement, limiting xml-rpc requests to one per minute has the potential to reject legitimate traffic.
We'd probably be better off queuing the requests to distribute load, but pingback does not cover this and that leads to a whole other discussion outside of the scope of the ticket.
Rate limiting, if that is what one chooses to do, is best done at the server, not the WordPress level. The two settings noted in configuration are not meant to disable incoming pingbacks. One disables outgoing pings, the other covers new posts, not existing posts.
As the recommendation impacts the experience and alternatives, including rate limiting at the WordPress level, could be added by plugin, I don't believe that the suggestion can be considered as it is not uncommon that a DOS Attack would come from a variety of different servers and thus the solution would not be workable.
As I concur with the goal of reducing load, hope you will consider alternative suggestions in this area that would improve performance without compromising effectiveness.