Las primeras horas tras un CVE crítico: una lista de comprobación que funciona

Se publica una vulnerabilidad de máxima severidad en un componente central. Desde ese momento el reloj corre para todos, atacantes incluidos. La diferencia entre un día tranquilo y una mala semana rara vez es el parche en sí. Es lo que hace en las horas anteriores y posteriores. Esta es la secuencia que seguimos, escrita para que pueda adaptarla a su propia flota.

Hora cero: lea el aviso dos veces

Lea el aviso una vez para entender el fallo y otra para entender las condiciones. La mayoría de los avisos serios vienen con matices: solo cuando un módulo concreto está cargado, solo en un modo de servidor concreto, solo cuando una función es alcanzable desde la red. Esos matices deciden cuáles de sus hosts son urgentes, cuáles están simplemente afectados y qué mitigación encaja.

Anote tres cosas antes de tocar nada: los nombres de los paquetes afectados, la versión upstream corregida y las condiciones de explotación. Todo lo que sigue se contrasta con esa nota.

Encuentre cada host que lo ejecuta

Pregunte a la base de datos de paquetes de cada host en lugar de fiarse de lo que cree que está instalado:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Después compruebe las condiciones. Si el fallo vive en un módulo, liste lo que está cargado de verdad. Si necesita que una función sea alcanzable, compruebe si lo es. Clasifique el resultado en tres grupos: expuestos y alcanzables, instalados pero no explotables tal como están configurados, y no presentes. El primer grupo se mitiga ahora.

Mitigue antes de que exista la corrección

Casi siempre hay algo que puede hacer antes de que haya un paquete corregido disponible: desactivar la función vulnerable, cambiar un valor de configuración, poner en el edge una regla que bloquee la forma de petición que el exploit necesita. Elija la mitigación menos disruptiva que cierre el camino, y aplíquela con disciplina:

• Lleve una lista de cada mitigación que haya puesto, para poder levantar las que cuestan rendimiento cuando llegue la corrección real. Las mitigaciones que no cuestan nada pueden quedarse.

Construya la corrección usted mismo si hace falta

A veces el proyecto upstream ha publicado el código fuente corregido y la distribución aún no lo ha empaquetado. Esperar es una opción, pero no la única. Cuando decidimos no esperar, construimos el paquete nosotros mismos: a partir de la especificación del propio mantenedor de la distribución, en un contenedor limpio y desechable, desde un código fuente cuyo checksum se verifica contra la página oficial de descargas del proyecto, con una etiqueta de release elegida para que la build del propio fabricante sustituya la nuestra automáticamente cuando llegue. Los paquetes van a nuestro propio mirror con sus checksums archivados. El método completo, con comandos, está en Su propio mirror RPM, y construir la corrección antes de que la distribución la publique.

La decisión de construir es un juicio, no un reflejo. Construya cuando el fallo se esté explotando o sea trivialmente explotable, los hosts afectados sean alcanzables y ninguna mitigación cierre el camino lo bastante bien. En caso contrario, una mitigación sólida más una breve espera por el paquete del fabricante suele ser la opción más tranquila.

Lleve un registro, y avise a la gente

Lleve una cronología sobre la marcha

Abra un fichero de texto plano en la hora cero y escriba una línea por acción, con la hora: aviso leído, inventario hecho, mitigación puesta en qué hosts, paquete construido, cada host parcheado, revisión de logs terminada. Cuesta segundos por línea. Le da la ventana de exposición exacta de cada host, que la revisión de logs necesita, y convierte el informe que debe entregar después en una edición en lugar de en un ejercicio de memoria.

Avise a la gente antes de que pregunte

Las personas que dependen de los sistemas afectados oirán hablar de una vulnerabilidad famosa por las noticias, a menudo en cuestión de horas. Avíselas usted primero. Un mensaje breve que diga si sus sistemas están afectados, qué se ha hecho ya y cuándo llegará la corrección vale más que un informe perfecto una semana después. Si algún paso necesita downtime, acuerde el momento con ellas antes de tomarlo.

Despliegue un host cada vez, con pruebas

Cada host recibe una comprobación previa y una posterior, y las dos se comparan, no se miran por encima:

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

En una flota mayor, automatice la parte cuidadosa en lugar de saltársela. Un despliegue que actualiza un servidor por ejecución, muestrea sitios reales antes y después, y detiene todo el barrido y llama a un ingeniero en el momento en que un solo sitio no vuelve, es a la vez más rápido y más seguro que una persona recorriendo una lista de noche.

Después pregúntese si la ventana se aprovechó

Parchear cierra la puerta. No le dice si alguien la cruzó mientras estaba abierta. Cuando el despliegue termine, busque en los logs web y de autenticación del periodo entre la publicación y el parche en cada host expuesto. Busque las formas de petición que el exploit necesita, procesos o ficheros inesperados creados en esa ventana, e inicios de sesión que no encajen con el patrón habitual. Anote lo que encontró, incluido «nada», porque las personas que dependen de esos sistemas lo preguntarán.

La versión corta

• Lea las condiciones, no solo la severidad.
• Inventaríe desde la base de datos de paquetes, no de memoria.
• Mitigue en cuestión de horas.
• Construya la corrección usted mismo solo cuando esté justificado, y hágalo de la forma limpia.
• Lleve una cronología y avise pronto a las personas afectadas.
• Despliegue un host cada vez con comprobaciones previas y posteriores comparables, y una parada automática.
• Revise la ventana de exposición en los logs, e infórmelo.

Si se publica un aviso y le gustaría ayuda para trabajarlo en su propia plataforma, aquí estamos. Hable con un ingeniero

Related (rows[1])

Relacionado: Respuesta urgente a vulnerabilidades, el mismo día · El hardening baseline de cada host · Plataformas al día y disciplina de actualización