Gunicorn: Capacidade de mascarar o atributo do servidor do cabeçalho de resposta http

Normalmente o gunicorn é implantado atrás de um servidor proxy reverso como o nginx no ambiente de produção, e o nginx produziria sua própria tag Server .

upstair plus one

com @benoitc podemos propor uma opção na linha de comando, o que você acha? caso contrário, fecharemos este tíquete conforme explicado por @georgexsh , no modo de produção, você pode usar um proxy reverso (nginx, apache, ...).

Não se poderia simplesmente modificar o ambiente em um gancho post_request ?

@tilgovi isso funcionaria, eu acho ... não tenho certeza se precisamos criar outra opção ...

Não funciona. A solicitação já foi enviada nesse ponto.

O middleware Server está nos cabeçalhos padrão.

E se apenas removermos o cabeçalho do servidor por completo?

+1

Se permitirmos que você defina o valor do cabeçalho como uma string aleatória, também devemos permitir que você remova o cabeçalho completamente.

+1

por que você quer remover o cabeçalho?

No passado, removi o cabeçalho das implantações para ocultar o software e a versão do servidor, para que não seja detectado por alguém que está procurando servidores com um exploit conhecido.

Sim. A segurança é um dos motivos. Claro, você pode alterar o Server para algo aleatório, mas por que enviar bytes extras que não são realmente necessários?

Tomei a liberdade de fazer um PR para este recurso: # 1384. Está na minha lista de procurados há algum tempo.

Para adicionar à discussão: Eu diria que enquanto alguns servidores proxy reverso modificam o cabeçalho Server , alguns adicionam um cabeçalho Via conforme descrito em https://www.w3.org/Protocols/ rfc2616 / rfc2616-sec14.html # sec14.38

Infelizmente, @mathiasverhoeven fechou seu RP por algum motivo e não teve atividade recentemente.

Seria impossível ter uma opção mais genérica aqui, como em --set-headers onde você pode especificar qualquer quantidade de cabeçalhos como pares de valores-chave? O valor vazio omitiria o cabeçalho completamente.

No momento, gostaria de ajustar Server , mas também gostaria de adicionar mais um cabeçalho de resposta, por exemplo, X-Product: MyProduct .

Posso lançar algo com base no PR de @mathiasverhoeven . @benoitc e @tilgovi o que você acha?

Vou deixar aqui: https://www.fastly.com/blog/headers-we-dont-want. Como você pode ler no artigo, o cabeçalho Server é muito comum E completamente desnecessário.

Também gostaria de omitir o cabeçalho do servidor. Eu uso um servidor da web com foco em segurança chamado Hiawatha para reverter o proxy, configurado para não adicionar um cabeçalho de servidor próprio, portanto, o cabeçalho de servidor do gunicorn está sendo disponibilizado para os clientes.

A ideia de @tuukkamustonen parece boa para mim. :)

Editar: acabei de ver https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string seria ótimo.

Alguém executando o Flask? https://stackoverflow.com/a/46858238/452210 sugere envolver e substituir process_response , substituir ou remover o cabeçalho.

Também gostaria de omitir o cabeçalho do servidor. Eu uso um servidor da web com foco em segurança chamado Hiawatha para reverter o proxy, configurado para não adicionar um cabeçalho de servidor próprio, portanto, o cabeçalho de servidor do gunicorn está sendo disponibilizado para os clientes.

Percebi que até mesmo o cloudflare exibe um cabeçalho de servidor, então não tenho certeza atualmente de como isso é mais uma questão de segurança do que de fama.

Acho que, em vez de adicionar outra opção à linha de comando ou configuração, eu simplesmente removeria a versão do cabeçalho para começar. Em seguida, adicione uma definição apenas do arquivo de configuração para remover o server_token. A vantagem disso é que a atualização do servidor para a nova versão será capaz de adicionar essa configuração sem interromper o serviço. Pensamentos?

Percebi que até mesmo o cloudflare exibe um cabeçalho de servidor, então não tenho certeza atualmente de como isso é mais uma questão de segurança do que de fama.

