Blog Tecnológico

Blog everyWAN

Tecnología, ciberseguridad y tendencias IT que importan

Análisis Profundo
Ciberseguridad
Tendencias IT
Filtrar por:
Interior de una librería de cintas: filas de ranuras y una unidad de cinta extraída sobre su guía
9 min lectura

Ransomware: recuperar rápido no es echar al atacante

De las organizaciones que sufrieron más de un ataque de ransomware en los últimos doce meses, el 30% los sufrió el mismo día y otro 29% dentro de la misma semana. Eso no mide reincidencia a largo plazo: mide accesos que nunca llegaron a cerrarse. El 87% de los ataques fue contra el sistema de identidad —Active Directory, Entra ID, Okta—, pero los planes de recuperación siguen restaurando máquinas. Repasamos qué mide cada cifra del informe de Semperis, el dato de España que juega en contra de esa lectura, el orden de recuperación que publica Microsoft y casi nadie tiene escrito, y las ocho condiciones con las que damos por cerrado un incidente.

Bastidores de servidores vacíos, con los montantes y los raíles a la vista y sin ningún equipo montado
7 min lectura

El plano de control es lo primero que se cae, y tu plan B lo necesita

Hace un año, el lunes 20 de octubre de 2025 a las 8:48 de la mañana hora peninsular, un registro DNS se quedó vacío y arrastró media internet. El informe oficial de AWS deja una lectura incómoda para cualquier plan de recuperación: las instancias que ya estaban en marcha siguieron sanas. Lo que no se podía era arrancar otra, actualizar una función, levantar un contenedor, pedir credenciales temporales, entrar en la consola o abrir un ticket de soporte. El titular fueron 2 h 52 min; lo último que AWS dio por restablecido llegó 28 h 17 min después. Repasamos el documento con el reloj de aquí puesto, las seis preguntas que le hacemos a un plan de continuidad y por qué montarlo en hierro propio no te saca del problema: te lo deja en casa.

Registrador de banda de papel abierto, con su rollo milimetrado y la plumilla que dibuja una línea continua
6 min lectura

El 99,9% no te dice cuánto dura la caída: lo que firmas de verdad en un SLA

Tres nueves suenan a cifra seria hasta que haces la división: el 99,9% anual son 8,76 horas al año, y nada en ese número impide que caigan las ocho seguidas un martes. El mismo 99,9% medido por meses son 43,8 minutos y no se acumulan: el total del año es idéntico, pero el techo de un solo corte baja de 8,76 horas a 43,8 minutos. Hacemos la cuenta exacta de los cuatro niveles de nueves, explicamos por qué el porcentaje esconde lo único que tu empresa nota —cuánto dura UNA caída—, qué suele quedar excluido del cómputo y las tres preguntas que hay que hacer antes de firmar. Con el conflicto de interés declarado: nosotros también firmamos SLA.

Torre de alta tensión y línea eléctrica cruzando un campo arado hasta el horizonte
7 min lectura

Barcelona tiene 63 MW de centro de datos. El pipeline está a 300 kilómetros

Colliers publicó su radiografía de la península para abril-septiembre de 2026: unos 450 MW IT operativos, Barcelona de 42 a 63 MW y un pipeline aragonés de 3.764 MW. El titular «los centros de datos crecen un 17 %» no responde a ninguna pregunta que tú te hayas hecho. Las dos que sí importan están en el mismo informe: cuánta capacidad de colocation queda libre donde tú estás (14 % en Barcelona) y a qué distancia se está construyendo el resto: Barcelona tiene anunciados 525 MW, pero Aragón siete veces más, a trescientos kilómetros. Porque la segunda sala de tu plan de recuperación no se decide en euros: se decide en kilómetros, y la cuenta la puedes hacer tú con un mapa.

Técnico de espaldas, agachado delante de un rack abierto, con los cables de red a la altura de la cara
10 min lectura

Probar el sistema vivo evitaba 26 caídas de 40; comprar más redundancia, 9

