Alternativas a VMware en 2026: conozca Huawei FusionCompute

Quienes trabajan en el ámbito de la virtualización ya se han dado cuenta de que VMware se ha convertido en un tema distinto tras la adquisición por parte de Broadcom. El debate ha pasado de «¿qué recursos necesito?» a «¿cuánto me va a costar esto en la próxima renovación?». En el caso de muchos clientes, esta conversación ha dado pie a que surja Proxmox. Tiene sentido. Pero existe una tercera opción que casi nunca sale a relucir en las primeras reuniones: Huawei FusionCompute. La plataforma no es nueva ni experimental. Se encuentra en la versión 8.10, cuenta con una amplia documentación técnica y casos de uso en empresas de telecomunicaciones, bancos y organismos gubernamentales de todo el mundo. En Brasil, todavía apenas se menciona en las conversaciones sobre la sustitución de VMware. Y quizá haya llegado el momento de analizarlo con más detenimiento. ¿Qué es FusionCompute? FusionCompute es la capa de virtualización de Huawei para centros de datos. Se ejecuta en servidores físicos, proporciona máquinas virtuales, gestiona la CPU, la memoria, la red y el almacenamiento, y forma parte de la solución DCS de Huawei. La arquitectura gira en torno a dos componentes: CNA (Computing Node Agent): se ejecuta en cada servidor físico, implementa el hipervisor UVP y gestiona las máquinas virtuales de forma local. VRM (Virtual Resource Manager): El VRM es el cerebro central y se encarga de la gestión del clúster. Controla la programación de recursos, el ciclo de vida de las máquinas virtuales, la asignación de direcciones IP y VLAN, y proporciona la interfaz web de administración. Funciona en modo activo/en espera con conmutación automática por error en un plazo de 1 a 2 minutos en caso de que el nodo activo deje de funcionar. El hipervisor UVP se basa en KVM, al igual que Proxmox, pero funciona en una arquitectura «bare-metal» sin sistema operativo anfitrión intermedio, de forma similar a ESXi. Tabla comparativa de las tres plataformas La tabla que figura a continuación le ayudará a distinguir entre lo que constituye una diferencia real de arquitectura y lo que es simplemente una diferencia de presentación comercial. Funcionalidad VMware ESXi / vSphere 8 Proxmox VE 9.2 Huawei FusionCompute 8.10 Tipo de hipervisor Bare-metal (ESXi) Tipo 1 (KVM + QEMU) Bare-metal (UVP/KVM) Hosts por clúster hasta 96 Sin límite explícito* hasta 128 Máquinas virtuales por clúster hasta 8.000 Sin límite explícito hasta 8.000 Licencias Suscripción obligatoria; mínimo 72 colores por CPU Código abierto (asistencia técnica de pago opcional) Licencia comercial de Huawei VM HA ✅ ✅ ✅ automático, independiente del nodo de gestión Migración en vivo ✅ vMotion ✅ ✅ Migración en vivo del almacenamiento ✅ Storage vMotion ✅ ✅ Equilibrado automático de la carga ✅ DRS (incluso en el paquete) ✅ Equilibrador de carga dinámico (a partir de PVE 9.2) ✅ DRS + DPM integrados Ahorro automático de energía (DPM) ✅ ❌ ✅ Desconecta automáticamente los hosts inactivos Sobrecarga inteligente de memoria ✅ ✅ (globo) ✅ (ballooning + sharing + swapping; x86 y Arm) Asignación dinámica de recursos ✅ ✅ ✅ Conmutador virtual distribuido ✅ vDS (no incluido en el paquete de pago) ✅ OVS/SDN ✅ DVS nativo SR-IOV Limitado ✅ ✅ Passthrough de GPU ✅ ✅ ✅ Virtualización de GPU ✅ (vGPU de NVIDIA) ✅ (vGPU de NVIDIA, a partir de 2025) ✅ (vGPU de Intel integrada) Contenedores / K8s nativo ❌ (Tanzu, independiente y de pago) ✅ (LXC; sin K8s nativo) ✅ K8s integrado Multitenencia completa ✅ (con complementos) ❌ ✅ (VPC, ECS, ELB, NAT, etc.) DR orquestado ✅ SRM (de pago) ❌ ✅ UltraVR integrado Copia de seguridad sin agente con CBT ✅ (a través de terceros) ✅ Proxmox Backup Server ✅ eBackup nativo Compatibilidad con Arm ❌ ❌ ✅ Caja negra de diagnóstico ❌ ❌ ✅ La documentación oficial de Proxmox no establece un límite de nodos por clúster. El límite práctico depende del hardware de red y de la latencia; hay casos de clústeres con más de 50 nodos en producción con hardware de nivel empresarial. Lo que llama la atención de FusionCompute Escala de clúster FusionCompute admite 128 hosts y 8.000 máquinas virtuales por clúster lógico, con un máximo de 4.096 hosts y 80.000 máquinas virtuales gestionadas por instancia. VMware alcanza los 96 hosts por clúster en vSphere 8. Proxmox no tiene un límite máximo documentado, pero la estabilidad en clústeres muy grandes depende en gran medida de cómo se haya diseñado la red de gestión. En el caso de los grandes centros de datos corporativos, la compatibilidad con 128 hosts por clúster, con una capacidad total de 80 000 máquinas virtuales, supone una gran ventaja competitiva. DRS y DPM: programación que ahorra energía El DRS de FusionCompute supervisa la carga de los hosts en tiempo real y migra automáticamente las máquinas virtuales para equilibrar el uso de la CPU y la memoria en el clúster, sin necesidad de intervención manual. Esto equivale a lo que ofrece VMware en el paquete de vSphere y a lo que Proxmox ha comenzado a ofrecer con el Dynamic Load Balancer de PVE 9.2. La ventaja distintiva de FusionCompute en este caso es el DPM (Dynamic Power Management): cuando la carga del clúster disminuye, el sistema consolida las máquinas virtuales en un menor número de hosts y apaga automáticamente los servidores inactivos. Cuando la demanda aumenta, los hosts se vuelven a encender. Para entornos con una carga variable a lo largo del día o de la semana, esto supone un ahorro energético real sin necesidad de recurrir a la automatización externa. Sobrecarga de memoria en tres capas FusionCompute combina el «ballooning», el uso compartido de memoria (las páginas idénticas entre máquinas virtuales se consolidan en una única copia física) y el intercambio de memoria para permitir que un servidor ofrezca más memoria virtual que la física disponible. Proxmox utiliza el «ballooning», pero no implementa de forma nativa el uso compartido de memoria entre máquinas virtuales. El resultado práctico es una mayor densidad de máquinas virtuales por host en FusionCompute, especialmente cuando las cargas tienen

