Cancel

Jeff Chandler

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 WAF or Web Application Firewall.

In the report, Imperva’s application defense center group analyzed 297,954 attacks and 22,850,023 alerts on 198 of the applications it protects behind its WAF. The data is from January 1st, 2015 – June 30th, 2015 and provides a solid overview of the number and types of attacks web applications are experiencing.

The report covers a lot of ground but for the purpose of this site, I’m focusing on WordPress.

Analysis Methodology

Automated tools recorded the web applications’ traffic and malicious events were documented in log files. Imperva’s application defense center group analyzed the data using special-purpose software and its knowledge base.

You can find more information that explains how the data was analyzed on page seven of the report.

WordPress Is the Most Attacked CMS Application

Out of the 198 applications protected, Imperva identified 55 that are CMS-based, 20 WordPress applications, 11 Drupal, and 24 that are based on 11 other CMS frameworks.

Average Number of Incidents per Applications CMS Slice
Average Number of Incidents per Applications CMS Slice

According to the report, CMS applications suffered an average of three times more attacks than non-CMS applications. WordPress applications suffered from 3,497 attacks in the reported period which is 250% more than non-CMS Applications. Note from the above image that spam attacks against WordPress outnumber all other types of attacks.

Imperva says the attraction to CMS applications, especially WordPress is not new.

CMS frameworks have an open nature,  with open developer communities that generate a never-ending sequence of plug-ins and add-ons, with varying levels of security. This situation has led to corresponding never-ending flow of CMS vulnerabilities, with WordPress as the leading CMS taking the lead also in the amount of published attacks.

Furthermore, the fact that WordPress and other CMS applications resemble each other facilitates automated scanning attacks that work effectively on all applications of this type with only minimal adjustments.

Varying levels of security in plugins have led to many vulnerabilities making WordPress the leader in the amount of published attacks.

Proportions of Attacks

Taking spam attacks out of the equation, the most popular attack type against WordPress applications is (RCE) Remote Command Execution with (RFI) Remote File Inclusion taking second place.

Proportion of Attack Types
Proportion of Attack Types
  • Remote File Inclusion (RFI) is an attack that allows an attacker to include a remote file, usually through a script, on the web server. This attack can lead to data theft or manipulation, malicious code execution on the web server, or malicious code execution on the application client side such as JavaScript execution, which can lead to other attacks. This vulnerability occurs due to the use of user-supplied input without proper validation.
  • Remote Command Execution (RCE) is an attack that allows the attacker to execute operating system commands in a system shell. The attack exploits applications that suffer from insufficient input validation in conjunction with passing this input to a system shell. The attacker’s payload is executed with the same privileges of the vulnerable application and can lead to full compromise of the server.

Even though the other monitored CMS applications are written in PHP, RFI attacks on WordPress are significantly higher than all other applications. Imperva offers one possible explanation:

Attackers don’t target a specific application, but start with scanning the Internet for vulnerable applications. A Low Hanging Fruit approach that is simple and effective for the detection of potential RFI targets, would be to run a WordPress test and mount an RFI attack in case of success.

The report goes on to show geographic attack trends, PHP vs non-PHP attack incidents, traffic volume, case studies, and more.

No Need to Panic

Even though it’s only six months of data, the results don’t surprise me. WordPress is used on a quarter of the top 10 million websites ranked by Alexa so of course its going to be the most attacked CMS.

The data in the report reinforces my belief that every public site online is likely being scanned or attacked multiple times a day. Unless you’re using a service or plugin that logs these types of attacks, its hard to know how popular of a target a site is.

If you’re aware of a plugin or service that provides a user-friendly interface that shows and explains the attacks it’s protecting against a site, please send me a link in the comments.

Basic Security Principles

It’s imperative that you use a strong password and two-factor authentication. Consider using a service like Clef that allows you to login to WordPress without a password. I also highly encourage you to read the WordPress security whitepaper to learn how WordPress protects itself against common attacks mentioned in Imperva’s report and how to responsibly disclose a WordPress security vulnerability.

