Blog Tecnológico

Blog everyWAN

Tecnología, ciberseguridad y tendencias IT que importan

Análisis Profundo
Ciberseguridad
Tendencias IT
Filtrar por:
Antenas de telefonía móvil instaladas sobre la azotea de un edificio de ladrillo, con los mástiles y el cableado a la vista
9 min lectura

Dos operadores en la factura, un solo núcleo en la red

El 21 de octubre de 2026 Orange estuvo casi diez horas sin servicio móvil en toda Francia por un fallo en el núcleo de su red; la fibra, en cambio, aguantó. Si el plan B de tus ocho sedes es una SIM, ese día no tenías ocho respaldos: tenías uno. Explicamos por qué la diversidad de ruta física no cubre este fallo, cómo leer en diez minutos el código PLMN de cada router para saber sobre qué red está registrado de verdad —y qué NO contesta ese código—, por qué en España quedan menos núcleos independientes de los que sugiere la factura (Orange y Yoigo son el mismo grupo con núcleo único de Ericsson; Digi tiene núcleo propio pero comparte radio con Movistar), y por qué una conmutación que mira si el enlace está «up» no se entera de un fallo de núcleo.

Sala de cuadros eléctricos de una instalación real: una hilera de armarios de maniobra grises con un técnico midiendo en un interruptor
8 min lectura

La zona que se cayó en Londres era un cuadro eléctrico

El 20 de octubre de 2026, a las 06:08 UTC, un «evento eléctrico» dentro de una sola zona —europe-west2-b, una de las tres de la región de Londres de Google Cloud— dejó sin servicio a bancos, paquetería y portales durante casi ocho horas. No se cayó una región: se cayó la corriente dentro de una zona. Y «estamos repartidos en dos zonas» no es una respuesta, porque el nombre de una zona es una etiqueta de reparto, no un sitio que puedas auditar: AWS documenta que us-east-1a no es el mismo lugar físico en dos cuentas distintas. Explicamos por qué el dominio de fallo que más cuesta es el que nadie dibuja, por qué la jerarquía por defecto de Ceph lleva años teniendo un tipo de cubo llamado pdu, cuándo NO conviene subir el dominio de fallo y el plano de una fila por réplica que rellenamos a pie de armario.

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.

Parte trasera de un servidor montado en bastidor, con el haz de cables de red y de consola conectados y las etiquetas de aviso del fabricante
8 min lectura

Exchange cae 24 horas después del parche de octubre, y la mitigación deshace el parche

Las actualizaciones de Windows Server del 13 de octubre de 2026 metieron un tope de 512 contextos guardados en el Endpoint Mapper de RPC. Exchange los consume a unos 23,7 por hora, así que el servidor aguanta algo más de veinte horas y se cae al día siguiente, cuando ya nadie lo relaciona con el parche. La mitigación de Microsoft es un valor de registro que multiplica el tope por 128 y, al hacerlo, deshace casi todo el endurecimiento que ese tope venía a aportar. Qué vas a ver en el visor de eventos, qué hacer esta semana, y por qué un fallo que tarda veintiuna horas en aparecer no lo caza ninguna ventana de cambio de dos horas.

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.

Pulsador de parada de emergencia rojo sobre carcasa amarilla, en el panel de control de una máquina industrial
9 min lectura

«Una de cada diez caídas ya es de IA»: ese dato mide otra cosa

El 10,7% que circula esta semana sale de un informe serio —109.000 incidentes de páginas de estado, 390 empresas, 2018 a 2026— pero no dice que la IA cause una de cada diez caídas: dice que una de cada diez caídas publicadas la publicó una empresa de IA. En el mismo informe hay otro número que sí cambia una decisión: una cascada provocada por un tercero tarda 247 minutos de mediana en resolverse, frente a los 96 de un fallo de configuración propio. Dos veces y media, porque el arreglo no está en tu mano. Repasamos qué mide cada cifra de los tres estudios de esta semana, por qué el 61% de fallos que pasaron las pruebas internas no es un problema de IA sino de staging, y la prueba del apagón.

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.

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.

Mesas de una oficina vacía con una silla, archivadores y un monitor apagado
8 min lectura

El apaño era apagar Global Secure Access: el consejo que tu propia política bloquea

