Биткойн в клетка?

Сложилось так, что по профессии я администратор на компютърни системи и мрежи (съкратено: системен администратор) и имам над 10 години професионален опит с различни системи, включително и с такива, които изискват [по|за]вишени мерки за безопасност. Освен това, преди известно време открих, че темата ме интересува. биткойн, и не просто го ползвах, а и стартирах няколко микро-сервиза, за да науча как да работя самостоятелно с мрежата на биткойн (както и да е, p2p е). Разбира се, не съм специалист по разработка, но не това ми е темата, а безопасната и ефективна среда за приложения. devФинансовите технологии (

fintech) вървят ръка за ръка с информационната безопасност (infosec), а първото без второто може да работи, но не за дълго. Именно затова искам да споделя своя опит и комплект инструменти, който използвам, и който включва както, в същото време, така и може да бъдат използвани за по-широки или съвсем различни цели. В тази статия ще разкажа не толкова за биткойн, колкото за модела на инфраструктура за изграждане и експлоатация на финансови (и не само) услуги — с една дума, за услугите, където „Б“ има значение. Това е приложимо както за биткойн борса, така и за типичен корпоративен зоопарк на услуги на малка компания, която няма никаква връзка с биткойн. ) вървят ръка за ръка с информационната безопасност (, така и ), а първото без второто може да работи, но не за дълго. Именно затова искам да споделя своя опит и комплект инструменти, който използвам, и който включва кактоИскам да отбележа, че съм привърженик на принципите

«keep it stupid simple» «less is more» и , затова както статията, така и описаното в нея ще притежават качества, свързани с тези принципи.Представете си сценарий:

Въображаем сценарий: Нека да разгледаме всичко на примера на биткойн обменник. Решихме да стартираме обмен на рубли, долари и евро за биткойни и обратно, и вече имаме работещо решение, но за други цифрови валути като Qiwi и WebMoney, т.е. закрили сме всички юридически въпроси, и разполагаме с готово приложение, което функционира като платежен шлюз за рубли, долари и евро, както и за други платежни системи. То е свързано с нашите банкови сметки и има API за нашите крайни приложения. Освен това имаме уеб приложение, функциониращо като обменник за потребители, подобно на типичния кабинет на Qiwi или WebMoney — създайте акаунт, добавете карта и така нататък. То комуникира с нашето шлюзово приложение, чрез REST API в локалната мрежа. И така, решихме да свържем биткойни и същевременно да актуализираме инфраструктурата, тъй като първоначално всичко бе инсталирано на VirtualBox на офис бюрото... сайтът започна да се използва, а ние започнахме да се притесняваме за uptime и производителност.

И така, да започнем с основното — избор на сървър. Тъй като бизнесът в нашия пример е малък и ние доверяваме на хостера (OVH), ще изберем бюджетен вариант в който не може да бъде инсталирана система от оригинален образ .iso, но не е беда, отделът по ИТ сигурност задължително ще проведе анализ на инсталирания образ. А когато пораснем, ще наемем собствен шкаф с ключ и ограничен физически достъп, а може би дори ще построим собствен дата център. Във всеки случай, важно е да се помни, че при наемане на хардур или инсталиране на готови образи, съществува риск във вашата система да има „троян от хостера“, който в повечето случаи не е предназначен за следене на вас, а за предлагане на по-удобни инструменти за управление на сървера.

Инсталиране на сървър

Тук всичко е просто. Избираме хардур, който отговаря на нашите нужди. След това избираме образ на FreeBSD. Или се свързваме (в случай на друг хостер и собствен хардур) чрез IPMI или с монитор и зареждаме .iso образа на FreeBSD. За оркестрационна инсталация използвам Ansible и mfsbsd. Единственото, в нашия случай с Kimsufi, избрахме персонализирана инсталация за да имат двата диска в огледало „отворени“ само за дяловете за зареждане и \/home, останалото пространство на диска ще бъде криптирано, но за това по-късно.

Инсталацията на системата става по стандартен начин, няма да спирам на това, само ще отбележа, че преди началото на експлоатацията е добре да обърнете внимание на засилване опциите, които предлага bsdinstaller в края на инсталацията (ако сами инсталирате системата):

Има добър материал по тази тема, накратко ще го повторя тук.

Включването на споменатите параметри е възможно и на вече инсталирана система. За целта трябва да редактирате конфигурационния файл на зареждача и да активирате параметрите на ядрото. *ee — това е редактор в BSD

# ee /etc/rc.conf