Category:
Tags: , , ,
41

41 responses to “Imperva’s Web Application Attack Report Shows Spam Is WordPress’ Largest Security Threat”

  1. So Jeff, we were talking the other day about how to bring up issues of wordpress, and how to engage the core developers.

    Today, we are looking at a huge problem for WordPress, spam in all it’s different colors. The number of times through TRAC and other means that the developers have been engaged on spam is huge, the number of solutions and changes incredibly small.

    First and foremost, there is no simple or direct method to disable the various routes taken to spam. You could require users login to post comments, but then you create additional risks by allowing them a basic level of access to the back end of your site. Allowing people to log in means that every permission escalation hack can now be applied to your site. So for many sites, forcing users to log in is not a cure, just a different and more dangerous problem waiting to happen.

    So then you move to “approved comments only”. The downside (as you well know) is that you get to spend a good part of your day deleting spam. Akismet can help, but for a commercial user the cost versus the effectiveness isn’t a good balance. Way too much spam still gets through.

    Why does this happen? Well, there are two core issues at hand here: WP seems to do a poor job at handling direct calls to comment code, and a seeming quiet agreement between the core developers and Automattic not to fix the spam issue and harm the income stream from Akismet services. It sounds a little weird but it really does seem that spam issues are not addressed because of a business model issue – both to sell Akismet service and also to sell wordpress “hosted” solutions for sites. It’s sort of like a non-compete clause.

    WP comment system was created when the web was sweet and innocent, and track backs and glib comments were all the rage. Like email, comments have become less and less useful because the spammers realized they could get their message and links out via your sites. Faced with the issue, the true question is how to handle spam better – and that may be a complete overhaul of the way the comment systems work. There is no safe and reasonable way to have wide open comments anymore.

    For me, the first step is to give better control on the sites themselves. Each of the routes for a comment to get on your site should be able to be controlled. XMLRPC? wp-comment.php ? trackbacks? each route needs to have it’s own security and choices so that sites can handle the flow. That would include the ability to shut off and return 404 errors to discourage bots and scammers from even knocking on the door. Just denying people with a “we can’t accept comments this way” message doesn’t work, because every attempt to spam uses system resources, starts a database connection, uses up a process… handling big volume spammers can cripple a site even if you don’t want their stuff.

    My personal solution is to hack XMLRPC and others to deny access based on IP. I have only a few IP addresses that can use XMLRPC, everyone else gets a blank 404 response. I have to hack it because there is no provision in any of the site access programs to add security code or filtering. For the record, I do the same on wp-login and /admin/index.php to control the flow of door knockers and hackers – all with code added manually on each update because, well… there is no hook and no place to handle this stuff directly.

    WordPress is a target. Developers need to more clearly understand that and understand what it means not for highly technical users but for “end users” who can’t write a regex or code htaccess well enough to be secure. We need to push down the business model barriers that appear to block progress on the issue, it’s very likely that this sort of issue is what will eventually bring wordpress down.

    • I’m on the same fence as you when it comes to the difficulty of solving the spam problem. I’ve used Akismet since I started using WordPress nearly 7 years ago. It’s done a fantastic job as a free plugin combating spam but lately, it’s been missing a lot of obvious ones.

      It’s missed so many obvious spam comments that I’m questioning whether it’s a viable solution for the site anymore. After all these years of algorithmic learning billions of spam comments, I’d think Akismet would be much better at discovering and discarding spam.

      If Akismet is not yet at a level where it solves the problem, then I think there’s a problem either with how the WordPress comment system works or with Akismet as you allude to in your comment.

      I don’t know which it is and if Akismet hasn’t solved the problem by now, is it a problem a competitor like Mollom which is also a service, can solve?

      It’s really difficult to find a balance between combating comment spam and allowing visitors to participate in the conversation without requiring a user account. I don’t think the user privilege escalation issues are as bad as you make them out to be as the core team does a good job patching them as they become known. However, you’re right that opening registration is one more point of attack hackers can focus on.

      I don’t know what the answer is but it not only has to solve the spam problem, it has to do it in a way that doesn’t make it harder for visitors to participate in the conversation. That means no captchas or requiring visitors to know math.

      • After all these years of algorithmic learning billions of spam comments, I’d think Akismet would be much better at discovering and discarding spam.

        Spam changes pretty rapidly. Knowing spam comments from five years ago doesn’t help much in detecting spam comments today, so it’s more about how good of a system we can build to respond to new types of spam as soon as they appear, and I don’t think we’re doing that bad of a job. Akismet’s accuracy rate is currently at or above 99.99%. Five years ago, it was closer to 99.8%.

        That being said, it hurts every time we miss something “obvious.” If you’re consistently seeing spam comments that are getting past Akismet, let me (finke@automattic.com or support@akismet.com) know, and we’ll address it as quickly as possible. (That goes for all readers of the Tavern too.)

      • Basic spam problems are easy to solve. I’ve seen very few sites which have what I would call a “spam problem”. The problem is normally that you just haven’t done enough to block the spam. Akismet on it’s own is rarely enough to block spam on a site with even a moderate amount of spam coming in.

    • a seeming quiet agreement between the core developers and Automattic not to fix the spam issue and harm the income stream from Akismet services. It sounds a little weird but it really does seem that spam issues are not addressed because of a business model issue

      Here is the answer

  2. It’d be more useful if these numbers were proportional.

    What proportion of attacks are launched against WordPress compared to other CMSs? Is it more or less than 25%?

    Kudos for posting the white paper, which is a great start for folks looking to stay secure.

    • Not sure, the percentages are based on the number and types of attacks, not proportional to attacks overall. I feel like I needed a PHd to decipher the charts and percentages.

      • Not to imply that there is anything obviously wrong with that paper, but statistically it is not a good representative of anything as it focuses only on their clients of which only 20 are wordpress based. minimal statistically significant sample should be in the hundreds and there is also a selection bias as those are sites that pay for the security service which probably implies that they have a bigger public profile and maybe are a more sought after attack target.

        The big takeaway for me is how inefficient it is to block IP addresses based on geo criteria since the US and UK rank number 2 and 3 as attack source and together generate more attacks then china,

  3. Spam used to be a big deal for me but then I found what works. Akismet doesn’t stop spam. It merely classifies it. I use the Conditional CAPTCHA plugin to give comments classified as spam a second chance. It’s a simple text CAPTCHA and if it isn’t filled in correctly, the comment gets automatically trashed.

    I moderate all comments that make it through and I’ve yet to see a real comment not make it through.

    There’s another solution and it isn’t easy to do with Apache, but incredibly easy with Nginx. My author URL points to an article I wrote about it.

    • I use Conditional CAPTCHA too and I think it works really well, but the one problem I have with it is that if Akismet doesn’t identify a comment as spam, then Conditional CAPTCHA doesn’t perform a second check, it just assumes that Akismet is right. So while using Conditional CAPTCHA gives me confidence that all real comments are coming through, I still get spam comments coming through as well sometimes…

  5. Jeff, unrelated question, where does the cool avatars come from? Is it a new option in 4.4 or something that was tailored for the tavern?

  7. Hi Jeff,

    Regarding “low hanging fruit” – I believe its best to prevent spambots identifying your site in the first place. I couldn’t find advice on this when I started blogging, so I did my own research. If anyone is interested I’ve written a post about how these bots use “footprints” to find your site (and how to foil the bots).

    I also think password protecting wp-admin directory is a simpler & more effective starting point than 2 -factor authentication for small sites. A friend was suffering burst mode DDOS attacks on wp-login, bringing his site down even though he was using the limit logins plugin. We solved this by password protecting the admin directory – drastically reducing server load/bandwidth i.e. no PHP/Wordpress scripts run and no returning an HTML “page”; just a few bytes HTTP response. With 2 factor authentication plugins you still have the server load and bandwidth issues – and they only protect login from hacking.

    • Spambots don’t need much effort to identify your site as wordpres, after all 1 in 4 site is wordpress. the bigger the market share of wordpress will become the less relevant the question of “how do they identify” will be. but nice research, although I am sure the spammers don’t use google.

      The best way to prevent brute force attacks from bringing down your site is to not use a security plugins (a little exaggerating here). Login limiter brought your friend’s site down because it needs to write to the DB on every failed attempt while the cost of just handling the request the usual way is non zero but it is much smaller then a write to the DB.

      • The execution of core code and the invoking of DB connections is a real issue. Someone hitting your wp-login page a thousand times a minute invokes 1000 DB connections, loads the core code 1000 times, checks your mysql version 2000 times (it happens at least twice in start up) and does a myriad of other things. All of that takes system resources. Adding a failed login tracker that access a database and writes to it is the kiss of death.

        This is actually the reason I tried (and posted a TRAC about) trying to get a “hook” at the start of each of these methods that would first run a PHP file which could be maintained and changed by the end user. As an example, if you use XMLRPC to update posts on your blog, but only do so from home or your office, you could limit the access by IP or country code (example), and reject all others before they even can access the wordpress code. You could also choose to exclude certain countries, IP blocks, or the like in an easier fashion.

        Yes, you can do the same with htaccess, but most users are NOT going to be able to create reliable htaccess rules on a “by file” basis. The heavy duty core programmers don’t seem to understand that not everyone can write complex code.

        I am thinking that the access points (wp-login, xmlrpc, wp-comments, admin/index.php etc) need to be re-written in order to limit the amount of system resources required before credentials are checked. Those access points should have, almost as the first line of code, a call to a set php file that can be maintained by a user or plug in, that could set parameters for access to those programs. Eliminating the system load from these processes would limit the DDoS effects of just a few attempted logins to a site.

        Remember: more and more often, hackers and spammers are using hosting services like OVH to create droplets / virtual servers, some of which do have very high speed connections to the net. I have seen some of them doing hundreds of connection requests a second (!). If each of those connection requests lead to opening a DB connection, loading a bunch of files, checking mysql version, running wp_maintenance routines and so on, then yes, they could drag down a server pretty solidly. Get a few of them pointing at the same server, and they can effectively lock out any normal user from gaining access to your site.

        This is an area I think needs a huge improvement. WordPress is a magnet for this activity, and it’s less than optimal design on this level is becoming it’s archillies heel.

        • Bootstraping wordpress has almost the same cost to whatever page you load. So having 1% of your site traffic directed at the login page should not be a big thing. If the site can not handle a spike of 1% in traffic then it is next to needing an hardware upgrade and blocking the login will not really change that.

          Not only read is much faster then write out of the gate, reads you can also cache and have an even better performance (object cache or DB cache settings) , but writes can not be cached and worse, they invalidate any cache you already have hurting the next read as well (this is very general statement and of course depends on the specifics).

          Limiting access by IP is a great way to lock yourself out of your system If you are too specific, and since US and UK are the second and third source of attacks you can not use any source of geographic filtering. Anyway network users do not have access to htaccess and nginx can not be easily change without root access to the server, so this technique can be used by a very small amount of wordpress users. and if you keep doing it at PHP level so anyone can use it, then you will still pay the “penalty” for bootstraping wordpress.

          As for moving the access points I agree but there are 2 caveats
          1. do it wrong and you are looked out without anybody being able to help you since your config is different then the normal one.
          2. For some protocols to work you need to expose your end pont in any case. this goes for comment and xml-rpc because of pingbacks. And even for login, if you stop the automatic redirect from wp-admin you hurt usability.

          Anyway, this discussion about blocking IPs and endpoints reminds me the joke about the fact that companies in trouble will first thing cut their coffee budget because everybody understands in coffee but the real expanses are harder to understand and therefor harder to cut. Same here, brute force is not a real problem but people always focus on it because it is easy to understand. Main breaches to wordpress are via badly coded plugins and themes but everybody installs them without doing even minimal security review of them.

          There is nothing wrong with cutting the coffee budget if you can, it is just not the thing that will likely move your company from red to black.

        • Mark,

          “Bootstraping wordpress has almost the same cost to whatever page you load. So having 1% of your site traffic directed at the login page should not be a big thing. If the site can not handle a spike of 1% in traffic then it is next to needing an hardware upgrade and blocking the login will not really change that.”

          For a VERY large single site, the percentage might be small. For smaller sites, however, the numbers are different. When you have a server that hosts hundreds (or thousands) of small wordpress sites, a high power spammer with a big connection can be absolute death. I am not talking about some guy doign a copypasta manual job with comments, but hardcore bots that can hit your sites with a 10-50meg a second assault on your server. They can literally eat up all system resources and create a virtual DDoS in seconds. The longer you leave them connected, and the longer you give them enough response to keep trying, they will absolutely bombard you.

          I looked at one case this morning (in real time). Blocking a SINGLE xmlrpc bot was enough to take a full 1 off the server load – which is load enough to handle hundreds if not thousands of regular requests a minute. That is with sending them nothing more than a 404.

          I suggest you relook at your sites carefully. I think you would be shocked to see how many times your door gets knocked, how often someone tries to log in without permission, how often spammers trying to directly call wp-comments or xmlrpc. For a small to mid site with say 1000 session a day, the spam and attack traffic can easily match or exceed normal users. It’s twice the resources for nothing.

          The old “throw more hardware at it” is generally a poor answer, that is money down the toilet similar to making a new pot of coffee every time someone takes a single cup.

          • Alex, but those people do not intend to DOS you, they gain nothing from it.
            People that do DDOS do it for extortion or some political reason and are totally not interested in spamming the comments or hacking your site in a way that will not be immediately discovered and therefor don’t need proper login.

            And 1% is still just 1% no matter from which number you take it from small or big. If you are doing shared hosting style of thing then you need to be able to handle traffic spikes in one of the sites (they sent a newsletter) without impacting the others and must have the spare capacity ready or at least a plan on how to handle such situation.

            Comment spam is a problem because akismet writes to the DB. Akismet should really be the last line of defense and not the first one. But brute force attacks? Most of the cures are worse than the decease. From experience, even mediocre passwords can stand them.

            And as for not wanting to pay for more hardware, I don’t think that 10$ more a month is excessive to anyone that has a web site, if the site important enough for him, but what is lacking in your comment is a solution. What exactly do you propose that will work under all server configurations and will reduce brute force attempts and spam?

        • Mark, I have plenty beefy servers at work. But with a good connection and the spammers having a good connection, they can make literally thousands of connection requests a second. There is a point where Apache, even well configured, will fall behind that level of connection. Do the math, even at 1000 connection a minute, that is 60,000 an hour or 1.5 million a day run rate.

          I don’t say that they are trying to DDoS, I am saying that is the effect.

          Good servers don’t cost $10.

          • “Good servers don’t cost $10.”

            You have to decide who are you trying to protect here. For a big site the added brute force and spam are in significant in the amount of valid traffic they use.

            For a small site a 10$ digital ocean or linode is way more then enough even for handling the brute force and spam. Making it 20$…. well it is not needed, maybe just just to sleep better at night if you are really paranoid.

            I admined a site with 40M page views a month and brute force against the login was a total non issue, no one bothered to look at the logs. Now cache busting urls from whatever misconfigured server they came from (didn’t look like an attack), that was a real big issue.

      • @mark k “I am sure the spammers don’t use google” – when I checked all the major spambots did.

        “Spambots don’t need much effort to identify your site as wordpres, after all 1 in 4 site is wordpress”. I said “find site” for brevity – sorry my bad on clarity. To expand:

        Knowing there is “25% chance” a site is WordPress is not sufficient to automate spam, so you can prevent spambots targeting your site. To work effectively bots need the URLs of individual posts (with comments open) on hundreds of sites. They create lists of victim URLs (which are then auto spammed) by Googling for WordPress footprints and scraping the URLs from the results. E.g. to generate a list of target URLs for posts about cats with comments open you would use the search term ‘ “Leave a reply” “Powered by WordPress” cats ‘

        As I explained in my article (link in my previous comment) you can “prevent” your site being identified by spambots. It seems to work for me, when moderating comments there are only 2 or 3 (probably human) spam comments a month across 3 WP sites (I guess I used to get between 50 and 150 a month that weren’t blocked by anti-spam plugin).

        I highlight that my comments are moderated which I guess discourages human spam. I don’t use Askimet – it wasn’t necessary when using the old version of “Spam free WordPress (SFW)”. Unfortunately SFW was castrated a few years ago to encourage use of the commercial version – so I now use in-house code – it doesn’t log so I’ve no idea how much it blocks.

        • Those claims fall into “citation needed” category”

          To clarify what I meant regarding google is that google is rate limiting their services so I will be surprised if a john do spammer can just run a search whenever he want without paying for it, and spammer don’t like to pay as it cuts their margins (and google probably monitors for such a use).

          As for detecting wordpress, you need to do it only once a year and have a DB of it. And it is much easier to identify wordpress and its version by trying to load several file and page (does anyone remove the comment yaost and W3TC insert into the HTML)

          Once you have the DB you can just cross check the URLs you want to spam against the DB to know the right endpoint to send the spam to and what parameters should be included.

          Your footpring suggestion are just the tip of the iceberg if that is really the direction you want to follow. If “powered by wordpress” was something that spammers actually cared to detect than changing it to “powered by drupal” would have given a perfect spam solution.

          If it was so easy to avoid spam as your suggestions suggest we would have been all spam free by now. Real life suggest that such security by obscurity usually leads to hurting the valid users more then the spammers.

  8. Since you asked for helpful plugins: The Redirection plugin by John Godley has some logging abilities, and the 404s log shows me what page folks are trying to access and their IP (and the date & the referrer). I’m not sure where that falls on the “user-friendly” continuum, but it’s much better than nothing.
    (I manage a small, niche website that focuses on providing free information — it’s not a complicated setup. Comments aren’t even allowed since they are usually misleading or off topic (or both) questions on well-researched articles — and it was easier than handling spam, and people can and do just email the website management instead of commenting.)

  9. IP Geo Block (https://wordpress.org/plugins/ip-geo-block/ ) plugin has an updated logging of many attacks by country – even blocking attacks and logging for scans / attempted access to plugins folder, and options to turn on and off other country access to admin ajax, comments, logins.
    (older version hod log ability but was turned off by default upon install, newer installs I think turn on logging for some events and others optional)

    sucuri has some good logs for showing failed login attempts (and changes to wp-files, posts, plugins) – even shows the multiple fails that limit login attempts doesn’t see.

    I’m guessing many use limit login attempts plugin, which may show 4 attempted logins from a now blocked ip addy – but it’s missing the 96 other attempts / fails that were made by same when the method is xmplc.

    Currently I just disable xmlrpc with “Simple Security Firewall” (in wp repo, too many links and akismet puts you in never-to-been-again-land )

    On one domain name that has never had a wordpress on it I set a script to log all ips that tried get and post to xmlrpc (and that domain / site / server folder never had a file there before) – it’s amazing how many gets and posts to that there are in raw access logs..

    long story shorter – I don’t have as good of a way to log those xmlrpc requests at the moment, and most of my wp sites have it disabled now finally.

    I started to engage this plugin developer ( https://wordpress.org/support/topic/add-option-to-export-text-file ) about modding his code to output this info to a readable file instead of just to an iptables apache file

    (I’m trying to log all of the failed attempts to login from the US, do a whois lookup to determine if it’s a server company or home computer network.. save additional fields that are needed for AWS abuse complaints, stuff like that.. been to busy to follow up with those suggestions there, need to get on that)

    Anyhow, spam be number exploit attempt ‘by the numbers’ currently – and even though there was a version of WP where comments had a known security vulnerability and that was a big issue then.. from all of the hacked sites I’ve seen, it’s just finding one on a server with a plugin or theme or some other hole. get in. and own it – they can (and do) whatever they want with your site and other files on other sites on the same server.

    It is not “low hanging fruit”, it is “a LOT of fruit- not so high hanging”..

    ps – the akismet comment – after using it for years I had to do a complete wipe / reinstall of site – fresh database and latest akismet – entered my old key and told that need to upgrade – so akisment stopped working for me, deleted it (hope it does not auto-reinstall with future wp updates, and how the whole privacy of Euro visitors that comment and have them routed.. another tangent..

    anyhow, I have found wp spam shield plugin in the repo to be pretty solid for comment spam, and have not gotten any emails about comments posted that never made it out of moderation (not that had THAT many with akismet in the past, but have had some users email about comments that were falsely flagged and hidden from my normal view more than a dozen times)

    • Those solutions are painful because they require both that the normal bootstrapping and startup of wordpress occurs, but also then that additional resources are spent to open a db connection for logging, and for checking incoming requests. That makes the cure almost worst than the cause, and makes it much easier for your machine to be DDoS’ed by someone just trying to spam you.

  10. Akismet became useless for me after I had two websites get to be rather large (as in, 8+ years of data).

    I had been using Conditional Captcha to cut off Akismet’s comment histories, which had bloated my databases to ridiculous levels, but I got tired of always having to optimize my databases so frequently because Akismet couldn’t clean up after itself.

    I don’t even install Akismet anymore, and since then, I’ve noticed a TON of 404 errors from probing attacks aimed at Akismet files, and I’d love to know why that is.

    I’ve used either WP-SpamShield or ZeroSpam, depending on site needs for the past year or two, and I’m delighted with their performance. I’ve begun looking at newer options for protecting login attempts, and all the other goodies.

    Observing the logs for the 404 errors from people scanning for specific files in specific plugins that have previously been exploited is a fascinating read… I had no idea that so many free plugins were targets.

  11. If you’re aware of a plugin or service that provides a user-friendly interface that shows and explains the attacks it’s protecting against a site, please send me a link in the comments.

    Wordfence Wordfence Wordfence Wordfence Wordfence.

    Even the free version is fantastic, the caching engine alone makes it worth the install. It blocks brute force attacks, logs every failed entry, can completely blacklist an IP when they attempt logins like “admin”, it logs countries where attacks originate from, and with the paid version you can even whitelist certain countries (or specific IPs) that are allowed to log in. Oh, and malware scanning! (Paid version)

    Ok, no, it’s not super user friendly – it’s very much a power user plugin, I usually tell my clients not to mess with it – but anybody who actively manages a WordPress site will be able figure it out. This is very much a must-have plugin.

  12. A few days ago, right after I posted my comment above, I created a function to add a JavaScript cookie to every post. I then used Nginx rules to return a 403 to anyone attempting to comment without that cookie present. I turned off Akismet.

    I haven’t seen a single spam comment since then.

    • A problem I experienced with that approach, is that when people have a cookie issue, they can’t comment. It’s also not as effective as requiring JS, as a cookie seems to be easier for spammers to fake.

      I made a plugin which works around this, by providing a fallback to a CAPTCHA when the user can’t run either cookies or JS (it also does some JS trickery to see if the visitor can handle JS calculations) …
      https://wordpress.org/plugins/spam-destroyer/

      • I’m setting the cookie with JavaScript, so I’m killing both birds with the same stone.

        I’m not concerned if someone who’s turned cookies off suddenly wants to post a comment. In my experience, your average person doesn’t do that.

        If I had a really busy site, I’d probably do something different.

        • It’s not just someone turning them off, and be something out of their control, like the page didn’t fully load, and so neither did your JS. In that case the form gets submitted are per normal, but no JS ran and so the comment gets picked up as spam.

          It took me a LONGGG time to realise that’s why I was getting so many false positives with the Spam Destroyer plugin.

          And if the site has a JS bug, it can cause all comments to get picked up as spam.

        • I understand what you’re saying. There are going to be certain cases where JavaScript itself is an issue, but I think it’s going to be a rare exception.

          Just in case, I’m moving the inline JavaScript to use the comment_form hook. If the person can post a comment, the JS is already in place.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: