Материал предназначен только для образовательных целей и не является инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
Краткий ответ
Eclipse-атака изолирует целевой узел от добросовестных пиров, устанавливая контроль над всеми или достаточным числом его сетевых соединений. После этого атакующий может задерживать, подавлять или выборочно передавать блоки и транзакции, формируя для жертвы подконтрольное ему представление о сети.
Узел-жертва может продолжать проверять подписи, доказательство работы и все остальные правила консенсуса. Однако это не означает, что его представление полно и актуально. Узел с полной валидацией способен отклонять некорректные данные, но при этом оставаться на корректной, однако устаревшей ветви, не видеть конфликтующую транзакцию или ошибочно воспринимать решения остальной сети.
Это не атака большинства на всю сеть. Атакующий воздействует на один узел или ограниченную группу узлов на одноранговом уровне, и ему не требуется контролировать большую часть вычислительной мощности или доли участия сети. Sybil-атака может способствовать eclipse-атаке, предоставляя множество подконтрольных атакующему идентификаторов или адресов, но эти понятия не тождественны: Sybil означает размножение идентификаторов, а eclipse — успешную изоляцию информационного поля жертвы.
Как происходит изоляция
Одноранговые клиенты обнаруживают и сохраняют адреса-кандидаты, выбирают исходящих пиров, принимают часть входящих соединений и переподключаются после сбоев или перезапусков. Конкретные алгоритмы зависят от клиента и версии. Атакующий ищет способ сместить достаточное число этих решений в пользу подконтрольной ему инфраструктуры.
Типичный сценарий атаки состоит из 4 этапов:
- Подготовка подконтрольных пиров. Атакующий запускает доступные из сети узлы или идентификаторы на адресах, которые правила выбора пиров жертвы, вероятно, сочтут различными.
- Смещение набора кандидатов. Вредоносные пиры распространяют подконтрольные атакующему адреса или иным способом пытаются вытеснить добросовестные записи из менеджера адресов жертвы. Практическая осуществимость зависит от устройства корзин, правил сетевых групп, ограничений частоты и качества уже сохраненных адресов.
- Провоцирование или ожидание переподключения. Перезапуск, нестабильность соединений, отказ в обслуживании или нарушение маршрутизации могут заставить цель заменить добросовестных пиров. Изоляция проще, если у цели мало независимых путей или изначально слабая база адресов.
- Монополизация и фильтрация. Когда нужные соединения жертвы ведут к атакующему, тот передает только выбранные блоки и транзакции, зачастую не нарушая правила консенсуса, чтобы избежать немедленного отклонения.
Исследование USENIX 2015 года продемонстрировало этот класс атак на тогдашней реализации одноранговой сети Bitcoin и описало последствия, включая двойную трату с опорой на подтверждения, содействие эгоистичному майнингу и враждебные форки. Приведенные в нем оценки ресурсов и особенности клиента имеют исторический характер и не являются универсальными константами для современного Bitcoin Core или других сетей.
Современные клиенты могут повышать стоимость изоляции с помощью рандомизированного и сегментированного хранения адресов, разнообразия источников пиров, проверочных соединений, защищенных исходящих соединений или каналов ретрансляции блоков, якорей между перезапусками, правил вытеснения и ограничений на ретрансляцию адресов. Это многоуровневые меры снижения риска, а не доказательство невозможности eclipse-атак.
Пример с платежом и реагирование
Предположим, узел продавца получил платеж и показывает 6 confirmations. Атакующий, изолировавший этот узел, может демонстрировать ему поддерживаемую втайне корректную ветвь с платежом, тогда как добросовестная сеть принимает конфликтующую транзакцию. Если продавец передаст необратимо отчуждаемый товар, полагаясь только на изолированный узел, отображаемое число не доказывает, что добросовестная сеть подтвердила платеж.
При реагировании на инцидент следует сохранить доказательства до внесения нарушающих работу изменений:
- Зафиксируйте заявленную вершину цепочки, накопленную работу, хеши недавних блоков, список пиров, направление соединений, тип сети, сопоставленную автономную систему при наличии и временные метки последнего полученного блока.
- Сравните вершину и состояние транзакции с независимо управляемыми узлами, доступными через действительно отдельные сетевые и административные пути. Публичные обозреватели блоков полезны только тогда, когда их инфраструктура также независима.
- При расхождении независимых представлений приостановите расчеты на крупные суммы или автоматическую выдачу. Дополнительные подтверждения в том же изолированном представлении проблему не устраняют.
- Перейдите на заведомо исправные ПО и конфигурацию, проверьте DNS, маршрутизацию, межсетевой экран, прокси и возможный взлом хоста, затем перестройте состояние пиров согласно документированной процедуре восстановления клиента.
- Восстанавливайте соединения постепенно и проверяйте разнообразие пиров, сетевых групп, поступления блоков, работы цепочки и наблюдений транзакций. Не восстанавливайте вслепую потенциально отравленную базу пиров.
- Сохраните журналы и передайте инцидент команде безопасности узла или протокола. Предполагаемая eclipse-атака может совпасть с обычным сбоем, инцидентом маршрутизации или более широким компрометированием хоста.
В Bitcoin Core 30.0 команда getpeerinfo возвращает такие поля, как network, mapped_as, inbound, last_block, synced_headers, synced_blocks и connection_type. Они помогают в расследовании, но ни одно поле само по себе не доказывает изоляцию. Система мониторинга должна установить нормальный базовый уровень и сопоставлять концентрацию пиров с независимыми наблюдениями за цепочкой.
Риски и меры контроля
- Двойная трата против получателя: жертве могут показать подтверждения в подконтрольной атакующему ветви. Для дорогостоящей или необратимой выдачи требуйте независимого наблюдения и устанавливайте лимиты с учетом риска расчетов.
- Нарушение майнинга или работы валидатора: изолированный оператор может работать с устаревшими данными, терять доход или помогать враждебной ветви. Контролируйте работу цепочки, актуальность вершины и разнообразие пиров вне производственного узла.
- Выборочная цензура: атакующий может скрывать транзакции или задерживать блоки, не отправляя некорректные данные. Настройте предупреждения о необычных интервалах поступления блоков и расхождениях независимых наблюдателей.
- Сбой моста, оракула или RPC: внесетевые сервисы, доверяющие одному вышестоящему узлу, могут передать устаревшее состояние или пропустить реорганизацию. Используйте несколько источников данных с независимым администрированием и сетевой инфраструктурой, а также явными правилами кворума и актуальности.
- Ложная уверенность из-за числа соединений: 20 пиров под управлением одной организации, в одной сети или из одного источника адресов могут давать меньше независимости, чем небольшой разнообразный набор. Измеряйте разнообразие, а не только количество.
- Централизация из-за фиксированных пиров: один заданный вручную доверенный пир позволяет обойти отравленный набор кандидатов, но создает единую точку отказа. Если фиксированные якоря уместны, используйте несколько независимо управляемых путей и сохраняйте случайные соединения.
Операторам узлов следует своевременно обновлять поддерживаемые версии клиентов, понимать характерные для клиента настройки управления пирами по умолчанию, защищать административный доступ и контролировать топологию как входящих, так и исходящих соединений. Операторам платежных и протокольных систем следует разделять подписание, трансляцию, наблюдение за цепочкой и решение о выдаче, чтобы один изолированный узел не мог самостоятельно разрешить необратимое действие.
Распространенные заблуждения
- Полный узел невозможно обмануть. Полный узел отклоняет данные, нарушающие консенсус, но не узнает автоматически, что добросовестные пиры скрывают от него лучшую корректную цепочку.
- Большого числа подтверждений всегда достаточно. Подтверждения имеют смысл только относительно наблюдаемого представления цепочки. При вероятной изоляции важна независимость пути наблюдения.
- Большее число пиров всегда решает проблему. Дополнительные пиры полезны, только если их владельцы, сетевые пути, источники обнаружения и режимы отказа достаточно независимы.
- Eclipse-атака и Sybil-атака — одно и то же. Ресурсы Sybil могут облегчить изоляцию, но eclipse-атака представляет собой возникший в результате контроль над представлением жертвы о пирах.
- Совпадение с одним обозревателем блоков доказывает исправность узла. Обозреватель может использовать тот же вышестоящий провайдер, сетевой путь или административный домен, что и затронутая система.
- Любой отстающий узел подвергается атаке. Сходные симптомы могут вызывать дефекты ПО, перегрузка, обслуживание, сбои маршрутизации и нехватка ресурсов. Рассматривайте eclipse-атаку как гипотезу, проверяемую по нескольким сигналам.
Связанные темы
Источники
- Eclipse Attacks on Bitcoin’s Peer-to-Peer Network - USENIX Association (дата обращения: 2026-08-20)
- Bitcoin Core RPC: getpeerinfo - Bitcoin Core (дата обращения: 2026-08-20)
- Bitcoin Core: connection_types.cpp - Bitcoin Core (дата обращения: 2026-08-20)