Gunicorn: Posibilidad de enmascarar el atributo del servidor de encabezado de respuesta http

Normalmente, gunicorn se implementa detrás de un servidor proxy inverso como nginx en un entorno de producción, y nginx generaría su propia etiqueta Server .

arriba más uno

con @benoitc podemos proponer una opción en la línea de comandos, ¿qué os parece? de lo contrario, cerraremos este ticket como lo explica

¿No se podría simplemente modificar el entorno en un gancho post_request ?

@tilgovi eso funcionaría, supongo ... no estoy seguro si necesitamos crear otra opción ...

No funciona. La solicitud ya se envía en ese momento.

El middleware Server está en los encabezados predeterminados.

¿Qué pasa si simplemente eliminamos el encabezado del servidor por completo?

+1

Si le permitimos establecer el valor del encabezado en una cadena aleatoria, también deberíamos permitirle eliminar el encabezado por completo.

+1

¿Por qué quieres eliminar el encabezado?

En el pasado, eliminé el encabezado de las implementaciones para ocultar el software del servidor y la versión para que no sea detectado por alguien que busca servidores con un exploit conocido.

Sip. La seguridad es una de las razones. Por supuesto, puede cambiar el Server a algo aleatorio, pero ¿por qué enviar bytes adicionales que no son realmente necesarios?

Me tomé la libertad de hacer un PR para esta función: # 1384. Ha estado en mi lista de buscados durante algún tiempo.

Para agregar a la discusión: Yo diría que mientras algunos servidores proxy inversos modifican el encabezado Server , algunos agregan un encabezado Via como se describe en https://www.w3.org/Protocols/ rfc2616 / rfc2616-sec14.html # sec14.38

Desafortunadamente, @mathiasverhoeven cerró su PR por alguna razón y no ha tenido actividad últimamente.

¿Sería imposible tener una opción más genérica aquí, como en --set-headers donde puede especificar cualquier cantidad de encabezados como pares clave-valor? El valor vacío omitiría el encabezado por completo.

Por el momento, me gustaría ajustar Server , pero también me gustaría agregar un encabezado de respuesta más, por ejemplo, X-Product: MyProduct .

Puedo armar algo basado en las relaciones públicas de @mathiasverhoeven . @benoitc y @tilgovi ¿qué les parece?

Solo voy a dejar esto aquí: https://www.fastly.com/blog/headers-we-dont-want. Como puede leer en el artículo, el encabezado Server es muy común Y completamente innecesario.

También me gustaría poder omitir el encabezado del servidor. Utilizo un servidor web centrado en la seguridad llamado Hiawatha para invertir el proxy, configurado para no agregar un encabezado de servidor propio, por lo que el encabezado de servidor de gunicorn está llegando actualmente a los clientes.

La idea de @tuukkamustonen me suena bien. :)

Edición: recién visto https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string sería genial.

¿Alguien está ejecutando Flask? https://stackoverflow.com/a/46858238/452210 sugiere envolver y anular process_response , reemplazando o eliminando el encabezado.

También me gustaría poder omitir el encabezado del servidor. Utilizo un servidor web centrado en la seguridad llamado Hiawatha para invertir el proxy, configurado para no agregar un encabezado de servidor propio, por lo que el encabezado de servidor de gunicorn está llegando actualmente a los clientes.

Me di cuenta de que incluso Cloudflare muestra un encabezado de servidor, por lo que no estoy seguro en estos días de cómo se trata más de seguridad que de fama.

Creo que en lugar de agregar otra opción a la línea de comando o configuración, simplemente eliminaría la versión del encabezado para comenzar. Luego agregue un archivo de configuración solo para eliminar el server_token. La ventaja es que el servidor que se actualiza correctamente a la nueva versión podrá agregar esa configuración sin detener el servicio. ¿Pensamientos?

Me di cuenta de que incluso Cloudflare muestra un encabezado de servidor, por lo que no estoy seguro en estos días de cómo se trata más de seguridad que de fama.

