Так склалося, що я за фахом адміністратор комп'ютерних систем і мереж (короче: сісадмін), і довелося розповісти трохи більше ніж за 10 років проф. діяльності різних систем, включаючи тих, що вимагають [за | підвищених заходів безпеки. А ще склалося, що якийсь час тому я знайшов для себе цікавим , І не просто ним користувався, а й запустив кілька мікро-сервісів, щоб навчитися самостійно працювати з мережею біткойна (він же p2p як ніяк) з точки зору розробника (я звичайно такий собі dev, так, повз проходив). Але я не про розробку, я про безпечне та ефективне оточення для додатків.
Фінансові технології (FinTech) йдуть поряд з інформаційною безпекою (INFOSEC) і перше без другого працювати може, але недовго. Ось тому я хочу поділитися своїм досвідом і набором інструментів, що я використовую, який включає в себе як FinTech, Так і INFOSEC, причому одночасно, а також може бути використаний і в ширшому або зовсім іншому призначенні. У цій статті розповім не так про біткойн, як про модель інфраструктури для розробки та експлуатації фінансових (і не тільки) сервісів — одним словом тих сервісів, де «Б» має значення. Застосовно це як до біткойнової біржі, так і до самого типового корпоративного зоопарку сервісів невеликої компанії з біткойном не пов'язаної.
Хочу відзначити, що я прихильник принципів «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Хм, але тепер у нас перестане працювати сама система. Однак ми можемо вказати системний proxy. Але є одне, але на 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 <genesis@istar.ca>
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