En 2003, tres investigadores de Berkeley revisaron los informes de caída de tres grandes servicios de internet y se preguntaron qué habría evitado cada una. Para uno de ellos, con cuarenta caídas analizadas, la respuesta fue incómoda: probar el sistema en marcha habría evitado 26; añadir redundancia, 9. Veintitrés años después seguimos comprando lo segundo y saltándonos lo primero. Qué dice exactamente el estudio, por qué Chaos Monkey rompe cosas de nueve a tres y viene desactivado de fábrica, y cómo es un simulacro con hipótesis, radio de impacto y condición de parada en una empresa que no es Netflix.

Unidad de cinta LTO-6 y ranuras de una biblioteca IBM TS3500
7 min lectura

El procedimiento oficial para recuperar un GitLab empieza con un DELETE

El 12 de octubre GitLab publicó tres versiones por un CVSS 10.0 que permite ejecutar código en el servidor, y la propia nota avisa de que en una instancia de un solo nodo el parche obliga a parar el servicio. Si además decides que hay que reconstruir, el camino documentado cuando el fichero de secretos no aparece es borrar las variables de CI/CD, anular los tokens de los runners y desactivar el segundo factor para todos. Nueve cosas dejan de ser accesibles; el código no es ninguna de ellas.

Seta de parada de emergencia sobre una pared, con el pulsador rojo sin accionar
8 min lectura

El correo pedía seis horas; la nota de prensa, nueve: ¿quién firma un apagado así?

El 25 de septiembre Kiteworks pidió a sus clientes algo que casi ningún aviso pide: no que parchearan, sino que apagaran. Sin CVE, sin parche y sin indicadores de compromiso, por inteligencia creíble sobre un ataque «inminente» ese fin de semana. El correo que recibieron los clientes, que publicó primero Heise, decía seis horas; la nota de prensa pública de la compañía, nueve. Y el aviso pedía apagar incluso los sistemas que no dan a internet, con lo que no había forma de acotarlo por exposición. Dos días después se levantó la recomendación, y durante la ventana apareció un fallo crítico desconocido «confinado a una capacidad habilitada en menos del 1 % de la base de clientes». Reconstruimos el caso con las seis fuentes originales y vamos a lo que deja: quién firma en tu empresa una parada así y con qué evidencia (con la frase del CISO que sí la firmó), qué canal usan tus usuarios durante esas horas si tú no les das uno, y las tres cosas que muerden en una parada no ensayada —la HA que levanta lo que apagaste desde dentro del invitado, el fin de semana de copias que empuja fuera de retención los puntos buenos, y la monitorización sin mantenimiento declarado—.

Bahías de disco de un servidor con bandejas medio extraídas y huecos vacíos
8 min lectura

Tu redundancia supone que el repuesto llega mañana

Un disco se muere un martes y no pasa nada: para eso pagaste la réplica. Pero lo que compraste no es inmunidad, es una ventana de tiempo para reponer antes del siguiente fallo, y esa ventana se calculó dando por hecho que el repuesto llega mañana. Western Digital dijo en su llamada de resultados que estaba «prácticamente vendido para el año natural 2026» y Seagate que su capacidad nearline estaba «completamente asignada» para el mismo periodo, con acuerdos de nube que ya alcanzan 2027 y 2028. Hacemos la aritmética con las tasas de fallo publicadas por Backblaze: con el repuesto en 48 horas, la probabilidad de un segundo fallo antes de la reparación es del 0,18 %; con el repuesto en 20 semanas, del 11,5 %. El mismo diseño, los mismos discos, 66 veces más riesgo por una variable que no sale en ningún diagrama. Dónde duele más (el nodo, no el disco), el recorte de retención que no firma nadie, y las seis preguntas que hacemos ahora antes de dar por bueno un diseño.

Armario de servidores con cada máquina etiquetada a mano, una por una
8 min lectura

Tu copia de Proxmox se salta discos y el trabajo sale en verde

La página de limitaciones del complemento de Veeam para Proxmox VE se actualizó el 15 de septiembre de 2026, y hay dos líneas que usan la palabra que de verdad importa: skipped. Existen dos clases de «no soportado» muy distintas: la que te para el trabajo y la que se salta un disco y te lo pinta en verde. Qué se queda fuera de la copia de una plataforma Proxmox, qué no vuelve cuando vuelve la máquina, por qué los contenedores LXC son un inventario aparte, y por qué el manual del backup se lee antes de elegir el almacenamiento y no el día de la restauración.

