Existe algum motivo para manter o cabeçalho de resposta "Servidor" no Apache

16

Meu servidor responde com Server: Apache/2.2.15 (CentOS)todos os pedidos. Acho que isso abre mão da arquitetura do servidor, facilitando as tentativas de invasão.

Isso é útil para um navegador da web? Devo mantê-lo?

apache-2.2 http-headers Nic Cottrell
fonte
Obviamente, também estou mantendo meus servidores atualizados com o yum-cron!
Nic Cottrell

Respostas:

16

Na minha opinião, é melhor mascarar isso o máximo possível. É uma das ferramentas que você usa para invadir um site - descubra sua tecnologia, use as falhas conhecidas dessa tecnologia. A mesma razão pela qual as práticas recomendadas de segurança já começaram a promover URLs no formato "/ view / page" em vez de "/view/page.jsp" ou "/view/page.asp" ... então a tecnologia subjacente não seria exposto.

Há algumas discussões sobre isso, como /programming/843917/why-does-the-server-http-header-exist e http://www.troyhunt.com/2012/02/shhh- dont-let-your-response-headers.html e, obviamente, o livro Hacking Exposed.

Também isso no Security SE /security/23256/what-is-the-http-server-response-header-field-used-for

Mas lembre-se de que isso não é tudo para proteger seus servidores. Apenas mais um passo na direção certa. Não impede que nenhum hack seja executado. Apenas torna menos visível o que o hack deve ser executado.

ETL
fonte
6
Remover extensões de nome de arquivo em URLs não tem nada a ver com segurança ... é mais legível para humanos. Existem milhares de outras maneiras pelas quais sua plataforma de aplicativos é revelada.
213 Brad
Se o servidor estiver configurado corretamente, revelar a plataforma ao invasor não quer ajudá-lo.
Cthulhu
19

Você pode alterar o cabeçalho do servidor, se quiser, mas não conte com isso por segurança. Somente manter-se atualizado fará isso, pois um invasor pode simplesmente ignorar o cabeçalho do servidor e tentar todas as explorações conhecidas desde o início dos tempos.

A RFC 2616 declara, em parte:

Os implementadores de servidor são incentivados a tornar esse campo uma opção configurável.

E o Apache fez, com a ServerTokensdiretiva. Você pode usar isso se desejar, mas, novamente, não pense que isso vai impedir magicamente que você seja atacado.

Michael Hampton
fonte
4
+1 Meus logs estão cheios de "ataques" para software que não está instalado. Os hackers apenas jogam tudo o que têm e veem o que fica. Se houver algum utilitário para alterar os ServerTokens, é insignificante na melhor das hipóteses.
Chris S
@ChrisS Indeed. Eu nem me incomodo; Eu mantenho meus servidores da Web atualizados.
Michael Hampton
3
Eu meio que discordo. Embora possa ser pequena, a segurança nunca é forte o suficiente, e qualquer coisa que possa ajudar sem causar falhas ou diminuir o desempenho deve ser aplicada.
Mveroone 6/03/14
2
Por que informações sobre a versão voluntária? Eu sempre defino "ServerSignature Off" e "ServerTokens Prod". Concorde também que manter os servidores da Web atualizados é a única proteção real. Se você não remover as informações da versão e enviar para um teste de penetração de terceiros, elas sinalizarão isso como "Vazamento de informações".
HTTP500
@ HTTP500 Lido regularmente com a conformidade com o PCI-DSS. Este não é um problema completo, desde que você esteja corrigido. O problema é quando vazam informações sobre outras partes do sistema (ou seja, posso dizer que o OP está executando o CentOS 5.x) ou você não se manteve atualizado.
Michael Hampton
2

Mostrar a string completa, com informações da versão, pode aumentar o risco de ataques com 0 dia de duração, se o invasor estiver mantendo uma lista de quais servidores executam qual software.

Dito isto, você não deve esperar que ocultar uma sequência de servidores o proteja contra tentativas de hackers. Existem maneiras de imprimir um servidor com base na maneira como as respostas e os erros são relatados.

Desabilito minhas cordas o máximo que posso, mas não me importo com as que não posso esconder (por exemplo, OpenSSH).

Dan
fonte