Так склалася, што я па прафесіі адміністратар кампутарных сістэм і сетак (карацей: сісадмін), і давялося распавесці за крыху больш за 10 гадоў праф. дзейнасці самых розных сістэм, уключаючы тых, што патрабуюць [за|за]вышаных мер бяспекі. А яшчэ склалася, што некаторы час таму я знайшоў для сябе цікавым , і не проста ім пакарыстаўся, але і запусціў некалькі мікра-сэрвісаў, для таго каб навучыцца самастойна працаваць з сеткай біткойна (ён жа p2p як ніяк) з пункта гледжання распрацоўчкіка (я вядома такі сабе dev, так, міма праходзіў). Але я не пра распрацоўку, я пра бяспечнае і эфектыўнае асяроддзе для прыкладанняў.
Фінансавыя тэхналогіі (FinTech) ідуць побач з інфармацыйнай бяспекай (інфасек) і першае без другога працаваць можа, але нядоўга. Вось таму я хачу падзяліцца сваім вопытам і наборам інструментаў што я выкарыстоўваю, які ўключае ў сябе як FinTech, так і інфасек, прычым адначасова, а гэтак жа можа быць скарыстаны і ў шырэйшым ці зусім іншым прызначэнні. У гэтым артыкуле распавяду не гэтулькі пра біткойн, колькі пра мадэль інфраструктуры для распрацоўкі і эксплуатацыі фінансавых (і не толькі) сэрвісаў - адным словам тых сэрвісаў, дзе "Бы" мае значэнне. У адносінах гэта як да біткойновай біржы, так і да самага тыпавога карпаратыўнага заапарка сэрвісаў невялікай кампаніі з біткойнам ніяк не звязанай.
Жадаю адзначыць, што я прыхільнік прынцыпаў "keep it stupid simple" и "less is more", таму як артыкул, так і апісанае ў ім будзе валодаць ўласцівасцямі аб якіх гэтыя прынцыпы.
Уяўны сцэнар: Давайце разбяром усё на прыкладзе біткой новага абменніка. Мы вырашылі запусціць абмен рублёў, даляраў, еўра на біткойны і назад, і ў нас ужо ёсць працуючае рашэнне, але для іншых лічбавых грошай накшталт ківі і webmoney, г.зн. у нас зачыненыя ўсе юрыдычныя пытанні, маецца гатовае прыкладанне якое выконвае ролю плацежнага шлюза для рублёў, даляраў і еўра і іншых плацежных сістэм. Завязана з нашымі банкаўскімі рахункамі і мае нейкае API для нашых канчатковых дадаткаў. Гэтак жа ў нас ёсць вэб-дадатак, якое выконвае ролю абменніка для карыстальнікаў, ну накшталт тыповага ківі ці webmoney кабінета - завядзіце рахунак, дадайце карту і гэтак далей. Яно мае зносіны з нашым дадаткам-шлюзам, хай па REST API у лакалцы. І вось мы вырашылі падлучыць біткойны і заадно праапгрэйдзіць інфраструктуру, т.к. першапачаткова ўсё было ў спешцы паднята на віртуалбоксах у офісе пад сталом ... сайтам сталі карыстацца, а мы сталі перажываць за аптайм і прадукцыйнасць.
Такім чынам, пачнем з асноўнага – выбар сервера. Т.к. бізнес у нашым прыкладзе маленькі і мы давяраем хосцера (OVH) мы выберам у якім нельга ўсталяваць сістэму з арыгінальнай выявы .iso, але не бяда, аддзел ІТ-бяспекі абавязкова правядзе аналіз усталяванай выявы. А калі вырасцем, дык увогуле арандуем сваю шафу пад замком і абмежаваным фізічным доступам, а можа і сваю ДЦ пабудуем. У любым выпадку, варта памятаць, што пры арэндзе жалеза і ўсталёўцы гатовых выяў ёсць шанец што ў вас у сістэме будзе вісець "траян ад хосцера", які ў большасці выпадкаў прызначаны не для сачэння за вамі а для таго што б прапанаваць зручнейшыя прылады кіравання серверам.
Ўстаноўка сервера
Тут усё проста. Выбіраемы жалеза якое падыходзіць нашым патрэбам. Затым выбіраемы выява FreeBSD. Ну ці падлучаемся (у выпадку іншага хосцера і свайго жалеза) па IPMI або з маніторам і скормліваем у загрузку .iso FreeBSD выявы. Для аркестральнай устаноўкі я выкарыстоўваю и . Адзінае, у нашым выпадку з 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 калі мы плануем выкарыстоўваць поўную віртуалізацыю.
У якасці менеджменту кантэйнераў і віртуальных машын я выкарыстоўваю ад , жадаю пабольш яму здароўя і выгод за гэтую выдатную ўтыліту!
Кантэйнеры? Зноў docker ці што?
А вось і не. - Гэта выдатная прылада для кантэйнерызацыі, ну а згаданы cbsd для аркестрацыі гэтых кантэйнераў, якім імя - клеткі.
Клетка гэта вельмі эфектыўнае рашэнне для пабудовы інфраструктуры для самых розных мэт, дзе ў выніку патрабуецца поўная ізаляцыя асобных сэрвісаў ці працэсаў. Па сутнасці гэта клон хост-сістэмы, але яму не патрабуецца поўная віртуалізацыя "жалеза". І рэсурсы дзякуючы гэтаму не марнуюцца на «гасцявую АС», а толькі на выкананую працу. Калі клеткі выкарыстоўваюцца для ўнутраных патрэб, гэта вельмі зручнае рашэнне для аптымальнага выкарыстання рэсурсу - куча клетак на адным жалезным серверы могуць кожная па асобнасці выкарыстоўваць увесь рэсурс сервера пры неабходнасці. Улічваючы што звычайна розным падсэрвісам патрэбныя дадатковыя. рэсурсы ў розны час, можна атрымаць з аднаго сервера максімальную прадукцыйнасць, калі правільна спланаваць і разбалансаваць клеткі паміж серверамі. У выпадку неабходнасці клеткам можна гэтак жа і выстаўляць абмежаванні па выкарыстоўваным рэсурсе.
А што тамака з поўнай віртуалізацыяй?
Наколькі мне вядома, cbsd падтрымлівае працу bhyve і XEN гіпервізары. Другім я ніколі не карыстаўся, а вось першы гэта адносна малады . Мы разгледзім прыклад выкарыстання bhyve у прыкладзе далей.
Устаноўка і настройка акружэння хаста
Мы выкарыстоўваем ФС . Гэта вельмі магутная прылада для кіравання прасторы на серверы. Дзякуючы 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 і астатніх кружэлак у масіве. І ствараем новы .
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 for jails
nat pass on $IF_PUBLIC from $JAIL_IP_POOL to any -> $IP_PUBLIC
## Bitcoin network port forward
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/bitcoindjexec 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 і вэб-аплікацыю, якая па нейкіх прычынах на апачы і пхп, а яшчэ для апошняй патрэбна БД 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 МБ пакетаў ізалявана
далей мы падпампоўваем гітом наша дадатак і запускаем.
# 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 брандмаўэр
Паглядзім, якія ў нас ІП у клетак і як наогул выглядае наша «лакалка».
# 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, таму такі ж кашалёк мы збіраемся выкарыстоўваць у сябе на
лаптопах. Пакуль будзем электрум выкарыстоўваць з публічнымі серверамі, а пазней у яшчэ адной клетцы паднімем , Што б зусім ні ад каго не залежаць.
# cbsd jsconstruct-tui
# cbsd jstart electrum
# jexec electrum
electrum:/@[8:45] # pkg install py36-electrum
яшчэ 700 МБ софту ў нас у клетцы
electrum:/@[8:53] # adduser
Username: wallet
Full name:
Uid (Leave empty for default):
Login group [wallet]:
Login group is wallet. Invite wallet into other groups? []:
Login class [default]:
Shell (sh csh tcsh nologin) [sh]: tcsh
Home directory [/home/wallet]:
Home directory permissions (Leave empty for default):
Use password-based authentication? [yes]: no
Lock out the account after creation? [no]:
Username : wallet
Password : <disabled>
Full Name :
Uid : 1001
Class :
Groups : wallet
Home : /home/wallet
Home Mode :
Shell : /bin/tcsh
Locked : no
OK? (yes/no): yes
adduser: INFO: Successfully added (wallet) to the user database.
Add another user? (yes/no): no
Goodbye!
electrum:/@[8:53] # su walletelectrum:/@[8:53] # su wallet
wallet@electrum:/ % electrum-3.6 create
{
"msg": "Please keep your seed in a safe place; if you lose it, you will not be able to restore your wallet.",
"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
Да нашага на ланцугу кашальку надалей зможа падключыцца толькі абмежаванае кола асоб. Для таго каб не адчыняць доступ звонку ў гэтую клетку, падлучэнні па 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» network. І 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"
Remove old IP: /sbin/ifconfig em0 inet 192.168.0.6 -alias
Setup new 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 = socks5polipo:/@[9:42] # sysrc polipo_enable=YES
polipo:/@[9:43] # service polipo start
Ну вось, зараз у нашай сістэме ёсць два проксі-сервера, і абодва выводзяць праз TOR: socks5://192.168.0.2:9050 і
Цяпер можна наладзіць асяроддзе нашага кашалька
# 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:22tor:/@[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
The authenticity of host 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:iW8FKjhVF4yyOZB1z4sBkzyvCM+evQ9cCL/EuWm0Du4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'mdjus4gmduhofwcso57b3zl3ufoitguh2knitjco5cmgrokpreuxumad.onion' (ECDSA) to the list of known hosts.
FreeBSD 12.1-RELEASE-p1 GENERIC
To save disk space in your home directory, compress files you rarely
use with "gzip filename".
-- Dru <[email protected]>
wallet@electrum:~ % logout
Поспех!
Для працы з імгненнымі і мікра-плацяжамі нам гэтак жа неабходна нода , уласна гэта будзе наш асноўны працоўны інструмент з біткойнам. У *, які мы збіраемся выкарыстоўваць у якасці дэмана, ёсць , які з'яўляецца паўнавартасным 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
Username: 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
#allow only c-lightning
rpcallowip=192.168.0.7/32bitcoind:/@[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:9735tor:/@[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 plugin
# 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
# for the example above the initialization logs (mixed with lightningd logs) should print something likelightning@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, і гэта вельмі зручна. рабіць розныя іншыя крутыя штукі, накшталт адпраўкі снапшотаў па SSH. Апісваць гэта не будзем, дык вось ужо шмат.
Варта таксама адзначыць неабходнасць выдаленага маніторынгу хаста, у нас для гэтых мэт .
Б - бяспека
Што да бяспекі, давайце зыходзіць з ключавых прынцыпаў у кантэксце інфраструктры:
Канфідэнцыяльнасць - Стандартныя прылады UNIX-падобных сістэм забяспечваюць выкананне гэтага прынцыпу. Мы лагічна падзяляем доступ да кожнага лагічна асобнага элемента сістэмы - клетцы. Доступ ажыццяўляецца з дапамогай стандартнай карыстацкай аўтэнтыфікацыяй па асабістых ключах карыстальнікаў. Уся камунікацыя паміж і да канчатковых клетак адбываецца ў шыфраваным выглядзе. Дзякуючы шыфраванню дыскаў мы можам не турбавацца і захаванасці дадзеных падчас замены дыска ці міграцыі на іншы сервер. Адзіны крытычны доступ з'яўляецца доступ да хост-сістэме, бо такі доступ забяспечвае ў агульным выпадку доступ да дадзеных усярэдзіне кантэйнераў.
цэласнасць - Выкананне гэтага прынцыпу адбываецца на некалькіх розных узроўнях. Па-першае важна адзначыць што ў выпадку сервернага абсталявання, ECC памяці, ZFS ужо "са скрынкі" клапоціцца аб цэласнасці дадзеных на ўзроўні бітаў інфармацыі. Імгненныя снапшоты дазваляюць рабіць рэзервовае капіраванне ў любы момант часу на лета. Зручныя інструменты экспарту-імпарту клетак робяць простым рэпліцыраванне клетак.
даступнасць - Тут ужо апцыянальна. Залежыць ад ступені вашай вядомасці і факту наяўнасці ў вас ненавіснікаў. У нашым прыкладзе мы забяспечылі даступнасць кашалька выключна з ТОР сеткі. Пры неабходнасці можна на фаерволе заблакаваць усё і дазволіць доступ да сервера выключна праз тунэлі (ТОР ці ВПН гэта іншае пытанне). Такім чынам сервер будзе адрэзаны ад знешняга свету наколькі гэта магчыма, і паўплываць на яго даступнасць зможам толькі мы самі.
Немагчымасць адмовы - А гэта залежыць ад далейшай эксплуатацыі і захавання верных палітык карыстацкіх правоў, доступу і г.д. Але пры правільным падыходзе ў нас усе дзеянні карыстальнікаў аўдытуюцца, а дзякуючы крыптаграфічным рашэнням магчыма адназначна ідэнтыфікаваць хто і калі здзяйсняў тыя ці іншыя дзеянні.
Вядома апісаная канфігурацыя не з'яўляецца абсалютным прыкладам як яно павінна быць заўсёды, гэта хутчэй адзін з прыкладаў, як яно можа быць, захоўваючы за сабой вельмі эластычныя магчымасці маштабавання і кастамізацыі.
А як жа поўная віртуалізацыя?
Пра поўную віртуалізацыю сродкамі cbsd можна . Я толькі дадам, што для прац bhyve неабходна ўключыць некаторыя параметры ядра.
# cat /etc/rc.conf
...
kld_list="vmm if_tap if_bridge nmdm"
...# cat /boot/loader.conf
...
vmm_load="YES"
...Так што калі раптам ёсць неабходнасці завесці докер, то ўздымаем які-небудзь debian і наперад!
Вось і ўсё
Мабыць, гэта ўсё чым я хацеў падзяліцца. Калі Вам спадабаўся артыкул то мне можна закінуць біткойнаў . Калі хочаце паспрабаваць клеткі ў дзеянні і ёсць крыху біткойнаў, то можна зайсці на мой .
Крыніца: habr.com