Protegiendo sus servidores: Prevención de la divulgación de información con Istio Service Mesh

por Alexandre Vazquez
2025-11-03

En el panorama digital actual, donde las violaciones de datos y las amenazas cibernéticas se están volviendo cada vez más sofisticadas, garantizar la seguridad de sus servidores es primordial. Una de las preocupaciones críticas de seguridad que las organizaciones deben abordar es la «Divulgación de Información del Servidor». La Divulgación de Información del Servidor ocurre cuando información sensible sobre la configuración de un servidor, su pila tecnológica o estructura interna se expone inadvertidamente a partes no autorizadas. Los hackers pueden explotar esta vulnerabilidad para obtener información sobre posibles puntos débiles y lanzar ataques dirigidos. Tales violaciones pueden llevar al robo de datos, interrupción del servicio y daño a la reputación.

Divulgación de Información y Malla de Servicios Istio

Un ejemplo es el Encabezado HTTP del Servidor, que generalmente se incluye en la mayoría de las respuestas HTTP donde se encuentra el servidor que está proporcionando esta respuesta. Los valores pueden variar dependiendo de la pila, pero asuntos como Jetty, Tomcat o similares suelen verse. Pero también, si está utilizando una Malla de Servicios como Istio, verá el encabezado con un valor de istio-envoy, como puede ver aquí:

Divulgación de Información de Implementación del Servidor usando Malla de Servicios Istio

Como se comentó, esto es de tal importancia para varios niveles de seguridad, tales como:

Privacidad de Datos: La fuga de información del servidor puede exponer datos confidenciales, socavando la confianza del usuario y violando regulaciones de privacidad de datos como GDPR y HIPAA.
Reducción de la Superficie de Ataque: Al ocultar los detalles del servidor, minimiza la superficie de ataque disponible para posibles atacantes.
Seguridad por Oscuridad: Aunque no es un enfoque infalible, limitar la divulgación agrega una capa extra de seguridad, dificultando que los hackers recopilen información.

¿Cómo mitigar eso con la Malla de Servicios Istio?

Al usar Istio, podemos definir diferentes reglas para agregar y eliminar encabezados HTTP según nuestras necesidades, como puede ver en la siguiente documentación aquí: https://discuss.istio.io/t/remove-header-operation/1692 usando cláusulas simples para la definición de su VirtualService como puede ver aquí:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: k8snode-virtual-service
spec:
  hosts:
  - "example.com"
  gateways:
  - k8snode-gateway
  http:
    headers:
      response:
        remove:
          - "x-my-fault-source"
  - route:
    - destination:
        host: k8snode-service
        subset: version-1

Desafortunadamente, esto no es útil para todos los encabezados HTTP, especialmente los «principales», por lo que los que no son personalizados agregados por sus cargas de trabajo, sino los que son principalmente utilizados y definidos en el estándar HTTP W3C https://www.w3.org/Protocols/

Entonces, en el caso del encabezado HTTP del Servidor es un poco más complejo de hacer, y necesita usar un EnvoyFilter, uno de los objetos más sofisticados que forma parte de la Malla de Servicios Istio. Basado en las palabras de la documentación oficial de Istio, un EnvoyFilter proporciona un mecanismo para personalizar la configuración de Envoy generada por Istio Pilot. Por lo tanto, puede usar EnvoyFilter para modificar valores para ciertos campos, agregar filtros específicos o incluso agregar nuevos oyentes, clústeres, etc.

Implementación de EnvoyFilter para Eliminar Encabezado

Así que ahora que sabemos que necesitamos crear un EnvoyFilter personalizado, veamos cuál necesitamos usar para eliminar el encabezado del Servidor y cómo se hace esto para obtener más conocimiento sobre este componente. Aquí puede ver el EnvoyFilter para ese trabajo:

---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: gateway-response-remove-headers
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
          server_header_transformation: PASS_THROUGH
  - applyTo: ROUTE_CONFIGURATION
    match:
      context: GATEWAY
    patch:
      operation: MERGE
      value:
        response_headers_to_remove:
        - "server"

Así que centrémonos en las partes de la especificación del EnvoyFilter donde podemos obtener por un lado el usual workloadSelector, para saber dónde se aplicará este componente, que en este caso será el istio ingressgateway. Luego entramos en la sección configPatches, que son las secciones donde usamos la personalización que necesitamos hacer, y en nuestro caso, tenemos dos de ellas:

Ambas actúan en el contexto: GATEWAY y se aplican a dos objetos diferentes: NETWORK_FILTER Y ROUTE_CONFIGURATION. También puede usar filtros en sidecars para afectar su comportamiento. La primera parte lo que hace es incluir el filtro personalizado http_connection_manager que permite la manipulación del contexto HTTP, incluyendo para nuestro propósito principal también el encabezado HTTP, y luego tenemos la segunda parte que actúa en el ROUTE_CONFIGURATION eliminando el encabezado del servidor como podemos ver usando la opción response_header_to_remove

Conclusión

Como puede ver, esto no es fácil de implementar. Sin embargo, al mismo tiempo, es evidencia del poder y las capacidades de bajo nivel que tiene al usar una malla de servicios robusta como Istio para interactuar y modificar el comportamiento de cualquier pequeño detalle que desee para su beneficio y, en este caso, también para mejorar y aumentar la seguridad de sus cargas de trabajo desplegadas detrás del alcance de la Malla de Servicios.

