За пределами смарт-контракта: операционная безопасность доменов и DNS в Web3

1. Точка входа за пределами блокчейна: где начинается операционная безопасность web3

Граница безопасности web3-проекта уже давно выходит за пределы его смарт-контрактов. Утечка серверных ключей, подмена фронтенда, перехват DNS-резолвинга — всё это происходит вне контракта, но напрямую влияет на то, какую страницу загружает пользователь и какую транзакцию он подписывает. Со стороны пользователя почти не имеет значения, произошла ли атака на уровне блокчейна или за его пределами. Важно то, был ли он направлен на неправильную точку входа.

Аудиты контрактов относительно зрелы. Операционная безопасность за пределами блокчейна — нет: долгое время не существовало общей структуры, которую команды проектов могли бы применять непрерывно, а третья сторона могла бы её проверить. SEAL Certifications [1], открытая система сертификации операционной безопасности, опубликованная Security Alliance, создана именно для устранения этого разрыва. Она разбивает операционную безопасность на шесть модулей: операции с мультиподписью, операции с казначейством, реагирование на инциденты, DevOps и инфраструктура, DNS и регистратор, а также управление идентификацией и учётными записями.

Эта статья следует по этой линии в один из шести модулей — DNS и регистратор. Он находится в самом начале пути, по которому пользователи попадают к проекту, что делает его наиболее прямым способом для злоумышленника обойти защиту на уровне контракта. Мы не пытались провести исчерпывающую оценку операционной безопасности. Мы заняли внешнюю точку наблюдения и задали более узкий вопрос: насколько хорошо настроены публичные точки входа, которые ведущие проекты предоставляют своим пользователям?

Чтобы ответить на этот вопрос, мы разработали BlockSec DNS Security Scanner (BDSS) на основе модуля SEAL DNS и регистратор [2], а затем прогнали его по 100 уникальным доменам, принадлежащим топ-100 проектов по TVL из DefiLlama — по восемь стандартизированных проверок для каждого, всего 800 проверок. После ручной проверки базовые пробелы оказались широко распространены и сконцентрированы в нескольких контролях: только 1% выборки прошёл все проверки, а более девяти из десяти доменов дали хотя бы один сигнал о проблеме в точке входа. У 72% отсутствовала запись CAA, а у 47% обнаружены дефекты валидации DNSSEC, при этом аутентификация электронной почты и блокировка домена также показали явные недостатки.

2. DNS и регистратор: граница безопасности перед пользователем

DNS превращает читаемое человеком доменное имя в достижимый адрес службы. Это точка входа за пределами блокчейна, через которую пользователи попадают на веб-сайт проекта, торговый фронтенд, документацию, бизнес-API и официальную электронную почту. Как только путь резолвинга или контроль над доменом скомпрометирован, пользователя можно незаметно перенаправить на поддельную страницу — и каждое последующее подключение кошелька, подпись и транзакция теряют свою основу. Поэтому DNS и регистратор не следует рассматривать как обычную конфигурацию инфраструктуры; они входят в границу операционной безопасности проекта.

Публичные инциденты уже сделали этот риск конкретным. Curve Finance подвергся перехвату DNS в 2022 году и снова в 2025 году [3][4]. В октябре 2023 года злоумышленник, применивший социальную инженерию, захватил учётную запись регистратора Galxe и направил посетителей на вредоносный фронтенд; проект сообщил, что было затронуто около 1 120 пользователей [5]. В 2025 году основной домен Aerodrome Finance подвергся атаке на фронтенд [6]. В апреле 2026 года злоумышленник получил контроль над доменом CoW Swap и направил пользователей на фишинговую страницу, при этом убытки оцениваются примерно в 1,2 миллиона долларов [7]. Более ранний случай перехвата BGP-маршрута cBridge подчёркивает ещё один момент: пользователи не всегда могут полагаться на предупреждение браузера, чтобы понять, что точка входа была скомпрометирована [8]. В каждом из этих случаев на смарт-контракт напрямую могло не влиять ничего, однако средства пользователей всё равно оказывались под угрозой, поскольку путь доступа был утрачен.

