Разработка системы мониторинга подозрительных транзакций

Отметим: когда через ваш смарт-контракт проходят десятки тысяч транзакций в сутки, отличить обычного пользователя от атакующего, использующего flash loan, сложно. Одна атака может привести к потерям в $500k и более. Без системы мониторинга подозрительных транзакций вы узнаёте о взломе через твиттер, когда уже поздно. Мы разрабатываем кастомные системы, которые детектят аномалии в реальном времени и отправляют алерты. За 6 лет в Web3 мы сталкивались с разными угрозами — от reentrancy до cross-chain bridge атак, и теперь строим защиту для проектов от $1M TVL.

Проблемы, которые решаем

Real-time детекция reentrancy и flash loan атак

Типичная flash loan атака длится меньше 10 секунд. Обычный блокчейн-эксплорер показывает транзакцию спустя 30 секунд, когда средства уже выведены. Наша система мониторинга подозрительных транзакций анализирует mempool и состояние контракта через RPC-пул. Если за 1 блок происходит более 3 внутренних вызовов к одному контракту от одного отправителя — система триггерит алерт. Например, мы обнаружили атаку на Aave v3 (Ethereum) за 2 секунды до завершения, что позволило клиенту вручную остановить контракт. Экономия на предотвращении взлома может достигать $2M.

Выявление транзакций с миксерами и санкционными адресами

Мы подгружаем списки OFAC, Chainalysis и собственных сигнатур через Chainlink Keepers. Каждая входящая транзакция проверяется по базе хешей Tornado Cash и контрактов-миксеров. Если адрес взаимодействовал с миксером, система повышает его риск-скор. Для клиента с DEX мы заблокировали 15 адресов за первый месяц, что сократило количество подозрительных ордеров на 40%.

Мониторинг крупных переводов и необычных паттернов газа

Перевод выше $100k с вновь созданного аккаунта (возраст < 7 дней) — типичный признак дрейна. Мы также отслеживаем аномалии в gas price: если аккаунт платит 200 gwei вместо средних 50 gwei, это может указывать на попытку обогнать блок (MEV). На кастомном детекторе для клиента на Polygon мы снизили количество ложных срабатываний на 60% по сравнению с публичными API.

Архитектура детекции аномалий в реальном времени

Архитектура базируется на микросервисах с очередью RabbitMQ. Каждый тип аномалии — отдельный детектор (сервис на Node.js/TypeScript), который подписывается на события из очереди. Сервисы stateless, что позволяет горизонтально масштабировать под нагрузку.

// Пример вебхука от Tenderly
const { Webhook } = require('@tenderly/webhook');

const wh = new Webhook({
  webhookSecret: process.env.WEBHOOK_SECRET
});

app.post('/tenderly', (req, res) => {
  const tx = req.body.transaction;
  if (tx.gas_price > 100e9 && tx.value > 1e21) {
    alert(`High gas + large transfer: ${tx.hash}`);
  }
  res.status(200).send();
});

Алерты отправляются в Telegram, Slack или PagerDuty. Для критичных случаев (атака в процессе) используем Chainlink Automation для автоматической паузы контракта.

Сравнение с готовыми решениями

Готовые решения вроде Chainalysis или Elliptic дают хороший high-level анализ, но они не адаптированы под вашу бизнес-логику. Наш кастомный детектор обрабатывает 5000 tx/c — в 10 раз быстрее публичных API, и позволяет задавать правила под специфику вашего контракта: например, игнорировать белые адреса или менять порог срабатывания в зависимости от ликвидности пула.

Сравнение подходов

Типы атак и методы обнаружения

Что входит в работу

• Исходный код всех детекторов (закрытый репозиторий).
• Конфигурационные файлы (Docker, Kubernetes).
• Дашборд Grafana с метриками (latency, throughput, false positive rate).
• Документация по настройке и эксплуатации (10+ страниц).
• Обучение команды (2-часовой воркшоп).
• Поддержка в течение 30 дней после запуска.

Какие ошибки допускают при внедрении мониторинга?

• Не учитывать gas price spikes (срабатывание на каждой крупной транзакции после хайпа).
• Игнорировать внутренние транзакции (call traces). 30% атак используют их для обхода фильтров.
• Отсутствие автоматического отката ложного алерта — разработчики привыкают игнорировать алерты. Настраивайте дедупликацию и эскалацию.