En el panorama en constante evolución de las amenazas de ciberseguridad, proteger sus servidores contra la divulgación de información es crucial para proteger datos sensibles y mantener la integridad de su organización. Istio le permite fortalecer la seguridad de su servidor al proporcionar herramientas robustas para la gestión del tráfico, el cifrado y el control de acceso.

Recuerde, la clave para una seguridad adecuada del servidor es un enfoque proactivo que aborde las vulnerabilidades antes de que puedan ser explotadas. Tome la iniciativa de implementar Istio y eleve la protección de su servidor.

Etiquetas:EnvoyFilter Security Service Mesh

Safeguarding Your Servers: Preventing Information Disclosure with Istio Service Mesh

por Alexandre Vazquez
2023-08-122024-09-29

In today’s digital landscape, where data breaches and cyber threats are becoming increasingly sophisticated, ensuring the security of your servers is paramount. One of the critical security concerns that organizations must address is «Server Information Disclosure.» Server Information Disclosure occurs when sensitive information about a server’s configuration, technology stack, or internal structure is inadvertently exposed to unauthorized parties. Hackers can exploit this vulnerability to gain insights into potential weak points and launch targeted attacks. Such breaches can lead to data theft, service disruption, and reputation damage.

Information Disclosure and Istio Service Mesh

One example is the Server HTTP Header, usually included in most of the HTTP responses where you have the server that is providing this response. The values can vary depending on the stack, but matters such as Jetty, Tomcat, or similar ones are usually seen. But also, if you are using a Service Mesh such as Istio, you will see the header with a value of istio-envoy, as you can see here:

Information Disclosure of Server Implementation using Istio Service mesh

As commented, this is of such importance for several levels of security, such as:

Data Privacy: Server information leakage can expose confidential data, undermining user trust and violating data privacy regulations such as GDPR and HIPAA.
Reduced Attack Surface: By concealing server details, you minimize the attack surface available to potential attackers.
Security by Obscurity: While not a foolproof approach, limiting disclosure adds an extra layer of security, making it harder for hackers to gather intelligence.

How to mitigate that with Istio Service Mesh?

When using Istio, we can define different rules to add and remove HTTP headers based on our needs, as you can see in the following documentation here: https://discuss.istio.io/t/remove-header-operation/1692 using simple clauses to the definition of your VirtualService as you can see here:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: k8snode-virtual-service
spec:
  hosts:
  - "example.com"
  gateways:
  - k8snode-gateway
  http:
    headers:
      response:
        remove:
          - "x-my-fault-source"
  - route:
    - destination:
        host: k8snode-service
        subset: version-1

Unfortunately, this is not useful for all HTTP headers, especially the “main” ones, so the ones that are not custom added by your workloads but the ones that are mainly used and defined in the HTTP W3C standard https://www.w3.org/Protocols/

So, in the case of the Server HTTP header is a little bit more complex to do, and you need to use an EnvoyFilter, one of the most sophisticated objects part of the Istio Service Mesh. Based on the words in the official Istio documentation, an EnvoyFilter provides a mechanism to customize the Envoy configuration generated by Istio Pilot. So, you can use EnvoyFilter to modify values for certain fields, add specific filters, or even add entirely new listeners, clusters, etc.

EnvoyFilter Implementation to Remove Header

So now that we know that we need to create a custom EnvoyFilter let’s see which one we need to use to remove the Server header and how this is made to get more knowledge about this component. Here you can see the EnvoyFilter for that job:

---
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: gateway-response-remove-headers
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager"
          server_header_transformation: PASS_THROUGH
  - applyTo: ROUTE_CONFIGURATION
    match:
      context: GATEWAY
    patch:
      operation: MERGE
      value:
        response_headers_to_remove:
        - "server"

So let’s focus on the parts of the specification of the EnvoyFilter where we can get for one side the usual workloadSelector, to know where this component will be applied, that in this case will be the istio ingressgateway. Then we enter into the configPatches section, that are the sections where we use the customization that we need to do, and in our case, we have two of them:

Both act on the context: GATEWAY and apply to two different objects: NETWORK\_FILTER AND ROUTE\_CONFIGURATION. You can also use filters on sidecars to affect the behavior of them. The first bit what it does is including the custom filter http\_connection\_maanger that allows the manipulation of the HTTP context, including for our primary purpose also the HTTP header, and then we have the section bit that acts on the ROUTE\_CONFIGURATION removing the server header as we can see by using the option response_header_to_remove

Conclusion

As you can see, this is not easy to implement. Still, at the same time, it is evidence of the power and low-level capabilities that you have when using a robust service mesh such as Istio to interact and modify the behavior of any tiny detail that you want for your benefit and, in this case, also to improve and increase the security of your workloads deployed behind the Service Mesh scope.

In the ever-evolving landscape of cybersecurity threats, safeguarding your servers against information disclosure is crucial to protect sensitive data and maintain your organization’s integrity. Istio empowers you to fortify your server security by providing robust tools for traffic management, encryption, and access control.

Remember, the key to adequate server security is a proactive approach that addresses vulnerabilities before they can be exploited. Take the initiative to implement Istio and elevate your server protection.

Etiquetas:EnvoyFilter Istio Security Service Mesh