...
#sec hard
clear_tmp_enable="YES"
syslogd_flags="-ss"
sendmail_enable="NONE"

# ee /etc/sysctl.conf

...
#sec hard
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 9999)
security.bsd.stack_guard_page=1

Също така е важно да се уверите, че имате инсталирана последната версия на системата, и да изпълните всички актуализации и ъпгрейди. В нашия случай, например, е необходим ъпгрейд до последната версия, тъй като предварителните образи изостават с половин до една година. И там променяме SSH порта на различен от подразбиращия се, добавяме автентикация с ключове и деактивираме паролата.

След това настройваме aide, мониторинга на състоянието на конфигурационните файлове на системата. По-подробно можете да прочетете тук.

pkg install aide

и редактираме нашия кронтаб

crontab -e

06 01 * * 0-6 /root/chkaide.sh

#! /bin/sh
#chkaide.sh
MYDATE=`date +%Y-%m-%d`
MYFILENAME="Aide-"$MYDATE.txt
/bin/echo "Aide check !! `date`" > /tmp/$MYFILENAME
/usr/local/bin/aide --check > /tmp/myAide.txt
/bin/cat /tmp/myAide.txt|/usr/bin/grep -v failed >> /tmp/$MYFILENAME
/bin/echo "**************************************" >> /tmp/$MYFILENAME
/usr/bin/tail -20 /tmp/myAide.txt >> /tmp/$MYFILENAME
/bin/echo "****************DONE******************" >> /tmp/$MYFILENAME

Включваме системно одитиране

sysrc auditd_enable=YES

# service auditd start

Как да администрираме това е отлично описано в ръководство.

Сега перезареждаме и преминаваме към софтуера на сървера. Всеки сървър представлява хипервизор за контейнери или пълни виртуални машини. Затова е важно, че процесорът поддържа VT-x и EPT, ако планираме да използваме пълна виртуализация.

Като мениджмънт на контейнери и виртуални машини използвам cbsd от olevole, желая му много здраве и благоденствие за тази прекрасна утилита!

Контейнери? Пак ли docker?

А ето и не. FreeBSD Jails — това е отличен инструмент за контейнеризация, а споменатият cbsd за оркестрация на тези контейнери, който се нарича — клетки.

Клетката е изключително ефективно решение за изграждане на инфраструктура за различни цели, при което се изисква пълна изолация на отделните услуги или процеси. По същество това е клонинг на хост-системата, но не изисква пълна виртуализация на хардуера. Така ресурсите не се харчат за "гостоприемна ОС", а само за извършваната работа. Когато клетките се използват за вътрешни нужди, това е много удобен начин за оптимално използване на ресурса — множество клетки на един физически сервер могат всяка поотделно да използват целия ресурс на сървъра при необходимост. Като се има предвид, че различните подсервизи обикновено имат нужда от допълнителни ресурси в различно време, е възможно да се извлече максимална производителност от един сървър, ако клетките бъдат правилно планирани и разпределени между сървърите. При нужда на клетките могат да се наложат ограничения за използваните ресурси.

А какво ще кажеш за пълната виртуализация?

Насколько мне известно, cbsd поддържа работа bhyve и XEN хипервизори. Вторият не съм ползвал, но първият е сравнително млад хипервизор от FreeBSD.. В следващия пример ще разгледаме bhyve в примера по-долу.

Инсталиране и настройка на хост околна среда.

Използваме файловата система ZFS.Това е изключително мощен инструмент за управление на пространството на сървера. С ZFS можете директно от дисковете да строите масиви с най-различни конфигурации, динамично да разширявате пространството "на горещо", да сменяте повредени дискове, да управлявате моментни снимки и много, много повече, което би могло да бъде описано в цяла серия статии. Върнем се към нашия сървър и неговите дискове. В началото на инсталацията оставихме свободно пространство на дисковете за криптирани раздели. Защо така? Това е, за да може системата да се стартира автоматично и да слуша по SSH.

gpart add -t freebsd-zfs /dev/ada0

/dev/ada0p4 added!

добавяме раздел на диска в оставащото пространство.

geli init /dev/ada0p4

въвеждаме паролата за криптиране.

geli attach /dev/ada0p4

отново въвеждаме паролата и получаваме устройството /dev/ada0p4.eli — това е нашето криптирано пространство. След това повтаряме същото за /dev/ada1 и останалите дискове в масива. И създаваме нов ZFS пул..

