Один пост с тегом "Безопасность"

Когда вы отправляете криптовалюту, какова ваша обычная процедура? Для большинства из нас она включает копирование адреса получателя из истории транзакций. В конце концов, никто не может запомнить строку из 40 символов, такую как 0x1A2b...8f9E. Это удобный ярлык, которым мы все пользуемся.

Но что, если это удобство — тщательно расставленная ловушка?

Разрушительно эффективная афера, называемая отравлением блокчейн-адресов, использует именно эту привычку. Недавнее исследование Университета Карнеги-Меллона выявило шокирующие масштабы этой угрозы. Всего за два года только в сетях Ethereum и Binance Smart Chain (BSC) мошенники совершили более 270 миллионов попыток атак, нацелившись на 17 миллионов жертв и успешно украв не менее 83,8 миллиона долларов.

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

Как работает обман 🤔​

Отравление адресов — это игра визуального обмана. Стратегия злоумышленника проста, но гениальна:

1. Генерация похожего адреса: Злоумышленник определяет адрес, на который вы часто отправляете средства. Затем он использует мощные компьютеры для генерации нового крипто-адреса, который имеет точно такие же начальные и конечные символы. Поскольку большинство кошельков и блокчейн-эксплореров сокращают адреса для отображения (например, 0x1A2b...8f9E), их мошеннический адрес на первый взгляд выглядит идентично настоящему.

2. «Отравление» вашей истории транзакций: Далее злоумышленнику необходимо внедрить свой похожий адрес в историю вашего кошелька. Они делают это, отправляя «отравляющую» транзакцию. Это может быть:

   • Крошечный перевод: Они отправляют вам ничтожную сумму криптовалюты (например, $0.001) со своего похожего адреса. Теперь он появляется в вашем списке недавних транзакций.
   • Перевод с нулевой стоимостью: В более хитром ходе они используют функцию во многих токен-контрактах для создания поддельного перевода на нулевую сумму, который выглядит так, будто он пришел от вас на их похожий адрес. Это делает поддельный адрес еще более легитимным, поскольку создается впечатление, что вы уже отправляли туда средства.
   • Перевод поддельного токена: Они создают бесполезный, поддельный токен (например, «USDTT» вместо USDT) и фальсифицируют транзакцию на свой похожий адрес, часто имитируя сумму предыдущей реальной транзакции, которую вы совершали.

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

Взгляд на преступное предприятие 🕵️‍♂️​

Это не работа хакеров-одиночек. Исследование показывает, что эти атаки осуществляются крупными, организованными и высокодоходными преступными группами.

Кого они выбирают в качестве цели​

Злоумышленники не тратят время на мелкие аккаунты. Они систематически нацеливаются на пользователей, которые являются:

• Состоятельными: Владеют значительными балансами в стейблкоинах.
• Активными: Совершают частые транзакции.
• Крупными транзакторами: Перемещают большие суммы денег.

Гонка вооружений в сфере оборудования​

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

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

Как защитить свои средства 🛡️​

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

1. Для каждого пользователя (это самая важная часть):

   • ПРОВЕРЯЙТЕ ПОЛНЫЙ АДРЕС. Прежде чем нажать «Подтвердить», потратьте пять дополнительных секунд, чтобы вручную проверить весь адрес, символ за символом. Не просто смотрите на первые и последние несколько цифр.
   • ИСПОЛЬЗУЙТЕ АДРЕСНУЮ КНИГУ. Сохраняйте доверенные, проверенные адреса в адресной книге или списке контактов вашего кошелька. При отправке средств всегда выбирайте получателя из этого сохраненного списка, а не из вашей динамической истории транзакций.
   • ОТПРАВЬТЕ ТЕСТОВУЮ ТРАНЗАКЦИЮ. Для крупных или важных платежей сначала отправьте небольшую сумму. Подтвердите с получателем, что он ее получил, прежде чем отправлять полную сумму.

2. Призыв к улучшению кошельков:

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

3. Долгосрочное решение:

   • Такие системы, как Ethereum Name Service (ENS), которые позволяют сопоставить удобочитаемое имя, например yourname.eth, с вашим адресом, могут полностью устранить эту проблему. Широкое распространение является ключом.

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

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

Однако недавняя исследовательская работа под названием "Деанонимизация валидаторов Ethereum: P2P-сеть имеет проблему конфиденциальности" от исследователей из ETH Zurich и других учреждений выявила критический недостаток в этом предположении. Они продемонстрировали простой, недорогой метод прямой привязки публичного идентификатора валидатора к IP-адресу машины, на которой он работает.

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

Как работает уязвимость: недостаток в протоколе распространения информации​

Чтобы понять уязвимость, нам сначала нужно представить, как взаимодействуют валидаторы Ethereum. Сеть состоит из более чем миллиона валидаторов, которые постоянно «голосуют» за состояние цепочки. Эти голоса называются аттестациями, и они транслируются по одноранговой ($P2P$) сети всем другим нодам.

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

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

