Blog Tecnológico

Blog everyWAN

Tecnología, ciberseguridad y tendencias IT que importan

Análisis Profundo
Ciberseguridad
Tendencias IT
Filtrar por:
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
8 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
8 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
8 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
8 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
8 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í.

Panel de salidas de una estación con horarios anunciados: el papel promete tiempos y el hierro tarda lo que tarda

Warning: Undefined array key "read_time" in /var/www/html/public/blog.php on line 3122
min lectura

RTO y RPO sin humo: dos números que se firman sin haberlos calculado

Casi todos los planes de continuidad llevan un RPO y un RTO escritos con seguridad y calculados con ninguna. Qué prometen de verdad esos dos números, por qué el RPO real es el de la última copia verificada, los cuatro relojes del RTO y la aritmética que desmonta un «cuatro horas» sobre un enlace de 1 Gbps.

Escalera de evacuación atornillada a la fachada del edificio del que tiene que sacarte: la copia que depende de lo que protege
8 min lectura

Tu servidor de copias está dentro del dominio que tiene que restaurar

Veeam corrigió en junio un fallo de 9,4 sobre 10 que permitía ejecutar código en el servidor de copias a «un usuario de dominio autenticado». Según el análisis técnico que publicó un tercero, en un servidor en grupo de trabajo ese fallo no llegaba a existir. La diferencia no está en el código: está en a quién le pregunta tu servidor de copias si eres de fiar. Qué comprueba exactamente, por qué es el sexto fallo con la misma descripción en poco más de un año, la dependencia circular que nadie dibuja en el plan de recuperación, lo que cuesta de verdad sacar el servidor del dominio y los casos en los que no lo haríamos.

Informe de ransomware 2026: 1,7 millones de dólares de coste medio de recuperación por incidente
7 min lectura

Restaurar no es recuperar: dos de cada tres salen de la copia y casi la mitad paga igual

El informe anual de ransomware de Sophos (2.158 responsables de IT en 17 países, España incluida) trae el mayor rebote de copias de la serie: el 66% de las víctimas con datos cifrados recuperó desde backup, doce puntos por encima del 54% de 2025. Y a la vez el 48% pagó, y el coste medio de recuperar subió un 11% hasta 1,7 millones de dólares sin contar el rescate. Por qué los dos números no se contradicen, el apunte de método sobre las dos medianas que casi nadie está leyendo bien, qué hay dentro de esa factura y las cinco cosas que conviene cronometrar antes del día malo.

Caída de Google Cloud en europe-west4-a por fallo de energía y refrigeración en el datacenter
10 min lectura

Tres milisegundos y 44 grados: la caída de nube que no fue de software

El 15 de julio de 2026 una bajada de tensión de tres milisegundos en la acometida eléctrica dejó tres servicios de una zona de Google Cloud en Países Bajos casi quince horas fuera de juego. Ni un CVE, ni un despliegue mal hecho, ni una ruta BGP: un transitorio eléctrico, un sistema de respaldo que no cogió la carga, un controlador de enfriadora que se cayó y una sala a 44 grados. Qué falló exactamente según el informe oficial, por qué la redundancia sobre el papel no siempre es redundancia, qué significa que una zona no sea un edificio y las siete preguntas que conviene hacerle a cualquier datacenter —incluido el tuyo— antes de que pase.

Registro de Rumanía
Borrado; lo salvó la copia fuera de alcance
8 min lectura

Borraron el registro de la propiedad de Rumanía, backups incluidos. Lo salvó la copia que el atacante no podía tocar

El 14 de julio un atacante entró en el ANCPI rumano con credenciales válidas, fracasó al extorsionar y borró la base de datos del registro de la propiedad y los backups que alcanzó. Una semana sin compraventas ni hipotecas en todo el país. La diferencia entre incidente y catástrofe fue una copia fuera de su alcance.

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