Creo que el servicio y el encabezado del servidor de Cloudflare tienen un contexto diferente al del servidor de un sitio individual. Cuando se realiza un proxy inverso a un sitio a través de Cloudflare, no se desconoce el hecho de que es Cloudflare quien realiza el proxy; es evidente a través de servidores de nombres y / o dirección IP, etc. En contraste, alojar un sitio en un VPS sin un proxy inverso de terceros potencialmente me brinda alguna esperanza de evitar al menos la identificación directa a través del encabezado HTTP del software del servidor. (La idea es, por supuesto, que si en el futuro se descubre que gunicorn tiene alguna vulnerabilidad, encontrar objetivos debería ser más difícil que simplemente buscar el encabezado del servidor).

Creo que en lugar de agregar otra opción a la línea de comando o configuración, simplemente eliminaría la versión del encabezado para comenzar. Luego agregue un archivo de configuración solo para eliminar el server_token. La ventaja es que el servidor que se actualiza correctamente a la nueva versión podrá agregar esa configuración sin detener el servicio. ¿Pensamientos?

Eso seria genial. : +1:: leve_sonriente_cara:

Sí, al menos elimine la versión. La versión no aporta nada a la fama y ahorra mucho tiempo a los atacantes.

Estoy pensando en eliminar la versión. @tilgovi ¿ alguna idea al respecto?

¡Bien por mí!

¿Algún progreso en este? Esto parece una victoria rápida para la seguridad.

que formará parte del próximo 20.1

Estoy pensando en eliminar la versión.

¿Todavía está planificada la configuración de solo archivo de configuración para eliminar el encabezado del servidor por completo?

@DavidOliver ¿

@benoitc Su comentario que

Gracias.

Si podemos eliminar el encabezado del servidor por completo, deberíamos hacerlo.

Todavía tengo que estar convencido de que eliminarlo tiene algo que ver con el
seguridad. No ha sido un problema en los últimos 10 años. Seguridad por
la oscuridad tampoco ayuda, preferiría saber que tenemos un problema y
arreglalo. También conocer el servidor puede ayudar a las operaciones

Me inclino a eliminar la versión en este momento, ya que esta versión está dando
demasiada información sobre cómo se mantiene el servidor. Deberíamos hacerlo por
cada rama que mantuvimos.

¿Pensamientos?

Benoît

El domingo 29 de diciembre de 2019 a las 04:23, Randall Leeds [email protected] escribió:

Si podemos eliminar el encabezado del servidor por completo, deberíamos hacerlo.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMDVBW63 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

Enviado desde mi móvil

Hola,

Estoy usando gunicorn para entregar respuestas a través de una conexión donde los datos
es caro, cualquier cosa que pueda eliminar es cualquier cosa que no tenga que pagar.

El encabezado del servidor es pequeño, pero las cosas pequeñas se suman y, a veces,
cosas pequeñas significa que puede colocar todo en un paquete menos: el
El encabezado del servidor con la versión es de 24 bytes, aproximadamente el 1,7% de la carga útil
con un MSS de 1460 y encabezados TLS. Incluso sin el paquete extra,
es mucho más probable que un paquete más grande necesite ser reenviado por completo
cuando la conexión es mala (como una red celular en un lugar remoto).

En una nueva conexión HTTPS, el protocolo de enlace y el certificado
Exchange aprovecha al máximo la carga útil y las pequeñas cosas pueden ser
ignorado. Para pequeñas solicitudes repetidas usando Keep-Alive, redundant
los encabezados se convierten en una parte mucho más importante de la solicitud / respuesta.

Esto también puede ser importante para las personas que se preocupan más por el cliente.
rendimiento (latencia más que rendimiento) que costo.

Para este caso de uso, la opción más útil es poder
eliminar por completo el encabezado, no simplemente eliminar el valor
o la parte de la versión.

Este comentario se limita principalmente a agregar información relevante de referencia / especificación / RFC y (con suerte) interpretación / comentario en su mayoría sin opinar.

RFC7231 Protocolo de transferencia de hipertexto (HTTP / 1.1): Semántica y contenido https://tools.ietf.org/html/rfc7231#section -7.4.2

... Un servidor de origen PUEDE generar un campo de servidor en sus respuestas.

Un servidor de origen NO DEBE generar un campo de Servidor que contenga detalles innecesarios y DEBERÍA limitar la adición de subproductos por parte de terceros. Los valores de campo del servidor demasiado largos y detallados aumentan la latencia de respuesta y potencialmente revelan detalles de implementación interna que podrían facilitar (ligeramente) a los atacantes encontrar y explotar los agujeros de seguridad conocidos.

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

