Lühidalt: Drupali PHP turvalisuse puhul on pärast PHP2Shelli tähtsaim server: turvaauk asub PHP-s, mitte Drupalis. Kontrollige PHP seisu olekuaruandes ja haldaja juures, taaskäivitage kõik PHP protsessid ning vaadake seejärel üle settings.php, kataloog files ja rollide õigused.
Drupal ja PHP2Shell: olukord
Drupalit kasutatakse sageli suuremate veebisaitide, portaalide ja avalike asutuste jaoks, tihti paljude toimetajate ja liidestega. PHP turvaaugud CVE-2026-109618 ja CVE-2026-109619 võimaldavad PHP meeskonna andmetel kahjuliku koodi kaugkäivitamist ilma sisselogimiseta. Kui hästi Drupalit ennast hooldatakse, sealjuures rolli ei mängi.
Drupalil on oma turvameeskond, kes avaldab teateid tuumiku ja moodulite kohta. PHP2Shell nende hulka ei kuulu, sest see ei ole Drupali turvaauk. Kes jälgib ainult Drupali teateid, võis seetõttu teate märkamata jätta.
Suuremate Drupali projektide puhul jaguneb vastutus sageli mitme koha vahel: agentuur hooldab koodi, andmekeskus haldab servereid, toimetus asub majas. Selgitage kirjalikult, kes PHP uuenduse peale paneb, kes taaskäivituse käivitab ja kes kontrollib, kas varem midagi juhtus. Mitme veebiserveriga lahenduste puhul koormusjaguri taga peab iga üksik server olema paigatud ja taaskäivitatud, muidu jääb osa päringuid vanale PHP-le.
Drupali PHP turvalisus: versiooni ja paigataseme kontrollimine
Menüüs Aruanded > Olekuaruanne näitab Drupal PHP versiooni, millega veebisait töötab, koos konfiguratsiooni hoiatustega. Käsurealt annab drush status CLI-PHP versiooni, millega töötavad ka cron-tööd ja juurutused. Mõlemad peavad olema paigatud.
Upstream'i parandatud versioonid on 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Distributsioonid ja majutajad toovad parandused osaliselt sisse tagasiportimisena (backport), siis jääb number samaks; määrav on kinnitatud pakettide seis. Milliseid PHP versioone teie Drupali versioon toetab, kontrollige süsteeminõuete järgi lehel drupal.org. Pärast uuendust kuulub juurde taaskäivitus, mida kirjeldab leht PHP-FPM-i ja kõigi töötajate taaskäivitamine.
Kataloogid ja failid, mis loevad
| Koht | Sisu | Kontrollpunkt |
|---|---|---|
sites/default/settings.php |
Andmebaas, räsisool (hash salt), trusted_host_patterns |
Muutmiskuupäev, sissetoodud include'id |
sites/default/files/ |
Avalikud üleslaadimised, genereeritud pildid, CSS ja JS | PHP faile pole, .htaccess olemas |
| Privaatne failikataloog | Kaitstud üleslaadimised, sageli väljaspool dokumendijuurt | Ligipääsuõigused |
modules/contrib/, modules/custom/ |
drupal.org moodulid ja oma arendused | Muudetud või tundmatud moodulid |
themes/ |
Teemad Twig-mallidega | Võõras JavaScript |
vendor/ |
Composeri sõltuvused | composer audit |
Drupal loob kataloogi files .htaccess'i, mis takistab PHP käivitamist. Apache'i all see toimib, Nginxi all mitte. Seal on vaja oma reeglit:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Ohutud kontrollid sisseehitatud vahendite ja Drushiga:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Võrrelge serveris olevat koodiseisu oma Git-hoidlaga. Composeriga Drupali projektide puhul on see kiireim viis võõraid või muudetud faile leida, sest iga kõrvalekalle peab olema seletatav.
Rollid, õigused ja moodulid riskina
Sisselogimine asub aadressil /user/login, haldusala aadressil /admin. Drupalis ei otsusta turvalisuse üle ainult administraatorikontod, vaid üksikud õigused. Õigused, nagu moodulite, kasutajate, õiguste või täis-HTML-iga tekstivormingute haldamine, on praktiliselt administraatoriõigused. Kontrollige jaotistes Inimesed ja Õigused, millised rollid neid omavad ja kes nendesse rollidesse kuulub.
Contrib-moodulid laiendavad Drupalit tugevalt, kuid toovad kaasa oma koodi. Aktiivse hoolduseta moodulid ja vanad oma arendused on sageli põhjus, miks PHP-upgrade edasi lükatakse. Rohkem sõltuvuste kohta leiate lehelt Composeri sõltuvuste kontroll turvaaukude suhtes.
Mida Drupali uuendus annab ja mida mitte
Tuumiku või mooduli uuendus sulgeb selle koodi vead ja võib võimaldada uuemaid PHP versioone. See ei paiga PHP-d, ei eemalda võõraid faile kataloogist sites/default/files, ei lähtesta õigusi ega kustuta salaja loodud kontosid. Ka vahemälu võib manipuleeritud sisu edasi serveerida, kuni see tühjendatakse. Kahtluse korral tuleb räsisool ja andmebaasi ligipääs uuendada.
Multisite paigalduste puhul jagavad mitu veebisaiti sama koodi, kuid kataloogis sites/ on igaühel oma settings.php ja oma kataloog files. Kontrollige siis iga veebisaiti eraldi. Leid ühes saidis mõjutab ühise koodi tõttu tavaliselt kõiki teisi samuti.
Kuidas PHP SOS konkreetselt aitab?
- Kontrollime teie Drupali serveri veebi- ja CLI-PHP-d ning laseme paigatud ja taaskäivituse kinnitada.
- Varundame logid ja andmed ning võrdleme koodiseisu teie hoidla või originaalpakettidega.
- Kontrollime
settings.php, kataloogifiles, serverireegleid, rolle ja õigusi. - Soovi korral võtame jooksva hoolduse enda peale turvahoolduslepingus, et PHP ja Drupali uuendused enam lahku ei läheks.
Korduma kippuvad küsimused
Kas Drupali turvauuendus aitab PHP2Shelli vastu?
Ei. Drupali uuendused sulgevad vead Drupali tuumikus ja moodulites. PHP2Shell asub serveri PHP-s ja vajab PHP uuendust või kinnitatud tagasiportimist (backport) ning kõigi PHP protsesside taaskäivitust.
Kus Drupal PHP versiooni näitab?
Olekuaruandes menüüs Aruanded. Drushiga näitab drush status käsurea PHP versiooni. Need kaks andmet võivad erineda ja tagasiportimist ei saa kummastki kindlalt ära tunda.
Kas kausta files .htaccess kaitseb ka Nginxi puhul?
Ei. Drupali loodud .htaccess'i töötleb ainult Apache. Nginxi puhul vajate serveri konfiguratsioonis oma reeglit, mis blokeerib PHP failid kataloogis files.
Mida tähendab trusted_host_patterns?
Säte failis settings.php määrab, millistel hostinimedel Drupal vastab. See kaitseb manipuleeritud hostiandmetega rünnakute eest ja kuulub igasse tootmispaigaldusse.