Причины различаются, но они сводятся к четырём векторам атаки, которые напрямую влияют на точку входа пользователя. Во-первых, злоумышленник изменяет записи DNS или путь резолвинга и направляет посетителей на вредоносный фронтенд. Во-вторых, механизмы контроля выдачи сертификатов обходятся или настроены неправильно, что позволяет поддельному сайту получить TLS-сертификат, доверенный браузером. В-третьих, учётная запись регистратора или контроль над доменом захватывается, что позволяет передать домен или изменить записи NS и другие критические записи. В-четвёртых, злоумышленник имитирует бренд или электронную почту проекта, чтобы заманить пользователей на фишинговую страницу. Все четыре варианта могут закончиться одинаково: пользователь попадает на неправильный интерфейс и его подталкивают к завершению неправильной подписи, разрешения или транзакции.

Суть в следующем: точка входа пользователя — это не отдельная веб-страница, а цепочка доверия, состоящая из контроля над доменом, резолвинга DNS, TLS-сертификатов и официальной коммуникации. Даже при безупречном смарт-контракте отказ одного звена позволяет злоумышленнику использовать собственный домен или бренд проекта, чтобы направить пользователей на неправильную страницу и в неправильный поток транзакций. Для команды проекта цель состоит не в исправлении одной изолированной настройки, а в обеспечении того, чтобы домен не мог быть передан без авторизации, резолвинг не мог быть тихо изменён, выдача сертификатов была должным образом ограничена, а официальную электронную почту было трудно подделать. Внешнее сканирование, представленное далее, охватывает ту часть этой цепочки, которая наблюдаема из публичного интернета.

3. BDSS: дизайн и охват

Чтобы превратить эти риски точки входа в задачи, над которыми команда может реально работать, мы создали BDSS на основе внешне наблюдаемых механизмов контроля из модуля SEAL DNS и регистратор [2]. Он не предназначен для замены внутренней проверки проекта. Он устанавливает базовый уровень для выявления публичных пробелов в конфигурации без обращения к какой-либо конфиденциальной операционной информации.

Модуль SEAL DNS и регистратор [2] устанавливает полную структуру оценки, охватывающую как технические механизмы контроля — резолвинг, сертификаты, электронную почту, контроль над доменом, — так и операционные требования, такие как управление доменными активами, контроль доступа к учётным записям, управление изменениями, мониторинг и оповещения, а также реагирование на инциденты.

BDSS сужает это до механизмов контроля, которые можно наблюдать и проверять извне, чтобы можно было масштабно выявлять сигналы риска публичной конфигурации по резолвингу, сертификатам, электронной почте и стороне регистратора. Он охватывает восемь стандартизированных проверок.

BDSS не является полной сертификацией безопасности DNS проекта. Механизмы контроля, которые невозможно проверить из публичного интернета — блокировка реестра, утверждение изменений, процедуры восстановления — всё ещё требуют проверки в соответствии с собственной документацией и процессами проекта.

4. Результаты внешнего сканирования по топ-100 DefiLlama

Оценка была завершена 17 августа 2026 года с использованием топ-100 проектов по TVL DefiLlama на эту дату. Основные домены были определены, начиная с публичных точек входа, представленных пользователям. Дублирующиеся кандидаты, неофициальные сайты и домены, назначение которых невозможно было определить, были исключены после ручной проверки, оставив 100 уникальных доменов. Каждый был прогнан через восемь стандартизированных проверок по базовому уровню риска точки входа пользователя. Результаты описывают только состояние конфигурации, наблюдаемое из публичного интернета; они не заменяют оценку внутренних процессов или формальную сертификацию. Каждая проверка приводит к одному из трёх состояний. PASS означает, что публично видимая конфигурация соответствовала внешне наблюдаемому критерию, реализуемому данной проверкой, выведенному из модуля SEAL DNS и регистратор. WARN отмечает сигналы, требующие внимания — сертификат или домен, близкий к истечению срока, большое количество CA, авторизованных через CAA, чрезмерно длинный TTL. FAIL означает, что явное требование механизма контроля SEAL не было выполнено (например, DMARC не установлен в p=reject), либо соответствующая реализация безопасности не была соблюдена (например, более десяти DNS-запросов SPF).