zpool create vms mirror /dev/ada0p4.eli /dev/ada1p4.eli /dev/ada3p4.eli — ето, имаме минимален боен комплект. Зеркален масив от дискове в случай на повреда на един от трите.

Създаваме dataset на новия "pool"

zfs create vms/jails

pkg install cbsd — стартирахме командата и инсталираме мениджъра за нашите jail-и.

След като cbsd е инсталиран, той трябва да бъде инициализиран:

# env workdir="/vms/jails" /usr/local/cbsd/sudoexec/initenv

и отговаряме на много въпроси, основно с отговори по подразбиране.

*Ако използвате криптиране, е важно демонът cbsdd да не стартира автоматично, докато не декриптирате дисковете ръчно или автоматично (в нашия пример това прави zabbix)

**Също така не използвам NAT от cbsd, а го настройвам сам в pf.

# sysrc pf_enable=YES

# ee /etc/pf.conf

IF_PUBLIC="em0"
IP_PUBLIC="1.23.34.56"
JAIL_IP_POOL="192.168.0.0/24"

#WHITE_CL="{ 127.0.0.1 }"

icmp_types="echoreq"

set limit { states 20000, frags 20000, src-nodes 20000 }
set skip on lo0
scrub in all

#NAT за jail-ове
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

## Порт за Bitcoin мрежа напред
IP_JAIL="192.168.0.1"
PORT_JAIL="{8333}"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

# service pf start

# pfctl -f /etc/pf.conf

Настройката на политиките на фаервола е също отделна тема, затова няма да се задълбочавам в настройките на BLOCK ALL и белите списъци, може да се направи, като прочетете официалната документация или някоя от многото статии, налични в Google.

Какво пък... инсталирахме cbsd, време е да създадем нашия първи работен кон — демон на Bitcoin в jail!

cbsd jconstruct-tui

Тук виждаме диалога за създаване на jail. След като зададем всички стойности, създаваме!

При създаването на първия jail, трябва да изберем какво да използваме като основа за jail-овете. Избирам дистрибуция от репозитория FreeBSD с командата repo. Този избор се прави само при създаването на първия jail за конкретната версия (може да хоствате jail-ове на всякакви версии, по-стари от версията на хоста).

След като всичко е инсталирано — стартираме jail-а!

# cbsd jstart bitcoind

Но трябва да инсталираме софтуера в jail.

# jls

   JID  IP Address      Hostname                      Path
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind

jexec bitcoind за да влезете в конзолата на jail

и вътре в jail инсталираме софтуера с неговите зависимости (нашата хост система остава чиста)

bitcoind:/@[15:25] # pkg install bitcoin-daemon bitcoin-utils

bitcoind:/@[15:30] # sysrc bitcoind_enable=YES

bitcoind:/@[15:30] # service bitcoind start

Bitcoin в jail е наличен, но ни трябва анонимност, защото искаме да се свързваме с някои jail-ове през TOR мрежата. И изобщо, в плановете ни е повечето jail-ове с подозрителен софтуер да работят само през прокси. Благодарение на pf можем изключим NAT за определен диапазон IP адреси в локалната мрежа и разрешим NAT само за нашия TOR-узел. По този начин, дори ако зловреден софтуер попадне в клетката, той вероятно няма да може да се свърже с външния свят, а ако успее, няма да разкрие IP адреса на нашия сървър. Затова създаваме още една клетка за „проброс“ на услуги като „.onion“-сервиз и като прокси за излизане в интернет на отделни клетки.

# cbsd jsconstruct-tui

# cbsd jstart tor

# jexec tor

tor: /@[15:38] # pkg install tor

tor: /@[15:38] # sysrc tor_enable=YES

tor: /@[15:38] # ee /usr/local/etc/tor/torrc

Настройваме да слуша на локалния адрес (достъпен за всички клетки)

SOCKSPort 192.168.0.2:9050

Какво още ни липсва за пълно щастие? Да, необходим ни е сервис за нашия уеб, може би не само един. Ще стартираме nginx, който ще изпълни ролята на reverse-proxy и ще се погрижи за подновяването на сертификатите на Let’s Encrypt.

# cbsd jsconstruct-tui

# cbsd jstart nginx-rev

# jexec nginx-rev

nginx-rev: /@[15:47] # pkg install nginx py36-certbot

И ето, 150 МБ зависимости сме сложили в клетката. А хостът все още е чист.

Ще се върнем на настройката на nginx по-късно, трябва да поднимем още две клетки за нашия платежен шлюз на nodejs и rust и уеб приложение, което по някаква причина е на апач и php, а за последното е нужна БД MySQL.

