cPanel hiba okozta a rejtélyes 500-as szerverhibákat
Ismert cPanel hiba HTTP 500 válaszokat okozhat
Egy production cPanel szerveren végzett hibakeresés során olyan problémával találkoztunk, amely első pillantásra szerverterhelésnek, PHP-FPM problémának vagy Apache backend hibának tűnt. A monitoring időszakosan HTTP 500 hibákat és cPanel backend problémákat jelzett, miközben a szerver szolgáltatásainak jelentős része megfelelően működött.
A részletes naplóelemzés végül megmutatta, hogy egy ismert cPanel hiba áll a háttérben. Egy nem létező statikus fájl lekérése a cPanel saját 404-kezelésén keresztül belső lock- és jogosultsági hibához vezetett, amelynek eredménye HTTP 500 válasz lett.
Egy nem létező fájlt kerestek a scannerek
A cPanel access logjának vizsgálatakor feltűnt, hogy nagyszámú különböző IP-cím ugyanazt a fájlt próbálta elérni:
/unprotected/json-minified.js.map
A szerveren létezett a json-minified.js JavaScript fájl, a hozzá tartozó .map állomány azonban nem.
A JavaScript fájl végét is ellenőriztük, de nem tartalmazott olyan sourceMappingURL hivatkozást, amely miatt egy normál böngészőnek ezt a fájlt automatikusan le kellett volna töltenie.
Ez alapján egyértelművé vált, hogy külső automatizált scannerek próbálják közvetlenül lekérni a nem létező állományt.
Normál működés mellett egy ilyen kérésnek egyszerű HTTP 404 válasszal kellene lezárulnia.
Nálunk azonban HTTP 500 érkezett.
A cPanel saját 404 kezelése futott hibára
A cPanel error_log állományában ugyanabban az időpontban a következő hiba jelent meg:
safelock: Failed to create a lockfile
'/var/cpanel/cache/404/webmaild.lock'
Permission denied
A cPanel ezt követően ismételten megpróbálta megszerezni a lockot, majd végül FileCreateError kivétellel állt le.
A stack trace egyértelműen megmutatta, hogy a folyamatot a nem létező json-minified.js.map fájl lekérése indította el.
Közvetlenül ezután a cPanel már HTTP 500 Internal Server Error választ naplózott.
A naplók időbélyege alapján tehát egyértelmű kapcsolat volt a külső kérés, a cPanel 404-kezelése, a webmaild.lock jogosultsági hiba és az HTTP 500 válasz között.
A cPanel CPANEL-53195 azonosítóval tartja nyilván a hibát
Az esetet jeleztük a cPanel Technical Support számára.
A cPanel megerősítette, hogy a /var/cpanel/cache/404/webmaild.lock körüli probléma már ismert, és a fejlesztőknél CPANEL-53195 azonosítóval nyitott hibajegy tartozik hozzá.
A support tájékoztatása szerint a probléma okát továbbra is vizsgálják, és jelenleg nincs megadott pontos javítási verzió vagy biztos kiadási időpont.
Az esetet végül magasabb szintű technikai vizsgálatra is továbbították.
A legfrissebb RELEASE frissítés sem oldotta meg
A vizsgált szerveren eredetileg cPanel 136.0 build 37 futott.
A rendszert frissítettük az elérhető újabb RELEASE verzióra, a 136.0 build 38-ra.
A frissítés megfelelően lefutott, a szolgáltatások elindultak, és a webszerver is normálisan működött.
Rövid időn belül azonban ismét megjelent ugyanaz a webmaild.lock Permission denied hiba.
Ez alapján a probléma a 136.0.38 buildben is reprodukálható maradt.
Az HTTP 500 nem PHP-FPM túlterhelésből keletkezett
A hibakeresés során felmerült annak lehetősége is, hogy az HTTP 500 válaszokat a cPanel PHP-FPM max_children limitjének elérése okozza.
A rendelkezésünkre álló naplók azonban ennél sokkal pontosabban megmutatták a folyamatot.
Ugyanabban a másodpercben látható volt a nem létező fájl lekérése, a webmaild.lock Permission denied hiba, a cPanel FileCreateError kivétele, majd az HTTP 500 válasz.
Ez alapján nem tartottuk indokoltnak, hogy bizonyíték nélkül PHP-FPM limiteket kezdjünk módosítani egy production szerveren.
Elosztott scannerek több különböző IP-címről érkeztek
Az access log további vizsgálata során kiderült, hogy ugyanazt az URI-t sok különböző IP-címről kérik le.
A forráscímek folyamatosan változtak, miközben a lekért útvonal és sok esetben a User-Agent is azonos volt.
Ez tipikus elosztott scanner működésre utalt.
Ilyen helyzetben az egyszerű IP-alapú védelem nem feltétlenül elegendő. Ha egyetlen IP-cím több száz kapcsolatot nyit, azt connection limit vagy L7 rate limiter segítségével viszonylag egyszerű megfogni.
Ha azonban több száz különböző IP egyenként csak egy vagy két kérést küld, egyik cím sem lépi át az egyedi limiteket.
Nem az IP-címeket kezdtük egyenként tiltani
A különböző cloud és hosting szolgáltatók címeinek egyenkénti blokkolása nem jelentett volna életszerű megoldást.
A kérések közös pontja nem az IP-cím volt, hanem maga az URI:
/unprotected/json-minified.js.map
Ezért olyan védelmet kerestünk, amely ezt a konkrét kérést még azelőtt megállítja, hogy az elérné a cPanel cpsrvd hibás 404-kezelési útvonalát.
ModSecurity szabállyal kerültük meg ideiglenesen a hibát
A szerveren egy célzott ModSecurity szabályt helyeztünk el, amely kizárólag a problémát kiváltó URI-t kezeli.
A szabály közvetlenül HTTP 404 választ ad a kérésre, így az már nem jut el a cPanel problémás 404-cache mechanizmusáig.
A konfigurációt Apache configtest segítségével ellenőriztük, majd graceful reload után ismét lefuttattuk ugyanazt a kérést.
A workaround után HTTP 500 helyett HTTP 404 érkezett
A módosítás után ugyanaz a lekérés már megfelelő választ adott:
HTTP 404
Ezt követően újra ellenőriztük a cPanel error logot, és nem keletkezett új webmaild.lock vagy cpaneld.lock Permission denied hiba.
A korábbi folyamat lényegében így nézett ki:
külső scanner
→ cpsrvd
→ cPanel 404 cache
→ safelock
→ Permission denied
→ HTTP 500
A célzott ModSecurity védelem után:
külső scanner
→ ModSecurity
→ HTTP 404
A problémás cPanel kódrészlet tehát már nem futott le.
Nem módosítottuk a cPanel belső könyvtárainak jogosultságait
A hibaüzenet alapján egyszerű megoldásnak tűnhetne a /var/cpanel/cache/404 könyvtár jogosultságainak módosítása.
Production környezetben azonban ezt nem tartottuk megfelelő megoldásnak.
A cPanel saját belső könyvtárstruktúrájáról van szó, amelynek jogosultságait maga a rendszer kezeli. Egy gyors chmod vagy tulajdonosváltás ugyan eltüntethet egy konkrét hibaüzenetet, közben azonban biztonsági vagy későbbi frissítési problémákat hozhat létre.
Mivel maga a cPanel is ismert hibaként tartja nyilván az esetet, sokkal biztonságosabb volt a kiváltó kérést célzottan kezelni.
A végleges javítást a cPanel fejlesztőitől várjuk
A jelenlegi ModSecurity szabály működő workaround, de nem tekinthető végleges javításnak.
Egy szerveradminisztrációs rendszernek egy nem létező statikus fájl lekérésére normál HTTP 404 választ kell adnia. Egy külső, hitelesítés nélküli kérés nem vezethet belső lock permission hibához és HTTP 500 válaszhoz.
A CPANEL-53195 végleges megoldását ezért továbbra is a cPanel fejlesztőitől várjuk.
A logok pontos összerakása sokszor fontosabb, mint a gyors konfigurációmódosítás
Ez az eset ismét jó példa arra, hogy egy HTTP 500 hiba önmagában még nem mondja meg a valódi okot.
Lehet PHP hiba, erőforrás-limit, webszerver-probléma, backend kapcsolat, jogosultsági probléma vagy akár egy szoftverhiba is.
A megfelelő diagnózishoz ebben az esetben a konkrét HTTP kérés, a cPanel stack trace, az időbélyegek és a szerver access logjának összevetése vezetett el.
Nem kellett találomra PHP limiteket emelni, Apache-ot újraindítani vagy több száz IP-címet manuálisan blokkolni.
A hibát kiváltó folyamat pontos azonosítása után egy célzott ideiglenes védelemmel sikerült stabilan megkerülni a problémát addig, amíg a cPanel elkészíti a végleges javítást.
Az esetet a cPanel közösségi fórumán is dokumentáltuk
A hibát és a vizsgálat során összegyűjtött technikai bizonyítékokat angol nyelven a cPanel hivatalos közösségi fórumán is dokumentáltuk.
A fórumon közzétett bejegyzés részletesen bemutatja, hogyan képes egy külső kérés a CPANEL-53195 hibán keresztül HTTP 500 választ kiváltani, valamint azt is, milyen ideiglenes ModSecurity megoldással sikerült megakadályozni a probléma ismételt előidézését.
A teljes angol nyelvű technikai dokumentáció a cPanel közösségi fórumán olvasható.