9.6. Divulgación de información del producto
Los campos de encabezado de User-Agent (Sección 5.5.3), Vía (Sección 5.7.1 de [RFC7230]) y Servidor (Sección 7.4.2) a menudo revelan información sobre los sistemas de software del remitente respectivo. En teoría, esto puede facilitar que un atacante se aproveche de los agujeros de seguridad conocidos; en la práctica, los atacantes tienden a probar todos los posibles agujeros, independientemente de las aparentes versiones de software que se estén utilizando. Los proxies que sirven como portal a través de un firewall de red deben tomar precauciones especiales con respecto a la transferencia de información de encabezado que podría identificar a los hosts detrás del firewall. El campo de encabezado Via permite a los intermediarios reemplazar nombres de máquinas confidenciales con seudónimos.

Desde (obsoleto) RFC2616:

15.1.2 Transferencia de información confidencial
Como cualquier protocolo de transferencia de datos genérico, HTTP no puede regular el contenido de los datos que se transfieren, ni existe ningún método a priori para determinar la sensibilidad de cualquier información en particular dentro del contexto de una solicitud determinada. Por lo tanto, las aplicaciones DEBEN proporcionar el mayor control posible sobre esta información al proveedor de esa información. En este contexto, merecen una mención especial cuatro campos de encabezado: Servidor, Vía, Referente y De.
Revelar la versión de software específica del servidor podría permitir que la máquina del servidor se vuelva más vulnerable a los ataques contra software que se sabe que contiene agujeros de seguridad. Los implementadores DEBEN hacer que el campo de encabezado del servidor sea una opción configurable.

PEP3333 Interfaz de puerta de enlace del servidor web Python v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

En general, el servidor o la puerta de enlace es responsable de garantizar que los encabezados correctos se envíen al cliente: si la aplicación omite un encabezado requerido por HTTP (u otras especificaciones relevantes que estén vigentes), el servidor o la puerta de enlace deben agregarlo. Por ejemplo, los encabezados HTTP Date: y Server: normalmente serían proporcionados por el servidor o la puerta de enlace.

• El encabezado de respuesta del servidor es opcional según HTTP 1.1
• La RFC reconoce que los campos de servidor demasiado detallados pueden facilitar la exploración de sitios en busca de servidores vulnerables. Claramente, esta es una disposición de oscuridad que hace que sea un paso más difícil, y cuánto detalle es demasiado es circunstancial.
• HTTP 1.1 RFC2616 obsoleto es un poco más atrevido en el valor de ocultar el encabezado del servidor.
• PEP3333 parece sobrepasarse ligeramente al mencionar el encabezado del servidor en el contexto de encabezados requeridos o normales.

Mucha opinión sobre esto, como en Apache HTTPD ServerTokens : https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

No se recomienda establecer ServerTokens en menos del mínimo porque dificulta la depuración de problemas interoperativos. También tenga en cuenta que deshabilitar el encabezado Server: no hace nada en absoluto para que su servidor sea más seguro. La idea de "seguridad a través de la oscuridad" es un mito y conduce a una falsa sensación de seguridad.

Cambiar el encabezado del servidor para que solo diga gunicorn es una solución práctica y creo que deberíamos hacerlo, sin configuración.

Personas como @ kmichel-sereema, que quieren optimizar el tamaño de cada transferencia, creo que este no es el lugar para realizar dicha microoptimización. Si los encabezados HTTP tienen demasiada sobrecarga, HTTP 1.x no es el protocolo ideal para usar, y no creo que debamos agregar una configuración adicional para permitir cambiar o deshabilitar el encabezado del servidor.

La sugerencia de @tilgovi me parece un buen compromiso.

En muchos entornos, esto puede incluso ser discutible. Los documentos de implementación de gunicorn recomiendan tener un servidor proxy como nginx frente a gunicorn. nginx elimina automáticamente el encabezado de respuesta del servidor del servidor proxy antes de que vaya al cliente, y se puede configurar para eliminar más encabezados. Seguramente los proxies más centrados en la seguridad pueden hacer lo mismo.

Siguiendo mi sugerencia y comentarios de @tilgovi & @jamadden , cierro este número a favor del # 2233. ¡Gracias a todos por el código y los comentarios!