Cómo configurar Geofeed en Registro.br

En el artículo anterior hablamos sobre geofeed, RFC 8805, RFC 9632, RDAP y por qué es importante para los proveedores. Ahora pasemos a la práctica. La idea es crear un ejemplo sencillo de publicación de un geofeed utilizando Registro.br, con un archivo CSV publicado en HTTPS y validación a través de WHOIS y RDAP. Para no utilizar ningún bloque real, los ejemplos que figuran a continuación utilizan bloques reservados para pruebas y documentación. En entorno de producción, como es lógico, deberá sustituirlos por los bloques reales de la ASN. Ejemplo de escenario Imaginemos que el proveedor dispone de un bloque de direcciones IPv4 /22 y utiliza cada una de las direcciones /24 en una ciudad diferente. Para el ejemplo de IPv4, utilizaremos: Este bloque forma parte de un espacio reservado para pruebas y evaluaciones comparativas. No debe utilizarse en entornos de producción en Internet. En este caso, solo sirve para que el ejemplo parezca una operación real, sin mostrar el prefijo. La división operativa sería la siguiente: En IPv6, utilizaremos el bloque de documentación: Y dividirlo en /40: Este enfoque se ajusta más a la realidad: un bloque más amplio registrado y, dentro de él, divisiones por ciudad o región. Un archivo por bloque Por el momento, Registro.br mantiene una política más restrictiva en cuanto a la publicación de geofeeds. En la práctica, lo más seguro es trabajar con un archivo por bloque registrado, que contenga únicamente el propio bloque o sus subbloques. Entonces, si el bloque registrado es: Tiene sentido disponer de un único archivo para este /22, que contenga los /24 internos: Contenido: Fíjese en lo más importante: todas las líneas se encuentran dentro del bloque « 198.18.0.0/22 ». Esto es diferente a mezclar bloques independientes en el mismo archivo. Por ejemplo, si tuviera dos bloques diferentes registrados en Registro.br, como: No sería una buena idea incluirlo todo en el mismo archivo CSV en este momento. Lo más seguro sería crear un archivo para cada bloque. Archivo IPv6 En el caso de IPv6, siguiendo la misma lógica, el bloque registrado sería: El archivo podría llamarse: Contenido: Aquí también se aplica la misma regla: los archivos « /40 » se encuentran dentro de la carpeta « /32 ». En un proveedor real, el nivel de detalle puede variar. Puede utilizar /40, /44, /48 u otro tamaño, dependiendo de cómo se haya planificado el IPv6. Lo importante es que el geofeed refleje el funcionamiento de forma coherente y no intente ser más preciso de lo que la red realmente permite. Formato correcto del archivo CSV La RFC 8805 define el formato básico del geofeed [1]: Sin embargo, en el archivo publicado, normalmente no se incluye encabezado. Entonces, no lo haga así: Haga lo siguiente: Algunos detalles importantes: El archivo debe estar en UTF-8. El prefijo debe estar en formato CIDR. El país de Brasil es BR. El estado debe cumplir con la norma ISO 3166-2. Paraná es BR-PR, São Paulo es BR-SP y Rio Grande do Sul es BR-RS. El nombre de la ciudad no debe contener ninguna coma. El campo del código postal debe quedar en blanco, pero debe mantenerse la coma final. Dónde consultar los códigos de los estados En el campo «región», utilice la norma ISO 3166-2. Algunos ejemplos: La fuente oficial es la Plataforma de consulta en línea de la ISO [4]. Para una consulta rápida, la página ISO 3166-2:BR también recoge los códigos de los estados brasileños [5]. Publicación del archivo Puede publicar el archivo CSV en la propia página web del proveedor, en un servidor web, en un bucket público o mediante GitHub Pages. Lo más importante es que la URL debe descargar el archivo directamente. Ejemplo para IPv4: Ejemplo para IPv6: O bien, utilizando GitHub Pages: Tenga cuidado con enlaces del tipo: Este enlace abre una página HTML de GitHub, no el archivo directamente. Para Registro.br, la URL debe proporcionar el archivo CSV directamente. Ejemplo con GitHub Pages Una opción sencilla para laboratorios o pequeños proveedores es utilizar GitHub Pages. El flujo es: El archivo IPv4 quedaría así: La URL final podría quedar así: Si, al abrir esa URL, el navegador descarga o muestra únicamente el contenido CSV, va por buen camino. Si al abrir una página de GitHub aparece con diseño, botones, menú y vista previa, es un error. Tipo de contenido Registro.br puede verificar el tipo de contenido publicado. Lo ideal es que el servidor responda con: o: La RFC 9877 define el tipo « application/geofeed+csv » para los archivos geofeed [3]. Para validar: Ejemplo de respuesta esperada: o: Validación de la sintaxis Antes de registrarse en Registro.br, conviene comprobar el archivo con un validador. Una opción práctica es: Ayuda a detectar errores tontos, como: Ejemplo incorrecto: Problemas: Correcto: Configuración en Registro.br Una vez que haya publicado y validado el archivo, acceda al portal de Registro.br. El proceso general es el siguiente: 3. Seleccione el bloque y abra la opción «Configurar Geofeed»; 4. Indique la URL HTTPS del archivo; Ejemplo de IPv4: Ejemplo de IPv6: Le recordamos una vez más: estos bloques son solo ejemplos con fines de documentación. En entorno de producción, utilizaría los bloques reales. Comprobación en WHOIS Una vez configurado, compruebe si el geofeed aparece en WHOIS. Ejemplo de IPv4: Resultado esperado: Ejemplo de IPv6: Resultado esperado: En entorno de producción, sustitúyalos por las direcciones IP reales de los bloques configurados. Validación en el RDAP También se puede validar a través de RDAP. IPv4: Resultado esperado: IPv6: Resultado esperado: El RDAP es importante porque constituye la vía más estructurada para que los sistemas automatizados detecten el geofeed. La RFC 9877 se creó precisamente para estandarizar este enlace de geofeed en las respuestas RDAP [3]. Comprobando si ha quedado al descubierto Además de WHOIS y RDAP, una herramienta útil es GeolocateMuch: En un entorno real, utilice el prefijo o la dirección IP. Esta herramienta permite comprobar si el geofeed está siendo detectado a partir de datos públicos. Lista de comprobación final Antes de darlo por terminado, revíselo: Errores

