Qué hacemos · Operaciones: Respuesta urgente a vulnerabilidades, el mismo día
Entre un aviso crítico y la llegada de la corrección a su servidor, el hueco lo cerramos nosotros. Las mitigaciones entran en horas, los paquetes corregidos se construyen internamente el mismo día que se publica la corrección, y cada servidor afectado se parchea el mismo día, un host cada vez, con un camino de vuelta probado.
Qué es
Un procedimiento de emergencia ensayado, no una improvisación a la carrera. Cubre todo el recorrido, desde leer el aviso hasta demostrar después que nadie aprovechó la ventana. Se apoya en nuestro propio mirror de paquetes dentro de nuestro datacenter, de modo que el parcheo nunca depende de que un mirror público tenga un buen día.
Cómo lo construimos
Primero leemos nuestro propio parque. Confirmamos qué servidores ejecutan el componente afectado y si las aplicaciones que corren en ellos usan realmente la función vulnerable.
Mitigar primero. Mientras se prepara la corrección, entra la mitigación menos disruptiva: un cambio de configuración, una función desactivada, una regla en el perímetro. Las medidas que cuestan rendimiento se retiran en cuanto la corrección real está dentro. Las medidas que no cuestan nada se quedan.
Lo construimos nosotros, el mismo día. Cuando el proyecto upstream publica el código fuente corregido, construimos los paquetes parcheados el mismo día. Construimos a partir de la propia especificación del maintainer de la distribución en un container limpio, y etiquetamos la versión de modo que el build del propio fabricante sustituya al nuestro automáticamente en la siguiente actualización normal. Los paquetes van a nuestro propio mirror con sus checksums registrados.
Despliegue de un host cada vez. Cada servidor recibe una comprobación previa y una posterior: los mismos módulos cargados antes y después, los mismos sitios respondiendo, la aplicación devolviendo una respuesta sana. Los pools de workers se reinician de forma ordenada, de modo que un sitio con carga ve una pausa de alrededor de un segundo, no una interrupción.
Automatizar la parte delicada. En flotas mayores, como las plataformas cPanel y Plesk donde la corrección viene del fabricante del panel de control, un despliegue temporizado actualiza un servidor por ejecución, muestrea sitios reales en él antes y después, y detiene toda la pasada y llama a un ingeniero en el momento en que un solo sitio no vuelve correctamente.
Comprobar si se usó la ventana. Tras el despliegue revisamos los registros web y de autenticación de la ventana de divulgación, buscando intentos de explotación y cualquier cosa que haya tenido éxito.
De qué le protege
- Un fallo en explotación activa que sigue abierto después de publicarse su corrección.
- Una corrección apresurada que rompe todos los sitios de un servidor de noche sin nadie mirando.
- Un parche cuyo origen nadie puede garantizar.
- Un parcheo estancado porque un mirror público va lento o no responde.
- No saber si alguien entró antes de que llegara la corrección.
En la práctica
Divulgaciones críticas de runtime, cerradas en un día. Cuando un fallo de PHP de máxima gravedad recibe su corrección oficial, las mitigaciones se aplican en las plataformas gestionadas antes del mediodía. El PHP corregido, construido internamente a partir de la propia especificación del maintainer, se publica en nuestro mirror interno en cuestión de horas desde la publicación upstream, y los servidores de aplicaciones de un editor de noticias se parchean uno a uno, cada uno con un único reinicio ordenado de workers de alrededor de un segundo.
La flota de una agencia digital, parcheada antes de medianoche. Esa misma tarde, la flota multiservidor de una agencia digital se parcheó de extremo a extremo, incluidos los hosts cuyos builds corregidos llegaron del fabricante de su panel de control a última hora de ese día y salieron a través del despliegue automatizado con parada automática. Cuando el desarrollador principal de la agencia preguntó esa misma noche si sus servidores estaban cubiertos, tuvo su respuesta en menos de una hora: todos y cada uno estaban hechos.
Y los registros estaban limpios. Una revisión de la ventana de divulgación en las plataformas parcheadas solo encontró escaneos y un intento lento y distribuido de adivinar credenciales, todo ello denegado, y ninguna señal de compromiso.
Por qué EuroVPS
- Parcheo el mismo día en cada servidor afectado, no «en la siguiente ventana de mantenimiento».
- Construimos nosotros mismos paquetes corregidos de confianza, el mismo día que se publica la corrección.
- Nuestro propio mirror de paquetes en nuestro propio datacenter, accesible solo desde nuestro espacio de direcciones.
- Cada despliegue tiene comprobaciones previas, comprobaciones posteriores y una parada automática.
- Después buscamos indicios de explotación, y le contamos lo que encontramos.
Preguntas frecuentes
¿Parchean mi servidor sin preguntar? Para vulnerabilidades críticas en servicios gestionados, parcheamos el mismo día y le mantenemos informado en todo momento. Cualquier tiempo de inactividad se acuerda antes con usted.
¿El parcheo tirará mi sitio? Diseñamos los despliegues para evitarlo: reinicios ordenados, un host cada vez, comprobaciones de salud antes y después, y una parada automática si algo no parece correcto.
¿Y si mi aplicación necesita una versión antigua? Mitigamos a su alrededor, la aislamos, acordamos con usted una ruta de actualización y documentamos las medidas aplicadas.
¿Recibo un informe? Sí. Recibe qué estaba afectado, qué hicimos, cuándo, y qué mostró la revisión de registros.
Si quiere vulnerabilidades cerradas por personas que construyen la corrección ellas mismas, hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.