4.1 Общие результаты

Сканирование охватило 100 доменов, каждый из которых прошёл восемь стандартизированных проверок, что дало 800 результатов: 232 FAIL и 119 WARN. В пересчёте на домены, 86 дали хотя бы один FAIL, 13 не имели FAIL, но имели хотя бы один WARN, и только 1 прошёл все проверки. Другими словами, среди наблюдаемых публичных точек входа полное покрытие базовых механизмов контроля операционной безопасности DNS остаётся исключением.

По типу проверки результаты FAIL сосредоточены в трёх областях — CAA, DNSSEC и аутентификация электронной почты, — в то время как результаты WARN чаще всего появляются в области охвата авторизации CAA и статуса истечения срока домена. В таблице ниже приведено распределение PASS, WARN и FAIL для каждой проверки, а также основной источник каждого результата.

4.2 Основные пробелы в конфигурации

В совокупности базовая публичная конфигурация DNS среди ведущих проектов остаётся недостаточной, и пробелы не сосредоточены в каком-либо одном техническом механизме контроля. Отсутствующий CAA, неполные цепочки доверия DNSSEC, слишком мягкая политика аутентификации электронной почты и меры защиты на стороне регистратора, которые всё ещё требуют проверки, влияют соответственно на выдачу сертификатов, надёжность резолвинга, коммуникацию бренда и контроль над доменом. Вместе они составляют условия, на которые пользователь неявно полагается, попадая на официальную точку входа. Ниже приведены четыре характерных пробела.

1. Ограничения на выдачу CAA в основном отсутствуют: у 72 доменов не была настроена CAA. Запись CAA ограничивает, какие CA могут выдавать TLS-сертификаты для домена [9]. Её отсутствие не даёт злоумышленнику сертификат напрямую, но означает, что проект не установил дополнительной границы выдачи через DNS. Если валидация домена или связанная с ней плоскость управления скомпрометирована, набор CA, способных принять запрос на сертификат, тем труднее сдержать. Для web3-фронтендов CAA имеет значение главным образом в сценариях составных атак: злоумышленник, одновременно вмешивающийся в валидацию домена, резолвинг DNS или пересылку трафика, не сталкивается с дополнительным ограничением области CA, что увеличивает вероятность того, что поддельный фронтенд может представить сертификат, доверенный браузером.

2. Цепочки доверия DNSSEC неполны: 47 доменов не прошли валидацию. Сбои проявлялись в основном как отсутствующий DNSKEY (34 домена) или отсутствующий DS в родительской зоне (40 доменов), с перекрытием между этими двумя. Без этих записей внешний проверяющий резолвер не может установить полную цепочку доверия DNSSEC [10]. DNSSEC не предотвратит захват учётной записи регистратора или подмену кода фронтенда, но помогает проверить, был ли результат резолвинга подделан или заражён через кэш-пойзонинг. Для протоколов, предлагающих пользователям подключить кошелёк и подписать транзакции, отсутствие этого уровня проверки означает, что пользователь может быть направлен на неправильный адрес, сервер или контракт, при этом интерфейс будет выглядеть практически неизменным.

3. Политика аутентификации электронной почты слаба: 38 проверок не пройдены. У некоторых доменов было сразу несколько проблем: у 35 не была повышена политика DMARC до p=reject [11], у 6 не был настроен адрес агрегированной отчётности rua, а у 4 была чрезмерно длинная цепочка авторизации SPF [12]. Мягкая политика DMARC ослабляет применение мер против подделанной почты, отсутствующий rua ослабляет непрерывный мониторинг, а превышение лимита запросов SPF может вызывать ошибки валидации. Поскольку электронная почта проекта регулярно содержит рекомендации по безопасности, инструкции по airdrop и уведомления о миграции, эти пробелы делают подделанную почту более эффективным путём к поддельному фронтенду или фишинговому потоку.