Geofeed: por qué tus IP aparecen en la ciudad equivocada y cómo empezar a solucionarlo

Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja: «Mi cliente está en Paraná, pero el sitio web cree que está en São Paulo».«El streaming está diciendo que estoy en otro país».«El banco bloqueó el acceso porque pensó que la ubicación IP era extraña».«Google está mostrando una previsión meteorológica para otra ciudad». Es una situación un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP está bien, DNS responde, traceroute pasa, la latencia es aceptable. Pero para el usuario final, la constatación es sencilla: algo va mal en su Internet. Y a menudo lo es. No en la conectividad, sino en la forma en que esa dirección IP está siendo geolocalizada por terceros. La IP no tiene ninguna ciudad registrada en su interior Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro. No existe tal campo en el protocolo IP: o: La geolocalización de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de búsqueda, los servicios de streaming y las bases comerciales intentan averiguar dónde se está utilizando probablemente esa IP. Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tráfico, mediciones, historial, información de usuarios, bases comerciales, DNS, BGP, entre otras cosas. En la mayoría de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia. Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicación. Sólo que las bases externas pueden tardar en aprenderlo. Y entonces empiezan las llamadas. Dónde entra el geofeed El geofeed es una forma normalizada de que el operador de red diga: «Estos prefijos IP se están utilizando en estos lugares». No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesión ascendente. No es más que un archivo CSV publicado a través de HTTPS, siguiendo un formato definido en el RFC 8805 [1]. Un ejemplo sencillo: 192.0.2.0/24,BR,BR-PR,Apucarana,198.51.100.0/24,BR,BR-PR,Londrina,203.0.113.0/24,BR,BR-SP,Sao Paulo,2001:db8:100::/48,BR,BR-RS,Porto Alegre, Cada línea asocia un prefijo a una ubicación aproximada. El formato es: En la práctica: Es decir: La coma del final es importante. Representa el último campo, postal_code, que está vacío. Qué significa cada campo El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR. Ejemplos: El segundo campo es el país, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR. El tercer campo es la región, utilizando la norma ISO 3166-2. En el caso de los estados brasileños: BR-PR ParanáBR-SP São PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia rápida, también existe la página ISO 3166-2:BR, que enumera los códigos de los estados brasileños [5]. El cuarto campo es la ciudad. El quinto campo es el código postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precaución, porque puede dar demasiada granularidad [1]. Para el ISP, en la mayoría de los casos, el país, el estado y la ciudad son suficientes. La geolocalización es aproximación, no GPS Este punto es más importante de lo que parece. Cuando hablamos de geolocalización, es fácil caer en la tentación de intentar ser demasiado precisos. Pero la geolocalización IP no es un GPS. En NANOG 96, Sid Mathur presentó una charla titulada Geolocalización IP de alta calidad mediante asistentes de codificación de IA y MCP. Uno de los mensajes más útiles de la presentación es precisamente éste: la geolocalización IP es estadística e inexacta. Lo ideal es pensar en regiones geográficas, no en un punto exacto del mapa [6]. Tiene razón: más precisión no siempre significa más calidad. Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad: Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado: Esto evita resolver el problema de un cliente y crear un problema a otro. En la misma presentación, también comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona está en otro país, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo está fuera de la capa de conectividad [6]. Cualquiera que viva en una operación sabe que esto ocurre. ¿El geofeed lo soluciona todo? No. Y aquí es importante ser honesto. Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa información. La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1]. Aun así, publicar correctamente mejora mucho tu posición. Antes, tenías que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente pública, normalizada y descubrible automáticamente. No es una garantía de corrección instantánea, pero es una práctica operativa mucho mejor. ¿Cómo se enteran los demás de tu geofeed? Publicar el archivo en una URL es sólo una parte de la historia. Tienes que indicar dónde está este archivo en los registros del bloque IP. Ahí es donde entra la RFC 9632 [2]. Define cómo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum y inet6num. Hay dos formas principales. La forma más novedosa es utilizar el atributo propio: La forma compatible con entornos que aún no admiten el atributo específico es utilizar remarks: Lo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a él. ¿Qué pasa con el RDAP? RDAP es la forma más moderna de

Made4Flow 2.11.1: exportación de NetFlow para la mitigación de ataques DDoS, nuevas alertas y mucho más

