Руководство по безопасности DeFi: как эффективно защищаться от хакерских атак в эпоху искусственного интеллекта?

Автор: sysls

Перевод: AididiaoJP, Foresight News

Введение

Ознакомившись с многочисленными случаями хакерских атак на DeFi-протоколы, я испытал страх перед «государственными субъектами». Их техническая подготовка высока, ресурсы неограниченны, и они играют в игру чрезвычайно долгосрочной перспективы; эти суперзлодеи тщательно анализируют каждый уголок вашего протокола и инфраструктуры в поисках уязвимостей, в то время как внимание обычных команд разработчиков протоколов рассеяно между шестью-семью различными направлениями деятельности.

Я не претендую на звание эксперта в области безопасности, однако руководил командами в условиях высокого риска (включая военные подразделения и финансовые структуры, работающие с крупными суммами), обладаю богатым опытом стратегического мышления и планирования аварийных процедур.

Я искренне верю: выжить могут только параноики. Ни одна команда изначально не ставит себе цель «относиться к безопасности небрежно и формально»; тем не менее атаки всё равно происходят. Нам необходимо действовать эффективнее.

ИИ действительно меняет ситуацию

（Источник данных: https://defillama.com/hacks）

Хакерские атаки не являются редкостью, однако их частота явно возрастает. Первый квартал 2026 года стал самым атакуемым за всю историю наблюдений по числу инцидентов в DeFi, а второй квартал только начался — и уже имеет все шансы побить рекорд предыдущего квартала.

Мое ключевое предположение заключается в следующем: ИИ значительно снижает стоимость поиска уязвимостей и одновременно расширяет поверхность атаки. Человеку требуется несколько недель, чтобы проанализировать конфигурации сотни протоколов в поиске ошибок; новейшие базовые модели способны выполнить ту же задачу за несколько часов.

Это должно кардинально изменить наш подход к осмыслению и противодействию хакерским атакам. Протоколы, привыкшие к мерам безопасности, существовавшим до появления мощного ИИ, всё чаще рискуют быть «мгновенно уничтоженными».

Мышление через поверхности и уровни

（Источник данных: https://defillama.com/hacks）

Поверхность атаки на самом деле сводится к трём компонентам: команда протокола, смарт-контракты и инфраструктура, границы доверия пользователей (DSN, социальные сети и т.д.).

Определив эти поверхности, следует наложить защитные уровни:

• Профилактика: процессы, которые при строгом соблюдении максимально снижают вероятность эксплуатации.
• Смягчение последствий: ограничение масштаба ущерба в случае провала профилактических мер.
• Приостановка: никто не способен принимать оптимальные решения в условиях колоссального стресса. При подтверждении атаки немедленно активируйте «общий выключатель». Заморозка остановит дальнейшие потери и предоставит пространство для размышлений…
• Восстановление контроля: если вы утратили контроль над токсичным или скомпрометированным компонентом, откажитесь от него и замените.
• Восстановление: верните утраченное. Заранее спланируйте взаимодействие с партнёрскими организациями, способными заморозить средства, отменить транзакции и оказать помощь в расследовании.

Принципы

Эти принципы направляют конкретные действия по реализации каждого защитного уровня.

Широкое применение передовых ИИ-моделей

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

Используйте такие инструменты, как pashov и nemesis, а также ИИ-платформы Cantina (Apex) и Zellic (V12), чтобы быстро просканировать кодовую базу ещё до полного аудита.

Время и трение — это хорошая защита

Добавьте многоступенчатые процедуры и временные блокировки ко всем операциям, способным причинить ущерб. Вам нужно достаточно времени, чтобы вмешаться и заморозить действия при обнаружении аномалий.

Ранее возражения против временных блокировок и многоступенчатых настроек сводились к тому, что они создают трение для команды протокола. Сейчас вы можете не беспокоиться об этом: ИИ легко преодолевает такое трение в фоновом режиме.

