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

Оригинальный заголовок: Как прекратить терять деньги из-за взломов DeFi
Автор оригинала: sysls, openforage
Перевод и компиляция: 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): в конце каждой функции, затрагивающей ценность, повторно проверяйте те переменные, которые должны сохраняться. Многие атаки типа CEI (Checks-Effects-Interactions), такие как флеш-лоаны, атаки на оракулы и межфункциональные выплаты, можно перехватить проверками в конце функции.

Хорошее тестирование

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

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

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

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

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

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

Поверхностные атаки

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

Обеспечьте встроенные механизмы спасения

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

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

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

Кошельки и топология ключей

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

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

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

Рассмотрите возможность внедрения бонец

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

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

Найдите хороших аудиторов

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

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

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

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

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

Меры смягчения

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

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

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

Белый список (и чёрный список)

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

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

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

Мониторинг алгоритмов

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

Перезагрузка и калибровка

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

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

Запустите командный центр

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

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

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

Рассмотрите цепную реакцию

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