1. alex

    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.


    • Jeffr0

      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.


      • Chris Finke

        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.)


      • Ryan Hellyer

        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.


    • mark k.

      “option instead of decision” is not going to happen in core, so kinda pointless to kick that dead horse any longer.


    • Paul

      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. Philip John

    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.


    • Jeffr0

      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.


      • mark k.

        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. RT Cunningham

    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.


    • Julie @Niackery

      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…


  4. Manny Costa

    I always recommend to WP site owners and super admins to go over this checklist often:



  5. mark k.

    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?


  6. Martha

    Here is a link to a plugin that I use https://wordpress.org/plugins/wp-cerber/ . I don’t know if this is exactly what you are wanting but it protects against brute force attacks and shows you how many and where they are coming from and it is user-friendly.


  7. Andy W

    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.


    • mark k.

      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.


      • alex

        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.


        • mark k.

          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.


        • alex


          “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.


          • mark k.

            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?


        • alex

          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.


          • mark k.

            “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.


      • Andy W

        @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.


        • mark k.

          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. VC

    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. djsteveb

    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)


    • alex

      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. Summer

    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. Paul

    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. RT Cunningham

    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.


Comments are closed.

%d bloggers like this: