Dealing With Apache Error 403 BFHS

Trouble Is Coming

 

troubled-emoticon-150x150 Dealing With Apache Error 403 BFHS How To Tips Web Site Security The day started out as any other day. I got out of bed. Rounded up my two dogs and let them “outside”. Made some coffee. Fired up my Mac, and began to read my emails. As I scanned my emails looking for any that were urgent, I quickly saw that my WordPress website security plugin, Bullet Proof Security (BPS), had sent me an email. As this plugin has never saw fit to converse with me before, I thought this was not a good sign. Before I opened the security plugin’s email, I quickly scanned the rest of my unread emails, and found that the BPS plugin had been particularly busy during the night providing two other emails. From looking at their time stamps, I could see the emails were being sent every three hours. I quickly opened each email. Inside all three emails I found a BPS security log. After opening each individual log (see Figure1.BPS Security Log Example), what I found was pretty much the same:  attempts were being made to get access to my site, and my site refused access, providing an Error 403 to explain the refusal. These attempts were being made from all around the world, and from different URL’s. During the nine-hour period represented by the logs, there were 3,600 total refused requests made from my website.

http_error_log_txt-1024x943 Dealing With Apache Error 403 BFHS How To Tips Web Site Security
Figure 1. BPS Security Log Example

Was this a denial of service attack (DDoS), or some other kind of hack? I had done some redirects the day before, had I somehow perverted a small part of the internet? Had I suddenly gained overnight fame as a writer, and these requests were actually valid, and from adoring readers whose number simply over whelmed my website’s ability to handle their requests? Once I set my ego aside, I then quickly eliminated the later possibility; however, the former two still held promise. The truth is I didn’t really have a clue what was happening, all I knew was that my site was blocking many requests, and then issuing an Error 403, for each blocked request.

At this point, I felt the most prudent thing to do was see if the site itself was still functioning, and I did the following:

1. Even though BPS pretty much hardens .htaccess, I went to my site’s cpanel, opened its file manager, and verified that nothing “funny” had happened to .htaccess. All was good.

2. I have changed “permissions” on most critical programs and files, but double checked them as well. My quick scan showed no problems.

3. I left cpanel, and went to StatCounter.com, – this is one of the ways I track how the site is used. My site appeared to be taking “legitimate” requests from users, and the stats looked pretty normal.

4. Now for the last test, I accessed my site as a “user”. Once again, no issues.

From my cursory examination, I concluded that the site had not been breached and that it was still operational. Now to do some digging into what Error 403 BFHS really is, and what I can do to stop the attacks.

What Is An Error 403?

Wikipedia provides a good general explanation of an Error 403:

“A web server may return a 403 Forbidden HTTP status code in response to a request from a client for a web page or resource to show that the server can be reached and understood the request, but refuses to take any further action. Status code 403 responses are the result of the web server being configured to deny access, for some reason, to the requested resource by the client.

A typical request that may receive a 403 Forbidden response is a GET for a web page, performed by a web browser to retrieve the page for display to a user in a browser window. The web server may return a 403 Forbidden status for other types of requests as well.

The Apache web server returns 403 Forbidden in response to requests for url paths that correspond to filesystem directories, when directory listings have been disabled in the server. Some administrators configure the mod_proxy extension to Apache to block such requests, and this will also return 403 Forbidden. Microsoft IIS responds in the same way when directory listings are denied in that server. In WebDAV, the 403 Forbidden response will be returned by the server if the client issued a PROPFIND request but did not also issue the required Depth header, or issued a Depth header of infinity.”(1)

I started looking at the individual log entries (See Figure 1.BPS Security Log Example.) In my particular situation, each the Error 403 had a GET request (Letter “A” on the Example). By looking at the URL entires (Letter “B”), I could see that the addresses were from pretty much around the world. I opened a terminal on my Mac. I used the “whois” command, and by entering a URL for each of a small number of IP addresses, it was determined (at least from my sample) the addresses were real; however, they also could be spoofed. Finally, by looking at the Request_URI (Letter “C”. A URI is an anagram for Uniform Resource Identifier), I saw what the request was trying to GET: a php based feature named xml-rpc.php.