Acho que o serviço e o cabeçalho do servidor da Cloudflare tem um contexto diferente do servidor de um site individual. Quando um site é submetido a proxy reverso via Cloudflare, o fato de que é o Cloudflare que está fazendo o proxy não é desconhecido; é aparente por meio de servidores de nomes e / ou endereço IP, etc. Em contraste, eu hospedar um site em um VPS sem nenhum proxy reverso de terceiros potencialmente me dá alguma esperança de evitar pelo menos a identificação direta via cabeçalho HTTP do software do servidor. (O pensamento é, é claro, que se no futuro for descoberto que gunicorn tem alguma vulnerabilidade, encontrar alvos deve ser mais difícil do que simplesmente pesquisar seu cabeçalho de servidor.)

Acho que, em vez de adicionar outra opção à linha de comando ou configuração, eu simplesmente removeria a versão do cabeçalho para começar. Em seguida, adicione uma definição apenas do arquivo de configuração para remover o server_token. A vantagem disso é que a atualização do servidor para a nova versão será capaz de adicionar essa configuração sem interromper o serviço. Pensamentos?

Isso seria bom. : +1:: ligeiramente_smiling_face:

Sim, pelo menos remova a versão. A versão não adiciona nada à fama e economiza muito tempo para os invasores.

Estou pensando apenas em remover a versão. @tilgovi alguma opinião sobre isso?

Por mim tudo bem!

Algum progresso neste? Esta parece uma vitória rápida para a segurança.

isso fará parte dos próximos 20.1

Estou pensando apenas em remover a versão.

A definição de apenas arquivo de configuração para remover o cabeçalho do servidor ainda está planejada?

@DavidOliver por que a pergunta?

@benoitc Seu comentário que citei pode ser interpretado como significando que é "apenas" / apenas o número da versão que será removido, enquanto no início da conversa a configuração para remover o cabeçalho do servidor por completo (o que eu gostaria de fazer) era sendo considerado.

Obrigado.

Se pudermos apenas remover o cabeçalho do servidor por completo, devemos fazer isso.

Eu ainda tenho que estar convencido de que removê-lo tem algo a ver com o
segurança. Não tem sido um problema nos últimos 10 anos. Segurança por
obscuridade também não ajuda, eu prefiro saber que temos um problema e
consertá-lo. Também conhecer o servidor pode ajudar nas operações

Estou inclinado a remover a versão no momento, pois esta versão está fornecendo
muitas informações sobre como o servidor é mantido. Devíamos fazer isso por
cada filial que mantivemos.

Pensamentos?

Benoît

No domingo, 29 de dezembro de 2019 às 04:23 Randall Leeds [email protected] escreveu:

Se pudermos apenas remover o cabeçalho do servidor por completo, devemos fazer isso.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHYW27Q#issuecomment-569470334 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

Enviado do meu celular

Oi,

Estou usando o gunicorn para fornecer respostas em uma conexão onde os dados
é caro, tudo o que posso remover é tudo o que não tenho que pagar.

O cabeçalho do servidor é pequeno, mas pequenas coisas se somam e, às vezes,
pequenas coisas significam que você pode colocar tudo em um pacote a menos: o
o cabeçalho do servidor com a versão é de 24 bytes, cerca de 1,7% da carga útil
com um MSS de 1460 e cabeçalhos TLS. Mesmo sem o pacote extra,
um pacote maior tem muito mais probabilidade de precisar ser totalmente reenviado
quando a conexão é ruim (como uma rede celular em um local remoto).

Em uma nova conexão HTTPS, o handshake e o certificado
troca faz a maior parte da carga útil e pequenas coisas podem ser
ignorado. Para pequenas solicitações repetidas usando keep-alive, redundante
os cabeçalhos se tornam uma parte muito maior da solicitação / resposta.

Isso também pode ser importante para pessoas que se preocupam mais com o cliente
desempenho (latência mais do que taxa de transferência) do que custo.

Para este caso de uso, a opção mais útil é ser capaz de
remova totalmente o cabeçalho, não simplesmente removendo o valor
ou a parte da versão.

Este comentário limita-se principalmente a adicionar informações relevantes de referência / especificações / RFC e (esperançosamente) interpretação / comentário principalmente não formulado.

Protocolo de transferência de hipertexto RFC7231 (HTTP / 1.1): semântica e conteúdo https://tools.ietf.org/html/rfc7231#section -7.4.2

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

Um servidor de origem NÃO DEVE gerar um campo Servidor contendo detalhes refinados desnecessariamente 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 (ligeiramente) mais fácil para os invasores encontrar e explorar brechas de segurança conhecidas.

