Admin
Администратор
Вступление
И снова здравствуйте, уважаемые форумчане. На повестке сегодняшней статьи у нас попытка описать и одновременно реализовать один из элементов части безопасной инфраструктуры в лице запрятанного в управляемый нами узел сети ТОР классического биткоин кошелька Bitcoin Core с набором данных по цепочкам транзакций криптовалютной сети биткоин. Данное решение не призвано защитить конфиденциальность самих транзакций и их владельцев в контексте уровня операций криптовалютной сети, но в то же время способно сделать более безопасным сам узел на уровне сетевого и прикладного взаимодействия в рамках стека OSI, начиная с маскировки сетевых идентификаторов того узла где расположено приложение кошелька и операций сетевого обмена данными с ним, заканчивая обеспечением безопасности взаимодействия прикладных служб уровня приложений, включая приложения самого кошелька. В статье так же не предполагается раскрытие информации об устройстве криптовалютной сети, о компонентах ее составляющих и их взаимодействии, в том числе на уровне транзакций, как не предполагается и обучения этой тематике. В общем, речь будет идти исключительно о настройках безопасности компьютерной системы и Интернет сети поверх которой работает сеть биткоин, но при этом без специального углубления в логику работы самих критовалютных систем и блокчейн технологий. И в то же время, с учетом особенностей их взаимодействия между компьютерными системами и блокчейн сетью там где это целесообразно и необходимо.
Теперь давайте рассмотрим схему нашего решения и коротко опишем применяемые в схеме технологии. Как уже было упомянуто, мы прячем холодный кошелек bitcoin core в сети ТОР. Это предполагает использование как самого приложения кошелька, так и программы обеспечивающей работу хоста в сети ТОР. В нашем с вами примере мы работаем с окружением Linux, а значит все версии используемых приложений должны быть выбраны именно для этой операционной системы. Итак, приведем перечень технологий и продуктов выбранных для реализации предлагаемого решения:
1) Дистрибутив операционной системы Linux - для упрощения процесса настройки остановимся на свежей версии Ubuntu во-первых по причине его наибольшей распространенности. Тем более и во-вторых, в данной статье мы и не преследуем цель изучать особенности какого-либо конкретного дистрибутива, а выбираем самый неприхотливый с точки зрения использования для большинства уровней технической подготовки пользователя. При этом данная система была выбрана еще потому, что имеет в наличии множество штатных средств защиты информации широкой функциональности и гибкости, включая защиту процессов, данных, пользователей и многого другого. Имеется ввиду различные модели разграничения доступа, в том числе ролевые, например selinux, apparmor, многоуровневые межсетевые экраны, такие как netfilter(с оболочками iptables, nftables), системы обнаружения и предотвращения вторжений(к примеру snort), мониторинга(zabbix,prometheus), журналирования и реагирования на инциденты. И важная составляющая их особенности заключается в открытости кода и условной бесплатности решений. Но особенности конфигурирования упомянутых компонентов в текущей статье к рассмотрению не предполагаются, но планируется сделать в дальнейшем в будущих публикациях.
2) Комплексная прокси - система ТОР для туннелирования и обфускации сетевых идентификаторов и маршрутов сети Интернет, а так же шифрования проходящих путем ее использования направляемых потоков данных. Большинству участников данный продукт хорошо знаком, по крайней мере по опыту практического использования, а потому в детальном представлении особенно не нуждается, но в рамках настройки нашего решения некоторые основы ее функционирования и конфигурации рассмотреть придется, тут уж как ни крути. Одним словом, будем прятать кошелек внутри ТОР и применять настройки безопасности, которые предоставляются его конфигурационными возможностями.
3) Luks(dm-crypt) - система шифрования объектов носителей информации, включая диски, их объединения и массивы, в том числе низкоуровневые LVM разделы, разделы для файловых систем, а так же отдельные файлы и файлы образов. Данная система позволяет создавать зашифрованные области в самых различных вариантах с целью обеспечения защиты статической информации от кражи и интерпретации. В нашем случае будем шифровать как конфигурацию решения и его компонентов, так и блоки данных, и информацию об операциях, необходимую системе для функционирования с биткоин сети.
4) Bitcoin Core - собственно сам кошелек и основное звено конфигурации. Указанное решение является классическим и одним из наиболее распространенных продуктов от разработчиков bitcoin, и известный как одноименная служба bitcoind в linux. Bitcoin Core требует загрузки полной цепочки блоков, то есть фактически он загружает и хранит полную историю всех транзакций в блокчейне Bitcoin, если используется именно эта криптовалютная сеть. Кошелек может создавать новые адреса, отправлять и получать средства, а также шифровать данные, а пользователи могут создавать и подписывать транзакции. Bitcoin Core проверяет каждую транзакцию на корректность, прежде чем добавить её в блокчейн. При первом запуске загружается весь блокчейн, что может занять достаточно много времени и места на носителе. После первой и полной синхронизации клиент кошелька поддерживает актуальность данных путем инкрементной синхронизации, загружая только новые блоки. Свежие версии данного кошелька имеют многочисленные и весьма широкие современные возможности, в том числе для обеспечения безопасности продукта. Выбор пал на него исключительно из соображений распространенности, неплохой функциональности и достаточно простой настройки, аналогично выбору ОС Ubuntu, упомянутой в первом пункте.
5) Armory - специальное приложение созданное как дополнение к кошельку. Оно работает во взаимодействии с Bitcoin Core в качестве узла, который загружает и синхронизирует блокчейн, а также обрабатывает транзакции. Armory взаимодействует с Bitcoin Core через RPC, обеспечивая пользователям возможность более безопасного хранения и управления кошельком и биткойнами. Так же он позволяет пользователям хранить приватные ключи в оффлайн режиме(так называемое "холодное хранение"), поддерживает создание многоподписнных кошельков, что позволяет нескольким пользователям совместно управлять средствами. Кроме того, данная программа предлагает пользователям многочисленные полезные инструменты для управления одновременно несколькими адресами и кошельками, а также возможность создания резервных копий и восстановления. В общем, достаточно полезный инструмент, но фишка в том, что он имеет чуть более сложный интерфейс по сравнению с другими кошельками, что может быть полезно для опытных пользователей.
6) Docker контейнеризация - ну и наконец, в рамках одного из возможных вариантов конфигурации попробуем применить относительно современный подход контейнеризации в среде Linux, так как этот дополнительный, и отчасти казалось бы лишний слой инфраструктурной реализации может быть весьма полезным в части применения более расширенных возможностей настройки безопасного окружения для многих вариантов развертывания решений. Что бы и попробуем детально раскрыть и продемонстрировать. Для примера используем Docker с сопутствующими ему стандартными компонентами: cgroups, namespaces которые и помогут нам ввести дополнительные разграничения. Про сам докер и дополнительные возможности его использования и защиты можно найти и изучить массу информации в Интернет, недостатка в которой нет.
Вот и пришло время перейти от вводной теоретической части к практике и заняться непосредственно настройкой защищенного кошелька, запрятанного в сети ТОР. Как уже упоминалось ранее, мы будем последовательно рассматривать две конфигурации - с использованием контейнеризированной версии на основе Docker, а предварительно выполним настройку без использования контейнеризации. Приступим.
Установим сразу почти все необходимое программное обеспечение, за исключением того, к которому потребуются отдельные пояснения:
Ставим отдельно armory посредством git:
Существует так же вариант автономной установки deb пакета в ручном режиме, например через инструмент apt-offline пакетного менеджера apt-get и dpkg, но с этим способом при необходимости вы справитесь и самостоятельно, инструкции того как это делать в сети имеются.
И для варианта с контейнеризацией скорее всего предварительно потребуются дополнительные шаги по установки более свежей версии докер:
Добавьте gpg ключ для репозитория Docker:
Добавьте репозиторий Docker:
И устанавливаем сам докер:
Вариант настройки без docker:
1. Настраиваем криптосистему luks c возможностью экстренного уничтожения данных
Для начала выполняем следующую группу команд в терминале:
Если в двух словах, то здесь мы создаем точку монтирования в виде директории /home/bitcore/lukspartition, затем делаем файл образа /home/bitcore/luks.img на котором впоследствии формируем файловую криптосистему, монтируем образ во вновь созданное для этого блочное устройство lukspartition(/dev/mapper/lukspartition), затем форматируем его и записываем файловую систему ext4, и наконец монтируем к созданному устройству с прикрепленным образом первоначально созданную точку монтирования. Кроме того, если мы по какой-либо причине захотим создать шифрованный образ более детализировано и гибко, пожалуйста, можно делать это с указанием дополнительных параметров:
с - выбор алгоритма шифрования. aes используется по умолчанию. (cписок доступных алгоритмов можно посмотреть таким образом: cat /proc/crypto). s - длинна ключа
Для автоматизации подключения зашифрованного раздела можно использовать файлы /etc/crypttab и /etc/fstab. Кроме того, не забывайте и про swap раздел, в том случае конечно, если они используется в вашей системе.
Теперь установим упомянутую выше функцию Nuke с секретным паролем для системы luks в случае ввода такого пароля, например при первоначальной загрузке операционной системы, или же при ручном монтировании криптораздела в файловую систему, доступ к зашифрованным данным будет мгновенно прекращен. Фактически будут стерты все ключи заголовка dmcrypt.
Установим необходимое ПО:
Затем вводим команду инициализации специального пароля.
После ввода данной команды мы попадаем в псевдографическое меню, которое предложит нам ввести пароль для уничтожения диска.
Вводим пароль, запоминаем и после установки пароля вводим следующую команду:
Теперь, после перезагрузки, вы сможете уничтожать свой зашифрованный раздел или его ключи специальным паролем, при необходимости разумеется. И не забываем заранее сохранить копии всех ключей разделов, как уже было упомянуто ранее.
2. Настраиваем tor+torrc
Давайте кратко рассмотрим значение параметров файла torrc:
Тут все относительно понятно. Параметр RunAsDaemon устанавливает режим сервера, DataDirectory определяет директорию с данными TOP, включая конфигурацию и контент для скрытых сервисов, среди которых кошелек bitcoin core. Далее идет блок определения настроек Socks: SocksPort и SockBindAddress, отвечающие за сетевые настройки узла ТОР, наш узел слушает сеть ТОР для связи с другими узлами на внутреннем сетевом интерфейсе на порту 9075(по умолчанию tor использует socks порт 9050). В некоторых случая вместо SocksPort целесообразно применять TransPort, он умеет заворачивать трафик без протокола Socks, а также использовать сторонние проксификаторы, но в данном случае это сильно избыточно, так как кошелек имеет внетренние возможности для работы с протоколом Socks почти любых версий. HiddenServiceDir и HiddenServicePort устанавливают окружение(в данном случае, как нетрудно догадаться, - местоположение данных и сетевой сокет) для развертывания скрытых служб внутри ТОР, что и является нашей основной задачей и главной целью статьи. Если вы обратили внимание, то мы развернули сразу три скрытые службы внутри ТОР: непосредственно сам кошелек core, дополнение armory и сервер ssh. И напоследок пара опций усиливающих безопасность, значение которых нетрудно логически понять из приведенного контекста. Более детальное описание этих и остальных параметров можно изучить в официальной документации и при необходимости произвести дополнительные настройки, так как более подробные и тонкие настройки, особенно связанные со сторонними службами не являются основной целью данной статьи. Наша основная задача-обозначить главную суть и указать вектор для конфигурирования безопасной схемы.
3. Настраиваем bitcoin core
Давайте кратко рассмотрим значение параметров файла bitcoin.conf:
Директива server указывает на режим работы кошелька, исходя из контекста понятно что 1 означает режим сервера. listen - разрешает прослушивание сервером входящих соединений, на что указывает значение 1. Далее идут параметры определяющие пути размещения данных конфигурации и кошелька с копией блокчейн транзакций, затем блок управления RPC(включая параметры аутентификации rpcuser и rpcpassword, правда в некоторых версиях вместо них может быть использован объединенный параметр rpcauth в формате user
assword). Блок RPC необходим в том числе для связи с дополнительным приложением armory, являющимся фактически дополнением к bitcoin core в качестве модуля безопасности. Обратите особое внимание на то, чтобы доступ к службам RPC доступ из внешних сетей был строго ограничен на сетевом и прикладном уровнях из-за уязвимости данного протокола. Затем следуют директивы сетевых настроек, таких как port, bind, listenonion(разрешение на прослушивание из сети ТОР), proxy - перенаправление всех запросов и данных блокчейн сети на порт ТОР, testnet, указывающий на то что используется только основная(боевая) сетка блокчейн, а тестовая отключается, ну и параметр encrypt, разрешающий шифрование и запароливание кошелька. Правда в некоторых версиях вместо нее применяется директива walletencrypt.
Приведем несколько примеров использования общего синтаксиса различных команд для командной строки для управления кошельком bitcoin core и его функционалом:
Примет запуск Bitcoin Core с параметрами в виде опций и из командной строки:
Проверка статуса синхронизации с блокчейн-сетью:
Проверка статуса подключения кошелька к блокчейн-сети:
Получение информации о кошельке:
Отправка биткойнов:
Получение адреса:
Зашифровывание кошелька из терминала:
Полный перечень команд и их возможности вы можете изучить в официальной документации по bitcoin core.
4. Настраиваем Armory. Ниже приведен пример самых необходимых настроек файла конфигурации armory.conf:
Давайте кратко рассмотрим значение параметров файла armory.conf:
Datadir определяет путь к каталогу для хранения данных Armory, далее идет группа настроек RPC, которая реализует необходимые настройки для связи с основным приложением bitcoin core, включая аутентификацию и авторизацию. Эти настройки должны совпадать с указанными для основного узла/приложения bitcoin core.
Вариант настройки с docker.
Приводим пример настройки варианта Docker почти ничем не отличается от бесконтейнерного варианта, за исключением того, что сам кошелек мы усадим в контейнер, а сам контейнер, данные для всех нужных сервисов, включая конфигурации, данные самого контейнера, включая информацию блокчейн сети мы по аналогии расположим в криптоконтейнере luks, контейнерную часть которого благополучно примонтируем к контейнеру докер.
1. Итак, установку докера в систему мы для удобства и краткости произвели в самом начале вместе с остальным ПО, необходимым для демонстрации примеров. Следующим шагом производим установку cryptsetup в точно таком же порядке, как мы делали это в варианте конфигурации без использования Docker. Далее, создадим директорию для хранения данных контейнера и делаем зашифрованный раздел пошагово и по аналогии с вариантом без контейнеризации, приведенным выше. После чего приступаем к реализации установки версии с докер:
Измените права доступа. Убедитесь, что Docker имеет доступ к директории, либо присвойте ей такие права:
Теперь пишем небольшую инфраструктуру(IAC) для автоматического развертывания bitcoin core внутри докер контейнера:
Переходим в рабочую директорию:
2. Создаем файл конфигурации кошелька:
Тут все примерно так же, как в первом случае настройки. Идем дальше.
3. Создаем запускаемый при старте контейнера bash скрипт, разворачивающий переменные окружения, и другие компоненты контейнера, включая имена пользователей и групп необходимых для его функционирования:
4. Создаем сценарий Dockerfile для сборки образа контейнера кошелька:
5. Создаем docker-compose.yaml как точки входа для сборки контейнеров в системе docker:
Все что делает docker compose, это реализует сценарии более оптимизированных, массовых и главное автоматизированных многокомпонентых развертываний контейнеров на основе более сложных и комплексных схем, чем просто единичных развертываний с помощью сценариев Dockerfile.
6. В данном случае docker compose производит запуск сборки из Dockerfile.
Либо мы можем не использовать docker compose, а например последовательно применить сначала "docker build" для сборки контейнера на основе Dockerfile, а затем "docker run -d" для его запуска в режиме сервера.
В качестве замечания, стоит упомянуть, что бывает так, что при использовании зашифрованных разделов luks, монтируемых в контейнеры docker возникают определенного рода сложности, такие как невозможность подключения зашифрованного тома внутрь контейнера, либо другие ошибки, например когда команды luksFormat и luksOpen не работают внутри окружения контейнера. Обычно это связано с тем, что luks/dm-crypm создает временные блочные устройства в контексте /dev/mapper, которые при этом не находится в разрешенных группах cgroups устройств контейнера, следовательно доступ к ним запрещён. Возможное опциональное решение - это открыть блочное устройство luks/dmcrypt на основном(центральном) хосте вручную с уникальным именем, а затем уже вручную экспортировать его в контейнер как отдельное блочное устройство. Контейнер не может активировать устройства /dev/mapper внутри контейнера, так как для этого обычно требуется root, так же внутри контейнера нет технической возможности настройки системы управления узлами устройств udev. В таком случае, возможным выходом из данной ситуации может стать оптимизация настроек ioctl для блочных устройств внутри контейнеров. Но этим потенциальные проблемы при интеграции криптоконтейнеров с контейнерами докер отнюдь не ограничиваются и это отдельная и достаточно широкая тема для экспериментов.
Ну и напоследок, приведу в пример команду терминала linux необходимую для подключения к ssh серверу, расположенному в ТОР сети(раз уж мы его там разместили):
Вроде бы все чем хотелось поделиться, переходим к заключительному абзацу-)
Заключение
Рассмотрение вариантов конфигурации безопасного кошелька подошло к концу и пришло время подвести итоги. Мы с вами увидели казалось бы банальный случай настройки очередного скрытого сервиса в специальной сети ТОР. Ну подумаешь, вроде как ничего особенного, публиковалось в сети уже много всевозможного материала на эту тему, по инсталляции различных сервисов и служб в ТОР, и офисных, и коммуникационных, и web-проектов, и много чего другого. И при всем при этом, кому в голову придет специально скрывать в закрытой сети ТОР именно криптовалютный кошелек, если транзакции криптовалютной сети считаются условно анонимными, что кстати не совсем верно. Правда вот никогда не стоит забывать, что контур безопасности не ограничивается одним лишь аспектом, в данном случае защищенностью сети биткоин транзакций, а атаки обычно многоконтурны и многовекторны и направлены сразу на многие точки входа на различных уровнях работы систем и их взаимодействия. Могут быть атакованы операционные системы, компьютерные локальные и глобальные сети, прикладной уровень приложений, в частности отвечающих за хранение и обработку данных криптовалютной сети, в том числе ваших финансовых средств, функционирующий на уровнях взаимодействия операционных систем и сетей по ширине всего стека. А потому, с учетом всего вышесказанного, приходится принимать максимально широкие меры защиты в контексте всего периметра инфраструктуры и всех уровней системного и сетевого стеков. Что мы здесь и постарались обозначить на практике, на примере настройки защищенной конфигурации сетевого узла для криптовалютного кошелька bitcoin core, поместив его в сеть ТОР. Надеюсь что для кого-то информация в статье была или будет в будущем полезной и познавательной, и каждый, даже гораздо более опытный пользователь сможет извлечь из нее хоть что-то нужное как в практическом, так и в теоретическом смысле. И еще раз, - не забывайте о том, что как бы вы ни старались защитить свою систему или инфраструктуру, всегда останется или найдется необнаруженная вами брешь, которую наверняка рано или поздно смогут нащупать более продвинутые и упрямые специалисты, что следует обязательно учитывать в ваших развертываниях и настройках. Тут как говорится, нет предела совершенству, как в части защиты, так и нападения. Прогресс не стоит на месте-) Помните так же о том, что чем более наворочена конфигурация, тем более повышается степень вероятности ее уязвимости уже со стороны возможных известных, либо неизвестных брешей в ее компонентах. Минимализм или максимализм конфигураций - такая же сложная и важная дилемма в контексте безопасности, как само по себе состязание сторон защиты и нападения. Будем работать дальше!
И снова здравствуйте, уважаемые форумчане. На повестке сегодняшней статьи у нас попытка описать и одновременно реализовать один из элементов части безопасной инфраструктуры в лице запрятанного в управляемый нами узел сети ТОР классического биткоин кошелька Bitcoin Core с набором данных по цепочкам транзакций криптовалютной сети биткоин. Данное решение не призвано защитить конфиденциальность самих транзакций и их владельцев в контексте уровня операций криптовалютной сети, но в то же время способно сделать более безопасным сам узел на уровне сетевого и прикладного взаимодействия в рамках стека OSI, начиная с маскировки сетевых идентификаторов того узла где расположено приложение кошелька и операций сетевого обмена данными с ним, заканчивая обеспечением безопасности взаимодействия прикладных служб уровня приложений, включая приложения самого кошелька. В статье так же не предполагается раскрытие информации об устройстве криптовалютной сети, о компонентах ее составляющих и их взаимодействии, в том числе на уровне транзакций, как не предполагается и обучения этой тематике. В общем, речь будет идти исключительно о настройках безопасности компьютерной системы и Интернет сети поверх которой работает сеть биткоин, но при этом без специального углубления в логику работы самих критовалютных систем и блокчейн технологий. И в то же время, с учетом особенностей их взаимодействия между компьютерными системами и блокчейн сетью там где это целесообразно и необходимо.
Теперь давайте рассмотрим схему нашего решения и коротко опишем применяемые в схеме технологии. Как уже было упомянуто, мы прячем холодный кошелек bitcoin core в сети ТОР. Это предполагает использование как самого приложения кошелька, так и программы обеспечивающей работу хоста в сети ТОР. В нашем с вами примере мы работаем с окружением Linux, а значит все версии используемых приложений должны быть выбраны именно для этой операционной системы. Итак, приведем перечень технологий и продуктов выбранных для реализации предлагаемого решения:
1) Дистрибутив операционной системы Linux - для упрощения процесса настройки остановимся на свежей версии Ubuntu во-первых по причине его наибольшей распространенности. Тем более и во-вторых, в данной статье мы и не преследуем цель изучать особенности какого-либо конкретного дистрибутива, а выбираем самый неприхотливый с точки зрения использования для большинства уровней технической подготовки пользователя. При этом данная система была выбрана еще потому, что имеет в наличии множество штатных средств защиты информации широкой функциональности и гибкости, включая защиту процессов, данных, пользователей и многого другого. Имеется ввиду различные модели разграничения доступа, в том числе ролевые, например selinux, apparmor, многоуровневые межсетевые экраны, такие как netfilter(с оболочками iptables, nftables), системы обнаружения и предотвращения вторжений(к примеру snort), мониторинга(zabbix,prometheus), журналирования и реагирования на инциденты. И важная составляющая их особенности заключается в открытости кода и условной бесплатности решений. Но особенности конфигурирования упомянутых компонентов в текущей статье к рассмотрению не предполагаются, но планируется сделать в дальнейшем в будущих публикациях.
2) Комплексная прокси - система ТОР для туннелирования и обфускации сетевых идентификаторов и маршрутов сети Интернет, а так же шифрования проходящих путем ее использования направляемых потоков данных. Большинству участников данный продукт хорошо знаком, по крайней мере по опыту практического использования, а потому в детальном представлении особенно не нуждается, но в рамках настройки нашего решения некоторые основы ее функционирования и конфигурации рассмотреть придется, тут уж как ни крути. Одним словом, будем прятать кошелек внутри ТОР и применять настройки безопасности, которые предоставляются его конфигурационными возможностями.
3) Luks(dm-crypt) - система шифрования объектов носителей информации, включая диски, их объединения и массивы, в том числе низкоуровневые LVM разделы, разделы для файловых систем, а так же отдельные файлы и файлы образов. Данная система позволяет создавать зашифрованные области в самых различных вариантах с целью обеспечения защиты статической информации от кражи и интерпретации. В нашем случае будем шифровать как конфигурацию решения и его компонентов, так и блоки данных, и информацию об операциях, необходимую системе для функционирования с биткоин сети.
4) Bitcoin Core - собственно сам кошелек и основное звено конфигурации. Указанное решение является классическим и одним из наиболее распространенных продуктов от разработчиков bitcoin, и известный как одноименная служба bitcoind в linux. Bitcoin Core требует загрузки полной цепочки блоков, то есть фактически он загружает и хранит полную историю всех транзакций в блокчейне Bitcoin, если используется именно эта криптовалютная сеть. Кошелек может создавать новые адреса, отправлять и получать средства, а также шифровать данные, а пользователи могут создавать и подписывать транзакции. Bitcoin Core проверяет каждую транзакцию на корректность, прежде чем добавить её в блокчейн. При первом запуске загружается весь блокчейн, что может занять достаточно много времени и места на носителе. После первой и полной синхронизации клиент кошелька поддерживает актуальность данных путем инкрементной синхронизации, загружая только новые блоки. Свежие версии данного кошелька имеют многочисленные и весьма широкие современные возможности, в том числе для обеспечения безопасности продукта. Выбор пал на него исключительно из соображений распространенности, неплохой функциональности и достаточно простой настройки, аналогично выбору ОС Ubuntu, упомянутой в первом пункте.
5) Armory - специальное приложение созданное как дополнение к кошельку. Оно работает во взаимодействии с Bitcoin Core в качестве узла, который загружает и синхронизирует блокчейн, а также обрабатывает транзакции. Armory взаимодействует с Bitcoin Core через RPC, обеспечивая пользователям возможность более безопасного хранения и управления кошельком и биткойнами. Так же он позволяет пользователям хранить приватные ключи в оффлайн режиме(так называемое "холодное хранение"), поддерживает создание многоподписнных кошельков, что позволяет нескольким пользователям совместно управлять средствами. Кроме того, данная программа предлагает пользователям многочисленные полезные инструменты для управления одновременно несколькими адресами и кошельками, а также возможность создания резервных копий и восстановления. В общем, достаточно полезный инструмент, но фишка в том, что он имеет чуть более сложный интерфейс по сравнению с другими кошельками, что может быть полезно для опытных пользователей.
6) Docker контейнеризация - ну и наконец, в рамках одного из возможных вариантов конфигурации попробуем применить относительно современный подход контейнеризации в среде Linux, так как этот дополнительный, и отчасти казалось бы лишний слой инфраструктурной реализации может быть весьма полезным в части применения более расширенных возможностей настройки безопасного окружения для многих вариантов развертывания решений. Что бы и попробуем детально раскрыть и продемонстрировать. Для примера используем Docker с сопутствующими ему стандартными компонентами: cgroups, namespaces которые и помогут нам ввести дополнительные разграничения. Про сам докер и дополнительные возможности его использования и защиты можно найти и изучить массу информации в Интернет, недостатка в которой нет.
Вот и пришло время перейти от вводной теоретической части к практике и заняться непосредственно настройкой защищенного кошелька, запрятанного в сети ТОР. Как уже упоминалось ранее, мы будем последовательно рассматривать две конфигурации - с использованием контейнеризированной версии на основе Docker, а предварительно выполним настройку без использования контейнеризации. Приступим.
Установим сразу почти все необходимое программное обеспечение, за исключением того, к которому потребуются отдельные пояснения:
Код:
# apt update
# apt upgrade
# apt install cryptsetup tor bitcoin-qt bitcoind apt install python3 python3-pyqt5 python3-pyqt5.qtsvg python3-pyqt5.qtwebengine python3-pyqt5.qtwebkit \
python3-pyqt5.qtquick python3-pyqt5.qtquickcontrols python3-pyqt5.qtmultimedia python3-qt5 python3-pyqt5.qtsql git apt-transport-https ca-certificates \
curl software-properties-commonСтавим отдельно armory посредством git:
Код:
# git clone https://github.com/Armory3D/Armory.git
# cd Armory
# python3 ./run.pyСуществует так же вариант автономной установки deb пакета в ручном режиме, например через инструмент apt-offline пакетного менеджера apt-get и dpkg, но с этим способом при необходимости вы справитесь и самостоятельно, инструкции того как это делать в сети имеются.
И для варианта с контейнеризацией скорее всего предварительно потребуются дополнительные шаги по установки более свежей версии докер:
Добавьте gpg ключ для репозитория Docker:
Код:
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -Добавьте репозиторий Docker:
Код:
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"И устанавливаем сам докер:
Код:
# apt install docker-ceВариант настройки без docker:
1. Настраиваем криптосистему luks c возможностью экстренного уничтожения данных
Для начала выполняем следующую группу команд в терминале:
Код:
# mkdir -p /home/bitcore/lukspartition
# dd if=/dev/zero of=/home/bitcore/luks.img bs=15M count=1000
# cryptsetup -y luksFormat /home/bitcore/luks.img
# cryptsetup open /home/bitcore/luks.img lukspartition
# mkfs.ext4 -j /dev/mapper/lukspartition
# mount /dev/mapper/lukspartition /home/bitcore/lukspartitionЕсли в двух словах, то здесь мы создаем точку монтирования в виде директории /home/bitcore/lukspartition, затем делаем файл образа /home/bitcore/luks.img на котором впоследствии формируем файловую криптосистему, монтируем образ во вновь созданное для этого блочное устройство lukspartition(/dev/mapper/lukspartition), затем форматируем его и записываем файловую систему ext4, и наконец монтируем к созданному устройству с прикрепленным образом первоначально созданную точку монтирования. Кроме того, если мы по какой-либо причине захотим создать шифрованный образ более детализировано и гибко, пожалуйста, можно делать это с указанием дополнительных параметров:
Код:
# cryptsetup -c aes -s 256 luksFormat /home/bitcore/luks.imgс - выбор алгоритма шифрования. aes используется по умолчанию. (cписок доступных алгоритмов можно посмотреть таким образом: cat /proc/crypto). s - длинна ключа
Для автоматизации подключения зашифрованного раздела можно использовать файлы /etc/crypttab и /etc/fstab. Кроме того, не забывайте и про swap раздел, в том случае конечно, если они используется в вашей системе.
Теперь установим упомянутую выше функцию Nuke с секретным паролем для системы luks в случае ввода такого пароля, например при первоначальной загрузке операционной системы, или же при ручном монтировании криптораздела в файловую систему, доступ к зашифрованным данным будет мгновенно прекращен. Фактически будут стерты все ключи заголовка dmcrypt.
Установим необходимое ПО:
Код:
# apt install cryptsetup-nuke-passwordЗатем вводим команду инициализации специального пароля.
Код:
# dpkg-reconfigure cryptsetup-nuke-passwordПосле ввода данной команды мы попадаем в псевдографическое меню, которое предложит нам ввести пароль для уничтожения диска.
Вводим пароль, запоминаем и после установки пароля вводим следующую команду:
Код:
# update-initramfs -uТеперь, после перезагрузки, вы сможете уничтожать свой зашифрованный раздел или его ключи специальным паролем, при необходимости разумеется. И не забываем заранее сохранить копии всех ключей разделов, как уже было упомянуто ранее.
2. Настраиваем tor+torrc
Код:
torrc:
Код:
RunAsDaemon 1
DataDirectory /home/bitcore/lukspartition/tor
SocksPort 9075
SocksBindAddress 127.0.0.1
SocksPolicy accept 127.0.0.1
SocksPolicy reject *
HiddenServiceDir /home/bitcore/lukspartition/tor/hidden_service
HiddenServicePort 8334 127.0.0.1:8334
HiddenServiceDir /home/bitcore/lukspartition/tor/hidden_service
HiddenServicePort 8335 127.0.0.1:8335
HiddenServiceDir /home/bitcore/lukspartition/tor/hidden_service
HiddenServicePort 22 127.0.0.1:22
DisableDebuggerAttachment 1
SecurityLevel highДавайте кратко рассмотрим значение параметров файла torrc:
Тут все относительно понятно. Параметр RunAsDaemon устанавливает режим сервера, DataDirectory определяет директорию с данными TOP, включая конфигурацию и контент для скрытых сервисов, среди которых кошелек bitcoin core. Далее идет блок определения настроек Socks: SocksPort и SockBindAddress, отвечающие за сетевые настройки узла ТОР, наш узел слушает сеть ТОР для связи с другими узлами на внутреннем сетевом интерфейсе на порту 9075(по умолчанию tor использует socks порт 9050). В некоторых случая вместо SocksPort целесообразно применять TransPort, он умеет заворачивать трафик без протокола Socks, а также использовать сторонние проксификаторы, но в данном случае это сильно избыточно, так как кошелек имеет внетренние возможности для работы с протоколом Socks почти любых версий. HiddenServiceDir и HiddenServicePort устанавливают окружение(в данном случае, как нетрудно догадаться, - местоположение данных и сетевой сокет) для развертывания скрытых служб внутри ТОР, что и является нашей основной задачей и главной целью статьи. Если вы обратили внимание, то мы развернули сразу три скрытые службы внутри ТОР: непосредственно сам кошелек core, дополнение armory и сервер ssh. И напоследок пара опций усиливающих безопасность, значение которых нетрудно логически понять из приведенного контекста. Более детальное описание этих и остальных параметров можно изучить в официальной документации и при необходимости произвести дополнительные настройки, так как более подробные и тонкие настройки, особенно связанные со сторонними службами не являются основной целью данной статьи. Наша основная задача-обозначить главную суть и указать вектор для конфигурирования безопасной схемы.
3. Настраиваем bitcoin core
Код:
bitcoin.conf:
Код:
server=1
listen=1
wallet=1
datadir=/home/bitcore/lukspartition/.bitcoin
walletdir=/home/bitcore/lukspartition/.bitcoin/wallets
rpcallowip=127.0.0.1
rpcport=8335
rpcuser=xssis_user
rpcpassword=xssis_password
port=8334
bind=127.0.0.1:8334
listenonion=1
socks=5
proxy=127.0.0.1:9075
testnet=0
encrypt=1Давайте кратко рассмотрим значение параметров файла bitcoin.conf:
Директива server указывает на режим работы кошелька, исходя из контекста понятно что 1 означает режим сервера. listen - разрешает прослушивание сервером входящих соединений, на что указывает значение 1. Далее идут параметры определяющие пути размещения данных конфигурации и кошелька с копией блокчейн транзакций, затем блок управления RPC(включая параметры аутентификации rpcuser и rpcpassword, правда в некоторых версиях вместо них может быть использован объединенный параметр rpcauth в формате user
assword). Блок RPC необходим в том числе для связи с дополнительным приложением armory, являющимся фактически дополнением к bitcoin core в качестве модуля безопасности. Обратите особое внимание на то, чтобы доступ к службам RPC доступ из внешних сетей был строго ограничен на сетевом и прикладном уровнях из-за уязвимости данного протокола. Затем следуют директивы сетевых настроек, таких как port, bind, listenonion(разрешение на прослушивание из сети ТОР), proxy - перенаправление всех запросов и данных блокчейн сети на порт ТОР, testnet, указывающий на то что используется только основная(боевая) сетка блокчейн, а тестовая отключается, ну и параметр encrypt, разрешающий шифрование и запароливание кошелька. Правда в некоторых версиях вместо нее применяется директива walletencrypt.Приведем несколько примеров использования общего синтаксиса различных команд для командной строки для управления кошельком bitcoin core и его функционалом:
Примет запуск Bitcoin Core с параметрами в виде опций и из командной строки:
Код:
# bitcoin-qt -datadir=/home/bitcore/lukspartition -server=1Проверка статуса синхронизации с блокчейн-сетью:
Код:
# bitcoin-cli getblockchaininfoПроверка статуса подключения кошелька к блокчейн-сети:
Код:
# bitcoin-cli getconnectioncountПолучение информации о кошельке:
Код:
# bitcoin-cli getbalanceОтправка биткойнов:
Код:
# bitcoin-cli sendtoaddressПолучение адреса:
Код:
# bitcoin-cli getnewaddressЗашифровывание кошелька из терминала:
Код:
# encryptwallet "xssis_wallet_password"Полный перечень команд и их возможности вы можете изучить в официальной документации по bitcoin core.
4. Настраиваем Armory. Ниже приведен пример самых необходимых настроек файла конфигурации armory.conf:
Код:
datadir=/home/bitcore/lukspartition/.armory
bitcoinRPCServer=127.0.0.1
bitcoinRPCPort=8335
bitcoinRPCUser=XSSIS_USER
bitcoinRPCPassword=xssis_passwordДавайте кратко рассмотрим значение параметров файла armory.conf:
Datadir определяет путь к каталогу для хранения данных Armory, далее идет группа настроек RPC, которая реализует необходимые настройки для связи с основным приложением bitcoin core, включая аутентификацию и авторизацию. Эти настройки должны совпадать с указанными для основного узла/приложения bitcoin core.
Вариант настройки с docker.
Приводим пример настройки варианта Docker почти ничем не отличается от бесконтейнерного варианта, за исключением того, что сам кошелек мы усадим в контейнер, а сам контейнер, данные для всех нужных сервисов, включая конфигурации, данные самого контейнера, включая информацию блокчейн сети мы по аналогии расположим в криптоконтейнере luks, контейнерную часть которого благополучно примонтируем к контейнеру докер.
1. Итак, установку докера в систему мы для удобства и краткости произвели в самом начале вместе с остальным ПО, необходимым для демонстрации примеров. Следующим шагом производим установку cryptsetup в точно таком же порядке, как мы делали это в варианте конфигурации без использования Docker. Далее, создадим директорию для хранения данных контейнера и делаем зашифрованный раздел пошагово и по аналогии с вариантом без контейнеризации, приведенным выше. После чего приступаем к реализации установки версии с докер:
Код:
# useradd bitcoin && groupadd bitcoin
# mkdir -p /home/bitcore/lukspartition
# dd if=/dev/zero of=/home/bitcore/luks.img bs=15M count=1000
# cryptsetup -y luksFormat /home/bitcore/luks.img
# cryptsetup open /home/bitcore/luks.img lukspartition
# mkfs.ext4 -j /dev/mapper/lukspartition
# mount /dev/mapper/lukspartition /home/bitcore/lukspartitionИзмените права доступа. Убедитесь, что Docker имеет доступ к директории, либо присвойте ей такие права:
Код:
# chown -R bitcoin:bitcoin /home/bitcore/lukspartitionТеперь пишем небольшую инфраструктуру(IAC) для автоматического развертывания bitcoin core внутри докер контейнера:
Переходим в рабочую директорию:
Код:
# cd /home/bitcore/lukspartition2. Создаем файл конфигурации кошелька:
Код:
# cat > /home/bitcore/lukspartition/bitcoin.conf
Код:
server=1
listen=1
wallet=1
datadir=/home/bitcore/lukspartition/.bitcoin
walletdir=/home/bitcore/lukspartition/.bitcoin/wallets
rpcallowip=127.0.0.1
rpcport=8335
rpcuser=xssis_user
rpcpassword=xssis_password
port=8334
bind=127.0.0.1:8334
listenonion=1
socks=5
proxy=127.0.0.1:9075
testnet=0
encrypt=1Тут все примерно так же, как в первом случае настройки. Идем дальше.
3. Создаем запускаемый при старте контейнера bash скрипт, разворачивающий переменные окружения, и другие компоненты контейнера, включая имена пользователей и групп необходимых для его функционирования:
Код:
# cat > /home/bitcore/lukspartition/start_docker.sh
Код:
#!/bin/bash
set -e
if [ -n "${UID+x}" ] && [ "${UID}" != "0" ]; then
usermod -u "$UID" bitcoin
fi
if [ -n "${GID+x}" ] && [ "${GID}" != "0" ]; then
groupmod -g "$GID" bitcoin
fi
echo "$0: assuming uid:gid for bitcoin:bitcoin of $(id -u bitcoin):$(id -g bitcoin)"
if [ $(echo "$1" | cut -c1) = "-" ]; then
echo "$0: assuming arguments for bitcoind"
set -- bitcoind "$@"
fi
if [ $(echo "$1" | cut -c1) = "-" ] || [ "$1" = "bitcoind" ]; then
mkdir -p "$BITCOIN_DATA"
chmod 700 "$BITCOIN_DATA"
chown -R bitcoin:bitcoin "$(getent passwd bitcoin | cut -d: -f6)"
chown -R bitcoin:bitcoin "$BITCOIN_DATA"
echo "$0: setting data directory to $BITCOIN_DATA"
set -- "$@" -datadir="$BITCOIN_DATA"
fi
if [ "$1" = "bitcoind" ] || [ "$1" = "bitcoin-cli" ] || [ "$1" = "bitcoin-tx" ]; then
echo
exec gosu bitcoin "$@"
fi
echo
exec "$@"4. Создаем сценарий Dockerfile для сборки образа контейнера кошелька:
Код:
# cat > /home/bitcore/lukspartition/Dockerfile
Код:
FROM debian:bullseye-slim
ARG UID=105
ARG GID=105
RUN groupadd --gid ${GID} bitcoin \
&& useradd --create-home --no-log-init -u ${UID} -g ${GID} bitcoin \
&& apt-get update -y \
&& apt-get install -y curl git gnupg gosu \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
ARG TARGETPLATFORM=x86_64-linux-gnu
ENV BITCOIN_VERSION=28.1
ENV BITCOIN_DATA=/home/bitcore/lukspartition/.bitcoin
ENV PATH=/opt/bitcoin-${BITCOIN_VERSION}/bin:$PATH
WORKDIR /home/bitcore/lukspartition
RUN gpg --keyserver hkps://keys.openpgp.org --refresh-keys \
&& git clone https://github.com/bitcoin-core/guix.sigs \
&& gpg --import guix.sigs/builder-keys/* \
&& rm -rf guix.sigs
RUN set -e && curl -SLO https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/bitcoin-${BITCOIN_VERSION}-${TARGETPLATFORM}.tar.gz \
&& curl -SLO https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/SHA256SUMS \
&& curl -SLO https://bitcoincore.org/bin/bitcoin-core-${BITCOIN_VERSION}/SHA256SUMS.asc \
&& gpg --verify SHA256SUMS.asc SHA256SUMS
RUN set -e && grep " bitcoin-${BITCOIN_VERSION}-${TARGETPLATFORM}.tar.gz" SHA256SUMS | sha256sum -c - \
&& tar -xzf *.tar.gz -C /opt \
&& rm *.tar.gz *.asc SHA256SUMS \
&& rm -rf /opt/bitcoin-${BITCOIN_VERSION}/bin/bitcoin-qt
COPY start_docker.sh ./start_docker.sh
VOLUME ["/home/bitcore/lukspartition"]
EXPOSE 8332 8334 8335 18332 18333 18443 18444 38333 38332
ENTRYPOINT ["/home/bitcore/lukspartition/start_docker.sh"]
RUN bitcoind -version | grep "Bitcoin Core version v${BITCOIN_VERSION}"
CMD ["bitcoind"]5. Создаем docker-compose.yaml как точки входа для сборки контейнеров в системе docker:
Код:
# cat > /home/bitcore/lukspartition/docker-compose.yaml
Код:
version: "2.38.2"
bitcoin_wallet:
build:
context: .
volumes:
- "/home/bitcore/lukspartition:/home/bitcore/lukspartition"
environment:
- UID=$UID
- GID=$GIDВсе что делает docker compose, это реализует сценарии более оптимизированных, массовых и главное автоматизированных многокомпонентых развертываний контейнеров на основе более сложных и комплексных схем, чем просто единичных развертываний с помощью сценариев Dockerfile.
6. В данном случае docker compose производит запуск сборки из Dockerfile.
Код:
# UID=$UID GID=$GID docker compose up bitcoin_walletЛибо мы можем не использовать docker compose, а например последовательно применить сначала "docker build" для сборки контейнера на основе Dockerfile, а затем "docker run -d" для его запуска в режиме сервера.
В качестве замечания, стоит упомянуть, что бывает так, что при использовании зашифрованных разделов luks, монтируемых в контейнеры docker возникают определенного рода сложности, такие как невозможность подключения зашифрованного тома внутрь контейнера, либо другие ошибки, например когда команды luksFormat и luksOpen не работают внутри окружения контейнера. Обычно это связано с тем, что luks/dm-crypm создает временные блочные устройства в контексте /dev/mapper, которые при этом не находится в разрешенных группах cgroups устройств контейнера, следовательно доступ к ним запрещён. Возможное опциональное решение - это открыть блочное устройство luks/dmcrypt на основном(центральном) хосте вручную с уникальным именем, а затем уже вручную экспортировать его в контейнер как отдельное блочное устройство. Контейнер не может активировать устройства /dev/mapper внутри контейнера, так как для этого обычно требуется root, так же внутри контейнера нет технической возможности настройки системы управления узлами устройств udev. В таком случае, возможным выходом из данной ситуации может стать оптимизация настроек ioctl для блочных устройств внутри контейнеров. Но этим потенциальные проблемы при интеграции криптоконтейнеров с контейнерами докер отнюдь не ограничиваются и это отдельная и достаточно широкая тема для экспериментов.
Ну и напоследок, приведу в пример команду терминала linux необходимую для подключения к ssh серверу, расположенному в ТОР сети(раз уж мы его там разместили):
Код:
ssh-keygen -b 4096 -t rsa -f ~/.ssh/sshkey.rsa
Код:
ssh-copy-id -o VerifyHostKeyDNS=no -o User=user -o CheckHostIP=no\
-o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" \
-i ~/.ssh/sshkey.rsa oniondomain
Код:
ssh -o VerifyHostKeyDNS=no -o User=user -o CheckHostIP=no\
-o IdentitiesOnly=yes \
-o ProxyCommand="nc -X 5 -x localhost:9050 %h %p" \
-i ~/.ssh/sshkey.rsa oniondomainВроде бы все чем хотелось поделиться, переходим к заключительному абзацу-)
Заключение
Рассмотрение вариантов конфигурации безопасного кошелька подошло к концу и пришло время подвести итоги. Мы с вами увидели казалось бы банальный случай настройки очередного скрытого сервиса в специальной сети ТОР. Ну подумаешь, вроде как ничего особенного, публиковалось в сети уже много всевозможного материала на эту тему, по инсталляции различных сервисов и служб в ТОР, и офисных, и коммуникационных, и web-проектов, и много чего другого. И при всем при этом, кому в голову придет специально скрывать в закрытой сети ТОР именно криптовалютный кошелек, если транзакции криптовалютной сети считаются условно анонимными, что кстати не совсем верно. Правда вот никогда не стоит забывать, что контур безопасности не ограничивается одним лишь аспектом, в данном случае защищенностью сети биткоин транзакций, а атаки обычно многоконтурны и многовекторны и направлены сразу на многие точки входа на различных уровнях работы систем и их взаимодействия. Могут быть атакованы операционные системы, компьютерные локальные и глобальные сети, прикладной уровень приложений, в частности отвечающих за хранение и обработку данных криптовалютной сети, в том числе ваших финансовых средств, функционирующий на уровнях взаимодействия операционных систем и сетей по ширине всего стека. А потому, с учетом всего вышесказанного, приходится принимать максимально широкие меры защиты в контексте всего периметра инфраструктуры и всех уровней системного и сетевого стеков. Что мы здесь и постарались обозначить на практике, на примере настройки защищенной конфигурации сетевого узла для криптовалютного кошелька bitcoin core, поместив его в сеть ТОР. Надеюсь что для кого-то информация в статье была или будет в будущем полезной и познавательной, и каждый, даже гораздо более опытный пользователь сможет извлечь из нее хоть что-то нужное как в практическом, так и в теоретическом смысле. И еще раз, - не забывайте о том, что как бы вы ни старались защитить свою систему или инфраструктуру, всегда останется или найдется необнаруженная вами брешь, которую наверняка рано или поздно смогут нащупать более продвинутые и упрямые специалисты, что следует обязательно учитывать в ваших развертываниях и настройках. Тут как говорится, нет предела совершенству, как в части защиты, так и нападения. Прогресс не стоит на месте-) Помните так же о том, что чем более наворочена конфигурация, тем более повышается степень вероятности ее уязвимости уже со стороны возможных известных, либо неизвестных брешей в ее компонентах. Минимализм или максимализм конфигураций - такая же сложная и важная дилемма в контексте безопасности, как само по себе состязание сторон защиты и нападения. Будем работать дальше!
