wordfence_syncAttackData creates high load

My own server, running about 20 installations of WordFence, has roughly logged 750+ wordfence_syncAttackData requests (out of 250K+) in the past 24 hours. I consider that a ‘slow day’ ??

I have no idea how much is too much, of course, but I’d say that having ? of all requests being flagged as wordfence_syncAttackData is way, way too much, and clearly a sign that there is some sort of deliberate attack going on.

BTW, as reported elsewhere, those calls including wordfence_syncAttackData (which come from your own server talking to itself) are simply the mechanism that Wordfence uses to push data into the database. In other words, on the lines before each wordfence_syncAttackData request, you might find the real culprit — before Wordfence detects the (potential) attack and logs it to the database. As that link I’ve posted suggests, you can try to change your Live Traffic settings to ‘Security Only’ — it makes an insane difference! In fact, the concept around Live Traffic is a cute nicety that will almost never be deployed on a real setup, especially one that is being attacked — because it’ll basically kill your database, as Wordfence tries to write each access to the database server — thus magnifying the attack a thousandfold or more, since nginx can easily deal with several orders of magnitude of accesses than MySQL.

In fact, one personal peeve I have with the Wordfence development team is the level of aggressivity they place on the database server. I use nginx as well, and I can say with a reasonable degree of confidence that most of those 250K+ requests do not hit the database at all — except if Wordfence, for some reason, needs to log something about any one of those requests (in my case, as said, it just felt the ‘need’ to log ‘only’ 750 or so requests… which is nothing). I’ve started a few threads on this subject but, unfortunately, I was not quick enough to answer those threads before they were closed… ??

I hoped to have some sort of file-based logging mechanism as an option to the constant hammering on the database, but, alas, I learned that Wordfence really, really needs all those logs at the database level to be able to process them fully. It’s either that or having no security whatsoever.

As for performance increases at the database engine level… MariaDB, the MySQL fork, includes a few extra database engines. I have had reasonable success in using the Aria engine for tables having lots of writes (and lots of accesses in general). The Aria engine is conceptually similar to the old MyISAM engine, in the sense that it’s super-fast (very slightly faster than MyISAM, in fact) and handles big loads well — at the cost of not being transactional (as InnoDB is). However, it includes journaling and data recovery (unlike MyISAM) so that it resists quite well to database or even server crashes. Being a simpler engine, it has fewer configuration variables, so it is not so finicky to fiddle with as InnoDB — which has an endless supply of configuration options. It might be an option for you — because of the unknown future of Oracle’s MySQL, MariaDB has been packaged with the most recent Debian/Ubuntu distros (as well as a few others, of course) as the ‘default’ SQL database engine. It’s 99.9999% compatible with MySQL and works as a drop-in replacement — so if you have a choice there, it may be a good option. If you have to stick with MySQL, then InnoDB is still the best overall engine (that’s why it’s the default one!).

On the other hand, if you have lots of memory to spare, I guess that you could put the Wordfence log tables in the Memory engine… that would certainly increase performance!

Also, unless you really need the massive amount of logs produced by Wordfence, you can decrease the number of lines that get written to the log by changing the Amount of Live Traffic data to store (number of rows) to 100, and the Maximum days to keep Live Traffic data to 5. I actually use even less than that.

Anyway, to resume:

1. Those wordfence_syncAttackData apparently coming from your own server are just the mechanism that Wordfence uses to push data into the database;
2. Having two-thirds of your logs with wordfence_syncAttackData is not normal IMHO;
3. You should check if you have Live Traffic turned on; while useful, it’s an almost-certain database killer; switch to ‘Security Only’ instead and see if it improves things;
4. Reduce Amount of Live Traffic data to store (number of rows) to 100, and the Maximum days to keep Live Traffic data to 5 or even less;
5. If you’re using MariaDB, you might get some performance increase (or at least avoid the highest traffic peaks) by switching some of the most intensely-used tables to the Aria engine.

Good luck…

Thank you for your feedback and suggestions, Gwyneth.
Let me add some more information to my previous post.

1. wordfence_syncAttackData
I think you are right. I notice in the log files, that just before or very close to the lines containg wordfence_syncAttackData I get requests like this: POST /xmlrpc.php HTTP/1.1 and POST /wp-login.php HTTP/1.1. IP Adresses for those requests are changing. Interestingly I also see requests close to that line containing wp-cron like:
"POST /wp-cron.php?doing_wp_cron=1614403548.1214759349822998046875 HTTP/1.1"
followed by:
"POST /?wordfence_syncAttackData=1614403547.8128 HTTP/1.1"
Notice how similar the number in those two requests are.

2. Just to clarify: the wordfence_syncAttackData lines are not 2/3 of my log, but 2/3 of the lines coming from my own IP adress. The log contains much more data.

3. Live Traffic
‘All Traffic’ wasn’t turned on. Just ‘Security Only’.

4. Reduce Amount of Live Traffic
Good idea. I changed that from 2000 rows and 30 days to 100 and 5 as you suggested.

5. MariaDB
I will be switching to a new server soon and I already planed to switch to MariaDB anyways.

Thanks again for your suggestions.

• This reply was modified 4 years ago by devcri.

Hello @devcri and thanks for reaching out!

@gwynethllewelyn Really hit the nail on the head. Excellent suggestions!

As mentioned, wordfence_syncAttackData is usually just a sting added to any sort of visit to your site. Live Traffic generally will generate these.

Thanks again!