https://tools.ietf.org/html/rfc7231#section -9.6

9,6. Divulgação de informações do produto
Os campos de cabeçalho do Agente do Usuário (Seção 5.5.3), Via (Seção 5.7.1 de [RFC7230]) e Servidor (Seção 7.4.2) costumam revelar informações sobre os respectivos sistemas de software do remetente. Em teoria, isso pode tornar mais fácil para um invasor explorar brechas de segurança conhecidas; na prática, os invasores tendem a tentar todas as falhas potenciais, independentemente das versões de software aparentes que estão sendo usadas. Os proxies que funcionam como um portal por meio de um firewall de rede devem tomar precauções especiais com relação à transferência de informações de cabeçalho que podem identificar hosts atrás do firewall. O campo de cabeçalho Via permite que intermediários substituam nomes de máquinas confidenciais por pseudônimos.

De (obsoleto) RFC2616:

15.1.2 Transferência de informações confidenciais
Como qualquer protocolo genérico de transferência de dados, o HTTP não pode regular o conteúdo dos dados que são transferidos, nem existe qualquer método a priori para determinar a sensibilidade de qualquer informação específica no contexto de qualquer solicitação. Portanto, os aplicativos DEVEM fornecer o máximo de controle possível sobre essas informações ao provedor dessas informações. Quatro campos de cabeçalho merecem menção especial neste contexto: Servidor, Via, Referente e De.
Revelar a versão específica do software do servidor pode permitir que a máquina do servidor se torne mais vulnerável a ataques contra software que é conhecido por conter brechas de segurança. Os implementadores DEVEM tornar o campo de cabeçalho do servidor uma opção configurável.

PEP3333 Python Web Server Gateway Interface v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

Em geral, o servidor ou gateway é responsável por garantir que cabeçalhos corretos sejam enviados ao cliente: se o aplicativo omitir um cabeçalho exigido por HTTP (ou outras especificações relevantes em vigor), o servidor ou gateway deve adicioná-lo. Por exemplo, os cabeçalhos HTTP Date: e Server: normalmente seriam fornecidos pelo servidor ou gateway.

• O cabeçalho de resposta do servidor é opcional de acordo com HTTP 1.1
• A RFC reconhece que campos de servidor excessivamente detalhados podem facilitar a varredura de sites em busca de servidores vulneráveis. Claramente, esta é uma cláusula de obscuridade que torna um passo mais difícil, e o quanto os detalhes são demais é circunstancial.
• HTTP 1.1 RFC2616 obsoleto é um pouco mais ousado no valor de ocultar o cabeçalho do servidor.
• PEP3333 parece ultrapassar um pouco ao mencionar o cabeçalho do servidor no contexto de cabeçalhos obrigatórios ou normais.

Muitas opiniões sobre isso, como no Apache HTTPD ServerTokens : https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

Definir ServerTokens para menos do que o mínimo não é recomendado porque torna mais difícil depurar problemas interoperacionais. Observe também que desativar o cabeçalho Server: não faz nada para tornar o seu servidor mais seguro. A ideia de "segurança na obscuridade" é um mito e leva a uma falsa sensação de segurança.

Alterar o cabeçalho do servidor para apenas gunicorn é uma solução prática e acho que devemos fazer isso, sem configuração.

Pessoas como @ kmichel-sereema, que querem otimizar o tamanho de cada transferência, acho que este não é o lugar para realizar tal micro-otimização. Se os cabeçalhos HTTP sobrecarregam muito, HTTP 1.x não é o protocolo ideal a ser usado e não acho que devemos adicionar configurações adicionais para permitir a alteração ou desabilitação do cabeçalho do servidor.

A sugestão de @tilgovi me parece um bom compromisso.

Em muitos ambientes, isso pode até ser discutível. Os documentos de implantação do gunicorn recomendam ter um servidor proxy como o nginx na frente do gunicorn. O nginx remove automaticamente o cabeçalho de resposta do servidor do servidor proxy antes de ir para o cliente e pode ser configurado para remover mais cabeçalhos. Certamente, proxies mais focados em segurança podem fazer o mesmo.

seguindo minha sugestão e comentários de @tilgovi & @jamadden , estou encerrando esta edição em favor de # 2233. Obrigado a todos pelo código e comentários!