교육 목적으로만 제공되며 투자 조언이 아닙니다. 투자로 인해 손실이 발생할 수 있습니다.
핵심 답변
이클립스 공격은 대상 노드의 네트워크 연결 전부 또는 격리에 충분한 수를 장악해 정직한 피어로부터 고립시키는 공격입니다. 공격자는 이후 블록과 트랜잭션을 지연하거나 차단하거나 선별적으로 전달하여 피해 노드가 공격자에 의해 왜곡된 네트워크 관점을 보게 할 수 있습니다.
피해 노드는 서명, 작업 증명 및 다른 모든 합의 규칙을 계속 검증할 수 있습니다. 하지만 그렇다고 노드가 보는 정보가 완전하거나 최신이라는 뜻은 아닙니다. 모든 검증을 수행하는 노드도 무효 데이터를 거부하면서 유효하지만 오래된 분기에 머물거나, 충돌하는 트랜잭션을 보지 못하거나, 더 넓은 네트워크가 무엇을 받아들였는지 잘못 판단할 수 있습니다.
이는 네트워크 전체를 대상으로 하는 과반수 공격과 다릅니다. 공격자는 P2P 계층에서 노드 하나 또는 제한된 수의 노드를 노리며, 네트워크 채굴 능력이나 지분의 대부분을 장악할 필요가 없습니다. 시빌 공격은 공격자가 제어하는 다수의 신원이나 주소를 제공해 이클립스 공격을 도울 수 있지만 두 개념은 같지 않습니다. 시빌 공격은 신원의 증식을 뜻하고, 이클립스 공격은 피해자의 정보 관점을 성공적으로 격리한 상태를 뜻합니다.
격리가 이루어지는 방식
P2P 클라이언트는 후보 주소를 찾고 저장하며, 아웃바운드 피어를 선택하고 일부 인바운드 피어를 받아들인 뒤, 연결 실패나 재시작 후 다시 연결합니다. 구체적인 알고리즘은 클라이언트와 버전에 따라 다릅니다. 공격자는 이러한 결정 중 충분한 수를 자신이 제어하는 인프라로 편향시킬 방법을 찾습니다.
일반적인 공격 경로는 다음 4 단계로 이루어집니다.
- 공격자가 제어하는 피어를 준비합니다. 공격자는 피해 노드의 피어 선택 규칙에서 서로 독립된 것으로 취급될 가능성이 높은 여러 주소에 접속 가능한 노드나 신원을 운영합니다.
- 후보 집합을 편향시킵니다. 악성 피어는 공격자 소유 주소를 알리거나 다른 방법으로 피해 노드의 주소 관리자에서 정직한 항목을 밀어내려 합니다. 실제 성공 가능성은 버킷 설계, 네트워크 그룹 규칙, 속도 제한 및 이미 저장된 주소의 품질에 따라 달라집니다.
- 재연결을 유발하거나 기다립니다. 재시작, 잦은 연결 교체, 서비스 거부 또는 라우팅 장애로 인해 대상이 정직한 피어를 교체할 수 있습니다. 대상에 독립적인 경로가 적거나 초기 주소 데이터베이스가 취약하면 더 쉽게 격리됩니다.
- 연결을 독점하고 정보를 선별합니다. 피해 노드의 관련 연결이 공격자에게만 이어지면 공격자는 선택한 블록과 트랜잭션만 전달합니다. 즉시 거부되지 않도록 합의 규칙을 지키는 경우가 많습니다.
2015 년 USENIX 연구는 당시 비트코인의 P2P 구현을 대상으로 이 공격 유형을 입증하고, 확인을 이용한 이중 지불, 이기적 채굴 지원 및 적대적 포크 등의 결과를 설명했습니다. 연구에 나온 구체적인 자원 추정치와 클라이언트 세부 사항은 당시 상황을 반영한 것이며, 현재 Bitcoin Core나 다른 네트워크에 보편적으로 적용되는 상수가 아닙니다.
현대 클라이언트는 무작위화되고 분할된 주소 저장소, 다양한 피어 출처, 테스트 연결, 보호되는 아웃바운드 또는 블록 릴레이 연결, 재시작 이후에도 유지되는 앵커, 연결 퇴출 규칙 및 주소 릴레이 제한을 통해 격리에 드는 비용을 높일 수 있습니다. 이는 여러 겹의 완화책이지, 이클립스 공격이 불가능하다는 증명은 아닙니다.
결제 사례와 대응
판매자의 노드가 결제를 받고 6 confirmations를 표시한다고 가정해 보겠습니다. 해당 노드를 격리한 공격자는 결제가 포함된 유효한 분기를 비공개로 유지해 보여 주는 한편, 정직한 네트워크에서는 충돌하는 트랜잭션이 승인되도록 할 수 있습니다. 판매자가 격리된 노드만 믿고 되돌릴 수 없는 상품을 인도한다면, 표시된 확인 수는 정직한 네트워크가 그 결제를 확인했다는 증거가 아닙니다.
사고 대응 시에는 시스템을 크게 변경하기 전에 증거를 보존해야 합니다.
- 보고된 체인 끝, 누적 작업량, 최근 블록 해시, 피어 목록, 연결 방향, 네트워크 유형, 확인 가능한 경우 매핑된 자율 시스템, 마지막 블록 수신 시각을 기록합니다.
- 체인 끝과 트랜잭션 상태를 실제로 분리된 네트워크 및 관리 경로를 통해 접속하는 독립 운영 노드와 비교합니다. 공개 블록 탐색기도 인프라가 독립적일 때만 유용합니다.
- 독립된 관점이 서로 다르면 고액 결제나 자동 인도를 중단합니다. 동일한 격리 관점에서 확인 수만 늘려도 문제가 해결되지 않습니다.
- 신뢰할 수 있는 것으로 확인된 소프트웨어와 설정으로 전환하고 DNS, 라우팅, 방화벽, 프록시 및 호스트 침해 여부를 조사하며, 클라이언트에 문서화된 복구 절차에 따라 피어 상태를 재구성합니다.
- 단계적으로 재연결하고 피어, 네트워크 그룹, 블록 도착, 체인 작업량 및 트랜잭션 관측이 다양해지는지 확인합니다. 오염되었을 수 있는 피어 데이터베이스를 무작정 복원해서는 안 됩니다.
- 로그를 보존하고 노드 또는 프로토콜 보안팀에 보고합니다. 이클립스 공격으로 의심되는 상황이 일반적인 서비스 중단, 라우팅 사고 또는 더 광범위한 호스트 침해와 겹칠 수 있습니다.
Bitcoin Core 30.0에서 getpeerinfo는 network, mapped_as, inbound, last_block, synced_headers, synced_blocks, connection_type 등의 필드를 제공합니다. 이 필드들은 조사에 도움이 되지만 어느 하나만으로 격리를 입증할 수는 없습니다. 모니터링 시스템은 정상 기준선을 정하고 피어 집중도를 독립적인 체인 관측 결과와 연관 지어 분석해야 합니다.
위험과 통제 방안
- 수취인을 상대로 한 이중 지불: 피해자는 공격자가 제어하는 분기에서 생성된 확인을 볼 수 있습니다. 고액 또는 취소할 수 없는 인도에는 독립적인 관측을 요구하고 결제 위험에 맞는 한도를 설정해야 합니다.
- 채굴 또는 검증인 업무 방해: 격리된 운영자는 오래된 정보를 바탕으로 작업해 수익을 잃거나 적대적인 분기를 도울 수 있습니다. 프로덕션 노드 외부에서 체인 작업량, 체인 끝의 최신성 및 피어 다양성을 모니터링해야 합니다.
- 선택적 검열: 공격자는 무효 데이터를 보내지 않고도 트랜잭션을 숨기거나 블록을 지연할 수 있습니다. 비정상적인 블록 도착 간격과 독립 관측자 간의 불일치에 경보를 설정해야 합니다.
- 브리지, 오라클 및 RPC 장애: 하나의 업스트림 노드를 신뢰하는 오프체인 서비스는 오래된 상태를 전달하거나 체인 재구성을 놓칠 수 있습니다. 관리 주체와 네트워크가 독립적인 여러 데이터 소스를 사용하고 명확한 정족수 및 최신성 규칙을 적용해야 합니다.
- 연결 수에서 비롯되는 잘못된 확신: 하나의 조직, 네트워크 또는 주소 출처가 제어하는 20 개 피어는 규모가 더 작더라도 다양한 집합보다 독립성이 낮을 수 있습니다. 수량뿐 아니라 다양성을 측정해야 합니다.
- 고정 피어로 인한 중앙화: 수동으로 설정한 신뢰 피어 하나는 오염된 후보 풀을 우회할 수 있지만 단일 장애점이 됩니다. 고정 앵커가 적절하다면 독립적으로 운영되는 여러 경로를 사용하고 무작위 연결도 유지해야 합니다.
노드 운영자는 지원되는 클라이언트 릴리스를 최신 상태로 유지하고, 클라이언트별 피어 관리 기본값을 이해하며, 관리자 접근을 보호하고, 인바운드와 아웃바운드 토폴로지를 모두 모니터링해야 합니다. 결제 및 프로토콜 운영자는 서명, 브로드캐스트, 체인 관측 및 인도 결정을 분리해 하나의 격리된 노드가 되돌릴 수 없는 작업을 단독으로 승인하지 못하게 해야 합니다.
흔한 오해
- 전체 노드는 속지 않습니다. 전체 노드는 합의에 어긋나는 무효 데이터를 거부하지만, 정직한 피어가 더 나은 유효 체인을 보여 주지 않고 있다는 사실을 자동으로 알지는 못합니다.
- 확인 수가 많으면 언제나 충분합니다. 확인은 관측 중인 체인 관점 안에서만 의미가 있습니다. 격리 가능성이 있다면 관측 경로의 독립성이 중요합니다.
- 피어를 늘리면 항상 문제가 해결됩니다. 추가 피어는 소유권, 네트워크 경로, 발견 출처 및 장애 양상이 충분히 독립적일 때만 도움이 됩니다.
- 이클립스 공격과 시빌 공격은 같습니다. 시빌 공격의 자원은 격리를 더 쉽게 만들 수 있지만, 이클립스 공격은 피해 노드의 피어 관점을 장악한 결과를 뜻합니다.
- 하나의 블록 탐색기와 결과가 같으면 노드가 정상임을 입증합니다. 탐색기가 영향을 받은 시스템과 업스트림 제공자, 네트워크 경로 또는 관리 도메인을 공유할 수 있습니다.
- 오래된 상태를 보이는 노드는 모두 공격받고 있습니다. 소프트웨어 결함, 혼잡, 유지 보수, 라우팅 장애 및 자원 고갈도 비슷한 증상을 일으킬 수 있습니다. 이클립스 공격은 가설로 두고 여러 신호를 통해 검증해야 합니다.
관련 주제
출처
- 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)