Puncte:0

PHP Timpul maxim de execuție depășit - semn de atac?

drapel jp

Ne confruntăm astăzi cu o încărcare foarte mare a procesorului pe serverul nostru web. Aplicația noastră a fost înghețată și nu reacție. Am putea reduce sarcina setând timp maxim de execuție de la 180 la 90 de secunde.

Cu toate acestea, fișierele jurnal sunt acum pline de următoarea eroare:

Timpul maxim de execuție de 90 de secunde a depășit {"exception":"[obiect] (Symfony\Component\ErrorHandler\Error\FatalError(cod: 0):

Și aproximativ la fiecare 10 secunde, există o nouă eroare de acest tip în jurnal.

Niciunul dintre formularele și scripturile aplicației noastre nu ar trebui să dureze această perioadă de execuție. Prin urmare, întrebarea mea este dacă acest jurnal de eroare ar putea fi semnul unui atac (de exemplu, DDoS)? În plus, există șansa de a afla adresa IP a clientului care a declanșat eroarea?

drapel us
ar trebui nu este important, ceea ce fac ei este important. SX a fost odată redus de o expresie regex scrisă prost.
arety_ avatar
drapel jp
S-a oprit exact la 12:42 ieri și a continuat astăzi la 7:19. Deci nu pare să fie o problemă cu aplicația în sine.
Nikita Kipriyanov avatar
drapel za
Așadar, ați reîncercat solicitările care cauzează expirarea timpului de execuție PHP, sunt acelea care rulează întotdeauna atât de mult și de ce? Ce îi face să ruleze atât de mult, sunt legați de CPU, de bază de date, orice? Se întâmplă atacuri, în general, cea mai bună strategie este să eliminați URI-urile care se comportă astfel sau să limitați accesul la ele cumva.
Puncte:1
drapel pk

Trebuie să depanați scriptul, să plasați elemente de sincronizare și să adăugați un jurnal de depanare. Mă îndoiesc că este un atac, probabil că este o buclă neprevăzută în scenariu. Am scris scripturi în care o condiție de eroare nu a fost blocată și a creat o buclă neprevăzută. Presupunerea mea educată este că exact asta se întâmplă.

Puncte:1
drapel ru

Cu toate acestea, fișierele jurnal sunt acum pline de următoarea eroare:

I-ai spus PHP să elimine toate scripturile care rulează mai mult de 90 de secunde, așa că asta este ceea ce primești.

Niciunul dintre formularele și scripturile aplicației noastre nu ar trebui să dureze această perioadă de execuție.

Teoria și practica diverg uneori. Ar trebui să depanați serios problema - să identificați scriptul de lungă durată și să aflați de ce face asta - jurnal profund și analiză URL/cookie-uri/anteturi, eventual cu un nivel de jurnal crescut.

Deci nu pare să fie o problemă cu aplicația în sine.

Aceasta este o presupunere foarte periculoasă. Foarte probabil că încă mai are loc un atac.În prezent, ar putea fi încă timp pentru a remedia problema înainte ca atacatorul să găsească cu adevărat o gaură de securitate (încărcarea mare poate provoca condiții de cursă care, la rândul lor, pot deschide bucle). Cel puțin, site-ul dvs. web va primi unele întăriri împotriva DoS.

Puncte:0
drapel us

Având în vedere că aplicația dvs. este perfectă și nu există nicio modalitate de a identifica ce cauzează problema, singura voastră speranță este un serviciu comercial de păstrare a timpului de funcționare precum Akamai sau Cloudflare.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.