El 13 de octubre, tras casi once horas de degradación, el apaño que se ofreció fue apagar Global Secure Access. Llegó once minutos antes de que la incidencia se diera por cerrada, y en los tenants configurados como recomienda la propia documentación ese paso no funciona: apagar el cliente y quedarte fuera es, literalmente, la prueba de que la comprobación de red conforme está bien puesta. El procedimiento correcto existe y lo publicó Microsoft en marzo, con dos scripts; lo que ninguno de los dos te dice es cuánto tarda cada paso en notarse.

Parte trasera de un armario con servidores y latiguillos de red azules y verdes
9 min lectura

Entraron en un aparato al día y fueron a por las claves de recuperación

El 13 de octubre Volexity publicó el análisis de un concentrador de acceso remoto al día de parches en el que alguien consiguió root sin autenticarse. Lo interesante no es el fallo: es que no dejaron puerta trasera, que la herramienta de integridad del fabricante no detecta nada porque todo ocurre en memoria, y que lo que fueron a buscar dentro fueron contraseñas de LAPS y claves de recuperación de BitLocker. Tu plan de continuidad está escrito contra el borrado, y aquí nadie borró nada.

Pared de buzones metálicos numerados en el vestíbulo de un edificio, con una papelera al fondo
8 min lectura

Tu copia de Exchange Online depende de un campo de texto

Microsoft encendió el interruptor hoy, 10 de octubre, en su nube multi-tenant: un tenant con EwsEnabled en $true y la lista de aplicaciones permitidas vacía deja de dejar pasar a todas y pasa a no dejar pasar a ninguna. El 8 y el 9 Microsoft escribió esa lista por ti, con lo que vio usar EWS en los 60 días anteriores. Si copias los buzones de Microsoft 365, tu copia depende ahora de una lista que probablemente no escribiste tú, guardada en un parámetro que la documentación declara como campo de texto y que no admite añadir ni quitar: solo reescribir entero.

Técnico agachado con un portátil delante de un armario de servidores abierto en una sala técnica
7 min lectura

Solo lectura en la consola de copias no era solo lectura

Veeam publicó el 6 de octubre de 2026 el aviso KB4934 con tres vulnerabilidades de Backup & Replication. Dos de las tres las dispara el mismo rol: Backup Viewer, el que se reparte sin pensar porque sirve para mirar. La peor llega a 9,4 y ejecuta código en el servidor de copias; la otra, puntuada 6,1, permite borrar la master key de Enterprise Manager, que es el mecanismo documentado para descifrar una copia cuando se pierde la contraseña. Dentro: la tabla de los tres CVE con sus vectores, por qué PR:L es la parte que importa, y la lista de asignaciones de rol que ningún plan de recuperación incluye.

Pasillo entre armarios de servidores con las puertas cerradas en un centro de datos
9 min lectura

Hardening de VCF: el P0 cierra la puerta y el P2 te deja la llave

VMware publicó el 5 de octubre de 2026 su guía de configuración de seguridad de VMware Cloud Foundation. Nos descargamos la hoja de la 9.1 y contamos: 260 controles, 160 de ellos sin el valor seguro puesto de fábrica. Dentro: por qué el control que cierra el acceso al host es P0 y el que te deja una vía de recuperación es P2, qué ajuste del switch virtual viene abierto solo en un tipo de switch, y las frases donde la propia guía dice lo que no hace.

Armario de cableado de red con latiguillos de pares trenzados y paneles de parcheo
8 min lectura

Caída de Azure: cuatro puertas y el sitio donde guardabas el plan B

El 30 de septiembre de 2026, cinco horas y cuarenta y cinco minutos de incidente en Azure. De los cinco servicios que Microsoft lista como afectados, cuatro son el camino hasta tu infraestructura y el quinto es Azure VMware Solution. Dentro: qué dice y qué no dice el parte oficial 7Q30-010, el reloj real de la detección, por qué la cifra de regiones que circula no está en la fuente, y qué pasa con tu procedimiento de contingencia cuando lo que falla es la consola.

Escritorio doméstico de noche con un monitor, un teclado retroiluminado y un micrófono, iluminado solo por una lámpara
10 min lectura

250 dólares de entrada, un millón de euros de daño