Deep inside WordPress is a core function called XML-RPC. This function allows WordPress to post from WordPress client software installed on a computer, tablet, or smartphone. This function can also allow WordPress sites to be tricked. Here, from Mor10.com, is a very good definition about how this can happen:

“The feature also powers pingbacks – essentially messages sent to other sites when they are being linked to – and it is very useful if you want to use a 3rd party application to write posts or you want to email posts to your site. This function can unfortunately be exploited to make your site send requests to target sites, thus becoming an accomplice in a DDoS attack. It is disturbingly simple: A few lines of code will trigger a cascade of requests to your WordPress site that then in turn send pingback requests to a specified site. Multiply that by a hundred or a thousand or a million sites like yours and you have a perfectly orchestrated DDoS attack executed by proxy through your and other sites…. Again, not an attack but an exploit. ….it seems any standard install WordPress site without Akismet activated is vulnerable to this exploit. Which is a serious problem.”(2)

What To Do…

At this point, I believed the Pingback Exploit was being attempted. Now, what to do about it. I first called my website host provider, made a “ticket”, and discussed the problem with one of the techs. This call turned out to be fruitless. It was suggested that I turn off the email part of the BPS plugin, and wait till the exploit attempts were done. Really?  This was not exactly what I was expecting to hear. I did some digging. My first stop was golden. I found a forum by the author of the BPS plugin. The author explains how to add a bonus code to the BPS .htaccess variants. You can read more about it, here. For those of you without BPS, enter this code into .htaccess, just before the very bottom entry:(3)

# XML-RPC DDoS & TRACKBACK/PINGBACK PROTECTION

# Using this code blocks Pingbacks and Trackbacks on your website.

# You can whitelist your IP address if you use A Weblog Client # or want to whitelist your IP address for any other reasons. # Example: uncomment

#Allow from x.x.x. by deleting the # sign and # replace the x’s with your actual IP address. Allow from 99.88.77.

# Note: It is recommended that you use 3 octets x.x.x. of your IP address # instead of 4 octets x.x.x.x of your IP address.

<FilesMatch “^(xmlrpc\.php|wp-trackback\.php)”>

Order Deny,Allow

Deny from all

#Allow from x.x.x.

</FilesMatch>

I added the above to .htaccess. My next stop was to my Content Delivery Network (CDN) provider, CloudFlare. They were most helpful, and suggested I added a Page Rule from my Dashboard on CloudFlare. For CloudFlare users, here are there instructions:

Page Rules are setup via your CloudFlare dashboard, and it would look like this: *larrytalkstech.com/xmlrpc.php and change Security Level to I am under attack. How do I create a Page Rule? – https://support.cloudflare.com/hc/en-us/articles/200172336

All the configuration settings basically, “harden” xml-rpc, making it more difficult to exploit; however, the exploit attempts may not stop, or may not stop entirely. I am still seeing some refused requests in my security log today, after all the configuration settings are in place.

Conclusion

This type of exploit with WordPress does not seem to be uncommon. If you are using WordPress without a good security plugin, you are in dangerous territory. There are some good security plugins available.  I use the “FREE” version of BulletProof Security. Find one, and install it today.

Endnotes

1.  HTTP 403 | http://en.wikipedia.org/wiki/HTTP_403

2. . Your blog has been hacked. Actually, maybe not. The Pingback Exploit. Morten Rand-Hendriksen. December 9, 2013.  http://mor10.com/blog-hacked-actually-maybe-pingback-exploit/

3. WordPress XML-RPC DDoS Protection. July 24, 2014 | BulletProof Security Forum http://forum.ait-pro.com/forums/topic/wordpress-xml-rpc-ddos-protection-protect-xmlrpc-php-block-xmlrpc-php-forbid-xmlrpc-php/

By prometheus

Husband. Father. Grandfather. World class Geek.

Leave a comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.