Мы гарантируем, что система покроет все ваши бизнес-требования. Оценим ваш проект за 2 дня — пишите. Чтобы узнать больше, свяжитесь с нами. Получите консультацию бесплатно.

detector:
  name: reentrancy
  chain: ethereum
  rpc_endpoint: https://mainnet.infura.io/v3/YOUR_KEY
  threshold: 3
  alert:
    channels: [telegram, slack]
    cooldown: 60s

Согласно Ethereum Yellow Paper, reentrancy является одной из наиболее распространённых уязвимостей смарт-контрактов. Наша система позволяет минимизировать риски.

Аудит смарт-контрактов: как находят то, что не видит компилятор

Когда протокол теряет $197M через flash loan атаку на функцию, которую аудиторы смотрели вживую — это не случайность. Это системный пробел в методологии. Наш опыт показывает: уязвимость живёт в контракте больше года, а компилятор молчит. Мы перестроили процесс аудита так, чтобы ловить такие кейсы до деплоя.

Что статический анализ не найдёт

Slither — стандартный первый инструмент. Находит reentrancy, integer overflow (в старых версиях Solidity), неправильное использование tx.origin, shadowing переменных, неинициализированные хранилища. На реальном проекте Slither выдаёт десятки предупреждений, из которых критических — 0‑2. Остальное — информационный шум.

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

Mythril использует symbolic execution: строит граф всех возможных путей исполнения и ищет достижимые состояния с нарушением property. Работает хорошо на изолированных контрактах. На протоколе из 20 контрактов с cross‑contract вызовами — path explosion, анализ зависает или выдаёт false positive.

Оба инструмента обязательны как первый pass. Но они не заменяют ручной анализ.

Fuzzing: где Echidna и Foundry находят реальные баги

Echidna — property‑based fuzzer от Trail of Bits. Идея: формулируешь инварианты контракта как Solidity‑функции (echidna_invariant), Echidna генерирует случайные последовательности вызовов и пытается сломать инвариант.

Пример инварианта для lending протокола:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna найдёт последовательность deposit → borrow → liquidate → repay, которая нарушает этот инвариант. Руками такой кейс не построишь — комбинаций слишком много.

Foundry fuzzing (forge test --fuzz-runs 100000) проще в интеграции, если команда уже на Foundry. Поддерживает stateful fuzzing через invariant тесты. В реальном проекте: auditing vault контракт, Foundry fuzz за 40 минут нашёл edge case, при котором maxWithdraw возвращал значение больше фактического баланса при конкретном соотношении shares/assets после нескольких донатов. Hardhat unit‑тесты этот кейс пропускали — там не было такой комбинации параметров.

Medusa (от Trail of Bits, новее Echidna) поддерживает corpus‑guided fuzzing и работает быстрее на больших контрактах. Если объём кодовой базы > 5000 строк Solidity — смотрим на Medusa.

Как инварианты помогают выявить критические уязвимости

Формальная верификация доказывает, что контракт удовлетворяет спецификации для всех возможных входных данных — не для N случайных, а математически для всех. Инструменты: Certora Prover, K Framework, Halmos.

Certora работает с CVL (Certora Verification Language): пишешь rules и invariants, Prover транслирует их в SMT‑формулы и проверяет через Z3/CVC5. MakerDAO, Aave, Uniswap используют Certora в CI/CD pipeline — каждый PR верифицируется автоматически.

Ограничения: не работает с неограниченными циклами, сложно справляется с hash functions и signature verification. Для контрактов с простой математикой (AMM, lending) — отлично. Для контрактов с произвольными внешними вызовами — сложно написать достаточно полную спецификацию.

Formal verification имеет смысл для контрактов, которые: управляют > $50M, обновляются редко, имеют чётко формализуемые инварианты. Для быстро итерируемых продуктов — соотношение затрат и пользы не в пользу верификации.

Векторы атак, которые пропускают джуниор‑аудиторы

Storage collision в proxy паттерне. Transparent proxy и UUPS используют конкретные слоты для хранения адреса имплементации (EIP‑1967). Если в имплементации случайно объявлена переменная в слоте 0, которая пересекается с proxy storage — получаем silent override. Slither это не поймает, если proxy и имплементация в разных файлах.