Именно здесь кроется уязвимость. Представьте ноду, чья задача — управлять трафиком для каналов 12 и 13. Весь день она добросовестно пересылает сообщения только из этих двух каналов. Но затем она внезапно отправляет вам сообщение, которое относится к каналу 45.

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

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

Метод оказался шокирующе эффективным. Используя всего четыре ноды в течение трех дней, команда успешно определила IP-адреса более 161 000 валидаторов, что составляет более 15% всей сети Ethereum.

Почему это важно: риски деанонимизации​

Раскрытие IP-адреса валидатора — это не пустяк. Это открывает двери для целенаправленных атак, которые угрожают отдельным операторам и здоровью сети Ethereum в целом.

1. Целенаправленные атаки и кража вознаграждений Ethereum заранее, за несколько минут, объявляет, какой валидатор должен предложить следующий блок. Злоумышленник, знающий IP-адрес этого валидатора, может запустить атаку типа «отказ в обслуживании» (DDoS), перегрузив его трафиком и отключив от сети. Если валидатор пропускает свое четырехсекундное окно для предложения блока, возможность переходит к следующему валидатору в очереди. Если злоумышленник является этим следующим валидатором, он может затем получить вознаграждение за блок и ценные комиссии за транзакции (MEV), которые должны были достаться жертве.

2. Угрозы живучести и безопасности сети Хорошо обеспеченный ресурсами злоумышленник мог бы многократно выполнять эти «снайперские» атаки, вызывая замедление или остановку всего блокчейна (атака на живучесть). В более серьезном сценарии злоумышленник мог бы использовать эту информацию для запуска сложных атак по разделению сети, потенциально заставляя различные части сети расходиться во мнениях относительно истории цепочки, тем самым компрометируя ее целостность (атака на безопасность).

3. Выявление централизованной реальности Исследование также пролило свет на некоторые неудобные истины о децентрализации сети:

• Чрезвычайная концентрация: Команда обнаружила пиры, размещающие ошеломляющее количество валидаторов, включая один IP-адрес, на котором работало более 19 000 валидаторов. Сбой одной машины может оказать непропорционально большое влияние на сеть.
• Зависимость от облачных сервисов: Примерно 90% обнаруженных валидаторов работают на облачных провайдерах, таких как AWS и Hetzner, а не на компьютерах индивидуальных домашних стейкеров. Это представляет собой значительную точку централизации.
• Скрытые зависимости: Многие крупные стейкинг-пулы заявляют, что их операторы независимы. Однако исследование выявило случаи, когда валидаторы из разных, конкурирующих пулов работали на одной и той же физической машине, создавая скрытые системные риски.

Меры по смягчению: как валидаторы могут защитить себя?​

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

• Создание большего шума: Валидатор может выбрать подписку на более чем две подсети — или даже на все 64. Это значительно затрудняет наблюдателю различение между ретранслируемыми сообщениями и сообщениями, сгенерированными самим валидатором.
• Использование нескольких нод: Оператор может разделить обязанности валидатора между разными машинами с разными IP-адресами. Например, одна нода может обрабатывать аттестации, в то время как отдельная, приватная нода используется только для предложения высокоценных блоков.
• Приватный пиринг: Валидаторы могут устанавливать доверенные, приватные соединения с другими нодами для ретрансляции своих сообщений, скрывая их истинное происхождение внутри небольшой, доверенной группы.
• Протоколы анонимной трансляции: Могут быть реализованы более продвинутые решения, такие как Dandelion, который скрывает происхождение сообщения, передавая его по случайному «стеблю» перед широкой трансляцией.

Заключение​

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

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

В стартапах Кремниевой долины Docker Compose является одним из предпочтительных инструментов для быстрого развертывания и управления контейнерными приложениями. Однако удобство часто сопряжено с рисками безопасности. Как инженер по надежности сайта (SRE), я прекрасно осознаю, что уязвимости безопасности могут привести к катастрофическим последствиям. В этой статье я поделюсь лучшими практиками безопасности, которые я обобщил в своей реальной работе, сочетая Docker Compose с системами Ubuntu, помогая вам наслаждаться удобством Docker Compose, обеспечивая при этом безопасность системы.

I. Укрепление безопасности системы Ubuntu​

Перед развертыванием контейнеров крайне важно обеспечить безопасность самой хост-системы Ubuntu. Вот несколько ключевых шагов:

1. Регулярное обновление Ubuntu и Docker​

Убедитесь, что как система, так и Docker постоянно обновляются для исправления известных уязвимостей:

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Ограничение прав управления Docker​

Строго контролируйте права управления Docker, чтобы предотвратить атаки с повышением привилегий:

sudo usermod -aG docker deployuser
# Предотвратить легкое получение обычными пользователями прав управления Docker

3. Настройка брандмауэра Ubuntu (UFW)​

Разумно ограничьте сетевой доступ, чтобы предотвратить несанкционированный доступ:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Правильная настройка взаимодействия Docker и UFW​

По умолчанию Docker обходит UFW для настройки iptables, поэтому рекомендуется ручное управление:

Измените файл конфигурации Docker:

sudo nano /etc/docker/daemon.json

Добавьте следующее содержимое:

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Перезапустите службу Docker:

sudo systemctl restart docker

Явно привяжите адреса в Docker Compose:

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Лучшие практики безопасности Docker Compose​

Следующие конфигурации применимы к Docker Compose v2.4 и выше. Обратите внимание на различия между режимами без Swarm и Swarm.

1. Ограничение прав контейнера​

Контейнеры, работающие от имени root по умолчанию, представляют высокие риски; переключитесь на пользователей без прав root:

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000" # Пользователь без прав root
    read_only: true # Файловая система только для чтения
    volumes:
      - /tmp/app:/tmp # Монтируйте определенные каталоги, если требуется доступ для записи
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Пояснение:

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

2. Сетевая изоляция и управление портами​

Точно разделите внутренние и внешние сети, чтобы избежать exposing чувствительных сервисов общественности:

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• Сеть Frontend: Может быть открыта для публичного доступа.
• Сеть Backend: Строго ограничена, только для внутренней связи.

3. Безопасное управление секретами​

Конфиденциальные данные никогда не должны размещаться непосредственно в файлах Compose:

В одномашинном режиме:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

В режиме Swarm:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true # Управляется через встроенное управление Swarm

Примечание:

• Встроенные секреты Docker Swarm не могут напрямую использовать внешние инструменты, такие как Vault или AWS Secrets Manager.
• Если требуется внешнее хранилище секретов, интегрируйте процесс чтения самостоятельно.

4. Ограничение ресурсов (адаптируйте к версии Docker Compose)​

Ограничения ресурсов контейнера предотвращают исчерпание ресурсов хоста одним контейнером.

Режим Docker Compose для одной машины (рекомендуется v2.4):

version: "2.4"

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Режим Docker Compose Swarm (v3 и выше):

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

Примечание: В средах без Swarm ограничения ресурсов в разделе deploy не действуют, обязательно обращайте внимание на версию файла Compose.

5. Проверки работоспособности контейнеров​

Настройте проверки работоспособности, чтобы заблаговременно выявлять проблемы и сокращать время простоя сервиса:

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. Избегайте использования тега Latest​

Избегайте неопределенности, связанной с тегом latest в производственных средах, используйте конкретные версии образов:

services:
  api:
    image: your-image:1.4.0

7. Правильное управление журналами​

Предотвратите исчерпание дискового пространства журналами контейнеров:

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Конфигурация AppArmor в Ubuntu​

По умолчанию Ubuntu включает AppArmor, и рекомендуется проверить статус профиля Docker:

sudo systemctl enable --now apparmor
sudo aa-status

Docker в Ubuntu по умолчанию включает AppArmor без дополнительной настройки. Обычно не рекомендуется одновременно включать SELinux в Ubuntu, чтобы избежать конфликтов.

9. Непрерывные обновления и сканирование безопасности​

• Сканирование уязвимостей образов: Рекомендуется интегрировать такие инструменты, как Trivy, Clair или Snyk, в процесс CI/CD:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• Автоматизированный процесс обновления безопасности: Пересобирайте образы как минимум еженедельно для исправления известных уязвимостей.

III. Пример из практики: Уроки ошибок конфигурации Docker Compose​

В июле 2019 года Capital One пострадала от крупной утечки данных, затронувшей личную информацию более 100 миллионов клиентов 12. Хотя основной причиной этой атаки были ошибки конфигурации AWS, она также включала проблемы безопасности контейнеров, аналогичные описанной вами ситуации:

1. Проблемы с разрешениями контейнеров: Злоумышленник использовал уязвимость в брандмауэре веб-приложений (WAF), работающем в контейнере, но с избыточными разрешениями.
2. Недостаточная сетевая изоляция: Злоумышленник мог получить доступ к другим ресурсам AWS из скомпрометированного контейнера, что указывает на недостаточные меры сетевой изоляции.
3. Раскрытие конфиденциальных данных: Из-за ошибок конфигурации злоумышленник смог получить доступ и украсть большое количество конфиденциальных данных клиентов.
4. Ошибки конфигурации безопасности: Основной причиной всего инцидента стало накопление множества ошибок конфигурации безопасности, включая проблемы конфигурации контейнеров и облачных сервисов.

Этот инцидент привел к значительным финансовым потерям и ущербу репутации Capital One. Сообщается, что компания столкнулась со штрафами до 150 миллионов долларов из-за этого инцидента, а также с долгосрочным кризисом доверия. Этот случай подчеркивает важность конфигурации безопасности в контейнерных и облачных средах, особенно в управлении разрешениями, сетевой изоляции и защите конфиденциальных данных. Он напоминает нам, что даже, казалось бы, незначительные ошибки конфигурации могут быть использованы злоумышленниками, что приводит к катастрофическим последствиям.

IV. Заключение и рекомендации​

Docker Compose в сочетании с Ubuntu — это удобный способ быстрого развертывания контейнерных приложений, но безопасность должна быть интегрирована на протяжении всего процесса:

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

Безопасность — это непрерывная практика без конечной точки. Надеюсь, эта статья поможет вам лучше защитить вашу среду развертывания Docker Compose + Ubuntu.