I'm getting massive amounts of attacks from this beastie

Hi,

I started to get the exact same issue, at around the same time. I can first see my “uncached” requests going strangely upward starting around Feb. 11/12 2016. The thing is, I don’t run wordpress on my main site, only one of the subdomains. But I DO run Sovrn ads on the main site (where all the trouble was).

The hosting company couldn’t figure it out.. Thought maybe malware or ddos attack. But things just didn’t stack up. Finally, I found this thread. I pulled all Sovrn ads, and stopped the 404 index redirects. Immediately things began going back to normal. I kept checking the “Visitors” section in cpanel where I could see the weird URL requests. Finally, I blocked the IPs that kept repeating in CloudFlare, and things now seem completely normal.

It’s a shame though because I love Sovrn and I am eager to start running their ads again…

..oh, and my zoneid also matched up to Sovrn ads, at least to the 300×250 that I could see.

olawordpress, you might want to think twice about blocking the IPs. Those are the IPs of your users. They aren’t trying to attack your site. It’s simply that the ad code that’s on your site isn’t executing correctly, likely because of a problem on sovrn’s side.

A better solution is to do something like what dun_edwards did above with your .htaccess file. If you do that, you should be able to run the ads fine and keep your users.

I agree with vhagerty. Yeah, blocking IPs might work well for some DDOS attacks, but the PCs that are “attacking” your server are clients of your website running some buggy ad network code. If you ban their IPs then you are locking your users out of your own website! You need to block the request pattern as opposed to the IPs. The RewriteRule I’ve detailed above has so far worked perfectly for me and I still run Sovrn ads as one of my main ad providers.

Oh, yeah, forgot to mention, I did dun’s redirect as well. Haha, oh, I only blocked 3 IPs (out of a million monthly visitors), and it pained me to do it, but it was the same three triggering the same URL all day long, for multiple days. I don’t know if it was users who left their browsers open or what, but my OCD wanted to clear the logs =D

Btw, I ran a test today and started running one of the ad units again. The requests started again, with a zoneid matching the ad unit. So I pulled it. Didn’t get to see if the resource drain restarted but I was too scared to find out :/

FYI, I alerted sovrn to this problem and this thread so they know this is not just an isolated incident.

I also implemented a similar htaccess fix and that seems to have worked. Our server is no longer maxing out and core dumps are no longer being generated.

I was wrong…core dumps are still being generated. Is anyone else still getting them?

What are they and how does one check? I’m happy to look ~

I’ve notified them as well, a while ago

Core dumps are simply files that have the naming convention of “core.xxxxxx,” where xxxxxx is just a bunch of numbers. You’ll typically find them in your “public_html” directory. To check to see if you have any, all you have to do is go into your cPanel, open up File Manager, then navigate to your public_html directory.

These get generated when your server gets overloaded (like when that sovrn script goes awry) and processes crash. The system will essentially dump everything is has in memory into a file. Thus, the fact that core dump files exist means that something overloaded the server and caused it to crash.

Ah, ok, wow, thanks!
I don’t see any in public_html. Do they get cleared out?
Should be noted though, I stopped running the ads completely Feb. 20. I have it set to AdSense only and since then no issues.
But I did the redirect etc on the same day so it’s hard to pin point which action was the most effective.
I’d be curious if anyone else switched back, if it helped for them?

sovrn would like to acknowledge a defect that was introduced in a software release a few weeks ago and sincerely apologize for any trouble this may have caused. Unfortunately we didn’t have immediate visibility into its existence. It didn’t affect all of our publishers so we struggled to get clear definition of the issue. On Thursday, March 10th our engineering teams implemented a fix, it was deployed to production Friday evening, March 11. Testing over the weekend has concluded the fix to be working.

Yay, great news!
I’ll reinstate the ads asap =D