Инварианты

Смарт-контракты можно защищать, задавая неизменяемые «факты»: если эти факты нарушаются, вся логика протокола прекращает работу.

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

Баланс власти

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

Для этого требуется баланс между губернансом (который решает всё) и возможностью спасения (способностью восстановить управляемую стабильность, но без права замены или отмены самого губернанса).

Всегда что-то пойдёт не так

Изначально предполагайте: независимо от вашей изощрённости, вас взломают. Ваш смарт-контракт или зависимость могут дать сбой. Вы можете стать жертвой социальной инженерии, а новое обновление может внести непредвиденные уязвимости.

Как только вы начинаете мыслить именно так, ограничители скорости ущерба и автоматические выключатели протокола становятся вашими лучшими друзьями. Ограничьте ущерб до 5–10 %, затем заморозьте систему и приступайте к планированию ответных действий. Никто не способен принимать оптимальные решения под огнём.

Лучшее время для планирования — сейчас

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

Вам не нужно быть идеальным, но вы должны выжить. Ни одна система не является неуязвимой с первого дня; благодаря многократной итерации вы станете антихрупкой, извлекая уроки из каждого опыта.

Отсутствие подтверждённых случаев взлома не означает, что вас никогда не взломают. Максимальный комфорт часто совпадает с максимальной опасностью.

Профилактические меры

Проектирование смарт-контрактов

Определив инварианты, превратите их в проверки времени выполнения. Тщательно продумайте, какие инварианты действительно стоит принудительно выполнять.

Для этого применяется шаблон FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): в конце каждой функции, затрагивающей ценность, повторно проверяются ключевые инварианты, которые эта функция обязуется сохранять. Многие атаки типа «осушения» («flash loan sandwich», «griefing» через оракулы при ликвидациях, межфункциональное истощение платёжеспособности), проходящие проверку CEI (Checks-Effects-Interactions), перехватываются именно проверками инвариантов в конце функции.

Качественное тестирование

Состоятельное фаззинг-тестирование (stateful fuzzing) генерирует случайные последовательности вызовов ко всей открытой поверхности протокола и на каждом шаге проверяет выполнение инвариантов. Большинство уязвимостей в рабочих средах проявляются в рамках нескольких транзакций; состоятельное фаззинг-тестирование — почти единственный надёжный способ обнаружить такие пути ещё до того, как это сделают злоумышленники.

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

Оракулы и зависимости

Сложность — враг безопасности. Каждая внешняя зависимость расширяет поверхность атаки. Если вы разрабатываете примитив, предоставьте пользователям выбор: кому и чему доверять. Если зависимость нельзя устранить, диверсифицируйте её так, чтобы ни одна точка отказа не могла уничтожить ваш протокол.

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

Недавний инцидент с KelpDAO служит примером: они использовали конфигурацию LayerZero по умолчанию requiredDVNCount=1, которая находилась вне сферы их аудита. В итоге был взломан оффчейн-инфраструктурный компонент, не входивший в аудит.

Атаки через поверхности

Большинство атак через поверхности в DeFi уже документированы. Последовательно пройдитесь по каждому типу, задайте вопрос: «Применимо ли это к моему протоколу?», и внедрите соответствующие контрмеры. Развивайте навыки красной команды и обучите свои ИИ-агенты активно искать уязвимости в вашем протоколе — сегодня это уже базовое требование.

Наличие встроенной способности к спасению

В системах губернанса, основанных на голосовании, власть первоначально сосредоточена в мультиподписи команды и требует времени для децентрализации. Даже при широком распределении токенов делегирование часто концентрирует полномочия в руках нескольких кошельков (иногда даже одного — n=1). Как только такие кошельки оказываются взломаны, игра окончена.

Разверните «кошельки-стражи», наделённые строго ограниченными полномочиями: они могут только приостанавливать протокол, а при достижении порога >=4/7 — в экстремальных случаях заменять повреждённые делегированные кошельки на заранее определённые резервные. Стражи никогда не могут исполнять предложения губернанса.

