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

Заголовок оригинала: How To Stop Losing Money To DeFi Hacks
Автор оригинала: sysls, openforage
Перевод оригинала: AididiaoJP, Foresight News

Автор оригинала:律动BlockBeats

Источник оригинала:

Репост: Mars Finance

Введение

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

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

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

AI означает, что в этот раз всё действительно по-другому

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

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

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

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

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

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

· Профилактика: строгое выполнение процедур, максимально снижающих вероятность эксплуатации.

· Смягчение: при неудаче профилактики ограничить масштаб ущерба.

· Пауза: никто не способен принимать оптимальные решения под сильным давлением. После обнаружения атаки немедленно активируйте «тотальный выключатель». Заморозка может остановить дальнейшие потери и дать время на размышление…

· Восстановление: если контроль над вредоносными или взломанными компонентами утрачен, их нужно выбросить и заменить.

· Восстановление: вернуть утерянное. Предварительно подготовьте контакты организаций, способных заморозить средства, отменить транзакции и помочь в расследовании.

Принципы

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

Массовое использование передовых AI

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

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

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

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

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

Неподвижные свойства

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

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

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

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

Это требует баланса между управлением (принятием решений) и спасением (восстановлением стабильности, без возможности отмены или свержения управления).

Всегда возникают проблемы

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

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

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

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

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

Отсутствие взлома не означает, что вас не взломают. Максимальная комфортная точка зачастую — самая опасная.

Меры профилактики

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

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

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

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

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

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

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

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

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

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

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

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

Обладание встроенными средствами спасения

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

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

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

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

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

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

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

Обдумайте систему бонусов

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

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

Поиск хороших аудиторов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перезагрузка и перенастройка

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

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

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

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

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

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

Обдумывайте цепные реакции

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

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

Заранее назначайте преемников

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

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

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

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

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

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

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

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

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

Переговоры

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

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

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

Заключение

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