# cbsd jsconstruct-tui

# cbsd jstart paygw

# jexec paygw

paygw: /@[15:55] # pkg install git node npm

paygw: /@[15:55] # curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

… и още 380 МБ пакети изолирано

След това изтегляме приложението ни с git и го стартираме.

# cbsd jsconstruct-tui

# cbsd jstart webapp

# jexec webapp

webapp: /@[16:02] # pkg install mariadb104-server apache24 php74 mod_php74 php74-pdo_mysql

450 МБ пакети. в клетката.

Тук даваме достъп на разработчик по SSH директно в клетката, те сами ще се справят:

webapp: /@[16:02] # ee /etc/ssh/sshd_config

Port 2267 — променяме порта на SSH клетката на произволен

webapp: /@[16:02] # sysrc sshd_enable=YES

webapp: /@[16:02] # service sshd start

Ето, сервисът е стартиран, остава да добавим правило в pf файервола

Нека видим какви IP адреси имаме на клетките и как изглежда нашата „локалка“

# jls

   JID  IP Address      Hostname                      Path
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind
     2  192.168.0.2     tor.space.com                 /zroot/jails/jails/tor
     3  192.168.0.3     nginx-rev.space.com           /zroot/jails/jails/nginx-rev
     4  192.168.0.4     paygw.space.com               /zroot/jails/jails/paygw
     5  192.168.0.5     webapp.my.domain              /zroot/jails/jails/webapp

и добавяме правило

# ee /etc/pf.conf

## SSH for web-Devs
IP_JAIL="192.168.0.5"
PORT_JAIL="{ 2267 }"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

въпреки че, понеже сме тук, добавяме и правило за reverse-proxy:

## web-ports for nginx-rev
IP_JAIL="192.168.0.3"
PORT_JAIL="{ 80, 443 }"
rdr pass on $IF_PUBLIC proto tcp from any to $IP_PUBLIC port $PORT_JAIL -> $IP_JAIL

# pfctl -f /etc/pf.conf

А сега малко за биткойните

Какво имаме — у нас е уеб приложение, което е достъпно отвън и локално комуникира с нашия платежен шлюз. Сега трябва да подготвим работната среда за взаимодействие с самата биткойн мрежа — нода bitcoind това е просто демон, който поддържа локално копие на актуалната блокчейн. Този демон разполага с RPC и функционалност на портфейл, но за разработка на приложения съществуват по-удобни „обвивки“. В началото решихме да инсталираме electrum — това е CLI портфейл. Този портфейл ще използваме като „студен склад“ за нашите биткойни — общо взето, тези биткойни, които трябва да съхраняваме „извън“ системата, достъпна за потребителите и наистина далеч от всички. Той също така разполага с GUI, затова същия портфейл ще използваме на нашите
лаптопи. Засега ще използваме Electrum с публични сървъри, а по-късно ще разположим ElectrumX, за да не зависим напълно от никого.

# cbsd jsconstruct-tui

# cbsd jstart electrum

# jexec electrum

electrum: /@[8:45] # pkg install py36-electrum

още 700 MB софтуер в клетката ни

electrum: /@[8:53] # adduser

Потребителско име: wallet
Пълно име: 
Uid (оставете празно за подразбиране): 
Група за вход [wallet]: 
Група за вход е wallet. Да поканим wallet в други групи? []: 
Клас за вход [по подразбиране]: 
Обвивка (sh csh tcsh nologin) [sh]: tcsh
Домашен каталог [ /home/wallet]: 
Права на домашния каталог (оставете празно за подразбиране): 
Да се използва аутентикация с парола? [да]: не
Да заключим ли акаунта след създаването? [не]: 
Потребителско име   : wallet
Парола   : 
Пълно име  : 
Uid        : 1001
Клас      : 
Групи     : wallet 
Домашен каталог       : /home/wallet
Режим на домашен каталог  : 
Обвивка      : /bin/tcsh
Заключен     : не
Добре? (да/не): да
adduser: ИНФО: Успешно добавихме (wallet) в базата данни на потребителите.
Да добавим ли друг потребител? (да/не): не
До скоро!
electrum: /@[8:53] # su wallet

electrum: /@[8:53] # su wallet

wallet@electrum:/ % electrum-3.6 create