Descubra las novedades de Made4Flow 2.11.1: exporte NetFlow V5, V9 y sFlow a plataformas de mitigación de DDoS, configure alertas por router e integre el sistema con sistemas externos a través de la API REST. Quien gestiona una red de tamaño mediano o grande sabe que la visibilidad del tráfico no es una ventaja competitiva, sino una cuestión de supervivencia. Detectar un ataque DDoS en curso, saber de qué país procede el tráfico anómalo o integrar el analizador de NetFlow con la plataforma de mitigación del operador sin necesidad de reconfigurar los routers: estos son los verdaderos retos a los que se enfrentan a diario los equipos de NOC y de seguridad. La versión 2.11.1 de Made4Flow, disponible a partir del 27 de febrero de 2026, responde precisamente a estas necesidades. En este artículo, detallamos cada novedad y lo que aporta en la práctica. ¿Qué es Made4Flow y a quién va dirigida esta actualización? Made4Flow es un analizador de NetFlow y sFlow desarrollado por Made4it para proveedores de Internet, operadores y equipos de NOC que necesitan una visibilidad detallada del tráfico de red. Recopila los flujos exportados por los routers (NetFlow V5, V9, sFlow, IPFIX), aplica análisis inteligente a dichos datos y ofrece gráficos, alertas y análisis en tiempo real. Esta actualización es especialmente relevante para quienes: Cómo exportar NetFlow a una plataforma de mitigación de DDoS — sin necesidad de intervenir en los routers Esta es la novedad más esperada de la versión 2.11.1 por parte de los equipos que gestionan plataformas de mitigación de ataques DDoS. La situación anterior era la siguiente: para enviar flujos a una solución de mitigación de terceros, era necesario configurar el router para que exportara simultáneamente a dos destinos: el colector de Made4Flow y el colector de la plataforma de mitigación. En muchos entornos, esto no es sencillo, resulta arriesgado o, sencillamente, inviable. Con el nuevo replicador de flujos de Made4Flow, el enrutador sigue exportando con normalidad a Made4Flow. A partir de ahí, la propia plataforma replica y reenvía los flujos a cualquier destino externo, en los siguientes formatos: La configuración se realiza directamente en la interfaz de Made4Flow: sin tiempo de inactividad, sin ventana de mantenimiento en los routers y sin riesgo operativo. Para los proveedores que utilizan soluciones como Wanguard, NSFOCUS, Arbor o cualquier otra plataforma que utilice NetFlow o sFlow, esta funcionalidad elimina una dependencia compleja y agiliza la integración. Integre su plataforma de mitigación de DDoS con Made4Flow y replique NetFlow V5, V9, IPFIX o sFlow con una sola configuración. Análisis de amenazas: nueva visualización para identificar ataques internos La página de Análisis de amenazas de Made4Flow se ha rediseñado por completo en la versión 2.11.1. El nuevo diseño reúne en una única pantalla las principales métricas de seguridad: el total de amenazas detectadas, las direcciones IP sospechosas, el volumen de tráfico malicioso, la distribución temporal de los incidentes y los principales objetivos. La visión geográfica de las amenazas también se ha mejorado, lo que facilita la correlación entre el origen del ataque y el impacto en la red. Para los equipos de seguridad que necesitan responder rápidamente ante incidentes, esto supone menos clics y más información contextual disponible en el momento crítico. Descubra quién está provocando ataques dentro de su red interna con UN SOLO CLIC. Alertas relacionadas con la frecuencia de muestreo y el enrutador: deje de analizar datos distorsionados Uno de los problemas más ocultos en la monitorización con NetFlow es la incompatibilidad de la frecuencia de muestreo. Cuando el valor configurado en la herramienta de análisis difiere del que el router está aplicando realmente, todos los gráficos de tráfico se distorsionan, y el equipo puede tomar decisiones basadas en datos erróneos sin darse cuenta. La versión 2.11.1 incorpora dos tipos de alertas específicas para este escenario: Aviso de incompatibilidad de la frecuencia de muestreo Le avisa automáticamente cuando el valor de muestreo configurado en Made4Flow difiere del que está indicando el router. Esto resulta especialmente útil en entornos con varios routers de distintos fabricantes (Cisco, Huawei, MikroTik, Juniper), en los que el patrón de muestreo puede variar. Alertas explícitas por router Cada router registrado en Made4Flow puede ahora tener sus propias alertas activas, visibles directamente en la lista de equipos y en la página de edición. Esto facilita la gestión en entornos con decenas o cientos de routers supervisados. Reciba una alerta antes de que el problema afecte a sus datos: configúrelo en cuestión de minutos. Tráfico por país y aplicación por prefijo: visibilidad geográfica en tiempo real Para los proveedores de Internet y los operadores, saber de dónde procede el tráfico es tan importante como saber cuál es su volumen. Un pico procedente de un país concreto puede indicar que se está produciendo un ataque volumétrico; un prefijo específico que consuma ancho de banda por encima de lo habitual puede indicar que un cliente ha sido víctima de un ataque. La versión 2.11.1 incorpora una nueva pantalla de visualización con gráficos de tráfico desglosados por: Esta información ya estaba disponible en los datos sin procesar, pero ahora se presenta en un formato visual nativo, sin necesidad de exportar datos, cruzar hojas de cálculo ni utilizar herramientas externas. Compruebe en cuestión de segundos qué país o prefijo está generando tráfico anómalo, y actúe antes de que el ataque se intensifique. Agregación por indicadores TCP y países: detecte con precisión los patrones de ataques DDoS Los ataques DDoS modernos suelen camuflarse entre un volumen de tráfico aparentemente normal. El análisis de los indicadores TCP —como las inundaciones de SYN, ACK o RST— es una de las formas más eficaces de identificar el tráfico malicioso antes de que afecte a los servicios. La versión 2.11.1 incorpora nuevas pestañas de agregación en los datos brutos de Made4Flow: Para los equipos de seguridad que investigan incidentes, la combinación del análisis por indicadores y por origen geográfico resulta especialmente eficaz a la hora de establecer una correlación entre la técnica de ataque y su origen. Detecte los ataques basándose

BOTNET KIMWOLF: Ataques DDoS internos y cómo mitigarlos ahora (2026)