4. Меры защиты контроля над доменом всё ещё требуют проверки: у 3 доменов отсутствовала блокировка передачи, а статус блокировки реестра оставался неопределённым для ещё 90. В публичном статусе RDAP только 7 доменов показали достаточно полный набор сигналов блокировки; для большинства остальных можно было подтвердить только блокировку передачи, а наличие блокировки реестра необходимо проверять через консоль регистратора или документацию реестра. Блокировка передачи — это базовая мера против несанкционированной передачи; блокировка реестра лучше подходит для доменов высокой ценности, несущих основной фронтенд, документацию и API. Управление продлением также влияет на непрерывность контроля: сканирование обнаружило 2 TLS-сертификата в 30-дневном окне предупреждения и 10 доменов в 90-дневном окне напоминания об истечении срока. Для доменов, несущих критические точки входа, такие механизмы, как автоматическое продление, многоуровневые напоминания и назначенные основные и резервные владельцы, могут предотвратить превращение истекающего сертификата или домена в отказ сервиса или потерю контроля над точкой входа.

5. Что результаты говорят о безопасности DNS в web3 сегодня

Сканирование показывает, что базовая публичная конфигурация DNS у ведущих проектов DeFi остаётся недостаточно покрытой. Из 100 доменов только 1 прошёл все проверки, а 86 дали хотя бы один FAIL. Основные пробелы касаются CAA, DNSSEC, аутентификации электронной почты и блокировок домена — влияя соответственно на ограничения выдачи сертификатов, валидацию резолвинга, коммуникацию бренда и контроль над самим доменом.

Эти пробелы не ограничиваются уровнем резолвинга или каким-либо одним техническим механизмом контроля. Они распределены по домену, резолвингу, сертификату и электронной почте — нескольким различным звеньям в пути пользователя к точке входа. Слабое покрытие CAA и DNSSEC в частности показывает, что эти механизмы контроля точки входа ещё не развёрнуты последовательно по всей выборке — даже несмотря на то, что контроль над доменом, сертификаты и путь резолвинга находятся прямо перед пользователями. Ни один из этих внешних сигналов не указывает на то, что проект был скомпрометирован. Но когда злоумышленник вмешивается в резолвинг DNS, получает действительный сертификат через нерегулярный процесс, захватывает учётную запись регистратора или подделывает официальную электронную почту, отсутствующие механизмы контроля ослабляют уже существующую защиту и облегчают перенаправление пользователей на поддельную страницу или в фишинговый поток. Неадекватное управление продлением сертификатов и доменов также может прерывать работу официальных точек входа.

BDSS может выявлять пробелы в конфигурации из публичного интернета и устанавливать сопоставимый внешний базовый уровень безопасности. Однако он не может адекватно продемонстрировать операционные механизмы контроля, такие как блокировка реестра, MFA учётной записи регистратора, подтверждение критических изменений, мониторинг и оповещения или реагирование на инциденты — ничего из этого невозможно установить только на основе публичных записей. Поэтому публичные сигналы хорошо подходят для описания состояния отрасли и выявления областей, требующих дальнейшей проверки, но не должны восприниматься как окончательное суждение о реальных операционных возможностях какого-либо проекта. В рамках этой границы внешнее сканирование и SEAL Certifications дополняют друг друга: первое делает публичные пробелы в конфигурации постоянно наблюдаемыми и сопоставимыми, а второе опирается на операционную документацию и реальные процессы для проверки внутренних механизмов контроля над доменными активами, контроля доступа регистратора, управления изменениями и реагирования на инциденты. Будучи аккредитованным аудитором SEAL Certifications первой когорты — и единственным в Азии — BlockSec может помочь проектам систематически оценивать свою операционную безопасность в рамках этой структуры.

Ссылки

[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/

[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/

[3] Curve Finance. Заявление об инциденте с DNS 2022 года. https://x.com/CurveFinance/status/1557505570533478403

[4] Curve Finance. Заявление об инциденте с доменом 2025 года. https://news.curve.finance/curve-domain-incident/

[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide

[6] Aerodrome Finance. Заявление об инциденте с доменом. https://x.com/AerodromeFi/status/1992097133869375783

[7] CoW Swap. Заявление об инциденте с доменом. https://x.com/CoWSwap/status/2044924940886163780

[8] Celer Network. Заявление об инциденте с маршрутизацией cBridge. https://x.com/CelerNetwork/status/1560022871564775424

[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html

[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html

[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html

[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html