Таким образом, вы получаете слой спасения, который всегда может восстановить управляемую стабильность, не обладая при этом правом отмены губернанса. Вероятность наихудшего сценария — потери >=4/7 стражей — крайне мала (с учётом разнообразия владельцев), и этот слой можно постепенно выводить из употребления по мере зрелости и децентрализации губернанса.

Топология кошельков и ключей

Мультиподпись — обязательное требование, минимум 4/7. Ни один человек не должен контролировать все семь ключей. Регулярно и незаметно меняйте подписчиков.

Ключи никогда не должны взаимодействовать с устройствами, используемыми в повседневной работе. Если вы используете устройство для подписи при серфинге в интернете, чтении почты или работе в Slack, считайте, что этот подписчик уже скомпрометирован.

Имейте несколько мультиподписей с различными назначениями. Предполагайте, что хотя бы одна полная мультиподпись будет взломана, и начинайте планирование именно с этой точки. Ни один человек не должен обладать достаточным контролем для взлома протокола даже в самых экстремальных сценариях (похищение, пытки и т.д.).

Рассмотрите возможность программы вознаграждений

Если у вас есть ресурсы, установка щедрой программы вознаграждений за обнаружение уязвимостей, пропорциональной TVL протокола, является чрезвычайно выгодной инвестицией; даже для сравнительно небольших протоколов размер вознаграждения должен быть максимально щедрым (например, от 7 до 8 цифр).

Если вы столкнётесь с атаками со стороны государственных субъектов, они, возможно, не пойдут на переговоры, однако вы всё равно можете участвовать в программе «белых шляп — безопасная гавань», предоставляя белым хакерам право действовать от вашего имени для защиты средств и выплачивая им процент от суммы уязвимости в качестве вознаграждения (фактически — вознаграждение, финансируемое депозиторами).

Выбор квалифицированных аудиторов

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

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

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

Практика операционной безопасности

Рассматривайте операционную безопасность как показатель успеха. Проводите фишинговые учения; нанимайте (доверенных) специалистов красной команды для попыток социальной инженерии в отношении вашей команды. Подготовьте резервные аппаратные кошельки и устройства, чтобы при необходимости полностью заменить мультиподпись. Вам не захочется в день D покупать всё это в спешке.

Смягчение последствий

Ваш путь вывода средств — это верхний предел потерь

Максимальный размер любого пути вывода стоимости из протокола определяет теоретический верхний предел потерь при эксплуатации уязвимости на этом пути. Проще говоря: функция чеканки без ограничения на блок — это «чистый лист» для любой атаки, позволяющей бесконечно чеканить токены. Функция вывода без недельного лимита — это «чистый лист» для любого сбоя баланса активов.

Тщательно продумайте конкретные числовые значения для ваших путей вывода. Эти цифры должны обеспечивать баланс между максимальным ущербом, который вы готовы понести, и крайними требованиями пользователей к удобству UX. Если произойдёт сбой, именно это станет вашим спасением от полного уничтожения.

Белые и чёрные списки

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

Официальное оформление позволяет использовать двухэтапные механизмы установки, создающие значимое трение. Злоумышленнику сначала нужно попасть в белый список (и/или быть удалённым из чёрного), а затем уже действовать. Наличие обоих списков означает, что при тайном внедрении нового вектора атаки злоумышленник должен одновременно преодолеть два процесса: рынок должен быть разрешён (интеграция / листинг), и действие не должно быть запрещено (безопасностная проверка).

Восстановление контроля

Алгоритмический мониторинг

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

Остановитесь и переоцените ситуацию

Если вы получили ранение, сначала остановите кровотечение, а не принимайте решения под давлением обратного отсчёта. Для протокола это и есть «выключатель» (который также должен быть доступен в UI): одна кнопка, нажатая в одной транзакции, приостанавливает все пути перемещения стоимости. Подготовьте вспомогательный скрипт «приостановить всё», который перечисляет все подлежащие приостановке компоненты и приостанавливает их атомарно.

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

