--- title: "Attacco eclipse: isolamento, rilevamento e difesa dei nodi" description: "Scopri come un attacco eclipse isola un nodo blockchain, perché dati validi possono comunque creare una falsa visione della rete e come la diversità dei peer e i controlli indipendenti riducono il rischio." 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. # Attacco eclipse: isolamento, rilevamento e difesa dei nodi > Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite. ## Risposta diretta Un **attacco eclipse** isola un nodo bersaglio dai peer onesti controllando tutte le sue connessioni di rete, o un numero sufficiente di esse. L'attaccante può quindi ritardare, sopprimere o inoltrare selettivamente blocchi e transazioni, facendo sì che la vittima veda una rappresentazione della rete modellata dall'attaccante. La vittima può continuare a convalidare firme, prova di lavoro e ogni altra regola di consenso. Questo non rende la sua visione completa o aggiornata. Un nodo che esegue la convalida completa può rifiutare dati non validi e tuttavia essere mantenuto su un ramo valido ma obsoleto, non riuscire a vedere una transazione in conflitto o essere indotto a una percezione errata di ciò che la rete più ampia ha accettato. Questo è diverso da un attacco di maggioranza esteso all'intera rete. L'attaccante prende di mira un nodo o un insieme limitato di nodi al livello peer-to-peer e non deve necessariamente controllare la maggior parte della potenza di mining o della partecipazione della rete. Un attacco Sybil può favorire un attacco eclipse fornendo molte identità o indirizzi controllati dall'attaccante, ma i concetti non sono identici: Sybil indica la moltiplicazione delle identità; eclipse indica l'isolamento riuscito della visione informativa della vittima. ## Come funziona l'isolamento I client peer-to-peer scoprono indirizzi candidati, li memorizzano, selezionano peer in uscita, accettano alcuni peer in entrata e si riconnettono dopo errori o riavvii. Gli algoritmi esatti variano in base al client e alla versione. L'attaccante cerca un modo per orientare un numero sufficiente di queste decisioni verso l'infrastruttura che controlla. Un tipico percorso di attacco comprende 4 fasi: 1. **Preparare peer controllati dall'attaccante.** L'attaccante gestisce nodi o identità raggiungibili tramite indirizzi che le regole di selezione dei peer della vittima considereranno probabilmente distinti. 2. **Condizionare l'insieme dei candidati.** I peer malevoli pubblicizzano indirizzi controllati dall'attaccante o cercano in altro modo di espellere le voci oneste dal gestore degli indirizzi della vittima. La fattibilità pratica dipende dalla struttura dei gruppi di indirizzi, dalle regole sui gruppi di rete, dai limiti di frequenza e dalla qualità degli indirizzi già memorizzati. 3. **Provocare o attendere una riconnessione.** Un riavvio, il ricambio delle connessioni, un attacco denial of service o un'interruzione del routing possono indurre il bersaglio a sostituire i peer onesti. L'isolamento è più facile quando il bersaglio dispone di pochi percorsi indipendenti o parte da un database di indirizzi debole. 4. **Monopolizzare e filtrare.** Quando le connessioni rilevanti della vittima conducono all'attaccante, quest'ultimo inoltra soltanto i blocchi e le transazioni prescelti, spesso rispettando le regole di consenso per evitare un rifiuto immediato. Lo studio USENIX del 2015 ha dimostrato questa classe di attacco contro l'implementazione peer-to-peer di Bitcoin in uso all'epoca e ne ha descritto conseguenze quali la doppia spesa basata sulle conferme, il sostegno al mining egoistico e le biforcazioni avversarie. Le stime specifiche delle risorse e i dettagli del client contenuti nello studio sono dati storici, non costanti universali per l'attuale Bitcoin Core o per altre reti. I client moderni possono aumentare il costo dell'isolamento mediante l'archiviazione casuale e segmentata degli indirizzi, la diversità delle fonti dei peer, connessioni di prova, connessioni in uscita o di inoltro dei blocchi protette, ancoraggi mantenuti tra i riavvii, regole di espulsione e limiti all'inoltro degli indirizzi. Si tratta di mitigazioni a più livelli, non di prove che gli attacchi eclipse siano impossibili. ## Esempio di pagamento e risposta Supponiamo che il nodo di un commerciante riceva un pagamento e mostri `6 confirmations`. Un attaccante che ha isolato quel nodo può mostrargli un ramo valido mantenuto privatamente che contiene il pagamento, mentre sulla rete onesta viene accettata una transazione in conflitto. Se il commerciante consegna beni non recuperabili basandosi solo sul nodo isolato, il numero visualizzato non dimostra che la rete onesta abbia confermato il pagamento. La risposta all'incidente dovrebbe preservare le prove prima di apportare modifiche dirompenti: - Registra la punta della catena segnalata, il lavoro cumulativo, gli hash dei blocchi recenti, l'elenco dei peer, la direzione delle connessioni, il tipo di rete, il sistema autonomo associato quando disponibile e le marche temporali dell'ultimo blocco ricevuto. - Confronta la punta e lo stato della transazione con nodi gestiti in modo indipendente e raggiunti attraverso percorsi di rete e amministrativi realmente separati. Gli explorer pubblici sono utili solo se anche la loro infrastruttura è indipendente. - Sospendi il regolamento di importi elevati o il rilascio automatico quando le visioni indipendenti non concordano. Un maggior numero di conferme dalla stessa visione isolata non risolve il problema. - Passa a software e configurazioni di comprovata affidabilità, esamina DNS, routing, firewall, proxy e una possibile compromissione dell'host, quindi ricostruisci lo stato dei peer secondo la procedura di ripristino documentata dal client. - Riconnettiti gradualmente e verifica che peer, gruppi di rete, arrivo dei blocchi, lavoro della catena e osservazioni delle transazioni si diversifichino. Non ripristinare alla cieca un database dei peer che potrebbe essere contaminato. - Conserva i log e segnala il caso al team di sicurezza del nodo o del protocollo. Un sospetto eclipse può sovrapporsi a normali interruzioni, incidenti di routing o a una più ampia compromissione dell'host. In Bitcoin Core 30.0, `getpeerinfo` espone campi quali `network`, `mapped_as`, `inbound`, `last_block`, `synced_headers`, `synced_blocks` e `connection_type`. Questi campi aiutano l'indagine, ma nessuno di essi dimostra da solo l'isolamento. Il monitoraggio deve stabilire un riferimento normale e correlare la concentrazione dei peer con osservazioni indipendenti della catena. ## Rischi e controlli - **Doppia spesa contro un destinatario:** alla vittima possono essere mostrate conferme su un ramo controllato dall'attaccante. Richiedi un'osservazione indipendente per consegne di valore elevato o irreversibili e stabilisci limiti che riflettano il rischio di regolamento. - **Interruzione di miner o validatori:** un operatore isolato può lavorare su informazioni obsolete, perdere ricavi o favorire un ramo avversario. Monitora il lavoro della catena, l'attualità della punta e la diversità dei peer al di fuori del nodo di produzione. - **Censura selettiva:** l'attaccante può nascondere transazioni o ritardare blocchi senza inviare dati non validi. Genera avvisi per intervalli insoliti nell'arrivo dei blocchi e per discordanze tra osservatori indipendenti. - **Malfunzionamento di bridge, oracoli e RPC:** i servizi off-chain che si affidano a un unico nodo a monte possono trasmettere uno stato obsoleto o non rilevare una riorganizzazione. Usa più fonti di dati amministrate e collegate alla rete in modo indipendente, con regole esplicite di quorum e aggiornamento. - **Falsa sicurezza derivante dal numero di connessioni:** 20 peer controllati da un'organizzazione, una rete o una fonte di indirizzi possono offrire meno indipendenza di un insieme più piccolo ma diversificato. Misura la diversità, non solo la quantità. - **Centralizzazione tramite peer fissi:** un unico peer fidato configurato manualmente può aggirare un insieme di candidati contaminato, ma crea un singolo punto di errore. Se gli ancoraggi fissi sono opportuni, usa più percorsi gestiti in modo indipendente e mantieni connessioni casuali. Gli operatori dei nodi dovrebbero mantenere aggiornate le versioni supportate del client, conoscere le impostazioni predefinite di gestione dei peer specifiche del client, proteggere l'accesso amministrativo e monitorare sia la topologia in entrata sia quella in uscita. Gli operatori di pagamenti e protocolli dovrebbero separare firma, trasmissione, osservazione della catena e decisioni di rilascio, affinché un solo nodo isolato non possa autorizzare autonomamente un'azione irreversibile. ## Idee sbagliate comuni - **Un nodo completo non può essere ingannato.** Un nodo completo rifiuta i dati non validi secondo il consenso; non sa automaticamente che peer onesti gli stanno nascondendo una catena valida migliore. - **Un numero elevato di conferme è sempre sufficiente.** Le conferme sono significative solo rispetto alla visione della catena osservata. Quando l'isolamento è plausibile, l'indipendenza del percorso di osservazione è importante. - **Più peer risolvono sempre il problema.** I peer aggiuntivi aiutano solo quando proprietà, percorsi di rete, fonti di scoperta e modalità di errore sono sufficientemente indipendenti. - **Gli attacchi eclipse e Sybil sono la stessa cosa.** Le risorse Sybil possono facilitare l'isolamento, ma un attacco eclipse è il conseguente controllo della visione dei peer della vittima. - **Un block explorer che mostra gli stessi dati dimostra che il nodo è integro.** L'explorer può condividere con il sistema interessato un fornitore a monte, un percorso di rete o un dominio amministrativo. - **Qualsiasi nodo obsoleto è sotto attacco.** Difetti del software, congestione, manutenzione, errori di routing ed esaurimento delle risorse possono produrre sintomi simili. Considera l'eclipse un'ipotesi da verificare con più segnali. ## Argomenti correlati - [Nodo completo](/it/crypto/full-node/) - [Rete peer-to-peer](/it/crypto/peer-to-peer-network/) - [Attacco Sybil](/it/crypto/sybil-attack/) - [Conferma dei blocchi](/it/crypto/block-confirmation/) - [Riorganizzazione della catena](/it/crypto/chain-reorg/) ## Fonti - [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (consultato: 2026-08-20) - [Bitcoin Core RPC: getpeerinfo](https://bitcoincore.org/en/doc/30.0.0/rpc/network/getpeerinfo/) - Bitcoin Core (consultato: 2026-08-20) - [Bitcoin Core: connection_types.cpp](https://github.com/bitcoin/bitcoin/blob/v30.0/src/node/connection_types.cpp) - Bitcoin Core (consultato: 2026-08-20) Source: https://wiki.fcontext.com/it/crypto/eclipse-attack/index.mdx