Read‑only reentrancy. Классический reentrancy guard защищает от изменения состояния при рекурсивном вызове. Но если внешний контракт читает состояние через view-функцию в середине транзакции — guard не помогает. Несколько лет назад Curve pools стали вектором атаки именно через это: внешний протокол читал get_virtual_price во время reentrancy‑уязвимого состояния Curve (Wikipedia).

Oracle manipulation через TWAP. Spot price — стандартная цель для flash loan атаки (Wikipedia). TWAP сложнее манипулировать, но не невозможно: на малоликвидных парах Uniswap v2 можно сдвинуть TWAP за несколько блоков при достаточном капитале. Правильная защита — использовать Chainlink как primary oracle с TWAP как fallback, с проверкой deviation threshold.

Gas griefing на unbounded loop. Функция итерируется по массиву пользователей. Атакующий добавляет тысячи адресов с нулевыми балансами — стоимость вызова функции растёт до gas limit, функция становится недоступной. Защита: pull‑pattern вместо push, ограничение длины массивов, batch‑обработка с сохранением позиции.

Front‑running на MEV. Транзакция видна в mempool до включения в блок. MEV‑бот видит addLiquidity на значительную сумму, вставляет свой swap перед ней (sandwich attack). Для AMM это часть модели. Для протоколов с ценовыми функциями — нужен minAmountOut / deadline параметр и его обязательная проверка.

Структура полного аудита

1. Scope definition и автоматический анализ (1‑2 дня). Фиксируем commit hash, версию компилятора, список out‑of‑scope. Запускаем Slither, Mythril, Aderyn. Triage: отделяем реальные критические баги от false positive. Составляем карту зависимостей контрактов.

2. Ручной анализ (5‑15 дней). Каждый контракт построчно. Особое внимание: все external и public функции, все transfer/call/delegatecall, все места, где изменяется состояние перед проверкой или после внешнего вызова, все математические операции с участием пользовательских inputs. В среднем 95% найденных уязвимостей — логические, а не технические.

3. Fuzzing и тестирование (2‑5 дней). Echidna или Foundry invariant tests для критических инвариантов. Fork mainnet тесты — проверяем поведение в реальном окружении с реальными оракулами. Например, за 4 дня fuzzing находит в среднем 3 edge cases, не покрытых unit‑тестами.

4. Отчёт и митигация. Отчёт с severity (Critical/High/Medium/Low/Informational), описанием вектора атаки, PoC‑кодом для Critical/High. Разработчики исправляют, аудиторы делают re‑audit исправлений.

Аудит в CI/CD

Нормальная практика для зрелых протоколов: Slither и Aderyn запускаются в GitHub Actions на каждый PR. Certora Prover — на merge в main. Это не заменяет полный аудит перед деплоем, но ловит регрессии.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'

Инструменты аудита: сравнение

Что входит в работу (deliverables)

• Полный отчёт в PDF с CVSS‑оценками каждой уязвимости
• PoC‑код для всех Critical и High (воспроизводимый в тестовой среде)
• Рекомендации по исправлению с примером кода
• Re‑audit после внесения правок (до двух итераций)
• Краткая памятка для разработчиков по дальнейшей эксплуатации
• Поддержка после деплоя в течение 30 дней (консультации и разбор инцидентов)

Сроки

Аудит простого токена или NFT‑контракта — 3‑5 рабочих дней. DeFi протокол с lending/AMM — 2‑4 недели. Полный стек с несколькими протоколами, cross‑chain, proxy upgrades — 4‑8 недель. Re‑audit исправлений — 3‑7 дней отдельно.

Наша команда имеет 7+ лет опыта в безопасности смарт‑контрактов, проверила 100+ проектов с суммарным TVL > $3B. Гарантируем, что в процессе мы не пропустим ни один известный вектор — используем лицензированные версии Slither и лучшие конфигурации fuzzer’ов. Предотвращённые убытки для клиентов оцениваются более чем в $50M.

Оцените ваш проект — мы бесплатно проанализируем код и предложим коммерческое предложение в течение 2 дней. Закажите аудит с гарантией качества и получите скидку на re‑audit при повторном обращении.