Saltar para o conteúdo 
Segurança do manipulador de PHP determina a intensidade com que os sítios Web são separados uns dos outros em ambientes partilhados e quais as superfícies de ataque que um servidor Web expõe; numa comparação direta entre FPM e CGI, o isolamento dos processos, os direitos dos utilizadores e os limites rígidos são os factores mais importantes. Mostro por que razão o FPM com pools dedicados reduz o risco, ao passo que o CGI clássico proporciona um isolamento rigoroso, mas gera latência e carga de CPU devido a elevadas despesas gerais.
Pontos centrais
- Isolamento determina a superfície de ataque e os riscos entre contas.
- Piscinas FPM separar utilizadores, definir limites e proteger recursos.
- CGI isola fortemente, mas custa CPU e tempo por pedido.
- OPcache precisa de segmentos de armazenamento separados para cada conta.
- hospedagem compartilhada beneficia de instâncias FPM dedicadas.
Como os manipuladores de PHP moldam a segurança
Cada manipulador liga o servidor Web e o interpretador PHP, mas o manipulador Execução O mod_php carrega o PHP diretamente no processo do servidor Web; isto proporciona velocidade, mas partilha o mesmo contexto de utilizador e aumenta o risco de alojamento. O CGI inicia um novo processo por pedido no utilizador alvo, o que mantém os direitos separados de forma limpa, mas com uma sobrecarga notável. O FastCGI mantém os processos vivos e reduz os custos de arranque, mas apenas o FPM fornece o controlo preciso que as configurações multiutilizador modernas exigem. Eu prefiro o FPM porque ele permite pools separados, UIDs separados e limites estritos por conta sem perder eficiência.
FPM vs CGI: demarcação de segurança no quotidiano
Numa comparação direta, a CGI separa estritamente, mas a FPM continua a separação. permanente e mantém a latência baixa. Os pools FPM são executados sob a respectiva conta de utilizador, isolam caminhos e encapsulam recursos; desta forma, uma exploração no site A impede o acesso ao site B. Eu também limito o efeito de scripts defeituosos com memory_limit, max_execution_time e request_terminate_timeout. Embora o CGI termine todos os processos após o pedido, ele desperdiça tempo de CPU ao iniciar e carregar extensões constantemente. Em ambientes partilhados, o FPM predomina, idealmente como um pool dedicado por domínio ou projeto.
Isolamento no alojamento partilhado: riscos e soluções
Em ambientes partilhados, a maior Risco de alojamento, quando as contas partilham recursos ou direitos de forma não intencional. Os atacantes visam permissões de ficheiros fracas, diretórios temporários defeituosos ou caches não separadas. Com pools FPM dedicados por conta, encapsulo processos, caminhos de ficheiros, registos e segmentos OPcache. Também separo os caminhos de upload e evito ataques de links simbólicos com opções de montagem restritivas e modelos de proprietários limpos. Vários níveis Isolamento do processo com chroot, CageFS ou jails reduz significativamente o impacto de uma intrusão, porque o atacante não pode alcançar o sistema anfitrião.
Gestão de recursos: pools, limites e tempos limite
O FPM marca pontos porque posso direcionar os recursos atribuir e, assim, reduzir o uso indevido. Utilizo pm.max_children para limitar os processos PHP simultâneos, enquanto pm.max_requests reinicia os trabalhadores de longa duração após X pedidos para evitar fugas de memória. request_terminate_timeout acaba com as interrupções que, de outra forma, ocupariam a RAM e protege contra ataques de travagem. Para uploads, eu defino post_max_size e upload_max_filesize para que os fluxos de trabalho normais sejam executados, mas arquivos gigantescos não sejam aceitos. Em combinação com cgroups em todo o sistema para CPU e RAM, o host permanece responsivo mesmo durante picos de carga.
Desempenho e segurança numa comparação de números
Uma comparação direta dos manipuladores revela as diferenças práticas tangível. Utilizo a seguinte visão geral para tomar decisões e calibrar as expectativas. Os valores descrevem tendências típicas em configurações reais e mostram por que razão o FPM é a primeira escolha em cenários de alojamento partilhado. O CGI dá prioridade à dureza através do reinício, o FPM equilibra o isolamento e a velocidade, o LSAPI brilha com as pilhas LiteSpeed. Continua a ser importante: O isolamento sem limites é de pouca ajuda, assim como os limites sem isolamento.
| manipulador | Desempenho | Segurança | Consumo de RAM | Isolamento | Ideal para |
|---|---|---|---|---|---|
| mod_php | Elevado | Baixa | Baixa | Baixa | Sítios pequenos e simples |
| CGI | Baixa | Elevado | Elevado | Elevado | Testes, separação rigorosa |
| FastCGI | Médio | Médio | Médio | Médio | Fase de transição |
| PHP-FPM | Muito elevado | Elevado | Baixa | Elevado | Hospedagem partilhada, CMS |
| suPHP | Baixa | Muito elevado | Elevado | Muito elevado | Segurança máxima dos ficheiros |
| LSAPI | Muito elevado | Médio | Muito baixo | Médio | Alto tráfego com LiteSpeed |
Desta justaposição retiro uma clara ConsequênciaPara alojamento multi-utilizador, o FPM oferece a melhor segurança global por unidade de desempenho. O CGI continua a ser uma opção para casos especiais com separação máxima e poucos pedidos. Evito o mod_php em ambientes com vários clientes. O LSAPI merece consideração quando o LiteSpeed é usado e a RAM é extremamente escassa. Na maioria dos cenários, no entanto, as vantagens de pools FPM separados com limites claros superam as desvantagens.
Armadilhas de configuração: predefinições seguras para pilhas FPM
Muitos arrombamentos são causados por Configuração incorrecta, e não através de explorações exóticas. Para mim, dois interruptores são obrigatórios: defino cgi.fix_pathinfo=0, para evitar travessias PATH_INFO, e limitar com security.limit_extensions as terminações executáveis (por exemplo .php,.php8,.phtml). Nas configurações do Nginx, verifico se NOME_DO_SCRIPT está definido corretamente e nenhum pedido passa para caminhos arbitrários. Também desactivei funções raramente utilizadas, como executar, shell_exec, proc_open e popen via desactivar_funções. Isto não é uma panaceia, mas reduz significativamente o efeito de webshells simples. open_basedir Utilizo-o de forma muito selectiva: pode ajudar, mas conduz facilmente a efeitos secundários com tarefas CLI, bibliotecas de manipulação de imagens ou o Composer. Uma separação consistente de caminhos por conta e direitos de proprietário limpos são melhores.
Isolar corretamente as sessões, os carregamentos e os diretórios temporários
Comum Caminhos de temperatura são um clássico da escalada de privilégios. Para cada pool FPM eu defino session.save_path e upload_tmp_dir num diretório específico da conta, abaixo da home, com direitos restritivos e sticky bit apenas quando necessário. noexec, nodev e nosuid nas montagens reduzem a superfície de ataque de outros níveis. Para a sessão GC, defini session.gc_probability/gc_divisor para que os ficheiros dentro de da conta podem ser envelhecidos e eliminados; rejeito baldes de sessão globais para todos os utilizadores. Qualquer pessoa que use o Redis para sessões separa estritamente os namespaces e atribui credenciais e limites separados para cada conta. Isto evita que código defeituoso afecte sessões noutros projectos.
Conceção de sockets, autorizações e reforço do systemd
Os pools FPM comunicam através de sockets. Eu prefiro Soquetes UNIX para comunicação local e colocá-los num diretório específico da conta com 0660 e grupo adequado. Global 0666-sockets são tabu. Alternativamente, eu só uso TCP com Bind on 127.0.0.1 ou numa interface interna e firewalls. Ao nível do serviço systemd de forma fiável: NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=verdadeiro, PrivateTmp=true, CapabilityBoundingSet= (vazio), limites para MemóriaMax, CPUQuota, TarefasMax e LimiteNOFILE. Isto elimina muitos caminhos de escalada, mesmo que uma vulnerabilidade de uma aplicação Web seja atingida. Também coloco os pools nas suas próprias fatias para abafar os vizinhos barulhentos e impor orçamentos.
CLI, cron e queue worker: o mesmo isolamento que na Web
Uma frequência Ponto Cego: php-cli não é executado através do FPM. Por isso, inicio cronjobs, indexadores e queue workers explicitamente como o utilizador da conta associada e utilizo um php.ini por projeto (ou php_value-overrides), os limites, extensões e open_basedir-equivalentes. Os queue workers (por exemplo, de CMS e frameworks comuns) recebem os mesmos orçamentos de RAM/CPU que os processos web, incluindo uma estratégia de reinício em caso de fugas. Para trabalhos recorrentes, defino limites de backoff e de taxa para que um importador de feeds defeituoso não bloqueie o host. A paridade é importante: o que é proibido no pool da Web não deve ser permitido repentinamente na CLI.
Registo, slowlogs e contrapressão
A visibilidade determina a rapidez com que reconheço um ataque ou uma má configuração. Para cada grupo, escrevo o meu próprio Registos de erros e ativar request_slowlog_timeout veludo registo lento, para obter traços de pilha para travamentos. log_limit impede que os pedidos individuais inundem os registos. Com pm.status_path e um ponto final de ping, monitorizo os processos, os tempos de espera e a utilização. Ao nível do servidor Web, defino Limites de taxas, O FPM também pode usar limites de corpo de solicitação e tempos limite (leitura de cabeçalho e corpo) para evitar que os back-ends fiquem sobrecarregados em primeiro lugar. Uma base de regras WAF também pode intercetar vectores de ataque triviais; no entanto, continua a ser crucial que o FPM mantenha a superfície de ataque por conta pequena e que os limites tenham efeito de forma fiável.
Separe de forma limpa versões e extensões multi-PHP
Especialmente no alojamento partilhado, vários Versões PHP em paralelo. Eu mantenho meus próprios binários, extensões e configurações do FPM prontos para cada versão e os vinculo por conta para. As sockets acabam em diretórios separados para que nenhum pedido seja acidentalmente encaminhado para a pool errada. O OPcache permanece separado para cada versão e cada conta; revalidar_freq e validar_carimbos_de_data/hora dependendo da estratégia de lançamento. Eu tenho cuidado com o JIT: Raramente acelera as cargas de trabalho típicas do CMS e aumenta a complexidade - desactivá-lo é frequentemente a escolha mais segura e estável. Carrego extensões minimamente; tudo o que não é absolutamente necessário (por exemplo. pdo_mysql vs. condutores não utilizados), permanece no exterior.
Modelo de ameaça: vectores de ataque típicos e influência do manipulador
Na prática, vejo sempre os mesmos padrões: carregamentos de ficheiros com terminações executáveis, desserialização insegura, ficheiros não limpos PATH_INFO-encaminhamento, inclusão de ficheiros locais e truques de ligações simbólicas. O FPM não resolve isso automaticamente, mas limita o alcanceUm pool comprometido só vê o seu próprio espaço de nomes. Com security.limit_extensions e a configuração correta do servidor web, evito que os uploads de imagens sejam interpretados como PHP. Caminhos separados para temporários e sessões evitam sessões entre contas e corridas de ficheiros temporários. Juntamente com permissões de ficheiros restritivas, umask e noexec-a taxa de sucesso de explorações simples diminui consideravelmente.
Direitos de ficheiro, Umask e conceitos de propriedade
Os sistemas de ficheiros continuam a ser um Vulnerabilidade, se as permissões forem definidas incorretamente. Eu uso umask para regular as permissões padrão para que os uploads não acabem globalmente graváveis. suPHP ou FPM com a atribuição correta de UID/GID garantem que o proprietário do script corresponda ao proprietário do arquivo. Isto impede que um processo de terceiros altere ficheiros ou leia registos. Eu também bloqueio caminhos sensíveis, defino noexec em montagens /tmp e reduzo a superfície de ataque separando consistentemente caminhos de leitura e escrita.
Utilizar a OPcache com segurança
O armazenamento em cache traz velocidade, mas sem uma separação limpa cria memória partilhada Efeitos secundários. Para pools FPM, mantenho o OPcache separado para cada conta, para que as chaves e o código não se sobreponham. Eu ativo o validate_timestamps no modo de desenvolvimento e só o reduzo em produção para implantações estáveis, para que as alterações de código tenham efeito corretamente. Além disso, eu só verifico file_cache dentro do diretório home da conta, não globalmente. Se você usa memória compartilhada, você deve usar o Riscos da memória partilhada e limitar rigorosamente a visibilidade.
Combinações de servidores Web: Apache, Nginx, LiteSpeed
A escolha do front end influencia a latência, os handshakes TLS e o tratamento dos pedidos percetível. O Apache com mpm_event harmoniza-se bem com o FPM se o keep-alive e o buffer de proxy estiverem corretos. O Nginx antes do FPM convence com activos estáticos e pode desviar a carga, enquanto o PHP apenas recebe caminhos dinâmicos. O LiteSpeed com LSAPI oferece despesas gerais muito baixas, mas permanece ligado a um ecossistema diferente. O seguinte se aplica a cada pilha: separe os pools de FPM de forma limpa, defina limites, monitore os logs e configure conscientemente as camadas de cache.
Fortalecimento: chroot, CageFS e Jails
Para além dos manipuladores, o isolamento do sistema operativo determina o Efeito de uma intrusão. Com chroot, CageFS ou Jails, eu bloqueio a conta em seu próprio universo de sistema de arquivos. Isso significa que um invasor perde acesso aos binários do host e caminhos de dispositivos sensíveis. Combinado com o FPM por conta, isto cria uma defesa multi-camadas que também é eficaz contra fraquezas de plugins em sistemas CMS. Se quiser comparar opções, pode encontrar Comparação de manipuladores PHP orientação valiosa para categorizar as pilhas.
Contentores, SELinux/AppArmor e expectativas realistas
contentores e estruturas MAC, tais como SELinux ou AppArmor complementam o FPM de forma eficaz. A contentorização ajuda a ligar as dependências por projeto e a limitar o acesso ao sistema de ficheiros raiz. Eu mantenho as imagens no mínimo, removo capacidades desnecessárias e só monto os diretórios que são realmente necessários. Os perfis SELinux/AppArmor restringem as chamadas de sistema e impedem que um processo actue fora do seu contexto. Isso continua sendo importante: Os contêineres não substituem o isolamento do FPM e as permissões de arquivo limpas - eles formam uma camada adicional que intercepta erros, não substitui a base.
Lista de controlo prática para anfitriões e equipas
Nos projectos, começo por definir claramente SequênciaEm primeiro lugar, separo as contas tecnicamente e, em seguida, distribuo os conjuntos de FPM por domínio. Em seguida, defino limites realistas, meço os picos de carga e ajusto pm.max_children e pm.max_requests. Em seguida, verifico as permissões dos ficheiros, protejo os diretórios de carregamento e removo as permissões de escrita desnecessárias. Configuro o OPcache por pool para que o código, as sessões e os caches permaneçam isolados. Por fim, testo o failover: simulo travamentos, padrões de DoS e situações de falta de memória até que os mecanismos de proteção funcionem de forma fiável.
Brevemente resumido
Para mim, uma coisa é certa: a FPM oferece o melhor Equilíbrio de segurança e desempenho, especialmente quando se compara fpm vs cgi. O CGI continua a ser útil quando a separação absoluta tem prioridade sobre a velocidade, mas o FPM atinge objectivos de segurança semelhantes com uma sobrecarga significativamente menor. Pools dedicados, limites rígidos e caches segregados reduzem significativamente o risco de alojamento em ambientes partilhados. Complementado pelo isolamento de processos, permissões de ficheiros limpas e utilização controlada da OPcache, um anfitrião define as barreiras de segurança decisivas. A combinação consistente destes componentes protege eficazmente os projectos, mantendo os tempos de resposta baixos.
