Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Respuesta a incidentes y análisis forense

Su capacidad para reaccionar rápidamente ante un incidente puede ayudar a minimizar los daños causados por una infracción. Disponer de un sistema de alertas fiable que pueda advertirle de cualquier comportamiento sospechoso es el primer paso de un buen plan de respuesta a los incidentes. Cuando se produce un incidente, debe decidir rápidamente si desea destruir y reemplazar el contenedor afectado, o aislar e inspeccionar el contenedor. Si opta por aislar el contenedor como parte de una investigación forense y un análisis de la causa raíz, debe seguir el siguiente conjunto de actividades:

Ejemplo de plan de respuesta a incidentes

Identifique el pod y el nodo de trabajo infractores

Lo primero que debes hacer es aislar el daño. Comience por identificar dónde se produjo la violación y aísle ese pod y su nodo del resto de la infraestructura.

Identifique los pods y nodos de trabajo infractores mediante el nombre de la carga de trabajo

Si conoce el nombre y el espacio de nombres del pod infractor, puede identificar el nodo de trabajo que ejecuta el pod de la siguiente manera:

kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

Si un recurso de carga de trabajo, como una implementación, se ve comprometido, es probable que todos los pods que forman parte del recurso de carga de trabajo estén en peligro. Utilice el siguiente comando para enumerar todos los pods del recurso de carga de trabajo y los nodos en los que se ejecutan:

selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'

El comando anterior es para las implementaciones. Puede ejecutar el mismo comando para otros recursos de carga de trabajo, como replicasets, statefulsets, etc.

Identifica los pods y nodos de trabajo infractores mediante el nombre de la cuenta de servicio

En algunos casos, puedes identificar que una cuenta de servicio está comprometida. Es probable que los pods que utilizan la cuenta de servicio identificada se vean comprometidos. Puede identificar todos los pods con la cuenta de servicio y los nodos en los que se ejecutan con el siguiente comando:

kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'

Identifique los pods con imágenes y nodos de trabajo vulnerables o comprometidos

En algunos casos, es posible que descubras que la imagen de un contenedor que se usa en los pods de tu clúster es malintencionada o está comprometida. Una imagen de contenedor es malintencionada o está comprometida si se ha descubierto que contiene malware, se sabe que es mala o tiene un CVE que ha sido explotado. Deberías considerar que todos los pods que utilizan la imagen del contenedor están en peligro. Puedes identificar los pods con la imagen y los nodos en los que se ejecutan con el siguiente comando:

IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

Aísle el pod creando una política de red que niegue todo el tráfico de entrada y salida al pod

Una regla de denegación total del tráfico puede ayudar a detener un ataque que ya está en marcha, ya que interrumpe todas las conexiones al pod. La siguiente política de red se aplicará a un pod con la etiquetaapp=web.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress

Si es necesario, revoque las credenciales de seguridad temporales asignadas al pod o al nodo de trabajo

Si al nodo de trabajo se le ha asignado una función de IAM que permita a los pods acceder a otros recursos de AWS, elimine esas funciones de la instancia para evitar que el ataque cause más daños. Del mismo modo, si al pod se le ha asignado un rol de IAM, evalúe si puede eliminar de forma segura las políticas de IAM del rol sin que ello afecte a otras cargas de trabajo.

Acordona el nodo de trabajo

Al acordonar el nodo de trabajo afectado, se informa al programador para evitar programar módulos en el nodo afectado. Esto le permitirá retirar el nodo para realizar un estudio forense sin interrumpir otras cargas de trabajo.

Habilite la protección contra interrupciones en el nodo de trabajo afectado

Un atacante puede intentar borrar sus fechorías acabando con un nodo afectado. Habilitar la protección de terminación puede evitar que esto suceda. La protección de escalamiento de instancias protegerá al nodo de un evento de escalamiento.

Etiquete al infractor Pod/Node con una etiqueta que indique que forma parte de una investigación activa

Esto servirá de advertencia a los administradores del clúster para que no manipulen a los afectados Pods/Nodes hasta que se complete la investigación.

Capture los artefactos volátiles del nodo de trabajo

Vuelva a implementar el pod o el recurso de carga de trabajo comprometido

Una vez que haya recopilado los datos para el análisis forense, puede volver a implementar el pod o recurso de carga de trabajo comprometido.

Primero, implemente la solución para la vulnerabilidad que estaba comprometida e inicie nuevos módulos de reemplazo. A continuación, borra los módulos vulnerables.

Si los pods vulnerables están gestionados por un recurso de carga de trabajo de Kubernetes de nivel superior (por ejemplo, una implementación o DaemonSet), al eliminarlos se programarán otros nuevos. Por lo tanto, los pods vulnerables se volverán a lanzar. En ese caso, debe implementar un nuevo recurso de carga de trabajo de reemplazo después de corregir la vulnerabilidad. A continuación, debe eliminar la carga de trabajo vulnerable.

Recomendaciones

Consulte el documento técnico sobre la respuesta a los incidentes de seguridad de AWS

Si bien esta sección ofrece una breve descripción general junto con algunas recomendaciones para gestionar las presuntas infracciones de seguridad, el tema se trata de forma exhaustiva en el documento técnico titulado AWS Security Incident Response.

Practique los días de juegos de seguridad

Divida a sus profesionales de seguridad en 2 equipos: rojo y azul. El equipo rojo se centrará en investigar las vulnerabilidades de los diferentes sistemas, mientras que el equipo azul se encargará de defenderse de ellas. Si no tienes suficientes profesionales de seguridad para crear equipos independientes, considera contratar a una entidad externa que tenga conocimiento de las vulnerabilidades de Kubernetes.

Kubesploit es un marco de pruebas de penetración CyberArk que puedes usar para organizar días de juego. A diferencia de otras herramientas que analizan tu clúster en busca de vulnerabilidades, kubesploit simula un ataque real. Esto le da a tu equipo azul la oportunidad de practicar su respuesta a un ataque y medir su eficacia.

Realiza pruebas de penetración en tu clúster

Atacar periódicamente tu propio clúster puede ayudarte a descubrir vulnerabilidades y errores de configuración. Antes de empezar, sigue las directrices de las pruebas de penetración antes de realizar una prueba en tu clúster.

Herramientas y recursos