{
    "msg": "Моля, запазете семето си на сигурно място; ако го загубите, няма да можете да възстановите портфейла си.",
    "path": "/usr/home/wallet/.electrum/wallets/default_wallet",
    "seed": "jealous win pig material ribbon young punch visual okay cactus random bird"
}

Сега имаме създаден портфейл.

wallet@electrum:/ % electrum-3.6 listaddresses

[
    "18WEhbjvMLGRMfwudzUrUd25U5C7uZYkzE",
    "14XHSejhxsZNDRtk4eFbqAX3L8rftzwQQU",
    "1KQXaN8RXiCN1ne9iYngUWAr6KJ6d4pPas",
    ...
    "1KeVcAwEYhk29qEyAfPwcBgF5mMMoy4qjw",
    "18VaUuSeBr6T2GwpSHYF3XyNgLyLCt1SWk"
]

wallet@electrum:/ % electrum-3.6 help

К нашия on-chain портфейл в бъдеще ще може да се свързва само ограничен кръг лица. За да не отваряме достъп извън клетката, връзките по SSH ще се извършват чрез ТОР (такъв децентрализиран вариант на VPN). Стартираме в клетката SSH, но не засягаме нашия pf.conf на хоста.

electrum: /@[9:00] # sysrc sshd_enable=YES

electrum: /@[9:00] # service sshd start

Сега ще изключим клетката с портфейла от интернет. Ще му зададем IP адрес от друго подмрежово пространство, което не е NAT-вано. Първо ще променим /etc/pf.conf на хоста

# ee /etc/pf.conf

JAIL_IP_POOL="192.168.0.0/24" да сменим на JAIL_IP_POOL="192.168.0.0/25", по този начин всички адреси 192.168.0.126-255 няма да имат пряк достъп до интернет. Някаква софтуерна „air-gap“ мрежа. И NAT правилото остава такова, каквото беше

nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

Презареждаме правилата

# pfctl -f /etc/pf.conf

Сега преминаваме към нашата клетка

# cbsd jconfig jname=electrum

jset mode=quiet jname=electrum ip4_addr="192.168.0.200"
Премахване на стария IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Настройка на новия IP: /sbin/ifconfig em0 inet 192.168.0.200 alias
ip4_addr: 192.168.0.200

Хм, но сега самата система ще спре да работи. Въпреки това можем да зададем системен прокси. Но има едно но, за TOR това е SOCKS5 прокси, а за удобство бихме искали и HTTP прокси.

# cbsd jsconstruct-tui

# cbsd jstart polipo

# jexec polipo

polipo:/@[9:28] # pkg install polipo

polipo:/@[9:28] # ee /usr/local/etc/polipo/config

socksParentProxy = "192.168.0.2:9050"
socksProxyType = socks5

polipo:/@[9:42] # sysrc polipo_enable=YES

polipo:/@[9:43] # service polipo start

Ну вот, теперь в нашей системе есть два прокси-сервера, и оба выводят через TOR: socks5://192.168.0.2:9050 и http://192.168.0.6:8123

Сега можем да настроим околната среда на нашия портфейл

# jexec electrum

electrum:/@[9:45] # su wallet

wallet@electrum:/ % ee ~/cshrc

#in the end of file proxy config
setenv http_proxy http://192.168.0.6:8123
setenv https_proxy http://192.168.0.6:8123

Ето, сега шелът ще работи през прокси. Ако искаме да инсталираме пакети, трябва да добавим в /usr/local/etc/pkg.conf от под рут на клетката

pkg_env: {
               http_proxy: "http://my_proxy_ip:8123",
           }

А сега дойде времето да добавим TOR hidden service като адрес на нашия SSH сервис в клетката на портфейла.

# jexec tor

tor:/@[9:59] # ee /usr/local/etc/tor/torrc

HiddenServiceDir /var/db/tor/electrum/
HiddenServicePort 22 192.168.0.200:22

tor:/@[10:01] # mkdir /var/db/tor/electrum

tor:/@[10:01] # chown -R _tor:_tor /var/db/tor/electrum

tor:/@[10:01] # chmod 700 /var/db/tor/electrum

tor:/@[10:03] # service tor restart

tor:/@[10:04] # cat /var/db/tor/electrum/hostname

mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion

Ето го нашият адрес за свързване. Нека проверим от локалната машина. Но първо трябва да добавим нашия SSH ключ:

wallet@electrum:/ % mkdir ~/.ssh