Una vez más, las redes ISP están siendo atacadas… pero ahora el enemigo viene de dentro. ¿Has visto alguna vez el centro de llamadas estallar con quejas de lentitud inexplicable? Apenas nos hemos recuperado del ataque que explotó vulnerabilidades en el SDK de Realtek, en el que se comprometieron routers y ONUs y se utilizaron para DDoS contra terceros, y ya estamos lidiando con una amenaza mucho más peligrosa y extendida: la botnet AISURU/Kimwolf. Esta botnet explota principalmente dispositivos baratos Android IPTV, SmartTV y set-top-box instalados en los hogares de los usuarios. Estos dispositivos se convierten en zombis que venden proxies domésticos y, en menor medida, participan en ataques DDoS a terceros. ¿El resultado? Problemas generalizados en varios frentes: RESULTADO: clientes frustrados, elevados costes de asistencia y riesgo para la reputación de todo el ISP. Un círculo vicioso que nadie quiere y que crece rápidamente. CAOS REAL A continuación encontrarás una recopilación de preguntas y respuestas a lo que ya sabemos sobre el tema. Y al final algunos consejos sobre cómo protegerte o mitigarlo. 1) ¿De dónde procede este ataque y por qué? Según los sitios web de seguridad Xlab y Synthient, los actores implicados en la botnet la utilizan para ganar dinero con determinados tipos de servicios: Como tienen el control total de todos los dispositivos, utilizan servidores de control de comandos para crear túneles de navegación, instalar aplicaciones y lanzar ataques DDoS contra terceros. También se ha informado de cosas que van más allá de la seguridad, como la difusión de imágenes y vídeos de temas controvertidos (políticos, geopolíticos, etc.). 2) ¿Ya hay demasiadas personas infectadas? Los datos de Synthient y XLab indican que, aunque solo representan una fracción de las comunicaciones, se registraron más de 12 millones de direcciones IP únicas (se estima que hay unos 2 millones de dispositivos). Y la mayor parte de ellas proceden de Brasil (~15 %), seguidas de Vietnam, India, EE. UU. y Argentina. La empresa de seguridad china XLab identificó que la botnet Kimwolf había comprometido entre 1,8 y 2 millones de dispositivos, con una fuerte concentración en Brasil, India, Estados Unidos y Argentina. Imagen: blog.xLab.qianxin.com 3) ¿Cómo se infectan los equipos? Seguramente se habrá preguntado alguna vez cómo es posible que estos equipos sean tan baratos, ¿verdad? Pues sí. Algunas imágenes de dispositivos ya infectados. Fuente: Synthient. Además, ya se ha comprobado que no se someten a un proceso riguroso de corrección de vulnerabilidades, parches de seguridad y actualizaciones o mejoras. Es un auténtico festín para los delincuentes. La principal forma de infectar Kimwolf es aprovechando un fallo en los SDK de las aplicaciones proxy (como Byteconnect, IPIDEA y PYPROXY). El atacante alquila un proxy legítimo de estos servicios, utiliza el túnel para «volver atrás» a través de la propia conexión del dispositivo y acceder a la red local interna, donde encuentra el ADB (Android Debug Bridge) expuesto sin autenticación (puerto 5555 y similares). En segundos, envía comandos remotos, descarga el malware y lo instala todo. Topología de infección por proxy residencial. Fuente: Synthient. Hay varias formas de infectar los equipos (pero todas acaban convergiendo en este mecanismo principal): 1º) De fábrica Muchos dispositivos salen de fábrica con aplicaciones proxy preinstaladas (sin que el usuario lo sepa), para monetizar después el ancho de banda. Cuando el dispositivo entra en el grupo proxy (por ejemplo, IPIDEA, Byteconnect, PYPROXY), el atacante explota exactamente este puerto abierto.Ésta es la principal vía de infección y así es como más se propagó la botnet Kimwolf, con millones de dispositivos comprometidos en meses. 2º) Instalando apps poco fiables Los usuarios instalan aplicaciones de terceros (no verificadas), y éstas añaden silenciosamente el SDK del proxy, activando la ruta del exploit a través de ADB. 3º) Puertos ADB/Telnet vulnerables Algunos de estos IPTV ya vienen con ADB expuesto por defecto. Incluso sin el SDK inicial, un pequeño escaneo/fuerza bruta en puertos como 5555, 3222 o 5858 permite el acceso shell y la instalación del malware. 4) ¿Qué son estas aplicaciones proxy? Básicamente, son empresas que venden la navegación por Internet a través de sus «proxies» en todo el mundo. Cuando les compras un servicio, configuras una «VPN» a sus servidores, y luego tu navegación pasa por el paquete elegido (por ejemplo, navegar a través de IPs residenciales en Brasil, Vietnam, etc.). Ganan dinero cobrando unos pocos dólares por GB de tráfico. Pero, ¿qué hacer? Si quieres una respuesta fácil, no la tendrás. Vamos a tener que abordar este problema desde varios frentes. Al fin y al cabo, a diferencia de otras botnets en las que el dispositivo estaba bajo el control del ISP (el router, la ONU, etc.), en este caso el equipo infectado en el 99% de los casos es el del propio cliente. Desde la perspectiva de un ISP, podemos abordar el problema con cuatro acciones: Acción 1: Identificar a los clientes/equipos infractores En el github de Synthient (el enlace estará más abajo), hay una parte de la lista de IPs/puertos utilizados en la botnet. Pero ya son el primer paso hacia la identificación. Utiliza esta lista y compárala con las comunicaciones de tu software netflow (preferiblemente made4flow), procedentes de tu BNG. Con esto, ya sabrás quién está infectado internamente. Acción 2: mitigar / eludir los impactos Aquí es donde entra en juego la creatividad técnica. Lo básico es bloquear las comunicaciones mediante un cortafuegos o un agujero negro (pero éstos no duran mucho y sirven como mucho de tirita, porque la red de bots es tan capaz de cambiar de IP/red como las TV piratas de burlar los bloqueos de Anatel). Una vez hecho esto, empieza a pensar en soluciones más elaboradas. Si necesitas ayuda, ¡llámanos! Acción 3: reparar los equipos infectados Las recomendaciones de los sitios web de seguridad son: destruye estos dispositivos. Y punto. Pero conocemos la realidad. No puedes destruir el aparato de un cliente, pero puedes trabajar para concienciarlo. Desarrolla un guión, ten tu ingenio a mano y ve a visitar a tu cliente. Enséñale cómo se utiliza su red

