RPC stands for Remote Procedure Call. WordPress XMLRPC is a protocol which allows remote systems to communicate with WordPress. The language to communicate is XML.
With WordPress XMLRPC support, you can post to your WordPress blog using many popular Weblog Clients.
XML-RPC functionality is turned on by default since WordPress 3.5.
Brute Force Attack through wordpress XMLRPC
Attackers usersystem.multicall method in XML-RPC to create hundreds of request combined in a single request to attack a system i.e. mostly to guess the username and password to the system. This is called as Brute Force Amplification Attacks via WordPress XML-RPC
How to prevent XMLRPC attack
The most recommended way is to disable XML-RPC completely. To disable XML-RPC completely add following to your APACHE configuration file.
Deny from all
Some plugins in wordpress e.g. Jetpack is based on XML-RPC. In that case it is not possible to disable XML-RPC entirely. In that case you can disable system.multicall requests through your firewall
Check server logs regularly and find IPs trying to access XML-RPC. Any suspicious IP can be blocked through your Firewall or iptables. Here are some sample logs
220.127.116.11--[02/Mar/2016:19:26:28+0530]"POST /xmlrpc.php HTTP/1.0"404-"-""Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
18.104.22.168--[02/Mar/2016:19:26:28+0530]"POST /xmlrpc.php HTTP/1.0"404-"-""Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
22.214.171.124--[02/Mar/2016:19:26:28+0530]"POST /xmlrpc.php HTTP/1.0"404-"-""Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
126.96.36.199--[02/Mar/2016:19:26:28+0530]"POST /xmlrpc.php HTTP/1.0"404-"-""Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
For security reasons and to prevent spam it is always recommended to log visitor/client IP address in your database atleast for important transactions like posting a comment, registration, etc. However it is important that we store the real IP of the visitor.
Visitor/Client is not using proxy
In almost all cases i.e. when the visitor/client is not behind the proxy we can get the real IP address of the visitor/client using
Visitor/Client is behind a proxy server
In some cases the visitor/client could be behind a proxy server. In that case we can get the real IP using
However using some tools one can easily pretend to be behind a proxy server. In that case we cannot get the real IP using above method
Also we cannot be sure if the visitor/client is using a proxy or not.
So it is best to store both the values in different fields in your database.
In simple words Clickjacking means users are tricked into clicking or keystroking on a different site/page making them think they are on their usual site.
How can that be a problem from security point of view. Here is an example
An example of Clickjacking
Lets assume you own a website my_domain.com and you login to it everyday. If this site is not protected from clickjacking a hacker may be able to call this site in an iframe on some page hosted on his domain some_domain_owned_by_hacker.com
Through some means the hacker may trick you in clicking and opening this page. If you do not notice the domain name in the URL then you may feel that it is your own website and may even log in.
Due to the keystroke recording script the hacker is then able to get your password.
However you may feel that you always check the domain name before performing any transaction on a website and more so if it is your own website. So would this still be a problem?
Remember that the hacker can even trick other administrators on your site and they may not be as careful as you are and it follows the same about your website users.
Further to this
Let’s assume you are already logged in to your website and the hacker tricks you in clicking some button on his page. Through the above mentioned iframe and button overlapping the hacker may perform a malicious administrative task on your website on your behalf by just tricking you to click on a link.
Solution to prevent clickjacking using X-Frame-Options
Solution to this is very simple. Simple add below code in your .htaccess file
Header always appendX-Frame-Options SAMEORIGIN
The above code checks if the page called within iframe is from the same origin. If not it does not display the page
1. WordPress security at the Configuration and installation level
This section explains measures to be taken for achieving wordpress security while installing and configuring wordpress.
1.1 Change default table prefix
Many published WordPress-specific SQL-injection attacks make the assumption that the tableprefix is wp, the default. Changing this can block at least some SQL injection attacks.
1.2 Securing wp-config.php
Are you aware that wp-config.php can be stored one directory level above the WordPress installation?
This is quite a simple task. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission). This file contains quite sensitive information like password, database user etc so it’s very imp to protect this file
1.3 Disable File Editing through WordPress Dashboard
The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files. This is often the first tool an attacker will use if able to login, since it allows code execution. WordPress has a constant to disable editing from Dashboard.
Add below line in wp-config.php
Disable file editing
1.4 Blocking Search Engine Spiders from Indexing the Admin Section
Search engine spiders crawl over your entire blog and index every content. Using robots.txt file we can restrict the content which we would like to be indexed by Search engines. Obviously the admin section is not required to be indexed. Just create a file named robots.txt in your root folder (generally public_html) folder and paste below contents in that file.
Login with a subscriber account regularly to check of any of your plugins have created any unnecessary administrative links which are not supposed to be accessed by subscribers
1.7 Keep your wordpress and plugins uptodate with latest versions
Latest wordpress version mostly has fixes related to recent security vulnerabilities. It is very important to update your wordpress installation as soon as a new version is released. The same follows for plugins. However plugins security is mostly upto the author so it is very important to select a secure plugin.
1.8 Change the default login URL
WordPress default login URL is http://www.yoursite.com/wp-login.php
A hacker who wants to break in to you site typically uses Brute Force technique on this URL. Brute Force in this case means a script which will automatically try various usename/password combinations on your login URL. You would think that you are safe because your firewall is set to track this particular activity and would just block the IP. Howerver the hackers are one step ahead. They keep trying this script from various IPs. So if one IP is blocked the script automatically runs from a different IP. Also the script is set to run at regular intervals to avoid any DDoS alarlms
To avoid such scripts attacking your login page, just change/redirect your login page to some secret page e.g. http://www.yoursite.com/entermysite. That way you would protect yourself from such automated scripts trying to Brute Force your authentication.
To change your login page just install the plugin Rename wp-login.php and on the settings page on this page provide your new URL.
There are a few reasons why this error occurs. The most obvious is your server is down or a certain process is taking too long and your server is very busy. However that may not be the most likely reason for this error especially if this is happening quite frequently. Here are the 2 most likely reasons.
When your website goes on clouflare, most of the incoming connections to your website are through the cloudflare IPs. If your server does not know about cloudflare IPs, its internal firewall limits access to any connections through those IPs simply because of the number of connections. So it is very important for your server firewall to whitelist those IPs. (Just to tell your server that connections through these IPs are ok). These IPs can be found on the cloudflare site: https://www.cloudflare.com/ips
You may have tried something which may have triggered some rule set within the clouflare firewall. This block is only limited to you and mostly for a certain time duration. However if you are a developer or are maintaining the website then you need to whitelist your IP by adding it to your IP firewall within the firewall settings on your cloudflare. If you are on a dongle or a network with frequent IP changes then you may need to do this a few times. In that case better to add a range of IP.