Vista aérea de un corredor de centros de datos: naves industriales bajas y anchas repartidas a lo largo de una autopista
13 min lectura

Tu nube aguanta perder una zona. AWS acaba de perder una región

El 15 de septiembre AWS escribió en su panel de estado que no puede restaurar los recursos y datos alojados «exclusivamente» en la región de Baréin ni en la zona mec1-az2 de Emiratos. Esa palabra separa a quien perdió datos de quien no. El perímetro de esa redundancia estaba publicado desde el principio: S3 está diseñado para aguantar la pérdida de UNA zona, y las zonas están a menos de 100 km unas de otras. Lo que dice la documentación, lo que dice el contrato y las cuatro preguntas que escribimos en una hoja antes de tocar nada.

Nave de un centro de distribución: estanterías metálicas con palés embalados y pasillo de preparación de pedidos
8 min lectura

Desconectarte lleva 101 minutos; reconectarte, nueve días

Boston Scientific hizo público su incidente un miércoles. Ese mismo día, 101 minutos después del primer aviso, la plataforma por la que sus clientes le pasan los pedidos le cortó todas las conexiones globales. Tardó nueve días en devolvérselas. La cronología completa está en una página de estado pública y enseña tres cosas que no están en casi ningún plan de continuidad: quién decide desconectarte, con qué canal degradado aguantas mientras, y por qué tu sistema de estado deja de decir la verdad.

Pasillo de un centro de datos con dos filas de armarios de rack idénticos
9 min lectura

El cluster elige nodo contando invitados: anti-afinidad en Proxmox VE 9 y la regla que nadie declara

Cuando cae un nodo, el planificador de Proxmox VE elige dónde arrancan tus máquinas dadas de alta en HA. En un cluster recién instalado lo hace contando invitados activos: no sabe que la 101 es la segunda pata de la 100. Proxmox VE 9.0 trajo las reglas de afinidad para poder decírselo, con una asimetría que conviene conocer —la regla que fija a un nodo es una preferencia, la que separa dos máquinas es una orden— y una aritmética que decide si tu VM arranca degradada o no arranca.

Pasillo estrecho de un centro de datos, con un rack abierto de paneles de parcheo de fibra en primer plano y latiguillos aguamarina y amarillos recogidos en las guías de cable
10 min lectura

La redundancia no sobrevive al procedimiento

El 1 de septiembre, una actualización de capacidad programada desconectó de forma secuencial el 100% de los caminos de fibra de una parte de la zona us-central1-b de Google Cloud, en trece minutos. El informe describe justo antes una arquitectura correcta: caminos físicamente separados, alimentación diversa, tolerancia a fallos dobles y triples. Un estudio de Berkeley de 2003 ya explicaba por qué no sirvió: el error de operador no es más frecuente que el de hardware, es que se enmascara peor.

Plan de continuidad sin ensayar: un servidor sacado a medias del rack con los cables de alimentación desenchufados
9 min lectura

El plan de continuidad que nadie ha ensayado es un documento, no un plan

El informe anual de caídas de Uptime Institute de mayo de 2026 dice que la primera causa de las caídas con error humano detrás sigue siendo no seguir procedimientos ya establecidos. Establecidos: el documento existía. Y el 87% de quienes sufrieron una caída con impacto cree que se podía evitar con mejor gestión, procesos o configuración, siete puntos más que en 2024. Qué falta entonces, cómo es un simulacro que sirve, y cuándo NO deberías hacer uno.

Mostrador de pedidos de un almacén con el monitor apagado apartado, una libreta con los pedidos apuntados a mano, albaranes en un pincho y un teléfono descolgado
5 min lectura

El backup estaba a salvo. Y llevaba 47 horas dentro de la misma caída

El parte oficial de un proveedor de hosting decía dos cosas el mismo día: «No existe riesgo de pérdida de datos» y «no es posible acceder a los backups ni realizar la migración de los servicios afectados hacia otro nodo». Las dos eran ciertas, y juntas describen el fallo de diseño que casi nadie tiene en su plan: un RPO perfecto con un RTO sin número. Reconstruimos el reloj con el status del proveedor delante y proponemos la cifra que falta en casi todos los planes: a qué hora dejas de esperar.