Pruebas de rendimiento de CGN/BNG en la plataforma Huawei NE8000

Aprenda de la mano de Luiz Puppin, especialista en Huawei, cómo realizar un análisis técnico de las pruebas de rendimiento (Forwarding Performance) llevadas a cabo en un entorno de laboratorio con la plataforma Huawei NE8000, con el fin de validar la capacidad del equipo para funcionar como BNG+CGN integrado bajo una carga elevada. Las pruebas tenían por objeto comprobar: Objetivo de las pruebas de rendimiento El objetivo era demostrar que la solución de Huawei es capaz de soportar: Estas características son fundamentales para las operaciones de los proveedores de servicios de Internet (ISP) y los operadores con una elevada concentración de abonados detrás de un CGN. Arquitectura utilizada La topología utilizada conecta: Metodología 5. Evidencias y resultados A continuación se incluyen las pruebas extraídas directamente del archivo de prueba. 5.1. Suscriptores autenticados correctamente El informe confirma la autenticación simultánea de miles de abonados PPPoE: El total validado fue de: 5.2. Creación de 32 millones de sesiones NAT El DUT ha alcanzado el límite de escalabilidad previsto por el fabricante: Es decir, el equipo soportó 32 millones de flujos simultáneos sin que se apreciara ninguna pérdida de calidad. 5.3. Tráfico sostenido a 50 Gbps – Sin pérdida de paquetes Es decir: 5.4. Tráfico bidireccional de 50 Gbps (25G + 25G) El laboratorio ha validado el funcionamiento simultáneo de las fases de pretratamiento y postratamiento: Una vez más, sin pérdida alguna de paquetes: 5.5. Estabilidad de la CPU La CPU se mantiene en niveles estables, sin alcanzar los límites críticos. 5.6. Conclusión de las pruebas de rendimiento A la luz de las pruebas, cabe concluir que: Por lo tanto, la plataforma demuestra una capacidad real para gestionar redes CGN/BNG en entornos a gran escala, con un elevado volumen de tráfico y una gran densidad de abonados. Este artículo se ha elaborado en colaboración con el equipo de responsables de productos IP para ISP de Huawei Brasil, con un agradecimiento especial a Thiago Sério y a Natan Fernandes. ¿Necesita ayuda para configurar sus equipos Huawei? ¡Podemos ayudarle! Quiero saber más

MC-LAG en routers Huawei

Cómo configurar MC-LAG en Huawei: E-Trunk, Eth-Trunk, LACP y BFD paso a paso. Aprende MC-LAG en Huawei, hoy te mostramos por qué E-Trunk (multichasis), cuándo utilizar Eth-Trunk (agregación), cómo ajustar LACP para puertos activos/de reserva y cómo BFD acorta el MTTR. Hemos incluido recomendaciones para el hashing en escenarios MPLS y un script de prueba para validar el comportamiento ante fallos. La agregación de enlaces (LAG), llamada Trunk en Huawei(Eth-Trunk cuando es Ethernet), es una tecnología que combina varias interfaces físicas en una única interfaz lógica. Con la agregación de enlaces ganamos: El LAG tradicional es siempre entre dos dispositivos, punto a punto: Tipos de LAG para Huawei En pocas palabras, en Huawei tenemos tres formas principales de utilizar Eth-Trunk: En el contexto de MC-LAG, lo que nos importa es básicamente: Hagámoslo sencillo: Manual LACP estático Cómo equilibra Trunk el tráfico Eth-Trunk no «añade puertos» como una puerta gigante. El equipo decide a través de qué miembro enviar cada flujo mediante algoritmos de equilibrado. Esto define dos comportamientos principales: Equilibrio de carga basado en hash Es estándar en la mayoría de los routers/conmutadores. Funciona así El hash puede utilizar varios criterios, por ejemplo: Con hash, el modo por defecto es por flujo: El hash tiene una consecuencia importante: No siempre distribuye uniformemente el ancho de banda.Según la distribución de los flujos (hash), un miembro puede estar en el cuello de botella mientras que otro casi no tiene tráfico. Esto es normal. Equilibrio dinámico de la carga Algunos dispositivos admiten el modo dinámico, que supervisa la carga instantánea de cada miembro y reasigna los flujos entre los enlaces infrautilizados o sobrecargados. Un dispositivo que utiliza este tipo de equilibrado son los conmutadores Datacom. ¿Y qué pueden utilizar los chips para el hashing? Casi nadie habla de este punto, pero es crucial. Dependiendo del ASIC, el router puede tener un aspecto: En el caso de MPLS: Eso importa porque Ejemplos prácticos: En resumen: Cuanto mayor sea la profundidad MPLS que vea el ASIC, mejor será la distribución de los flujos MPLS en el LAG. Qué hace LACP LACP (Protocolo de Control de Agregación de Enlaces, IEEE 802.3ad) es el que: En Huawei, cuando Eth-Trunk está en LACP estático, las interfaces miembro: El lado con mayor prioridad del sistema (valor numérico más bajo) se convierte en el Actor. A partir de ahí Qué tiene que estar «bien» para que el GAL suba correctamente Para que un Eth-Trunk con LACP funcione como se espera, es necesario que ciertos puntos estén alineados entre ambos lados: Lo que hace LACP es utilizar la prioridad del sistema + ID del sistema + prioridad de la interfaz + número de interfaz para: Entrar en MC-LAG Hasta ahora hemos hablado de LAG «normal», es decir, sólo entre dos dispositivos. MC-LAG (Multi-Chassis LAG) entra cuando lo deseas: La idea es sencilla: Objetivo principal del MC-LAG: Básicamente es llevar la idea de redundancia del nivel de puerto/enlace al nivel de dispositivo. Activo/activo vs activo/reserva En muchos vendedores puedes encontrar MC-LAG de dos sabores: En Huawei, para este escenario concreto con E-Trunk/mLACP, el comportamiento es activo/respaldo: MC-LAG en Huawei: E-Trunk vs mLACP En Huawei, hay dos formas principales de implantar MC-LAG: La diferencia radica en el mecanismo de control entre los PE: En este artículo nos centraremos en el E-Trunk, que es la forma«clásica»de MC-LAG en muchos escenarios PE-CE. Cómo funciona E-Trunk No confundas E-Trunk (la tecnología de sincronización entre chasis) con Eth-Trunk (la propia agregación de enlaces). Considera el siguiente escenario: Los EP entonces: Con esto: Cuando se produce un fallo: Opcionalmente, puedes Conectividad CE ↔ PEs con E-Trunk Algunos puntos importantes del diseño: Casos prácticos En la topología siguiente, cubriremos dos casos de uso de MC-LAG (hay muchos otros). 1) MC-LAG que protege VPLS (capa 2) En la parte superior del dibujo, CE1 está en multihoming con PE1 y PE2 mediante MC-LAG, todos en la misma instancia VPLS-1.En el lado de la red, PE1/PE2 cierran el VPLS con PE3, que presta el mismo servicio a CE2. Se trata de una protección L2 de extremo a extremo para el VPLS, con redundancia de equipos y POP. 2) MC-LAG que protege /30 L3 (capa 3) En la parte inferior del dibujo, CE3 recibe un /30 L3 a través de MC-LAG, dual-homed en PE2 y PE3. Configurar el entorno Ahora que ya conoce todos los conceptos que subyacen al MC-LAG, pasemos al laboratorio. Utilizaremos el entorno virtual PNETLAB, con la imagen Huawei NE40 V22. Los puertos físicos y las conexiones entre dispositivos se describen en la topología siguiente. La configuración de los CE es sencilla: un mikrotik (ROS 7.6) que utiliza interfaces bonding, con LACP rápido (en 1s). CE3 es simplemente una interfaz física con una VLAN. CE1 CE2 CE3 La configuración de los PE incluye las interfaces punto a punto, activas con OSPF, MPLS. En las interfaces de acceso, las configuraciones LAG y de sincronización e-trunk. Y en la capa de servicio, el VPLS (VSI) y la pasarela L3 (con la dirección mac y la misma IP). PE1 – Capa central Servicio MLAG y E-trunk Aquí es donde el MLAG cobra todo su sentido. Primero creamos un Eth-Trunk ordinario, y luego lo asociamos a una configuración e-trunk, que hace que se produzca la magia MLAG. Una vez creado el LAG, ahora debemos configurar el e-trunk. Para configurarlo, necesitamos: En nuestro laboratorio, vamos a cerrar el loopback entre PE1 y PE2, que forman parte del MLAG desde la perspectiva de CE1. La prioridad maestra será PE2, con prioridad 5. Los temporizadores configurados son 9 para hello y 30 para hold-timer. Por último, es hora de asociar la interfaz LAG con e-trunk, creando así un MLAG desde la perspectiva de CE1. Servicios VPLS PE2 – Capa central Las configuraciones CORE y VPLS del PE2 son similares a las del PE1 Servicio MLAG y E-trunk Servicios de pasarela redundantes Para el servicio de pasarela redundante para CE3, lo haremos: PE3 – Capa central Las configuraciones CORE del PE3 son similares a las del PE1.

