Sysadmin Paranoid -vs- versão do PHP desatualizada

Question

Como um administrador de sistemas paranóico pode manter-se atualizado com as últimas versões estáveis do PHP? (correções de segurança vêm chegando bem regularmente).

Este é um servidor de produção e, portanto, "quebrar coisas" está assustando meu cara até a morte. O tempo de inatividade para manutenção não é o problema.

Especificamente, estamos executando um recente Suse Enterprise Linux, mas uma resposta genérica ou mais geral é perfeitamente aceitável.

Como você lida com atualizações de segurança para máquinas de produção? O que nós somos tão ignorantes de que esse cara tem tanto medo de usar o gerenciador de pacotes para "atualizar"?

Algum conselho?

    

Answer 1

Eu manejo o PHP da mesma forma que ligo todo o resto: Atualize o ambiente de desenvolvimento (um clone de produção VMWare) primeiro, teste de regressão e, em seguida, promova-o para produção usando os mesmos modelos de implantação que usamos para o VMWare anfitriões. (Se você estiver usando gerenciadores de pacotes para fazer suas atualizações, você usaria os mesmos pacotes).

Como uma camada extra de isolamento, nosso ambiente de produção é composto de hosts redundantes emparelhados, e um host é retirado da rotação de produção para sua atualização e testado completamente antes de passarmos para o host para atualizar seu parceiro.

Como regra geral, as atualizações de segurança são aplicadas assim que as atualizações de correções de bugs não-seguras / não críticas são aplicadas trimestralmente para minimizar o tempo de inatividade.

    

Answer 2

O PHP está na minha lista de coisas para manter atualizado para a versão atual. Eu confio menos que a maioria das coisas.

Em última análise, sua melhor opção é revisar todos os registros de alterações de sua versão atual para o mais recente e ponderar de maneira tangível o risco.

Se você está falando de atualizar versões secundárias, como 5.3.1 a 5.3.2, eu não me preocuparia muito.

Se você estiver atualizando do 5.2.x para o 5.3.x, é provável que você introduza alguns problemas de compatibilidade.

Se você estiver usando pacotes de sistema, normalmente as distribuições não apresentarão atualizações que quebrarão o desempenho existente. O RHEL e o CentOS corrigem versões antigas para correções até que uma versão principal da distribuição seja lançada. Faça os testes para você, normalmente, o que reduz o risco. Eu esperaria que o SuSE enterprise fosse similar.

Para caminhos de atualização, a melhor aposta seria criar um servidor de teste e testar o aplicativo com a versão mais recente antes de atualizar a produção.

    

Answer 3

Outra resposta menos apreciada é criar uma lista de permissões de URLs e recursos permitidos. No Apache, você pode fazer isso combinando os recursos de proxy e reescrever.

Basicamente, você faz duas instalações, uma que possui uma configuração simplificada: Proxy, reescrita e nenhuma execução de código; Qualquer URL "permitido" (com parâmetros, etc) fica com proxy na segunda instalação.

Em seguida, adicione-se à lista de desenvolvedores do PHP e monitore as notas de lançamento com cuidado. Sempre que você vê algo que parece ser uma vulnerabilidade de segurança, você cria um shim na primeira instalação para detectar esse tipo de falha e envia ao usuário um erro.

Em uma configuração como essa, você desejará redirecionar o POST para um filtro (se precisar de POST; alguns sites ficarão bem apenas permitindo POST apenas de alguns endereços IP!) que podem procurar fontes permitidas, e pré-validar tudo.

Essa lista branca é muito demorada para ser configurada, mas para aplicativos essenciais que precisam ser executados por mais tempo do que o tempo de vida estável do PHP (o que parece ser apenas alguns anos), essa pode ser uma excelente maneira de aproveitar a grande número de aplicativos PHP sem obter suas vulnerabilidades também.

    

Answer 4

Além do acima, você pode habilitar rollbacks de pacotes apenas no caso.

Então, se algo der errado na produção que você estava absolutamente certo de que estava funcionando bem no desenvolvimento , você pode pelo menos desfazer a alteração rapidamente antes de solucionar o problema.

Consulte Rollback YUM package para ver um exemplo no Yum. Tenho certeza de que outros sistemas de gerenciamento de pacotes têm semelhantes.

Eu sei que são cintos e cintas e eu concordo com a Warner com lançamentos pontuais. Pequenas mudanças não devem quebrar nada. Pessoalmente, eu não tive nenhum problema em atualizações do PHP, mas é sempre melhor prevenir do que remediar.