Several types of attack can be launched against WordPress website such as unwanted Bots, SSH Bot requests, unwanted Crawlers etc.. Some times back, i noticed that there were several attempts to perform a DDOS attack on a WordPress website by sending massive POST requests on the xmlrpc.php file. This will consequently brings the webserver to consume almost all resource and consequently caused the website to crash. Worst is that if you are hosting your website on a container such as OpenVZ or Docker, your hosting provider would usually mentioned on its agreement about abuse of resource which would turn you solely responsible. In many agreements, the provider would terminate the contract and you may loose all your data. Hosting your website on a container is indeed a huge responsibility.
What is xmlrpc.php file on a WordPress website ?
It is actually an API which enables developers who build apps the ability to communicate to the WordPress site. The XML-RPC API that WordPress provides gives developers a way to write applications that can do many things when logged in the web interface such as post publishing, Editing etc.. There is a full list of the wordpress API at this link. There are several ways to block out users from performing POST requests on the xmlrpc.php such as IPtables rules, rules in the htaccess file or in the webserver etc.. However, i find Fail2Ban more suitable for my environment.
How VPS hosting providers might interprete these attacks ?
Usually VPS provider will not perform analysis of the attack but it depends on the service you are buying. One of the way how the attack might felt at hosting level is about the conntrack sessions usage. Abuse of conntrack usage will usually raise an alert at hosting side and you might received a mail about the issue. Its now upto you to investigate deeply the issue.
What are conntrack (connections tracking) sessions ?
A normal Linux OS has a maximum of 65536 conntrack sessions by default, these sessions all require memory which is used by the host node and not by the VPS so setting this limit to high can impact the whole node and allow users to use more RAM than their VPS has allocated by eating up the host’s RAM. Any VPS that uses over 20000 conntrack sessions will automatically be suspended by our automated system. “In brief, conntrack refers to the ability to maintain state information about a connection in memory tables such as source and destination ip address and port number pairs (known as socket pairs), protocol types, connection state and timeouts.” – rigacci.org Firewalls that performed such task are known as stateful.
Counter attack measures that could be taken
1.In the jail.local of the Fail2Ban application add the following line. By default jail.local is located at /etc/fail2ban/jail.local
It also depends where your web server access log is located. In this case its located at /var/log/nginx/access.log
[xmlrpc]
enabled = true
filter = xmlrpc
action = iptables[name=xmlrpc, port=http, protocol=tcp]
logpath = /var/log/nginx/access.log
bantime = 43600
maxretry = 20
2. Then, create a conf file in /etc/fail2ban/filter.d I have created it as xmlrpc.conf and add the following lines:
This acts as a rules to look for all post for xmlrpc.php
[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
ignoreregex =
3. Restart your fail2ban service and watch them out in the fail2ban log. Here is an idea what happens when an IP is caught
[root@server nginx]# cat /var/log/fail2ban.log | grep -i xml 2016-07-17 06:39:06,685 fail2ban.actions [4565]: NOTICE [xmlrpc] Ban 108.162.246.97
4. Here is an idea the number of POST request received from a server.
[root@server nginx]# grep -i “xmlrpc.php” /var/log/nginx/access.log| grep POST | awk ‘{print $1}’ | wc -l
62680
5. Lets have a look at the 10 top IPs performing more POST request
[root@server nginx]# grep -i “xmlrpc.php” /var/log/nginx/access.log| grep POST | awk ‘{print $1}’ | uniq -c | sort -n | tail -n 10
185 91.121.143.111
186 94.136.37.189
279 37.247.104.148
317 80.237.79.2
1497 191.96.249.20
3060 46.105.127.185
5999 5.154.191.55
11612 191.96.249.54
16917 52.206.5.20
17111 107.21.131.43
6. However, if you are not using a container server, you can set different type of parameters in sysctl.conf if you have not performed a full analysis of the conntrak abuse. You can limit number of connections using the following command.
In this case, i have limit it to 10,000 connections.
/sbin/sysctl -w net.netfilter.nf_conntrack_max=10000
7. To check how many sessions, use the following command
/sbin/sysctl -w net.netfilter.nf_conntrack_count
8. However, you need to make sure that the modules have been activated into the kernel. Check with the following command
modprobe ip_conntrack
The aim is to find a solution to get away with DDOS over xmlprc.php as well as the setting up of the conntrack parameter in sysctl.conf