Cómo Pontonet salió del caos de servidores y redujo costes con Proxmox

Descubre cómo Made4it transformó un escenario de fracaso total en una infraestructura moderna, resistente y más barata. 16/09/2025 – Por Made4it La escena es familiar para cualquier responsable informático: final de mes, facturas por emitir, sistema en marcha… hasta que todo se cae. Esto es exactamente lo que le ocurrió a Pontonet, cuando un fallo simultáneo en un servidor físico puso en peligro toda la empresa. Párate a pensar: si todos tus discos fallaran hoy, ¿cuánto costaría recuperar la información de todo un año? Fue entonces cuando Made4it intervino para convertir el desastre en oportunidad. El problema: fallo simultáneo y sin copia de seguridad Este es el tipo de riesgo que muchas empresas ignoran hasta que es demasiado tarde. Soluciones sobre la mesa: ¿mantener VMware o migrar? Ante el desastre, evaluamos dos alternativas: Continuar con VMware Migrar a Proxmox ¿Por qué Proxmox? Proxmox es más que una alternativa gratuita. Te ofrece: En comparación con VMware, Proxmox demostró ser más ágil, económico y seguro. El papel de Made4it en este giro Pontonet ya era cliente de las redes y servidores de Made4it. Cuando se produjo el fallo, tomamos las siguientes medidas: Este proceso demostró nuestro dominio técnico y nuestra capacidad para convertir las crisis en oportunidades de innovación. Resultados: seguridad y ahorro Después de la migración: Proxmox y Made4it: la combinación ganadora Esta historia demuestra que la tecnología y la estrategia van de la mano. No tiene sentido invertir en licencias caras si el proyecto no incluye redundancia y copias de seguridad; del mismo modo, una solución de código abierto requiere conocimientos especializados para aplicarse con seguridad. Made4it ofrece ambas cosas: conocimientos profundos y soluciones asequibles. ¿Conoces a alguien que siga confiando en un servidor antiguo sin copia de seguridad? ¡Envíale este artículo! Y si no quieres llevarte una sorpresa al descubrir que tu empresa es vulnerable, habla con nuestros expertos.

Por qué las empresas líderes tienen NOCs: y tú también deberías tenerlos

