Eu tenho um CentOS 7 limpo e padrão instalado e agora (após uma verificação de segurança) quero atualizar os pacotes para corrigir problemas de segurança conhecidos (todos eles têm números CVE e alguns já são antigos).
De alguma forma, o CentOS 7 realmente não se importa com essas questões de segurança (um grande problema também é o PHP, que está travado na versão 5.4, sem nenhuma boa forma de atualização).
Como devo lidar com problemas de segurança no CentOS, além de um simples yum update?
Responder1
Você afirma isso:
Eu tenho um CentOS 7 limpo e padrão instalado e agora (após uma verificação de segurança) quero atualizar os pacotes para corrigir problemas de segurança conhecidos (todos eles têm números CVE e alguns já são antigos).
Não entrar em pânico! A instalação do CentOS 7 está correta.
A realidade é que o CentOS 7 está perfeitamente bem e muitos dos itens que você acredita estarem “sem patch” sãoportado. Ou seja, embora você possa ter versões principais mais antigas de itens como PHP, a equipe do CentOS faz backport dos patches necessários para tornar os pacotes no CentOS 7 tão estáveis e seguros em todos os níveis quanto as versões mais recentes de software empacotado.
Também como desenvolvedor web, eu definitivamentenãoquero estar na “vanguarda” de uma nova versão do PHP. Gosto de manter as coisas estáveis em uma versão conhecida e suportada. E o PHP 5.4 está perfeitamente bem. Muitos sites ainda usam PHP 5.3 (backported) pelos mesmos motivos. Pular para uma versão principal em PHP quebrará mais coisas do que “protegerá” mais sua instalação.
A natureza “duvidosa” das verificações de segurança de sites.
Mas você também menciona uma “verificação de segurança”. O que você quer dizer com “verificação de segurança?” Algumas ferramentas de verificação de segurança baseadas na Web apenas listam todas as falhas que podem encontrar e emitem alertas genéricos de pânico. Muitos desses alertas de pânico são baseados apenas em versões principais como PHP 5.4 sendo mostradas e nada mais.
E a razão pela qual essas varreduras de sites reagem dessa forma é para criarFUD (medo, incerteza e dúvida)naqueles que os utilizam para que os patrocinadores de tal serviço possam, por exemplo, vender a um utilizador em pânico algum serviço online ou produto relacionado com consultoria. Muitas dessas varreduras são úteis até certo ponto, mas você deve realizá-las com cautela.grão forte de sale deveriasempre pesquiseas reivindicações ainda mais se algo lhe interessar.
O problema maior – se você me perguntar – é que de alguma forma o seu servidor estáexpondo a versão exata do PHPPara o mundo. E isso não é um problema do CentOS. Aquilo é umproblema de proteção do servidor. Isso significa que servidores bem protegidos nunca revelam a versão exata do software principal usado para evitar que alguém pense que existe alguma falha.
Meu conselho? Se você fez um yum updatee diz que está tudo atualizado, você está tudo atualizado. Mas, como eu disse, o fortalecimento do servidor é um problema 100% diferente que as verificações de segurança predefinidas parecem nunca resolver. Mas é assim que você pode lidar com esse problema específico do PHP. E o processo é muito fácil.
Protegendo o PHP desabilitando o expose_php.
Primeiro, encontre seu arquivo de configuração do PHP ( php.ini) e abra-o assim; este exemplo está usando nanoum caminho para o arquivo no Ubuntu, mas o conceito é o mesmo:
sudo nano /etc/php5/apache2/php.ini
Agora faça uma busca nesse arquivo pela linha que configura o arquivo expose_php. Olhando paraa documentação oficial do PHP, expose_phpé descrito a seguir:
Expõe ao mundo que o PHP está instalado no servidor, o que inclui a versão do PHP dentro do cabeçalho HTTP (por exemplo, X-Powered-By: PHP/5.3.7).
Sabendo disso, aposto que a verificação de segurança apenas viu o X-Powered-Bycabeçalho e reagiu. Mas qualquer pessoa que faça administração de segurança real pode dizer que o problema não é o número da versão em si, mas o fato de queo cabeçalho está exposto. Então basta alterar esse expose_phpvalor da seguinte forma:
expose_php = Off
E então reinicie o Apache e tente a verificação de segurança novamente. Caramba, você pode até verificar os cabeçalhos do seu servidor na linha de comando usando curlassim:
curl -I example.com
Os cabeçalhos retornados devem agoranãocontém qualquer informação de número de versão do PHP.
Endureça o Apache enquanto você faz isso.
Contanto que a segurança seja uma preocupação, eu recomendaria fortalecer o Apache também enquanto você estiver fazendo isso. Basta abrir este arquivo de configuração do Apache; novamente baseado no Ubuntu, mas encontre o equivalente no CentOS:
sudo nano /etc/apache2/conf.d/security
Em seguida, localize ServerTokense defina para “produção” assim:
ServerTokens Prod
Depois disso, localize ServerSignaturee desative-o:
ServerSignature Off
Por fim, localize TraceEnablee desative isso também:
TraceEnable Off
Reinicie o Apache e verifique os cabeçalhos – ou verifique a segurança do servidor – novamente. Agora você deve estar em melhor forma.
O conceito básico dessas ideias simples de proteção é um site configurado com uma configuração padrão que expõe os internos para o mundo, envia uma mensagem aos bots de malware de que um, o servidor está em um estado padrão e dois, o servidor está rodando “mais antigo” Programas. Portanto, um servidor não protegido como esse seria um bom alvo para um ataque. Ao ofuscar detalhes nos cabeçalhos retornados, você torna seu servidor um alvo menos desejável, pois não há como um script dizer a que você pode estar vulnerável.
Responder2
O que faz você pensar que o CentOS não se importa com essas questões de segurança? O backport do Redhat (e, portanto, do CentOS) muda, então é totalmente provável que eles tenham backportado problemas de segurança conhecidos para seus problemas.
No que diz respeito ao PHP, você pode adicionar oRepositório Webtáticopara obter PHP5.6.