Vai al contenuto 
Sicurezza del gestore PHP determina quanto i siti web siano separati gli uni dagli altri in ambienti condivisi e quali superfici di attacco espone un server web; in un confronto diretto tra FPM e CGI, l'isolamento dei processi, i diritti degli utenti e i limiti rigidi sono i fattori più importanti. Mostro perché l'FPM con pool dedicati riduce il rischio, mentre il CGI classico fornisce un isolamento rigoroso ma genera latenza e carico della CPU a causa degli elevati overhead.
Punti centrali
- Isolamento determina la superficie di attacco e i rischi di cross-account.
- Piscine FPM separare gli utenti, impostare limiti e proteggere le risorse.
- CGI isola fortemente, ma costa CPU e tempo per ogni richiesta.
- OPcache ha bisogno di segmenti di archiviazione separati per ogni account.
- hosting condiviso beneficiano di istanze FPM dedicate.
Come i gestori PHP influenzano la sicurezza
Ogni gestore collega il server web e l'interprete PHP, ma l'interprete Esecuzione mod_php carica PHP direttamente nel processo del server web; questo garantisce velocità, ma condivide lo stesso contesto utente e aumenta il rischio di hosting. CGI avvia un nuovo processo per ogni richiesta sotto l'utente di destinazione, mantenendo i diritti separati, ma con un notevole overhead. FastCGI mantiene i processi in vita e riduce i costi di avvio, ma solo FPM fornisce il controllo preciso richiesto dalle moderne configurazioni multiutente. Preferisco FPM perché consente pool separati, UID separati e limiti rigorosi per account senza perdere efficienza.
FPM vs CGI: la demarcazione della sicurezza nella vita quotidiana
In un confronto diretto, CGI separa rigorosamente, ma FPM continua la separazione. permanente e mantiene bassa la latenza. I pool FPM vengono eseguiti sotto l'utente del rispettivo account, isolano i percorsi e incapsulano le risorse; in questo modo, un exploit nel sito A impedisce l'accesso al sito B. Inoltre, limito l'effetto degli script difettosi con memory_limit, max_execution_time e request_terminate_timeout. Anche se CGI termina ogni processo dopo la richiesta, spreca tempo di CPU avviando e caricando continuamente estensioni. Negli ambienti condivisi predomina quindi FPM, idealmente come pool dedicato per dominio o progetto.
Isolamento nell'hosting condiviso: rischi e rimedi
Negli ambienti condivisi, il più grande Rischio di hosting, quando gli account condividono risorse o diritti in modo non intenzionale. Gli aggressori prendono di mira permessi di file deboli, directory temporanee errate o cache non separate. Con pool FPM dedicati per account, incapsulo i processi, i percorsi dei file, i log e i segmenti OPcache. Inoltre, separo i percorsi di upload e prevengo gli attacchi symlink con opzioni di montaggio restrittive e modelli di proprietario puliti. A più livelli Isolamento dei processi con chroot, CageFS o jails riduce significativamente l'impatto di un'intrusione perché l'attaccante non può raggiungere il sistema host.
Gestione delle risorse: pool, limiti e timeout
FPM guadagna punti perché posso indirizzare le risorse allocare e quindi frenare l'uso improprio. Uso pm.max_children per limitare i processi PHP simultanei, mentre pm.max_requests riavvia i worker a lunga vita dopo X richieste, per evitare perdite di memoria. request_terminate_timeout mette fine ai blocchi che altrimenti occuperebbero la RAM e protegge dagli attacchi di frenata. Per gli upload, ho impostato post_max_size e upload_max_filesize in modo che i normali flussi di lavoro vengano eseguiti, ma i file giganteschi non vengano accettati. In combinazione con i cgroup a livello di sistema per CPU e RAM, l'host rimane reattivo anche durante i picchi di carico.
Prestazioni e sicurezza a confronto
Un confronto diretto tra i manipolatori rivela le differenze pratiche tangibile. Utilizzo la seguente panoramica per prendere decisioni e calibrare le aspettative. I valori descrivono le tendenze tipiche delle configurazioni reali e mostrano perché FPM è la prima scelta negli scenari di hosting condiviso. CGI privilegia la durezza attraverso il riavvio, FPM bilancia isolamento e velocità, LSAPI brilla con gli stack LiteSpeed. Rimane importante: L'isolamento senza limiti è poco utile, così come i limiti senza isolamento.
| gestore | Prestazioni | Sicurezza | Consumo di RAM | Isolamento | Ideale per |
|---|---|---|---|---|---|
| mod_php | Alto | Basso | Basso | Basso | Siti piccoli e semplici |
| CGI | Basso | Alto | Alto | Alto | Test, separazione rigorosa |
| FastCGI | Medio | Medio | Medio | Medio | Fase di transizione |
| PHP-FPM | Molto alto | Alto | Basso | Alto | Hosting condiviso, CMS |
| suPHP | Basso | Molto alto | Alto | Molto alto | Massima sicurezza dei file |
| LSAPI | Molto alto | Medio | Molto basso | Medio | Traffico elevato con LiteSpeed |
Da questa giustapposizione traggo un chiaro ConseguenzaPer l'hosting multiutente, FPM fornisce la migliore sicurezza complessiva per unità di prestazione. CGI rimane un'opzione per casi speciali con massima separazione e poche richieste. Evito mod_php in ambienti con molti clienti. LSAPI merita considerazione quando si usa LiteSpeed e la RAM è estremamente scarsa. Nella maggior parte degli scenari, tuttavia, i vantaggi di pool FPM separati con limiti chiari superano gli svantaggi.
Trappole di configurazione: impostazioni predefinite sicure per gli stack FPM
Molte effrazioni sono causate da Configurazione errata, non attraverso exploit esotici. Due interruttori sono obbligatori per me: ho impostato cgi.fix_pathinfo=0, per evitare l'attraversamento di PATH_INFO, e limitare con security.limit_extensions le terminazioni dell'eseguibile (ad es. .php,.php8,.phtml). Nelle configurazioni di Nginx, verifico che NOME_SCRITTORE è impostato correttamente e nessuna richiesta passa attraverso percorsi arbitrari. Disattivo anche le funzioni usate raramente, come ad esempio eseguire, shell_exec, proc_open e popen tramite disabilitare_funzioni. Non è una panacea, ma riduce significativamente l'effetto di semplici webshell. open_basedir Lo uso in modo molto selettivo: può essere utile, ma porta facilmente a effetti collaterali con lavori CLI, librerie di manipolazione delle immagini o Composer. È meglio una separazione coerente dei percorsi per account e diritti di proprietà puliti.
Isolare correttamente le sessioni, i caricamenti e le directory temporanee.
Comune Percorsi temporali sono un classico per l'escalation dei privilegi. Per ogni pool FPM definisco session.save_path e upload_tmp_dir in una directory specifica per l'account sotto la home, con diritti restrittivi e sticky bit solo se necessario. noexec, nodev e nosuid sui montaggi riducono la superficie di attacco di ulteriori livelli. Per la sessione GC ho impostato session.gc_probability/gc_divisore in modo che i file all'interno dell'account può essere invecchiato e cancellato; rifiuto i bucket di sessione globali per tutti gli utenti. Chiunque utilizzi Redis per le sessioni separa rigorosamente i namespace e assegna credenziali e limiti separati per ogni account. In questo modo si evita che il codice difettoso influisca sulle sessioni di altri progetti.
Progettazione di socket, autorizzazioni e hardening di systemd
I pool FPM comunicano tramite socket. Preferisco Prese UNIX per la comunicazione locale e inserirli in una directory specifica per l'account con 0660 e gruppo adatto. Globale 0666-I socket sono tabù. In alternativa, uso solo TCP con Bind su 127.0.0.1 o su un'interfaccia interna e sui firewall. A livello di servizio systemd in modo affidabile: NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, CapabilityBoundingSet= (vuoto), limiti per MemoryMax, CPUQuota, CompitiMax e LimiteNOFILE. In questo modo si eliminano molti percorsi di escalation, anche se viene colpita una vulnerabilità dell'applicazione Web. Ho anche collocato i pool nelle proprie fette per attutire i rumori dei vicini e far rispettare i budget.
CLI, cron e queue worker: lo stesso isolamento del web
Un frequente Blindspot: php-cli non viene eseguito tramite FPM. Pertanto, avvio i cronjob, gli indicizzatori e i lavoratori delle code esplicitamente come utente dell'account associato e utilizzo un account separato php.ini per progetto (o php_value-), i limiti, le estensioni e le open_basedir-Equivalenti. I lavoratori di coda (ad esempio, quelli dei CMS e dei framework più comuni) ricevono gli stessi budget di RAM/CPU dei processi web, compresa una strategia di riavvio in caso di perdite. Per i lavori ricorrenti, imposto limiti di backoff e di velocità in modo che un importatore di feed difettoso non blocchi l'host. La parità è importante: ciò che è proibito nel pool web non dovrebbe essere improvvisamente permesso nella CLI.
Logging, slowlog e backpressure
La visibilità determina la rapidità con cui riconosco un attacco o una configurazione errata. Per ogni pool, scrivo il mio Registri degli errori e attiva timeout_richiesta_slowlog velluto slowlog, per ottenere tracce di stack per i blocchi. log_limit impedisce che le singole richieste inondino i registri. Con pm.status_path e un endpoint ping, monitoro i processi, i tempi di attesa e l'utilizzo. A livello di server web, imposto Limiti tariffari, limiti al corpo della richiesta e timeout (lettura dell'intestazione e del corpo) per evitare che i backend vengano sovraccaricati in primo luogo. Una base di regole WAF può anche intercettare vettori di attacco banali; tuttavia, è fondamentale che FPM mantenga la superficie di attacco per account ridotta e che i limiti abbiano effetto in modo affidabile.
Separare in modo pulito le versioni e le estensioni multi-PHP
In particolare, nell'hosting condiviso, diversi Versioni PHP in parallelo. Tengo i miei binari FPM, le estensioni e le configurazioni pronte per ogni versione e le lego per conto a. I socket finiscono in directory separate, in modo da evitare che le richieste vengano accidentalmente indirizzate al pool sbagliato. OPcache rimane separata per ogni versione e per ogni account; riconvalida_freq e validare_timestamp a seconda della strategia di rilascio. Sono cauto con il JIT: Raramente accelera i carichi di lavoro tipici di un CMS e aumenta la complessità: disattivarlo è spesso la scelta più sicura e stabile. Carico le estensioni in modo minimale; tutto ciò che non è assolutamente necessario (ad es. pdo_mysql contro i conducenti non utilizzati), rimane all'esterno.
Modello di minaccia: vettori di attacco tipici e influenza dell'handler
In pratica, vedo sempre gli stessi schemi: upload di file con terminazioni eseguibili, deserializzazione insicura, errori di PATH_INFO-Inoltro, inclusione di file locali e trucchi per i link simbolici. FPM non risolve questo problema in modo automatico, ma limita la gammaUn pool compromesso vede solo il proprio spazio dei nomi. Con security.limit_extensions e la corretta configurazione del server web, impedisco che il caricamento di immagini venga interpretato come PHP. Percorsi temporanei e di sessione separati impediscono le sessioni di account incrociati e le corse ai file temporanei. Insieme a permessi di file restrittivi, umask e noexec-Il tasso di successo degli exploit semplici diminuisce sensibilmente.
Diritti sui file, Umask e concetti di proprietà
I file system rimangono un'opzione frequente Vulnerabilità, se i permessi sono impostati in modo errato. Uso umask per regolare i permessi predefiniti, in modo che gli upload non finiscano per essere scrivibili a livello globale. suPHP o FPM con l'assegnazione corretta di UID/GID assicurano che il proprietario dello script corrisponda al proprietario del file. Questo impedisce a un processo di terze parti di modificare i file o leggere i log. Blocco anche i percorsi sensibili, imposto noexec sui montaggi /tmp e riduco la superficie di attacco separando in modo coerente i percorsi di lettura e scrittura.
Utilizzare OPcache in modo sicuro
La cache porta velocità, ma senza una separazione netta crea memoria condivisa Effetti collaterali. Per i pool FPM, mantengo OPcache separata per ogni account, in modo che chiavi e codice non si sovrappongano. Attivo validate_timestamps in modalità di sviluppo e lo abbasso solo in produzione per le distribuzioni stabili, in modo che le modifiche al codice abbiano effetto correttamente. Inoltre, controllo file_cache solo all'interno della home directory dell'account, non a livello globale. Se si usa la memoria condivisa, si dovrebbe usare l'opzione Rischi legati alla memoria condivisa e limitare rigorosamente la visibilità.
Combinazioni di server web: Apache, Nginx, LiteSpeed
La scelta del front-end influenza la latenza, gli handshake TLS e la gestione delle richieste. evidente. Apache con mpm_event si armonizza bene con FPM se keep-alive e proxy buffer sono corretti. Nginx prima di FPM è convincente con le risorse statiche e può spostare il carico, mentre PHP riceve solo percorsi dinamici. LiteSpeed con LSAPI offre costi generali molto bassi, ma rimane legato a un ecosistema diverso. In ogni stack vale quanto segue: separare i pool FPM in modo pulito, definire i limiti, monitorare i log e configurare consapevolmente i livelli di cache.
Irrigidimento: chroot, CageFS e Jails
Oltre ai gestori, l'isolamento del sistema operativo determina la Effetto di un'intrusione. Con chroot, CageFS o Jails, blocco l'account nel proprio universo di file system. Ciò significa che un aggressore perde l'accesso ai file binari dell'host e ai percorsi sensibili dei dispositivi. In combinazione con FPM per account, si crea una difesa a più livelli, efficace anche contro le debolezze dei plugin nei sistemi CMS. Se si desidera confrontare le opzioni, è possibile trovare Confronto tra gestori PHP un valido orientamento per la categorizzazione delle pile.
Contenitori, SELinux/AppArmor e aspettative realistiche
contenitori e framework MAC come SELinux oppure AppArmor completano efficacemente FPM. La containerizzazione aiuta a vincolare le dipendenze per progetto e a limitare l'accesso al file system root. Mantengo le immagini al minimo, rimuovo le funzionalità non necessarie e monto solo le directory realmente necessarie. I profili SELinux/AppArmor limitano le chiamate di sistema e impediscono a un processo di operare al di fuori del suo contesto. Rimane importante: I contenitori non sostituiscono l'isolamento FPM e i permessi dei file puliti: costituiscono un livello aggiuntivo che intercetta gli errori, non sostituisce la base.
Lista di controllo pratica per gli ospiti e le squadre
Nei progetti, inizio con una chiara SequenzaPrima separo gli account dal punto di vista tecnico, poi creo dei pool FPM per dominio. Poi imposto limiti realistici, misuro i picchi di carico e regolo pm.max_children e pm.max_requests. Controllo i permessi dei file, proteggo le directory di upload e rimuovo i permessi di scrittura non necessari. Configuro OPcache per pool in modo che codice, sessioni e cache rimangano isolati. Infine, verifico il failover: simulo blocchi, modelli DoS e situazioni di esaurimento della memoria finché i meccanismi di protezione non funzionano in modo affidabile.
Riassumendo brevemente
Una cosa è certa per me: FPM offre la migliore Equilibrio di sicurezza e prestazioni, soprattutto quando si confrontano fpm e cgi. CGI rimane utile quando la separazione assoluta è prioritaria rispetto alla velocità, ma FPM raggiunge obiettivi di sicurezza simili con un overhead significativamente inferiore. Pool dedicati, limiti rigidi e cache segregate riducono significativamente il rischio di hosting negli ambienti condivisi. Con l'isolamento dei processi, le autorizzazioni pulite per i file e l'utilizzo controllato di OPcache, l'host stabilisce le guardie decisive. La combinazione coerente di questi componenti protegge efficacemente i progetti mantenendo bassi i tempi di risposta.
