0

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?

arety_
  • 103
  • 2
  • 1
    should is not important, what they do is important. SX was once brought low by a badly written regex. – Jasen Nov 24 '21 at 01:18
  • 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. – arety_ Nov 24 '21 at 12:42
  • 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. – Nikita Kipriyanov Nov 24 '21 at 13:10

3 Answers3

1

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.

Zac67
  • 10,320
  • 2
  • 12
  • 32
1

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.

DaBus
  • 51
  • 1
  • 3
0

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.

Jasen
  • 826
  • 6
  • 12