The WordPress XML-RPC API has been under attack for many years now. Back in August 2014, WordPress released version 3.9.2, fixing a possible denial of service issue in PHP’s XML processing. There are brute-force amplification attacks, reported by Sucuri, and so on. So, how do you protect WordPress from xmlrpc.php attacks, but still being able to use (some of) its functionality like Jetpack? This post gives you some insight.
Imperva’s Web Application Attack Report shows spam is WordPress’ largest security threat. Imperva, an international cyber security company founded in 2002, published its 2015 web application attack report. The report includes a thorough analysis of attack data obtained through its Web Application Firewall (or WAF).
Rewrite and proxy HTTP requests in IIS. In my case scenario, I had to proxy requests on IIS, because a website was moved from web server A to B, and the DNS wasn’t updated yet. All HTTP requests for the moved website are handled in IIS’ Default Web Site; that’s the wildcard host, and the original host no longer existed there. We needed to match our website and proxy those requests to the new IIS web server. This can either be done using a proxy with URL Rewrite, IIS Application Request Routing (ARR), or a
.htaccess file handled by Helicon Ape.
The Baidu spider (BaiduSpider user agent) can be a real pain to block, especially since it does not respect a robots.txt as it should. The following IIS URL Rewrite snippet blocks the Baidu spider based on its User-Agent string.
Do you host your WordPress website on Windows Server IIS? Having trouble with your web.config? I often receive questions about how to use a web.config file in WordPress on Windows Server, and which settings are important for a WordPress website. Maybe it’s because I’m a WordPress on IIS enthusiast, so here is my web.config for your convenience (really, it’s not that special).
The following PHP function will disable the execution of PHP scripts in WordPress’ wp-content/uploads, on IIS web servers. Securing the WordPress uploads folder is important. In many hacked WordPress sites, a PHP backdoor is found within the
WP_CONTENT_DIR/uploads directory. Often because this is the location where uploads are placed automatically. From the backdoor within
wp-content/uploads other backdoors are uploaded to various locations, and scripts are injected with malware.
An HTTP to HTTPS redirect on IIS is often better left to the web server, with a simple httpRedirect redirection, than to a resource expensive URL Rewrite. Where possible, use the IIS
httpRedirect element for IIS HTTP to HTTPS redirection, and here is how:
WordPress xmlprc.php DDoS and brute-force attacks. How to identify, block, mitigate and leverage these xmlrpc.php scans, brute-force, and user enumeration attacks on WordPress sites… Secure WordPress xmlprc.php interface and reduce service disruption.
How to remove HTTP response headers in IIS 7, 7.5, 8.0, 8.5, and ASP.NET. Windows Server IIS loves to tell the world that a website runs on IIS, it does so with the Server header in the HTTP response, as shown below. In this post I’ll show you how to remove response server headers in IIS. You don’t want to give hackers too much information about your servers, heh? ;-).
uses used URL Rewrite Outbound Rules in IIS, to offload content from a different server and/or host name. This should improve website performance. Just recently I noticed Outbound Rules conflicted with gzip compressed content. I started noticing HTTP 500 error messages:
Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").. Here is how to fix that error.
The less spammers hit your WordPress blog, the better your blog performs, is one of my opinions. A second is, the less unnecessary plugins you use on your WordPress blog, the better. So, a little while ago I decided to remove plugins like Stop Spammer Registration Plugin and do its work myself. Here is why & how:Read More
This website Saotn.org is hosted on Windows Server 2012 with IIS 8.0 with WordPress for a few months now, and everything is running very smooth. And I would never hit this bug because I don’t need to change my permalinks structure, or save any other plugin setting which would want write to a web.config file. One of my colleagues on the other hand, just moved his website to one of our IIS 8.0 web servers and he noticed he couldn’t save his Permalinks structure in the IIS web.config file. This can be pretty annoying ;-) Quick fix attached…