29 постов с тегом "Безопасность"

Одно из ключевых обещаний технологии блокчейн, такой как 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.