Īsi: Drupal PHP drošības jautājumā pēc PHP2Shell galvenais ir serveris: ievainojamība atrodas PHP, nevis Drupal. Pārbaudiet PHP stāvokli statusa pārskatā un pie operatora, pārstartējiet visus PHP procesus un pēc tam kontrolējiet settings.php, direktoriju files un lomu tiesības.
Drupal un PHP2Shell: situācija
Drupal bieži izmanto lielākām vietnēm, portāliem un publiskajām iestādēm, bieži ar daudziem redaktoriem un saskarnēm. PHP ievainojamības CVE-2026-109618 un CVE-2026-109619 saskaņā ar PHP komandu ļauj izpildīt ļaunprātīgu kodu no attāluma bez pieteikšanās. Cik labi uzturēts ir pats Drupal, tam nav nozīmes.
Drupal ir sava drošības komanda, kas publicē norādes par kodolu un moduļiem. PHP2Shell tajās neietilpst, jo tā nav Drupal ievainojamība. Kas seko tikai Drupal norādēm, tāpēc varēja šo ziņojumu palaist garām.
Lielākos Drupal projektos atbildība bieži sadalās starp vairākām pusēm: aģentūra uztur kodu, datu centrs darbina serverus, redakcija atrodas uzņēmumā. Rakstiski noskaidrojiet, kurš ievieš PHP atjauninājumu, kurš izraisa pārstartēšanu un kurš pārbauda, vai iepriekš kaut kas nav noticis. Uzbūvēs ar vairākiem tīmekļa serveriem aiz slodzes balansētāja (load balancer) katram serverim jābūt ielāpotam un pārstartētam, citādi daļa pieprasījumu paliek uz veca PHP.
Drupal PHP drošība: versijas un ielāpa stāvokļa pārbaude
Sadaļā Reports > Status report Drupal rāda PHP versiju, ar kuru vietne darbojas, kopā ar konfigurācijas brīdinājumiem. Komandrindā drush status sniedz CLI PHP versiju, ar kuru darbojas arī cron uzdevumi un izvietošanas (deployments). Abiem jābūt ielāpotiem.
Labotās upstream versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Distributīvi un hostinga sniedzēji labojumus daļēji ievieš kā backport, tad numurs paliek tāds pats; noteicošs ir apstiprinātais pakotnes stāvoklis. Kuras PHP versijas atbalsta jūsu Drupal versija, pārbaudiet pēc sistēmas prasībām vietnē drupal.org. Pēc atjaunināšanas jāveic pārstartēšana, kas aprakstīta sadaļā PHP-FPM un visu worker procesu pārstartēšana.
Direktorijas un faili, kas ir svarīgi
| Vieta | Saturs | Pārbaudes punkts |
|---|---|---|
sites/default/settings.php |
Datubāze, hash salt, trusted_host_patterns |
Izmaiņu datums, ievietoti include |
sites/default/files/ |
Publiskās augšupielādes, ģenerēti attēli, CSS un JS | Nav PHP failu, .htaccess ir klāt |
| Privātā failu direktorija | Aizsargātas augšupielādes, bieži ārpus dokumentu saknes | Piekļuves tiesības |
modules/contrib/, modules/custom/ |
Moduļi no drupal.org un pašizstrādātie | Mainīti vai nezināmi moduļi |
themes/ |
Tēmas ar Twig veidnēm | Svešs JavaScript |
vendor/ |
Composer atkarības | composer audit |
Drupal mapē files izveido .htaccess, kas aizliedz PHP izpildi. Zem Apache tā darbojas, zem Nginx ne. Tur vajadzīgs savs noteikums:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Droši pārbaudes soļi ar sistēmas līdzekļiem un Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Salīdziniet koda stāvokli serverī ar savu Git repozitoriju. Drupal projektos ar Composer tas ir ātrākais veids, kā atrast svešus vai mainītus failus, jo katrai atšķirībai jābūt izskaidrojamai.
Lomas, tiesības un moduļi kā risks
Pieteikšanās atrodas adresē /user/login, pārvaldības apgabals adresē /admin. Drupal drošību nosaka ne tikai administratoru konti, bet arī atsevišķas atļaujas. Tiesības, piemēram, pārvaldīt moduļus, lietotājus, atļaujas vai teksta formātus ar pilnu HTML, praktiski ir administratora tiesības. Sadaļā People un Permissions pārbaudiet, kurām lomām tās ir un kas šīm lomām pieder.
Contrib moduļi Drupal ievērojami paplašina, bet atnes savu kodu. Moduļi bez aktīvas uzturēšanas un veci pašizstrādātie risinājumi bieži ir iemesls, kāpēc PHP jauninājums tiek atlikts. Vairāk par atkarībām lasiet rakstā Composer atkarību pārbaude uz ievainojamībām.
Ko Drupal atjauninājums dod un ko ne
Kodola vai moduļa atjauninājums aizver kļūdas šajā kodā un var ļaut izmantot jaunākas PHP versijas. Tas neielāpo PHP, nenoņem svešus failus no sites/default/files, neatiestata atļaujas un nedzēš slepeni izveidotus kontus. Arī kešatmiņa var turpināt piegādāt manipulētu saturu, līdz tā tiek iztukšota. Aizdomu gadījumā jāmaina hash salt un datubāzes piekļuve.
Multisite instalācijās vairākas vietnes dala vienu kodu, bet zem sites/ katrai ir sava settings.php un sava direktorija files. Tad pārbaudiet katru vietni atsevišķi. Atradums vienā vietnē kopīgā koda dēļ parasti skar arī visas pārējās.
Kā PHP SOS palīdz konkrēti?
- Mēs pārbaudām jūsu Drupal servera tīmekļa un CLI PHP un liekam apstiprināt ielāpu un pārstartēšanu.
- Mēs saglabājam žurnālus un datus un salīdzinām koda stāvokli ar jūsu repozitoriju vai oriģinālajām pakotnēm.
- Mēs kontrolējam
settings.php, direktorijufiles, servera noteikumus, lomas un atļaujas. - Pēc vēlēšanās mēs uzņemamies pastāvīgo uzturēšanu drošības uzturēšanas līgumā, lai PHP un Drupal atjauninājumi atkal nesaietos.
Biežāk uzdotie jautājumi
Vai Drupal drošības atjauninājums palīdz pret PHP2Shell?
Nē. Drupal atjauninājumi aizver kļūdas Drupal kodolā un moduļos. PHP2Shell atrodas servera PHP un prasa PHP atjauninājumu vai apstiprinātu backport, kā arī visu PHP procesu pārstartēšanu.
Kur Drupal rāda PHP versiju?
Statusa pārskatā sadaļā Reports. Ar Drush komanda drush status parāda komandrindas PHP versiju. Abi dati var atšķirties, un backport nevar droši atpazīt ne vienā, ne otrā.
Vai .htaccess mapē files aizsargā arī zem Nginx?
Nē. Drupal izveidoto .htaccess apstrādā tikai Apache. Zem Nginx nepieciešams savs noteikums servera konfigurācijā, kas bloķē PHP failus direktorijā files.
Ko nozīmē trusted_host_patterns?
Iestatījums settings.php nosaka, zem kādiem resursdatora nosaukumiem Drupal atbild. Tas aizsargā pret uzbrukumiem ar manipulētiem Host datiem, un tam jābūt katrā produktīvajā instalācijā.