El 30 de septiembre, en la Operación KillSwitch, las autoridades apagaron KillSec: tres detenciones, ocho registros, cinco servidores y al menos 110 TB de datos robados puestos a salvo. La cifra que no fue titular en ninguna parte es la tarifa: entrar en ese negocio como afiliado costaba 250 dólares y la casa se quedaba el 12 % de cada rescate. Dentro: la Operación ROTOMA de la Guardia Civil y los Mossos, los dos registros de Alicante y el ciberataque a una entidad catalana de principios de 2025 con un daño estimado de cerca de un millón de euros; el cambio de tarifa de enero de 2025 y el cifrador para ESXi que borraba instantáneas; por qué la edad del sospechoso mide la barrera de entrada y no la sofisticación; las cuatro puertas por las que entraban, una de ellas sin tocar siquiera tu red; nuestras dos medias de los 110 TB con los supuestos declarados; lo que una incautación no borra; y el inventario de comprobaciones hechas desde fuera que puedes cerrar esta semana.

Sala de reuniones vacía con dos pizarras blancas y sillas alrededor de una mesa larga
9 min lectura

Tu política de parcheo no contempla que no haya parche

El 21 de septiembre entraron en el Dutch Institute for Vulnerability Disclosure, la gente que se dedica a avisar a los demás de que parcheen. Once días después, el segundo de los dos fallos encadenados sigue sin corrección publicada. Dentro: la cronología que el propio afectado publicó con su nombre; por qué el titular —«lo hizo un agente de IA»— no es lo que decide el resultado, y qué dicen de verdad los registros («loud and very messy»); el campo del aviso que dice «Patch status: Available» dos secciones antes del párrafo que dice que el fabricante «está trabajando en una corrección», y por qué tu proceso de vulnerabilidades lee el campo y no el párrafo; los dos documentos públicos que no coinciden y que los dos son verdad; qué te queda cuando el parche no existe —romper la cadena por el otro eslabón, quitar exposición, reducir el radio de daño, subir la vigilancia—; y el párrafo que le falta a tu política de seguridad, redactado entero para que lo copies, con las dos cláusulas que lo hacen funcionar: que caduca sola y que lleva un nombre y un cargo.

Subestación eléctrica de alta tensión con aisladores, embarrados y un transformador
7 min lectura

6.329 MW concedidos a centros de datos y ninguno en servicio

El dato salió esta mañana en la prensa de energía, así que no lo va a leer nadie de informática: Red Eléctrica ha publicado por primera vez el reparto por tipo de consumo de la capacidad de acceso concedida en la red de transporte, y los centros de datos se llevan el trozo más grande —6.329 MW, el 34,2% del total— con 0 MW en servicio. La industria, con menos potencia concedida (5.838 MW), tiene 4.346 ya enchufados: un 74% frente a un 0%. Hacemos las tres divisiones que no vienen en la nota, y una de ellas es que más de la mitad de la potencia que España ha prometido y aún no entrega está apalabrada para salas de servidores. Pero la parte que nos ha hecho parar es otra: en febrero la red estaba «copada al 75%» y hoy queda margen en más del 35% de los nudos, sin que la mejora venga de obra nueva, sino de revisar el escenario de cálculo de la CNMC —capacidad firme arriba en 204 nudos, igual en 658, abajo en 75—. De las tres cifras que circulan, sólo «en servicio» es física. Qué significa eso el día que pidas pasar de 4 a 8 kW por rack, por qué la respuesta peligrosa no es «no puedo» sino «te los doy por una sola vía», y el anexo de cuatro líneas que proponemos grapar al contrato de colocation —al nuestro también—.

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—.

Interior de una librería de cintas con los cartuchos alineados en sus ranuras
9 min lectura

Tu backup inmutable tiene un permiso que lo borra

«Nuestras copias son inmutables» es una frase incompleta, y la documentación de Amazon lo demuestra. Object Lock tiene dos modos: en compliance no puede borrar nadie, ni la cuenta raíz, y la única salida documentada es cerrar la cuenta de AWS; en governance borra cualquiera que tenga el permiso s3:BypassGovernanceRetention. Los dos se llaman inmutabilidad. Y AWS añade una nota que casi nadie ha leído: la consola web incluye por defecto la cabecera que hace falta para saltarse el bloqueo, así que la fricción existe en la API y desaparece en la interfaz. Además: por qué la prueba intuitiva (intentar borrar un objeto) devuelve 200 OK y te engaña en las dos direcciones, por qué Veeam suma 30 días a la inmutabilidad que configuraste en S3, y qué dice de verdad ese estudio del 93 % / 16 % que ha circulado en septiembre —incluida la muestra, que no se parece a tu empresa—. Al final, una frase con cuatro huecos que quien lleva tus copias tiene que poder terminar.

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