wallet@electrum:/ % ee ~/.ssh/authorized_keys

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAG9Fk2Lqi4GQ8EXZrsH3EgSrVIQPQaAlS38MmJLBabihv9KHIDGXH7r018hxqLNNGbaJWO/wrWk7sG4T0yLHAbdQAFsMYof9kjoyuG56z0XZ8qaD/X/AjrhLMsIoBbUNj0AzxjKNlPJL4NbHsFwbmxGulKS0PdAD5oLcTQi/VnNdU7iFw== user@local

А с клиентската линукс-машина

user@local ~$ nano ~/.ssh/config

#remote electrum wallet
Host remotebtc
        User wallet
        Port 22
        Hostname mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion
        ProxyCommand /bin/ncat --proxy localhost:9050 --proxy-type socks5 %h %p

Свързваме се (За да работи това, е нужен локален демон на TOR, който слуша на 9050)

user@local ~$ ssh remotebtc

Автентичността на хост 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion ()' не може да бъде установена.
ECDSA ключовият отпечатък е SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Сигурни ли сте, че искате да продължите свързването (да/не/[отпечатък])? да
Внимание: Постоянно добавено 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) в списъка на познатите хостове.
FreeBSD 12.1-RELEASE-p1 GENERIC 
За да спестите дисково пространство в домашната си директория, компресирайте файлове, които рядко използвате с "gzip filename".
        -- Dru 
wallet@electrum:~ % logout

Успех!

За работа с моментални и микро-плащания ни е необходима и нода Lightning Network, всъщност това ще бъде нашият основен инструмент за работа с биткойн. У *c-lightning, който ще използваме като демон, има плъгин Sparko, който е пълен HTTP (REST) интерфейс и позволява работа както с off-chain транзакции, така и с on-chain транзакции. c-lightning за функциониране е необходима bitcoind нода.

*има различни реализации на различни ЯП на протокола Lightning Network. От тези, които тестваме, c-lightning (написан на С) се оказа най-стабилен и ефективен по отношение на ресурсите

# cbsd jsconstruct-tui

# cbsd jstart cln

# jexec cln

lightning:‍/@[10:23] # adduser

Потребителско име: lightning
...

lightning:‍/@[10:24] # pkg install git

lightning:‍/@[10:23] # su lightning

cd ~ && git clone https://github.com/ElementsProject/lightning

lightning@lightning:~ % exit

lightning:‍/@[10:30] # cd /home/lightning/lightning/

lightning:/home/lightning/lightning@[10:31] # pkg install autoconf automake gettext git gmp gmake libtool python python3 sqlite3 libsodium py36-mako bash bitcoin-utils

lightning:/home/lightning/lightning@[10:34] # ./configure && gmake && gmake install

Докато се компилират и инсталират всички необходими компоненти, ще създадем RPC потребител за lightningd в bitcoind

# jexec bitcoind

bitcoind:‍/@[10:36] # ee /usr/local/etc/bitcoin.conf

rpcbind=192.168.0.1
rpcuser=test
rpcpassword=test
# разрешаване само на c-lightning
rpcallowip=192.168.0.7/32

bitcoind:‍/@[10:39] # service bitcoind restart

Моето хаотично превключване между клетките се оказва не толкова хаотично, ако отбележим утилитата tmux, която позволява в рамките на една сесия да се създадат множество под-сесии на терминали. Аналог: screen

Добре, не искаме да разкриваме нашия истински IP адрес и искаме да извършваме всички финансови операции през TOR. Следователно ни е необходима още една .onion.

# jexec tor

tor:/@[9:59] # ee /usr/local/etc/tor/torrc

HiddenServiceDir /var/db/tor/cln/
HiddenServicePort 9735 192.168.0.7:9735

tor:‍/@[10:01] # mkdir /var/db/tor/cln

tor:‍/@[10:01] # chown -R _tor:_tor /var/db/tor/cln

tor:‍/@[10:01] # chmod 700 /var/db/tor/cln

tor:/@[10:03] # service tor restart

tor:‍/@[10:04] # cat /var/db/tor/cln/hostname

en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onion

сега ще създадем конфигурация за c-lightning

lightning:‍/@[10:31] # su lightning

lightning@lightning:~ % mkdir .lightning

lightning@lightning:~ % ee .lightning/config

alias=My-LN-Node
bind-addr=192.168.0.7:9735
rgb=ff0000
announce-addr=en5wbkavnytti334jc5uzaudkansypfs6aguv6kech4hbzpcz2ove3yd.onion:9735
network=bitcoin
log-level=info
fee-base=0
fee-per-satoshi=1
proxy=192.168.0.2:9050
log-file=/home/lightning/.lightning/c-lightning.log
min-capacity-sat=200000