Cuadro eléctrico general abierto en un cuarto de instalaciones, con filas de magnetotérmicos colgando todos de un mismo interruptor principal
5 min lectura

Cayeron seis servicios de Microsoft 365 a la vez. Para tu plan de continuidad son uno solo

El lunes 31 de agosto el incidente EX1464935 sobre Exchange Online acabó en MO1465074, con OneDrive, SharePoint Online, Teams, Purview y Defender XDR dentro. Seis nombres, una configuración de autenticación compartida por debajo. Repasamos las horas —incluidas las que no cuadran entre BleepingComputer y Computerworld, y lo decimos en vez de elegir una—, por qué nadie ha confirmado lo del certificado caducado, y la dependencia que casi nadie va a mirar: la consola de seguridad y la capa de auditoría estaban dentro de lo que se había caído.

Armario de llaves metálico abierto en el pasillo de servicio de una oficina, con dos hileras de llaves colgadas de sus ganchos
7 min lectura

Borraron las copias en los dos centros de datos

El aviso conjunto AA26-222A, publicado el 10 de agosto de 2026 por seis agencias, cuenta que contra una de las víctimas de Gunra los actores borraron los datos de copia y de archivo en el centro de datos principal <em>y</em> en el de recuperación, antes y después de desplegar el cifrador. En otro apartado cuenta cómo se hicieron con el llavero: SSH a un servidor de control de accesos y una clave simétrica que descifraba las contraseñas de las cuentas de servidor de toda la empresa. Nuestra lectura: dos sedes que aceptan la misma credencial son una sola sede con dos direcciones postales. Qué queda fuera del bloqueo de retención y seis comprobaciones para esta semana, dos de ellas hay que ejecutarlas de verdad.

Rack abierto en una sala de servidores con dos bandejas de disco a medio sacar
5 min lectura

Con cifrar el 10 % del VMDK le basta: la cuenta que cambia tu plan de recuperación

El cifrador de ESXi que Rapid7 desensambló trae un parámetro de porcentaje y el valor observado era 10: de un VMDK grande solo toca una décima parte, y con eso ya no arranca. El cifrado parcial no es nuevo —LockFile lo hacía en 2021—, pero los números sí son nuevos. Qué cambia en el reloj de tu respuesta, por qué en el hipervisor no hay agente de EDR que valga (Broadcom dice literalmente que no está soportado), qué hace el mismo actor con los servicios de copias y por qué cambiar de hipervisor no es un control de seguridad.

Caja fuerte pequeña de oficina abierta sobre una repisa, con dos sobres, un juego de llaves y una memoria USB dentro
5 min lectura

Clonar el repositorio no es tener copia de GitLab

El 17 de agosto GitLab publicó cuatro versiones fuera de calendario por un fallo que permite modificar o borrar proyectos públicos sin cuenta. La respuesta habitual —«el código lo tenemos clonado»— es cierta y es la parte que menos se pierde. Qué se lleva de verdad un clon, qué se queda solo en el servidor, por qué el fichero de secretos no va dentro de la copia y por qué el arreglo de junio, el que no llevaba CVE, es el que explica mejor el problema.

Una tormenta de verano avanzando sobre el desierto, origen del fallo de refrigeración que apagó 5.000 servidores
5 min lectura

Tus servidores los puede apagar alguien con quien no has firmado nada

El 13 de agosto se apagaron más de 5.000 servidores en un edificio de Phoenix y con ellos cayeron webs, correo y DNS de miles de empresas. La decisión de apagar fue correcta; lo interesante es la cadena por la que bajó la orden, porque el cliente final está al final de ella y no tiene contrato con quien decide. Qué preguntar sobre el edificio donde vive tu hierro y por qué el DNS tumbó a gente que no estaba allí.

  • 1
  • 2

Suscríbete a nuestra newsletter

Para recibir historias del mundo IT, novedades de everyWAN y ofertas exclusivas para suscriptores, date de alta a nuestra lista de correo

everyWAN
everyWAN