Активируйте свой центр управления кризисом

Заморозьте систему, остановите утечку, затем соберите всех, кому вы доверяете (узкий круг, заранее согласованный), в одном канале связи. Желательно, чтобы поверхность была минимальной, чтобы предотвратить утечку информации злоумышленникам, общественности или злонамеренным арбитражерам.

Распределите роли внутри команды: один человек принимает решения; один — опытный оператор, выполняющий защитные скрипты и операции приостановки; один — анализирует уязвимость и определяет корневую причину; один — взаимодействует с ключевыми сторонами; один — фиксирует наблюдения, события и хронологию решений.

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

Учитывайте цепные реакции

Предположите, что ваш атакующий чрезвычайно опытный. Первая уязвимость может быть приманкой или заложенным семенем для последующей атаки. Атака может быть направлена на то, чтобы заставить вас совершить совершенно неверное действие, которое и активирует настоящую уязвимость.

Приостановка должна быть тщательно продумана, полностью контролируема и сама по себе не подвержена эксплуатации. Она должна охватывать весь протокол: вам не хотелось бы, чтобы вас заставили приостановить какой-то один компонент, тем самым открыв другой. Как только вы определите корневую причину и вектор атаки, исследуйте смежные уязвимые поверхности и возможные цепные реакции и устраните их все сразу.

Заранее согласованная замена наследников

Замена безопасна только тогда, когда наследник известен заранее. Мне нравится идея реестра заранее согласованных наследников: она усложняет злоумышленнику подмену здоровых кошельков стражей / губернанса на скомпрометированные. Эта концепция согласуется с принципом «белых и чёрных списков» в разделе смягчения последствий.

Для каждой важной роли зарегистрируйте адрес наследника. Единственная операция, которую может выполнять аварийный слой, — это «заменить роль X на её наследника». Это также позволяет вам оценивать наследников в мирное время: действуйте медленно, проведите должную проверку, лично встретьтесь с человеком, подавшим заявку.

Тщательное тестирование перед обновлением

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

Задержите выпуск, если нет достаточного времени на тестирование. Если аудит невозможен, опирайтесь на связи с белыми хакерами или организуйте 48-часовое соревнование перед развертыванием, чтобы получить свежий независимый противодействующий аудит.

Восстановление

Быстрые действия

Украденные средства имеют период полураспада: как только уязвимость эксплуатируется, они быстро попадают в каналы отмывания. Заранее подготовьте поставщиков услуг анализа блокчейна, таких как Chainalysis, чтобы в режиме реального времени маркировать кластеры адресов злоумышленников и уведомлять биржи о необходимости маркировки и отслеживания при их переходе между блокчейнами.

Заранее подготовьте список контактных лиц: отделов соответствия централизованных бирж, администраторов кроссчейн-мостов, администраторов хранилищ и других третьих сторон, обладающих административными правами для заморозки кроссчейн-сообщений или конкретных находящихся в пути депозитов.

Переговоры

Да, это болезненно, но всё равно стоит попытаться вступить в диалог с атакующим. Многие вещи в жизни решаются переговорами. Предложите ограниченное по времени вознаграждение для белых хакеров и публично объявите, что при полном возврате средств до установленного срока юридические действия предприняты не будут.

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

Перед этим обязательно привлеките юридического консультанта.

Заключение

Хакерские атаки не прекратятся, и по мере того, как ИИ становится умнее, их количество будет только расти. Недостаточно просто сделать защитников «более бдительными». Нам необходимо использовать те же инструменты, что и злоумышленники, — проводить красные командные тесты наших протоколов, осуществлять постоянный мониторинг и устанавливать жёсткие ограничения на ущерб, чтобы выжить даже в самых худших сценариях.