# sparko плъгин
# https://github.com/fiatjaf/lightningd-gjson-rpc/tree/master/cmd/sparko

sparko-host=192.168.0.7
sparko-port=9737

sparko-tls-path=sparko-tls

#sparko-login=mywalletusername:mywalletpassword

#sparko-keys=masterkey;secretread:+listchannels,+listnodes;secretwrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
sparko-keys=masterkey;secretread:+listchannels,+listnodes;ultrawrite:+invoice,+listinvoices,+delinvoice,+decodepay,+waitpay,+waitinvoice
# за примера по-горе инициализационните журнали (смешано с журнали на lightningd) трябва да печатат нещо подобно

lightning@lightning:~ % mkdir .lightning/plugins

lightning@lightning:~ % cd .lightning/plugins/

lightning@lightning:~/.lightning/plugins:% fetch https://github.com/fiatjaf/sparko/releases/download/v0.2.1/sparko_full_freebsd_amd64

lightning@lightning:~/.lightning/plugins % mkdir ~/.lightning/sparko-tls

lightning@lightning:~/.lightning/sparko-tls % cd ~/.lightning/sparko-tls

lightning@lightning:~/.lightning/sparko-tls % openssl genrsa -out key.pem 2048

lightning@lightning:~/.lightning/sparko-tls % openssl req -new -x509 -sha256 -key key.pem -out cert.pem -days 3650

lightning@lightning:~/.lightning/plugins % chmod +x sparko_full_freebsd_amd64

lightning@lightning:~/.lightning/plugins % mv sparko_full_freebsd_amd64 sparko

lightning@lightning:~/.lightning/plugins % cd ~

трябва също да създадете конфигурационен файл за bitcoin-cli, инструмента, който комуникира с bitcoind

lightning@lightning:~ % mkdir .bitcoin

lightning@lightning:~ % ee .bitcoin/bitcoin.conf

rpcconnect=192.168.0.1
rpcuser=test
rpcpassword=test

проверяваме

lightning@lightning:~ % bitcoin-cli echo "test"

[
  "test"
]

стартираме lightningd

lightning@lightning:~ % lightningd --daemon

Самият lightningd може да управлява инструмента lightning-cli, например:

lightning-cli newaddr да получите адрес за ново входящо плащане

{
   "address": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv",
   "bech32": "bc1q2n2ffq3lplhme8jufcxahfrnfhruwjgx3c78pv"
}

lightning-cli withdraw bc1jufcxahfrnfhruwjgx3cq2n2ffq3lplhme878pv all да изпратите всички средства от портфейла (всички адреси он-чейн)

Също така командите за off-chain операции lightning-cli invoice, lightning-cli listinvoices, lightning-cli pay и т.н.

А за комуникация с приложението разполагаме с REST Api

curl -k https://192.168.0.7:9737/rpc -d '{"method": "pay", "params": ["lnbc..."]}' -H 'X-Access masterkey'

Нека обобщим

# jls

   JID  IP Address      Hostname                      Path
     1  192.168.0.1     bitcoind.space.com            /zroot/jails/jails/bitcoind
     2  192.168.0.2     tor.space.com                 /zroot/jails/jails/tor
     3  192.168.0.3     nginx-rev.space.com           /zroot/jails/jails/nginx-rev
     4  192.168.0.4     paygw.space.com               /zroot/jails/jails/paygw
     5  192.168.0.5     webapp.my.domain              /zroot/jails/jails/webapp
     7  192.168.0.200   electrum.space.com            /zroot/jails/jails/electrum
     8  192.168.0.6     polipo.space.com              /zroot/jails/jails/polipo
     9  192.168.0.7     lightning.space.com           /zroot/jails/jails/cln

Имаме набор от контейнери, всеки със собствено ниво на достъп както за локалната мрежа, така и отвън.

# zfs list

