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

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

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

Искам да отбележа, че съм привърженик на принципите „keep it stupid simple“ и „less is more“, затова и статията, и описаното в нея ще притежават Eigenschaften, свързани с тези принципи.

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

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

Инсталация на сървъра

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

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

Ние използваме FS 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 pool.

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

Създаваме датасет на новия "пул"

zfs create vms/jails

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

След като 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 за клетки
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC

## Порт за пренасочване на биткойн мрежата
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 и белите списъци, това може да се направи, прочитайки официалната документация или която и да е от многото статии, налични в гугъл.

Е, имаме инсталиран cbsd, време е да създадем нашето първо работещо средство — биткойн демон в клетка!

cbsd jconstruct-tui

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

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

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

# cbsd jstart bitcoind

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

# jls

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

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

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

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

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

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

Биткойн в клетката е наличен, но ни трябва анонимност, тъй като искаме да се свързваме с някои клетки през мрежата ТОР. И всъщност в плановете ни е повечето клетки с подозрителен софтуер да работят само през прокси. Поради това 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 и уеб приложение, което по някакви причини е на apache и 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 firewall

Нека видим какви 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, така че същият портфейл планираме да използваме на
лаптопите ни. За момента ще използваме електрум с публични сървъри, а по-късно в още една клетка ще стартираме ElectrumX, за да зависим напълно от никого.

# cbsd jsconstruct-tui

# cbsd jstart electrum

# jexec electrum

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

още 700 МБ софтуер имаме в клетката

electrum:⁄@[8:53] # adduser

Потребителско име: wallet
Пълно име: 
Uid (оставете празно за по подразбиране): 
Login group [wallet]: 
Login group е wallet. Да поканим wallet в други групи? []: 
Login class [default]: 
Черупка (sh csh tcsh nologin) [sh]: tcsh
Домашна директория [⁄home⁄wallet]: 
Права на домашната директория (оставете празно за по подразбиране): 
Да се използва ли удостоверяване с парола? [да]: не
Да се блокира ли профила след създаване? [не]: 
Потребителско име: wallet
Парола: <disabled>
Пълно име: 
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

А с клиентската Linux машина

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 (<no hostip for proxy command>)' не може да бъде установена.
ECDSA ключовият отпечатък е SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Сигурни ли сте, че искате да продължите със свързването (да/не/[отпечатък])? да
Предупреждение: Постоянно добавен 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) към списъка на известни хостове.
FreeBSD 12.1-RELEASE-p1 GENERIC 
За да спестите дисково пространство в домашната си директория, компресирайте файловете, които рядко използвате с "gzip filename".
        -- Dru <genesis@istar.ca>
wallet@electrum:~ % logout

Успех!

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

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

# 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 адрес на нашата нода и искаме да извършваме всички финансови операции чрез ТОР. Затова ни е необходим още един .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: /home/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 Можете да създадете snapshots и да свържете нова клетка с този snapshot. Новата клетка ще има напълно собствено пространство, но в файловата система ще се отчита само разликата между текущото състояние и оригинала (ще спестим поне 190 GB).

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

Важно е също да се отбележи необходимостта от дистанционно наблюдение на хоста, за което имаме Zabbix.

Б — безопасност

Що се отнася до безопасността, нека да изходим от основните принципи в контекста на инфраструктурата:

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

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

Достъпност — Тук всичко е опционално. Зависимостта е от степента на вашата известност и наличието на врагове. В нашия пример осигурихме достъп до портфейла единствено от мрежата на TOR. При необходимост можем да блокираме всичко на защитната стена и да разрешим достъпа до сървъра единствено през тунели (TOR или 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