15/08/2025 – Por Emerson Martins Internet está en el corazón de las empresas de hoy. Basta un corte en la red para que las ventas se detengan, los equipos se vuelvan improductivos y la reputación se vaya por el desagüe. ¿Cuántas veces te ha ocurrido esto? Si la respuesta es «más de una vez», estás apostando por la suerte y la suerte no es una estrategia. Te mostraremos por qué tener un NOC (Centro de Operaciones de Red) y elegir un proveedor de Internet que también opere un NOC son decisiones que pueden salvar tu operación. ¿Qué es un NOC y por qué es importante? El NOC es el centro neurálgico de tu red. Es donde los expertos supervisan el tráfico, analizan los indicadores de rendimiento y toman medidas preventivas para evitar fallos. Funciona 24 horas al día, siete días a la semana, para garantizar que nada escape a los ojos de quienes cuidan de tu infraestructura. Sin un NOC, tu empresa está a merced de los imprevistos. Con él, puedes anticiparte a los problemas y convertir los incidentes en oportunidades de mejora. NOC corporativo: tu empresa protegida en todo momento Empresas de todos los tamaños dependen de sistemas en línea, de la nube y de servicios que no pueden detenerse. Un NOC interno ofrece: Tener un NOC interno no es un lujo; es la base de una operación estable y escalable. ISP NOC: el diferenciador que todo proveedor debe ofrecer De nada sirve que tu infraestructura sea impecable si el enlace de tu ISP se cae. Un ISP con NOC propio te garantiza estabilidad y seguridad. Lo que obtienes Un proveedor con un NOC es un socio que se ocupa de tu operación junto contigo. NOC interno + NOC proveedor: la unión hace la fuerza Cuando tu empresa tiene un NOC y el proveedor también, añades el control interno a la estabilidad externa. Esto reduce drásticamente el riesgo de tiempo de inactividad y ofrece apoyo por ambas partes. Es la combinación perfecta para quienes no pueden aceptar estar desconectados. Tener un NOC detrás de tu operación es sinónimo de control, agilidad y prevención.Y cuando tu ISP también tiene un NOC eficiente, ganas aún más estabilidad y apoyo. Juntos, estos dos puntos garantizan una red más segura, disponible y preparada para crecer con tu negocio. Si Internet y la tecnología son una parte fundamental de tu vida diaria, estar a merced de la suerte no es una opción. Si tu empresa necesita contratar o ampliar su monitorización, necesitas conocer Made4NOC, que se creó para ser una alternativa eficaz, fiable y adaptada a tus necesidades, garantizando que tu operación esté monitorizada donde más te importa. Conheça o Made4NOC Conheça todas as vantagens que você ganha ao ter o Made4NOC na sua operação Vantagens do Made4NOC Se quiser, fale com nosso time agora mesmo Comercial (WhatsApp)

IPv6 para proveedores de servicios de Internet: seguridad, rendimiento y escalabilidad

IPv6: la clave para el futuro de la conectividad en los proveedores de Internet Internet a nivel mundial está atravesando una transición inevitable. Con la proliferación de dispositivos conectados —desde teléfonos inteligentes y el Internet de las cosas (IoT) hasta las aplicaciones 5G—, el agotamiento de las direcciones IPv4 ha dejado de ser una previsión lejana para convertirse en un verdadero cuello de botella. Desde 2011, la IANA ya venía advirtiendo sobre el agotamiento de los bloques de direcciones IPv4 y, en Brasil, desde 2020, ya no hay direcciones disponibles para su asignación. Ante esta situación, muchos proveedores de servicios de Internet (ISP) han recurrido al CGNAT como solución provisional. Funciona a corto plazo, pero tiene un alto coste: pérdida de conectividad de extremo a extremo, repercusiones en aplicaciones sensibles y graves problemas de trazabilidad y seguridad. En este contexto, el IPv6 deja de ser una mera alternativa tecnológica. Se convierte en la única vía viable para garantizar la escalabilidad, la estabilidad y la competitividad en la nueva generación de redes. ¿Por qué es más que necesario el IPv6? ¡Es fundamental para su proveedor! La adopción de IPv6 va mucho más allá de una simple actualización técnica: se trata de una decisión estratégica que repercute directamente en el presente y el futuro de su empresa. Al eliminar las limitaciones del IPv4, el IPv6 abre nuevas perspectivas en materia de conectividad, con un mayor número de direcciones, mayor seguridad, menor latencia y un rendimiento superior. Todo ello con un mayor control y escalabilidad de la red. Los proveedores que ya han migrado están obteniendo resultados: operaciones más eficientes, menor dependencia de soluciones provisionales como el CGNAT y una mayor preparación para tecnologías como el 5G, el IoT, la automatización y las aplicaciones en tiempo real. El cliente final también nota la diferencia gracias a una navegación más rápida, conexiones más estables y una experiencia optimizada para juegos, llamadas, streaming y acceso remoto. IPv6 no es solo el futuro. Es una ventaja competitiva ya en la actualidad. Cómo implementar el IPv6 de forma segura y eficiente La migración a IPv6 no tiene por qué ser compleja. Con una planificación adecuada, se lleva a cabo de forma gradual, segura y sin que ello afecte a sus clientes. El secreto está en comprender las ventajas reales, preparar a su equipo y seguir una estructura bien definida. Descubra cómo el IPv6 aporta un valor inmediato a su proveedor —y al usuario final—. ¿Cuáles son los beneficios reales para su proveedor? ¿Y para sus clientes? Una experiencia de primer nivel. Cómo ponerlo en práctica: guía paso a paso simplificada Errores habituales que pueden poner en peligro su transición La transición ya ha comenzado y quien esté a la cabeza ahora, tomará la delantera La migración a IPv6 ya no es una posibilidad futura. Es una realidad en curso y quienes la adopten ahora obtendrán las ventajas antes que sus competidores. Más rendimiento. Más seguridad. Más escalabilidad. Menos costes operativos. Los proveedores que lideran este cambio aportan más valor a sus clientes, evitan los cuellos de botella técnicos y se posicionan con firmeza ante las exigencias de un mercado cada vez más conectado, automatizado y exigente. Con el apoyo adecuado, una planificación técnica y una ejecución estructurada, su empresa podrá llevar a cabo esta transición de forma segura, gradual y eficiente, sin comprometer la calidad del servicio. Made4it puede acompañarle en este proceso.Póngase en contacto con nuestro equipo y descubra cómo podemos acelerar su transición hacia una infraestructura preparada para el futuro.