NAME                    USED  AVAIL  REFER  MOUNTPOINT
zroot                   279G  1.48T    88K  /zroot
zroot/ROOT             1.89G  1.48T    88K  none
zroot/ROOT/default     1.89G  17.6G  1.89G  /
zroot/home               88K  1.48T    88K  /home
zroot/jails             277G  1.48T   404M  /zroot/jails
zroot/jails/bitcoind    190G  1.48T   190G  /zroot/jails/jails-data/bitcoind-data
zroot/jails/cln         653M  1.48T   653M  /zroot/jails/jails-data/cln-data
zroot/jails/electrum    703M  1.48T   703M  /zroot/jails/jails-data/electrum-data
zroot/jails/nginx-rev   190M  1.48T   190M  /zroot/jails/jails-data/nginx-rev-data
zroot/jails/paygw      82.4G  1.48T  82.4G  /zroot/jails/jails-data/paygw-data
zroot/jails/polipo     57.6M  1.48T  57.6M  /zroot/jails/jails-data/polipo-data
zroot/jails/tor        81.5M  1.48T  81.5M  /zroot/jails/jails-data/tor-data
zroot/jails/webapp      360M  1.48T   360M  /zroot/jails/jails-data/webapp-data

Както виждате, bitcoind заема целия капацитет от 190 ГБ. А какво, ако ни е необходима още една нода за тестове? Тук ZFS е много удобен. Като използваме cbsd jclone old=bitcoind new=bitcoind-clone host_hostname=clonedbtc.space.com можете да създадете моментна снимка и да свържете нова клетка към този моментен снимка. Новата клетка ще има напълно собствено пространство, но в същото време в файловата система ще се отчита само разликата между текущото състояние и оригинала (ще спестим поне 190 ГБ)

Всяка клетка е свой отделен набор от данни ZFS, и това е изключително удобно. ZFS също така позволява да правите различни други интересни неща, като изпращане на моментни снимки по SSH. Няма да го описваме, вече е много.

Важно е да споменем необходимостта от отдалечен мониторинг на хоста, за целта имаме Zabbix.

Б — сигурност

Що се отнася до сигурността, да предположим основните принципи в контекста на инфраструктурата:

Конфиденциалност — Стандартните инструменти на UNIX-подобните системи осигуряват изпълнението на този принцип. Логически разделяме достъпа до всеки логически отделен елемент на системата — клетка. Достъпът се осъществява чрез стандартна потребителска удостоверяване по лични ключове на потребителите. Цялата комуникация между клетките и до крайните клетки протича в криптиран вид. Чрез криптиране на дисковете можем да не се притесняваме за запазването на данните при замяна на диск или миграция на друг сървър. Единственият критичен достъп е достъпът до хост-системата, тъй като такъв достъп в общия случай осигурява достъп до данните вътре в контейнерите.

Целостност — Изпълнението на този принцип се осъществява на няколко различни нива. Първо е важно да се отбележи, че в случай на сървърно оборудване, ECC памет, ZFS вече "извън кутия" се грижи за целостта на данните на ниво битове информация. Моментните снимки позволяват резервно копиране по всяко време в реално време. Удобните инструменти за ексползация-импорта на клетки правят лесно репликирането на клетки.

Достъпност — Тук вече е по избор. Зависи от вашата известност и факта, че имате противници. В нашия пример сме осигурили достъпността на портфейла изключително от мрежата ТОР. При необходимост можете на фаервола да блокирате всичко и да разрешите достъп до сървъра единствено чрез тунели (ТОР или VPN, това е друг въпрос). Така сървърът ще бъде откъснат от външния свят, колкото е възможно, и можем да повлияем на неговата наличност само ние сами.

Невъзможност за отказ — Това зависи от бъдещото използване и спазването на правилните политики за потребителските права, достъпа и т.н. Но при правилен подход всичките действия на потребителите се одитират, а благодарение на криптографските решения е възможно еднозначно идентифициране на това кой и кога е извършил определени действия.

Разбира се, описаната конфигурация не е абсолютен пример как винаги трябва да бъде, а по-скоро един от примерите как може да бъде, запазвайки много гъвкави възможности за мащабиране и персонализиране.

А какво става с пълната виртуализация?

За пълната виртуализация с cbsd може да се прочете тук. Ще добавя само, че за работа bhyve необходимо е да включите някои параметри на ядрото.

# cat /etc/rc.conf

...
kld_list="vmm if_tap if_bridge nmdm"
...

# cat /boot/loader.conf

...
vmm_load="YES"
...

Така че, ако изведнъж трябва да стартирате Docker, просто инсталирайте някакъв Debian и напред!

Ето и всичко.

Може би това е всичко, което исках да споделя. Ако ви е харесала статията, можете да ми изпратите малко биткойни — bc1qu7lhf45xw83ddll5mnzte6ahju8ktkeu6qhttc. Ако искате да опитате клетките в действие и имате малко биткойни, можете да посетите моя pet-project.

Източник: habr.com