XML-RPC technology is used in WordPress system for different pleasant chips by type of pingbacks, trackbakes, remote management of the site without entering the administration, etc. Unfortunately, attackers can use it for DDOS attack on sites. That is, you create beautiful interesting WP projects for yourself or to order and at the same time, without knowing anything, you can be part of the botnet for DDOS`a. Connecting tens and hundreds of thousands of sites, bad people create a powerful attack on their sacrifice. Although your site also suffers, because The load goes to hosting where it is placed.
Evidence of such bad activity can be server logs (access.log in NGINX), containing the following lines:
103.238.80.27 - "POST /WP-LOGIN.php HTTP / 1.0" 200 5791 "-" "-"
But back to the XML-RPC vulnerability. Visually, it manifests itself in slow opening of sites on your server or the impossibility of downloading them in general (502 Bad Gateway error). In the technical support of my Hoster FastVPS confirmed guesses and advised:
- Refresh Wordpress to the latest version along with plugins. In general, if you follow, you could read about the need to install the last 4.2.3. Due to critical safety comments (just as previous versions). In short, it is useful to be updated.
- Install the Disable XML-RPC Pingback plugin.
Disconnection XML-RPC in WordPress
Previously, it seems to me that the XML-RPC on / off option was somewhere in the system settings, but now I can not find it there. Therefore, the easiest way to get rid of it is to use the corresponding plugin.
Find and download Disable XML-RPC PingBack or installing it directly from the admin administrator. You do not need to adjust anything additionally, the module immediately starts working. It removes the Pingback.ping methods and pingback.Extensions.GetpingBacks from the XML RPC interface. Also, removes the X-Pingback from HTTP headlines.
In one of the blogs, I also found a couple of options for deleting a shutdown XML-RPC.
1. Disconnect XML-RPC in the template.
To do this, a string is added to the FunctionS.php theme file file:
The last two methods personally did not use it, because Connected Disable XML-RPC PingBack plugin - I think it will be enough. Just for those who do not like extra installations, offered alternative options.
A few days ago I noticed that the load of my sites on the hosting grew at times. If usually it was in the region of 100-120 "Parrots" (CP), then over the past few days it has increased to 400-500 CP. There is nothing good in this, because the hoster can translate to a more expensive tariff, and even cover access to sites at all, so I began to understand.
But I chose a method that allows you to save the XML-RPC functionality: installation of the DISABLE XML-RPC Pingback plugin. It deletes only the "dangerous" methods pingback.ping and pingback.extensions.getpingbacks, leaving the XML-RPC functionality. After installing the plugin you only need to activate - no further configuration is required.
Along the way, I scored all IP attackers to file.htaccess my sites to block them access. Just finished at the end of the file:
Order All Deny From 5.196.5.116 37.59.120.214 92.222.35.159
That's all, now we securely protected the blog from further attacks using xmlrpc.php. Our sites stopped shipping by requests, as well as attack with DDOS third-party sites.
From noon, Saturdays on my server, where about 25 sites on Wordpress will be hosted, wild brakes began. Since I managed to survive the previous attacks (Attack 1 - Exactly a year ago, Attack 2 - in March) not noticed, I did not immediately understand what was the matter.
When I figured out, it turned out that passwords were passing + many requests to XMLRPC.
As a result, it was possible to cut off this, although not immediately. Cat three simple techniques, how to avoid it.
These techniques are most likely known to everyone, but I have come for a couple of rake, which I did not find in the descriptions - suddenly it will save time to someone.
1. Start the bust, Limit Login Attempts plugin - put it, since other protection strongly hang the server, for example, when using the Login Security Solution plugin, the server has died after half an hour, the plugin is very loading the database.
In the setting, be sure to turn on the test "for proxy" - otherwise it will define the IP of your server for all and automatically block all.
Update, thanks to DarkByte, the details below in the comments - the checkbox "for proxy" only if the definition does not work when the "Direct Connection" is enabled
2. Disconnect the XML RPC - Disable XML-RPC plugin (simply activate it and everything).
3. Close WP-Login.php - if you contact the site through the IP, the plugin does not work and the pickles continue to dab site. To avoid this, V.HTaccess add:
The WP-Login file is copied, renamed any strange name, for example Poletnormalny.php and inside the file with the auto-transmission all the inscriptions WP-Login.php on Poletnormalny.php.
All, now you can only contact the admin in your file.
After these 3 simple steps, sites began to fly again and came calm.
Well, suddenly interesting
One option to see what you are attacked. This can be seen in the NGINX logs (for example, here is the path for Debian / Var / Log / Nginx file Access.log).Using XML-RPC in PHP to publish materials in LiveJournal.com (LJ)
To begin with, you will need to download the XML-RPC library. The most successful version it seems to me freely distributed via SourceForge ": All examples below will be given for this library version 2.2.
What is XML-RPC? RPC is decrypted as Remote Procedure Call, respectively, in Russian, this can be translated as a remote procedure call using XML. The method of remote call procedure itself is known for a long time and is used in technologies such as DCOM, SOAP, CORBA. RPC is designed to build distributed client-server applications. This makes it possible to build applications that work in heterogeneous networks, for example, on computers of various systems, to make remote data processing and remote applications. In particular, this protocol enjoys a well-known site LiveJournal.com.
Consider an example of how you can place a Cyrillic recording (namely, problems often arise) in LJ. Below is a working code with comments:
New xmlrpcval ($ name, "string)," password "\u003d\u003e new xmlrpcval ($ password," string), "event" \u003d\u003e new xmlrpcval ($ text, "string)," subject "\u003d\u003e new xmlrpcval ($ subj, "String"), "LineEndings" \u003d\u003e new xmlrpcval ("unix", "string"), "year" \u003d\u003e new xmlrpcval ($ year, "int"), "mon" \u003d\u003e new xmlrpcval ( $ MON, "INT"), "day" \u003d\u003e new xmlrpcval ($ day, "int"), "hour" \u003d\u003e new xmlrpcval ($ hour, "int"), "min" \u003d\u003e new xmlrpcval ($ min , "int"), "ver" \u003d\u003e new xmlrpcval (2, "int")); / * based on the array create a structure * / $ Post2 \u003d Array (New XMLRPCVAL ($ Post, "Struct")); / * Create an XML server message * / $ F \u003d new xmlrpcmsg ("lj.xmlrpc.postevent", $ post2); / * Describe the server * / $ c \u003d new xmlrpc_client ("/ interface / xmlrpc", "www.livejournal.com", 80); $ C-\u003e REQUEST_CHARSET_ENCODING \u003d "UTF-8"; / * Optionally, we look at the XML code of what will go to the server * / ECHO NL2BR (HTMLENTIES ($ F-\u003e Serialize ())); / * We send an XML message to the server * / $ R \u003d $ C-\u003e SEND ($ F); / * analyze the result * / if (! $ r-\u003e faultcode ()) (/ * The message is made successfully and returned the XML result * / $ V \u003d PHP_XMLRPC_DECODE ($ R-\u003e VALUE ()); Print_R ($ V); ) ELSE (/ * The server has returned the error * / Print "An error OccURRED:"; Print "Code:" .htmlspecialchars ($ R-\u003e FaultCode ()); Print "Reason:" .htmlspecialchaars ($ R-\u003e FaultString ( )). "" \\ n ";)?\u003e
In this example, only one LJ.XMLRPC.POSTEvent method is considered - a complete list of possible commands and their syntax (in English) is available at:
Hackers are looking for different ways of hacking your sites. In the history of cases, if only the site does not represent some kind of commercial value, it will frolic the kids trying to somnake.
The other day, the sites of my hosting, to put it mildly, "faced". It was seen that DOS-Yat is some of the sites.
And it is seen primarily from the statistics of the use of server resources:
I was surprised for the reason that any commercial resources on hosting do not lie. What is the question, dos-it then? For what purpose?
What is visible in the diagram?
In the first picture, we observe the processor boot. It is measured 100% per core. Somewhere 15.00 Greenwich Attack began, and in the area 21.00 I asked the provider something to do with it. Those endage began transfer hosting to another master server. Apparently, to give me the opportunity to use more system resources. Hours at 22:00 began moving, checking the integrity of files and other procedures.
I didn't want to really mess around - and I just went to bed, for, "Morning in the evening wisen."
What can be seen in server logs?
Statistics on the morning no longer showed any anomalies. Sites still opened in times and not immediately, i.e. Attack continued. Whether the statistics have written everything from the old server, or this was already the master server data ...
Therefore, I switched to the study of logs to find out where "knocks."
When I looked into the logs, it became clear that you could not worry - somehow shkolota from the same IP address in /xmlrpc.php one of my sites on WordPress. Most likely he is engaged in Brut-Forras Admin Password.
Of course, there is little pleasant, since "lying" and all other virtual server sites. And the thing is the annoying that I do not use these XML services on any of your WP sites.
Block XML RPC.
The simplest thing you can do in this situation are to remove the file from the root folder /xmlrpc.php.. The server does not find a violet, will not run PHP, spend memory resources and processor time. The solution is simple, but not beautiful. First, someone can use RPC capabilities. For example, publish entries on the site through one of many weblog customers. And secondly, the file will be restored after the next WP update.
If your server runs on Apache, you can block access to xmlrpc.php.without deleting the file itself. Need to add the following instructions to top your .htaccess. File in the root directory of the site on WordPress. It will block access to the file from any addresses.
# XML RPC DDOS Protection
# XML RPC DDOS Protection < FilesMatch "^(xmlrpc\.php)" > Order Deny, Allow DENY FROM ALL < / FilesMatch > |
In my case, only the IP address of the request source can be blocked, because Used the same address. To block only the IP address of the "SCHOODERSER":
< FilesMatch "^(xmlrpc\.php)" > Order Allow, Deny DENY FROM 85.93.93.157 ALLOW FROM ALL < / FilesMatch > |
But if you use RPC, you can make a white list of addresses that have access to the script xmlrpc.php.
