--- title: "Ataque de eclipse: aislamiento, detección y defensa de nodos" description: "Aprende cómo un ataque de eclipse aísla un nodo de blockchain, por qué los datos válidos aún pueden crear una visión falsa de la red y cómo la diversidad de pares y las comprobaciones independientes reducen el riesgo." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Ataque de eclipse: aislamiento, detección y defensa de nodos > Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas. ## Respuesta directa Un **ataque de eclipse** aísla un nodo objetivo de los pares honestos mediante el control de todas sus conexiones de red, o de una cantidad suficiente de ellas. El atacante puede entonces retrasar, bloquear o retransmitir selectivamente bloques y transacciones para que la víctima vea una versión de la red moldeada por él. La víctima puede seguir validando firmas, pruebas de trabajo y todas las demás reglas de consenso. Eso no garantiza que su visión sea completa ni esté actualizada. Un nodo que valida por completo puede rechazar datos no válidos y, aun así, quedar confinado en una rama válida pero obsoleta, no llegar a ver una transacción conflictiva o formarse una idea equivocada de lo que ha aceptado el resto de la red. Esto difiere de un ataque mayoritario contra toda la red. El atacante se dirige a un nodo o a un conjunto limitado de nodos en la capa entre pares, sin necesidad de controlar la mayor parte de la potencia de minería ni de la participación de la red. Un ataque Sybil puede facilitar un ataque de eclipse al aportar numerosas identidades o direcciones controladas por el atacante, pero no son conceptos idénticos: Sybil describe la multiplicación de identidades; eclipse describe el aislamiento efectivo de la visión informativa de una víctima. ## Cómo funciona el aislamiento Los clientes entre pares descubren direcciones candidatas, las almacenan, seleccionan pares salientes, aceptan algunas conexiones entrantes y vuelven a conectarse después de fallos o reinicios. Los algoritmos exactos varían según el cliente y la versión. El atacante busca la manera de sesgar suficientes decisiones hacia la infraestructura que controla. Una ruta de ataque habitual tiene 4 etapas: 1. **Preparar pares controlados por el atacante.** El atacante opera nodos o identidades accesibles mediante direcciones que las reglas de selección de pares de la víctima probablemente consideren distintas. 2. **Sesgar el conjunto de candidatos.** Los pares maliciosos anuncian direcciones controladas por el atacante o intentan desplazar las entradas honestas del gestor de direcciones de la víctima por otros medios. La viabilidad práctica depende del diseño de los depósitos, las reglas de agrupación de red, los límites de frecuencia y la calidad de las direcciones ya almacenadas. 3. **Provocar o esperar una reconexión.** Un reinicio, la rotación de conexiones, una denegación de servicio o una interrupción del enrutamiento pueden llevar al objetivo a sustituir pares honestos. El aislamiento resulta más sencillo cuando el objetivo cuenta con pocas rutas independientes o parte de una base de datos de direcciones deficiente. 4. **Monopolizar y filtrar.** Una vez que las conexiones relevantes de la víctima conducen al atacante, este solo retransmite los bloques y las transacciones elegidos, a menudo sin infringir las reglas de consenso para evitar un rechazo inmediato. El estudio de USENIX de 2015 demostró esta clase de ataque contra la implementación entre pares de Bitcoin vigente entonces y describió consecuencias como el doble gasto basado en confirmaciones, la ayuda a la minería egoísta y las bifurcaciones adversarias. Sus estimaciones concretas de recursos y los detalles del cliente son datos históricos, no constantes universales aplicables a Bitcoin Core actual ni a otras redes. Los clientes modernos pueden elevar el coste del aislamiento mediante almacenamiento de direcciones aleatorio y segmentado, diversidad de fuentes de pares, conexiones de prueba, conexiones salientes o de retransmisión de bloques protegidas, anclajes que persisten entre reinicios, reglas de expulsión y límites a la retransmisión de direcciones. Son mitigaciones por capas, no pruebas de que los ataques de eclipse sean imposibles. ## Ejemplo de pago y respuesta Supongamos que el nodo de un comerciante recibe un pago y muestra `6 confirmations`. Un atacante que haya aislado ese nodo puede mostrarle una rama válida mantenida en privado que contenga el pago, mientras en la red honesta se acepta una transacción conflictiva. Si el comerciante entrega bienes irreversibles basándose solo en el nodo aislado, el número mostrado no demuestra que la red honesta haya confirmado el pago. La respuesta al incidente debe preservar las pruebas antes de realizar cambios disruptivos: - Registra la punta de cadena indicada, el trabajo acumulado, los hashes de bloques recientes, la lista de pares, la dirección de las conexiones, el tipo de red, el sistema autónomo asignado cuando esté disponible y las marcas de tiempo del último bloque recibido. - Compara la punta y el estado de la transacción con nodos operados de forma independiente a los que se acceda mediante rutas de red y administrativas realmente separadas. Los exploradores públicos solo son útiles si su infraestructura también es independiente. - Pausa la liquidación de operaciones de alto valor o la entrega automatizada cuando las visiones independientes no coincidan. Más confirmaciones de la misma visión aislada no resuelven el problema. - Cambia a software y configuración de confianza, investiga posibles problemas en DNS, enrutamiento, cortafuegos y proxy, así como una posible intrusión en el host, y reconstruye el estado de los pares según el procedimiento de recuperación documentado por el cliente. - Vuelve a conectar gradualmente y verifica que se diversifiquen los pares, los grupos de red, la llegada de bloques, el trabajo de cadena y las observaciones de transacciones. No restaures a ciegas una base de datos de pares que podría estar contaminada. - Conserva los registros y escala el caso al equipo de seguridad del nodo o del protocolo. Una sospecha de eclipse puede coincidir con interrupciones ordinarias, incidentes de enrutamiento o una intrusión más amplia en el host. En Bitcoin Core 30.0, `getpeerinfo` expone campos como `network`, `mapped_as`, `inbound`, `last_block`, `synced_headers`, `synced_blocks` y `connection_type`. Estos campos ayudan en la investigación, pero ninguno demuestra por sí solo que exista aislamiento. La supervisión debe establecer una referencia normal y correlacionar la concentración de pares con observaciones independientes de la cadena. ## Riesgos y controles - **Doble gasto contra un receptor:** se pueden mostrar a la víctima confirmaciones de una rama controlada por el atacante. Exige observación independiente para entregas irreversibles o de alto valor y fija límites acordes con el riesgo de liquidación. - **Interrupción de mineros o validadores:** un operador aislado puede trabajar con información obsoleta, perder ingresos o favorecer una rama adversaria. Supervisa el trabajo de cadena, la actualidad de la cabecera y la diversidad de pares fuera del nodo de producción. - **Censura selectiva:** el atacante puede ocultar transacciones o retrasar bloques sin enviar datos no válidos. Genera alertas ante intervalos de llegada de bloques inusuales y discrepancias entre observadores independientes. - **Fallo de puentes, oráculos y RPC:** los servicios externos a la cadena que confían en un único nodo ascendente pueden retransmitir un estado obsoleto o no detectar una reorganización. Utiliza varias fuentes de datos administradas y conectadas a la red de forma independiente, con reglas explícitas de cuórum y actualidad. - **Falsa confianza por el número de conexiones:** 20 pares controlados por una organización, una red o una fuente de direcciones pueden aportar menos independencia que un conjunto diverso más pequeño. Mide la diversidad, no solo la cantidad. - **Centralización mediante pares fijos:** un único par de confianza configurado manualmente puede eludir un conjunto de candidatos contaminado, pero crea un punto único de fallo. Si conviene usar anclajes fijos, emplea varias rutas operadas de forma independiente y conserva conexiones aleatorias. Los operadores de nodos deben mantener al día las versiones compatibles del cliente, comprender los valores predeterminados de gestión de pares específicos de cada cliente, proteger el acceso administrativo y supervisar tanto la topología entrante como la saliente. Los operadores de pagos y protocolos deben separar la firma, la difusión, la observación de la cadena y las decisiones de entrega, de modo que un solo nodo aislado no pueda autorizar por sí mismo una acción irreversible. ## Errores comunes - **No se puede engañar a un nodo completo.** Un nodo completo rechaza los datos que infringen el consenso; no sabe automáticamente si los pares honestos le están ocultando una cadena válida mejor. - **Un número alto de confirmaciones siempre es suficiente.** Las confirmaciones solo tienen sentido con respecto a la visión de la cadena observada. La independencia de la ruta de observación importa cuando el aislamiento es plausible. - **Tener más pares siempre resuelve el problema.** Los pares adicionales solo ayudan si su propiedad, sus rutas de red, sus fuentes de descubrimiento y sus modos de fallo son suficientemente independientes. - **Los ataques de eclipse y Sybil son lo mismo.** Los recursos Sybil pueden facilitar el aislamiento, pero un ataque de eclipse es el control resultante de la visión de pares de una víctima. - **Un explorador de bloques que coincide demuestra que el nodo está sano.** El explorador puede compartir un proveedor ascendente, una ruta de red o un dominio administrativo con el sistema afectado. - **Todo nodo obsoleto está bajo ataque.** Los defectos de software, la congestión, el mantenimiento, los fallos de enrutamiento y el agotamiento de recursos pueden producir síntomas parecidos. Trata el eclipse como una hipótesis que debe comprobarse con múltiples señales. ## Temas relacionados - [Nodo completo](/es/crypto/full-node/) - [Red entre pares](/es/crypto/peer-to-peer-network/) - [Ataque Sybil](/es/crypto/sybil-attack/) - [Confirmación de bloque](/es/crypto/block-confirmation/) - [Reorganización de cadena](/es/crypto/chain-reorg/) ## Fuentes - [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (consultado: 2026-08-20) - [Bitcoin Core RPC: getpeerinfo](https://bitcoincore.org/en/doc/30.0.0/rpc/network/getpeerinfo/) - Bitcoin Core (consultado: 2026-08-20) - [Bitcoin Core: connection_types.cpp](https://github.com/bitcoin/bitcoin/blob/v30.0/src/node/connection_types.cpp) - Bitcoin Core (consultado: 2026-08-20) Source: https://wiki.fcontext.com/es/crypto/eclipse-attack/index.mdx