Faz sentido, do ponto de vista da segurança, remover o cabeçalho HTTP do servidor?

RFC 7231 diz sobre o cabeçalho do servidor :

Um servidor de origem PODE gerar um campo Servidor em suas respostas.

MAIO é interpretado como na RFC 2119 :

5. MAIO Esta palavra, ou o adjetivo "OPCIONAL", significa que um item é realmente opcional. Um fornecedor pode optar por incluir o item porque um determinado mercado o exige ou porque o fornecedor sente que isso aprimora o produto, enquanto outro fornecedor pode omitir o mesmo item. Uma implementação que não inclua uma opção específica DEVE estar preparada para interoperar com outra implementação que inclua a opção, embora talvez com funcionalidade reduzida. Da mesma forma, uma implementação que inclua uma opção específica DEVE estar preparada para interoperar com outra implementação que não inclua a opção (exceto, é claro, pelo recurso que a opção fornece).

Portanto, não há problema em restringir ou remover o cabeçalho de resposta do servidor. Claro que é uma boa ideia estar ciente do que você pode estar desistindo ao fazer isso. Para isso, volte ao RFC 7231:

O campo de cabeçalho "Servidor" contém informações sobre o software usado pelo servidor de origem para lidar com a solicitação, que geralmente é usado pelos clientes para ajudar a identificar o escopo dos problemas de interoperabilidade relatados, para contornar ou personalizar solicitações para evitar limitações específicas do servidor e para análises relacionadas ao uso do servidor ou do sistema operacional. Um servidor de origem PODE gerar um campo Servidor em suas respostas.

Server = product *( RWS ( product / comment ) )

O valor do campo Servidor consiste em um ou mais identificadores de produto, cada um seguido por zero ou mais comentários (Seção 3.2 de [RFC7230]), que juntos identificam o software do servidor de origem e seus subprodutos significativos. Por convenção, os identificadores de produto são listados em ordem decrescente de significância para identificar o software do servidor de origem. Cada identificador de produto consiste em um nome e uma versão opcional, conforme definido na Seção 5.5.3.

Exemplo:

Server: CERN/3.0 libwww/2.17

Um servidor de origem NÃO DEVE gerar um campo Servidor contendo detalhes desnecessariamente refinados e DEVE limitar a adição de subprodutos por terceiros. Valores de campo de servidor excessivamente longos e detalhados aumentam a latência de resposta e potencialmente revelam detalhes de implementação interna que podem tornar (um pouco) mais fácil para os invasores encontrar e explorar falhas de segurança conhecidas.

Embora, na prática, os invasores realmente não verifiquem o cabeçalho Server:. Eles apenas tentam todas as explorações de segurança que conhecem, independentemente de seu servidor fornecer alguma indicação de estar vulnerável ou não. A remoção do cabeçalho Server: é uma ação de segurança por obscuridade e quase totalmente ineficaz. Mas se isso faz você se sentir melhor, ou se seu chefe ou um auditor lhe disserem para fazer isso, vá em frente. Só não espere que isso resulte em qualquer melhoria significativa em sua postura de segurança.

Por exemplo, nmappode identificar um servidor da Web com precisão razoável, mesmo quando configurado para não enviar nenhum Servercabeçalho ou quando o conteúdo do cabeçalho é completamente falso. Experimente você mesmo com nmap -sV -P0 -p 80,443 <IP address>.

O Servercabeçalho HTTP serve apenas para um propósito - identificação. Não é necessário em nenhum lugar para executar seu site corretamente e, ao removê-lo, nada vai quebrar.

Ele revela a infraestrutura interna do servidor e, portanto, vaza informações de segurança que podem ser úteis para possíveis invasões.

Depois de obter conhecimento do software do seu servidor web, por meio Serverdo cabeçalho HTTP, o intruso em potencial pode pesquisar as vulnerabilidades conhecidas publicamente do seu servidor web. Em seguida, eles podem usar essas informações em conjunto com qualquer outra informação que possam obter (por exemplo, por meio de varredura) - para construir um vetor de ataque adequado.

Assim, você pode querer remover o Servercabeçalho completamente, por exemplo, removê-lo em nginx .

Se você tiver " server_tokens off " em sua configuração (e parece que tem, pois há apenas 'nginx' e não diz 'nginx/1.13.11'), então não há problema em deixar as coisas como estão agora. O problema pode aparecer se você tiver uma versão vulnerável e uma pessoa mal-intencionada pode usar essas informações para explorar a vulnerabilidade, mas para isso seu nginx deve ser acessível publicamente. Então, em poucas palavras, use "server_tokens off"; e não abra a porta nginx para todos os IPs, mas apenas para o Varnish, e você deve estar seguro.