Entry Process DDOS? Twice in 3 Days

epiz_25072880 (c28.epizy.com) <keddie28.com>

“Account is suspended due to Entry Process Limits.”

This began with a huge spike on EP failures on the afternoon of the 15th, leading to a 24 hr suspension. Shortly before the attack, and when my site came back online, there were a couple database errors, which happens every month or so-- typical burps and farts on the server which go away after a few minutes, so I chalked up the EP spike to changes apparently being made to the servers.

The site was fully operational about an hour after the suspension ended, so I let it go as a temporary glitch, as my site has never been attacked in ten years.

Then another massive spike happened again this morning around 4 AM my time: Same symptoms, same result: 24 hr suspension, which will end tomorrow morning. (see linked image below- both EP attacks are almost identical, except the first one was a larger spike within one hour). As a result, I now consider my site under direct attack.

In the lead-up to this, I’ve made no code changes of any kind in the last few weeks, and those changes were only to html pages. No PHP files have been altered in months. I’ve also made no changes at the Cloudflare level, until this second attack: This morning, I put CF in “Under Attack” mode as a first measure for when the current acct. suspension ends.

I have noticed that some trolls on my forum have been able to circumvent measures I’ve taken to ban them: Their IP ranges have been blocked on CF, via .htaccess, and via the BLOCK IP feature on the IF Control Panel. I suspect they are also behind the DDOS.

My Q: Can anything be done to determine which .php resources they are attacking? What measures can I put in place to block their attacks? What can I do at the infinity account level to identify and solve the problem? Same goes for expert suggestions on changes at the Cloudflare (free acct) level.

My site comes back online at 4AM PST Monday, and I would love to have shields in place which are impervious to these gutless trolls.


“I’m under attack mode” (You already did this)

Nothing really. To do something, you would need .htaccess or PHP. .htaccess did not work, and PHP will only bump and EP usage higher

Follow the guide about Cloudflare, and keep the under attack mode on. Let’s see what happens.



I’ve been reading up on this type of attack, particularly the experiences of others on IF, but I somehow missed the above article.

Thank You- and I’ll definitely be watching for spikes tomorrow. I’m going to bone up on how to decipher Cloudflare’s responses when in ATTACK mode, as I’m hoping they’ll at least log IP ranges of the spike origin, as well as resources being attacked.


I updated the article a bit and added this


I’m not sure that we got the same issues? 4 times suspended in a week.

My site was unsuspended around 4AM, and by the time I woke up (9:30 AM PST) it was already suspended again. I’m getting sick of this.

I’m reading thru OxyDac’s article (above link) but I have no clue how to install a damned thing on CF. So far, the only thing I know to do is turn on the BOT FIGHTS MODE. I’ve also updated my robots.txt file to disallow all bots, but that’s useless because my acct is suspended before I have a chance to ftp the updated file. I’ll also remove my sitemap xml file if/when I ever have a window of opportunity to use ftp on IF again, which is looking doubtful. My site is suspended within minutes of coming back online, so I have no access to tweak anything on IF’s side. My hands are tied, I’m at the will of those conducting the DDOS or the offending bots, and have no tools to even know which it is, much less put up a defense.

1 Like

It looks like your problem is out of the blue and ongoing, such as mine? I have no idea what’s happening, but I don’t think it’s a targeted attack on me right out thin air.

This could be happening to others, I thought it was just my site but I saw other people bring up the issue of their site being suspended due to hitting ep limiti


I’ve implemented OxyDac’s suggestions by installing LogFlare on my CF acct, then adding all the rules he listed on CF. I’m not using WP, so I blocked that altogether. I also blocked several more countries than listed- basically any country from which I’ve seen attacks over the years.

I’ve also edited my robots.txt to block all for the time being, and will overwrite it on the server when the acct/ftp is restored. I’ll also remove all xml sitemaps for the time being.

One upside to this problem is I’m getting a lot more from my free CF acct than I thought possible.


I’ve implemented everything… and more. Your advice, & LogFlare, are a godsend!

Thanks for your tutorial / advice!


I haven’t had any spikes or suspensions since following the recommendations, but what’s with the bizarre charting of EP failures? According to the charts, the facts and numbers vacillate wildly, yet the only constant is that I should apparently still be suspended for too many EP failures.

I recommad to add deflate for gzip your png and jpg files in the htaccess

I think that the server has instructions which extensions will compress to gzip by default and that it cannot be influenced with .htaccess.

so you can’t say for example deflate woff2

in addition the OP uses Cloudflare so CF takes care of that


What’s so strange about the numbers varying? Website traffic is never exactly the same. It would be much more weird if the numbers were the same every time.


Looking at the graphs I posted, the graphs change drastically for the same time period. In other words, 5 drastically different results on five different graphs for the same time period. And, according to the graphs, the attack has shifted from a couple days to a full week. In other words, the graphs are worthless.

I still don’t understand what you think is wrong with the graphs.

Yes, it shows much higher entry process usage. That’s because much higher entry process usage was (likely incorrectly) recorded for your account. The graph shows this information correctly, and help to determine that at some point in time entry process usage went up a lot, which is helpful when debugging issues with the metrics. So the graph is working correctly, as intended and is useful in this way.

And yes, the different limit graphs show different numbers. That’s because they measure different things. Just because one of the metrics is high doesn’t mean all metrics must be high. If they all kinda measured the same thing, we wouldn’t have bothered to record the metrics separately.

So again, what do you suppose is making the graphs worthless?


I suppose you mean it’s helpful for you, but useless for me…? According to the graph, I should have been suspended for the past two weeks, so said graph is of no value to me… correct?

Anyway, it’s a moot point because, false positives or not, my account is again suspended due to a spike in EPs. It happened a couple hours ago, and I see nothing in the LogFlare readout which indicates any such spike.

After all the tweaks i’ve done on cf, none of it helped and i’m again left scratching my head and my ball sac. Am I reading all of this correctly, that my site is not actually getting any such spike in EPs, that it’s a server-wide issue and the false positives will continue to roll in and kill my website because nothing can be done on my end to fix the situation…

I do believe that Ifastnet is aware of this problem (“false positives”) and investigating it. So, it likely won’t be forever. This has been happening to a lot of people and it seems off. Hopefully it is on their side and you did nothing wrong. If so, then it will be fixed, so patience is key here. Accidents unfortunately happen, but Ifastnet still cares enough about Infinityfree to actually fix problems when they arise :slight_smile:


There is an outage topic about this. Please keep the discussion centralized.


Naw, it’s all cool. I wasn’t upset, I was just making sure I was on the right path, because if there was another defense I could employ I didn’t want to be sitting on the sidelines. I believe I may as well turn off DDOS Attack Mode at the CF level, as it is outside the parameters of the issue, and it causes issues of it’s own…

Thx for the link, too.