El eclipse de calabaza
(blog.lumen.com)- Aunque la URL es
the-pumpkin-eclipse, el cuerpo proporcionado no corresponde a un artículo sobre un eclipse de calabaza, sino a una página hub de blog y noticias de Lumen Technologies - El artículo destacado superior se centra en la necesidad de una red programable, escalable y segura en un contexto en el que la IA está cambiando la forma en que operan las empresas
- El plan de adquisición de Alkira por parte de Lumen se presenta como un ejemplo de cómo preparar el plano de control necesario para la conectividad cloud de próxima generación
- Otros contenidos destacados continúan con redes programables, el uso de Lumen y Zoom AI por parte de Bank of Tennessee, y un caso de soporte de conectividad para eventos globales de AWS
- Las secciones de noticias recientes y exploración ofrecen noticias corporativas, como ofertas de intercambio, ascensos ejecutivos y resultados de ofertas públicas de adquisición, junto con filtros por tema, industria y servicio
Naturaleza real de la página proporcionada
- El cuerpo corresponde a una página de hub de blog y noticias de Lumen Technologies, que reúne innovación tecnológica, estrategia y experiencia relacionadas con la transformación digital y la preparación para la IA
- La estructura de la página se divide en contenidos destacados, noticias recientes y un área de exploración de contenidos
- Aunque la ruta original de la URL es
the-pumpkin-eclipse, el cuerpo proporcionado no contiene contenido real de un artículo sobre un eclipse de calabaza
Flujo de contenidos destacados
- Establishing the control plane for cloud connectivity: presenta el contexto de que, a medida que la IA cambia la forma en que operan las empresas, las redes empresariales necesitan programabilidad, escalabilidad y seguridad
- El plan de adquisición de Alkira por parte de Lumen se vincula con la construcción del plano de control necesario para la conectividad cloud de próxima generación
- Is your network ready?: artículo centrado en la preparación de la red y las redes programables
- Modern banking starts here: how Bank of Tennessee elevated customer service with Lumen and Zoom AI: cubre el caso de Bank of Tennessee, que mejoró su servicio al cliente con Lumen y Zoom AI
- Powering AWS innovation: how Lumen delivers world-class connectivity for global events: se relaciona con el caso en que Lumen proporcionó conectividad para eventos globales de AWS
- La sección de artículos populares se muestra como no disponible para cargar en ese momento
Noticias recientes
- Lumen Technologies, Inc. and Qwest Corporation Announce Expiration and Final Results of Exchange Offers and Consent Solicitations: cubre el vencimiento y los resultados finales de las ofertas de intercambio y solicitudes de consentimiento de Lumen Technologies y Qwest Corporation
- Lumen Elevates Melissa Mann and Jessica Taylor to Chief Officer Roles, Strengthening Public Policy and Communications Leadership: Melissa Mann y Jessica Taylor fueron ascendidas a cargos de máxima responsabilidad
- Lumen Technologies, Inc. and Qwest Corporation Announce Entry into Support Agreement with Certain Noteholders and Amendment to Previously Announced Exchange Offers: cubre el acuerdo de apoyo con ciertos tenedores de bonos y las modificaciones a las ofertas de intercambio anunciadas previamente
- Lumen Technologies, Inc. Announces Early Results of Previously Announced Tender Offers: cubre los resultados iniciales de las ofertas públicas de adquisición anunciadas previamente
Filtros de exploración de contenidos
- Los filtros por tema incluyen Application Protection, Customer Success, Data Center, DIA, Ransomware, SD WAN, API, Artificial Intelligence, Cloud Computing, DDoS Protection, SASE, ZTNA, entre otros
- Los filtros por industria ofrecen Manufacturing, State and Local Government, Technology, Defense Intelligence, Federal Government, Education, Gaming, Healthcare, Retail, Financial Services, Public Safety, entre otros
- Los filtros por servicio se componen de Infrastructure services, Connectivity services, Security services, Communication services y Media Entertainment
1 comentarios
Opiniones de Hacker News
Estaría bien poder interceptar la línea de habilitación de escritura del chip flash que contiene el firmware para bloquear actualizaciones, y eliminar con un reinicio diario toda la basura que solo reside en memoria
Era una técnica que se usaba en receptores satelitales hace 20 años, y quizá ahora haya que tratar a todos los equipos conectados a internet como vulnerables a medidas de respuesta electrónicas similares
Al menos en mis equipos, me gustaría monitorear si hubo una actualización y que se encienda un indicador cuando ocurra, para saber si fue algo legítimo o no
Lo que no entiendo en este caso es por qué no se podía restaurar el dispositivo a su estado original. Si es posible destruir por completo todo el firmware, incluso el respaldo, entonces parece un mal diseño
También hay una emulación de código abierto para flash SPI: https://trmm.net/Spispy/
Algunas memorias USB (Kanguru) y gabinetes SSD (ElecGear M.2 2230 NVME) pueden bloquear escrituras mediante firmware e interruptores físicos, lo que resulta útil para arrancar una live ISO personalizada que corre desde RAM
A medida que se actualizan y mantienen la planta de cable y los equipos del headend, cambian cosas como el plan de frecuencias y las velocidades de señal, así que la configuración es bastante dinámica
Si intentas bloquear la habilitación de escritura del EEPROM, probablemente termines haciendo que falle el aprovisionamiento del módem
Al artículo le faltan detalles interesantes. Me pregunto cómo entraron, si estos routers traen puertos y servicios abiertos por defecto y si responden de forma significativa en internet
¿No se podrían comparar distintas versiones del firmware?
Parece que usan el enfoque común de montar el SDK del proveedor sobre OpenWrt: https://forum.openwrt.org/t/openwrt-support-for-actiontec-t3...
Lo interesante es que se especula con que el proveedor pudo haber enviado una actualización maliciosa o defectuosa: https://www.reddit.com/r/Windstream/comments/17g9qdu/solid_r...
Si fue así, ¿por qué no hubo un anuncio oficial del ISP? Si fue un ataque, ¿no debería haber una investigación? No sé cómo se manejan estas cosas en EE. UU., pero realmente se ve extraño
Tal vez estos equipos estaban infectados por bots y el proveedor les envió una actualización que terminó arruinándolos a todos
O quizá, como dice el artículo, fue un ataque coordinado que incluso incluyó ransomware, y a todos simplemente les dijeron “es una actualización de firmware defectuosa, mantengan la calma”
Desde la perspectiva del cliente, eso también es bastante malo, porque uno quiere saber si hubo un incidente de seguridad
Me pregunto si hay imágenes del firmware de estos dispositivos o enlaces con información más detallada
También me pregunto cuánto del costo de reemplazo cubrirá el seguro. Probablemente nada, y entonces el ISP estaría asumiendo un riesgo serio para la continuidad del negocio. Esa sería otra razón para no anunciarlo
Dice que “Lumen identificó más de 330 mil direcciones IP únicas que se comunicaron con uno de los 75 nodos C2 observados”, pero ¿cómo sabe la telemetría remota global de Black Lotus Labs qué IP se comunicó con cuál si no controla ninguno de los dos extremos? ¿Quién está guardando esos logs de tráfico y qué exactamente se está guardando?
Si ellos pueden hacerlo, me gustaría que me volvieran a explicar por qué Tor es seguro. Ya saben, esa explicación de que es imposible seguir los paquetes desde mi equipo pasando por los saltos de onion routing hasta el nodo de salida, y que en el nodo de salida esos mismos paquetes se ven sin cifrar
Una proporción enorme del tráfico mundial pasa por su red, así que probablemente sí puedan observar directamente el tráfico y sus indicadores
Claro, en el otro extremo está el caso de la NSA conectando taps a enlaces centrales de internet para registrar todo lo posible y guardarlo para siempre
Ojalá esto esté claramente especificado en los términos del contrato de Windstream
Aun así, cuanto más tráfico maneje un nodo, más difícil se vuelve
Un método más simple es simplemente operar un nodo de salida.[1]
1: https://en.wikipedia.org/wiki/Tor_(network)#Exit_node_eavesd...
Desde hace algunos años compré una pequeña caja x86 con NIC dual y corro OpenWRT. Es de código abierto, tiene mucho soporte, una buena comunidad y también soporta WireGuard.
La versión más reciente incluso puede ejecutar contenedores Docker.
Incluso un adaptador DSL para ranura PCIe es básicamente un sistema tipo stick; solo le falta la carcasa, pero tiene todas las funciones y bugs de un “router”.
Si metes una puerta trasera en 600 mil routers y en uno de los parches introduces un bug de firmware, pasa esto.
¿No podían haber desplegado las actualizaciones por etapas? Parece que los creadores y usuarios del malware son demasiado geniales como para aceptar prácticas operativas estándar.
No entiendo qué significa el título del artículo.
Es solo mi interpretación, pero yo también creo que el título es confuso.
Para quienes se confundieron por el título: no se trata de un router de 600 mil dólares, sino de 600 mil routers pequeños individuales que fueron destruidos.
Si HN tuviera puntos de karma, quizá podrían darle más al usuario que mejoró el pésimo título clickbait original.
Aquí se está usando tiempo presente para un incidente de octubre del año pasado.
Artículo relacionado de Ars Technica: https://arstechnica.com/security/2024/05/mystery-malware-des...
Compré una computadora tipo appliance de red para mi red doméstica. Básicamente es un i3 común con soporte VT-x, gabinete fanless y 4 NIC de 2.5GiB.
Instalé una distribución Linux estable que recibe actualizaciones automáticas de seguridad regulares tanto en el host como en la VM, y asigné 3 de las NIC a esa VM mediante mapeo de dispositivos. La NIC restante no está conectada a nada, salvo cuando quiero entrar al host por SSH.
Dentro de la VM manejo el firewall y el enrutamiento con UFW y Shorewall. Si quiero ajustar algo, simplemente entro por SSH a esa VM. También tengo snapshots del disco de la VM para poder volver fácilmente a un estado bueno y conocido si cometo un error.
También compré varios puntos de acceso WiFi comerciales más baratos y los distribuí por la casa, configurando los canales para minimizar la interferencia.
Antes había usado muchas veces productos de red de Apple, Google y ASUS, pero todos tuvieron problemas de rendimiento y estabilidad. Por ejemplo, durante reuniones de Zoom se cortaban paquetes de forma aleatoria durante 3 a 5 segundos, lo cual era desesperante.
Desde que armé esto por mi cuenta no he tenido ningún problema, está configurado de forma segura y además tengo más confianza en que recibe las actualizaciones de seguridad pertinentes. En resumen, salvo que una gran parte del mundo que usa la misma distribución Linux estable y conocida tenga problemas al mismo tiempo, mi red doméstica tampoco los tendrá.