Join Log in
Score:0
arety_ avatar Server

PHP Maximum execution time exceeded - sign of attack?

jp flag
arety_

We were facing a very high CPU load on our web server today. Our application was freezing and not reaction. We could reduce the load by setting the maximum execution time from 180 to 90 seconds.

However, the log files are now full of the following error:

Maximum execution time of 90 seconds exceeded  {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\FatalError(code: 0):

And about every 10 seconds, there is a new error of this type in the log.

None of our application's forms and scripts should take this amount of execution time. Therefore my question is, if this error logs could be the sign of an attack (e.g. DDoS)? In addition, is there a chance to find out the IP address of the client that triggered the error?

88
0 + 0
php
us flag
Jasen
should is not important, what they do is important. SX was once brought low by a badly written regex.
1
Reply
arety_ avatar
jp flag
arety_
It stopped exactly at 12:42 yesterday and continued today at 7:19. So it doesn‘t seem to be a problem with the application itself.
0
Reply
Nikita Kipriyanov avatar
za flag
Nikita Kipriyanov
And so, did you retried the requests which cause PHP execution timeout, are those really always run that long and why? What makes them to run that long, are they CPU-bound, database-bound, whatever? Attacks happen, in general your best strategy is to eliminate URIs which behave like this, or limit access to them somehow.
0
Reply
Score:1
DaBus avatar Server
pk flag
DaBus

You have to debug the script, place timing elements and add to some debug log. I doubt its an attack, its probably some loop, in the script that was unanticipated. I have written scripts where an error condition was not trapped and created an unanticipated loop. My educated guess, is that is exactly what is going on.

0 + 0
Score:1
Zac67 avatar Server
ru flag
Zac67

However, the log files are now full of the following error:

You've told PHP to kill all scripts that run longer than 90 seconds, so this is what you get.

None of our application's forms and scripts should take this amount of execution time.

Theory and practice sometimes diverge. You should seriously debug the problem - pinpoint the long-running script and find out why it's doing that - deep log and URL/cookies/headers analysis, possibly with increased log level.

So it doesn‘t seem to be a problem with the application itself.

That is a very dangerous assumption. Quite possibly there's an attack still going on. Currently, there might still be time to fix the problem before the attacker actually finds a security hole (high load can cause race conditions which in turn can open loop holes). At the very least, your website will get some hardening against DoS.

0 + 0
Score:0
avatar Server
us flag
Jasen

Given that your application is perfect and there's no way to idenfify what is causing the problem your only hope is a commecrial uptime preservation service like Akamai or Cloudflare.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.